This section will provide an example of a business process modeled with BPMN. The process that will be described is a process that BPMI has been using to develop this notation. It is a process for resolving issues through e-mail votes (see See E-Mail Voting Process.). This Process is small, but fairly complex and will provide examples for many of the features of BPMN. There are some unusual features of this business process, such as infinite loops. Although not a typical process, it will help illustrate that BPMN can handle simple and unusual business processes and still be easily understandable for readers of the Diagram. The sections below will isolate segments of the Process and highlight the modeling features as the workings of the Process is described. In addition, samples of BPEL4WS code are provided to demonstrate how a BPMN Diagram maps to BPEL4WS.
The Process has a point of view that is from the perspective of the manager of the Issues List and the discussion around this list. From that point of view, the voting members of the working group are considered as external Participants who will be communicated with by messages (shown as Message Flow).
The Process starts with Timer Start Event that is set to trigger the Process every Friday (see See The Start of the Process.).
The Issue List Manager will review the list and determine if there are any issues that are ready for going through the discussion and voting cycle. Then a Decision must be made. If there are no issues ready, then the Process is over for that week--to be taken up again the following week. If there are issues ready, then the Process will continue with the discussion cycle. The "Discussion Cycle" Sub-Process is the first activity after the "Any issues ready?" Decision and this Sub-Process has two incoming Sequence Flow, one of which originates from a downstream Decision and is thus part of a loop. It is one of a set of five complex loops that exist in the Process. The contents of the "Discussion Cycle" Sub-Process and the activities that follow will be described below.
BPEL4WS processes must begin with a receive activity for instantiation (i.e., it "bootstraps" itself). The "E-Mail Voting Process" is scheduled to start every Friday as shown by the Timer Start Event. Therefore, an additional Process will have to be created and implemented that will run indefinitely and will send a starting message with the list of Issues to the "E-Mail Voting Process" every Friday. See The Ongoing Starter Process. shows this Process as starting that the beginning of the Working Group and continuing until the end of the Working Group. Even this Process needs a message to be sent to it to signal the start of the Working Group. There may be another Process defined that sends that message, but that Process is not shown here. In addition, the mapping from the Starter Process to BPEL4WS is not shown here.
The modeler-defined properties of the Process will be placed in a BPEL4WS variables element named "processData." The same variables element will be used in all derived processes in this example.
Note that empty does not have any corresponding activity in the BPMN Diagram, but is derived through the Diagram configuration.
This is done because the switch is a block structure and needs a definitive ending point and since the otherwise is connected to the end of the Process, then the end of the Process is the ending point that the case must use. The actual activities that make up the rest of the Process will be distributed among a set of BPEL4WS processes instead of all being within the case. The case will only contain an invoke that will call another process (as a web service). The distribution of the Process activities is due to the overall Diagram configuration that includes three upstream Sequence Flow that define some interleaving loops.
If the loop shown in this section of the model were merely a simple loop, and perhaps the only loop, then a BPEL4WS while would be used to handle the loop. In this situation, though, the looping is handled through a set of derived processes that are accessed by invoking them (as a web service). There would no specific Diagram element to represent these derived processes; indeed, a modeler would not want to create a set of related Processes to handle complex looping. While an execution engine can easily handle a complex set of language documents and elements, a business person developing and monitoring this process will want to see the Process in an easy-to-read format (such as BPMN) that contains the information in a more comprehensive, less distributed format. See Interleaved Loops. for details about how interleaved loops are mapped to BPEL4WS.
In this example, all derived processes will be named "[(target of loop) activity.Name]_Derived_Process." Any naming scheme will work as long as all the processes have unique names.
We shall see that later in the Process the same process is accessed through another invoke, marking the source of the loop.
All the sub-processes and derived processes in the BPEL4WS documents must be started with the receive of a message and then a reply to send a message back to the calling process.
The "Discussion Cycle" Sub-Process shown in See The Start of the Process. will continue the sequence (after the instantiating receive) for the "Discussion_Cycle_Derived_Process" process.
The "Discussion Cycle" Process has a loop marker. In this situation, the looping mechanism is simple. The attributes of the Sub-Process will tell us the details. The "Discussion Cycle" Sub-Process's relevant attributes are: LoopType: "Standard"; LoopCondition: DiscussionOver = "FALSE"; and TestTime: "After."
The default value for the "DiscussionOver" property is False, thus an activity within the Sub-Process will have to change it to True before the while loop is over. The logical opposite of the expression that is shown in the Sub-Process attributes is used since the EvaluationCondition property is "after." However, a while will test the condition prior to running the activity within. This means that to insure that the activity is always performed at least once (to mimic the behavior of an "until") a LoopCounter variable will always be added to a the while condition for an BPMN activity that has its TestTime attribute set to "After."
We will look into the details of the "Discussion Cycle" Sub-Process See The First Sub-Process..
See BPEL4WS Sample for Beginning of E-Mail Voting Process.See BPEL4WS Sample for Beginning of E-Mail Voting Process. displays some sample BPEL4WS code that reflects the portion of the Process that was just discussed and is shown in See The Start of the Process..
See "Discussion Cycle" Sub-Process Details. shows the details of the "Discussion Cycle" as an Expanded Sub-Process.
The Sub-Process starts of with a Task for the Issue List Manager to send an e-mail to the working group that a set of Issues are now open for discussion through the working group's message board. Since this Task sends a message to an outside Participant (the working group members), an outgoing Message Flow is seen from the "Discussion Cycle" Sub-Process to the "Voting Members" Pool in See E-Mail Voting Process.. Basically, the working group will be discussing the issues for one week and proposing additional solutions to the issues. After the first Task, three separate parallel paths are followed, which are synchronized downstream. This is shown by the three outgoing Sequence Flow for that activity.
The top parallel path in the figure starts with a long-running Task, "Moderate E-mail Discussion," that has a Timer Intermediate Event attached to its boundary. Although the "Moderate E-Mail Discussion" Task will never actually be completed normally in this model, there must be an outgoing Sequence Flow for the Task since Start and End Events are being used within the Process. This Sequence Flow will merged with the Sequence Flow that comes from the Timer Intermediate Event. A merging Exclusive Gateway is used in this situation because the next object is a joining Parallel Gateway (the diamond with the cross in the center) that is used to synchronize the three parallel paths. If the merging Gateway was not used and both Sequence Flow connected to the joining Gateway, the Process would have been stuck at the joining Gateway that would wait for a Token to arrive from each of the incoming Sequence Flow.
The middle parallel path of the fork contains an Intermediate Event and a Task. A Timer Intermediate Event used in the middle of the Process flow (not attached to the boundary of an activity) will cause a delay. This delay is set to 6 days. The "E-Mail Discussion Deadline Warning" Task will follow. Again, since this Task sends a message to an outside Participant, an outgoing Message Flow is seen from the "Discussion Cycle" Sub-Process to the "Voting Members" Pool in See E-Mail Voting Process..
The bottom parallel path of the fork contains more than one object, first of which is Task where the issue list manager checks the calendar to see if there is a conference call this week. The output of the Task will be an update to the variable "ConCall," which will be true or false. After the Task, an Exclusive Gateway with its two Gates follows. The Gate for labeled "default" Flow directly to an merging Exclusive Gateway, for the same reason as in the top parallel path. The Gate for the "Yes" Sequence Flow will have a condition that checks the value of the "ConCall" variable (set in the previous Task) to see if there will be a conference call during the coming week. If so, the Timer Intermediate Event indicates delay, since all conference calls for the working group start at 9am PDT on Thursdays. The Task for moderating the conference call follows the delay, which is followed the merging Gateway.
The merging Gateways in the top and bottom paths and the "E-Mail Discussion Deadline Warning" Task all flow into a joining Gateway. This Gateway waits for all three paths to complete before the Process Flow to the next Task, "Evaluate Discussion Progress." The issue list manager will review the status of the issues and the discussions during the past week and decide if the discussions are over. The DiscussionOver variable will be set to TRUE or FALSE, depending on this evaluation. If the variable is set to FALSE, then the whole Sub-Process will be repeated, since it has looping set and the loop condition will test the DiscussionOver variable.
Because it is a Sub-Process within a higher-level Process (the "E-Mail Voting" Process), it is invoked from the higher-level Process. The invoke sends a message from one (higher-level) BPEL4WS process to the other (lower-level) process for instantiation.
The receive and reply are not actually shown in the BPMN Diagram, but it is derived from this invoke relationship of "Discussion Cycle" Process being a Sub-Process to the "E-Mail Voting" Process.
The Diagrams elements of See "Discussion Cycle" Sub-Process Details. will determine the remaining activity(ies) of the sequence.
The catch of a faultHandlers will be triggered by the fault generated by the above throw. Since the Timer Intermediate Event leads direction to the Exclusive Gateway, there is no specific activity that must be performed in response the to time-out. The main purpose is to exit the Task. Thus,
In these situations, the sequence will continue until there is a location in the Diagram where there are multiple incoming Sequence Flow. When more than one Sequence Flow converge it marks the end of a BPEL4WS structure (as determined by structures that have been created by upstream objects). In this case, the Parallel Gateway also marks the end of the higher-level flow. The sequence will be listed in the higher-level flow without a source sub-element. This means that the sequence will be instantiated when the higher-level flow begins since it has no dependencies on any other activity. The sequence will have two activities:
This middle path of the fork could have been configured in BPEL4WS without a sequence and with links instead. This is an example of a situation where a BPMN configuration may derive two possible BPEL4WS configurations. Since both BPEL4WS configurations will handle the appropriate behavior, it is up to the implementation of the BPMN to BPEL4WS derivation to determine which configuration will be used. BPMN does not provide any specific recommendation in these situations. However, the lower parallel path of the Process can also be modeled with a sequence or with links, and, to show how links would be used, this section of the Process will be mapped to elements in a flow that have dependencies specified by links.
The lower parallel path of the fork has a number of objects and, as just described above, will be mapped to BPEL4WS elements connected with links. The path also contains a Decision, which can map to a switch, as will happen later in the process, but in this situation the Decision is mapped to links controlled by transitionConditions.
The invoke will be listed in the higher-level flow without a source sub-element. This means that the invoke will be instantiated when the higher-level flow begins since it has no dependencies on any other activity. The remaining elements of the higher-level flow will have a source element. Thus, they will not be instantiated until the source of the link has completed.
As mentioned above, the Parallel Gateway marks the end of the flow.
Finally, there will be a reply at the end of the sequence that corresponds to the initial receive and lets the parent process know that the (sub) process has been completed.
See BPEL4WS Sample of "Discussion Cycle" Sub-Process Details. displays some sample BPEL4WS code that reflects the portion of the Process as described above and shown in See "Discussion Cycle" Sub-Process Details..
See "Collect Votes" Sub-Process Details. shows the next section of the Process, which includes the expanded details of the "Collect Votes" Sub-Process.
This part of the process starts out with a Task for the issue list manager to send out an e-mail to announce to the working group, and the voting members in particular, which lets them know that the issues are now ready for voting. Since this Task sends a message to an outside Participant (the working group members), an outgoing Message Flow is seen from the "Announce Issues" Task to the "Voting Members" Pool in See E-Mail Voting Process.. This Task is also a target for one of the complex loops in the Process.
The "Collect Votes" Sub-Process follows the Task, and is also a target of one of the looping Sequence Flow. This Sub-Process is basically a set of four parallel paths that extend from the beginning to the end of the Sub-Process.
The first branch of the fork leads to a Decision that determines whether or not a conference call will occur during the upcoming week, after the Working Group's schedule has been checked. Basically, if there was a call last week, then there will not be a call this week and vice versa. The appropriate variable that was updated in the "Discussion Cycle" Process will be used again.
The second and third branches forks work the same way as the similar activities in the "Discussion Cycle" Sub-Process, except that the "Moderate E-Mail Discussion" Task does not have a Timer Intermediate Event attached. This is not necessary since the whole Sub-Process is interrupted after 7 days through the Intermediate Event attached to the Sub-Process boundary. The "E-Mail Vote Deadline Warning" Task sends a message to an outside Participant (the working group members), thus, an outgoing Message Flow is seen from the "Collect Votes" Sub-Process to the "Voting Members" Pool in See E-Mail Voting Process..
The fourth branch of the fork is rather unique in that the Diagram uses a loop that does not utilize a Decision. Thus, it is, as it is intended to be, an infinite loop. The policy of the working group is that voting members can vote more than once on an issue; that is, they can change their mind as many times as they want throughout the entire week. The first Task in the loop receives a message from the outside Participant (the working group members), thus, an incoming Message Flow is seen from the "Voting Members" Pool to the "Collect Votes" Sub-Process in See E-Mail Voting Process.. The Timer Intermediate Event attached to the boundary of the Sub-Process is the mechanism that will end the infinite loop, since all work inside the Sub-Process will be ended when the time-out is triggered. All the remaining work of the Process is conducted after the time-out and Flow from the Timer Intermediate Event.
See "Collect Votes" Sub-Process Details. shows that there are Two Tasks that follow the time-out. First, a Task will prepare all the voting results, then a Task will send the results to the voting members. A Document Object, "Issue Votes," is shown in the Diagram to illustrate how one might be used, but it will not map to anything in the execution languages. The remaining activities of the Process will be described in the next section.
See BPEL4WS Sample that sets up the Access for the Second Sub-Process. shows sample BPEL4WS code that defines the two derived processes.
The "Collect Votes Sub-Process is basically a set of four parallel paths that extend from the beginning to the end of the Sub-Process.
The first branch of this Sub-Process is basically the same as the upper parallel of the previous Sub-Process. An invoke, a wait, and an empty will be created. In addition, three links will be created to handle the dependencies between the elements, including the branching created by the Exclusive Gateway. See The Lower Parallel Path. for the details of the mappings.
The Timer Intermediate Event must be set up to create a fault at the appropriate time. To do this,
The Document Objects shown in the figure is not mapped into BPEL4WS. The remainder of the Process will be described in the next section.
See BPEL4WS Sample of the Second Sub-Process. shows sample BPEL4WS code that defines the "Collect Votes" Sub-Process.
See The last segment of the E-Mail Voting Process. shows the last section of the Process, which includes a complex set of Decisions and loops.
This segment of the Process continues from where the last segment left off (as described in the section above). It contains four Decisions that interact with each other and create loops to upstream activities.
The first Decision, "Did Enough Members Vote?," is necessary since two-thirds of the voting members are required to approve any solution to an issue. If less than two-thirds of the voting members cast votes, which sometimes happens, the issues can't be resolved. This Decision Flow to another Decision for both of its Alternatives. The "No" Alternative is followed by the "Have the Members been Warned?" Decision. If a voting member misses a vote, they are warned. If they miss a second vote, they lose their status as a voting member and the voting percentages are recalculate through a Task ("Reduce number of Voting Members and Recalculate Vote"). If they haven't yet been warned, then a warning is sent and the voting week is repeated.
If all issues are resolved, then the Process is done. If not, then another Decision is required. The voting is given two chances before it goes back to another cycle of discussion. The first time will see a reduction of the number of solutions to the two most popular based on the vote (more if there are ties). Some voting members will have to change their votes just because their solution is no longer valid. These two activities are placed in a Sub-Process to show how a Sub-Process without Start and End Events can be used to create a simple set of parallel activities. Informally, this is called a "parallel box." It is not a special object, but another use of Sub-Processes. For simple situations, it can be used to show a set of parallel activities without the extra clutter of a lot of Sequence Flow. In actuality, these two Tasks cannot actually be done in parallel, but they are modeled this way to highlight the optional use of Start and End Events.
After the parallel box, the flow loops back to the "Collect Votes" Sub-Process. If there already has been two cycles of voting, then the process Flow back to the "Decision Cycle" Sub-Process.
As mentioned above, the entire contents of this segment follow a Timer Intermediate Event, which means they are contained in the faultHandlers of the scope within the "Collect Votes" process.
The "No (default)" Alternative leads to a loop.
Notice that the "Issues w/o Majority?" Decision can be reached through the alternative paths from two different Decisions. This creates a situation that has two impacts on the Mapping to Execution Languages. First, it creates a section of the Process in which the Alternatives from two Decisions overlap. This is possible in a graph-structured Diagram like BPMN, but in a block-structured (and acyclic) language like BPEL4WS, these two sections cannot overlap because they have different block boundaries. This means that this section must be repeated in some way in both of the appropriate switch case activities. All these elements could be actually duplicated or they can be separated into a derived process and then invoked from the appropriate place. The later method was used in this example (see See Sample BPEL4WS code for the last section of the Process. and See Sample BPEL4WS code for derived process for repeated elements.).
The second impact of the multiple incoming Sequence Flow into the "Issues w/o Majority?" Decision has to do with how the three visible loops are created (actually there are five loops). Normally, Sequence Flow loops will map to a BPEL4WS while. If there are multiple loops in the Process they have to be physically separated or completely nested because of the block-structured nature of the BPEL4WS looping elements. The alternative paths of the Decisions cannot be mixed and still maintain the BPEL4WS blocks they way that the end of the "E-mail Voting" Process mixes the paths.
A different type of looping mechanism is required. This method requires the creation of a set of derived processes that can reference each other and also themselves. In this way, a block-structured language can simulate a set of interleaving loops (as seen in a graph-structured Diagram).
See Sample BPEL4WS code for the last section of the Process. displays the BPEL4WS code for first part of the end of the "E-Mail Voting Process."
See Sample BPEL4WS code for derived process for repeated elements. shows the BPEL4WS code for the Process from the "Issues w/o Majority?" Decision until the end of the Process or loops.
If there has already been two cycles of voting, then the process Flow back to the "Decision Cycle" Sub-Process.
See Sample BPEL4WS code for the last section of the Process. displays the BPEL4WS code for the final derived process of the "E-Mail Voting Process."