Timer Interrupt pattern with SAP NetWeaver BPM

kristiyan_marinov · ‎11-16-2012

Problem: You need to use a timer in BPM but you want it to be more flexible than "wait X amount of time"

Solution: The "timer-interrupt" pattern gives you the chance to use a regular timer yet have the flexibility to "cancel" it or force it to complete at any point in time

In this blog post I will outline how you can model around the standard timer in SAP NetWeaver BPM to provide the flexibility that your business case requires and also take a look at how this can be done in a way easy to reuse.

What's already there

Lets start by exploring what is provided by default.

The timer can be configured to go off after a specific amount of time after it has been created - either statically by specifying after how many seconds/minutes/hours/days/months/years at design time or dynamically, at runtime, by using an expression and specifying the amount of milliseconds. Lets see how we can improve on this.

Improving the standard

Since the timer is actually a kind of intermediate event (along with the intermediate message event) it can be used after an event-based choice. We have two options - combine it with another timer or with an intermediate message event. Next we'll cover the combination with another timer.

Combining a timer with a timer

This might not make sense at first but it is a valid option and has its purposes. Imagine a scenario where you have to wait the shorter amount of time between a statically defined amount (say, 5 minutes) and a dynamically calculated one at runtime. Having two timers combined with an event-based choice gives you the option to do this by using one statically configured timer and one dynamically. Refer to the screenshot below:

The event-based choice provides the "first comes first served" functionality while the two timers specify the two concrete events - dynamically calculated time or 5 miutes.

Combining a timer with an intermediate message event

This is the other option that we have and is the one which provides the most flexibility. It revolves around the concept of using a timer and an intermediate message event after an event-based split. The basic idea is "wait for the timer unless I say so". This construct gives you the full flexibility to either wait for your timer or not. You also get the chance to trigger this behavior at will, not based on a hard-coded amount of time or expression.

You either wait for the timer or send a message to the web service interface of the intermediate message event to terminate it. Simple as that.

Modeling for reuse

Now lets talk a little bit about reuse. This pattern is nice and it does provide flexibility but having it implemented everywhere in our process where we have a timer can be undesirable for several reasons:

Our process model gets complicated with too much technical details
The process model diagram gets bloated with repeated constructs of one and the same thing
We have to maintain the configuration for each use of this pattern separately, which introduces a lot of work
possibly others as well, based on the concrete situation the pattern is used in

In order to mitigate this we want something that:

Will not introduce any more "technical details" into the process diagram than necessary
Will not take too much space on it - not more than a simple timer event
Is easily configurable

And the solution is to extract this pattern construct in a separate process which can then be referenced in the original one. Lets see how this approach meets all the criteria:

Using the referenced process activity and naming it appropriately will not introduce any more unnecessary details than the timer itself
Since it is a single activity encapsulating everything and takes as much space as the timer, the diagram does not get bloated
Using the input mapping for the activity we can specify all relevant aspects that we want to configure and maintain them in one place via mappings

In order to achieve this you will need to model a service interface which will model the input of the process. An added benefit of this is that on the output of the process (a.k.a. the output of the service interface operation we use to start it) you can provide information whether the process completed because the timer was triggered or because some external event occurred.

Here's how this will look:

Now lets talk about re-usability on a whole different level. How can you reuse this not only within the same process/business step but throughout different processes with different requirements towards the timer?

Well, since intermediate message events support the concept of correlation - assessing whether a message is destined for them or not - you can use that to differentiate between uses. Here's a screenshot:

We've included a correlation id for our intermediate message event which can be any arbitrary object provided on input. We will use it to check whether the interrupt message was for our timer or not. This correlation id can be anything - the parent process id, a business data-related id or pretty much any random string that we have available.

Summary
We have explored the various options that we have to make our timers more flexible - we call this family of constructs the timer-interrupt pattern to signify its purpose. We have shown that using this pattern, you can get much more control of your timers. Also discussed was how we can model this for reuse throughout our entire project - and then used as simply as sending a message "Stop timer 3" or "Stop timer for process 1".

This of course could be extended with SAP NetWeaver Business Rules Management functionality for more complex re-usability rules and others.

Feel free to express your opinion in the comments below or ask any questions that might arise!

References

The Author

Kristiyan is part of the NetWeaver BPM Integration Projects team at SAP Labs Bulgaria. The team has years of experience developing customer-like composite applications using the SAP NetWeaver platform. Implemented scenarios are focused on Business Process Management/Process Orchestration and are targetting complex hardware environments with heavy integrations with other SAP solutions like NW MDM, NW PI, ERP and others.