SAP NetWeaver Process Integration (SAP NetWeaver PI) is a key component of SAP’s service-oriented architecture (SOA) infrastructure that companies use to integrate SAP and non-SAP systems. Scenarios include service enabling of legacy applications as well as application-to-application (A2A) and business-to-business (B2B) communication.

SAP NetWeaver PI 7.1 is the latest release and provides major benefits in many important areas. They include superior governance with Enterprise Services Repository (ES Repository) and the Services Registry; enhanced developer productivity; much faster installation (less than three hours); and reduced sizing.

We will focus on the performance improvements. We will first take a general look at the SAP NetWeaver PI architecture before moving on to middleware performance. Then we will narrow down the focus to three areas that deserve a closer look with SAP NetWeaver PI 7.1:

• The message packaging concept
• Direct connection
• Local processing on the Advanced Adapter Engine (AAE)

Out of these three, we will closely examine the AAE functionality by describing a business example that service enables a legacy supplier application using the AAE. Tests of the new SAP NetWeaver PI functionality have shown that local processing with the AAE can increase performance by up to factor 10, depending on your scenario. Message packaging can boost performance up to 300% in the best case. AAE local processing can boost performance up to 1000%.

We assume that you are familiar with SAP NetWeaver PI and SOA. In particular, a basic knowledge of SAP NetWeaver PI’s configuration and runtime will help you understand the main performance benefits delivered with the 7.1 release. It would also be helpful to be familiar with standard communication protocols such as SOAP and JDBC.

SAP NetWeaver PI 7.1 Architecture Components

Before we go into the details of performance aspects in SAP NetWeaver PI, it is helpful to understand the key architectural components of SAP NetWeaver PI 7.1. This short overview should also help you to better contextualize the performance improvement business example that we outline later in this article.

Figure 1 provides a view of the basic architecture components. ES Repository is the design environment. It allows you to model services and design all SOA artifacts, such as interface descriptions and mappings.

Figure 1

Basic architecture components of SAP NetWeaver PI

The Integration Directory is used at configuration time. With it you can configure the design objects you created in ES Repository for use in a specific system landscape. You configure the routing rules as well as the communication channels required for the message exchange with the connected systems. The configuration data is structured, organized, and saved in the Integration Directory in the form of configuration objects. The decision to either use the Integration Server or the AAE to process your message is realized via configuration in the Integration Directory.

The SAP NetWeaver System Landscape Directory (SLD) serves as a central information repository for your system landscape. A system landscape consists of a number of hardware and software components that depend on each other with regard to installation and software updates. The SLD ensures that you have a comprehensive overview of your landscape.

The Integration Server is the central runtime component of SAP NetWeaver PI, which enables applications to exchange messages with each other. The Integration Server forwards the messages from a sender to the receiver. By separating the communication parties and using additional integration services (mapping, routing, and service orchestration), the Integration Server can support the integration of most applications. SAP NetWeaver PI 7.1 has a new option for message processing, the AAE, which plays an important role for the performance. Before we discuss the details of the AAE, let’s take a look at key performance aspects in SAP NetWeaver PI.

Key Performance Aspects

Performance in the context of middleware consists of mainly two aspects, one being optimal processing speed and the other being maximum message throughput in a given time frame. Typically, synchronous scenarios focus more on the first aspect, which leads to a decrease in the elapsed time for a complete request/response cycle. An example for this is a query type message, which you use to retrieve information such as descriptions, listings, or other object-related information.

In asynchronous scenarios, the aim is to increment the volume of information processed in a determined period of time. A typical way to achieve throughput increase is by increasing the number of parallel tasks in execution, whereas you can increase message processing speed by reducing latency times. Both aspects can be interdependent.

A variety of factors can influence these performance aspects, including:

• SAP NetWeaver Application Server (OS, DB, ABAP, and Java Stack Basis Components)
• Related back-end systems
• Network infrastructure and topology (firewalls)
• Integration design
• System and environment configuration
• Configuration options with SAP NetWeaver PI

Note that performance is only one of many important aspects that you need to take into consideration when designing your SAP NetWeaver PI integration scenarios. In some cases, such as B2B communication, performance is likely to be a lower priority than, for example, message reliability. In contrast, scenarios that integrate applications (A2A communication) are often required to be both fast and reliable.

Finally, in synchronous human interaction scenarios, reaching a real-time message speed would be considered a natural requirement. Consequently, depending on the use case, performance expectations could range from a nice-to-have to a no-go situation, and thus should be thought about right from the beginning of your implementation.

Main Areas of Performance Improvement

Using SAP NetWeaver PI 7.1, organizations can process more than one million messages per day with single message sizes of more than 100 MB. Three options for performance improvement are message packaging, direct connection, and local processing using the AAE.

Message Packaging

To better understand the benefits of message packaging, it is helpful to understand how SAP NetWeaver PI traditionally processes messages. Normally, a message arrives to SAP NetWeaver PI and is then persisted in a message queue. Then the message starts the first pipeline process, is stored in the message queue again, starts the second pipeline process, and so on. This process is repeated for each pipeline step until the message is finally delivered to the proper receiver.

The aspect that is of central importance here is that every single message is treated in isolation. This means that every time the message is persisted in the message queue, it also has to be committed at the database level. Repeating these steps again and again for every single message can result in considerable overhead.

Message packaging improves this process. The system receives several messages in the message queue. When the scheduler starts to process a message, it first checks if there are any additional messages that should be processed as well. If so, they are grouped and processed together in the same package. After the pipeline process is executed for all of them, they are updated and committed to the database as a whole. The same procedure takes place for the additional pipeline steps, with the scheduler always checking what is available in the queue before starting to process a single message.

Compared to the previous message processing technique, this is more effective because both the context switch operations and database accesses are drastically reduced by grouping messages into packages.

Direct Connection

Direct connection is a middleware-centric concept to describe connections that are designed and configured using the SAP NetWeaver PI tools ES Repository and Integration Directory. At runtime, the messages skip SAP NetWeaver PI — the message processing takes place directly between the sender and receiver. The configuration in the Integration Directory is propagated to the back-end systems automatically.

This option is a good choice whenever these prerequisites are given:

• No mapping required
• Static routing is sufficient
• Only one message receiver

The two ways of improving performance that have been mentioned so far rely on changing the message processing configuration. The third option, local processing using the AAE, is based on an architectural change in SAP NetWeaver PI 7.1.

Local Processing Using the AAE

The AAE is a further development of the Adapter Engine from previous SAP NetWeaver PI releases. In SAP NetWeaver PI 7.1, the AAE provides not only pure connectivity options, but also mapping and routing capabilities. The AAE is based on the Java EE 5 Application Server and hosts the Adapter Framework, on top of which the Java-based adapters run. The adapters have basically two tasks:

• Convert the specific protocols of the connected systems to and from the HTTP-based XI message protocol
• Convert the data format required by the connected systems to and from XML

In principle, this is similar to how the message processing worked in SAP NetWeaver PI 7.0 or SAP NetWeaver Exchange Infrastructure (SAP NetWeaver XI) 3.0. However, in SAP NetWeaver PI 7.1, the integrated capabilities of mapping and routing allow pure Java-based processing of messages on the AAE. The message processing is only executed on the AEE from the sender adapter to the receiver adapter, without the involvement of the Integration Engine. Message processing on the AAE leads to significant benefits:

• It increases message processing (i.e., higher speed of a factor of up to 10, depending on scenario)
• Less latency and increased throughput
• Reduced resource consumption

You can use the message processing on the AAE for synchronous and asynchronous scenarios. Furthermore, you can install the AAE on non-central instances as well.

Note that you can only use the message processing on the AAE for scenarios that don’t require the SAP NetWeaver PI 7.1 functionality that is implemented in ABAP, such as integration processes (cross-component Business Process Management [ccBPM]) or ABAP-based adapters, which are currently HTTP, IDoc, and WS-RM.

Besides the performance enhancements at runtime, the AAE also provides major improvements in the area of configuration and a lower cost of development to design the message flow (routing). More details are described below in the example scenario about using the AAE.

Figure 2 shows the new architectural concept in SAP NetWeaver Process Integration 7.1, in which message processing is possible for certain scenarios on the AAE only. For these scenarios, the messages are not routed through the Integration Server. The components in Figure 2 are:

• SAP: An arbitrary SAP system, such as SAP ERP or SAP CRM
• Third-party application: An arbitrary non-SAP system, such as a database or a Web service client
• IS (Integration Server): Central runtime environment of SAP NetWeaver Process Integration. Its main components are the Integration Engine, ccBPM Engine, and the AAE.
• Integration Engine: Takes care of mapping and routing for scenarios that are processed by the Integration Server
• ccBPM Engine: Responsible for orchestrating complex message flows across multiple back-end applications

Figure 2

Basic architecture around the AAE

A Closer Look: Example Scenario Using the AAE

We will use a Web sales example scenario to highlight the use of the AAE. In this example, we have an SAP ERP system in which purchase orders are created. The supplier system in which the corresponding sales order should be created is a database application. Because we want to implement and publish the functionality for creating sales orders as a Web service, this requires the capabilities of SAP NetWeaver PI 7.1 for service-enabling legacy applications. High-speed processing, throughput, and availability are considered crucial preconditions for this Web sales scenario.

Figure 3 shows all the steps required to implement this scenario, in which we process messages on the AAE only. We’ll focus on the configure integration step because you decide whether to use the AAE or the Integration Server during this phase.

Figure 3

The required development steps for the example business scenario

Using the AAE means an immense simplification in terms of configuration — you need to deal with only one configuration object instead of the previously required four objects: the sender and receiver agreements and the receiver and interface determinations. Now in SAP NetWeaver PI 7.1, you only need to configure the integrated configuration object. Of course, you still need to configure the communication components and channels as well.

Figure 4 shows an example of the current integrated configuration object procedure between an SAP ERP application and a third-party supplier system. You use the integrated configuration object to define the message flow through the AAE. The entire configuration is carried out in the Integration Directory, which you access via the tools start page of SAP NetWeaver PI. Enter the details about the sender and receiver systems in the top section of the screen. The sender and receiver communication components have to be previously defined in the Integration Directory. In B2B scenarios, communication parties are typically used as identifiers for the external communication with business partners. Finally, you need to provide the (outbound) interface name and the namespace of the sender system as designed previously in ES Repository.

Figure 4

The integrated configuration object that defines the message flow between sender and receiver applications

In the bottom half of Figure 4, you only need to provide parameters for the three first tabs. In the Inbound Processing tab, you define the communication channel, including the adapter type for the sender system and whether the system should processes messages via the central AAE or a non-central AAE. In this tab, you also specify whether you would like to use XML payload validation to validate the payload against an XML schema at runtime and principal propagation to dynamically route principles from the sender to the receiver system based on certificates such as Security Assertion Markup Language (SAML).

In the Receiver Interfaces tab in Figure 5, you provide details about the receiving system (party and communication component) as previously defined in the Integration Directory. You also enter the name of the operation mapping that should be used at runtime to map the source and target messages. The mapping must be created earlier in the ES Repository.

Figure 5

The Receiver Interfaces tab for the integrated configuration object

In the Outbound Processing tab in Figure 6, you only need to specify the communication channel, including the adapter type for the receiver system. The communication channels define the adapter types as well as the settings of adapter-type-specific attributes that are required for communication with the connected back-end systems. The communication channels must be created ahead of time in the Integration Directory.

Figure 6

The Outbound Processing tab for the integrated configuration object

Supported Adapters for the AAE

Currently, the following adapters are supported for the message processing on the AAE:

• Technical connectivity for communication with SAP and non-SAP systems
• File systems/FTP servers
• Java Database Connectivity (JDBC) (relational database management systems)
• Java Message Service (JMS) (messaging systems such as MQSeries and SonicMQ)
• SOAP (Web Services based on SOAP)
• Mail (mail servers via SMTP, IMAP4, POP3)
• SAP Business Connector (SAP BC)
• SAP Service Marketplace
• Application connectivity
• Remote Function Call (RFC)
• XI 3.0 message protocol (with SAP enhancement package 1 for SAP NetWeaver PI 7.1)

The industry-speak adapters RNIF 2.0, RNIF 1.1, and CIDX are typically used in the context of mappings to and from IDocs and often used with integration processes, which are not yet supported on the AAE.

Additional Current and Planned Performance Enhancements

Because performance improvements through message processing are one of the key benefits of SAP NetWeaver PI 7.1, SAP plans further updates to provide more enhancements for the AAE. Some of these planned enhancements, particularly for the AAE, are already available with SAP enhancement package 1 for SAP NetWeaver PI 7.1:

• Enhanced flexibility for the integration developer in defining mediation flows
  • Content-based routing in the AAE
  • Receiver split in the AAE

• Automated A2A/B2B configuration support
  • Configuration based on process component interaction models

• Leverage performance enhancements via additional connectivity options
  • XI 3.0 message protocol supported via SOAP adapter in the AAE
  • End-to-end IDoc packaging
  • IDoc conversion adapter module

With the next release of SAP NetWeaver PI, the following enhancements are planned for the AAE:

• Higher performance using the AAE
  • IDoc and HTTP adapter in the AAE
  • Message split on the AAE
  • XI message packaging on the AAE

• Increased interoperability
  • Publish and subscribe scenarios via JMS topics in order to conveniently send or receive messages for previously defined subjects (topics)

• Enhanced developer productivity
  • Usability for XML payload validation to use schemas out of the ES Repository at runtime for validation

• Resource optimizations
  • Large (binary) file-to-file transfer
  • JDBC message size limits
  • Time-out configuration per communication channel

• Deeper insight into SOA landscapes
  • Further message persistence at various pipeline steps on the AAE

Dr. Susanne Rothaug

Dr. Susanne Rothaug has been with SAP since 2001, working in various areas of SAP NetWeaver product management. Currently, she is a solution manager for SAP NetWeaver foundation topics. 

You may contact the author at susanne.rothaug@sap.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.

Udo Paltzer

Dr. Udo Paltzer has worked as a product manager on integration topics at SAP for 14 years. Udo has detailed knowledge about SAP’s on premise integration platform and SAP Process Integration. During the last three years Udo focused on SAP’s Integration as a Service (IPaaS) offering – SAP HANA Cloud Integration (SAP HCI). As product manager Udo loves working together with customers and is committed to helping SAP customers succeed in their integration journey. One of the key tasks for Udo as product manager is to conduct presentations and workshops with deep dive hands-on sessions in order to train and educate customers on the key scenarios, capabilities, and benefits of an open source-based integration platform. Udo gives presentations and product trainings regularly on individual basis as well as at global SAP events around the globe.

 

You may contact the author at udo.paltzer@sap.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.