16    Migrating ccBPM from SAP PI to SAP PO

Change is the law of life. And those who look only to the past or present are certain to miss the future.
                                                                                                 —John F. Kennedy

If you’re reading this chapter, the chances are high that you’re coming from a dual stack (ABAP/Java) SAP Process Integration (SAP PI) installation and that you’ve heard about the new features offered by SAP Business Process Management (SAP BPM) as part of SAP Process Orchestration (SAP PO). Most likely, you’ve implemented service orchestration workflows using cross-component Business Process Management (ccBPM) integration processes, and you’re planning or at least considering moving those existing ccBPM integration processes to the new Java-only stack of SAP PO.

If that is the case, then you’re at the right place in this book to start preparing for that challenging task. We believe this chapter is definitely one of the highlights of this book because it outlines a frequent challenge encountered by many SAP NetWeaver integration developers and architects when adopting SAP PO as their new application and business process integration platform.

This chapter will take you through the journey of analyzing, redesigning, and re-creating those existing ccBPM flows using the new generation of SAP BPM tools as delivered by SAP PO.

16.1    Motivation for Migration

SAP BPM is the process orchestration tool used to model and execute integrated processes in SAP PO. ccBPM as part of the ABAP stack of SAP PI is no longer supported under the Java-only stack of SAP PO, which means that, at some point, all existing ccBPM integration processes (only supported in SAP PI dual-stack installations) will need to be migrated to SAP BPM. Before we get into the details, let’s first briefly discuss the motivation behind a new method of business process orchestration in SAP NetWeaver and recap some of the main differences between ccBPM and SAP BPM.

In earlier releases of SAP PI (before SAP PO became officially available), many SAP customers (and in particular SAP PI developers) faced many technical limitations and functional difficulties imposed by the lack of a flexible and open business process orchestration platform, not to mention the total absence of basic business process management features, such as a user-friendly design environment to model and analyze business processes and a business rules engine (BRE) in SAP PI. Back then, if you had to support stateful message processing (i.e., persisting the status of an integration process on the integration server) or do something more exciting than just passing a message through SAP PI from point A to point B, then you did not have much choice but to use the heavy and slow ccBPM.

Although you could design and execute most common system-to-system automated processes with the features delivered by ccBPM, those features weren’t sufficient to support more complex and sophisticated business processes that required a high degree of user interaction and reusability of user or organizational management information on the SAP backend systems. Perhaps not a direct technical limitation of the tool, but one important aspect that prevented transparency and smooth communication between IT and business stakeholders about the process logic in their integration processes, was the lack of a standard way of modeling those integration processes according to a common and almost natural language that could be understood by business and IT process experts.

As you might recall from Chapter 9, ccBPM integration processes are based on the SAP Business Workflow engine, which is also internally used by many SAP modules. Considering that SAP PO is a Java-only installation, you have few options beyond moving your current ccBPM integration processes to SAP BPM. In addition to having different process engines, both platforms also use different ways of modeling their business process diagrams (BPDs). In the case of ccBPM, Business Process Execution Language for Web Services (BPEL4WS) is used as a graphical modeling language to describe interactions between systems by means of messages via web services. SAP BPM, on the other hand, uses Business Process Model and Notation (BPMN 2.0) as the common modeling language for visualizing and executing BPDs.

Some big advantages of BPMN 2.0 when compared with BPEL4WS are definitely its flat learning curve and easy accessibility and applicability by IT and business process stakeholders. These advantages automatically deliver other positive side effects, such as common understanding of business processes by IT and non-IT and the fact that documented business processes diagrams aren’t static process pictures any longer but now become alive, representing the real business process as executed during runtime by the SAP BPM engine.

Here is the definition of each:

BPEL4WS’s main goal is to represent an integrated process from a technical perspective, using web services as the main method of information interchange between its actors. That’s in contrast to BPMN 2.0, in which the modeling of a BPD is from a business perspective—that is, top down rather than bottom up, as in BPEL4WS.

Perhaps the most fundamental difference between BPEL4WS and BPMN 2.0 is that BPEL4WS follows a diagram design model based on a block structured graph type, whereas BPMN 2.0 process diagrams are more flexible and don’t follow a block structure flow type. However, there are good examples of SAP BPM-driven projects in which both standards coexist and are applied in the areas in which they excel. For instance, business analysts will do the modeling part of the processes using BPMN 2.0 notation, and developers will take care of manually translating those BPMN 2.0 models into their BPEL4WS representations. We don’t advise such a method as your first choice, but it’s a feasible alternative and way of working that can be applied if needed in specific situations.

Having said that, it’s clear that from a technological perspective, an automatic migration tool that makes it possible to move from ccBPM into the new generation of SAP BPM integration flows simply doesn’t make sense.