Oracle SOA MDS - Adding and updating MDS from JDeveloper

Lets examine how to create a MDS repository for new project. We need to following steps for creating and updating MDS

Adding files to MDS:
Step 1: Run RCU by checking the MDS which will create required tables for MDS

Step 2: Create MDS db connection from JDeveloper

Step 3: Create jar file in Jdeveloper and have all the required resources to be uploaded to MDS. (Will provide screenshot and explain it later)

Step 4: Deploy the Application (not jar project created in step 1!)

Step 5: Refresh the MDS DB in Jdeveloper, you will see all the required files.

Updating MDS Files:
Step 1: First download the MDS files from the EM to the jar project which was created in step 1 above.

To download mds file navigate to:
soa-infra -> Adminstration -> MDS Configuration  -> and then on the right side of the screen: Import.

Step 2: Update the any file in the jar file and add additional schemas/wsdl.

Step 3: Deploy the Application. Done
-----------------------------------------------------------------------------------------------------------------
Step 3 of creating jar file with soa-bundle is explained Antony  here

Creating Shared Resources in a JDeveloper Project

First lets create a JDeveloper project and put our shared resources into that project.  To do this

1. In a JDeveloper Application create a New Generic Project (File->New->All Technologies->General->Generic Project)
2. In that project create a New Folder called apps (File->New->All Technologies->General->Folder) – It must be called apps for local File MDS to work correctly.
3. In the project properties delete the existing Java Source Paths (Project Properties->Project Source Paths->Java Source Paths->Remove)
4. In the project properties a a new Java Source Path pointing to the just created apps directory (Project Properties->Project Source Paths->Java Source Paths->Add)
   

Having created the project we can now put our resources into that project, either copying them from other projects or creating them from scratch.

Create a SOA Bundle to Deploy to a SOA Instance

Having created our resources we now want to package them up for deployment to a SOA instance.  To do this we take the following steps.

1. Create a new JAR deployment profile (Project Properties->Deployment->New->Jar File)
2. In JAR Options uncheck the Include Manifest File
3. In File Groups->Project Output->Contributors uncheck all existing contributors and check the Project Source Path
4. Create a new SOA Bundle deployment profile (Application Properties->Deployment->New->SOA Bundle)
5. In Dependencies select the project jar file from the previous steps.
   
6. On Application Properties->Deployment unselect all options.
   

The bundle can now be deployed to the server by selecting Deploy from the Application Menu.

Create a Database Based MDS Connection in JDeveloper

Having deployed our shared resources it would be good to check they are where we expect them to be so lets create a Database Based MDS Connection in JDeveloper to let us browse the deployed resources.

1. Create a new MDS Connection (File->All Technologies->General->Connections->SOA-MDS Connection)
2. Make the Connection Type DB Based MDS and choose the database Connection and parition.  The username of the connection will be the <PREFIX>_mds user and the MDS partition will be soa-infra.

Browse the repository to make sure that your resources deplyed correctly under the apps folder.  Note that you can also use this browser to look at deployed composites.  You may find it intersting to look at the /deployed-composites/deployed-composites.xml file which lists all deployed composites.

Create an File Based MDS Connection in JDeveloper

We can now create a File based MDS connection to the project we just created.  A file based MDS connection allows us to work offline without a database or SOA server.  We will create a file based MDS that actually references the project we created earlier.

1. Create a new MDS Connection (File->All Technologies->General->Connections->SOA-MDS Connection)
2. Make the Connection Type File Based MDS and choose the MDS Root Folder to be the location of the JDeveloper project previously created (not the source directory, the top level project directory).
   

We can browse the file based MDS using the IDE Connections Window in JDeveloper.  This lets us check that we can see the contents of the repository.

Using File Based MDS

Now that we have MDS set up both in the database and locally in the file system we can try using some resources in a composite.  To use a WSDL from the file based repository:

1. Insert a new Web Service Reference or Service onto your composite.xml.
2. Browse the Resource Palette for the WSDL in the File Based MDS connection and import it.
   
3. Do not copy the resource into the project.
4. If you are creating a reference, don’t worry about the warning message, that can be fixed later.  Just say Yes you do want to continue and create the reference.
   

Note that when you import a resource from an MDS connection it automatically adds a reference to that MDS into the applications adf-config.xml.  SOA applications do not deploy their adf-config.xml, they use it purely to help resolve oramds protocol references in SOA composites at design time.  At runtime the soa-infra applications adf-config.xml is used to help resolve oramds protocol references.

The reason we set file based MDS to point to the project directory rather than the apps directory underneath is because when we deploy SOA resources to MDS as a SOA bundle the resources are all placed under the apps MDS namespace.  To make sure that our file based MDS includes an apps namespace we have to rename the src directory to be apps and then make sure that our file based MDS points to the directory aboive the new source directory.

Patching Up References

When we use an abstract WSDL as a service then the SOA infrastructure automatically adds binging and service information at run time.  An abstract WSDL used as a reference needs to have binding and service information added in order to compile successfully.  By default the imported MDS reference for an abstract WSDL will look like this:

<reference name="Service3"
   ui:wsdlLocation="oramds:/apps/shared/WriteFileProcess.wsdl">
  <interface.wsdl interface="http://xmlns.oracle.com/Test/SyncWriteFile/WriteFileProcess# wsdl.interface(WriteFileProcess)"/>
  <binding.ws port="" location=""/>
</reference>

Note that the port and location properties of the binding are empty.  We need to replace the location with a runtime WSDL location that includes binding information, this can be obtained by getting the WSDL URL from the soa-infra application or from EM.  Be sure to remove any MDS instance strings from the URL.

The port information is a little more complicated.  The first part of the string should be the target namespace of the service, usually the same as the first part of the interface attribute of the interface.wsdl element.  This is followed by a#wsdl.endpoint and then in parenthesis the service name from the runtime WSDL and port name from the WSDL, separated by a /.  The format should look like this:

{Service Namespace}#wsdl.endpoint({Service Name}/{Port Name})

So if we have a WSDL like this:

<wsdl:definitions
   …
   targetNamespace=
   "http://xmlns.oracle.com/Test/SyncWriteFile/WriteFileProcess">
   …   <wsdl:service name="writefileprocess_client_ep">
      <wsdl:port name="WriteFileProcess_pt"
            binding="client:WriteFileProcessBinding">
         <soap:address location=… />
      </wsdl:port>
   </wsdl:service>
</wsdl:definitions>

Then we get a binding.ws port like this:

http://xmlns.oracle.com/Test/SyncWriteFile/WriteFileProcess# wsdl.endpoint(writefileprocess_client_ep/WriteFileProcess_pt)

Note that you don’t have to set actual values until deployment time.  The following binding information will allow the composite to compile in JDeveloper, although it will not run in the runtime:

<binding.ws port="dummy#wsdl.endpoint(dummy/dummy)" location=""/>

The binding information can be changed in the configuration plan.  Deferring this means that you have to have a configuration plan in order to be able to invoke the reference and this means that you reduce the risk of deploying composites with references that are pointing to the wrong environment.

Advantage of Oracle AIA for Error Handling notification

Oracle Application Integration Architecture (AIA) delivers Pre-built services which can be reused in custom application.

Error Handling is one of the AIA pre-build application, this service can be used in our custom composite to handle fault such that we can achive various advantages some of them are

1. Achieving a canonical form of error handling across the system.

2. For an fault we can trigger an email asynchronously.  Such that we can offload(loosely couple) email trigger functionality from our application.

OSB Asynchronus service call with updating the callback header

OSB is constructed as client to consume the Asyncronus service. Lets consider we already build the Oracle SOA Asynchronous composite.

Lets create proxy service to consume the asyncronus service.

Flow 1:    Proxy 1 -> Business 1 -> SOA Asynchronous Composite 1

Create a proxy service and business service. Business service just consumes SOA Asynchronous composite.

Flow 2: SOA Asynchronous Composite 1 -> Proxy 2 -> Business service 2

Now we need to create a new proxy and business service, such that SOA can callback to this OSB service.

But how does SOA composite know the endpoint url of Proxy 2?!

Hence we need to pass the callback proxy service( proxy 2) endpoint url in the the header of proxy 1 before invoking the business service 1 as below.

 In this proxy service while routing to the business service add an assign activity to reply to appropriate client service.

<soap-env:Header xmlns:ns1="http://schemas.xmlsoap.org/ws/2003/03/addressing">

        <ns1:MessageID>ws:uniqueAddress</ns1:MessageID>

        <ns1:ReplyTo>

        <ns1:Address>http://localhost:8011/CallAsyncService/proxyServices/CallSyncCompositeProxy</ns1:Address>

         </ns1:ReplyTo>

 </soap-env:Header>

Handling Large File in BPEL/OSB

There are three ways to handle the large file in Oracle SOA BPEL/OSB:

1. Route the complete file from source to destination without tranformation:
If we need to route the payload(File) to the destination based on some condition check then we can make the input file as stream. This can be achieved by checking the "Use File Streaming" check box during file adaptor creation.

Point to be noted here is we cant use the file stream for passing the payload to target after tranformation as we cant load the large file in heap memory. File stream can be used when we need to pass the file as it to other destination with/without conditinal routing.


2.  Route small part the payload(file) from source to destination:
If we need to transform the smaller part of the payload then again we can use the file stream concept explain above. Only difference is we can transform the payload using XQUERY, where the transformed target payload SHOLD be small enough to load in memory.

Example: Consider there are millions of Claims records in a file, if our destination service can process only individual claims at time then  we can go with this approach.

3. Transfor comple large payload before routing:
To transform complete payload before routing we can use file batch. Enter the batch size in   "Publish Messages in Batches of" during adaptor creation.

Each batch will create individual instance, ie., each record will be processed in that instance.

Orcale BPEL Compensation Handler Vs Compensate

We use Compensation when we need to revert the action done through webservice as there is no rollback stategy in webservice we need to call the revert activity of that particular service.


Compensation Handler : Reverse action to be conducted for the given scope. It wont be auto triggered.

Compensate: Composite Handler will be get triggered by Composite event.

If there are two compensation handler in a composite all the handler will be executed when we invoke compensate event.

OSB How to handle large payload

"Content streaming" is the solution for handling large payload in OSB.

We can enable this option in 'Message Handler' section of proxy service.

We can use the content streaming when rounting the content to end system based on the routing condition ie., without transforming the complete payload. As tranforming complete data will need huge RAM based on the payload size.

Instead we use the advantage of xquery which traverse only the particular element instead of loading complete payload. Here we need to be carefull the output variable which is created out of xquery transformation. This variable size also should be very huge as compared the RAM size

For best practise pls refer this link: http://docs.oracle.com/cd/E23943_01/admin.1111/e15867/context.htm#i1110512

We can also use streaming in DB Polling in JCA Adaptor.

OSB Split Join Parellel flow execution to improve performance

OSB Split Join Parellel flow execution to improve performance

Tracking OSB Instance | Logging vs Tracing

Oracle Service Bus tracking the instance:

1. OSB is stateless in nature so there is no consept of instances lineup like in BPEL. But we can have a log entry at the start of the OSB project such that we can make sure to track the failed call. We can log the important entries like Client Name invoked the OSB Project and Unique Id.

Ex. If we call the getCustomerDetail OSB call from Customer Portal

In realtime we have a header and body part for each request. Header part will speak about the which client calls (CallFrom) the osb and name of the osb composite(CallTo). In log we need to log this entry along with the UniqueID for unique representation. UniqueID is the combination of timestamp and id for the request which is populated from the portal.



 <xsd:complexType name="RequestHeader">
    <xsd:sequence>
      <xsd:element name="CallFrom"/>
      <xsd:element name="CallTo"/>
      <xsd:element name="UniqueID"/>
    </xsd:sequence>
  </xsd:complexType>
  <xsd:complexType name="RequestBody">
    <xsd:sequence>
      <xsd:element name="id"/>
    </xsd:sequence>
  </xsd:complexType>

For debugging the scenarios, you can also enable tracing (in Operation Settings) on the proxy/business service to capture the complete trace of the execution. But ensure this setting is turned off in PROD environments as this hampers performance.

Difference between Oracle SOA BPEL Service Callout and Routing

Difference between Oracle SOA BPEL Service Callout and Routing

Routing Action - Routing action can be created inside a Route Node only and Route Node is the last node in a request processing. A Route Node indicates that Request Processing will end here and Response Processing will begin. You can not have any node after Route Node in the message flow.

Service Callout - Service Callout is used in real time request-response scenarios (for sync response). If you have a use case where you need to call one or multiple real time request-response services (like sync web-services) then you may use Service Callout action in the message flow. Being a synchronus call, the thread gets blocked until a response is returned from target service.

Publish Action - Publish action is used for Request only scenarios where you don't expect a response back. The nature of Publish action (sync or async) will depend upon the target service you are invoking. If you are invoking an external service through a business service then Publish action with Quality of Service(QoS) as "Best Effort" (default) will work like fire and forget and thread won't get blocked (async call). If you are invoking a local proxy service (proxy with transport protocol as "local") from another proxy using publish action then it would be a blocking call (synchronus call) and thread will get blocked untill the processing of local proxy finishes.

JMS Topic Queue high avaibalily using durable and persistance feauture in Oracle SOA OSB

JMS Topic Queue high avaibalily using durable and persistance feauture in Oracle SOA OSB

JMS is used for improving the performance of the overall system and reliability of the system.

JMS Queue:
FIFO - First Msg will be Fetched First from Queue

Two import aspect of JMS Queu are

1. What will happen to the jms message when JMS server is down?
2. What will happen when the client which need to receive the message is down?

If we make the message as persistance then both above problem will be solved ie., msg will be persisten in the DB hence msg will be always be avaiable till its consumed by the client.

Persistance of the msg in the queue can be achieved by enabling the "Enable Message Persistance" of business service under JMS TRansport Tab. Screenshot is shown below





JMS Topic -
Producer and N number of subscriber is the concept of JMS Topic.

Oracle SOA Reading the message from Topic:

We can make the message persisted in the DB by persisting  the msg in the topic. Persistance can be achieved by enabling the "Enable Message Persistence" of business service under JMS TRansport Tab. Screenshot is shown below

Oracle SOA Reading the message from Topic:
Consider there are two subscriber for a topic. If one subscriber read the message and another subscript server is down then it will not be receiving the message any more! But this behaviour can be avoided by means using the Durable subscriber. Ie., message will be present in the topic till durable subscriber consumed that message. To make the subscriber durable  we need to enable the durable checkbox in proxsy service. Screenshot is given below.

Oracle SOA BPEL Correlation Why When How?

I like the about correlation from swapnil blog
http://swapnil-soa.blogspot.co.uk/2008/01/correlation-this-post-would-effort-to.html

Below one has few changes for clarity.

This post would effort to explore the meaning and need of correlating requests and the best way to do them using Oracle SOA Suite.

What & Why
In common business scenarios it is not possible to have a synchronous response to each of our requests. Mostly the business has to deal with vendors, who would need to undergo a detailed process to come up with a solution. However, this response may not be necessarily binding business from carrying on its other activities. In such scenarios, the business enters in to asynchronous communication with these third parties. The async process necessarily stresses that the response may come back at a later time, through callback or polling mechanism as is suitable.

In case of a single instance its quite easy to match the response to request, however, when there are multiple instances the business would be wondering which request has been responded to. For example, if a travel booking agent spawns 10 requests for Frankfurt to Paris, and after a while airline responds to one of those 10 requests, it would not be safe to assume that this is a response to first request only. Hence the travel agent would tag in an ID to segregate one request for another, and would expect the airline to return this id unaltered to match the request. This id, which enables requestor to correlate the response sent by the provider, is called Correlation Id.

How (in Oracle BPEL)
Oracle BPEL provides us with two mechanisms through which an asynchronous callback message could map to its calling instance in the crowd.

• WS-Addressing
• Correlation Sets

WS-Addressing
“How does the callback maps to the correct instance out of so many waiting processes”, it’s a very common surprise to all beginners, creating first ever Asynchronous Invoke in BPEL Process Manager. The answer is, any time an asynchronous service is invoked, Oracle BPM, instills a message UID in WS-Addressing headers that float with SOAP Packets, which are used internally by the BPEL Server to correlate the flowing request/response.

This is the default mechanism supported by Oracle BPEL Process Manager, which is overridden automatically when the user opts to create his own correlation set.

Correlation Sets
Correlation Sets enable you to correlate asynchronous messages based on message body contents.

Why?

The question now arises, why ever would a BPEL developer like to over-ride default WS-Addressing correlation and use content-based correlation. Well, he won’t have to; if the called service is an Oracle BPEL, or the one, which supports and retains WS-Addressing headers sent, and returns the same in response.

The reasons, to use content-based correlation, could be many; some of the familiar ones that come to my mind are –

1. The asynchronous web service invoked by BPEL does not support/understand WS-Addressing headers.
2. When BPEL instance is expecting messages from a third party, for example, a file-poller.
3. When asynchronous call has multiple hops and reply is received directly from end system. For example, Request path is A > B > C > D and response comes to A directly from D, i.e. D > A.

How?

WE now understand and appreciate, need of correlation and the two mechanisms to achieve correlation. In WS-Addressing, we, as in developer, does not bother of how the correlation ID is created and maintained. However, in content-based correlation the responsibility of managing correlation set, defining property alias and initializing the correlation with appropriate value falls on developer.

To understand how to perform these tasks, we would start by understanding in which activities do we need correlation. The Correlation is required whenever data is going out or coming in to the BPEL process, hence Correlation works only with Invoke, Receive, Pick and Reply activities.

To create a correlation of our own, we need to create the Correlation Set first. A correlation set is a set of properties shared by all messages in the correlated group.

The correlation set is normally instantiated on invoke or receive activity. When correlation is instantiated on receive activity it is fairly straight forward, you create a correlation set, and select initiate = “yes”.

However, when you have to create correlation set on invoke, we have one addition option to understand, it’s the “pattern”. Now before we move ahead with “pattern”, lets explore what is “initiate” option.

• in - specifies that the correlation applies to inbound messages
• out - specifies that the correlation applies to outbound messages
• out-in - specifies that the correlation applies to both inbound and outbound messages

When initiate = “yes”,
Pattern=”in” means the correlation is being instantiated with a value that is coming into the BPEL, from another service. Clearly, this invoke is then not the one which is invoking an asynchronous process, as the pattern suggests a response coming back.
Pattern = “out” means the correlation is being instantiated on the message that is going out of our BPEL.
Pattern = “out-in” means the correlation would be set on a variable that is part of both outgoing and incoming parameter, in this synchronous invoke. However, its nature is very much questionable.

When initiate=”no”
The above patterns would reflect which way the variable needs to be validated, inward, outward or both ways.

Creating a Correlation Set 

Correlation sets uses correlation tokens available inside messages, headers or business documents. Correlation tokens are the declarative properties of messages. A property is an element within a message identified by a query. Property aliases are the constructs to specify the queries to identify properties.

To create Correlation Set click the Createicon, and insert the appropriate values. As shown in the diagram below:



Here you would also need to create a Property (not shown in diagram above, its just beneath Xpath text box. This way we declared one of the property alias for instantiation, we need to create another one for validation.

Select the BPEL in diagram, in the adjacent Structure window, you would see set of properties. Right Click Property Alias, and select “Create Property Alias…”.



Now, select the appropriate message part, and then enter Xpath query string in the text box. You can use Ctrl+Space for Autofill.




Now, select the appropriate message part, and then enter Xpath query string in the text box. You can use Ctrl+Space for Autofill

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