News Desk

Digg This!

Page 2 of 2   « previous page

This example is based on a multi-organizational process that creates accounts for a financial service intermediary, its financial partners (insurance companies and their financial advisors), mutual fund companies, and clearinghouses. This value chain of partners collaborates to make the "New Account" business process more efficient and compliant. Each partner has compliance requirements that must be satisfied during the instantiation of the process. Regulations such as the U.S. Patriot Act, the Bank Secrecy Act, and other federal and state regulations apply and add requirements to the process for both automated system and human workflow interactions.

The example combines business process management through BPEL to orchestrate business processes in a B2B context, managing compliance in a secure environment, while greatly enhancing the efficiency of the overall process. This approach was selected because it makes the organization resilient to ongoing threats from a regulatory and competitive standpoint. These requirements were incorporated into the "New Account" business process, including the following key requirements:

• Common interfaces for maximum interoperability
• Comprehensive security, as each environment has firewall and other security requirements
• Audit trails and monitoring for compliance, security, and performance reasons

As with most business processes that require automation, human interactions play a large role in this business process. Workflow requirements for the process include:

• Electronic data routing (intra-organization as well as inter-organization)
• Data verification and approval of provided information
• Workflow routing to other departments with notification
• Escalation as a result of exceptions and/or alerts
• Approval of the entire heterogeneous transaction
• The need for workflow requirements to interact seamlessly with automated business process steps and existing enterprise information

BPEL fit these requirements perfectly and can also address security concerns due to its foundation of Web Services and integration with specifications such as WS-Security and SAML. Enterra, the company that developed this process, first evaluated how a BPEL server could function as both a process automation and workflow tool. Since workflow specifications for BPEL are evolving, as described above, the decision was based on the following criteria:

• Maturity of the BPEL product
• Support for workflow from BPEL
• Native support for relevant standards
• Ease of development, maintenance, and deployment
• Satisfying the process monitoring and audit capabilities
• Using a single security model supported by BPEL
• Taking advantage of BPEL's built-in transaction semantics

Oracle BPEL Process Manager was the selected product based on these criteria.

Workflow Interface Architecture and Benefits
Enterra used Oracle's BPEL Process Manager engine and its Java API to build an enterprise-ready resilient workflow architecture. Figure 2 shows that architecture.

The following describes the workflow:

1. The Rich Internet Interface (RIA) workflow portal instantiates the business process via the BPELService API
2. The instance ID of the process is captured to maintain state
3. When a task is initiated in the process, a correlation ID is captured
4. The payload data is sent to the task and is available via the worklist interface
5. The API pulls the worklist data and uses the correlation ID to gather the XML metadata to return to the RIA. The RIA uses the metadata to dynamically determine which panel to display next and to update the context of the visual navigation mechanisms used in the workflow portal. This data is returned to the portal and all the update events are processed.

To implement the workflow scenario shown here, Enterra developed the Rich Internet Interface and used Java APIs to interact with the Oracle BPEL Process Manager Workflow Service. The RIA user interface is the face of the application; it runs and manages the "New Account" business process. The presentation layer is built using Macromedia's Flex technology and ActionScript scripting language. It accepts the user input and passes it to the BPEL process and also displays the current status of the process. Figure 3 shows the RIA front-end for the New Account business process.

Let's review its four main components and their key capabilities:

1)  Workflow Bar: This lets users view the workflow steps in the New Account process at the business level. Every step in the Workflow Bar is displayed in a detail view in the BPEL Panel.

2)  BPEL Panel: The BPEL Panel offers an exploded view of every step of the New Account process. The panel dynamically loads the process model and the audit trail of a given process instance to combine the process paths available with the paths actually taken by the current instance. The panel also uses the audit trail to determine what action is pending, visually delineating where the current process is at that time. Previously executed nodes of the process can be clicked on to view their respective payload. This functionality gives operations and compliance managers real-time visibility into the past, current, and potentially future states of the current process. This panel is dynamically populated at runtime using the BPEL Process Manager API.

3)  Workflow Forms: These correspond to the workflow steps in the New Account BPEL process. This view stack (developed in Macromedia Flex) communicates with the audit trail of the business process, changing the view stack form to match the context of the BPEL process. When considering different architectural approaches, we found that the RIA application would have been much more difficult to build if the data had come from two different applications (workflow and BPM). A single platform made it much easier to build a unified interface for the business user.

4)  Zone Panels: Zone Panels provide alerts and feedback to help workflow and process activity users perform their respective tasks. These panels offer a superior usability experience and interact with the BPEL API. As the context of the business process changes, the Zone Panels are updated. The events that manage these changes are propagated through the Oracle BPEL Process Manager API.

5)  BPEL Process Manager: The BPELService class facilitates interaction between the RIA front-end and the process activity monitoring capabilities in Oracle BPEL Process Manager.

The RIA interface also provides detailed audit trails views and other business process and workflow alerts in real-time. The combination of BPEL, workflow, and RIA provides a compelling architecture for addressing compliance, security, and performance metrics.

The benefits of the New Account business process implementation are:

• Maximum interoperability without compromising security
• Real-time monitoring and auditing of the entire environment
• Robust workflow capabilities integrated cleanly in the BPEL environment
• An enterprise-ready infrastructure that supports transactions, availability, and advanced exception handling

Conclusion
When automating business processes, it's critical to include the element of human interaction in the design. Standards play a key role in business process automation, and BPEL is clearly the de facto standard for process execution, but human workflow doesn't have such a single widely adopted standard. In this article, we've highlighted the options related to human workflow support in BPEL, discussed the emergence of BPEL workflow extensions, shown how to incorporate workflow into BPEL servers today, and presented a real-world BPEL process that includes human workflow.

Acknowledgments
We would like to thank Harish Gaur and Dave Shaffer for their helpful comments.

Page 2 of 2   « previous page