The Flesh and Bone of SOA
BPEL & Role Activity Diagrams
By: Michael Havey
Jun. 6, 2007 05:45 PM
The overall disputes process that ACME intends to build is shown in Figure 5. (This figure shows the process in Oracle's graphical editor. The actual XML BPEL code for this example, as well as the Design example described above, will be available at http://webservices.sys-con.com/read/issue/archives/ under this issue/article .) The process begins when ACME receives a dispute from a customer (receiveDisputeFromCust). ACME then ensures that the dispute is fully captured (which might involve contacting the customer to get supporting information such as receipts) and then splits in two directions, one of which is normal processing, which ACME already supports (the normal chargeback cycle that follows rigid business rules). The other path is the RAD path, in which a sales-savvy disputes specialist makes the right choices to ensure that the customer wins the dispute and buys something along the way.
The RAD path is actually a collaboration involving three roles, In Figure 5, the main process sets this collaboration in motion: the invoke activity createCollab calls a Web Service known as CollabService to initialize the collaboration; the invoke activity startSpecialistRole launches a second BPEL process that manages the primary role in the collaboration, the Dispute Specialist role. The top-level process is now complete, and the RAD collaboration, implemented as three interacting BPEL processes representing the three RAD roles, now commences.
Before turning to those processes, let's examine the nature of the required RAD collaboration by studying its RAD diagram, shown in Figure 6. The dispute specialist begins by assessing the dispute (Assess Dispute) and deciding on an upsell strategy. If he thinks the dispute is invalid and would typically be rejected (the Upsell Reject refinement path), he instead writes it off (because rejections don't sit well with high-value customers) and makes a "level 3" (or "L3") sales offer (e.g., offer the gold card and waive the first-year membership fee). If he thinks the dispute would typically be written off (Upsell Writeoff), he writes it off and makes a slightly better, "level 2" ("L2") offer (e.g., a line of credit at a favorable rate). In the final two cases (Upsell Possible Loss and Upsell Likely Win), the specialist decides to chargeback the item to the merchant to try to recover the charges. If the dispute seems likely to win (i.e., the merchant's bank will probably concede), the dispute specialist assigns a sales specialist (Assign to Sales Specialist) to find a good "level 1," or "L1," offer (e.g., a retirement catch-up loan with the no payments for the first 24 months), makes the offer to the customer, and assigns to a Dispute Lackey (the colloquial term at ACME for a dispute specialist who knows the ins-out-outs of disputes management but doesn't interface with customers) the task of managing the chargeback; if the dispute is lost, the specialist unhappily writes it off. In the case where the dispute specialist thinks the dispute might lose but is worth charging back anyway, he makes an L2 offer and has the lackey follow through with the chargeback. If it loses, the specialist writes it off; if it wins, the dispute specialist asks sales to prepare an L1 offer and extends it to the customer. (Notice that the customer in this case is made two offers: an L1 and an L2. Because a dispute can drag on for weeks or months, ACME prefers to have the specialist make a modest L2 offer immediately, then the more lucrative L1 when the dispute is won.)
The need for RAD arises because of the adaptive nature of this collaboration. In the first place, many activities may be interleaved; in Upsell, Likely Win, for example, the specialist may assign tasks to sales and the lackey in parallel. Furthermore, if the specialist doesn't like the L1 offer prepared by sales, he may decide to make an L2 offer instead. And that's just the tip of the iceberg. In the future, more refinement paths could be added, more activities added, more roles added. The typical BPEL control structure can't easily support this.
Our strategy is to throw a sensible combination of workflow patterns and business rules at the problem. Figure 7 shows the disputes specialist BPEL process in the Oracle editor. The process begins by receiving its start event from the top-level disputes process (startMeUp), and then it calls CollabService to add itself to the collaboration (addRoleToCollab). Next (in the scope configureMyRole shown collapsed in the figure), the process calls the CollabService to configure its tasks, associating each task with its role in the collaboration; these tasks are AssessDispute, WriteOff, MakeL1Offer, MakeL2Offer, MakeL3Offer, AssignLackey, and AssignSales. The process then starts a while loop that runs for as long as the role is in the enabled state. In the first step in the loop, the process calls CollabService to run business rules (runRules) to determine the enablement status of the role and each of its tasks. This leads into a pick, in which the process waits for one of three events to occur. The first is a signal from the end user that one of the enabled tasks has now been completed. If that task is AssignLackey or AssignSales, the process sends a message to the BPEL process representing that role to join the collaboration. The other two events in the pick are callbacks from the Lackey and Sales processes indicating that their work is done. In each case, the process enriches the role's data with information about the event. That data is input to the business rules in the next iteration of the loop. Next time around, the set of enabled tasks might change, or the role itself might be considered complete, and thus disabled.
The processes for Lackey and Sales are similar, but simpler. Each role has only one task. The process adds its role to the collaboration, adds its task to the role, and waits for that task to be executed, on which it calls back the Dispute Specialist process to indicate that the work has completed.
Figure 8 shows the end-to-end sequence of interactions for the Upsell, PossibleLoss path. At this point, we can make the following observations on this design of RAD in BPEL:
The while loop in the Dispute Specialist process exhibits two common workflow patterns: Multiple Instances and Milestone.
(For more information on workflow patterns, see www.workflowpatterns.com.)
Finally, CollabService is a Web Service that uses a set of database tables, shown in Figure 9, to maintain the state of the collaboration. As the figure shows, a collaboration, identified by a collabID, has one or more roles. A role that participates in a collaboration is identified by its name (roleName) and an instance number (in case multiple instances of the same role are required, as with the Designer role in the Design example considered above). A role also has data (consisting of several pieces of structured, unstructured, and control information meaningful to the role), as well as a rule class and an enablement status. The rule class is a pointer to a class (e.g., Java, C#) or rule-set containing rules that decide, based on the role's current data, the enablement status of the role and each of its tasks. The tasks themselves are identified by name and instance (multiple instances of the same task occur when a role has iteration, as in the Manager role of the Design example above).
The collaboration service provides four methods to update this data: three - createCollaboration, addRoleToCollaboration, and addTaskToRole - to add new records to it, one - runRulesForRole - to update, based on business rules, role data and role and task enablement status. The service doesn't provide queries, although they could be added. A RAD UI tool should have read-only access to the tables to perform desired queries.
The behavior of the service method runRulesForRole is best understood by example. Consider the rules for enablement in the dispute specialist role specified in Table 1. When runRulesForRole is run, it tests the enablement condition for each of that role's tasks, as well as the role itself. On its first run, runRulesForRole will enable the task AssessDispute, because that task satisfies its condition that it hasn't been executed yet. No other tasks can be enabled initially.
When the specialist completes AssessDispute, he also specifies an assessment decision (i.e., one of the upsell strategies examined above). Assuming that decision is UpsellReject, next time the rules are run the following enablement changes are made:
The dispute specialist can work WriteOff and UpsellReject in any order. When these are completed, the role itself is disabled, because its enablement condition of having at least one enabled task or pending work from sales or the lackey fails.
Considering a more complicated scenario (shown in Figure 8), assume the specialist's decision in AssessDispute is UpsellPossibleLoss. The next enabled tasks are AssignLackey and MakeL2Offer. The specialist might then execute both tasks right away, which leaves no enabled tasks for the specialist role, but does trigger the lackey role. The dispute specialist role is still enabled, because it's waiting for information from the lackey. When the lackey completes his work, if the dispute was won the dispute specialist role is disabled, because no tasks are enabled and no activity is pending. On the other hand, if the dispute was lost, the WriteOff task is enabled, and the dispute specialist role waits for its completion.
Reader Feedback: Page 1 of 1
SOA World Latest Stories
Subscribe to the World's Most Powerful Newsletters
Subscribe to Our Rss Feeds & Get Your SYS-CON News Live!
SYS-CON Featured Whitepapers
Most Read This Week