The following discussion considers the BEA design.
Architecture
In the SOA-based
representation of the disputes process, the bulk of the process logic
moves from a business process to an orchestration process. In the BEA
stack, most of the logic is therefore in the process integration engine,
Weblogic Integration. BEA's BPM engine, AquaLogic BPM, plays the
comparatively minor role of managing a handful of operations tasks. The
ESB portion performs the same role in the BEA solution as in the TIBCO
solution. BEA's ESB is AquaLogic Service Bus. The architecture is shown
in the following figure:
Weblogic Integration Orchestration Process
For brevity, we discuss only the Weblogic Integration piece. The overall process is shown in the next figure:
The process begins by receiving the customer's dispute request (Create Dispute) and then creates the dispute in the database (Create Dispute in DB) and logs the creation action in an audit table (Log Creation Action) before entering in the Capture stage, shown in the figure as a collapsed step (Capturing). When the Capture stage is complete, the process runs through the Chargeback stage (Charging Back, also collapsed). As with the TIBCO implementation, the BEA design skips the Investigation stage.
The Capture stage, in expanded form, is shown in the next figure:
The Capture stage has two parts: a body and a cancellation handler. The body is a while
loop (which starts at topmost diamond symbol), which, on each
iteration, tests the value of a flag to determine if the dispute is
completely captured. If the dispute is not captured, the process
launches a BPM process for operational review (Assign Ops Review), waits for the outcome (Ops Capture Response), updates the dispute's status in the database (Update Status in DB), logs the response in the audit table (Log Ops Action),
and branches in one of the multiple directions depending on operations'
decision. If operations requests additional documentation (the More Docs case), the process sends the customer a request for documentation (Send Cust Doc Request); the loop now iterates back and starts with a new review cycle. If operations declares the dispute captured (the Captured case), the process sets its loop flag to indicate that capture is complete (Set Flag Break), causing the loop to exit. In the WriteOff and Rejected cases, the process informs the customer of the outcome (Send Cust WriteOff or Send Cust Reject) and sets the loop flag for exit (Set Flag Break).
Implicit in these steps is a flag that determines whether to proceed to
the Chargeback stage. In the rejected and written off cases, this flag
is set to false, because once the dispute is rejected or written off, it
is complete.
In pseudo code, the logic is the following:
Initialize keepCapturing = true
Initialize keepGoing = true
While (keepCapturing)
Assign Ops Review
Ops Capture Response
Update Status in DB
Log Ops Action
If (response is MoreDocs)
Send Cust Doc Request
Else If (response is Rejected)
Send Cust Reject
Set keepCapturing = false
Set keepGoing = false
Else If (response is WritenOff)
Send Cust Written Off
Set keepCapturing = false
Set keepGoing = false
Else If (response is Captured)
Set keepCapturing = false
Set keepGoing = true
At any point
during the loop's execution, the customer may cancel the dispute. The
cancellation handler, shown to the upper right of the capture group,
listens for the cancellation (Cust Cancel), launches a BPM case to have operations process the cancellation (Assign Ops Cancel), updates the dispute's status (Update Status in DB), and logs the cancellation in an audit table (Log Action). The while loop is aborted, and the process completes.
The Chargeback state is shown in the next figure:
The
Chargeback stage begins with an if/then decision (the topmost diamond),
which checks whether to proceed with the chargeback. If so, the process
takes the Yes path, whereupon it credits the customer's account (Credit Account), notifies the merchant of its chargeback (Send Merchant Chargeback), and starts a timer for the merchant's response (Set Merchant Timer). Next, there are two possible outcomes: the merchant responds (Merchant Response) or the timer expires (Merchant Timeout). If the merchant responds and accepts the chargeback, the process takes the Credited path, updating the status in the dispute database (Update Status in DB), auditing the outcome (Log Action), and sending the customer the good news (Send Cust Won). The logic for the case in which the merchant rejects the chargeback and represents the charge (the Represented path) is not implemented. If the merchant does not respond in time (Merchant Timeout), the process updates the status (Update Status in DB), creates a BPM case to have operations close the dispute (Assign Ops Close), and informs the customer that she won because the merchant was tardy (Send Cust Won).
The essential characteristics of the Weblogic Integration implementation are the following:
The process is event-driven. In addition to the event that starts the process (Create Dispute), there are four intermediate events: Ops Capture Response, Cust Cancel, Merchant Response, and Merchant Timeout. Two well-known process patterns are used in this design: cancellation (the Cust Cancel event cancels the activities of the Capture stage) and deferred choice (the process waits for the first of two events, Merchant Response and Merchant Timeout, before continuing).
Like
TIBCO's BusinessWorks, Weblogic Integration has a selection of built-in
integration step types. The disputes process makes heavy use of
Weblogic Integration's database control; steps bearing the database symbol (for example, Update Status in DB) use this control. BPM integration is modeled with the steps Assign Ops Review and OpsCaptureResponse.
The former step starts a BPM process to assign the work to operations.
The latter, which occurs some time later, gets the result of the work.
Assuming the BPM platform is AquaLogic BPM, the former step would use
PAPI (the AquaLogic BPM API) to start a business process. The business
process would, in turn, use an automatic activity to signal its completion to the orchestration process.
The
process is block-structured, which explains why the pseudo-code
fragment presented above is apropos.
