Have you ever wondered what are the major differences between SAP eXchange Infrastructure (XI), Process Integration (PI) and Process Orchestration (PO)? In this article we would like to take a closer look at components which belong to each version. In addition, we will show new components available in SAP PO and what components shall be considered as obsolete in XI/PI versions due to the fact that they can not be used in accordance with java only PO architecture.
As shown in the diagram below, SAP eXchange Infrastructure with ABAP ana Java stacks was released in 2002. Afterwards, SAP Process Integration (PI) was introduced by SAP, however, PI with single stack option was introduced in 2010. After a few versions of PI, SAP Process Orchestration (PO) with v. 7.31 was launched in 2011.
In order to understand the differences between architecture of these versions, let’s have a look at major architecture changes:
SAP XI Architecture Overview
Integration server, the key component of the SAP XI consists of following three engines: Adapter Engine, Integration Engine and Business Process Engine – it was installed on a ABAP and Java stacks.
Adapter Engine (AE) – as the name already suggests, the main role of this component is to provide connection possibilities between different communication protocols and adapters.
Integration Engine (IE) – the main purpose is to provide a runtime to the message communication. This component is responsible for routing and mapping.
Business Process Engine (BPE) – this engine deals with the processing of messages in ccBPM (Cross Component Business Process Management) workflows and requires dual stack installation.
SAP Process Integration (PI) Architecture Overview
Advance Adapter Engine (AAE) – using Integrated Configuration (ICO), it’s possible to define a local message processing on the Advanced Adapter Engine. The Advanced Adapter Engine provides mapping and routing for this locally. Message processing is only executed on the Advanced Adapter Engine from one adapter to another without Integration Engine (IE) runtime. Dual stack message persistence is eliminated since ICO scenarios are executed independently, because technically only the AS Java is involved.
Although AAE facilitates the performance in comparison with XI, it should be remembered that AAE still requires Integration Engine (IE) runtime for development and administrative tasks. Moreover, older versions of Advance Adapter Engine do not include iDoc and HTTP adapters since they belong to ABAP stack. Taking above mentioned facts into consideration, SAP could not have decoupled the Integration Engine (IE).
SAP Process Integration (PI) with AEX Architecture Overview
Advanced Adapter Engine Extended (AEX) – SAP Process Integration excludes the need of Integration Engine (IE) and SAPI PI 7.3 version provides Advanced Adapter Engine Extended which is a single engine that includes Enterprise Service Bus (ESB), Integration Directory (ID) and AAE capabilities. From now on, Process Integration is an AS Java only installation and SAP decouples ABAP stack. It is important to know that PI 7.3 provides iDoc AAE and HTTP AAE adapters that run on Java stack. SAP PI got rid of ABAP stack and it is considered as an essential change when it comes to SAP PI architecture.
SAP Process Orchestration (PO) Architecture Overview
NetWeaver Business Process Management (NW BPM) – there are a few minor differences between NW BPM and ccBPM. SAP NetWeaver Business Process Management is a component which is executable on java-based environment and uses Business Process Model Notation (BPMN) while ccBPM runs on dual stack and uses Business Process Execution Language (BPEL).
The minor changes between these two are shown in the table below:
| Area | ccBPM | NW BPM |
| Installation | dual stack | can be installed as java only |
| Installation time | multiple days | multiple hours |
| Performance | worse | better |
| Dev objects | Abstract interfaces required | Standard interfaces can be used |
| Adapters | XI protocol is used in order to communicate between IE and ccBPM | SOAP adapter with XI protocol is used to communicate between IE (AEX) and NW BPM |
| Dev environment | Enterprise Service Builder (ESR) | NetWeaver developer studio (NWDS) |
| Dev environment | Does not have support for debugging | Provides support for process debugging |
| Repository | Enterprise Service Builder (ESR) | With NWDI, process can be stored in DTR. Without NWDI, a separate server based location need to be used |
| Build | Build of the ccBPM is not required. | A separate build of the NW BPM process is necessary |
| Transport | File or CTS+ | NWDI with CTS+, CMS or manual methods |
| Deployment | ccBPM process is available in run-time upon activation of the process | Process must be built and deployed to the run-time. |
| Run-time engine | Business Process engine(BPE) is used to execute the process | Process server is used to execute the process |
| Run-time environment | Web AS ABAP | Web AS Java |
| Process as a Web Service | ccBPM is not available as a webs ervice | NW BPM Process is available as a web service upon deployment. Any client capable of making a web service call can directly invoke the process. |
| Process API | No API’s are available | API’s are available to handle processes remotely |
| Process start | The process can only be started by a message | The process can be started manually in process repository or by a message |
| Monitoring tools | SXMB_MONI_BPE, PIMON | Process Manager, Task Manager |
| Quality of service support | ccBPM supports BE, EO and EOIO | NW BPM supports BE and EO |
| Acknowledgement support | ccBPM supports acknowledgement handling | NW BPM does not support acknowledgement handling |
| Attachment support | ccBPM supports message attachment handling | NW BPM does not support message attachments |
Business Rule Management (BRM) – contains modeling capabilities which may be used by business analysts.
SAP PI/PO migration – risk or opportunity?
SAP Process Integration is commonly used as SAP middleware platform, needless to say. When it comes to PI which runs on Java and ABAP stack, it should be clearly stated once and for all that dual stack installation will no longer be supported at the end of 2020. The one thing that is certain is that in the near future, there will be a need to carry out SAP PI renewal projects.
Taking into account SAP PI migration projects, it should be remembered that migration from dual to single stack is not only about copying and moving objects from one environment to another. With regard to the above mentioned SAP PI architectures, it can be concluded that there are a lot of steps that must be taken due to differences between SAP XI/PI/PO versions.
During this kind of project, there are plenty of activities that must be carried out so that all existing interfaces could work properly. We need to keep in mind that it’s always risky undertaking. Below is the list of activities that may have a significant impact on processes and various integration scenarios.
Connectivity
Communication channels – all ABAP adapter must be replaced with JAVA adapters
- HTTP -> HTTP_AAE
- IDoc -> IDocAAE
- XI -> SOAP (XI 3.0)
- WS -> WS_AAE
Mappings
In case of ABAP/ABAP-XSLT mapping is used, there is a need to convert it into JAVA-based mapping as ABAP mappings will not be longer supported in a single stack.
Routing
Standard routing must be replaced with Integrated Configuration (ICO) using appropriate communication channels.
Multi-Adapter Engine Usage
iFlows and Folders are kept in NetWeaver Developer Studio (NWDS Eclipse).
BPM
There is a need to redesign existing ccBPMs by BPM processes. Differences are listed in the table which is located in place where NetWeaver Business Process Management was explained in more descriptive way.
Monitoring
All messages are visible in PIMON, there is no SXMB_MONI.
Backend Systems
It is necessary to create new IDoc port in order to connect with adapter IDoc_AAE via RFC Destination type T.
In case of proxy interfaces, there is no need to indicate to Integration Engine, we need to point to Adapter Engine RFC Destination instead.
Opportunities …
Although, migration from dual stack SAP PI to a single stack SAP PI/PO is a highly demanding task, at the same time, we cannot fail to mention the crucial reasons to migrate from PI or other middleware to PO.
Below, there are a few reasons why it is worth to make this upgrade. For that moment SAP PO offers following features:
Support with HANA
It’s possible to run PO middleware on HANA (PI dual stack will not be released for HANA, as for 7.5 version, there is a need to split the ABAP and Java Application servers)
Use of Netweaver Developer Studio and iFlows
iFlows used in the PO system use artefacts that can also be used in the HANA Cloud Integration product
Availability of NW BPM
It facilitates man-machine flows using SAP Fiori which supports different devices
B2B Add-on
It’s not required to have an additional EDI format converting software.
B2B Add-on supports hundreds of EDI formats and their versions. This is to avoid costs related to licences and people with skills to support chosen EDI software either in house or external.
Flexibility and better performance optimization
The move to Java only architecture means we get a massive boost in the performance throughputSimplification in maintenance operations
Centralized monitoring tools
There is no need to use ABAP-based transactions SXI_MONITOR, SM58, SMQ2 etc.
Simplified IT Landscape
It is simpler to manage while it runs on java-stack only
SAP does not support and develop PI dual-stack anymore
Taking above mentioned into account, we can come to a common conclusion that PI/PO migration is a perfect opportunity to make an improvement so that system can be more resilient, reliable and secure.
Although Process Integration is not a burning middleware (rather more smouldering), those who use it, will be locked out as for new features.
