XPDL and BPMN


221 XPDL and BPMN Stephen A. White, SeeBeyond, United States ABSTRACT The Business Process Modeling Notation (BPMN) specification provides a graphical notation for expressing business processes in a Business Process Diagram (BPD). The objective of BPMN is to support process management by both technical users and business users by providing a notation that is intuitive to business users yet able to represent complex process semantics. The BPMN specification also provides a mapping between the graphics of the notation to underlying the constructs of execution languages, such as BPEL4WS and Business Process Management Language (BPML). As the WfMC works with BPMI, a mapping from BPMN to XML Process Definition Language (XPDL) will also be created. INTRODUCTION The Workflow Management Coalition has been developing workflow specifi- cations for many years. These specifications are designed for the developers of workflow software products to implement solutions that are consistent, complete, and interoperable with other systems. The main focus of this paper is the specification for Interface 1, the recently completed XPDL 1.0. This specification defines how business processes are defined through modeling tools in order to be executed by a workflow en- gine. This means that if a business process is defined in XPDL through a modeling tool, then a workflow engine can execute that business process if both software tools comply with the XPDL specification. In addition, a third tool designed for monitoring business processes can also track the same business process when the XPDL definition is used in conjunction with the WfMC Interface 5 specification. Thus, XPDL and other WfMC specifications provide for the interoperability of workflow oriented software systems. Although the XPDL specification defines the process activities, how they are performed, and the sequence in which they occur, the specification does not define how the process should be visualized. Thus, the individuals who are responsible for the development, maintenance, and management of business processes may see a different representation of the same business process as the move between different software tools and systems. Large organizations may have multiple workflow environments, particularly if the organization has grown through acquisition of other organizations. Thus, it is possible the same individual may see multiple business process repre- sentations in the course of their responsibilities. This means that there is a lack of software “interoperability” from the point of view of these individu- als. Interoperability, in this sense, means that those individuals responsible for the development, maintenance, and management of business processes can see a representation of business processes in any workflow environment and instantly recognize and understand the business process without any XPDL AND BPMN 222 mental translation between notations. Such interoperability will reduce training and will reduce potential errors in the development and manage- ment of the processes. A STANDARD BUSINESS PROCESS NOTATION The need for the interoperation of business processes at the human level, in addition to the software level, can be solved with standardization of the Business Process Modeling Notation (BPMN) being developed by the Busi- ness Process Management Initiative1 (BPMI). BPMN is a flow chart modeling notation designed for use by the people who design and manage business processes. BPMN also provides a formal mapping to execution languages of BPM Systems, such as BPEL4WS and BPML. Thus, BPMN would provide a standard visualization mechanism for business processes defined in an execution optimized business process language. In 2002, BPMI and WfMC agreed to work together. As part of this agree- ment, the WfMC has accepted BPMN as a notation for XPDL and will work with BPMI to enhance BPMN to manage workflow issues that are not inher- ently handled by BPEL4WS or BPML. A mapping between BPMN and XPDL will also be created. This paper is the first look at the relationship between XPDL and BPMN and the mapping between them. MAPPING FROM BPMN TO XPDL Structurally, BPMN and XPDL are very similar; both being flow-chart struc- tures. In fact, the mapping between BPMN and XPDL is much more straightforward than the mapping between BPMN and BPEL4WS or BPML. In general, we shall see the following mappings from BPMN to XPDL (see Table 1): BPMN Graphical Object Mapping to XPDL The details of a Pool or an Expanded Sub-Process Start Event 1 Business Process Management Initiative: www.bpmi.org XPDL AND BPMN 223 Sequence Flow Task + Sub-Process Intermediate Event attached to activity boundary Combined with a: Decision Combined with a: B A C D Fork AND-Split C D F Join AND-Join XPDL AND BPMN 224 C D E Merge OR-Join End Event Table 1: BPMN Objects and their Mappings to XPDL Applications assigned to the Tasks will fit into the tool (implementation) ele- ment of an activity. These applications and their parameters are not graphi- cally depicted within BPMN, but are properties of the Tasks in the diagram. These and other properties can be captured by a modeling tool and then used in mapping to XPDL to generate the appropriate XML elements. End- Users assigned to the Tasks will fit into the performer element of the activ- ity. BPMN WORKFLOW EXAMPLE To make the relationships between BPMN and XPDL clearer, an example of a business process that was modeled with BPMN will be analyzed and mapped to XPDL. The process that will be described is a process that the WfMC has been using for an example XPDL. The BPMN Business Process Diagram (BPD) was derived from a pre-existing XPDL, rather than the other way around. However, BPMN handles some flow elements differently than the model from which the XPDL file was originally derived. Because of this, the XPDL that would be created from a mapping from the BPD will be slightly different than the original XPDL. Thus, the XPDL examples presented in this paper will not be exactly the same as the sample XPDL provided by the WfMC. The BPD presented is a process for process a customer order electronically (see Figure 1). This Process will provide examples for many of the features of BPMN and how they map to XPDL. The sections below will highlight these features as we describe how the Process works. Note: The mapping of BPMN to executable XML languages is still a work-in-progress. Thus, the mapping and language relationships defined in this paper may change in the future. The intent of these examples is to make the reader familiar with the general concepts of BPMN elements and their relationship to XPDL elements. XPDL AND BPMN 225 Check Data Raise Alarm Transform Data Data Error Compose Rejection Message Check Vendor Account Data OK? Valid Data Invalid Data Order Type? orderType == "Credit" orderType == "PO" Credit Acceptable? Bad Credit or Over Limit Accept Check Credit Set Credit Info Get Credit Authorization Set Order Status Enter Order Order Email Confirmation + Fill Order Compose Acceptance Message Order CreditService creditInput creditOutput Order Shipper Shipping Message Figure 1: E-Order Process The Process has a point of view that is from the perspective of the company processing the order. From that point of view, the credit service and the or- der shipper are considered as external Participants (shown as BPMN Pools) who will be communicated with by messages (shown as Message Flow). The sections below will isolate different sections of the overall Process. Each of the process segments will be described and then mapped to XPDL. THE BEGINNING OF THE PROCESS The Process starts with an order being received (see Figure 2). Check Data Raise Alarm Transform Data Data Error To: Compose Rejection Message Task To: Data Ok? Decision Order Figure 2: The Start of the E-Order Process XPDL AND BPMN 226 The order data is then sent through an application to transform the data within the through a “Transform Data” Task. Order data is passed to the application and result information is returned. Through the application, this Task may generate a Process Error, as shown by the Intermediate Event attached to the boundary of the Task, if there is a problem with the data. A Task to raise an alarm follows the Process Error Intermediate Event. If the data is transformed properly then a Task that uses an applica- tion to check the data is performed. Order information is passed to the ap- plication and status information is returned. After the “Check Data” Task, the Process continues to a Decision and follow-on Tasks. These details will be shown in the next section. Mapping to XPDL Figure 3 shows how the BPD diagram objects for the beginning of the “E- Order” Process will map to XPDL. Check Data Raise Alarm Transform Data Data Error To: Compose Rejection Message Task To: Data Ok? Decision Order Maps to: route activity (id = "5")Maps to: transition (id = "20") Maps to: transition (id = "21") Maps to: transition (id = "19") Maps to: transition (id = "42") Maps to: transition (id = "40") Condition Type="EXCEPTION" Maps to: implementation activity (id = "58") Name="Check Data" No Implementation Maps to: implementation activity (id = "1") Name="Check Data" Application = "checkData" Parameters: orderInfo status Maps to: implementation activity (id = "1") Name="Check Data" Application = "transformData" Parameters: orderString orderInfo Maps to: implementation activity (id = "1") Name="Check Data" XOR Split TransitionRef Id="40" Figure 3: The Start of the E-Order Process and the Object Mappings to XPDL The BPD objects are straightforwardly mapped to XPDL as shown in the figure. The most complex mapping in this section of the Process appears in the “Transform Data” Task, the “Data Error” Intermediate Event attached to its boundary, and the attached Sequence Flow. These map to an implemen- tation activity (id = “17”) and a transition (id = “40”). The Task maps to the implementation activity and its name and implementation elements. The In- termediate Event attached to the boundary of the Task will result in an XOR Split TransitionRestriction within the implementation activity. Transi- tionRestrictions should only be used in implementation activities for excep- XPDL AND BPMN 227 tion and compensation handling. The TransitionRestrictions should refer- ence only one transition for the normal flow and one or more transitions for the exception or compensation flow. In this example, the referenced transi- tion (id = 21) defines the normal flow of the process and the other refer- enced transition (id = “40”) defines the exception flow. The exception flow transition will have a Condition of type "EXCEPTION.” Example 1 displays sample XPDL code that reflects the portion of the Proc- ess that is shown in Figure 3. orderString orderInfo No XPDL AND BPMN 228 Example 1: XPDL Sample for Beginning of E-Mail Voting Process THE MIDDLE OF THE PROCESS Figure 4 shows the activities and Decisions in the middle of the “E-Order” Process. For the Purposes of this section, the “Check Credit” Sub-Process will be collapsed. The next section will take another look at the Sub-Process as an Expanded Sub-Process within the Process. Enter Order Compose Rejection Message Check Vendor Account Data OK? Valid Data Invalid Data Order Type? orderType == "Credit" orderType == "PO" Credit Acceptable? Bad Credit or Over Limit Accept To: End Event To: Compose Acceptance Message Task Email Confirmation Task and Fill Order Sub- Process + Check Credit From: Check Data Task From: Raise Alarm Task Figure 4: The Middle of the Process This section starts out with a Decision that considers the results of the pre- vious Task (“Check Data”). If the data is invalid then the process will end after a rejection message is created. If the data is OK, then a second Deci- sion is made that checks the type of order. If the order is based on credit, then a credit check is performed through the “Credit Check” Sub-Process. If the order is based on a PO, then the vendor account is checked. In either case, if the credit is bad or the amount over the credit limit, then the proc- ess will end after a rejection message is created. If the credit is ok, then the process will continue with the order data being entered into the system. Mapping to XPDL Figure 5 shows how the BPD diagram objects for the middle of the “E- Order” Process will map to XPDL. XPDL AND BPMN 229 Enter Order Compose Rejection Message Check Vendor Account Data OK? Valid Data Invalid Data Order Type? orderType == "Credit" orderType == "PO" Credit Acceptable? Bad Credit or Over Limit Accept To: End Event To: Compose Acceptance Message Task Email Confirmation Task and Fill Order Sub- Process + Check Credit From: Check Data Task From: Raise Alarm Task Maps to: transition (id = "20") Maps to: transition (id = "22") Condition status == "Valid Data" Maps to: implementation activity (id = "41") Name="Check Vendor Account" Application = "checkVendor" Parameters: orderInfo.AccountNumber orderInfo.ToltalAmount status Performer = "DBConnection" Maps to: transition (id = "23") Condition status == "Invalid Data" Maps to: Name = "Data OK?" route activity (id = "2") XOR Split TransitionRef Id="22" TransitionRef Id="23" Maps to: Name = "Check Order Type" route activity (id = "12") XOR Split TransitionRef Id="24" TransitionRef Id="25" Maps to: route activity (id = "13") Name = "Credit Acceptable? OR Join XOR Split TransitionRef Id="27" TransitionRef Id="31" Maps to: transition (id = "24") Condition orderType == "Credit" Maps to: transition (id = "27") Condition status == "Accept" Maps to: transition (id = "42") Maps to: transition (id = "31") Condition status == "OverLimit or BadCredit" Maps to: implementation activity (id = "10") Name="Check Credit Subprocess" SubFlow id = "3" Execution = "SYNCHR" Maps to: implementation activity (id = "39") Name="Compose Rejection Message" Application = "composeMessage" Parameters: orderNumber -1 OR Join Maps to: implementation activity (id = "32") Name="Enter Order" Application = "enterOrder" Parameters: orderInfo orderNumber Performer = "DBConnection" AND TransitionRef Id="1" TransitionRef Id="38" TransitionRef Id="2 Maps to: transition (id = "29") Maps to: transition (id = "1") transition (id = "2") transition (id = "38") Maps to: transition (id = "25") Condition orderType == "PO" Figure 5: The Middle of the Process and the Object Mappings to XPDL The Decisions in the Process map to XPDL route activities that have split elements of type “XOR.” The split element references the transitions that follow the route activity. These transitions contain the conditions that de- termine which of the transitions will be taken. Note: XPDL implementation activities may also have split elements that could be used for Decisions. However, the mapping from BPMN is much cleaner by using only route activities for Decisions and split elements in implementation activities only for exceptions and compensation. Both the “Credit Acceptable?” Decision and the “Compose Rejection Mes- sage” Task have multiple alternative incoming Sequence Flows. This means that both of the activities to which these objects map will have a join ele- ment of type “OR.” Both the “Check Vendor Account” Task and the “Enter Order” Task define a performer for the Task and this maps to the performer element with the re- spective implementation activities. The mapping of the “Enter Order” Task also must handle the three parallel outgoing Sequence Flows (as can be seen in Figure 1 and Figure 8). The set of parallel transitions is referenced through a split element of type “AND.” Example 2 displays some sample XPDL code that reflects the portion of the Process as described above and shown in Figure 5. XPDL AND BPMN 230 XPDL AND BPMN 231 DBConnection DBConnection status == "Valid Data" status == "Invalid Data" orderType == "Credit" orderType == "PO" status == "Accept" XPDL AND BPMN 232 status == "OverLimit or BadCredit" Example 2: XPDL Sample of “Discussion Cycle” Sub-Process Details THE EXPANDED SUB-PROCESS Figure 6 shows isolates the Expanded Sub-Process “Check Credit.” Check Credit Set Credit Info Get Credit Authorization Set Order Status To: Credit Acceptable? Decision From: Check Order Type? Decision Figure 6: “Check Credit” Sub-Process Once within the Sub-Process, a Task is set to prepare the credit informa- tion for transfer to the credit service, then a Web service is used to get the results from the credit service, and then a Task is used to process the re- sults from the credit service. The Process then moves back up to the top level and continues. The details of the rest of the Process are shown in the previous section and the next section. The “Get Credit Authorization” Task has communications, through a Web service, with an external company. The communication is shown through Message Flows to and from the “Credit Service” Pool in Figure 1. Mapping to XPDL Figure 7 shows how the BPD diagram objects for the Expanded Sub- Process will map to XPDL. XPDL AND BPMN 233 Check Credit Set Credit Info Get Credit Authorization Set Order Status To: Credit Acceptable? Decision From: Check Order Type? Decision Maps to: transition (id = "20") Maps to: implementation activity (id = "48") Name="Set Credit Info" Application = "setCreditInfo" Parameters: accountNumber amount cardType creditInfo Performer = "DBConnection" Maps to: implementation activity (id = "10") Name="Check Credit Subprocess" SubFlow id = "3" Execution = "SYNCHR" Maps to: transition (id = "24") Condition orderType == "Credit" Maps to: implementation activity (id = "50") Name="Get Credit Authorization" Application = "getCreditAuthorization" Parameters: creditInfo creditStatus ExtendedAttribute Name="SystemActivity" Value="WebService" Maps to: implementation activity (id = "60") Name="Set Order Status" Application = "setOrderStatus" Parameters: creditStatus status Maps to: workflow process (id = "3") Name="Check Credit" Access Level = "Private" Parameters: accountNumber amount cardType status DataField creditStatus Hidden End Event Maps to: route activity (id = "52") and transition (id = "48") Hidden Start Event Maps to: route activity (id = "48") and transition (id = "46") Figure 7: “Check Credit” Sub-Process and the Object Mappings to XPDL As seen in the last section, the “Check Credit” Sub-Process maps to an im- plementation activity that has a SubFlow element. The details within the Expanded Sub-Process are defined in a separate WorkflowProcess element (id = “3”). The mapping for the details of the Expanded Sub-Process is straightforward except that Start Event and End Event for the Sub-Process are not dis- played. Thus, the route activities that start and end the XPDL process and the transitions that connect them are created through the implicit Start and End Events, rather than any actual graphical objects. Example 3 displays some sample XPDL code that reflects the portion of the Process as described above and shown in Figure 7. orderType == "Credit" XPDL AND BPMN 234 DBConnection Example 3: XPDL Sample XPDL AND BPMN 235 THE END OF THE PROCESS Figure 8 shows the last section of the Process. Enter Order Order Email Confirmation + Fill Order Compose Acceptance Message From: Compose Rejection Message Task From: Credit Acceptable? Decision Figure 8: The last segment of the E-Order Process This segment of the Process continues from where the last segment left off (as described in the section above). After the “Enter Order” Task there are three parallel activities: Two Tasks (“Compose Acceptance Message” and “E- mail Confirmation”) and a Sub-Process (“Fill Order”). The details of the “Fill Order” Sub-Process are not shown in this example. After these three activi- ties have been completed, the entire Process is completed. The “Fill Order” Sub-Process has communications with an external com- pany. The communication is shown through a Message Flow to the “Order Shipper” Pool in Figure 1. XPDL AND BPMN 236 Mapping to XPDL Enter Order Order Email Confirmation + Fill Order Compose Acceptance Message From: Compose Rejection Message Task From: Credit Acceptable? Decision Maps to: implementation activity (id = "32") Name="Enter Order" Application = "enterOrder" Parameters: orderInfo orderNumber Performer = "DBConnection" AND TransitionRef Id="1" TransitionRef Id="38" TransitionRef Id="2 Maps to: transition (id = "29") Maps to: transition (id = "38") Maps to: transition (id = "2") Maps to: transition (id = "1") Maps to: implementation activity (id = "11") Name="Fill Order Subprocess" SubFlow id = "2" Execution = "ASYNCHR" Maps to: transition (id = "36") Maps to: implementation activity (id = "8") Name="Email Confirmation" No Implemenation ExtendedAttribute Name="SystemActivity" Value="EMail" Maps to: implementation activity (id = "56") Name="Compose Acceptance Message" Application = "composeMessage" Parameters: status orderNumber Maps to: transition (id = "17") Maps to: transition (id = "16") Maps to: route activity (id = "33") AND Join XOR Join Maps to: Does not map to a specific XPDL element Figure 9: The last segment of the E-Order Process and Object Mappings to XPDL The mapping is fairly straightforward in this section of the Process. The “Enter Order” Task mapping, with the parallel outgoing Sequence Flows, was described in a previous section. The only other point to note is the mapping of the End Event. This object has three parallel incoming Se- quence Flows and a forth alternative incoming Sequence Flow. This results in a join element of type “AND" and a second join element of type “OR” within the route activity that concludes the process. The “Order” Data Object does not map to a specific XPDL element, but is shown here to illustrate how Data Objects can be used by a modeler to track how business objects interact with the activities of a business proc- ess. Example 4 displays some sample XPDL code that reflects the portion of the Process as described above and shown in Figure 9. XPDL AND BPMN 237 Order number %%orderNumber is being processed.Thank-you for ordering from PQR Products, Inc orderNumber orderInfo.orderType orderInfo.emailAddress DBConnection XPDL AND BPMN 238 status == "Accept" Example 4: Sample XPDL code for the last section of the Process SUMMARY The Business Process Modeling Notation (BPMN) provides ease-of-use and interoperability for business people who will design and manage the busi- ness processes on a daily basis. XPDL provides a standard mechanism for defining and executing business processes, enabling interoperability be- tween workflow environments. The WfMC and BPMI are actively developing a bridge between the two standards. This paper provides the first look at the relationships and mapping between XPDL and BPMN as shown through a sample business process. Extracted with permission from the Workflow Handbook 2003 published by Future Strategies Inc., in collaboration with the WfMC. Order the Workflow Handbook 2003 at www.wfmc.org
还剩17页未读

继续阅读

下载pdf到电脑,查找使用更方便

pdf的实际排版效果,会与网站的显示效果略有不同!!

需要 3 金币 [ 分享pdf获得金币 ] 0 人已下载

下载pdf

pdf贡献者

ccwing

贡献于2013-06-21

下载需要 3 金币 [金币充值 ]
亲,您也可以通过 分享原创pdf 来获得金币奖励!
下载pdf