Enterprise Resource Planning Dr. Djamal Ziani

ENTERPRISE SYSTEMS ARCHITECTURE CHAPTER 5 ENTERPRISE SYSTEMS ARCHITECTURE 2

Outline Examine the enterprise systems modules and architecture. Understand the implication of good architecture on ERP implementation. Know the various types of ERP architectures and the related benefits and drawbacks of each architecture. Learn about the Service Oriented Architecture and its impact on ERP systems. 3

Benefits to study Enterprise System Architecture Help management and the implementation teams understand in detail the features and components of the enterprise system. Provide a visual representation of the complex system interfaces among the ERP application and databases, operating systems, legacy applications, and networking. Management can develop a better IT plan.

Enterprise Systems Architecture (ESA) Model

Architecture categories Two-tiers architecture Three-tiers architecture Service oriented architecture

Two-tiers architecture The server handles both application and database duties

Two-tiers architecture Benefits Easy-to-use and access to information and services Low cost in terms of infrastructure requirements High performance with a limited number of workstations Drawbacks Inflexible in terms of adding more clients and software Requires expensive middleware for integration Changes or modifications in database affect applications Limited flexibility in moving program functionality from one server to another

Three-tiers architecture Data Tier (Data Management) Business Tier (Business logic of functional modules) Presentation Tier (End-User Interface—GUI)

Three-tiers architecture Benefits End-users have access to ERP applications over the Web. Easily integrate ERP applications with existing systems. Server-centric—No complex, expensive client software installation. Client-centric—Architecture has better response time because user requests are mostly processed on the client’s computer. Web-based architectures also allow better system-to-system integration. Drawbacks Client-centric architectures lack security

Example of Two-tiers architecture SAP R/2 is mainframe solution and was first compact software package for the whole spectrum of business applications. It runs on mainframes, such as IBM, Siemens, Amdahl. The current version of R/2 is 6.1.

Example of Three-Tiers architecture SAP R/3 is SAP' integrated software solution for client/server and distributed open systems. SAP R/3 is the world’s most-used standard business software for client/server computing. R/3 meets the needs of a customer from the small companies to multi-billion dollar companies. The software is highly customizable using ABAP programming language.

Service Oriented Architecture Also known as object-oriented architectures for Web platforms Breaks the business tier into smaller, distinct units of services, collectively supporting an ERP functional module Allows message interaction between any service consumer and service provider A consumer from a device using any operating system in any language can use this service.

service-oriented architecture (SOA)

Benefits of SOA Business-level software services across heterogeneous platforms Complete location independence of business logic Services can exist anywhere (any system and any network) Loose coupling across application services Granular authentication and authorization support Dynamic search and connectivity to other services

Benefits of SOA Enhances reliability of the architecture Reduces hardware acquisition costs Leverages existing development skills Accelerates movement to standards-based server and application consolidation Provides a data bridge between incompatible technologies

Strong and use coupling Strong coupling occurs when a dependent class contains a pointer directly to a concrete class which provides the required behavior. Loose coupling occurs when the dependent class contains a pointer only to an interface, which can then be implemented by one or many concrete classes. Loose coupling provides extensibility to designs. A new concrete class can easily be added later that implements that same interface without ever having to modify and recompile the dependent class. Strong coupling does not allow this.

loose coupling

Drawbacks of SOA SOA implementations are costly and time-consuming Requires complex security firewalls in place to support communication between services Performance can be inconsistent Requires enterprise-level focus for implementation to be successful

SAP eSOA Enterprise SOA is SAP's business oriented version of SOA (Service-Oriented Architecture) and SAP’s blueprint for developing flexible and services based business solutions. ESOA enables the rapid composition of business solutions by encapsulating business logic and expose it as enterprise services ESOA supports reassembling smaller functionality components and to develop new innovative business solutions that meet ever changing business requirements.

SAP eSOA eSOA = ES (Enterprise Service) + SOA Enterprise SOA provides business with an IT strategy and a top-down approach to define enterprise services and also to guide the deployment of Web services at a business process level.

Enterprise Service (ES) It is a service which provides business functionality and which is published by SAP in the enterprise services workplace in the SAP Developer Network (SDN) Enterprise services have the following Business semantics: The model is based on process components, business objects and global data types (GDTs) based on open standards. The interfaces are described according to WSDL

SAP Enterprise Architecture framework

Runtime Architecture Overview

HTTP Communication Layer at SAP, all SOAP messages are sent via HTTP The main task of the layer is to accept incoming HTTP requests and dispatch them to the appropriate receiver.

Web Service Enabling Layer receives HTTP-based SOAP messages from the HTTP Communication Layer It interprets the SOAP messages and extracts the parameters for calling a Web service. The layer contains the Web service proxies, which are the implementation components that implement the Web service interface by forwarding calls to existing mySAP applications.

Web Service Enabling Layer

Categories of web services Synchronous service: the client invoking a service and then waiting for a response to the request. Because the client suspends its own processing after making its service request, synchronous services are best when the service can process the request in a small amount of time. Asynchronous service: the client invokes the service but does not -- or cannot -- wait for the response. Often it may take a significant amount of time for the service to process the request.

Synchronous Web Services

Processes of Synchronous Service Dispatching a request (steps 1–3) Processing a request (steps 4–5) Sending a response (steps 6–8)

Dispatching a request The Internet Communication Manager (ICM) decides whether to forward an incoming request to the ABAP stack or the Java stack (base on URL part) The Internet Communication Framework (ICF) receives all HTTP requests which are sent to the ABAP stack and forwards the request to the appropriate application.

Processing a request Reads the information in the SOAP header and extracts the Web service data from the body of the message. The extracted XML Web service data is forwarded to the proxy framework. The proxy framework maps the data from XML to ABAP data structures and invokes the appropriate Web service proxy. local calls to function modules, BAPIs and RFCs of mySAP applications