Companies are under pressure to implement their unique, business-critical processes faster than their competition due to shrinking margins. SAP has always delivered technical products such as SAP NetWeaver Business Process Management (SAP NetWeaver BPM), SAP NetWeaver Business Rules Management (SAP NetWeaver BRM), and SAP NetWeaver Process Integration (SAP NetWeaver PI) to help IT departments in their implementation efforts. These applications focus on different areas: SAP NetWeaver BPM focuses on human-centric processes, while SAP NetWeaver PI supports companies in implementing integration-centric scenarios.

Human-centric processes are ones that are executed by different people in different process roles. A typical example is an approval process for a leave request. The employee enters (in one human process step) the dates when he intends to go on vacation. Once he has finished the task, his manager has to confirm the request before it is stored in an HR system. On the other hand, integration-centric processes consist mainly of automated steps. Take the aggregator pattern I described in detail in my article “Combine SAP NetWeaver BPM and AEX to Implement Powerful Integration Scenarios” as an example. The integration process collects incoming messages without human involvement. Once a certain number of messages has been collected or a certain amount of time has elapsed, the system sends out a single message containing all the collected messages.

Over time the borders between human-centric and integration-centric processes have blurred. Human-centric processes require integration capabilities, while integration-centric processes require human interactions in case of unexpected errors. SAP’s answer to supporting these challenges is SAP NetWeaver Process Orchestration, which is a combined installation of SAP NetWeaver BPM, SAP NetWeaver BRM, and SAP NetWeaver PI in one Java Virtual Machine (JVM). It is not only a combined installation — over the last year, SAP also optimized the integration of SAP NetWeaver BPM and SAP NetWeaver PI so that the two stacks could communicate faster and more reliably with each other.

Figure 1 depicts a high-level overview of SAP NetWeaver Process Orchestration’s architecture.

Figure 1

High-level architecture of SAP NetWeaver Process Orchestration (source:SAP)

SAP NetWeaver Process Orchestration is a pure Java solution. It fits well with SAP’s strategy to move to a pure Java environment for SAP NetWeaver PI. SAP NetWeaver Process Orchestration is based on the JavaEE 5 application server as the runtime environment. The modeling and development tools are grouped together in SAP NetWeaver Developer Studio, which is founded on the Eclipse framework. Consequently, the functionality of the rich client Swing tools for SAP NetWeaver PI (namely Enterprise Services Builder and Integration Builder) were integrated into SAP NetWeaver Developer Studio by providing new Eclipse plug-ins. The Java application server as a common platform delivers the standard functionality summarized in the Infrastructure Services box of Figure 1.

On top of the standard Java application server, additional enterprise service bus capabilities such as routing, mapping, and reliable messaging are provided. The connectivity to other systems and protocols via adapters is also part of the standard shipment. In the upper-left corner of Figure 1 the Enterprise Services Repository (ESR) and the Enterprise Services Registry are shown. They were already part of SAP NetWeaver Composition Environment and SAP NetWeaver PI and made their way into SAP NetWeaver Process Orchestration as well. They support the life cycle and governance of services in service-oriented architecture (SOA) landscapes. Finally, in the upper-right corner of Figure 1 are the two solutions SAP NetWeaver BPM and SAP NetWeaver BRM.

At a more detailed level, the architecture and connectivity between SAP NetWeaver PI and SAP NetWeaver BPM are depicted in Figure 2 (which is taken from the online documentation).

Figure 2

Detailed architecture of SAP NetWeaver Process Orchestration (source:SAP)

The dashed border of the rectangle on the left side makes up the design and configuration time and the dashed border of the rectangle on the right side contains the runtime parts of SAP NetWeaver Process Orchestration. In the middle, you can identify the dark gray boxes labeled Business Process Management, representing the design and runtime of SAP NetWeaver BPM, and Advanced Adapter Engine Extended (AEX), representing the pure Java installation option of SAP NetWeaver PI. The light gray box labeled AS Java around the two components indicates the common deployment of SAP NetWeaver BPM and AEX on one JVM. This is important as it saves the separated setup of SAP NetWeaver BPM and AEX in different JVMs (and even separate physical machines) and the associated additional overhead (e.g., memory space, performance).

SAP NetWeaver Process Orchestration optimizes the administration and monitoring of the whole stack, contributing to a reduced total cost of ownership (TCO). Figure 2 also summarizes quite nicely the relationship between the Advanced Adapter Engine (AAE) and the AEX, two terms that are often confusing. The AAE is just the adapter engine itself, which takes care of message handling and the connectivity to SAP and non-SAP systems. The AEX, on the other hand, is the combination of AAE, the Enterprise Services Repository, and the Integration Directory.

In the Integration Experts box on the left, the different development and configuration roles are depicted. The tools for those roles are all contained in SAP NetWeaver Developer Studio. A project typically starts with the definition of data types, message types, service interfaces, and mappings. This was formerly achieved using the rich Swing client called Enterprise Services Builder. SAP’s strategic approach to tools, however, is to include them in SAP NetWeaver Developer Studio. Consequently, all investments in the old Swing clients are significantly reduced (and only used for maintenance and bug fixing). For SAP NetWeaver Process Orchestration, the Enterprise Service Browser (ES Browser) plug-in in SAP NetWeaver Developer Studio was significantly enhanced. For example, you can now define your own custom life cycle attributes, assign them to your development artifacts, and subscribe to them so that you are notified of changes. Figure 3 shows a screenprint of the Enterprise Service Builder perspective in SAP NetWeaver Developer Studio.

Figure 3

Enterprise Service Browser Perspective withn SAP NetWeaver Developer Studio

It is important to know and understand that the server-side Enterprise Service Builder parts remain the same even with the new modeling front end. It’s just the user interface (UI) that has changed and simply connects to the ESR server to maintain all development artifacts remotely via the ES Browser. All the investments companies made in setting up (e.g., life cycle procedures) by using the ESR API are preserved.

You can then use the interfaces that were modeled in the ESR perspective within the modeling environment for business processes in the Process Composer. The Process Composer connects to the ESR to import available service interfaces into the process modeling environment. These service interfaces are not only used for describing the data structures being exchanged between SAP NetWeaver BPM and SAP or non-SAP systems. They are also used to describe the interface between SAP NetWeaver BPM and AAE — this means that in essence the relationship between the two is expressed completely by service interfaces. Several articles have been published about the Process Composer, so I will not dive into the details of using it to model processes. However, Figure 4 depicts the Process Composer perspective showing a process being modeled using the business process model and notation (BPMN) as the graphical notation.

Figure 4

Process Composer Perspective within SAP NetWeaver Developer Studio

The most significant change on the tooling side is to the configuration of integration scenarios within the Integration Directory (ID). Until SAP NetWeaver PI 7.3, the rich Swing client called Integration Builder was used for this purpose. Here the same applies as for the Enterprise Services Builder: the Swing front end will be replaced over time by an Eclipse-based UI, the new Process Integration Designer (PI Designer) perspective. The PI Designer is a new graphical modeling tool used to configure message handling within the integration engine of the AEX. Figure 5 depicts a screenprint of such a configuration.

Figure 5

Integration flow modeled with the new Process Integration Designer

Figure 5 shows the configuration of one message being sent from a sender that is represented by the rounded rectangle on the left to two receivers represented by the two rounded rectangles on the right. The names of senders and receivers are shown in the respective header areas of those rectangles (e.g., Receiver 2). You can also identify the interface that is being sent as well as the receiving interfaces. The interfaces are represented by the rounded rectangles inside the sender and receiver boxes with the interface icon  in their upper-left corners. Finally, you can recognize the adapter types (e.g., the SOAP adapter that sends the message) that are being used for connecting the respective systems. They are associated with the dashed arrows from the sender interface to the start event  and from the end event  to the receiver interfaces.

In between the participants of this communication, you find the integration flow, which is a new term introduced with the advent of the PI Designer. It is modeled again using BPMN, a notation standard normally used to define business processes. As an integration flow can also be seen as some kind of process handling, SAP decided to reuse the notation for configuring integration flows as well. As BPMN is also used for modeling business processes within the Process Composer, the use of a harmonized notation helps increase the understandability of those models across different tools. In the model in Figure 5, the message first passes the Receiver Determination for deriving the receivers of the message. Depending on the found receivers, the message is either forwarded directly to the first receiver without further ado, or the message has to additionally pass the Interface Determination step to find the right target service interfaces. Again, depending on the outcome of this step, the message is either forwarded unchanged or it has to be mapped to the target format of the receiver using a dedicated mapping program.

In summary, the advantage of using the graphical approach for configuring integration scenarios is quite obvious: You can immediately see who communicates with whom using which interfaces and which communication channels. You also grasp immediately how the message is being handled while being executed on the integration server and which steps are involved. This was not possible before in such a comprehensive manner.

You should now have a basic understanding of how integration flows are modeled using the PI Designer. Again, it is important to know that only the UI for the Integration Directory was replaced with the PI Designer. As I’ve explained for the ESR, the same applies for the relationship between the Process Integration Designer and the Integration Directory: The new Eclipse-based perspective just connects to the Integration Directory on the server and maintains configuration objects remotely in the Integration Directory. To be more precise, with the new Process Integration Designer you configure the Integrated Configuration Objects (ICOs) within the Integration Directory. ICOs are not new. They existed already in older releases of SAP NetWeaver PI. However, as of this writing some restrictions exist for the use of the new PI Designer. It can only be used for the Java-only deployment option of SAP NetWeaver PI (AEX) and it can only be used in combination with the 7.31 release. Unfortunately, even existing ICOs currently cannot be transformed to integration flows and hence cannot be handled with the PI Designer.

SAP NetWeaver Process Orchestration Runtime

Let’s turn to the runtime part of SAP NetWeaver Process Orchestration. As Figure 2 indicates, the SAP NetWeaver BPM engine and the AEX are installed on one system using only one JVM. However, the key improvement coming with SAP NetWeaver Process Orchestration is the connectivity between the two engines. The integration between the two was achieved by reusing the Java Proxy Runtime (JPR) and relying on the SAP NetWeaver PI 3.0 protocol via the SOAP adapter. Both JPR and the SAP NetWeaver PI 3.0 protocol existed for quite some time in former releases of SAP NetWeaver PI and are therefore stable and reliable. They are used in the following situations:

• AAE hands over a message to SAP NetWeaver BPM to start a new process instance via the message start event
• AAE hands over a message to SAP NetWeaver BPM to continue the process instance via the intermediate message event
• SAP NetWeaver BPM hands over a message to AAE to forward it to one or several receivers via an automated activity

The use of JPR and the SAP NetWeaver PI 3.0 protocol ensures the quality of service Exactly Once, meaning that the delivery of messages between the two is guaranteed. This is new as with former releases you were only able to achieve the quality of service Best Effort (meaning that no guarantee of a message delivery could be given).

With this coupling of SAP NetWeaver BPM and AEX on one Java stack, the modeling of new scenarios described at the beginning of this article becomes possible. Whether a human-centric process requires integration support (as it can itself only connect directly to SAP systems via Remote Function Calls [RFCs] or to other systems via Web services) or whether an integration scenario requires stateful process handling, the SAP NetWeaver BPM process engine can cover both cases (human centric and integration centric). This new combination fills another gap that was caused by the move to a pure Java environment for SAP NetWeaver PI: the cross-component Business Process Management (ccBPM) engine of the former dual SAP NetWeaver PI stack (Java and ABAP) was implemented completely in ABAP and hence could not be reused in the pure Java installation option of SAP NetWeaver PI. Now with SAP NetWeaver BPM at its side, the ccBPM functionality can already be covered partially by the BPM engine. Existing functional gaps compared to ccBPM will be closed by upcoming releases of SAP NetWeaver Process Orchestration.

One final enhancement that comes with SAP NetWeaver Process Orchestration is mapping as a service. Many companies have invested a lot in costly data mappings between two interfaces. They have either used the graphical mapping tool within the Enterprise Services Builder, have developed Java programs for this purpose, or have created complex extensible stylesheet language transformation (XSLT) mappings. The good news is: Their investments are not lost. The mappings can now also be reused within SAP NetWeaver BPM. By simply importing them into Process Composer, a Web service is generated and can be used within process models. This extends the reach of mappings to processes. The downside: As SAP NetWeaver Process Orchestration is completely Java based, existing ABAP mappings cannot be reused.

SAP NetWeaver Process Orchestration 7.31 has been in Ramp-Up since November 2011 and should be generally available at the end of Q2 2012. First scenarios using the combined stack should focus on enhancing classical business processes modeled within SAP NetWeaver BPM with integration capabilities provided by SAP NetWeaver PI. Over time, more and more integration-centric processes will be supported. SAP intends to deliver pre-configured integration process templates accompanied by documents explaining how to implement the template in particular integration scenarios. This ensures the correct use of SAP NetWeaver Process Orchestration for integration-centric processes.

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.