In the last issue, I looked at the importance of events, comparing them to the radio waves traveling through the ether. In this issue, we’ll look at how SAP propagates the effects of a business event between systems, to prevent the impact of an event stopping at the IT system boundary. In a large system landscape, the creation of a new customer record in, say, a CRM system, will affect other systems — such as a non-SAP financials system — which will, in turn, create ripples that return back to the original CRM system as well as systems elsewhere. This event propagation is the realm of Business Process Management (BPM),1 which is handled by SAP, with particular attention to total cost of ownership, in the SAP Exchange Infrastructure. So it is well worth revisiting this subject in more detail.2
It’s fitting that this column — newly renamed to reflect SAP’s focus on both workflow and business processes beyond a single system landscape — also unveils the first major building block of SAP’s new BPM suite. And no, it’s not SAP’s new process modeler, the Business Process Designer — although that is previewed here and worthy of an article in its own right. No, here I will zero in on a far more fundamental technology for driving multi-system, end-to-end, automated business processes: message-handling in the process context.
Message-handling is the key capability of the BPM engine in the SAP Exchange Infrastructure, which distinguishes it from workflow. By driving a business process using messages rather than direct interfaces, you have a more flexible process made up of more loosely coupled steps. In a nutshell, this makes it easier to:
- Incorporate external partners into the process, allowing your process to reach all corners of the business universe.
- Swap or upgrade components at a later time with minimum disruption. In other words, the total cost of ownership (TCO) is reduced, and you can make these changes far more often and far more quickly.
- Ensure smooth-running processes even when systems are temporarily unavailable, leading to reduced administration costs and even further reductions in TCO.
Message-handling differs radically from the object-oriented model of workflow, which assumes the ability to reach out via an object’s attributes to query additional information. True, this object-oriented approach is very powerful and one of the most attractive features of WebFlow, SAP’s workflow tool. But in the SAP Exchange Infrastructure environment, where a process might span several non-SAP systems, you want to avoid making assumptions about what can be extracted from those systems. A message carries with it all the necessary information, taking a “black box” approach for maximum compatibility with whatever system might be sending or receiving the message.
|Let’s take a simple example to illustrate possible approaches to designing business processes. Suppose you manufacture a material that, in certain countries, faces special export regulations for how the material is handled. You need an automated process to take in the order and ensure that it is properly and legally shipped to its destination.
If the complete process takes place within a single component, like CRM, you can automate it with workflow. Your workflow will receive an event within an SAP CRM system signaling the creation of a customer order. The workflow contains a reference to the customer order in the form of an object reference. The event triggers the workflow, which can then query the contents of the order to determine which path to take, which information to display, or which method to perform. If the ship-to address falls under the special export regulations, the workflow will start a sub-process to deal with this. This means that at several points in the process, the workflow engine queries the business object “customer order” to determine which country is being shipped to. Using the object-reference to query other attributes is a good ploy because all the information about this object is available within this single system so no external interfaces are needed and there are no problems with performance or system availability.
In this SAP Exchange Infrastructure scenario, the system handling the material management (e.g., MM) is not the same component that handles incoming orders (CRM) or transport requests (SCM). So once it is established that an order has been placed for the material that might require special handling, the process must know which country is being shipped to. To save one system from having to query another system (remember, each interface costs money to build) this message already contains information about the destination. Of course, the incoming messages can also trigger micro-processes in the form of workflows within the different systems, especially when workflow templates are delivered as part of the component or when local organizational management and user management is needed.
Reduce Expensive Interfaces in Your Business Processes
One of the greatest challenges in a distributed environment of heterogeneous systems is the sheer number of calls required between systems (interfaces). These not only add significant costs to the landscape, but also make it very rigid. A message-based approach reduces the number of point-to-point interfaces needed (see Figure 1).
||Comparing Interfaces to Messaging
To avoid any unnecessary, “expensive” interfaces, the message will contain a great deal of data, which is then available for reuse in any process or system. To keep the strain on the system to a minimum, the SAP Exchange Infrastructure keeps a small cache of the relevant message details. When you design a process, you define the relevant message elements using an Xpath description3 to generate a cached “skeleton” of the original message. These message elements can also be used in your process definition to determine splits, joins, and conditions in your process. The Business Process Modeler will help you with this (discussed in greater detail below).
Enhance Flexibility for Handling Process Information — No Matter What the Source
In addition to reducing the number of interfaces and remote calls, there is an even more significant effect of using messages — not only are you better prepared for handling information from within your landscape, but your processes are now better equipped to gather information coming in from outside sources. A message might originate in systems of your partners, vendors, or customers, and you cannot always control the design of these messages. The real goal is not to dictate how the information comes in, but to be as flexible as possible in reacting to this information, regardless of the source.
For instance, there are a variety of messages that might be applicable to a single process. The messages relating to an order might include:
- Order Placed
- Order Cancelled
- Order Dispatched
- Goods Received
What’s more, these names could vary slightly, depending on their source. With BPM, you need to be able to trigger new processes based on these messages — but you also have to match these messages with processes that are already up and running, irrespective of the message type or the originating system. Relating the messages to already running process instances is the tricky part. This is handled in the SAP Exchange Infrastructure by the correlation manager, which is new as of Release 2.0.
The correlation manager allows you to specify key fields in the different message types and designate them to a single, semantically equivalent element. The correlation manager “listens” for these messages and dispatches them to the relevant process instances when they arrive. By assigning message types centrally to a reusable correlation rule, you are, once again, cutting down the maintenance requirements and making it easier to change the processes or landscape in which the processes run (see Figure 2).
||Correlating Messages for Order 123abc
Here’s how this works in practice. In a process, if a step waits for the Goods Received message, it would look for a message that fulfills both these criteria:
- It is of the type GOODS_ RECEIVED.
- It matches (i.e., correlates to) this particular process instance based on the correlation rule ORDER_CORR, which, in turn, is based on the message content of the CUSTOMER_ORDER message (i.e., order 123abc).
This solves the problem of how to relate the message GOODS_RECEIVED to the process dealing with order 123abc.
In other words, the GOODS_RECEIVED message is passed to this particular process instance because, according to the correlation rule, ORDER_CORR, MY_ORDER matches OUR_REF both in value and in semantics in the CUSTOMER_ORDER message (see Figure 3). At the beginning of this article I explained how the SAP Exchange Infrastructure can reduce costs by reducing the number of system interfaces. In this example involving these three simple message types, you can see how a single correlation rule eliminates the need to create six separate coding routines.4
||Business Process Correlating a Customer Order with Goods Received Message from the Warehouse System
Figure 4 shows you how this process is defined with the Business Process Modeler, SAP’s new browser-based modeler. Notice that the individual elements of the message do not need to be specified, because they are already taken care of in the correlation rule, so even in this one single step we can take advantage of the reuse of the correlation rule.
||Business Process Modeler
You may be wondering, why not include the process ID itself in the Goods Received message? After all, if the Goods Received message carried the ID of the process instance that was dealing with the order, there would be no need for this correlation rule in the first place — the message could be sent straight to the necessary process instance.
The answer to this question is rooted in customer experience. Simply put, real life is just too complicated for this:
- Warehousing may be handled by a separate system or in a separate location from the component that created the order. Typically an SCM system will handle the warehousing and a CRM system handles the incoming order. The warehousing system will not even be aware that an automated process is handling the orders. The process ID is unknown.
- In the real world, you cannot force your partners or customers to design the messages according to your specifications. Bigger companies, in particular, will churn out their messages as they deem fit, leaving you to adapt. This reliance on another partner to include a consistent process ID throughout removes the flexibility needed to move a message across multiple processes.
The correlation manager, part of the SAP Exchange Infrastructure, is the tool that allows you to do this in a simple and reusable way.
For More Information
The correlation manager is available as part of the SAP Exchange Infrastructure. For more information on the SAP Exchange Infrastructure, visit http://service.sap.com/xi.