|
|
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.
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. |
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.
The Process control allows a business process (also a BEA WorkSpace Studio 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. 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 JPD Configuration view in the BEA WorkSpace Studio graphical design environment.
| Note: | If the JPD Configuration view is not visible, from the menu bar, choose Window > Show View > JPD Configuration. |
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. |
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 (Java file) 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. |
| Note: | 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: |
You can enable synchronous clients to interact with business processes that have asynchronous interactions with resources. For example, a synchronous BEA WorkSpace Studio 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.Figure 23-2 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 BEA WorkSpace Studio entity that uses the Service Broker control. See Figure 23-3.
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:
<service name="syncAsync">
<port name="syncAsyncSoap" binding="s0:syncAsyncSoap">
<soap:address location="http://localhost:7001/SyncAsyncWeb/processes/syncAsync.jpd"/>
</port>
<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. |
| Note: | Before designing your business process, be sure to read the Limitations section. |
| Note: | If the Node Palette is not visible in BEA WorkSpace Studio, from the BEA WorkSpace Studio menu, choose Window > Show View > Node Palette. |
The business process should now resemble the business process on the left side as shown in Figure 23-4.
If you enter the wrong name, an appears next to the Client Request node.
| Note: | If the JPD Configuration view is not visible, from the menu bar, choose Window > Show View > JPD Configuration. |
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.
| Note: | Before you can generate a WSDL file, you must first set the sync/async callback name attribute property on the Client Request node. |
> Sync/Async WSDL.
BEA WorkSpace Studio generates the WSDL file and displays it in the Package Explorer pane directly below the Process.java file. If the name of the Java file is HelloWorld.java, the name of the WSDL file would be HelloWorldSyncContract.wsdl.
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.
You cannot place a Client Request node inside of a synchronous pair.
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.
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.
The SyncAsyncTransportServlet is packaged within WebLogic Integration System EJBs. The deployment descriptor (web.xml) for this servlet is contained in the jpd-ejbs.ear file. This file is located in the BEA_HOME\weblogic92\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 jpd-ejbs.ear file. 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.
Starting Your Business Process
Building Stateless and Stateful Business Processes
|
