SAP PI Tutorials
Welcome to the SAP PI Tutorials. The objective of these tutorials is to get in depth understanding of SAP PI . In these tutorials, we will cover various SAP PI with examples. The tutorial starts with overview of SAP PI .
In addition to these tutorials, we will also cover common issues, Interview questions and How To’s of SAP PI .
SAP NetWeaver Process Integration (SAP PI) is SAP's enterprise application integration (EAI) software, 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.
SAP offers not only links to SAP product documentation, but also links to related information. All links are categorized for transparency:
- Links with no icon: Links to SAP product documentation
- Links with the icon: You are entering an SAP-owned site that is not part of SAP product documentation. By using such links, YOU AGREE that unless expressly stated otherwise in your agreements with SAP, the content of such sites is not part of SAP product documentation and that you may not infer any product documentation claims against SAP based on this information.
- Links with the icon: You are entering a site that is not hosted by SAP. By using such links, YOU AGREE that unless expressly stated otherwise in your agreements with SAP
The content of the linked-to site and any further external site is not product documentation and that you may not infer any product documentation claims against SAP based on this information.
The fact that SAP provides links to external sites does not imply that SAP agrees or disagrees with the contents and information provided on such sites. SAP does not guarantee the correctness of the information provided.
Architecture of SAP PI
The SAP PI consists of a hub and spoke structure; the spokes connect with external systems while the hub exchange messages between them. The source system is known as the sender system and the target system is known as the receiver system. The PI is not a single component, but rather a collection of components that work together flexibly to implement integration scenarios. The architecture includes components to be used at design time, at configuration time and at run time.
We can divide the SAP PI into several areas
-Configuration and Monitoring
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
-Business Process Engine
Interested in mastering SAP PI Training? Enroll now for FREE demo on SAP PI Training.
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:
Enterprise Service Repository – to design and develop objects to be used in scenarios
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.
Single stack and Dual stack
When PI was first released, not all components were built on the same platform. Integration Engine and Business Process Engine was built in ABAP while Adapter Engine, Integration Builder, SL, CM and Mapping Runtime were built in Java. So PI needs both the Java and the ABAP environment to run and is known as the dual stack.
But in the later version all the components are built in Java. Some of the dual-stack components are either dispensed off or modified to work on the Java stack. So PI needs only the Java environment to run and is known as the single stack.
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
Synchronous - has both the request-response part
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
Outbound interface - connect to the sender system
Inbound interface - connect to the receiver system
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:
-Receiver Identification - determines the system that participates in the exchange of the message.
-Interface Determination - determine which interface will should receive the message.
-Message Split - if more than one receiver are found, PI will instantiate new message for each receiver.
-Message Mapping - mapping to transform the source message to destination message format.
-Technical Routing - bind a specific destination and protocol to the message.
-Call Adapter - send the transformed message to the adapter or a proxy.
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.
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:
-State-full message processing: The status of an integration process is persisted on the Integration Server.
-You can also use correlations to establish semantic relationships between messages.
-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.
Learn more about SAP PI Interview Questions in this blog post.
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:
The Home page has hyperlinks to the following 4 working areas
-Enterprise Services Repository (ESR)
-Integration Directory (ID)
-System Landscape (SL)
-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
-Interface objects – Service Interface, Message Type, Data Type
-Mapping objects – Operation Mapping and Message Mapping
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
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.