Oracle SOA BPEL Design Patterns

Referred from Oracle docs:

6.1 Introduction to One-Way Messages

In a one-way message, or fire and forget, the client sends a message to the service (d1 in Figure 6-1), and the service does not need to reply. The client sending the message does not wait for a response, but continues executing immediately. Example 6-1 shows the portType and operation part of the BPEL process WSDL file for this environment.

Example 6-1 One-Way WSDL File

. . .
<wsdl:portType name="BPELProcess1">
      <wsdl:operation name="process">
         <wsdl:input  message="client:BPELProcess1RequestMessage" />
      </wsdl:operation>
</wsdl:portType>
. . .

Figure 6-1 provides an overview.

Figure 6-1 One-Way Message

Description of "Figure 6-1 One-Way Message"

BPEL Process Service Component as the Client

As the client, the BPEL process service component needs a valid partner link and an invoke activity with the target service and the message. As with all partner activities, the Web Services Description Language (WSDL) file defines the interaction.

BPEL Process Service Component as the Service

To accept a message from the client, the BPEL process service component needs a receive activity.

6.2 Introduction to Synchronous Interactions

In a synchronous interaction, a client sends a request to a service (d1 in Figure 6-2), and receives an immediate reply (d2 in Figure 6-2). A BPEL process service component can be at either end of this interaction, and must be coded based on its role as either the client or the service. For example, a user requests a subscription to an online newspaper and immediately receives email confirmation that their request has been accepted. Example 6-2 shows theportType and operation part of the BPEL process WSDL file for this environment.

Example 6-2 Synchronous WSDL File

. . .
<wsdl:portType name="BPELProcess1">
      <wsdl:operation name="process">
         <wsdl:input  message="client:BPELProcess1RequestMessage" />
         <wsdl:output message="client:BPELProcess1ResponseMessage"/>
      </wsdl:operation>
</wsdl:portType>

Figure 6-2 provides an overview.

Figure 6-2 Synchronous Interaction

Description of "Figure 6-2 Synchronous Interaction"

BPEL Process Service Component as the Client

When the BPEL process service component is on the client side of a synchronous transaction, it needs an invoke activity. The port on the client side both sends the request and receives the reply. As with all partner activities, the WSDL file defines the interaction.

BPEL Process Service Component as the Service

When the BPEL process service component is on the service side of a synchronous transaction, it needs a receive activity to accept the incoming request, and a reply activity to return either the requested information or an error message (a fault; f1 in Figure 6-2) defined in the WSDL.
For more information about synchronous interactions, see Chapter 8, "Invoking a Synchronous Web Service from a BPEL Process."

6.3 Introduction to Asynchronous Interactions

In an asynchronous interaction, a client sends a request to a service and waits until the service replies. Example 6-3 shows the portType and operation part of the BPEL process WSDL file for this environment.

Example 6-3 Asynchronous WSDL File

. . .
<wsdl:portType name="BPELProcess1">
      <wsdl:operation name="process">
         <wsdl:input message="client:BPELProcess1RequestMessage"/>
      </wsdl:operation>
</wsdl:portType>

. . .
<wsdl:portType name="BPELProcess1Callback">
      <wsdl:operation name="processResponse">
         <wsdl:input message="client:BPELProcess1ResponseMessage"/>
      </wsdl:operation>
</wsdl:portType>

Figure 6-3 provides an overview.

Figure 6-3 Asynchronous Interaction

Description of "Figure 6-3 Asynchronous Interaction"

BPEL Process Service Component as the Client

When the BPEL process service component is on the client side of an asynchronous transaction, it needs an invoke activity to send the request and a receive activity to receive the reply. As with all partner activities, the WSDL file defines the interaction.

BPEL Process Service Component as the Service

As with a synchronous transaction, when the BPEL process service component is on the service side of an asynchronous transaction, it needs a receive activity to accept the incoming request and an invoke activity to return either the requested information or a fault. Note the difference between this and responding from a synchronous BPEL process: a synchronous BPEL process uses a reply activity to respond to the client and an asynchronous service uses an invoke activity.
For more information about asynchronous interactions, see Chapter 9, "Invoking an Asynchronous Web Service from a BPEL Process."

6.4 Introduction to Asynchronous Interactions with a Timeout

In an asynchronous interaction with a timeout (which you perform in BPEL with a pick activity), a client sends a request to a service and waits until it receives a reply, or until a certain time limit is reached, whichever comes first. For example, a client requests a loan offer. If the client does not receive a loan offer reply within a specified amount of time, the request is canceled. Figure 6-4 provides an overview.

Figure 6-4 Asynchronous Interaction with Timeout

Description of "Figure 6-4 Asynchronous Interaction with Timeout"

BPEL Process Service Component as the Client

When the BPEL process service component is on the client side of an asynchronous transaction with a timeout, it needs an invoke activity to send the request and a pick activity with two branches: an onMessage branch and an onAlarm branch. If the reply comes after the time limit has expired, the message goes to the dead letter queue. As with all partner activities, the WSDL file defines the interaction.
For more information about asynchronous interactions with a timeout, see Section 14.2, "Creating a Pick Activity to Select Between Continuing a Process or Waiting."

BPEL Process Service Component as the Service

The behavior of the BPEL process service component as a service is equal to the behavior with the asynchronous interaction with the BPEL process service component as the service.

6.5 Introduction to Asynchronous Interactions with a Notification Timer

In an asynchronous interaction with a notification time, a client sends a request to a service and waits for a reply, although a notification is sent after a timer expires. The client continues to wait for the reply from the service even after the timer has expired. Figure 6-5 provides an overview.

Figure 6-5 Asynchronous Interaction with a Notification Time

Description of "Figure 6-5 Asynchronous Interaction with a Notification Time"

BPEL Process Service Component as the Client

When the BPEL process service component is on the client side of this transaction, it needs a scope activity containing an invoke activity to send the request, and a receive activity to accept the reply. The onAlarm handler of the scope activity has a time limit and instructions on what to do when the timer expires. For example, wait 30 minutes, then send a warning indicating that the process is taking longer than expected. As with all partner activities, the WSDL file defines the interaction.

BPEL Process Service Component as the Service

The behavior for the BPEL process service component as the service is equal to the behavior with the asynchronous interaction with the BPEL process service component as the service.

6.6 Introduction to One Request, Multiple Responses

In this interaction type, the client sends a single request to a service and receives multiple responses in return. For example, the request can be to order a product online, and the first response can be the estimated delivery time, the second response a payment confirmation, and the third response a notification that the product has shipped. In this example, the number and types of responses are expected. Figure 6-6 provides an overview.

Figure 6-6 One Request, Multiple Responses

Description of "Figure 6-6 One Request, Multiple Responses"

BPEL Process Service Component as the Client

When the BPEL process service component is on the client side of this transaction, it needs an invoke activity to send the request, and a sequence activity with three receive activities, one for each reply. As with all partner activities, the WSDL file defines the interaction.

BPEL Process Service Component as the Service

The BPEL service needs a receive activity to accept the message from the client, and a sequence attribute with three invoke activities, one for each reply.

6.7 Introduction to One Request, One of Two Possible Responses

In an interaction using one request and one of two possible responses, the client sends a single request to a service and receives one of two possible responses. For example, the request can be to order a product online, and the first response can be either an in-stock message, or an out-of-stock message. Figure 6-7 provides an overview.

Figure 6-7 One Request, One of Two Possible Responses

Description of "Figure 6-7 One Request, One of Two Possible Responses"

BPEL Process Service Component as the Client

When the BPEL process service component is on the client side of this transaction, it needs the following:

• An invoke activity to send the request
• A pick activity with two branches: one onMessage for the in-stock response and instructions on what to do if an in-stock message is received
• A second onMessage for the out-of-stock response and instructions on what to do if an out-of-stock message is received

As with all partner activities, the WSDL file defines the interaction.
For more information about interactions using one request and one of two possible responses, see Section 14.2, "Creating a Pick Activity to Select Between Continuing a Process or Waiting."

BPEL Process Service Component as the Service

The BPEL service needs a receive activity to accept the message from the client, and a switch activity with two branches, one with an invoke activity sending the in-stock message if the item is available, and a second branch with an invoke activity sending the out-of-stock message if the item is not available.

6.8 Introduction to One Request, a Mandatory Response, and an Optional Response

In this type of interaction, the client sends a single request to a service and receives one or two responses. Here, the request is to order a product online. If the product is delayed, the service sends a message letting the customer know. In any case, the service always sends a notification when the item ships. Figure 6-8 provides an overview.

Figure 6-8 One Request, a Mandatory Response, and an Optional Response

Description of "Figure 6-8 One Request, a Mandatory Response, and an Optional Response"

BPEL Process Service Component as the Client

When the BPEL process service component is on the client side of this transaction, it needs a scope activity containing the invoke activity to send the request, and a receive activity to accept the mandatory reply. The onMessage handler of the scope activity is set to accept the optional message and instructions on what to do if the optional message is received (for example, notify you that the product has been delayed). The client BPEL process service component waits to receive the mandatory reply. If the mandatory reply is received first, the BPEL process service component continues without waiting for the optional reply. As with all partner activities, the WSDL file defines the interaction.

BPEL Process Service Component as the Service

The BPEL service needs a scope activity containing the receive activity and an invoke activity to send the mandatory shipping message, and the scope's onAlarm handler to send the optional delayed message if a timer expires (for example, send the delayed message if the item is not shipped in 24 hours).

6.9 Introduction to Partial Processing

In partial processing, the client sends a request to a service and receives an immediate response, but processing continues on the service side. For example, the client sends a request to purchase a vacation package, and the service sends an immediate reply confirming the purchase, then continues on to book the hotel, the flight, the rental car, and so on. This pattern can also include multiple shot callbacks, followed by longer-term processing. Figure 6-9provides an overview.

Figure 6-9 Partial Processing

Description of "Figure 6-9 Partial Processing"

BPEL Process Service Component as the Client

In this case, the BPEL client is simple; it needs an invoke activity for each request and a receive activity for each reply for asynchronous transactions, or just an invoke activity for each synchronous transaction. Once those transactions are complete, the remaining work is handled by the service. As with all partner activities, the WSDL file defines the interaction.

BPEL Process Service Component as the Service

The BPEL service needs a receive activity for each request from the client, and an invoke activity for each response. Once the responses are finished, the BPEL process service component as the service can continue with its processing, using the information gathered in the interaction to perform the necessary tasks without any further input from the client.

6.10 Introduction to Multiple Application Interactions

In some cases, there are more than two applications involved in a transaction, for example, a buyer, seller, and shipper. In this case, the buyer sends a request to the seller, the seller sends a request to the shipper, and the shipper sends a notification to the buyer. This A-to-B-to-C-to-A transaction pattern can handle many transactions at the same time. Therefore, a mechanism is required for keeping track of which message goes where. Figure 6-10 provides an overview.
As with all partner activities, the WSDL file defines the interaction.

Figure 6-10 Multiple Party Interactions

Description of "Figure 6-10 Multiple Party Interactions"

When to use OSB and When use BPEL

Oracle OSB:  If the primary requirement is for a solutions to accomplish  content based routing,transformation,message validations,enrichments and the integration is enterprise wide and features like message throttling,service virtualization,Reliable messaging are important,the Oracle Service Bus is a great fit .

Oracle BPEL: If the requirement is for a solution to design, manage and run business processes which are stateful with functionalities like Human Workflow,Business Rules,monitoring and management and composite service implementations,the choice should be BPEL.

Java Emberd in Oracle SOA BPEL Notes

Reference Links:

• Create a PDF report from java jar file and call this jar file from BPEL process
• Set instance name from java emberd
• 
  

Steps to Invoke Asynchronous webservice from Oracle SOA

In earlier post we have seen how to create Asynch Webservice(BPEL Process) and test this Asynch service using SOAP UI.

In this post we will see how to call the Asynch Webservice(BPEL Process) within the SOA.

Here we invoke the Asynch service as syncronus webservice and only difference is we need to set the "replyToAddress".

replyToAddress = Callback URL.

Background:
Step 1. Create a Asynchronous webservice - link for reference

Step 2. Create a webservice for the client call back.
               * This service is required to be created in client end such that Asynch service which is                              created in            step 1 can replyback to the client.
               * This service should be created based on the schema of callback port of asych webservice.

Step 3: a. Create a new BPEL service which invokes the Asynchronous webservice created in step 1
            b. Set the invoke property replyToAddress to the wsdl address of client webservice ie.,                             created in Step2

Create Asynchronous Webservice in Oracle SOA BPEL

We use the Asych Webservice for better performance for overall system.


Oracle SOA BPEL Asyncronus project can be downloaded from here

SOAPUI Project to invoke the Asynch ORacle SOA Webservice BPEL process can be downloaded from here

Steps Followed:
1. Create a SOA Project
2. Drag a BPEL process with the Template define later
3. Drag a websive with template as Asynchronous and provide the input xsd and callback post input xsd mapping check the below screenshot

4. Connect the Asynch webservice with the BPEL process.

5. Do a process in bpel and invoke the call the call port as below

6. Test the Asyncronus composite by following below steps using SOAPUI.

Asynchronous Web Service Testing in soapUI

When invoking an asynchronous web service, the caller must provide a callback for the response. Since our testing will originate from soapUI, then it is only natural that soapUI would provide the callback mechanism. This mechanism in soapUI is called a MockService. In a nutshell, a soapUI MockService is a simulation of a Web Service (aka, a process listening on a port). We will go through the steps in setting up the MockService for a simple asynchronous BPEL process.

After creating your soapUI project based on an asynchronous BPEL process, you will see something like the following:

Notice that soapUI created an interface for both the request and the response (i.e., callback). The interface that was created for the callback will be used to create the MockService. Right-click on the callback interface and select the Generate MockService menu item:

You will be presented with the Generate MockService dialogue where we will tweak the Path and possibly the port (depends upon what ports are available on the machine where soapUI will be running). We will adjust the Path to include the operation name (append /processResponse in this example) and the port of 8088 is fine:

Once the MockService is created, you should have something like the following in soapUI:

This window acts as a console/view into the callback process. When the play button is pressed (green triangle in the upper left-hand corner), soapUI will start a process running on the configured Port that will accept web service invocations on the configured Path:

At this point we are “almost” ready to try out the asynchronous test. But first we must provide the web service addressing (WS-A) configuration on the request message. We will edit the message for the request interface that was generated when the project was created (SimpleAsyncBPELProcessBinding > process > Request 1 in this example). At the bottom of the request message editor you will find the WS-A configuration by left-clicking on the WS-A label:

Here we will setup WS-A by changing the default values to:

1. Must understand: TRUE
2. Add default wsa:Action: Add default wsa:Action (checked)
3. Reply to: ${host where soapUI is running}:${MockService Port}${MockService Path} … in this example: http://192.168.1.181:8088/mockSimpleAsyncBPELProcessCallbackBinding/processResponse

We now are ready to run the asynchronous test from soapUI free edition. Make sure that the MockService you created is running and then push the play button for the request (green triangle in the upper left-hand corner of the request editor). If everything is configured correctly, you should see the response show up in the MockService window:

To view the response message/payload, just double-click on a response message in the Message Log window of the MockService:

At this point you can now expand the project to include a Test Suite for some load balance tests etc. This same topic has been covered in various detail on other sites/blogs, but I wanted to simplify and detail how this is done in the context of SOA Suite 11g. It also serves as a nice introduction to another blog of mine

Oracle SOA BPEL Transaction Option in Asynchronous BPEL

Asynchronous BPEL process is helpful in achieving higher performance of the system. While connecting the ASynch Webservice to the BPEL process we have  following transaction options

By default, incoming requests are saved in the following delivery service database tables: dlv_message

• async.persist: Messages are persisted in the database.

• sync.cache: Messages are stored in memory.

• sync: Direct invocation occurs on the same thread.

We need to select the transaction option based on requirement mainly based on recovery process.

If the process failed in the Asyncronus process then we can resubmit that process instead of restarted from the beginning.

Oracle SOA BPEL Validate activity usuage

The validateXML property validates incoming and outgoing XML documents. If set to True, the Oracle BPEL Process Manager applies schema validation for incoming and outgoing XML documents. Nonschema-compliant payload data is intercepted and displayed as a fault.