Building Synchronous and Asynchronous Business Processes

Business Processes are synchronous or asynchronous, depending on which method you choose to invoke your business process. However, both methods can contain both types of activity.

• Synchronous—A business process that is invoked by a synchronous method. In other words, the Starting Event is represented by a Client Request with Return node or a Synchronous Subscription node.

A synchronous business process can contain asynchronous operations, but they must be added after the starting event in the process flow. That is, at run time, the processes are executed after the synchronous starting event is complete. You cannot put stateful logic inside a synchronous operation. To learn more about stateful and stateless business processes, see Building Stateless and Stateful Business Processes.

Note: If your synchronous process requires asynchronous operations within the Client Request with Return node, see Synchronous Clients for Asynchronous Business Processes.

• Asynchronous—A business process that is invoked by an asynchronous method. In other words, the Starting Event is represented by an asynchronous node. This includes business processes that are invoked via a Client Request node, an Asynchronous Subscription node, or one of several Client Request or Subscription nodes (that is, an Event Choice node). A asynchronous process can call a synchronous or asynchronous methods without additional configuration.
• Synchronous to Asynchronous—Enables synchronous clients to interact with business processes that have asynchronous interactions with resources. To learn more, see Synchronous Clients for Asynchronous Business Processes.

Working with Subprocesses

A subprocess is any process that is called to from your business process through a process control or a service broker control. They can be called synchronously or asynchronously.

Synchronous Subprocesses

The Process control allows a business process (also a WebLogic Workshop Web service or pageflow) to send requests to (and receive callbacks from) another business process. Process control invocations are Java Remote Method Invocation (RMI) calls. The target business process must be hosted on the same WebLogic Server domain as the caller. Transaction contexts are propagated from the parent processes to the subprocesses over the Process control calls.

The Service Broker control allows a business process (or a Web service) to invoke and receive callbacks from another service using one of several protocols; the most commonly used protocol is SOAP over HTTP. (To learn about the protocols, see Using Dynamic Binding.) The target service must expose a WSDL interface. Because the transport used is HTTP or JMS, the transaction contexts are not propagated over the Service Broker control calls.

A synchronous subprocess called through a Process control runs in the same transaction as its caller (parent) process. Synchronous subprocesses behave differently than asynchronous subprocesses, particularly when it comes to un-handled exceptions.

An un-handled exception in a subprocess causes the shared transaction to be marked as rollback only, which causes both the subprocess and the caller (parent) process to roll back. This behavior is the default because it prevents a scenario in which one of the processes is rolled back, leaving the other process in an inconsistent or uncompensated state.

You can override the default behavior by setting the on sync failure property for the subprocess to rethrow. You do so in the Property Editor in the WebLogic Workshop graphical design environment.

To Configure the On Sync Failure Property

1. In the Design View, select the Start node of the subprocess for which you want to configure the on sync failure property.

Note: If the Property Editor is not visible, from the menu bar, choose View —> Property Editor.

2. In the Property Editor, from the on sync failure drop-down menu, select rethrow.

Your subprocess is now configured to throw exceptions in the case of failure.

Note: Setting the on sync failure property does not force a rollback, it only causes the subprocess to throw an exception.

Asynchronous Subprocesses

For asynchronous operations, the transaction is never propagated to the subprocess. In other words, a subprocess runs in its own transaction. Messages sent to subprocesses are buffered on the process queue of the subprocess. The caller process considers message delivery successful if the message is properly delivered to the queue. Consequently, failure of the subprocess is not communicated to the caller. For example, an unhandled exception causes the subprocess to fail, but the caller process is not notified.

Note: The business process (JPD) generated session beans have a default time-out value of 300 seconds. If this value is insufficient and leads to the timing out of long-running processes, you can alter this value. Information about this value, is located in the WebLogic Server documentation; see "trans-timeout-seconds" in Programming WebLogic Enterprise JavaBeans in the weblogic-ejb-jar.xml Deployment Descriptor Reference, which is located at the following URL:

http://download.oracle.com/docs/cd/E13222_01/wls/docs81/ejb/DDreference-ejb-jar.html

Since asynchronous failure is not automatically visible to the caller business process, you should consider the following design pattern for your process to subprocess communication:

• Design your subprocess such that it contains multiple callbacks for communicating success or failure. For example, use an exception handler path to catch any thrown exceptions and add a node on the path that makes a callback to the caller process that communicates that there was a failure.
• Use an Event Choice node in the caller business process to block and wait for either type of callback (success or failure) and take action as appropriate, as illustrated in the following figure.

Synchronous Clients for Asynchronous Business Processes

You can enable synchronous clients to interact with business processes that have asynchronous interactions with resources. For example, a synchronous WebLogic Workshop client, such as a JSP or Portal page that uses a Java control, may need to invoke a business process and then block. While the client is blocking, the business process may perform asynchronous activities, such as enqueueing a JMS message and waiting for a JMS receive, and then return the response to the client, after which the client unblocks. The following figure demonstrates this scenario.

While it is not possible to create a synchronous process that requires asynchronous operations within a Client Request with Return node, as shown in the following figure (and indicated by on the Control Receive node), you can create an asynchronous process with Client Request and Client Response nodes that accomplishes this task. This business process will appear to be synchronous to clients that use its web service interface. Additionally, this scenario will work for Java clients created with the WebLogic Server clientgen utility or with a WebLogic Workshop entity that uses the Service Broker control.

To enable synchronous clients to interact with business processes that have asynchronous interactions with resources, you can create a business process with a Client Request node with an attribute property called sync/async callback name. This Client Request node property holds the name of the callback method used by the associated Client Response node. The Client Request and Client Response nodes delineate the activities (including asynchronous activities) that occur while the client is blocking. After setting this property, you need to generate the sync-to-async WSDL. The synchronous WSDL generation process replaces the SOAP address of the service with a modified SOAP address. The modified address causes the synchronous servlet to process the client request and subsequent return action. The generated service entry looks like the following:

Normal WSDL

<service name="syncAsync">
   <port name="syncAsyncSoap" binding="s0:syncAsyncSoap">
   <soap:address location="http://localhost:7001/SyncAsyncWeb/processes/syncAsync.jpd"/>
   </port>

Synchronous WSDL

<service name="syncAsync">
   <port name="syncAsyncSoap" binding="s0:syncAsyncSoap">
   <soap:address location="http://localhost:7001/sync2AsyncIM/SyncAsyncWeb/processes/syncAsync.sync2JPD"/>
   </port>

To learn how to generate the sync-to-async WSDL, see To Generate a Sync-to-Async WSDL File.

Note: To see an example of a synchronous client that invokes an asynchronous business process and waits (blocks) for the process to return information, see Solution Samples, which is located at the following URL:

http://download.oracle.com/docs/cd/E13214_01/wli/docs81/sol_samples/index.html

To Create a Synchronous Client for an Asynchronous Processes

Note: Before designing your business process, be sure to read the Limitations section.

1. In Design View, create a business process with a Client Request as the Starting Event.
2. From the Palette, drag-and-drop the following nodes between the Client Request and Finish nodes:

Note: If the Palette is not visible in WebLogic Workshop, from the WebLogic Workshop menu, choose View —> Windows —> Palette.

1. Control Send
2. Control Receive
3. Client Response

The business process should now resemble the business process on the left side of the following figure.



3. Configure each node as required by your design.
4. In the Design View, click the Client Request node.
5. In the Property Editor, click the sync/async callback name field, then enter the name of the callback method. You can find this name in the method name property in the associated Client Response node.

If you enter the wrong name, an appears next to the Client Request node.

Note: If the Property Editor is not visible, from the menu bar, choose View —> Property Editor.

6. Generate a Sync-to-Async WSDL file, as described in To Generate a Sync-to-Async WSDL File.
7. To learn about security for these processes, see Synchronous-Asynchronous Security.

To Generate a Sync-to-Async WSDL File

WSDL files are used to communicate interface information between web service producers and consumers. A WSDL description allows a client to utilize a web service's capabilities without knowledge of the implementation details of the web service. To learn more about WSDL files, see WSDL Files: Web Service Descriptions.

Note: Before you can generate a WSDL file, you must first set the sync/async callback name attribute property on the Client Request node.

1. In the Application pane, right-right click the business process (JPD) for which you want to generate the WSDL file.

Note: If the Application pane is not visible in WebLogic Workshop, from the menu bar, choose View Application.

2. From the drop-down menu, choose Generate Sync/Async WSDL File.

WebLogic Workshop generates the WSDL file and displays it in the Application pane directly below the JPD file. If the name of the JPD is HelloWorld.jpd, the name of the WSDL file would be HelloWorldSyncContract.wsdl.

Limitations

Mixing of Synchronous and Asynchronous Pairs is Not Allowed

You cannot mix synchronous and asynchronous Client Request and Client Response pairs in the same business process. Mixing synchronous and asynchronous pairs causes an error when generating the Sync/Async WSDL for the business process.

A Client Request within a Synchronous Pair is Not Allowed

You cannot place a Client Request node inside of a synchronous pair.

A Synchronous Client Cannot Call an Asynchronous Process with SOAP Attachment in a Client Request Node

Attachments are supported only on HTTP SOAP 1.1 and HTTP SOAP 1.2 bindings. Calling an asynchronous process from a synchronous process requires that JMS SOAP to be set as a binding. Subsequently, this scenario is not supported because of the conflicting requirements.

Synchronous-Asynchronous Security

The SyncAsyncTransportServlet is a transport object in the web tier. It provides HTTP protocol support for invoking WebLogic Integration components that are synchronously invoked from asynchronous internal and external clients.

Synchronous invocations to business processes from asynchronous clients that arrive via HTTP are received by the SyncAsyncTransportServlet transport. You can set basic authentication security on specific business process URLs that are invoked with the J2EE Web application web.xml and weblogic.xml deployment descriptors of the SyncAsyncTransportServlet.

To learn about security and basic authentication, see "Developing Secure Web Applications" in Securing Web Applications in Programming WebLogic Security at http://download.oracle.com/docs/cd/E13222_01/wls/docs81/security/thin_client.html and Basic Authentication in the WebLogic Workshop Security Overview.

To Configure Basic Authentication for Resources Accessed via SyncAsyncServlet

The SyncAsyncTransportServlet is packaged within WebLogic Integration System EJBs. The deployment descriptor (web.xml) for this servlet is contained in the wli-ejbs.ear file. This file is located in the BEA_HOME\weblogic81\integration\lib directory, where BEA_HOME is the directory in which you installed the WebLogic Platform. The web.xml is located in the transport/http/WEB-INF directory in the wli-ejbs.ear file.

1. To add basic authentication security settings for the business process URLs that are invoked from the SyncAsyncTransportServlet, you must modify the web.xml for the servlet.
2. Follow the guidelines in Basic Authentication in the WebLogic Workshop Security Overview.

Related Topics

Transaction Boundaries

Starting Your Business Process

Building Stateless and Stateful Business Processes

Web Service Features in Business Processes

WSDL Files: Web Service Descriptions

Handling Exceptions

Calling Business Processes

Securing Web Applications

Basic Authentication