Reasons for Using SAP NetWeaver Process Integration
Integration processes in a heterogeneous system landscape usually span several systems, and the external interfaces for connecting systems were implemented individually,resulting in a large number of point-to-point connections and a complicated network of relationships. Software often differ in their data structure and the protocol that they support, somapping programs are required to map the fields of the source documents to the fields of the target documents.
If processes change or new systems are added, you must change the individual interfaces in the applications accordingly, which can require a significant amount of time and effort.
The challenges regarding integration in companies can be summarized in the following points:
Challenges of Today's Integration Solutions
- Individual point-to-point integration that uses “any” technology
- Patchwork of integration solutions
- No centralized knowledge about interfaces and no way of building this knowledge
- A "homegrown" infrastructure that cannot be adapted, or only with great difficulty, and is very costly to maintain
- High costs for upgrading components
SAP NetWeaver Process Integration (SAP PI) provides a platform that enables different interfaces to interact using a common technology. SAP PI offers a central point of integration, with central information on involved processes, systems, and interfaces.
The Integration Platform of SAP NetWeaver Process Integration
As an integral part of SAP NetWeaver, SAP PI is based on an open architecture and uses open standards (in particular from the XML and Java environments).
The services provided by SAP PI are indispensable in a heterogeneous and complex system landscape:
- Central repository for interface design.
- Configuration options for controlling the message flow.
- Options for transforming message content between the sender and receiver.
- A runtime infrastructure for exchanging messages.
- Options for modeling and executing processes.
Structure of a PI SOAP message
A message in SAP PI has the following structure. The properties of the message itself are contained in the message header, for example the sender, which is used later to determine the receiver. The actual business data is contained in the "payload ". You can also attach any number of attachments (for example pictures, text documents, and so on) to the message. The message header and the payload are in XML format.
The focus of SAP PI is a SOAP message-based communication (based on an XML message format and the HTTP protocol). Application-specific content is transferred from the sender to the receiver as XML messages using the Integration Engine (IE) at runtime.
Processing of the messages on the Integration Server is stateless, that is, a message arrives, the receiver or receivers are determined, and the message is forwarded immediately.
Connecting Different Systems to SAP NetWeaver Process Integration
The message processing in SAP PI is based on PI SOAP messages. Most of the systems to be connected use different formats and protocols, that is why a variety of PI Adapters is offered by SAP and partners. The Adapter converts between the (PI internal) PI SOAP fomat and the (external used) format and protocol. SAP provides a number of adaptors for this purpose. (IDoc, File, RFC, JDBC, Mail, SOAP, RosettaNet, ...).
IDoc is an intermediate document the transport information. It is an SAP standard format for electronic data exchange between systems.
The sender system provides data in a document format, for example, IDoc, and makes it available to the adapter by means of a protocol. The adapter transforms the document to the PI SOAP format and forwards it to the Integration Server by using HTTP(S). In the configuration you specify which adaptor the receiver is to use to receive the message. The Integration Server sends the message to the relevant adapter, which in turn converts it to the protocol of the receiver and finally sends it to the receiver.
In the Integration Directory,you assign specific systems as senders and receivers to the interfaces that you defined in the Enterprise Services Repository.
Apart from Adapters, SAP systems support Proxy connectivity with PI without an Adapter: the SAP system can send and receiver PI SOAP messages directly, so no Adapter is necessary in this case. For this approach, interface descriptions are created in the Enterprise Services Repository and then, using this description, Proxies are generated in the application systems.
From a technical perspective, proxy objects are classes and methods in a programming language (ABAP or Java) that can generate and process messages for the format defined in the Enterprise Services Repository (ESR).You enter a description of all required interfaces in your company in the Enterprise Services Repository at design time. The descriptions are not platform-dependent. The description may also include mapping definitions if the data to be transferred between the interfaces is not all in the same format.
Based on a WSDL description, proxy generation generates proxy objects in an application system to use to send or receive messages.
The Principle and Advantages of Shared Collaboration Knowledge
The structure of a message is determined by the data structures of an interface. The central concept of SAP PI is that you develop all required interfaces at design time, independently of the platform, and store them in the Enterprise Services Repository (via import or manual creation). SAP PI thus applies the principle of shared collaboration knowledge.
You no longer have to search out information about a distributed process from all the involved systems (point-to-point) because you can now call this information centrally. This reduces the costs of development and maintenance of distributed applications. Another advantage to the customer as a result of using SAP NetWeaver Process Integration is that SAP ships predefined interfaces.
SAP applications (CRM, SRM, SCM, xRPM) can thus contribute their integration knowledge to the Enterprise Services Repository. If the application is enhanced, the content in the Enterprise Services Repository is also enhanced. This enables you to integrate SAP solutions “out-of-the-box” and simplifies solution upgrades.
SAP PI provides a range of adapters that enable you to connect systems to SAP NetWeaver Process Integration. Customers can also use the Adapter Framework to create their own adapters.
The Adapter Engine is a runtime component for adapters that integrate applications and systems into SAP NetWeaver Process Integration. You can deploy the Adapter Engine centrally, as part of the Integration Server (standard), or decentrally on any SAP AS Java or SAP NetWeaver AS Java.
If a customer uses SAP PI and wants to use it to communicate with a “smaller” customer, SAP provides the Advanced Adapter Engine Extended (AEX). This enables a connection using SAP PI. The smaller customer does not need to have the entire SAP PI solution installed, neither must it be an SAP customer.
In SAP NetWeaver Process Integration, you can use ccBPM to model and execute processes. This is described in more detail in the lesson “Business Process Management in SAP”.
Advantages of SAP PI and Shared Collaboration Knowledge are as follows:
- The gradual transition to SAP PI safeguards existing investments.
- Using shared collaboration knowledge reduces the costs of maintaining and developing interfaces.
- Shipment of a range of Adapters for connecting systems, as standard.
- Option of implementing customer-specific adapters for integration using the Adapter Framework.
- Option for customers to use the Avanced Adapter Engine Extended to create messages in SAP PI format without having to install the entire SAP PI solution.
- Option of modeling, executing, and monitoring cross-system processes (ccBPM).
- Additional advantages when using SAP systems.
- Integration of SAP solutions “out of the box”.
- Easier upgrade of SAP solutions.
Test Scenario Process Integration 'Making a Travel Request and Booking Flights'
The course scenario for process integration demonstrates the structure of SAP NetWeaver Process Integration and Business Process Management with Business Workflow. The scenario is as follows:
An employee of a company creates a travel request using a Business Server Page application (BSP application named ZSAPNW) in an Internet browser.
The request triggers a business workflow in the company's SAP system, which forwards the request to the employee's supervisor for approval. The approval process also uses a BSP application. In this case, the BSP page is started directly from the workflow process and a WebFlow service is used.
Once the request is approved, the employee can book the relevant flights. The requester receives a Business Workflow work item, which calls a BSP application of the Travel_Agency_Summer travel agency, which is closely linked to the company. The employee books an outbound and a return flight in the SingleFlightBooking scenario in the BSP application ZSAPNW_XIAGENT. The SingleFlightBooking service books a single flight in each case, that is, it must be called twice. The flights are booked asynchronously with the airline AA (American Airlines) or LH (Lufthansa) using SAP PI.
To keep things simple, the various systems (company, travel agency, SAP PI, airline) are different clients of the same system in the training system.
In the figure for the integration process, you can see that SAP NetWeaver Process Integration enables processes to be controlled across systems, whereby the SAP PI server assumes control of the process, thus removing point-to-point connections. SAP PI controls communication between processes, whereas Business Workflow controls communication between users within processes.
Integration Directory: Sender and Receiver Systems
During a configuration phase you then assign components, which you have defined in the Enterprise Services Repository, systems or processes as senders and receivers of messages. SAP PI calls this information thelogical routing and the corresponding objects are stored in the Integration Directory.
There you specify from which system, called communication component and with which output interface messages are sent via the Integration Server to which system with which input interface and whether a mapping program must be executed.
Unlike the figure showing design time, the figure for configuration time not only shows the inbound and outbound interfaces, but also the systems that send a message to, or receive a message from the Integration Server.
You use the Integration Builder to make these settings in the Integration Directory for each individual customer according to their specific system landscape.
To access the Integration Directory, call transaction SXMB_IFR. The application specific contents are transferred from the sender to the receiver by means of messages in a freely-definable XML schema. The structure of a message is determined by the data structures in the interface used (IDoc, file, database, and so on).
The Integration Engine on the Integration Server evaluates the configuration in the Integration Directory when an inbound message is received at runtime. It uses the configuration data to determine the receiver or receivers of the message, maps the inbound message to the interface structure of the receiver, and then forwards it for further processing. The Integration Server is the central communication and distribution machine for XML messages.
At design time, an integration scenario merely describes how communication will take place and which messages will be used. It does not describe which systems are involved.
Both the Enterprise Services Repository and the Integration Directory are written in Java and must be managed with the appropriate Java administration tools.
From a technical point of view, SAP NetWeaver Process Integration is based on an SAP NetWeaver Application Server (ABAP and Java). However, you must install this server in addition to SAP NetWeaver Process Integration. A detailed SAP installation guide is available for this purpose.
