zagandesign - Fotolia
What is the best way to upgrade to SAP Process Orchestration?
Upgrading from SAP Process Integration to SAP Process Orchestration is possible, but learn why many companies are opting for a side-by-side migration from PI to PO and some of the steps involved.
CIOs planning to migrate their existing interfaces build using SAP Process Integration to SAP Process Orchestration...
Continue Reading This Article
Enjoy this article as well as all of our content, including E-Guides, news, tips and more.
need to first carefully evaluate their existing SAP infrastructure to decide whether an in-place PI-to-PO migration is more effective in meeting the company's business rules and needs or whether a side-by-side PI-to-PO migration would be a better choice.
An in-place SAP Process Integration to SAP Process Orchestration upgrade will require upgrading the existing PI interface to Netweaver 7.31 in the same SAP system in which PO is installed. It also entails converting the existing Advanced Business Application Programming (ABAP) language-based Integration Directory to its Java equivalent, either manually or using the migration tool provided by SAP.
A side-by-side PI dual-stack (ABAP and Java stacks) to PO (single, Java-only stack) interfaces migration requires leaving the source PI infrastructure intact, while focusing all efforts to successfully migrate the source PI system's interfaces to target the PO system.
Going the side-by-side SAP Process Integration-to-SAP Process Orchestration option is finding far greater adoption by companies as this option significantly reduces the PI-to-PO migration downtime, thereby ensuring minimal workflow disruption. Since the new PO system is configured separately and independently from the existing PI system, the only downtime is when migrating all current PI interfaces' data from the newly created PO system and switching off the PI system.
Here are three sequential objects to focus on during the interfaces migration from SAP Process Integration to SAP Process Orchestration using the side-by-side migration approach.
1. Migrating SLD content
An export from the source system and then an import into the target system are undertaken. While it is certainly possible to automatically export all System Landscape Directory (SLD) objects from the source system to the target system using the migration tool provided by SAP, it's far better to do it manually and only choose the objects needed in the target system. Doing so ensures the new SAP Process Orchestration system isn't loaded with unused or unnecessary objects. Due to their dependencies on each other, the logical export sequence from PI to PO of SLD objects is products, software components, technical systems and, finally, the business systems that are then subsequently imported into the target PO system.
2. Migrating ESR content
Contrary to the migration approach adopted in the previous step, here, it's highly advisable to export all Enterprise Services Repository (ESR) content, such as software components, into the target SAP Process Orchestration system. Doing so avoids a mismatch among various object dependencies and the ensuing object inconsistencies errors encountered. Once all objects are successfully migrated into the new PO system, it is possible to delete the objects that are not needed.
3. Migrating Integration Directory content
On successful completion of the first two migration steps, which are also the required prerequisites for SAP Process Orchestration migration, the last step is migrating Integration Directory content that contains configuration objects. Since PO is based on a single-stack, Java-only framework, integrated configuration objects and integration flows are supported as the configuration objects. The options to manually migrate or use the migration tool offered by SAP are both available. The tool is available in SAP NetWeaver Process Integration 7.30 SP9, SAP Process Orchestration 7.31 SP7 and newer versions.
Note that all new SAP HANA implementations are going to leverage SAP Process Orchestration as the de facto technofunctional integration infrastructure.
