SAP NetWeaver Process Orchestration (SAP NetWeaver PO) 7.31 is a new offering for companies that want to benefit from the combined functionality of the three products SAP NetWeaver Process Integration (SAP NetWeaver PI), SAP NetWeaver Business Process Management (SAP NetWeaver BPM), and SAP NetWeaver Business Rules Management (SAP NetWeaver BRM). It is especially attractive for SAP NetWeaver PI users who can now build sophisticated stateful integration processes, which were not possible on the old cross-component Business Process Management (ccBPM) environment.

As SAP NetWeaver PO was built solely on the pure Java stack, it was clear from the beginning that companies could not reuse their existing ABAP-based ccBPM integration processes in the new environment. As a result, customers approached SAP with a question: How do we get our already-running processes onto SAP NetWeaver PO? This question came up often on our SAP NetWeaver PI forum on SCN and was heatedly debated at last year’s TechEd. This article explains why an automated solution is not possible without major drawbacks.

For migrating simple ccBPM processes to SAP NetWeaver BPM, which takes over the stateful integration role within SAP NetWeaver PO, you may simply be able to “translate” your existing ccBPM models to the new Business Process Model and Notation (BPMN) modeling language. To do this, you take each ccBPM shape and replace it with the corresponding BPMN element. Although this might work for simple scenarios, it isn’t that easy in more complex, nested real-life integration processes. In order to better understand the difficulties of such a translation, you have to take a closer look at the languages being used in each of the environments, because they are the main reason for the migration problems you will face.

ccBPM is based on the Business Process Execution Language (BPEL). BPEL was especially useful in the Web services era when more powerful (Web) services could be created by combining individual Web services. Combining Web services in this way is often referred to as “service orchestration.” Typical for BPEL-based processes is their nested structure, as BPEL is highly block-oriented. This becomes obvious if you take a look at an example ccBPM process, which is shipped with every SAP NetWeaver PI installation and which is used for reference purposes throughout this article. It is depicted in Figure 1.

Figure 1

ccBPM process for coordinating multiple flights

Figure 1 shows a flight-booking coordination process. It can be found in the Enterprise Services Repository (ESR) of your SAP NetWeaver PI installation at the following location:

• Software Component: SAP BASIS
• Software Component Version: SAP BASIS 7.31
• Namespace: https://sap.com/xi/XI/Demo/Agency
• Integration Process: MultipleFlightBookingCoordination

The process coordinates the connecting flights ordered by a travel agency. It is worth taking a closer look at the process as I use it as an example for discussing migrations. First of all you should notice the several blocks that are nested inside each other. You can identify the sendparallel block that itself contains the checkresult block. On the right the allconfirmationsreceived block encapsulates the cancelbookedflights block. As noted before, this is typical for BPEL-based processes due to its block-orientation.

As a consequence it is not possible, for example, to arbitrarily connect nodes from the cancelbookedflights block with nodes from the sendparallel block, as doing so would violate the rules for nested blocks. These rules only allow such connections within a block. You simply have to know such restrictions and apply them while developing BPEL processes.

BPMN-based processes do not follow the same rules, as BPMN is flow oriented. This relieves you of the burden of encapsulating and structuring your integration logic using blocks. You have more freedom in arranging the steps of your processes leading to more lean process models. It would be possible to simply translate your ccBPM processes one-by-one to BPMN. Figure 2 shows a comparison of the different shapes available in each of the modeling environments.

Figure 2

Comparing ccBPM shapes with BPMN shapes

Obviously for each ccBPM element you can identify an appropriate BPMN shape. This is very tempting as it suggests a simple one-to-one translation of your ccBPM processes to BPMN. However, my recommendation emphatically is:

Do not use the comparison of shapes shown in Figure 2 to “translate” your ccBPM processes to BPMN. BPMN offers much more powerful features to build highly optimized integration processes.

How would the final BPMN process look if you were to translate the process depicted in Figure 1 to BPMN using the “translation map” shown in Figure 2? The result is depicted in Figure 3.

Figure 3

BPMN translation of the flight coordination ccBPM process

The resulting BPMN-process reveals no surprises. You simply took each and every ccBPM shape and replaced them using the corresponding BPMN-element. You might say, “Why not? The result looks good to me.” And yes, you are right: This is a working BPMN process which (most likely) will also implement the process semantics of the original ccBPM process. However, applying BPMN, its flow-oriented approach, and its powerful shapes correctly leads to a completely different result, which is depicted in Figure 4.

Figure 4

Flight booking coordination process using BPMN correctly

Obviously the number of steps has been significantly reduced. The process model is leaner, easier to understand, better to maintain, and during runtime much more performant than its predecessor shown in Figure 3. The problem is that such a model cannot be derived automatically from a given BPEL process. To come up with such a solution the tool would have to automatically understand the semantics of a given process.

Let me explain this using my flight-booking example. The scenario works like this: A travel agency sends a document containing several flights for a customer. The flights are necessary for a journey the customer has planned. The task of the integration-centric process is to get confirmations from each involved airline that seats for the scheduled flights are still available, and at the same time let the airlines book a seat for the respective flight. If all flights can be confirmed and booked, the travel agency will receive a success message. If at least one airline cannot confirm a flight, all already-reserved seats for the other flights have to be cancelled and a failure message has to be sent back to the travel agency.

This problem is solved elegantly with the BPMN model shown in Figure 4. The incoming message Multiple Bookings leaves the Travel Agency pool, points to the start event () of the Integration-Centric Process pool, and kicks off the process instance. The content of the incoming message is moved to a local data object called Order_List, which comprises the requested flights.

The data object contains three parallel bars at the bottom indicating that this is a multiple instance data object containing more than one entry. A sequence flow leaves the start event and points to a subprocess named Booking Subprocess. It also contains the vertical bars at the bottom indicating that the subprocess will be instantiated as often as you have entries in your Order_List data object. In other words, the subprocess will be executed for each entry of the Order_List data object. This is a BPMN method that indicates the parallel execution of several subprocesses at the same time.

Within the subprocess, the first activity Send Booking sends a message to one airline containing the booking information. Next the subprocess waits asynchronously for the Booking Confirmation response message from the airline. If and only if the reservation was successful, the subprocess updates the data object Confirmed_List holding all confirmed flights. Once all instantiated subprocesses have finished, the gateway All Confirmed? checks the number of entries in the Confirmed_List data object with the number of entries in the Order_List data object.

The process knows that if the numbers are identical then all scheduled flights have also been confirmed by the airlines and it can send back the success message Confirmation to the travel agency. If the two numbers differ, the process has to cancel all already-reserved seats prior to sending the Failure message. The cancellation is done via the Send Cancel Booking activity. Send Cancel Booking likewise contains the multiple instance marker, which means that the process sends as many Cancel Booking messages as it has entries in the Confirmed_List data object. In other words, for each already confirmed booking, a cancellation must be sent. Once finished the process ends by sending the Failure message via the message end event Send Failure().

Once you are freed from the limitations of BPEL, your processes become quite different. If you also account for the runtime effort of the lean BPMN model (four activities, one subprocess) compared with the complex BPMN model (14 activities, five subprocesses), it becomes obvious that the complex model is also a waste of resources. Consider: Before and after each activity/block the contents of the process context (which is made up of all the data objects defined in the process) are automatically stored in the database by the process runtime for logging purposes.

This allows you to find out afterwards how each step modified the content of the process context while it was executed. Can you imagine what that means for the huge model? It would be significantly slower than the lean model. It would not even help if an automated tool were to deliver the process model of Figure 3 as a starting point. You would have to throw away more or less everything besides of the few send and receive steps.

However, there are other reasons for the lean model: All the transformations and container operations are handled implicitly in SAP NetWeaver BPM via process context mappings (mapping of the data flow from the process steps to the process context as output mapping and the reverse as input mapping) and not explicitly as you have modeled it in the ccBPM process. No fewer than eight transformation and container operation steps are part of the ccBPM model. They are simply superfluous in the BPMN model.

To sum up: The fundamental conceptual differences between BPEL and BPMN plus the way data and their transformations are handled within the processes makes it hard (if not impossible) to deliver an automation tool for ccBPM-to-BPMN migration. It will likely only work for very simple scenarios that can also be easily remodeled using the graphical Process Composer perspective of SAP NetWeaver BPM. SAP is delivering even more help in order to at least lower the migration effort, by planning to support the reuse of abstract interfaces, which are common in the ccBPM models for SAP NetWeaver BPM. This saves you from remodeling each abstract interface in the ESR for your new BPMN-based processes. In addition, SAP is delivering templates for well-known enterprise integration patterns (see Hohpe, G., Woolf, B. [2004]: Enterprise Integration Patterns. Designing, Building, and Deploying Messaging Solutions. Boston: Addison Wesly) showing you how to model solutions for typical integration problems using SAP NetWeaver BPM. Those templates are intended to be reused in your projects and are already available on SCN.

The model shown in Figure 4 is the optimal solution based on pure BPMN usage. There are some limitations to this model if it comes to the implementation on SAP NetWeaver BPM. Although SAP NetWeaver BPM implements BPMN, it currently doesn’t cover all available BPMN shapes. In addition, there are some SAP NetWeaver BPM particularities that lead to a slightly different solution for my flight coordination problem compared to the model depicted in Figure 4.

For a proper conversion of this business process to BPMN, see the second part of this series.

Dr. Volker Stiehl

Prof. Dr. Volker Stiehl studied computer science at the Friedrich-Alexander-University of Erlangen-Nuremberg. After 12 years as a developer and senior system architect at Siemens, he joined SAP in 2004. As chief product expert, Volker was responsible for the success of the products SAP Process Orchestration, SAP Process Integration, and SAP HANA Cloud Integration (now SAP HANA Cloud Platform, integration service). He left SAP in 2016 and accepted a position as professor at the Ingolstadt Technical University of Applied Sciences where he is currently teaching business information systems. In September 2011, Volker received his Ph.D. degree from the University of Technology Darmstadt. His thesis was on the systematic design and implementation of applications using BPMN. Volker is also the author of Process-Driven Applications with BPMN as well as the co-author of SAP HANA Cloud Integration and a regular speaker at various national and international conferences.

 

You may contact the author at editor@SAPpro.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.