There are basically two different motivations that normally bring out the performance topic in a customer installation. One is the need to increase processing speed of messages, especially regarding synchronous scenarios.
Of special interest is, for example, the processing speed of queries, used to retrieve information like descriptions, listings or other object-related information. Another demand may be an increase in throughput of messages, which means an increase of the data volume processed over a fixed period of time.
This does not necessarily also mean an increase in absolute message processing speed, but in a high load situation a more stable system behavior also increases the overall message processing speed.
On the other hand, while increasing message processing speed by reduction of latency times is likely to benefit the overall throughput of messages, but this cannot always be achieved in an easy way.
2008 © 2008 SAP AG. All rights reserved.
109
The most typical way to achieve throughput increase is by increasing the number of parallel tasks in execution. This is not always the case, but a fairly common solution.
Throughput is normally more frequently linked to asynchronous processing, whereas an increase of message processing speed is more often an approach used in synchronous scenarios.
Put in general terms, the way to achieve an improvement in message processing speed increase usually differs from the way to achieve an increase in volume throughput.
Performance requirements viewed from a different angle addresses another important issue. That is to consider performance as one topic within the requirements you have to meet for the integration scenarios.
In B2B scenarios, performance topics are prioritized lower in comparison to, for example, the reliability of the message exchange.
In contrast, scenarios of Application Integration (A2A) are often required to be both fast and reliable at the same time.
For synchronous human interaction scenarios (H2A) guaranteed low latency times may be obligatory and not reaching a particular service level could leave the scenario being not usable.
Regarding the particular use case, a particular performance topic could range from a nice-to-have type of requirement up to being absolutely critical for the scenario. Therefore, performance topics should be considered from the beginning of the implementation.
Here are some examples of performance requirements to be met, depending on the use case:
B2B: Exchange of documents with Business Partner has to be more reliable and secure than fast.
A2A: Application Integration has to be fast and reliable.
H2A: User expects near to real-time or synchronous communication.
There are several considerations regarding performance requirements.
Most important is a proper integration design. This is a generic concern regarding integration scenarios. SAP NetWeaver PI represents the middleware system at the center of the integration scenario which has to be analyzed as a whole. A methodology should be used considering all the required steps and roles to minimize possible design errors. For more Information, refer to the following blog:
"Important documentation for your process integration projects" at https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/wlg/5356.
Another important thing that needs to be considered is the environment that SAP NetWeaver Process Integration communicates with. Not only the database, operating system, and network connections must be set up and working correctly, any connected middleware or back-end system, receiving or sending data has to comply with the required performance, stability, QoS, and service level agreement. During and after design time, you should be aware of SAP NetWeaver PI features to fully exploit your design, configuration, and monitoring options.
Figure 80: Performance Improvement Options in General
The methods to optimize high volume support can be split into three different groups. Namely they are divided intp
• General SAP NetWeaver PI methods
• ccBPM specific enhancements and
• Adapter Specific enhancements.
2008 © 2008 SAP AG. All rights reserved.
111
The first group includes "General SAP NetWeaver PI methods”:
• Message Packaging: This is a throughput-increasing mechanism based on a message processing in groups inside each pipeline step. This provides for the benefits of loaded ABAP program re-execution and massive database access.
• Message Prioritization: Some interfaces are more important than others, depending on the immediate business need. If you have a very critical interface you would like to ensure that this interface is prioritized over other interfaces in the processing on the Adapter Engine as well as on the Integration Server side.
• Advanced Adapter Engine: The adapter engine supports integration engine capabilities like routing and mapping locally, resulting in a simplified architecture and message handling.
• Delayed Message Processing: Depending on your business needs, you might want to collect noncritical messages in the Integration Server and schedule the message processing into time intervals of general low message processing on your PI system.
• Large Message Handling: On the Integration Server large messages could be processed by separated large message queues, so that on one hand the parallel processing of large messages is reduced and that these queues do not interfere with smaller messages.
• Direct calls (formerly named “P2P connections”): This configuration allows back-end systems to contact each other directly bypassing the SAP NW PI middleware system. The benefits of this method are both an increase in messaging speed and throughput, due to the fact that a direct connection does not spend processing time on message mediation.
The second group addresses ccBPM-specific enhancements.
• Packaging: Message Packages can be transferred to the BPE, extending the message packaging features to the area of Integration Processes.
• Parallel Processing: This feature allows specific Integration Processes to be executed with the Quality of Service EO, instead of EOIO and is thus able to process them in parallel.
• Enhanced Transaction Handling: Allows design time optimization of transaction handling, spanning one transaction over several Integration Process steps instead of having to use one transaction per process step.
The third group relates to Adapter-specific enhancements.
• IDOC Adapter – Packaging and IDoc tunneling: The IDoc packaging functionality allows several IDocs to be handled together on the outbound side. This functionality has been replaced by message packaging, which basically uses the same principle. No XML transformation (or IDoc tunneling) allows IDocs to be kept in original format whenever there is no advantage expected from translating them to the internal PI message format.
• File Adapter: File Splitting makes use of a content conversion utility that allows you to split one file into several PI messages based on the specific configuration.
• Maximum Concurrency for File and JDBC Receiver Adapter: This method is mostly use to reduce parallel processing for slow performing back-end systems, keeping adapter-specific threads on the Adapter Engine free
• RFC Adapter: Parallel connections are possible for RFC Sender and RFC Receiver channels. Depending on the parallel message processing needs and the capacities on the back-end multiple parallel connections can be configured here.
An overall correct system configuration is an important prerequisite before any optimization option mentioned above will bring any benefit to message performance.
In order not to go beyond the scope of this course, only the (new) features of Message Packaging, ccBPM Packaging, Message Prioritization and local processing on the Advanced Adapter Engine, Maximum Concurrency for File/JDBC Adapter, and Direct Connections will be covered in the following sections.