- Introduction
- A Business Process Example
- BPEL Syntax
- The Future for BPEL
- Conclusion
- Additional Reading
A Business Process Example
Let's make the concept of business process more concrete. A business process is any activity that exists in its own right, has inputs and operational steps, and generates one or more outputs. A simple example is ordering a broadband line from a telecom service provider. Figure 1 illustrates the main steps in this process, in which a customer uses a service provider portal to initiate the broadband line order business process.
Figure 1 Business processes are conceptually similar to flowcharts. This business process is a broadband line order.
We can make a few observations about Figure 1:
- The business process depicted involves a minimum of two parties: the customer and the service provider.
- The business process consists of two main tiers: the customer side and the provider side.
- There is a definite ordering to the steps in this process—it is initiated by the customer and involves dialogue with potentially many systems and people inside the service provider. For example, step 3 in the second box might involve deployment of new hardware in the customer's local exchange. At a minimum, it would almost certainly require some device configuration to switch the bandwidth on in the customer's direction.
- There can be many instances of processes such as the one in Figure 1 (imagine the number of processes going on at any given time in organizations such as Amazon.com or the U.S. Internal Revenue Service). Each such process must follow a defined path to comply with the business policies.
- Exceptions can occur in processes; for instance, the customer location in step 2 of the second box might not support broadband. A graceful exit is required when exceptions occur—or, better still, a diversion to an alternative process pathway.
The interesting thing about business processes (well, I think it's interesting <g>) is that we're all widely experienced, without knowing it! Just think about loan applications, tax returns, insurance policies, etc. The more technical aspects of automating business processes may not be as well-known, but aren't overly complicated. Let's break them down a little.
A Schema for the Process
In step 1 of the customer activity in Figure 1, the customer initiating the process would likely use the service provider's portal (web site) to fill out and send a form detailing the required service request. The process passes this data to the service provider, who tries to fulfill the request as quickly as possible. It's no surprise that service providers are spending mountains of dollars trying to arrive at near-instantaneous customer request fulfillment.
Listing 1 illustrates a simple schema for this process, representing the major elements and data items. (Line numbers are included only for illustration.)
Listing 1 XML Schema for a Broadband Line Order Business Process
1. <element name="lineOrder" type="s1:LineOrder"/> 2. <element name="lineSupply" type="s1:LineSupply"/> 3. <complexType name="LineSupply"> 4. <sequence> 5. <element name="providerName" type="string"/> 6. <element name="approved" type="boolean"/> 7. <element name="provisioned" type="boolean"/> 8. <element name="lineType" type="string"/> 9. </sequence> 10. </complexType> 11. <complexType name="LineOrder"> 12. <sequence> 13. <element name="customerName" type="string"/> 14. <element name="email" type="string"/> 15. <element name="currentLineType" type="string"/> 16. <element name="requiredLineType" type="string"/> 17. </sequence> 18. </complexType>
Listing 1 describes two services—LineOrder and LineSupply—on lines 1 and 2, respectively. These services can be thought of as software services that are invoked by the process to achieve its required result. The LineOrder service is passed the data supplied by the customer at the provider portal. Lines 11–18 define the customer-side data. Then the LineSupply service does its stuff and tries to fulfill the order. Lines 3–10 define the data returned by the service provider.
The end result of the process is a successful or failed effort by the service provider to supply a broadband line to the customer. This line provision might even result in roads being dug up! All of this activity occurs under the control of the business process. That's the overall picture—let's break it down further.
Business Process Elements
The timeline for representing business processes is referred to as a swim lane—this is conceptually similar to the state transition diagrams of UML. The components of the business process consist of scope and activity:
- Scope can be thought of as the extent or boundary of the process elements; for example, providing a broadband line.
- The activity defines what happens within the scope, such as invoking the associated services.
In the case of Figure 1, the end user initiates the flow by sending a request from the service provider portal. The flow passes into the provider's BPEL framework, where the required services are called. Any required workflows then occur (such as digging up roads and laying cable, equipping local exchanges with broadband devices, and so forth), and a result is returned to the user. The entire process might take a long time, in which case the user is informed at a later date. The important point is that the flow is controlled and managed by the service provider's BPEL framework. This setup helps make the provisioning process tighter and avoids service requests disappearing into the ether.
Handling Long-Running Flows
The operations in the bottom half of Figure 1 may occur very quickly (within minutes) or they may take days or weeks (such as when broadband infrastructure has to be installed to meet the request). An important aspect of successful automation of business processes is persistence—the ability to maintain the state of the process for as long as necessary. Typically, the state of such long-running asynchronous flows is maintained in a database. The state details can then be retrieved as soon as the associated service returns.