Building SOA portfolio Business Services, part 9th

Part 9th: Business process Parallel activity patterns oriented to flexibility and configuration

This article series focuses on the development of the Combined Business Services (CBS), and this article is the 9th part. You can either get CBS by combining existing SOA services, or create a CBS as a new service, all of which are designed to provide a configurable nature. This article describes the parallel activity patterns used to design business Process Execution Language (BPEL) processes for CBS. This article provides an example of a bank use case that implements this pattern to create flexible, configurable business processes in simple applications built from CBS. This article describes a solution that uses BPEL parallel activities to implement practical use cases. Multiple concurrent processes can be instantiated, and the number of concurrent processes is indeterminate and can be specified by the business object at run time. This article begins with a brief introduction to the parallel activity pattern, and then provides a loan request use case where you will learn how to use the parallel activity pattern for flexibility and configuration.

Review Loan Request Use cases

You can view the other articles in this series to get detailed information about this use case scenario so far. In this scenario, the loan request use case is triggered when a bank customer applies for a loan product using the bank's Web portal. The submission of a loan application from a bank, web-based user interface will invoke the loan approval BPEL process. This process retrieves his social security number from the customer's profile and uses this number to invoke a credit check BPEL process to implement the parallel activity pattern. The credit check BPEL obtains a list of credit scores from multiple agents and returns the list to the loan approval process. Depending on the actual credit score in the list returned by the credit check BPEL process, the loan request can be automatically rejected or approved, or forwarded for manual review. The average credit score is calculated based on the list returned by the credit check BPEL process, and the corresponding decision is made through a set of business rules based on this score.

When a loan request requires manual approval, the loan approval process invokes another BPEL sub-process, which includes the use of human tasks. Forward the credit score list to this BPEL sub-process. The bank will check the credit score list and additional information related to the applicant and decide whether the loan request should be approved.

Using the parallel activity pattern

When you start designing a BPEL process, you can use any pattern, such as synchronous mode, state-based mode, or different types of parallel activity patterns (see Resources). This section introduces a parallel activity pattern that does not need to know the number of concurrent activities in a BPEL design. This pattern can concurrently invoke multiple BPEL process instances, until the runtime is able to determine the number of instances to invoke. This pattern also ensures that all process instances are completed before the workflow ends. The upcoming Ws-bpel 2.0 specification includes this parallel activity pattern, which uses a new BPEL ForEach activity and an associated flag for a sub-process parallel invocation. This article describes how to follow the parallel activity pattern and use the existing Websphere®integration Developer 6.0 tools to implement each of these activities. Figure 1 illustrates this pattern:

Figure 1. Parallel activity Mode

The parent BPEL process named Multiinvokerun (shown in the top half of Figure 1) uses a repeating, one-way (asynchronous) invocation of a circular element named InvokeAll (shown in the upper-left part of Figure 1). The second loop, called Waitreplies (shown in the upper-right section of Figure 1), runs in parallel and is used to receive notifications when the Sub-Process (the multiinvokechild process described in the lower part of Figure 1) completes. Before the first call, for Each loop, a counter is initialized in the setupcounters activity of the multiinvokerun process. This counter can be used at run time to help specify the number of subprocesses. The waitreplies loop does not end until you receive a notification from all subprocesses. When the waitreplies loop ends, the parent BPEL process Multiinvokerun is completed.