After spending much of last year learning to use the Business Process Execution Language (BPEL) to orchestrate Web Services and realize the benefits of a service-oriented architecture (SOA), we felt it was time for us to climb down off the bleeding edge of the razor and share our story about the real-world realities of implementing a BPEL-based project.

Policy Studies, Inc. (PSI) provides outsourcing, technology and consulting to government and private agencies. Outsourcing is a significant part of its business; and this service includes performing certain functions on behalf of clients such as registering newly hired employees with state human service agencies (as mandated by federal law) or processing eligibility and enrollment (E&E) for State Children's Health Insurance Programs (SCHIP). One of the challenges of outsourcing is to understand each state's unique business process requirements, then develop systems that are flexible enough to be used by multiple states, ones that can be easily customized to implement each state's unique policies and procedures.

The E&E line of business is relatively new for PSI. It's an area uniquely volatile in terms of requirements "churn." Federal and state legislation and policy-as well as program-level policy, procedures, funding and goals-all conspire to create an unusually large number of stakeholders with many needs, all of whom tend to keep the change orders flowing. In addition, we sometimes have to throw a case "over the wall" to another agency and wait to find out whether they will accept it or not. Currently, the integration with other agencies is done using batch files, and given the condition of our partners' technology, it'll be this way for another year or two.

These issues convinced us that our new E&E system had to be based on a flexible architecture - one that allowed for a generic system that we could quickly customize later; one that was easily adaptable in the field; and one that would fully support detailed but ever-changing operational workflows while letting us tune and/or overhaul them as our operations evolved.

In late 2003 we started reviewing our needs for a workflow solution that would integrate both people and systems in the basic architecture we had already developed. We considered some of the existing commercial workflow products, but they didn't fit our needs. We were seriously considering writing our own simple workflow definition language and execution engine when BPEL entered the picture. It was perfect timing: here was a process definition language that modeled all the things we thought our own invented language would need to have, but one that was open, supported by a consortium of major vendors, and had a good chance of becoming a widely supported standard. But the various ways that BPEL let us integrate with partners - by enlisting them directly in our workflow, for example - was what sealed the deal. After evaluating the various BPEL product offerings on the market, we selected Collaxa BPEL Server, which has since been acquired by Oracle and renamed Oracle BPEL Process Manager.

State Children's Health Insurance Program
As we've said, PSI is using BPEL as part of a new application to support our SCHIP E&E outsourcing business line. We're developing the solution with a specific state as the target, but with a strong emphasis on making the system generic and customizable enough to take it to other states, and even to other kinds of operations.

SCHIP is a state program that offers state-subsidized health insurance coverage to individuals whose incomes are too high to be covered by Medicaid but too low to afford private health insurance. Because it targets people of certain income ranges, applicants must pass an eligibility test.

Here's an example of a high-level flow that occurs when a SCHIP application is processed:

1. The applicant submits a completed paper application form for SCHIP coverage.
2. The form is scanned and the image is sent to a data entry operator, who enters the data into the application.
3. The system checks for data completeness, making sure that all required fields have been filled out, and, in some cases, verifying that required documentation (such as pay stubs and proof of citizenship) has been submitted.
4. If the data is incomplete, a sub-workflow to make the application complete is launched.
5. If the data is complete, the eligibility determination process is called. This process is based on the ILOG JRules product that uses a ruleset customized to the state's SCHIP eligibility determination criteria.
6. The application is approved, denied or, in some cases, referred to another agency such as Medicaid.
7. If the application is approved, a new workflow is launched to complete the applicant's enrollment, matching the applicant with a specific Managed Care Organization and physician.
8. If the application is denied, a letter of denial is sent and the workflow ends.
9. If the application is referred, a new workflow is launched to refer the case to the corresponding agency.

Heterogeneous Environments and XML
One of the BPEL's strengths is its ability to integrate heterogeneous environments. In the example illustrated in Figure 1, processing a SCHIP account involves a BPEL flow that calculates eligibility for the beneficiary members of a family account. The process will perform three steps without human intervention:

1. Calculate eligibility for the account
2. Invoke a transaction-safe letter-generation sub-process
3. Queue letters to the family by looping through family members

Since BPEL communicates with XML documents to its partner links, we defined all of the account and eligibility results data in a common XML Schema. This schema is imported into WSDL (Web Service Definition Language) files for both BPEL and our own custom Web Services. We also use XPath to access and manipulate data. Because each person can be individually eligible, the BPEL "while" construct is used to iterate through the Eligibility Result array and call the correspondence session bean interface.

Transactions and Exceptions
Additionally, the correspondence sub-process is defined as "supporting transactions." As a result, the session bean that participates in the transaction can be rolled back if there's a failure in persisting correspondence data, or any other exception.

Exceptions have also been leveraged at multiple levels in our eligibility process. WSIF lets you map a Java exception to an XML-based exception, which can then be caught in our process with the BPEL "catch" construct. Also, the child sub-process can throw an exception back to the calling parent process. At the BPEL level you can catch specific exceptions or all exceptions with the "catchall" construct. BPEL "scopes" helped in our design process by providing more finely grained exception handling in sections of the workflow.

As presented in Figure 2, suppose a custom Java exception is thrown by the session bean. This notifies the caller that the correspondence request wasn't queued. The WSIF layer then translates the Java exception into a XML fault, which is defined in the WSDL for the correspondence session bean. Once the exception has been caught in the correspondence process, the BPEL process creates a new OpusException and copies appropriate data into the new general exception. Finally, the OpusException is caught by the parent process, and is handled by queuing it on a JMS dead-letter queue. Having a custom exception facility lets us create our own exceptions and write a single handler for it in the parent process.

User Task Architecture
The SCHIP healthcare application workflow is a mixture of human- and system-oriented tasks. We devised a delegation model between BPEL and our external user application to fulfill this requirement. A typical user task in the SCHIP application is the quality assurance step. When a potential recipient of benefits files an application, the information received is checked for validity against a paper record or some other verification source. The human interaction necessarily makes this response asynchronous. For example, when an applicant's income is verified, the person verifying the data will compare the income against paper records and/or online data to make sure the data reported is accurate. This process will not occur immediately. Also, the verifier role may involve special attributes and these must be managed during the delegation.

As seen in Figure 3, the application intake process has a quality assurance step that requires a human to verify income from a received application. This delegation to the user is considered asynchronous and has the extra constraint of duration. A scope that contains the Verification Response activity is defined for three days; if the user doesn't respond during that time the BPEL engine will trigger an alarm event. The event handler for the alarm (not shown in Figure 3) typically re-queues the item to an administrator, who resolves the item by reassigning it. When the user completes a user task it is returned to the workflow with a specific resolution code. The workflow uses conditional branching and performs the appropriate activity so the application processing will continue along a defined path. This workflow illustrates the potential human action required to clear up data inconsistencies (the sub-flow beginning with "Queue Phone Call"); the optimal approach is to minimize the number of cases going to this branch.

Performance
Performance was an important factor in choosing Oracle BPEL Process Manager. Although we're not yet in production, we feel good about the capacity and scalability of the system we're designing. Early on we undertook several stress tests to show how many BPEL workflows we could have in flight at any given time, and we've repeated these tests several times. Our tests show we can handle the tens of thousands of in-flight workflows a day that we anticipate encountering in production.

Conclusion
At this point, we're creating the library of Web Services we need to complete the functionality required by the system. Orchestrating all of these Web Services with BPEL has given us a high degree of flexibility. In fact, our experience with BPEL has convinced us that it's the right solution for the workflow needs of the SCHIP application, and we're looking for other places to use it as well.

As we near production, we're starting to look into day-to-day operational issues. Clear usage numbers provided by the Business Activity Monitoring (BAM) features in the Oracle BPEL Process Manager will help us assess potential costs for the manual workflow steps and re-engineer internal processes to create more inexpensive and automated workflows.

BPEL is getting a lot of attention, and rightly so. The flexibility it provides in orchestrating Web Services, coupled with its ability to implement real-time workflows, will give us a winning edge that will help us react quickly and efficiently to our ever-changing business requirements.