BusinessWorks Orchestration Processes
The TIBCO solution uses seven short-lived BusinessWorks processes, shown in the next figure.
Processes (a) to (d) are called by iProcess to perform actions on behalf of the process. Processes (e) to (g) are triggered by inbound partner events. The following is a summary of these processes:
CreateDispute
(a) creates a dispute record in the disputes database.
UpdateDispute
(b) updates an existing dispute record.
SendParty
(c)
updates the dispute record in the database and sends a message to the
specified party (either the customer or the dispute network) by placing a
message on an EMS queue, where it is retrieved by the ESB and sent
directly to the party.
CreditAccount
(d) applies a credit to the customer's account record in the account database.
PartyInbound
(e) listens on an EMS queue (in JMS Queue Receiver)
for a message from a party (either the customer or the dispute
network). Partners do not write directly to the queue, but interface
with the ESB, which then puts the message on the queue. If the message
is a request from a customer to create a dispute, PartyInbound calls the CreateCase process (f). Otherwise, it calls the PartyUpdate process (g).
CreateCase
(f) creates an iProcess case to handle the customer's dispute request. It is called by the PartyInbound process (e).
PartyUpdate
(g), which is called by the PartyInbound process, triggers one of the two types of events in iProcess: Trigger Cancel triggers the cancellation event CANCEL Cust Cancel in the main procedure; DynTrigSSOLite
decides which event to trigger based on the current state of the
dispute, which it gets from the dispute record in the database with GetDisputeData. (DynTrigPrepSSOLite performs some setup work for making the dynamic call.)
Processes (a), (b), and (d) are internal service processes, to use the terminology just presented. Process (c) is an outbound process. Process (e) is an inbound process. Processes (f) and (g) are simply sub processes used by (e).
The variety of symbols in these processes is indicative of the rich integration capabilities of BusinessWorks:
Insert Dispute Record
(a) and Update Dispute Record
(b) are database update steps.
Get Dispute Data (g) is a database query step.
Apply Conditional Credit
(d), Dyn Trig Prep SSO Lite
(g), and Dyn Trig SSO Lite
(g) are database stored procedure calls.
iProcess Start Case
(f) and Trigger Cancel
(g) are iProcess calls.
JMS Send
(a) sends a message on a JMS queue.
JMS Queue Receiver
(e) receives a message on a JMS queue. It is known as a starter step in BusinessWorks terminology; when a message is received, the process containing the step starts executing.
Update Dispute
(c), Cust Create
(e), and Party Update
(e) directly invoke other BusinessWorks processes. For simplicity, these steps are named for the process they invoke; for example, Update Dispute invokes the process named Update Dispute.
ActiveMatrix ESB Processes
The next
figure shows the ActiveMatrix Service Bus mediation flow that routes
disputes messages to and from partners. All parties use a common web
service definition having two operations: create (to create a new dispute) and update (to update an existing dispute). According to the figure, when a party invokes the create operation, the mediation flow transforms the inbound message-copying the fields caseNum, account, merchant, txDetails, lastmsg, status, sender, and recipient, but setting the value of disputeID
(the key field, to be used in all subsequent exchanges to uniquely
identify the dispute) to the current date and time-and routes it to its
intended recipient (in the Target Interfaces column).
The
mediation flow treats participants abstractly, without concern for
their physical transport or address. In the next figure, also
constructed with TIBCO's ActiveMatrix, the source and target
participants in that mediation are mapped to specific endpoints.
According to the figure, ACMEBank receives inbound messages (that is,
has its create and update operations called) on a SOAP interface (labeled PartnerIn, and shown as a bar of soap) and lets the mediation flow (InMediation) process those messages. The target of the mediation flow is mapped here as an EMS queue (labeled InQueue,
and shown as a coffee cup with an envelope). Thus, when partners call
ACMEBank's service over SOAP, the service request is routed to an EMS
queue, where, as we have discussed, it is picked up by a BusinessWorks
orchestration process.
The idea of SCA is that services interact
with other services in a standard way without having to know at design
time their physical endpoints. Physical endpoints are resolved at
deployment time, using the wiring notation of the composite. Thus, the
mediation flow routes disputes requests in and out of ACMEBank without
any notion of EMS queues or SOAP endpoints. Those bindings are defined
elsewhere, in the composite.
(Not shown is
the outbound direction, in which ACMEBank invokes its partner's
service. For this scenario, the assembly is the reverse. The same
service definition is used, but it is bound to an EMS queue rather than a
SOAP transport. The recipient of the request-that is, the partner-has a
SOAP binding. Thus, when an ACMEBank orchestration process places a
message on the queue, the request is routed by SOAP to the partner.)
