SAP PI (Process Integration) Overview

What is SAP PI?

SAP NetWeaver Process Integration (SAP PI) is a component of the NetWeaver product group used to facilitate the exchange of information among a company's internal software and systems and those of external parties.



All the business modules (FICO, MM, SD, HR) are developed in ABAP while PI are developed mostly in Java. These modules are not executable but they need to be deployed in an Application Server i.e.  ABAP Web Application Server for ABAP modules and Java Web Application Servers for Java modules.

Legacy System

While implementing the SAP ERP in a large business establishment, it is found that not all sections can be brought under the SAP ERP. Many of the business sections may have their own proprietary tools which are highly complex and may not be possible to be replaced. They run parallel to the SAP System. They are called the Legacy Systems. Then it becomes necessary to integrate between the SAP Systems and such pre-existing non-SAP System. This is where the SAP PI comes into play.

Why do we need SAP PI                           Apart from Legacy Systems, in a large business establishment, SAP ERP does not consist of a single system but several integrated systems i.e. CRM, SRM and FICO etc. To handle with such complexities SAP introduced Process Integration a platform to provide a single point of integration for all systems without touching existing complex network of legacy systems. This is a powerful middleware by SAP to provide seamless end to end integration between SAP and non-SAP applications inside and outside the corporate boundary. SAP PI supports B2B as well as A2A exchanges, supports synchronous and asynchronous message exchange and includes built in engine for designing and executing Integration Processes.

SAP PI Architecture

We can divide the SAP PI into 4 main areas:

• Integration Builder
• Integration Server
• Central Monitoring
• System Landscape Directory

Integration Server is the central processing engine of the SAP PI. All messages are processed here in a consistent way. It consists of three separate engines

1. Integration Engine
2. Adapter Engine
3. Business Process Engine

Integration engine can be considered to be the hub and the Adapter engine the spoke. Regarding the Business Process Engine, I will explain it later. 

Integration Builder is a client-server framework for accessing and editing integration objects and it consists of two related tools:

1. Enterprise Service Repository – to design and develop objects to be used in scenarios
2. Integration Directory – to configure the ESR objects to develop scenarios

Two together, we built integration processes which are commonly called scenarios.  

The System Landscape is a central repository of information about software and systems in data center and simplifies the administration of your system landscape.

In Configuration and Monitoring we can monitor the messages and adapters.

Integration Engine

The Integration Engine is responsible for central Integration Server services i.e. the pipe-line steps - routing and mapping. If the source message structure is different from the target message structure, then integration engine calls the Mapping Runtime, where source structure is converted to the target structure. The Mapping Runtime is based on the Java stack.  The integration engine can also utilize an ABAP program for the conversion, which is based on the ABAP stack.

A message can be of two types

1. Synchronous      - has both the request-response part
2. Asynchronous    - has either the request or the response part only

   

In PI, message is represented by an interface.

Interface -> structure of the message in XML format + direction

Based on the above criteria, there are three types of interfaces

1. Outbound interface         - connect to the sender system
2. Inbound interface           - connect to the receiver system
3. Abstract interface           - connect to the BPE

When we configure integration logic (scenario) in the SAP PI as per our business requirements, it is the integration engine which executes that configuration in a step-wise manner. Pipeline is the term used to refer to all steps that are performed during the processing of an XML message. The pipe-line steps consist of the following:

1. Receiver Identification - determines the system that participates in the exchange of the message.
2. Interface Determination - determine which interface will should receive the message.
3. Message Split - if more than one receiver are found, PI will instantiate new message for each receiver.
4. Message Mapping - mapping to transform the source message to destination message format.
5. Technical Routing - bind a specific destination and protocol to the message.
6. Call Adapter - send the transformed message to the adapter or a proxy.

Adapter Engine

You must have noticed earlier that the integration engine handles messages in XML-SOAP protocol only. But what if we have a sender and a receiver business system where the data is not in the same format. We use the various adapters in the Adapter Engine to convert XML- and HTTP-based messages to the specific protocol and format required by these systems, and vice versa.

As we have discussed earlier, SAP PI is a hub and spoke structure where the Adapter Engine can be considered as spoke. We use the Adapter Engine to connect the Integration Engine (Hub) to the external systems. The Adapter Framework is the basis of the Adapter Engine. The Adapter Framework is based on the SAP J2EE Engine (as part of the SAP Web Application Server) and the J2EE Connector Architecture (JCA). The Adapter Framework provides interfaces for configuration, management, and monitoring of adapters.

In a dual stack system, most of the adapters where based on the Java stack barring two adapters which are based on the ABAP stack.

Java Stack	RFC adapter, SAP Business Connector adapter, file/FTP adapter, JDBC adapter, JMS adapter, SOAP adapter, Marketplace Adapter, Mail adapter, RNIF adapter, CIDX adapter
ABAP stack	IDOC adapter and HTTP adapter

When SAP PI moved from dual stack to single stack then these two adapters became part of the Java stack. The modified adapter engine is known as the Advance Adapter Engine and the two adapters are called the IDOC_AAE adapter and HTTP_AAE adapter respectively.

Business Process Engine

The Business Process Engine is responsible for executing and persisting integration processes.

BPM stands for cross-component Business Process Management or ccBPM and is also called Integration process. An integration process is an executable, cross-system process for processing messages. In an integration process you define all the process steps that are to be executed and the parameters relevant for controlling the process. Business Process Management provides SAP Exchange Infrastructure with the following functions:

1. State-full message processing: The status of an integration process is persisted on the Integration Server.
2. You can also use correlations to establish semantic relationships between messages.
3. You implement integration processes when you want to define, control, and monitor complex integration processes that extend across enterprise and application boundaries i.e. collect/Merge, Split, Multicast

At runtime, the Business Process Engine executes the integration processes. The integration process can send and receive messages using abstract interfaces only. 

Build a scenario in SAP PI

We start from the Home page if we have to build a scenario in PI.

The home page will look similar to as given below:

Figure 6 – Home Page for SAP PI Java Stack

The Home page has hyperlinks to the following 4 working areas

1. Enterprise Services Repository (ESR)
2. Integration Directory (ID)
3. System Landscape (SL)
4. Configuration and Monitoring (CM)

Each hyperlink will open one application. All these four are Java application. ESR and ID are swing applications. They are launched from the browser based on JNLP. So for the first time it takes more time as it downloads the entire library file. But from second time onwards, it takes less time to launch. SL and CM are pure web applications and run on the browser.

Enterprise Services Repository

Here we design and create objects to be used in the making of an integration scenario. The data flow in PI will look similar to as shown below:

We find the option to design the following

1. Interface objects – Service Interface, Message Type, Data Type
2. Mapping objects – Operation Mapping and Message Mapping
3. Integration Processes

PI uses integration repository to design message structure for both sender and receiver systems and develop an interface message using corresponding message structures which act as a point of interaction to the outside world. Data type and Message type are used to simplify and modularize the design of a complex interface.

Operation Mapping allows transformation of source structure to target structure when the two structures are different. But if the source and the target structure are same then the operation mapping may be dispensed off. Similar to service interface, message mapping is used to simplify and modularize the design of a complex operation mapping. Message mapping can be implemented in 4 ways

1. Graphical Mapping
2. Java Mapping
3. XSLT Mapping
4. ABAP Mapping

Graphical mapping is the most used as it allows developer to map attributes of both structures graphically to pass data using service interfaces. For the other three, we have to develop the mapping by writing code. If it is a single stack server, then the ABAP mapping will not be available.

There are other areas also, but they are not covered in this tutorial.

Integration Directory

Here we make the pipe-line steps by configuring the ESR objects created earlier. These steps are executed by the integration engine during run-time.

Before we start the configuration we need to create/import the following objects in the DIR.

1. Service - Business System/ Business Service/ Integration Process
2. Communication Channel

A service enables you to address a sender or receiver of messages. Depending on how you want to use the service, you can select from the following service types.

1. Business System - If you want to address a particular business system as the sender or receiver of messages, choose this service type. A business system is an actual application system in a system landscape.
2. Business Service - If you want to address an abstract business entity as the sender or receiver of messages, choose this service type. A business service is not defined in the system landscape.
3. Integration Process Service - If you want to address an integration process as the sender or receiver of messages, choose this service type. At runtime, these integration processes are controlled by messages and can themselves send messages.

Communication channel determines the inbound and outbound processing of messages. The messages are converted from native format to soap-xml specific message format and vice-versa through the adapter.  Generally there are two types of communication channel in a scenario

1. Sender Communication channel
2. Receiver Communication channel

You must assign a communication channel to a service. Depending on whether the service is addressed as a sender or receiver of messages, the assigned communication channel has the role of either a sender or a receiver channel, and must be configured accordingly. You cannot assign a communication channel to an integration process service.

The pipe-line steps are created by creating the following 4 configuration in the DIR

We find the following options:

1. Sender Agreement
2. Receiver Determination
3. Interface Determination
4. Receiver Agreement

Sender agreement defines how the message of a sender is to be transformed so that it can be processed by the Integration Server. It consists of the following

1. Sender Component
2. Sender Interface
3. Sender Communication Channel

  Sender Agreement is similar to primary key in table. There cannot be the two similar sender agreements in one landscape. 

Receiver Agreement defines how the message is to be transformed so that it can be processed by a receiver. It consists of

1. Sender Component
2. Receiver Component
3. Receiver Interface
4. Receiver Communication channel

You use a receiver determination to specify which receivers a message is to be sent to. You have the option of defining conditions for forwarding the message to the receivers. It consists of

1. Sender Component
2. Sender Interface
3. Receiver Component

Receiver Determination is of two types – Standard or Extended, depending upon whether you want to specify the Receiver manually or dynamically by a mapping at runtime. 

You use an interface determination to specify which inbound interface of a receiver; the message is to be forwarded to. You can also specify which interface mapping from the Integration Repository is to be used for processing the message i.e. if the sender and the receiver interface are not of the same format then there is an operational mapping to change the format. You define an interface determination for a sender, an outbound interface, and a receiver. It consists of

1. Sender Component
2. Sender Interface
3. Receiver Component
4. Receiver Interface

Interface Determination is of two types – Standard or Enhanced, depending upon whether you want to specify the receiver interface manually or through mapping-based message split. 

Receiver Determination and Interface Determination – the two together are commonly known as the logical routing. Sender Agreement and Receiver Agreement – the two together are commonly known as the Collaboration Agreement.

System Landscape

The SAP System Landscape Directory (SLD) is the central information provider in a system landscape. In the web page you will find the following links:

1. Technical System - Technical systems are application systems that are installed in your system landscape.
2. Business System - Business systems are logical systems, which function as senders or receivers within PI. Business Systems has one-to-one dependency with the associated technical system.
3. Products and Components – This is information about all available SAP products and components, including their versions. If there are any third-party products in the system landscape, they are also registered here.

The SLD will look similar to as given below:

Figure 11 – System Landscape

Products and Components are commonly called the Component Information

Technical System and Business System are commonly called the Landscape Description.

A business system can be configured as an Integration server or Application system.

1. Integration Server - The Integration server executes only integration logic configured in the Integration Builder. They can also be identified as Pipe Line Steps. It receives XML message, determines the receiver, executes the mappings, and routes the XML message to the corresponding receiver systems. Thus configured Integration Engine is identified to be Central Configured Integration engine.
2. Application system - The Application system will not execute the integration logic. It in turn calls the integration server to execute the integration logic if required. It acts as sender or receiver of XML messages. So, the Application system with a local Integration Engine requires the Integration server to execute the integration logic.

Only one client of SAP system can be configured as Integration Server.

The following information are extracted from the SLD into the ESR and DIR

1. Component Information are used in the ESR to define the Product and the SWCV
2. Business System are used in the Directory for defining the sender and receiver of messages

Configuration and Monitoring

It is the central entry point for monitoring purposes. This gives you the option of navigating to the monitoring functions of the Integration Engine, as well as integration with the Computing Center Management System (CCMS), and the Process Monitoring Infrastructure (PMI) of SAP.

The Configuration and Monitoring will look similar to as given below:

Figure 13 – Configuration and Monitoring

With the Configuration and Monitoring the following monitoring functions are supported:

1. Component monitoring - monitoring the different SAP PI components (Java and ABAP parts).
2. Message monitoring - tracking the message processing status within an SAP PI component and on error detection and analysis.
3. End-to-end monitoring - monitoring of a message lifecycle from the SAP PI point of view.
4. Performance monitoring - statistics about different performance aspects of SAP PI can be accessed through the RWB. Here, you can select and aggregate performance data, for example, by component, time range, or message attributes.
5. Index administration - by administering and monitoring the indexing of messages per SAP PI component, you enable an index-based message search that you can use in message monitoring. This kind of message search offers you enhanced selection criteria including adapter-specific message attributes and terms or phrases from the message payload.
6. Alert configuration - by using the Alert Framework, central monitoring in PI can be provided with all errors reported during message processing in ABAP and Java. This enables an improved reaction to such errors in both the ABAP runtime and the Java-based Adapter Engine. For this purpose, the Alert Framework is provided with rules based on certain events and on information from the header of the PI message protocol. These rules determine whether alerts are send or not. If an alert is sent, it can be used for error analysis.
7. Alert inbox - the alert inbox is user-specific and displays all the alerts for each alert server that has been generated based on the alert configuration.
8. Cache monitoring - cache monitoring displays objects that are currently in the runtime cache. Different cache objects are monitored depending on the cache instance concerned.

Synchronous vs. Asynchronous communication

A process can be defined as either synchronous or asynchronous.

• A synchronous process is invoked by a request/response operation, and the result of the process is returned to the caller immediately via this operation.
• An asynchronous process is invoked by a one-way operation and the result and any faults are returned by invoking other one-way operations. The result is returned to the caller via a callback operation.

In the computer world, there is no asynchronous communication. All communication between two systems is always via method call (request/response operation). So how do we make it asynchronous? The answer lies with the introduction of a third system in between the called and the caller function.

Suppose there are two systems – A and B. All communication between A and B is via a method call and thus they are synchronous. We introduce a third system between A and B and called it the Intermediate system – I. The communication between A and I is via method call and similarly between I and B is also via method call. But the communication between A and B can be called asynchronous as A does not have to wait for the response from B.

This is the basis of asynchronous communication and what is this intermediate system? That is the Queue. A is called the sender and B is called the receiver.  Message from A is first added to the Queue and then it is again pulled from the Queue and send to B. The response from B reaches A in a similar fashion.  In certain situation, the business requirement needs the messages to be delivered to B in the same order as they are triggered from A. In such case we follow a first-in and first-out policy. If there are no such requirements then messages are sending from the queue to B in any order.

With asynchronous communication, we achieve guaranteed delivery i.e. System B is not available when System A sends the message. The message is added to the queue and remains there as long as B is not available. Once B is available, the message is pulled from the queue and sends to B. 

So we can classify our message communication in three ways:

1. Synchronous
2. Asynchronous with order not maintained
3. Asynchronous with order maintained

In PI, we identify them as: Synchronous – BE (Best Effort), Asynchronous with order not maintained – EO (Exactly Once), Asynchronous with order maintained – EOIO (Exactly Once in Order).  

Acknowledgment

Acknowledgment is the root of asynchronous communication. Why?

For synchronous communication, System A calls system B and if B fails to send the response the process failed. But in an asynchronous communication, System A calls System I and System I calls System B. So suppose the communication between A and I is successful but between I and B, it fails. How should A realize that the delivery to B has failed? This is realized by an acknowledgment which is send back to A by B via the same route as the message from A took to B. If the acknowledgment from B fails to arrive to A then A consider that the process has failed and will send the message again.

While we discussed about asynchronous communication in PI, we have used the term – ‘Exactly Once’ for both EO and EOIO. Exactly Once means a message delivered once cannot be delivered again. To achieve this, there is an acknowledgment for every message send from A to B. It is the adapters which lie at the end of the communication. So the adapters must support acknowledgment.

All adapters’ provide system-acknowledgment i.e. delivery acknowledgment. Those adapters which support synchronous communication support application-acknowledgment in addition to the system acknowledgment.

So in PI, following are the type of acknowledgment

1. System Acknowledgment - System acknowledgments used by the runtime environment to confirm that an asynchronous message has reached the receiver.
2. Application Acknowledgment - Application acknowledgments used to confirm that the asynchronous message has been successfully processed at the receiver.

   

Remote Function Call

While working in PI, you will come across the term - RFC. What are they? To establish communication between two SAP systems i.e. an R/3 and PI, we create the RFC Destination. It is configured by the following

1. Connection Type
2. IP Address and Port of the receiver

  Connection Type tells the type of System Connection i.e. R/3, TCP/IP, Internal etc. 

The RFC Destination we create is classified according to the mode of communication required i.e. whether it should support synchronous or asynchronous communication.

1. for synchronous communication - Synchronous RFC
2. for asynchronous communication with order not maintained - Transactional RFC
3. for asynchronous communication with order maintained - Queued RFC

  They are identified by sRFC, tRFC and qRFC. 

When SAP PI is not recommended in enterprise SOA (Service Oriented Architecture)

• SAP PI is not recommended for synchronous communication as it will put a significant load on the infrastructure service for servicing a synchronous request
• SAP PI is not recommended for UI driven scenarios if the backend is exposed as enterprise services
• SAP PI is not needed for intermediation if a non-SAP backend like J2EE or .NET platform is exposing business services in a UI scenario