Make This Retailer Process Run
The architecture might be not have any current implementations, but, using the example of a retailer's handling of a purchase order, let's approximate its prescribed development cycle and build an actual process. We begin with choreography. A retailer process does not operate in isolation, but rather collaborates with consumer processes to receive orders and warehouse processes to have orders filled. The choreography can be described in plain English as follows:
A consumer sends a purchase order to a retailer.
The retailer sends to the consumer an acknowledgement that it received the purchase order.
The retailer forwards the purchase order to a warehouse, passing to it the electronic address of the consumer. The warehouse will use this address to notify the consumer when the order is complete.
If the warehouse accepts the order, it sends a positive acknowledgement to the retailer. If the warehouse rejects the order, it sends a negative acknowledgement to the retailer. In each case, the retailer forwards to the consumer the result from the warehouse.
Assuming it accepted the order, when the warehouse has finished its processing and is ready to ship the goods, it sends a notification directly to the consumer.
The benefit of WS-CDL is that it can encode these steps formally in an XML language. The first two steps in the English description above are represented in WS-CDL by the code in Example 1.
Example 1. WS-CDL consumer-retailer interaction
1 <interaction name="POInteraction" channelVariable="tns:RChannel" 2 operation="handlePO" initiate="true"> 3 <participate relationshipType="tns:CRRelationship" 4 fromRole="tns:Consumer" toRole="tns:Retailer"/> 5 <exchange name="POReq" informationType="tns:PO" action="request"> 6 <send variable="cdl:getVariable(poC, tns:Consumer)"/> 7 <receive variable="cdl:getVariable(poR, tns:Retailer)"/> 8 </exchange> 9 <exchange name="PORsp" informationType="tns:POAck" action="respond"> 10 <send variable="cdl:getVariable(poAckR, tns:Retailer)"/> 11 <receive variable="cdl:getVariable(poAckC, tns:Consumer)"/> 12 </exchange> 13 </interaction>
This code describes an interaction with two exchanges: in the first exchange (lines 5-8) the consumer sends (
action="request") a purchase order (
informationType="tns:PO") to the retailer; in the second (lines 9-12), the retailer responds (
action="response") with a purchase order acknowledgment (
The first step in building the retailer process is to generate a BPMN diagram that satisfies the retailer's required role in the choreography. Today this step is necessarily manual; there is no current WS-CDL tool that can generate BPMN (www.pi4tech.com presents a good source of information about the one or two current experimental WS-CDL implementations). The manual approach is to look at the choreography and draw a process that fits the role; Figure 3 shows the BPMN diagram representing the retailer as a participant in the choreography.
Figure 3. Retailer process to satisfy choreography (BPMN representation)
The logic of the process is straightforward. The process starts when it receives a purchase order (PO) message from the consumer ("PO From Consumer"). It then successively sends an acknowledgement of receipt to the consumer ("Send Receipt Ack to Consumer") and forwards the PO to the warehouse ("Send PO to Warehouse"), before waiting until it receives a response from the warehouse ("Wait Warehouse Response"). When the response arrives, the retailer process forwards it to the consumer ("Send Warehouse Response to Consumer"), and the process completes. The notation is clear and intuitive: the boxes perform "activities," the circles with enclosed letter symbols wait for "events," the empty circle marks the endpoint of the process.
Figure 4 shows the process with the addition of private steps (i.e., steps not required by the choreography but driven by internal requirements). These steps are italicized: "Write PO to DB" persists the purchase order to an internal retailer database when it arrives from the consumer; "Update PO Status in DB" updates the database record with the status of the warehouse response (i.e., accept or reject); "Sales Followup" is a manual task, assigned to a sales representative to help the consumer resubmit the order in case it was rejected by the warehouse. (The diamonds in the figure are called XOR gateways. When combined, they form a conditional code structure that works like an
if statement. Gateways are discussed at length in Essential Business Process Modeling.)