The natural visualization of a business process is of boxes and arrows arranged in a tree-like formation. A large process with numerous conditional paths forms a rather expansive tree that can't fir on a computer screen or printed page. If the process has loops, these are often represented as arrows pointing back to earlier boxes, resulting in an untidy graph structure. Although BPEL isn't a visual process language, its XML representation can form code trees that are no less cumbersome. A receive inside a sequence inside a flow inside a switch inside a pick, even if properly indented, can make a coder see double.

This technique article shows how to model BPEL 1.1 processes in a special flat form that represents even the most onerous processes in just a few levels of structure. A process modeled in this form, represented visually, more closely resembles a neat pile of sticks than a tree. Aesthetics aside, the flat approach is fundamentally better suited to SOA orchestration than the tree approach. Flat BPEL is good SOA.

Flat Credit Card Dispute
To demonstrate the flat technique, let's consider the (deliberately complicated) example of how a bank processes credit card disputes raised by its customers. The following is an English description of ACMEBank's business process for disputes on its personal Visa cards:

• The Capture Stage: The customer submits a dispute over one of various channels (call center, Web, e-mail, mail, or fax) to ACMEBank. The bank makes a quick determination whether to reject the dispute outright (e.g., because it wasn't submitted within 60 days of its posted date), write it off (e.g., because the dollar amount of the transaction is below a certain threshold), request from the customer supporting documentation (e.g., receipts), or pass it to one of the bank's dispute specialists for further investigation. At any time at this stage the customer may cancel the dispute. The goal of this stage is either to capture the dispute completely or to dispense with it.
• The Investigation Stage: The dispute specialist examines the fully captured dispute, and may reject it, write it off, proceed with a chargeback (i.e., take the disputed amount back from the merchant), or request a sales draft from the merchant to investigate its validity (and ask the customer for clarification if the draft appears valid). The happy path culminates in a chargeback decision.
• The Chargeback Stage: ACMEBank charges back the transaction and credits the customer's account. The merchant bank may, in turn, accept the chargeback or represent the transaction (i.e., present the charge again), at which point an ACMEBank dispute specialist determines whether to charge back a second time, write off, or reject. In rare cases, the dispute is brought to arbitration before the Visa association.

Figure 1 is the natural, naïve tree representation of this process. (The figure is a box-and-arrows diagram that matches the XML structure of BPEL code. For simplicity's sake, sequences are omitted from the diagram. Events are shaded.) The top-level structure is straightforward: the logic for each stage is enclosed in a large outer block (a scope in the Capture stage, picks for Investigation and Chargeback). The process begins when it gets a dispute submitted over a customer channel (receive CustChannel Submitted), and then enters into the scope for the Capturing stage, whereupon it assigns the dispute for investigation to operations (invoke Ops pickup), which leads into the Investigating pick. The last steps are to submit the chargeback to the merchant bank (invoke DisputeNet Chargeback ) and handle the subsequent exchange with the merchant (the Chargeback pick).

The complexity is in the internals of the three stages. In the Capturing stage, for instance, the logic to wait for documentation from the customer is a pick within a pick within a while within a scope. The scope defines a message handler that checks for a cancellation event (onMessage CustChannel Cancelled) from the customer, which terminates the flow outright. The while loop that forms the body of the scope iterates until the dispute has been completely captured. The loop first assigns the dispute for assessment to an operations person (invoke ops pickup), and then waits for the operator's response in a pick. The operator can respond in one of four ways, modeled as four onMessage handlers in the pick. Of the four, one handler completes the loop (onMessage Ops ChargedBack) and leads into the next stage, two terminate the process with immediate outcomes (onMessage Ops Rejected, onMessage Ops WrittenOff), and the final (onMessage Ops DocsRequested) sends a request to the customer for documentation (invoke CustChannel UpdateRequested) before transitioning to the innermost pick, which gets the customer's documentation (onMessage CustChannel Updated), thereby completing the loop's current iteration; next time around, the operator might decide that enough information exists for the dispute to be considered completely captured. The other two stages are no less onerous, each defining five levels of picks.

The process is designed in the style of a procedural program. The flow is deep and meandering. Activities are lost in the machinery of control structures. The most important steps in a BPEL process are its partner interactions (receives, onMessage handlers and invokes), but in this process they are scattered about the flow. Consequently, it's hard to determine how faithfully this process honors its contract with its partners; it's hard to see the orchestration in this process. Is ACME communicating properly with its customers and with merchants? It's hard to answer this question without shaking the tree.

The tree version of the disputes process is no straw man. Most business processes today are constructed in this fashion, largely because process designers lack process design sophistication. Business analysts, not surprisingly, understand the business problem domain but don't draw rigorous flowcharts. Technical designers, who are handed business analyst process diagrams in the transition from the requirements to the development stage, work mainly at hardening the process and plugging holes. They don't reshape or introduce patterns; processes remain procedural. Technical design perpetuates the bad practices of business analysis. Ironically, many of these designers write beautiful state-of-the-art services: their Java or C# is impeccable, but they aren't strong at designing processes around these services.

The flat style of process design recommended in this article kills two birds with one stone. On the one hand, it encourages flat processes organized around partner interactions rather than procedural control structures. On the other hand, the emphasis on partner interactions is a purer expression of SOA orchestration than the alternative tree approach.

The trick is to conceive of the process as the state machine of some entity, observed from the point of view of the participant that manages the process - e.g., a credit card dispute for ACMEBank, a claim for an insurance company, a purchase order for a supplier. Transitions between states are triggered by inbound events from other partners: receives, picks, and handlers. The process performs actions either during a transition or when a state is entered or exited. The most significant actions from an SOA perspective are invokes in which the current participant calls other participants, possibly triggering state changes in them too. Once the states, transitions, and actions of the state machine are understood, the BPEL process flow is easy to develop.