Skip to Content
You may have seen my article on workflow patterns and how we support them with our initial NetWeaver BPM 7.11 release. On the bottomline, there was a reasonably good coverage with this release, already. From a total of 43 (control-flow-related) patterns, we had full support for 30 patterns, even though some 20 patterns out of these required some extra modeling effort. For another 7 patterns, we had partial support, where some but not all of the pattern’s semantics could be reflected. And finally, there was limited support for the remaining 6 patterns.

Overview

With our second release of the NetWeaver BPM (“Galaxy”) product line (which is labelled as “7.20”), we made a big step twoards full supporting an even bigger range of workflow patterns. Most notably, we introduced support for BPMN’s:
  • Intermediate Message Events with correlation predicates,
  • Escalation End Events,
  • Embedded Subflows,
  • Multiple Instance (MI) Activities, and
  • Event-based Gateways (aka “Pick Split”)
With the addition of those shapes, many of the workflow patterns that had limited or partial support in 7.11, at best, are now supported in NetWeaver BPM 7.20. Before going into details of some selected patterns, here’s an overview of those improvements:
Pattern  NW BPM 7.11 Status  NW BPM 7.20 Status
 Sequence  fully supported
 Parallel Split  fully supported
 Synchronization  fully supported
 Exclusive Choice  fully supported
 Simple Merge  fully supported
 Multi-Choice  fully supported w/ modeling effort
 Structured Sync. Merge  fully supported w/ modeling effort
 Multi-Merge  fully supported
 Structured Discriminator  fully supported w/ modeling effort
 Arbitrary Cycles  fully supported
 Implicit Termination  fully supported
 MI w/o Synchronization  fully supported w/ modeling effort
 MI w/ a-priori DT Knowledge  fully supported w/ modeling effort
 MI w/ a-priori RT Knowledge  limited support  fully supported
 MI w/o a-priori RT Knowledge  limited support  fully supported w/ modeling effort
 Deferred Choice  partially supported  fully supported 
 Interleaved Parallel Routing  fully supported w/ modeling effort
 Milestone  fully supported w/ modeling effort
 Cancel Task  partially supported  fully supported w/ modeling effort
 Cancel Case  partially supported  fully supported w/ modeling effort
 Structured Loop  fully supported w/ modeling effort
 Recursion  limited support
 Transient Trigger  partial support  fully supported w/ modeling effort
 Persistent Trigger  partial support  fully supported w/ modeling effort
 Cancel Region  partial support
 Cancel MI Activity  fully supported w/ modeling effort
 Complete MI Activity  fully supported w/ modeling effort
 Blocking Discriminator  fully supported w/ modeling effort
 Cancelling Discriminator  fully supported w/ modeling effort
 Structured Partial Join  fully supported w/ modeling effort
 Blocking Partial Join  fully supported w/ modeling effort
 Cancelling Partial Join  fully supported w/ modeling effort
 Generalized AND-Join  fully supported
 Static Partial Join for MI  limited support  fully supported w/ modeling effort
 Cancelling Partial Join for MI  limited support  fully supported w/ modeling effort
 Dynamic Partial Join for MI  limited support  fully supported w/ modeling effort
 Local Synchronizing Merge  fully supported w/ modeling effort
 General Synchronizing Merge  limited support
 Critical Section  fully supported w/ modeling effort
 Interleaved Routing  fully supported w/ modeling effort
 Thread Merge  fully supported w/ modeling effort
 Thread Split  fully supported w/ modeling
 Explicit Termination  fully supported
On a bottomline, NetWeaver BPM 7.20 now fully supports 40 patterns, partially supports 1 pattern and has limited support for the remaining 2 patterns. The following patterns are now fully supported for the first time:
  • MI w/ a-priori RT knowledge
  • MI w/o a-priori RT knowledge
  • Deferred Choice
  • Cancel Case
  • Cancel Task
  • Transient Trigger
  • Persistent Trigger
  • Static Partial Join for MI
  • Cancelling Partial Join for MI
  • Dynamic Partial Join for MI

In the following sections, we will shed some light onto some of the patterns and explain how to implement them with the NetWeaver 7.20 feature set.

Multiple Instance Patterns

Let’s have a look into the “Multiple Instance” patterns, first. Roughly spoken, they are all about iterating over a list of line items and spawning an activity (or subflow) for any of these. Variants exist in terms of (1) when that list is being build up (at design time, at runtime _before_ the MI activity starts or while the MI activity is already running, i.e. has started processing some contained line items) and (2) how to synchronize the flows that process the individual line items upon completion.
Looping property sheet
BPMN comes with native support for “Multiple Instance” (MI) activities which is actually merely a flag that can be set on any activity (including embedded and referenced subflows). To do so, you will need to select the “Parallel For Each” option in the newly introduced “Looping” property sheet which is available for all activities. As MI activities are data-driven, you will also need to specify a list-valued expression or data object. In the example, the “tokenize” function will split up a given string (“Galaxy is cool”) at the delimiter character (” “), resulting in a list of three strings. As a result, the MI activity spawns three instances of the inner activity, each processing a unique line item. While in this case, the number of line items is actually (implicitly) known at design time, normally the list is only dynamically populated at runtime. In effect, the number of inner activities processing line items in parallel may vary.
To parameterize an inner activity (i.e., an instance of the activity working on a single line item), the “Input Mapping” property sheet provides for two extra (input) context elements: “currentCollectionItem” and “numberOfCompletedIterations”, representing the line item from the list for this inner instance, and the number of already processed items, respectively. Use these elements (in particular, the “currentCollectionItem” element) to instantiate (map to the signature of) the inner activities.
Multiple Instance activities natively implement the “Multiple Instances w/ a-priori Runtime Knowledge” pattern. And it is actually as easy as making the aforementioned settings in the “Looping” and “Input Mapping” property sheets and you are good to go. As a result, the affected activity shape is marked with three vertical lines, indicating the multiple instance characteristics:
The “{Static|Cancelling} Partial Join for Multiple Instance Activities” patterns can easily be implemented on top of “baseline” MI activities with some minor extra modeling effort. In the original “Workflow Pattern Coverage in SAP NetWeaver BPM 7.11” paper, we proposed a pattern which relies on an alternative implementation of “Multiple Instance” activities. Now having native support for the baseline pattern in NetWeaver BPM 7.20, implementing those patterns may be further simplified. The basic idea is to wrap the inner activity in a subflow (both embedded and referenced subflows will work), evaluate a condition that determines whether or not to pass on a token and  optionally also cancel the remaining inner instances (“Cancelling Partial Join for MI”, only) after the inner activity’s completion.
We make use of “Error End Events” and the newly introduced “Escalation End Events” to trigger a boundary event that is attached to the wrapper subflow. Depending on whether or not the end event is using a (non-critical) escalation event trigger or a (critical) error event trigger. In effect, the whole wrapper subflow (and all contained inner activities) will continue to run or be cancelled, thus, implementing the “static” and “cancelling” flavors of this pattern, respectively.
Please note, that BPMN do not yet natively support those multiple instance activity patterns which allow for dynamically adding line items (while some line items were already processed). While, admittedly, I consider those patterns to primarly be of an academic nature, they can still be implemented with the NetWeaver BPM 7.20 feature set. Thanks to non-cancelling “Escalation End Events”, you may model those patterns along the lines of what is proposed in my workflow patterns paper (please have a look into “Multiple Instance w/o a-priori Runtime Knowledge” and “Dynamic Partial Join for Multiple Instances” sections).

Cancellation and Force Completion Patterns

With NetWeaver BPM 7.11, cancelling a “scope” (like a subflow or task) was restricted to (1) internal stimuli or (2) implicit termination when the outer (“parent”) process/subflow was itself terminated. Otherwise cancelling or terminating a scope from outside could not be done. Thanks to “Intermediate Message Events”, those patterns are now fully supported.

Basically, the party who is cancelling (or terminating) a subflow from outside needs to call a Web Service which, in turn, is received within that subflow. Upon receiving the call, the subflow sends a token to a “Terminating End Event” or “Error End Event” to terminate or cancel itself, respectively.
Parent flow
There are a few things you need to consider, though. First of all, the service interface (aka WSDL portType) for the message event needs to be (1) asynchronous and (2) re-used by both the Automated Activity (that is performing the call) and the Intermediate Event (which is receiving the call). Secondly, that service interface needs to be “wrapped” in a “Message Event Trigger” which is a reusable artifact from the “Project Explorer” view. I will go into the details of what event triggers are used for in a separate blog posting on the newly introduced message correlation concept. And finally, you will need to spend some thoughts on security in this context. The Web Service endpoints that correspond to Intermediate Message Events are secure and require the invoking party to have the “SAP_BPM_SuperAdmin” user role.
Cancelled subflow
By default a pre-configured service user (“SAP_BPM_Service”) performs all Web Service and RFC calls (from Automated Activities). For security reasons, that service user does not have the “SAP_BPM_SuperAdmin” role. As a result, you cannot normally trigger an Intermediate Message Event from an Automated Activity. There are basically two ways to enable the aforementioned scenario. One is to manually assign the “SAP_BPM_SuperAdmin” role to the “SAP_BPM_Service” user. However, be aware that by default all NetWeaver BPM processes use this user to do Web Service and RFC calls. As a result, any other process instance could potentially send a cancellation message to the subflow.
However, in reality there are little chances that another process might interfere which is due to the fact that (1) it would need to use the very same service interface (which relates to a unique Web Service endpoint) and (2) you will typically configure a so-called “correlation condition” at the Intermediate Message Event which filters for messages that are really meant to be received in that context. The second way to have an Automated Activity successfully trigger an Intermediate Message Event is principal propagation. Again, you can expect a separate blog posting on this topic but roughly spoken, principal propagation is a concept of using the very same user that has interacted with the process in some way before (e.g., started the process, send a message to the process, or been a task processor) to authenticate successive outbound calls. Principal propagation needs to be explicitly switched on in the “General” property sheet of the process. By default, the aforementioned service user concept applies.
Principal propagation
In the example, the processor of the “Cancel subflow?” task would be used to perform the “Send cancellation message” automated activity. Again, that processor would need to have the “SAP_BPM_SuperAdmin” role to successfully perform the call and have the corresponding message received by the subflow.
Force completion (i.e., regular termination) and cancellation (erroneous abortion) of nested scopes only differs in the end event “flavors” that are being used in the subflow. That is, a “Terminating End Event” will send a token to the regular outbound edge of the subflow activity whereas an “Error End Event” triggers a boundary event that is attached to the parent flow’s subflow activity.
Cancellation patterns that affect other process fragments than subflows (“Cancel Task”, “Cancel Region”, “Cancel MI Activity”, “Complete MI Activity”) would need to be implemented by means of a wrapper subflow that contains (1) the to-be-cancelled process fragment and (2) the Intermediate Message Event – Terminating End Event (Error End Event) sequence. The process fragment would implicitly be terminated (cancelled) when the subflow ends.

Trigger Patterns

We have already implicitly used the persistent and transient trigger patterns in the aforementioned examples. Those patterns can be implemented by means of Escalation End Events”, “Boundary Events”, and “Intermediate Message Events”. The persistent and transient trigger patterns differ in whether or not events (“triggers”) that are received are queued until they can actually be consumed or not.
Intermediate Message Events provide for a “Persistent Trigger” pattern inasmuch as a process containing an “Intermediate Message Event” will queue up messages coming in on the corresponding Web Service endpoint until the process instance has terminated. In detail, a process instance may be in a state where it cannot instantly consume a message and only take that message from the queue, once the “Intermediate Message Event” element is reached. Think along the lines of a process currently processing some predecessor activity where the downstream “Intermediate Message Event” is reached at a later point in time.
In contrast, “Escalation End Events” will generate non-terminating escalation events which can only be received if there is a boundary event attached to the subflow activity which has called the subflow containing the “Escalation End Event”. If no boundary events exist that could receive that event (neither at the boundary of that subflow or somewhere up in the call stack), the escalation event is lost and will not be queued. In effect, “Escalation End Events” (in conjunction with “Boundary Events”) implement the “Transient Trigger” pattern.
To report this post you need to login first.

1 Comment

You must be Logged on to comment or reply to a post.

  1. Prasad Nutalapati
    Soren:
    I really see a lot of help in your original “work
    flow pattern coverage” article and this addendum
    to the original one.
    But these two documents still sound too academical.
    Ofcourse, the nature of the subject itself is like
    that. If there can be a small web dynpro ui project DC
    with a Rules Composer DC and a Process Composer DC
    exemplyfying each workflow pattern using a simple,
    fictitious business scenario would definitely be
    ultimate help.
    It is not easy, as it sounded or
    suggested, but still you need to ask for any thing
    to be given it to you 🙂

    Prasad Nutalapati

    (0) 

Leave a Reply