We now turn to the TIBCO design.
Architecture
The implementation of the BPM-based disputes process in TIBCO has the following pieces:
An iProcess business process (known as a procedure in iProcess terminology) that models the end-to-end flow.
Inbound, outbound, and internal service orchestration processes, developed in BusinessWorks.
An
ActiveMatrix mediation flow (running in the ActiveMatrix service bus)
to define the routing and transformation logic to move messages to and
from partner applications.
The following figure situates these pieces in the ACMEBank architecture:
Other salient features of this architecture are the following:
TIBCO's MOM implementation is the Enterprise Message Service (EMS), which offers a JMS interface. Mediation flows and orchestration processes communicate over EMS queues.
Orchestration
processes, running on BusinessWorks, call iProcess using the iProcess
Palette, which is a plug-in to BusinessWorks.
iProcess
calls BusinessWorks processes using EAI steps. iProcess has a
BusinessWorks plug-in that allows it to call BusinessWorks using EAI
steps.
In
TIBCO literature, the term orchestration process sometimes has a
stricter meaning than ours. In some uses it refers only to the
long-running BPEL processes, which run on a special BPEL plug-in to
BusinessWorks. In our usage, 'orchestration processes' can also refer to
the short-lived BusinessWorks processes. Our implementation, in fact,
uses short-lived processes only.
iProcess Business Processes
The main iProcess procedure is shown in the following figure.
When it begins, the procedure initializes its data (INITVARS Init Process Variables), notifies ACMEBank's operations that a new dispute has arrived (HEADSUP Dispute Coming Your Way), and calls a BusinessWorks process to create the dispute in the database (CRTDISP Create Dispute). It then launches a sub-procedure (CAPTURE)
to manage the Capture stage, in which operations determines whether the
dispute requires further documentation from the customer. We discuss
the logic of this sub-procedure presently. While the sub-procedure is
running, the main procedure listens for customer cancellation requests
with the event CANCEL Cust Cancel. If the event is triggered, the procedure verifies that it is still in the capturing stage (with the decision Still Capturing?)
and, if so, simultaneously cancels the sub-procedure-we discuss how
this is modeled next-and assigns to someone in operations the task of
processing the cancellation (CANCELOP Ops Cancel Dispute). If the dispute is no longer in capture, the procedure asks operations to follow-up with the customer (CANFAIL Followup Failed Cancel).
Before continuing with the main procedure, let's dive into the sub-procedure, which is shown in the following figure:
When the sub-procedure begins, it assigns a task to operations to review the dispute (REVIEW Review Dispute).
Operations has four choices: reject the dispute, write it off, declare
it fully captured, or request additional documentation from the
customer. If the choice is one of the first three, the sub-procedure
exits, and returns control to the main procedure. Otherwise, the
sub-procedure calls BusinessWorks to send to the customer the request
for documentation (SENDCUST Send Cust Doc Request). (The diamond labeled RequestDocs performs this if/else routing.) Next, capture waits for the customer's response with the event step WAITCUST Wait Next Cust Action.
If the customer does not respond within a specified interval, the event
times out, the procedure sets the outcome to ‘rejected because of
timeout' (OUTTO Set Outcome Timeout), and the sub-procedure exits. If the customer responds, the procedure calls BusinessWorks to update the status (UPDDOCS Update review docs), and loops back to the review step (REVIEW Review Dispute) for another review cycle.
When the sub-procedure exits, the main procedure performs a conditional check (Keep Going)
to determine whether the dispute is completed (that is, was rejected or
written off) or requires further investigation (that is, was declared
captured). In the former case, the procedure sends the outcome to the
customer (SNDFINAL Send Cust Final Status) and exits. In the latter case, the procedure enters the Investigation stage. For brevity, we skip this part-the step SKIPINV Skip Investigation is a no-op-and move directly to Chargeback, which starts with two BusinessWorks steps: CRDCUST Credit Customer Account (to credit the disputed amount to the customer's account) and MERCB Send Merchant Chargeback (to notify the merchant of the chargeback).
At this point the procedure waits on the event MERCB Merchant Respond CB
for one of three possible outcomes: the merchant accepts the
chargeback, represents the charge, or fails to respond in time. In the
first two cases, the procedure moves to the conditional step Credited, which checks whether the merchant accepted the chargeback. If so, the procedure calls SNDFINAL Send Cust Final Status to set the final status of the dispute and inform the customer of the good news. The logic for representment is skipped (NOREP Rep Not Implemented). In case of a timeout, the procedure assigns to operation the task of closing the dispute (CLOSE Close Dispute) before notifying the customer that the dispute was settled in her favor because the merchant failed to respond (SNDFINAL Send Cust Final Status using the status set in the script step SETOUT Set Outcome).
This
iProcess procedure, then, drives the flow of activities that we
documented previously in a more casual flowchart form. It is not
difficult to walk through the iProcess implementation, though admittedly
some uses of the notation need clarification:
User tasks are represented by a symbol that resembles a bullet list with a person to the side. (An example is HEADSUP Dispute Coming You Way
in the main procedure.) User tasks are assigned to a user or group in
an organization, and there are tools provided by iProcess that allow
users to view, execute, and monitor these tasks. Most of the user tasks
in the disputes process are assigned to operations, a group in
ACMEBank's back office. Tasks named Escalate are assigned to supervisors in the back office.
User
tasks take time to complete (perhaps hours, days, or longer), and thus
can have configured deadlines. Most of the user tasks in the disputes
process have an escalation action (named Escalate)
that is assigned when the task passes its deadline. Escalation tasks
allow supervisors to prod their disputes specialists to complete their
assigned work.
Steps having a light bulb symbol are events, which represent actions external to the process. There are three events in the disputes process: CANCEL Cust Cancel, MERCB Merchant Response CB, and WAITCUST Wait Next Cust Action.
(The first two are in the main procedure; the third is in the Capture
sub procedure.) These represent, respectively, customer cancellation,
the merchant's acceptance of the chargeback, and a customer
documentation update. BusinessWorks inbound processes trigger these
events when they receive messages from the customer or dispute network.
Events, like user tasks, can have deadlines. An example is the WAITCUST
event in the Capture sub procedure, which waits for the customer to
provide documentation related to the dispute. If the customer responds
in time, the event fires and control moves to the next step, UPDDOCS Update review docs,
which updates the dispute database with information from the
documentation. If the customer does act in time and the deadline passes,
a special deadline path is taken to the step OUTTO Set Outcome Timeout. That step sets a flag indicating that the dispute is rejected because of a customer timeout.
Cancellation in iProcess is achieved with withdrawal links. An example of a withdrawal link (from the main procedure) is the arrow from the right-side of the CANCEL event to the top of the CAPTURE sub procedure call. Thus, when the cancellation event fires, the effect is to withdraw, or cancel, the CAPTURE
sub-procedure. Any pending activities in that procedure are aborted.
This meets the requirement that the customer may cancel the dispute at
any time during the Capture stage.
Steps
that resemble a windmill atop a computer case are calls to
BusinessWorks. In iProcess terminology, such steps are known as EAI steps. CRTDISP Create Dispute in the main procedure is an example of such a step.
Steps that resemble a sheet of text atop a computer case are known as script steps. These steps manipulate process data. SETCAP Set Captured, for example, sets a flag that indicates that the capturing stage is complete.
Diamond-shaped steps (for example, Keep Going in the main procedure) are decisions
and work as expected. The path with the checkmark is followed if the
outcome of the decision is true. Otherwise, the path with the x symbol is taken.
A step whose symbol is an asterisk is known as a complex router.
Don't be intimidated by the name. A complex router is exceedingly
simple; its job is to do nothing! Complex routers are often used as
placeholders. SKIPINV Skip Investigation,
for instance, is a stub for the Investigation stage of the disputes
process. For the sake of simplicity, that stage is omitted from this
implementation; the placeholder is a reminder to us to add it later.
