SAP PI 7.1 Tips and Tricks

[Former Member]

This blog describes about SAP PI 7.1 Tips and Tricks:

SAP - Middleware :

SAP Process Integration (PI) is SAP’s Enterprise Application Integration (EAI) tool. It is used to facilitate the exchange of information among a company’s internal software/systems and those of external parties. SAP PI provides seamless end to end integration between SAP and Non-SAP applications inside and outside the corporate boundary.

SAP – SAP Interface:

The approach to be used for integrating two SAP systems would be as shown in the below decision tree diagram.

SAP PI (Middleware) :

In case if no standard configuration is available to integrate two SAP systems, then SAP PI should be used to create the interfaces between the two systems.

Various integration techniques are available in SAP PI to integrate two systems.

Standard IDoc Integration: 

SAP has integrated systems and applications that support IDoc format, using SAP’s Application Link Enabling (ALE) functionality. ALE is SAP proprietary technology that enables data communications between two or more SAP systems and/or between SAP systems with non-SAP systems. SAP has created a lot of different IDocs for transferring different data between the systems. In case of interfaces, this will be a preferred way of data transfer as it is a proven and stable technology and requires minimum development effort. 

SAP ABAP Proxies: In cases where there is no standard IDoc available to cater to the requirement, SAP Proxies should be used as a preferred way of integration

with the SAP system. The advantages of SAP Proxies are:

• ABAP proxies provide high performance throughput. Exchanging high volume data generally is not an issue
• With this “outside-in” approach, ABAP proxies are easy to design and provide a way of decoupling data transfer and handling application logic
• Proxy framework supports both PI communication as well as web services. This provides an added advantage of interchangeability between web services or PI for point to point interfaces
• SAP ABAP Proxy supports both synchronous and asynchronous communication with out-of-the box logging and monitoring tools

In case if there is any standard BAPI available which caters to the requirement of the interface, then that BAPI should be invoked through a proxy call rather than

directly calling it via RFC.

The following techniques can be used:

SAP inbound integration techniques:

BDC (Batch Data Communication): custom only background process of on-line transaction
IDOC (Intermediate Document): standard or custom metadata structure for processing transactions
BAPI/RFC (Business Application Programming Interface): standard or custom business program for processing standard transactions
ABAP proxy: ECC function that connects with PI directly
Custom ABAP program: custom business program for processing files and posting data to ECC transactions/functions/IDOCs

SAP outbound integration techniques:

IDOC: standard or custom metadata structure for processing standard transactions
BAPI / RFC: standard or custom business program for processing standard transactions
ABAP proxy: ECC function that connects with PI directly
Custom ABAP program: custom business program for processing files and posting data to ECC transactions/functions/IDOCs
Mapping and routing techniques

Mapping and routing performed in middleware PI:

Few examples of Legacy/Middleware integration techniques (inbound and outbound)

Flat File – fixed length and file delimited
JMS/XML – XML with schema definition
Database – SQL executed from JDBC connection
Webservices – HTTP/SOAP requests

Component Versions and Namespaces:

• Define a separate software component for each component involved
• Define a separate software component for the mappings
• Do not enhance SAP delivered objects in it’s original namespace

Mapping Types :

Mapping messages from one format/structure to another is a fundamental feature for any middleware application in A2A and B2B scenarios.

SAP NetWeaver Process Integration offers a wide variety of mapping program types:

• Message Mapping (Graphical Mapping Tool)
• Java Mapping
• XSLT Mapping (Java Engine)
• ABAP Mapping
• XSLT Mapping (ABAP Engine)

Data Lookup:

• Value Mapping
  • Integration Directory UI: Allows for direct manual input using the user interface of the Integration Directory
  • Value Mapping Replication for Mass Data: If the value mapping data is stored in external tables, this data can be replicated to the runtime cache (on the Integration Server) by using special service interfaces
  • Integration Directory API: web services containing all the necessary operations to create and edit configuration objects
• Mapping Lookups
  • By using a mapping lookup, mapping programs can call functions from other application systems while a mapping program on the Integration Server is being executed e.g. To read from application system data in the mapping program
  • The mapping runtime has a lookup API for calls to application systems. It supports access using the RFC, JDBC, and SOAP adapters

The following data criteria should be taken into account when defining the data lookup strategy:

 Amount of Data: Is there a small or large amount of data to maintain?
 Frequency of Change: Is the data static or dynamic?
 Location of Data: Is the data externally maintained?
 Input / Output Value Ratio: Is the input/output value ratio 1/1?
 Availability of Value Mapping Function: Does the value mapping function already exist in the backend or can it be easily implemented?
 Backend Application Type: Is the backend an SAP System, a DB, an Application that can provide Web Services?

Data Lookup should be used in the following cases:

 Dataset is large, dynamic and externally maintained
 Input / Output Value Ratio is n/n.
 A Value Mapping function is available in the back end or can easily be implemented
 Backend is an SAP system (RFC), database system (JDBC) or web service provider (SOAP)

Collection of Messages :

• Try to avoid using ccBPM to collect messages from one system for Mass processing
• Try to avoid ccBPM Collect Pattern for high volume interfaces

                                                                                       

Split of Messages :

• Try to avoid ccBPM, but use IS pipeline & AE functions for mapping based message split & interface determination.

Synchronous versus Asynchronous Scenarios :

• With asynchronous messages (EO or EOIO) processing, the messages can be sent to IS even if the receiving system is down and PI will take care of the EO/EOIO processing
• With asynchronous mode one message can be sent to multiple receivers
• Due to additional persistence layers more system resources are requiredthan comparable synchronous interfaces
• With async messages you can control parallel processing
• Integration Engine (queues)

Note: EO stands for Exactly Once, while EOIO stands for Exactly Once in Order

Serialization:

Try to avoid EOIO for mass data interfaces.

Performance Tuning :

The tuning of PI can lead to :

• A decrease of the overall message processing time or/and
• An increase of the message throughput, i.e. the number of messages processed within a specific time frame

• Use reasonable message sizes to improve performance, to avoid memory overflows and to increase overall system stability.
• At design time, consider that the message throughput is much higher for larger messages due to the necessary processing overhead for a single message. On the other side, the memory consumption is higher for processing larger messages.
• The best practice is to keep the average message size in the range of 1 MB to 5 MB.

Message Packing :

By processing multiple messages in packages instead of individually, the overall overhead can be reduced leading to less hardware resources consumption and an increased message throughput:

• The respective programs required for message processing are only loaded once into main memory for each package
• Multiple messages are processed in one dialog work process
• Only one DB commit is carried out for the complete package
• Only one logon is required when switching from ABAP stack to Java stack or vice versa

Use message Packaging in the Integration Server in the following cases:

• Small asynchronous messages
• Best results when using proxies
• Leads to throughput improvements

Serialization :

Serialization is a technique that is used to ensure that the interface records are processed in the target system, in the same order that they were generated in the

source system. Interface records can get processed in a different order due to:

• network or system delays
• parallel processing
• intermittent errors etc.

Based on update made to the business object and content, the appropriate serialization technique should be used:

Error handling:

Vital error information should be captured for effective error reporting. Effective error reporting can help project management to focus on priorities and support team

to resolve the errors faster.

• Errors should be reported with all message data (class, number, text, parameters) and important record data like key, organization, amounts etc. Several reporting techniques can be used:
• Monitoring: interface log (across the technology landscape) providing traceability into the relevant functional and technical details of each interface
• Notification: notifications to specific resources are triggered based on defined attributes of interfaces providing interface details
  • Interface errors should be categorized based on point of break

• The right course of resolution should be determined by category