Modeling of business processes for process documentation has been in place for many years. However, the application of business-process management in general has changed significantly due to the release of the graphical process notation Business Process Model and Notation (BPMN) 2.0 in January 2011. With this particular release it is not only possible to model business processes for documentation purposes using a widely adopted standard. You can now also execute models using a BPMN 2.0-compliant BPMN engine. This is a step forward for the business-process management world as it means an alignment of the process models that have been created by the business folks and the business processes that are implemented by their IT colleagues. SAP Process Orchestration is a bundle consisting of the three products: SAP Process Integration (SAP PI), SAP Business Process Management (SAP BPM), and SAP Business Rules Management. It contains a BPMN engine and is therefore suited to model and run differentiating business processes. However, the first projects using executable BPMN showed that it requires more than a process engine to build applications that are driven by business processes. It requires a rethinking of application development and a development methodology as well as a new application architecture. I’ve summarized all the learnings from those projects in my book Process-Driven Applications with BPMN. As these applications are distributed in nature, they require sophisticated monitoring support. This article gives a brief summary about process-driven applications, their architecture, and how to track them during run time. Process-driven applications in general are useful in a multitude of situations in which standard processes are not appropriate as they cannot cover all the processes unique to your particular business. Think about the new wave of signals and events originating from the Internet of Things (IoT): How would you act on these new sources of information? With process-driven applications you can fill the gaps in your process landscape. You can model and run tailored processes, (e.g., identifying that a machine requires maintenance based on the current usage and the knowledge from the past when it is necessary to take the machine out for an overhaul). Or you can react on delays in your supply chain by tailored business processes. In the end, to build a process-driven application you need a separation of concerns reflected by different application layers that communicate with each other. In essence you can differentiate between the layers as follows:

• The processes of the process-driven application formulated using BPMN. The process models of this layer are solely motivated by business needs. One key characteristic of the process-driven approach is that the responsibility for these process models is on both sides: business and IT. The models are not exclusively developed by business-oriented employees, but incorporate IT as well. IT colleagues, for example, accompany their business counterparts during the specification of their business processes. I’m referring to this new way of collaboration as BizDevs (the abbreviation for a new collaboration model between business and development), which reflects the responsibility of both business and development for the respective process models.

 

• What the processes of the process-driven layer require from the external world as well as what the processes provide for the external world is expressed as a so-called service contract. This contract can technically be described using XML Schema Definition (XSD), Web Services Description Language (WSDL), or any other means for interface descriptions. Note:  In most cases these interfaces are asynchronous in nature. Synchronous interfaces are recommended only for user interface (UI)-related read operations. Note that the interfaces are lean in the sense of keeping the number of fields as low as possible. The numbers of interface fields are driven by the requirements of the business processes and not by the systems that you might need later on to fulfill the service contract. I recommend using a canonical data model (CDM) for the definition of the service contract. A canonical data model is a universal cross-system data model that is completely independent of the applications to be integrated. This approach differs significantly from the Service-Oriented Architecture (SOA) methodology in which the interfaces of services and their reuse are of the highest importance. This isn’t the case for process-driven applications, where the focus is primarily on support for the top-level processes.

• The service contract implementation layer that implements the requirements of the service contract. Here you can distinguish between stateful and stateless integration centric processes.

Stateless processes care just about the messages they have to transport: validating the contents, enriching them with additional data, routing them to the target systems, mapping the data to the target system’s interface structure, and caring about the technical connectivity to the back-end systems are the main tasks. They can usually be covered by an Enterprise Service Bus (ESB). These processes are stateless because each process instance just cares for exactly one message. The instance doesn’t have to wait for other messages to arrive before it can continue. Because they are not waiting there is no need for them to store data in the meantime. This storing of data in between is referred to as state. Stateful integration-centric processes (ICPs) are different in this regard. They typically care for more than one message and the relationship between them. A typical example is the Aggregator (enterprise integration pattern) that collects several messages until a certain end criterion is met. Once the condition is fulfilled, all the collected messages are sent in one package. The messages themselves represent the state as they have to be kept within the process while waiting for more messages until the end condition for collecting is reached.

The Demo Business Processes

To demonstrate the monitoring functionality of SAP Process Orchestration I am using the approval process depicted in Figure 1. It shows the BPMN model for an order approval process within Process Composer, the process-modeling environment of the SAP NetWeaver Developer Studio (NWDS). The step named Send Order Request is important as it forwards the order to a stateful integration process. The service contract I was talking about above is applied here. It is reflected by a simple WSDL description shown in Figure 2. As you can see from Figure 2 the service interface was created in the Enterprise Services Repository (ESR) and has the Category Outbound assigned to it. It is in essence an asynchronous interface. The interface contains only one operation shown in the upper right area of the screen. The name of the operation is identical to the interface name and consists of all the fields the process hands over to the stateful ICP. Figure 3 shows the list of order fields that make up the operation. With that I have completed the main process of the process-driven application as well as the service contract.

The Stateful ICP

As outlined above, the service contract has to be implemented by the service contract implementation layer. In my example this is done by the stateful ICP depicted in Figure 4. Both the start event () as well as the intermediate message event () are assigned to the same trigger, which represents the interface this process is waiting for and which points to the Order_Async interface described above. Therefore, the interface is being used twice: as configuration for the Send Order Request step of Figure 1 and for both events in Figure 4. This ensures the direct communication between the two processes. Obviously the process in Figure 4 loops as many types, as the end criterion checked at the exclusive gateway () is not evaluated to true. In my simple example I wait for two messages to arrive until the Send to Systems step is reached. Here the process is handing over the collected messages to the stateless ICP, which takes care of forwarding the package to the respective system or systems. The overview of the interface which is configured for the Send to Systems task as well as the associated data structure are depicted in Figures 5 and 6 respectively. The message is comprised of a list of orders collected by the stateful integration process. Obviously it is again an Outbound interface (Figure 5) containing several orders (Figure 6). As you can see from the Details section of Figure 6 the orders attribute points to the order data type shown in Figure 3. Note the Max Occurs field in Figure 6 is set to unbounded, reflected by the asterisk (*), representing a list of order entries.

The Stateless ICP: Message Handling within SAP PI

As I outlined above, the message is forwarded to SAP PI, which is also part of the SAP Process Orchestration bundle. Its task is to forward the aggregated messages to one or more back-end systems. The configuration of message handling within SAP PI is done using the new SAP PI Designer perspective within NWDS. Figure 7 shows the integration flow caring for the collected message. The integration flow represents the stateless ICP and cares for transferring the message containing the collected orders from the sender business component ICP on the left to the receiver business component FileSystem on the right. The message is sent via the SOAP adapter and received via the File adapter (compare the annotations attached to the respective dashed arrows on the left and right of Figure 7). Note that for this particular integration flow no additional steps such as receiver determination, interface determination, or mapping need to be executed by SAP PI during run time. that is because there are no activities modeled between the integration flow’s start event () and end event (). However, the configuration of the sender business component, depicted as the ICP pool on the far left of Figure 7, is important. It represents the sender in my scenario and it is assigned exactly the same interface as for the Send to Systems step of Figure 4. This is a prerequisite for the handover of messages from the BPM engine to SAP PI. In order to track the message flow from the stateful ICP process to SAP PI, another setting is crucial. It is part of the configuration of the ICP business component. Double-click the pool’s name (ICP) to open the configuration shown in Figure 8. The Business Process check box instructs the SAP Process Orchestration environment to track messages leaving the process and reaching SAP PI for monitoring purposes. Without this setting it is impossible to track the complete message sequence from the source (the business process of the process-driven application) to the target (the respective external systems) as is explained in the following sections.

Running the Scenario

Now that I have configured the complete scenario, I’ll take a closer look at the monitoring capabilities of SAP Process Orchestration. What is happening when I execute the main process of Figure 1? Obviously an order has to be entered, which is approved by a respective approver. After approval, the process reaches the Send Order Request step (shown in Figure 1). At that point the BPM engine hands over the message to the stateful ICP of Figure 4. As no instance of this particular process is running yet, the BPM engine automatically starts a new process instance. After instantiation it reaches the gateway named All Msgs.? checking for the loop’s termination condition. As I’ve described above, the process currently waits for two messages to arrive before it completes. Hence, it continues downstream to the intermediate message event named Wait 4 Msg. To release the process from the intermediate message event, you have to start the order process for a second time. After approving the newly entered order, it again forwards a message to the stateful ICP. As an instance at this time is already running, it forwards the message to the waiting instance at the intermediate message event. The evaluation of the end criterion this time indicates the finalization of the loop. Hence, the process reaches the Send to Systems step (shown in Figure 4). Now the message is handed over to the stateless ICP executed by SAP PI, which simply stores the collected message in the file system (compare Figure 7, pool and message flow, on the far right).

Monitoring the Whole Message Flow End-To-End: Forward Chaining

The question is, how can the message flows be tracked—forward and backward? This is especially important in critical situations when, for example, a message cannot be delivered to back-end systems or a process becomes stuck. In those cases you want to find out under which circumstances the error occurred: From where was a message sent or which business process caused the stateful ICP to start? Hence, forward/backward navigation capabilities for efficiently identifying the root cause of a problematic situation are crucial. I first start with the forward-tracking capabilities of SAP Process Orchestration. Open the SAP NWA via the URL https://<server>:<port>/nwa and navigate to Operations > Processes and Tasks > Manage Processes. The Process Monitor opens. To search for completed processes, switch to the advanced mode of the Process Monitor by clicking the Advanced button in the upper right corner of the screen (Figure 9). As search entries I recommend you set the Status field to Completed and the Completed From/To field to the current date (see Figure 10 for details). Finally click the Go button to start the search. You get a list of all the process instances that have been completed on the requested day. The length of the list depends on the activities in your system. For my example you should find at least the three entries shown in Figure 11. You can identify the two finished order processes (SPJ_OrderHandling) and the one completed stateful ICP (SPJ_ICP). The question is: How can you find out which process received a message from one of the order processes? To find this out select one of the order process entries, click the Show button,  and then select Related Receiver Processes from the drop-down options (compare Figure 11). Using this command the monitoring environment searches for all process instances that have received a message from the currently selected instance. In my example this is only the stateful ICP named SPJ_ICP. The result of the search is shown in Figure 12. From this process instance you can now drill down to the messages that have been sent to the stateless ICP represented by the integration flow of Figure 7 that was finally executed by SAP PI. By inspecting the Details tab beneath the search result table more closely, you can identify a link named Show Related PI Messages. This link is activated only because the Business Process check box was set during the configuration of the associated business component (Figure 8). Because of this you can now navigate directly from the current process instance to the associated messages in SAP PI’s Message Monitor. The result looks like the one depicted in Figure 13. You can easily identify the sender component (ICP) and the receiver component (FileSystem). If necessary you can further analyze the message’s content as well as the message log. With this you have learned how to navigate from the originating business process down to the message level.

Monitoring the Whole Message Flow End-To-End: Backward Chaining

The next question that comes up is whether it is also possible to track the whole message flow backward. The answer is yes. The starting point this time is the SAP PI message, and you want to find out from where this message was originally sent. In the Message Details section in Figure 13 open the Related objects tab and you see a link named BPM Manage Processes, which is shown in Figure 14. By following this link you navigate back to the actual sender of the currently selected message. By no surprise you are back in the Process Monitor showing the process instance SPJ-ICP as the responsible sender of the message (Figure 15). However, you don’t have to stop here. You can navigate further up the hierarchy to the processes that either caused the current process instance to start or sent a message to the stateful ICPs intermediate message event. You again make use of the Show drop-down button. However, this time select the Related Sender Processes from the options (Figure 15). As a result you end up on the highest level of the chain, the related order processes (Figure 16). As the stateful ICP collected and aggregated two messages, you also see two associated order processes.

Process-Driven Approach

In this article you have learned how to structure applications based on more sophisticated business processes following the process-driven approach. That approach is characterized by separating the overall functional requirements such as business processes, stateful integration processes, and stateless message handling processes into several dedicated layers. Obviously this comes with an increased demand for integrated monitoring capabilities that allow:

• Bidirectional navigation between SAP BPM processes based on the messages being exchanged between them.
• Bidirectional navigation between SAP BPM processes and SAP PI messages that have been sent or received by the BPM processes.

All these capabilities are enhancing the monitoring capabilities of SAP NWA allowing for efficient and effective analysis of erroneous situations. The described features are available as of SAP Process Orchestration 7.31 SP 12 or SAP Process Orchestration 7.4 SP 7.