19.05.2020

SAP XI/PI dual stack to SAP PI/PO single stack migration

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:

AreaccBPMNW BPM
Installationdual stackcan be installed as java only
Installation timemultiple daysmultiple hours
Performanceworsebetter
Dev objectsAbstract interfaces requiredStandard interfaces can be used
AdaptersXI protocol is used in order to communicate between IE and ccBPMSOAP adapter with XI protocol is used to communicate between IE (AEX) and NW BPM
Dev environmentEnterprise Service Builder (ESR)NetWeaver developer studio (NWDS)
Dev environmentDoes not have support for debuggingProvides support for process debugging
RepositoryEnterprise Service Builder (ESR)With NWDI, process can be stored in DTR. Without NWDI, a separate server based location need to be used
BuildBuild of the ccBPM is not required.A separate build of the NW BPM process is necessary
TransportFile or CTS+NWDI with CTS+, CMS or manual methods
DeploymentccBPM process is available in run-time upon activation of the processProcess must be built and deployed to the run-time.
Run-time engineBusiness Process engine(BPE) is used to execute the processProcess server is used to execute the process
Run-time environmentWeb AS ABAPWeb AS Java
Process as a Web ServiceccBPM is not available as a webs erviceNW 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 APINo API’s are availableAPI’s are available to handle processes remotely
Process startThe process can only be started by a messageThe process can be started manually in process repository or by a message
Monitoring toolsSXMB_MONI_BPE, PIMONProcess Manager, Task Manager
Quality of service supportccBPM supports BE, EO and EOIONW BPM supports BE and EO
Acknowledgement supportccBPM supports acknowledgement handlingNW BPM does not support acknowledgement handling
Attachment supportccBPM supports message attachment handlingNW 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

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.

Share
Contact Person

Blog writer

Wiktoria Kałka

Integration Consultant

 

You have Successfully Subscribed!