Design Time

 

At configuration time, an integration expert (for example, an integration consultant) configures the integration scenario specified at design time for a specific system landscape to enable the scenario to run in this system landscape.The first configuration task is to identify, the “players” of the game at runtime – the systems that actually communicate with each other – and relate them to the corresponding process components. The following figure illustrates the relationship between the entities defined at design time (above, the communication of two process components including the entities introduced with figure 3) and those relevant at configuration time (below, for an exemplary system landscape). The different colors of the systems indicate the different technical characteristics the systems may be based on:

Figure 5: Relationship between design time and configuration time entities

Based on this assignment, an integration expert specifies further details at configuration time on how the messages are to be exchanged between the systems: x How the messages are routed by the integration broker from a sender system to one or multiple receiver systems x How the individual systems (each may be based on different technical characteristics) can be connected to the integration broker (connectivity and adapters) x Which security-relevant settings apply to the data exchange (for example, if messages are secured using digital signatures) The configuration time-relevant concepts and procedures are explained in detail in the chapter  Configuring Integration Content

Phases of an Integration Project

 

Based on this decoupling, it is possible to describe the integration-relevant aspects of a business process at an abstract level first – irrespective of the details of a particular system landscape. We call the corresponding phase of an integration project the design time. At design time, those parts of a business process can be specified that are independent from any technical details which are  implementation-relevant or system landscape-relevant. We have already introduced the integration scenario as a high-level description of the integration at design time and we will continue to use this term in the following discussion. In a later phase – at configuration time – the integration scenario will be configured to run in a specific system landscape. You can consider one and the same integration scenario to be deployed on completely different system landscapes. For example, in one case there is a material management integration scenario that spans only few systems within a midsize company, whereas in another case the same integration scenario spans several hundreds of systems located in the different departments of a large enterprise. The same scenario in this case involves the execution of the same business logic - just on a completely different scale. The scenario is finally executed at runtime and can be monitored by an administrator. The following figure illustrates the relationship of the design time and configuration time view

Figure 3: Integration scenario (design time view; left) and assignment of process components to systems of the actual system landscape (configuration time view; right) As an example, the figure shows the systems of the actual system landscape where the business logic of process components 1 and 2 is implemented: Process component 1 is deployed on systems 1a and 1b, whereas process component 2 is deployed on systems 2a, 2b, and 2c. Resulting from this, the communication between two process components is broken down to communication between the systems mentioned above at runtime, whereas the communication is mediated by an integration broker. The three phases introduced here can be considered to be phases of an integration project: They form the basic framework for the detailed description of the concepts in this handbook

Decoupling Business Semantics from Implementation Details

 

The preceding sections have already set out the basic concept. If we assume the different parts of a cross-system business application and their interactions to be “hard-coded” on the individual systems the process spans, then every change at the technical implementation level (such as changing a server address) would entail a change of the whole business process. This is time-consuming, error prone, and does not scale for complex business processes and large system landscapes. Therefore, one basic principle is to decouple the business semantics from the technical details of the concrete system landscape. Business semantics are, for example, the business flow of a process and its separation into individual process components, as well as the structure of exchanged data. These aspects of a business process are merely determined by business considerations rather than by details of the implementation or of the concrete system landscape.

SAP XI/PI Tutorials

Mediation

 

Technically, the business logic of different process components in an integration scenario is implemented on different systems. Let us assume that the systems involved in an integration scenario communicate directly with each other. For example, if the process components run on different SAP systems, one SAP system calls another using a remote function call. We call this kind of communication “point-to-point” or direct communication. However an upgrade to one part of the system landscape would, for example, entail that all individual connections that are affected also have to be adapted as part of the upgrade. In the case of large system landscapes, this approach could easily get out of control since the number of connections grows to the square of the number of systems. However, consider a situation where a central instance interconnects the systems as a communication hub or data hub. We call this type of communication mediated communication and refer to the data hub as the integration broker. With a central instance interconnecting the systems you then have the option to have all integration-relevant information accessible at one central location. In contrast to the point-to-point scenario where there is a “spaghetti-like” arrangement of connections, in a mediated scenario the number and arrangement of connections remains manageable. The following figure illustrates the difference between mediated and point-to-point communication:

Figure 2: Point-to-point communication (left) compared to mediated communication (right)

Mediated communication based on an integration broker is executed by exchanging XML messages. Accordingly, in the context of SAP NetWeaver PI we usually speak of message-based integration. The messages contain the business data exchanged between the systems involved in a cross-component process. The message protocol of SAP NetWeaver PI (which the integration broker can process) is based on the W3C standard SOAP Messages with Attachments (see also Messages). Note: While we do cover direct or point-to-point communication (see Setting Up Direct Communication between WSRM-  Enabled Systems), the main focus of this handbook is on mediated communication.

SAP XI Training

Integration of Processes

 

SAP NetWeaver PI is SAP’s implementation of Service-oriented Architecture (SOA) middleware and

facilitates the integration of business processes that span different departments, organizations, or companies. We will start by introducing the term process component which will accompany us throughout this handbook. A process component is part of the value chain of a business application or a business process. If we assume that a business application ranges over different departments of one company, then a process component usually represents one part of the process that is performed in one department. The following figure displays an integration scenario and shows the separation of a business application into its process components (blue icons), as well as the connections between the process components. In the example outlined in the figure, the process components run in three different departments of a company: A, B, and C. Process components can run on different systems, can be hosted in different departments of a company, or can be implemented in completely different companies that have a business relationship to each other. The process components exchange data with each other and thereby ensure that the value chain of the business process as a whole is maintained.

Figure 1: Integration scenario showing the interaction of process components

The focus of SAP NetWeaver PI is not on the inner life of the individual process components or how the

business logic is implemented within a process component but rather on how the process components

exchange data with each other. Process integration is all about the choreography of data exchange between

process components.

SAP XI Interview Questions

 

Technorati Tags: SAP PI Training,SAP PI Tutorials