8    Migrating Interfaces from SAP PI Dual Stack to SAP PO

True genius resides in the capacity for evaluation of uncertain, hazardous, and conflicting information.
                                                                                             —Winston Churchill

After reading the previous chapters, you now know many reasons to choose SAP Process Orchestration (SAP PO) as the ultimate enterprise service bus (ESB) for all your SAP-related integrations. If you’re currently using the dual stack of SAP Process Integration (SAP PI), then you’ve also been provided with reasons to migrate to SAP PO.

At this point in the book, you’ve built up the necessary knowledge to create interfaces and all the related supporting objects from scratch. So far, it has been assumed that you have to build brand-new interfaces in SAP PO, but this is obviously not always the case. You might face a situation in which your interfaces have already been built in an SAP PI dual stack, and the need arises to migrate to an SAP PO installation (or a Java-only stack). Understanding the challenges and steps involved in a migration from an older version of SAP PI (dual stack) to SAP PO is the main purpose of this chapter.

Note that the chapter won’t focus on how to upgrade or install an SAP PO system. Instead, it will explore the different aspects of migrating the actual interfaces and content. We’ll begin by discussing the various migration strategies. Then, we’ll discuss migration System Location Directory (SLD) content, Enterprise Services (ES Repository) content, and Integration Directory content.

8.1    Migration Strategies

The approaches and strategies to be used during a migration will be heavily influenced by your current infrastructure setup, requirements, and SAP PI installation version and flavor. The strategies explored here assume that the source system (that you want to migrate) is an SAP PI dual stack (ABAP and Java).

When starting the migration project, it’s important to decide between the following SAP PO installation or upgrade options:

• In-place upgrade
  With this option, most of the initial activities are performed on the source system. The following general guidelines need to be followed:
  • The current or existing SAP PI (dual stack) will need to be upgraded to a later dual-stack release (to version 7.31 at a minimum). Let’s call this system the source system.
  • All existing ABAP-based Integration Directory objects will need to be converted to their Java equivalents in the same installation (when possible). This can be done manually or by using the Migration tool provided by SAP.
• Side-by-side migration
  With this option, you’ll directly install a new SAP PO target system, in which most activities will be performed. The source system is left intact. From a high-level perspective, the steps involved in this migration option include the following:
  • Install a new SAP PO system running next to your existing (source) SAP PI dual-stack system.
  • Rethink and redesign your existing ABAP-based objects, including ABAP mappings and cross-component Business Process Management (ccBPM) processes.
  • Migrate relevant SLD objects, manually or by using the transport mechanism.
  • Migrate relevant ES Repository objects, manually or by using the transport mechanism.
  • Migrate relevant Integration Directory objects, using the Migration tool or manually.

In the next section, we’ll focus on the migration steps involved when using the side-by-side migration option because it’s the most commonly used. During migration, you’re creating a transition time during which you’ll have your old SAP PI and your new SAP PO installations running side by side (see Figure 8.1). After a successful migration, you’ll then switch off the old SAP PI installation and redirect all traffic to the new SAP PO installation. This strategy and approach will dramatically reduce the needed downtime.

Figure 8.1    Side-by-Side Migration: SAP PI Dual Stack to SAP PO

Tip

Note that if you’re currently not using ccBPM processes, and you’re not planning to use any business processes in the future, then you might consider installing only the Advanced Adapter Engine Extended (AEX) instead of SAP PO as a target system.

Before getting into the details of the different options available for the actual content migration, we want to highlight some of the differences between the SAP PI dual stack and SAP PO, which have an impact on the choices you’ll make for the migration. Table 8.1 details some of the differences between the two installation types.

Features	SAP PI (Dual Stack)	SAP PO
Development tools and integrated development environment (IDE)	Swing client and SAP NetWeaver Developer Studio	Swing client, SAP NetWeaver Developer Studio (can now be used for nearly all development) and SAP NetWeaver development infrastructure (used for source control).
Application server (AS)	Both SAP NetWeaver AS ABAP and SAP NetWeaver AS Java supported	Only SAP NetWeaver AS Java supported.
Mapping	Message mapping, Java mapping, and ABAP mapping	All the mapping possibilities are also supported, except for ABAP mapping; ABAP mapping will need to be redesigned as message mapping, Extensible Stylesheet Language Transformations (XSLT), or Java mapping.
Business process support	ccBPM, which is based on the SAP NetWeaver AS ABAP	SAP Business Process Management (SAP BPM) is provided instead. SAP BPM is purely based on SAP NetWeaver AS Java.
Data and value mapping	Fixed values and value mapping	Fixed values, value mapping, and SAP Business Rules Management (SAP BRM). The decision table of SAP BRM can also be used in some cases.
Custom tables	Custom ABAP tables built in SAP PI	Possible to create a SQL table to perform lookups. Consider using SAP BRM. SAP Composite Application Framework (SAP CAF) can also be used. Custom ABAP table in an SAP backend, and use Remote Function Call (RFC) lookup in your message or graphical mapping.
Interface configuration	Traditional “classic” configuration (based on SAP NetWeaver AS ABAP), Integrated Configuration (ICO), and integrated flow (iFlow)	ICO and iFlow. Traditional “classic” configuration is no longer supported due to the removal of SAP NetWeaver AS ABAP.

Table 8.1    Differences in Functionalities between SAP PI Dual Stack and SAP PO

We’re assuming here that you’ve already installed SAP PO in your landscape and that you’re now ready to start the content migration. Consider Table 8.1 for a mapping of the alternative Java-only objects for the existing ABAP-based objects. For example, from the table, you can establish that ABAP mappings will need to be re-created as message, Java, or XSLT mappings.

During the content migration, you need to follow a strategy that allows you to migrate existing components to their equivalent in the new system, starting with the least-dependent component group. The next section will explore the migration of each of these component groups.