16.2    Migration Approach

As discussed in the introduction of this chapter, we’ve seen that it isn’t possible nor feasible to fully automate existing ccBPM integration processes 1:1 into their equivalent BPMN 2.0 representations in SAP PO BPDs, which means that we have to apply a different approach to execute the migration of integration processes.

Note

We assume that you’re planning to execute the migration procedure with both systems available—that is, the old SAP PI (dual-stack) and the new SAP PO (Java single-stack) installations. This is a prerequisite for the steps we’ll explain in the next sections. We call this a side-by-side or parallel migration approach.

Before we continue with the migration steps, let’s first take a quick look at Table 16.1, which provides an overview of the main differences between ccBPM and SAP BPM.

Comparison Area	ccBPM	SAP BPM
Installation and availability	Runs only on ABAP stack; SAP PI dual-stack (ABAP/Java) was available since the early versions of SAP Exchange Infrastructure (SAP XI) 3.0.	Runs on Java-only single stack; available from SAP PO 7.3. EHP 1 and SAP Composition Environment 7.1 EHP 1 onwards.
Support of open standards	Very limited, mainly proprietary SAP standards.	Widely supported, XML standards, Java, and SAP BPM open standards.
Support of system- and human-centric processes	Original ccBPM focus was system-to-system, but basic human-interaction functionality was later added by SAP.	Both human- and system- centric processes are supported, and mixes of both types of process orchestration can be accomplished.
Versioning and transport mechanism across different environments	Same methods as for other SAP PI classic objects—that is, via export/import options and enhanced Change and Transport System (CTS+) transport integration.	SAP NetWeaver development infrastructure required for proper versioning and transport support via CTS+.
Modeling environment	Modeling of integration processes is done from Enterprise Services Builder (ES Builder) from the Enterprise Services Repository (ES Repository) using a proprietary palette of modeling objects.	Design of BPDs is done in SAP NetWeaver Development Studio based on Eclipse and applying BPMN 2.0 standard modeling objects.
Contains SAP Business Rules Management (SAP BRM) functionality	No SAP BRM functionality included; business rules need to be accessed as web services via SAP PI or using other techniques, such as external calls (Remote Function Calls [RFC]/Java Database Connectivity [JDBC]) via mapping steps in the process flow.	When SAP PO is installed, the SAP BRM component is also enabled as a companion of SAP BPM. SAP BRM includes a complete suite of tools to design, develop, execute, and monitor business rules. Business rules can be embedded as part of the process or accessed as independent web services.
Integration between SAP PI and process engines	Integration between SAP PI and its business process engine (BPE) is done using abstract interfaces. Underlying communication protocol is SAP XI Simple Object Access Protocol (SOAP) protocol over HTTP/S.	SAP PO uses SAP XI 3.0 protocol over HTTP/S to exchange messages between the Advanced Adapter Engine Extended (AEX) and the SAP BPM component. Non-SAP XI protocol can also be used, but you don’t get guaranteed delivery of Quality of Service (QoS) for that type of interface.
Required skills and complexity of technology	Besides the SAP PI classic skills, a ccBPM developer also must have specific skills for modeling and developing integration processes, defining correlations, configuring variable context, performing error handling in ccBPM, and so on. Previous experience with SAP Business Workflow can be extremely beneficial when debugging ccBPM flows on the ABAP stack.	SAP BPM runs on the Java stack of SAP PO, which automatically means that as developer, you need to have a good to strong level of Java knowledge. In addition, SAP BPM skills such as understanding, analyzing, and modeling BPMN and non-BPMN flow diagrams are required.
Performance	The performance of ccBPM integration processes has always been a concern for most customers implementing ccBPM. It’s certainly not one of the positive features of this technology.	When compared to ccBPM, the performance gain for similar processes can improve 8 to 10 times faster when running under SAP BPM. Of course, it all depends on the size of messages, complexity of mappings, and so on, but, in general, a performance gain should be observed.

Table 16.1    Comparing ccBPM to SAP BPM

You should have now a better overview of what to expect from SAP BPM when compared to its predecessor, ccBPM.

We’ll now provide you with step-by-step instructions for how to analyze and translate existing ccBPM integration processes into their equivalent BPDs in SAP BPM. We’ll explain where, with what, and how to perform the migration procedure by following an effective, verifiable, and low-risk strategy.

Figure 16.1 depicts four main steps for migrating ccBPM integration processes to SAP PO.

Figure 16.1    Process Steps Migration Procedure

16.2.1    Analyze the As-Is Integration Processes

The first step you must consider when planning the migration of existing ccBPM integration processes into SAP BPM is to have a clear overview of what needs to be migrated to SAP BPM, which means understanding how those integration processes look from the inside, what kind of (integration) business logic has been implemented inside the various process steps, and what types of service orchestration they support.

One of the important things you’ll also have to decide is whether you want to migrate existing integration processes in phases or all in one go. For instance, you could prioritize them by business criticality, business area, or complexity, or perhaps you want to do it all at once in one big bang approach. Regardless of the strategy you choose, the preparation steps remain the same.

Let’s now examine the different aspects to be analyzed during this first step and at the same time discuss how and where to perform the complete ccBPM analysis in your existing SAP PI (dual stack) environment.

As-Is Cross-Component Business Process Management

Go to the ES Repository in the source system (SAP PI), and open your existing ccBPM integration processes to analyze each of them internally. Make sure you answer the following questions when doing the analysis for each of the ccBPM processes:

• What type of abstract service interface originally triggers the process—that is, synchronous or asynchronous?
• Is it a system-centric only or human-centric only business process or a mix of both?
• Does it support a long-running (e.g., it can take hours/days/weeks/months to finish) process, or does it support a near-real-time (finishes within seconds/minutes) process?
• How many receiver steps does this ccBPM process have—one or multiple?
• Does it support different message types?
• Does it perform intermediate calls to external web services before the process finishes?
• Are there any process variables maintained at the process or container level? If yes, are they of simple (string, Boolean, numeric, etc.) or complex (e.g., containing multiple messages) types?
• Does the process contain any decision logic—that is, switch steps, loops, or so on? If yes, then find out on what parameters the logic performed at runtime is based.
• How is exception or error handling currently done? Does the process automatically inform an administrator or user group about runtime issues using embedded process alerts, workflow tasks, or emails?
• Does the integration process handle big volumes of messages? Are there any binary files or attachments passed along?

Ask your administrator for current performance logs, in which you can see whether the process is or is not performing well currently. After this analysis task, you’ll have collected valuable information about the internal process logic of each ccBPM integration process and how it’s currently implemented, and you’ll have documented the results of the analysis and identified any specific type of critical or complex integration logic that might require additional attention when performing the migration to SAP BPM.

With the collected information, you can start making an estimate about possible process changes or improvements in the new SAP BPM implementation and the effort needed to develop those processes.

Big Bang or Phase-Based Migration

At this point, you may want to decide whether you want to go for multiple phases or a big bang migration strategy for all of your ccBPM integration processes. Both strategies are valid, depending your situation. For instance, there might be situations in which you have a limited number of integration processes and don’t need to split them into different phases. Or, perhaps your current SAP PI installation will be upgraded to SAP PO; in that case, you don’t have much choice but to migrate everything at once. However, if you have the flexibility, time, and budget, then our advice is to go for the phase-based migration approach. You can start by picking one or two existing ccBPM processes (e.g., a simple and a complex integration process) and work them out through the migration process. That will give you the opportunity to get used to the new SAP PO environment and all the other new things that you’ll encounter in SAP PO. Furthermore, your developers will get the opportunity to learn the new way of working in SAP PO and will get the chance to come up with best practices and lessons learned after the first migration phase.

After you’ve completed the migration of your first integration processes to SAP PO, you should be able to decide which migration approach you’ll follow for the remaining ccBPM scenarios—that is, a phase-based or big bang approach.

16.2.2    Translate and Redesign

In the first migration step (Section 16.2.1), we checked the existing migrated integration processes and analyzed their contents and specific configuration as set in SAP PI (e.g., how they were modeled using the BPEL4WS notation), and we checked the different process steps and what type of process logic has been applied to support their associated orchestration processes.

The second part of the procedure is a critical step in the migration that you need to perform when you’re moving away from ccBPM and start carefully building the new SAP BPM domain. At this stage of the migration procedure, you’ll put into practice some of the new required SAP BPM skills when developing orchestration processes in SAP BPM. We’re talking about the exercise of translating the existing ccBPM integration processes into their corresponding BPMN 2.0 representations. In the next sections, we’ll unveil how you should proceed.

Tip

You should prepare your System Landscape Directory (SLD) software components (SCs) (software component versions [SWCVs], development components [DCs], dependencies, etc.) and perform SAP NetWeaver development infrastructure configuration before executing this step. Otherwise, you’ll have to export or import your local DCs manually from SAP NetWeaver Developer Studio into the real ones in the SLD or in SAP NetWeaver development infrastructure at a later stage.

Figure 16.2 shows a representation of what could be the final result after performing the translation of an existing ccBPM integration process into a BPMN 2.0 process diagram.

Figure 16.2    Translating ccBPM into BPMN 2.0

As you can see, we’ve provided a mapping (shown as arrows) between the old ccBPM objects and their equivalents in SAP BPM’s BPMN 2.0 palette.

Table 16.2 gives a complete overview of the different ccBPM objects and their equivalent flow objects in the BPMN 2.0 environment. You can use this table when doing the redesign and translation of your integration ccBPM processes as a reference guide. Chapter 9 also provides more information and detailed explanation about the BPMN 2.0 standards and its flow objects as supported in SAP BPM.

ccBPM Step (BPEL4WS)	SAP BPM (BPMN 2.0)
Start	Start event (with or without message as trigger)
Receive	Intermediate event (message)
Send	Automated activity
Transformation	Mapping activity or automated activity
Container operation	Data object (with or without mapping/transformation)
Switch	Gateway (different types)
Loop	Gateway and activity (Generally, you use a gateway to support the looping functionality; however, all activities also have their own looping option, which allows you to model multiple parallel instances of the activity in the process model.)
User decision	Human activity
Wait	Intermediate event (timer)
Control	Notification or end event

Table 16.2    ccBPM to BPMN 2.0 Reference Guide

As you may have noticed in the reference guide (Table 16.2), there are some ccBPM objects mapped to more than one equivalent flow object in SAP BPM’s BPMN 2.0 palette, which means that there might be different ways of modeling your current process logic in SAP BPM to obtain the same result.

Tip

It’s crucial that you keep in mind the following core design principle when redesigning the process model and doing the basic process logic translation: the new SAP BPM BPD, including its process orchestration logic, must deliver at least the same process functionality or better than its predecessor implemented in the ccBPM version.

If you encounter challenges or blocking issues while doing the business process redesign that might prevent you from meeting that core principle, then you should seek feasible alternatives and, if necessary, outsource those specific blocking components to a different layer in the SAP BPM application (e.g., Java custom logic or business rules), or consider moving some process logic to the backend system if applicable.

16.2.3    Export and Reuse Enterprise Services Repository Objects

The third step of the migration procedure involves creating a clear overview and making a preselection of the following:

• Which SAP PI repository objects can be directly migrated without changing them?
• Which objects can be migrated but require some adaptation?
• Which objects need to be re-created from scratch?
• Which objects will be discarded in the new SAP PO solution?

Based on that information, you can then estimate the design and configuration time requirements needed to execute the complete migration.

You can save valuable time during this task when you know that most SAP PI repository objects are supported in SAP PO, except for ccBPM integration processes, abstract interfaces, and any ABAP mappings.

This procedure consists of an export from the source repository of SAP PI containing the existing design objects you want to migrate and an import to the target repository in SAP PO.

Note

Where relevant, you can also perform a normal transport between the two ES Repository installations. This approach does require additional CTS+ configuration.

Before you start, make sure that you’ve created all required SWCVs with their corresponding namespaces in the target SLD and ES Repository.

The export procedure is as follows:

1. From the old SAP PI (dual-stack) system, go to the Enterprise Service Repository home page, and click on the Enterprise Service Builder link.
2. Go to http://<hostname>:<port>/dir where <hostname> and <port> correspond to the SAP PI host—for example, http://sappi.rojoconsultancy.com:50000/dir.
3. Navigate to Tools • Export Design Objects. You should see a window like the one displayed in Figure 16.3.
   

   Figure 16.3    Exporting ES Repository Objects

4. Select the Software Component Version in which the objects exist that you want to export, and choose Transport Using File System in the Mode dropdown menu.
5. The export file will be created with the extension .tpz, and depending on your choice, it will be created either on the SAP PI server (from where you perform the export) or on a local folder on your client PC. You can enable that functionality simply by selecting the Download File to Client checkbox.

Table 16.3 provides an overview of the export and import folders. If you don’t select the Download File to Client checkbox, then you’ll need the corresponding operating system-level authorizations on the SAP NetWeaver Application System to retrieve the exported .tpz files.

Type	ES Repository Folder
Export	<systemdir>/xi/repository_server/export
Import	<systemdir>/xi/repository_server/import

Table 16.3    ES Repository Export/Import Folders

On the next screen, you can select which design objects you want to include in your export file based on different criteria. We recommend that you select Individual Objects from the Object Set dropdown menu, unless you’re sure you can reuse all design objects in one single namespace or SWCV (see Figure 16.4).

Figure 16.4    Selecting Individual ES Repository Objects

Adding Fault Message Types to Existing Service Interfaces

Although existing service interfaces can be reused in SAP PO, you should consider reconfiguring them in terms of adding default fault message types to their service definitions. That will allow you to support exception handling using boundary events when modeling your new processes in SAP BPM. This recommendation doesn’t apply for outbound asynchronous service interfaces.

Abstract Interfaces in SAP PO

You might also have noticed that the Abstract option in SAP PO for declaring service interfaces hasn’t completely disappeared from the Category dropdown menu in the ES Builder (see Figure 16.5). This might be confusing because you know that this type of interface category isn’t supported (it’s only needed for ccBPM scenarios) or needed anymore in SAP PO or AEX Java-only systems. You shouldn’t try to reuse this deprecated capability in non-ccBPM scenarios in SAP PO because it might result in unpredictable runtime behavior. Surprisingly, if you carry on and activate the abstract interfaces, you’ll be able to configure this type of service interface and activate it in any Integrated Configuration (ICO). Currently, there is no restriction or validation message during the activation process that warns you about this faulty choice.

Figure 16.5    Abstract Service Category in SAP PO

16.2.4    Migrate and Adapt Configuration Scenarios

We dealt with the ES Repository objects in the previous migration step, so now it’s time to concentrate on the configuration time objects, which are maintained in the Integration Directory.

Note

We’re assuming in this step that you’re migrating ES Repository objects from SAP PI versions not older than 7.1. If you’re migrating from an older version, then you might need to re-create some objects manually, especially for communication channels, due to a change in the adapter metadata version.

SAP PO provides a wizard-based tool for the migration of existing integration directory content, including communication channels and configuration scenarios that can be directly migrated to ICOs. The Integration Directory Migration tool automatically detects all available SAP PI and SAP PO directory instances in your environment. In the Integration Directory Migration tool, you select which configuration scenarios you want to migrate from which system to which system and how you want to move or rename the objects. Furthermore, this Migration tool also supports a mass change functionality that can be applied to communication channels and configuration scenarios—for instance, to rename all or specific directory objects while performing the directory migration.

Integration Directory content from previous releases of SAP XI, SAP PI, and SAP PO (i.e., 3.0, 7.0, 7.1, 7.11, 7.3, 7.31, 7.4, and 7.5) is supported by the tool. To use the Migration tool, follow these steps:

1. Access the tool from the pimon URL: http://<hostname>:<port>/pimon, where <hostname> and <port> match the target system, which can be SAP PO, AEX, or Advanced Adapter Engine (AAE) running under a dual-stack system—for example, http://sappo.rojoconsultancy.com:50000/pimon (see Figure 16.6).
   

   Figure 16.6    Migration Tool in SAP NetWeaver Administrator

2. Click on the Migration Tool link from Configuration and Administration tab. You should now see a screen like the one shown in Figure 16.7.
   

   Figure 16.7    Integration Directory Migration Tool Main Page

   Tip

   The Integration Content Migration tool can be directly accessed and launched via http://<Hostname>:<Port>/webdynpro/resources/sap.com/tc~pi~tools~dirmig~wd/DirectoryCockpit.

   Figure 16.8 shows the first of the five-step Scenario Migration procedure, where the source and target system are selected.
   

   Figure 16.8    Scenario Migration

3. In the System Name dropdown, select the SAP PI source system from which the tool must read the configuration scenarios to be migrated.
4. Select the Use Secure URL checkbox if secure communication applies.
5. Enter the SAP PI User Name and Password for the source system; the user must be authorized to use the Directory API for display purposes.
6. Provide the SAP PO User Name and Password for the target system, and click on Next.
7. On the following screens, you can select on which criteria you want to migrate the existing configuration scenarios to SAP PO (see Figure 16.9).

Figure 16.9    Selecting the Scenario Migration Criteria

For more detailed information and guidance about how to use the Migration tool, refer to Chapter 8, Section 8.4.2, where the usage of this tool is extensively covered.

The tool also offers other useful features, such as mass editing or movement of communication channels and renaming existing configuration objects before creating them in the new SAP PO environment.

You create your own renaming rules based on suffixes added to the old configuration object names or by applying more specific value mappings to the migrated configuration objects. The renaming rules functionality is accessible via the Configuration link in the Integration Directory Migration tool (see Figure 16.10).

Figure 16.10    Migration Tool Renaming Rules