Use Patterns in SAP Exchange Infrastructure to Process Leapfrog Through Initial Development

If you want to easily and efficiently develop a cross-component process (either a combination of SAP and non-SAP components or, alternatively, a combination of SAP business applications complete with the scenario interfaces delivered by SAP), you'll want to take a message-oriented approach, starting with interfaces defined in the SAP Exchange Infrastructure's Integration Repository.1 Let's face it, if 60% of the integration costs are associated with mappings and the like, then it makes good business sense, when developing business processes, to take advantage of the predefined interfaces available to you.2 Of course, if any interfaces are missing, then they can easily be added to the central repository and reused in other business processes or message exchanges. But by approaching the process design with a view toward reducing the number of interfaces configured, you will gain the most control over the complete system landscape and the most cost-effective design of the executable processes.

In addition to using predefined interfaces, you can also turbo-drive the whole development cycle by using one of the predelivered SAP Exchange Infrastructure (SAP XI) patterns. Patterns describe typical situations that occur in message-based processes. For example, you may want to serialize a sequence of messages that arrive in an irregular order from various components and partners so that, once all have been received, you can feed them in the correct order into another system, such as a data warehousing component (see Figure 1).

Figure 1

Using the Predelivered SAP XI Synchronization Pattern to Jump-Start Your Development Cycle

You may still be asking yourself: Why not write some code inside the data warehousing component to perform this sequencing? Remember, this is an exercise in reducing costs by reducing custom coding — your programmed interface would be lost as soon as the data warehousing component is replaced by another. By uniting business process management with a central repository of interfaces, you are getting the best of both worlds. In other words, the process control in the SAP NetWeaver platform takes you well beyond pure Enterprise Application Integration (EAI).

The optimal starting point in configuring such processes is to select the most appropriate pattern from the SAP namespace of the Integration Repository (e.g., http://sap.com/xi/XI/ System/patterns...). If you cannot find an appropriate pattern, then there is nothing to stop you from modeling your process from scratch. The focus of this article, however, is to show how these patterns significantly reduce development and configuration costs. Therefore, I'll omit descriptions of other significant business process management (BPM) features.

Once you have selected your pattern, it will be displayed in the Process Editor, as shown in Figure 2. For the purposes of this article, I have chosen the serialization pattern, in which a certain number of messages are received in random order and are finally transmitted in a preconfigured sequence as described above. This is typical of integrating multiple components (business applications) with a single component, where this single component expects to receive a sequence of messages in a fixed order and cannot handle the messages when they arrive in an unexpected order. This may be easy to model when these incoming messages originate from one single component, but experience shows that, over time, the system and partner landscapes are likely to evolve. In other words, even if the relevant messages did at one time originate sequentially from one system, they are likely to originate from different systems in a random order in a year or two's time.

Figure 2

The Process Editor Graphically Depicts the Serialization Pattern

From the SAP namespace of the Integration Repository, you can copy and configure the pattern, enhancing it later to take into account the intricacies of the business process that you are modeling.

Although this serialization pattern is preconfigured to expect to receive three messages that need to be serialized, it can easily be enhanced to serialize any number of messages.3 The three parallel branches in Figure 2 each refer to one of the expected messages. Each of the three branches contains a receive step, which is flagged to either trigger a fresh process instance (if no process instance is already waiting to receive this message) or continue down that branch of the existing process instance (if this process instance has already been spawned).

Simplicity Itself: How Patterns Ease Your Coding Efforts

To delve into the sophistication hidden behind this simple pattern and see how much custom coding has been avoided, let's study a specific example in which three messages are serialized and fed to a data warehousing system.

Suppose the three messages that we are waiting for are:

"order confirmed" (from a supplier's software component)

"goods paid for" (from one of our software components)

"goods delivered" (from another software component)

Normally we would expect this to be the order of the messages, which is what a data warehousing system would expect.

However, real life being what it is, the messages arrive in an unforeseeable order. (Consider a call for an emergency order — you don't want any delays, so it gets keyed into the system later.) So, we need to design our patterns-based process to serialize the messages before relaying them to the data warehouse component. In other words, sometimes message 1 triggers the process, and the process then waits for messages 2 and 3. But sometimes message 2 or even 3 triggers the process. Put another way, sometimes message 1 is a trigger, and sometimes it is simply being waited for in an existing process instance.

How would you normally code this? It would be tricky — and even trickier to adapt so that it can take into account other typical business process management features such as deadline handling, either on the message level or on the block level for the complete parallel branch. But block-oriented deadline handling is just one of the standard features that SAP XI 3.0 offers, so deadline handling is easily deployed to enhance the basic pattern without having to resort to complex code development. The same is true for exception handling. The exceptions are offered based on the graphical blocks of the process definition, making the process logic easily manageable and transparent.

This example gives you an idea of the amount of development work such a simple pattern will save you. The pattern offers far more than three parallel steps in a standard workflow, and it has all sorts of sophistication built in so that it can be used in real business environments — plus the benefit of online documentation for each of the patterns delivered.

Of course, some customizing is necessary, but as you will see next, even that will take advantage of the interfaces defined within the Integration Repository.

Maintaining the Properties of a Pattern

The first properties that you have to maintain are those needed to map the structure of the message received in the first branch of the process. This has two purposes: First, you may want to use elements of the message later to control the process flow (such as by adding a conditional fork), and second, you will need to match the three incoming messages to each other so that you don't mix up message 1 "order for 10000 barrels of crude oil confirmed" with message 2 "10 kg of platinum goods received."

The method of matching different messages with each other is called correlation. So, as well as assigning a message structure to the message-received step, you also define a correlation. The correlation picks out the significant elements of the message and matches them to the corresponding elements of the messages in the other branches.

In the simplest case, there is only one element of the message to be correlated, and it is identical in all three messages (such as my-order-number). But of course, in practice — especially if external partners are involved — this will be more sophisticated and may involve correlating a different number of elements with different names from each of the three messages (for example, a match between a combination of order ID and product category).

However, even in complex cases, this simple task avoids custom coding in the business process definition. The correlation that you define is valid for the complete process, so it can be used in the dispatching of the messages in the final phase of the process.4

Other Patterns Available in SAP XI 3.0

We have looked at just one example of a pattern delivered with SAP XI 3.0. Other examples include:

Multicasting — sending a message to several partners and waiting for the responses, either all at once or one after another

Collecting messages until a certain time limit is reached — for example, collecting all messages until midnight every Sunday and then forwarding a summary to another plant

Collecting messages until the total number stated within the first message is reached — for example, when line items from an order are processed by different components and collected after processing

This is just a sampling of available patterns, and there are also many
variations of the basic patterns, such as time-dependent variations or count-dependent variations.

These patterns can even be combined with one another to create sophisticated processes that remain flexible despite their complexity, thanks to the direct integration between the Integration Repository and Business Process Management, which run on the same Integration Server. If you want even more detailed control of the process, you can drag and drop new individual steps from the Integration Repository into the pattern-based process.

Keeping the Processes Up and Running in a Rapidly Changing System Landscape

As you can see back in Figure 1, the last phase of the process dispatches the three messages one after the other in the correct order. Of course, the message dispatching offers a choice of endpoints, such as adapters and Java or ABAP proxies, as well as the mapping programs to transform the sending interface to the receiving interfaces.

Our example assumes that there is one receiving target for the messages (the data warehousing system), but what if, in another process, the target depends on the content of the message? An example of this is when two data warehousing components5 are used, and the data warehouse to receive the message depends on the type of goods ordered. In reality, this is a common occurrence, and a very dynamic one, too, as new business units are acquired or existing IT components merged. Reading this information from the Integration Repository rather than hard coding it into the business process definition is a huge advantage.

Additional Control

It is out of the scope of this article to describe all the additional control that you can model in a process, but it is worth describing the transform step in more detail to round up this particular example.

In our data warehousing scenario, suppose that a new data warehousing component is added to the system landscape and expects to be fed a single message containing cumulative information on the process (the distillation of the three messages) instead of three separate messages. You can rely on your SAP XI software to handle this, too, by adding a transform step into the last part of the process. The transform step will merge the three messages into one single message with a new structure.

Transform steps are very flexible, allowing a message to be split into multiple messages, several messages to be merged together, or a message to simply be transformed into a message of a different structure.

Conclusion

This article by no means explains all the features available with SAP XI 3.0's new business process management capabilities, but it should give you an idea of how much sophistication is customizable. The process modeling is simplified even further using patterns to facilitate the automation of real-world business processes in heterogeneous system and business landscapes, saving time and resources in your coding efforts.

3 There is a separate pattern if the number of messages varies from case to case.

4 For more information on correlation, see my column in the January-March 2003 issue of SAP Insider (www.SAPinsider.com).

5 Maybe even from different software vendors.

Alan Rickayzen has been with SAP since 1992 and in data processing since 1988. Since 1995, he has been performing development work as well as process technology consulting for various major US customers and, as a result, has amassed a good deal of technical knowledge in collaborative process technology. Alan Rickayzen is co-author of the book Practical Workflow for SAP, available at http://store.sapinsider.wispubs.com/products/H3057, and may be contacted at alan.rickayzen@sap.com.