OSB Error : Failed to set the value of context variable "body"

A common error one can get while assigning variables in OSB is  -

Failed to set the value of context variable "body". Value must be an instance of {http://schemas.xmlsoap.org/soap/envelope/}Body.

OSB has some predefined variables like body and it expects that the variable body content should always be enclosed with <soap-env:body>. Inside this element you can assign any value.

If you don't want to be worried about this every time manipulating body variable then you must use "Replace" instead of "Assign". Just select "Replace node contents" and replace will take care of not removing the <soap-env:body> from the variable. 

Difference between Route - Publish and Service Callout actions in OSB

There are mainly 3 types of MEPs (Message Exchange Pattern),to interact between end applications.
1) Synchronous interaction
2) Asynchronous interaction
3) One way interaction

Synchronous interaction is basically to communicate with end point and wait for its reply to process the response.
Service Callout: Service Call out is exactly meant for that. If you use Service Call out in any of Request or response pipeline proxy service will wait for the reply from the end application.
So when ever you are thinking to interact with synchronous process you can opt for Service call out. But this is not the only action which you can use when interacting with synchronous process.

Publish: As mentioned earlier there can be three types of interactions between application. For asynchronous interaction OSB does not provide specifically any action and it also does not suite its architecture. So if you are thinking to implement asynchronous service interaction better to choose Bpel(Oracle SOA)instead of OSB, though you can implement asynchronous interaction in OSB but it is not straight forward like Bpel.
Apart from asynchronous interaction there is another interaction named one way interaction.
OSB provide an action for this type of interaction named Publish. Publish action only sends the request and never ever waits for any response(default behavior if required one can use routing option to change its behavior)  from the back end service even if any exception happens you can not catch it using publish action because it doesn't block the request thread and doesn't wait for reply.

So far we came to know about Service call out and publish action now we will discuss the most important action in a OSB proxy flow for integrating with different application, action is called route.

Route: Route action has some special feature in a proxy flow. if you are using route in your proxy flow then route will be the last action in the flow and you can not add any other action after route action. It is route action where context is switched, what i meant to say about context switching is switching between request context to response context, that means in route action request body will be mapped to response body and similarly for all the context variables (body , fault etc).
Now inside a route you can use a routing option and you can communicate with back end applications using this routing option. you can interact with both Synchronous and oneway process using routing option.
More over it has a feature which makes the processing/interaction happen within the same transnational boundary (unless configured separately) by doing this it ensures that the response comes back from the back end application without having any dependency on the process type (Synchronous/oneway).

There is one action called routing option which is very useful for managing threads/transaction for the interaction.

Few more differentiating parameters:

Route

1.            Last node in request processing.  It can be thought of as a bridge between request pipeline processing and the response pipeline processing.

2.            You can only execute one route in your Proxy Service.

3.            Can only be created in a route node.

4.            OSB will wait for the Route call to finish before continuing to process.

a.            If you are calling a Business service and you specify Best Effort for QoS (Quality of Service), then OSB will release the thread it is holding while the business service executes.

b.            If you are calling a Business service and you specify Exactly Once or At Least Once for QoS, then OSB will hold onto the thread while the business service executes.

c.            If you are calling a local Proxy service, then OSB will hold onto the thread until the Proxy service finishes executing.

Service Callout

1.            Can have multiple Service Callout nodes in a Proxy service.

2.            Pipeline processing will continue after a Service Callout.

3.            Can be invoked from the request and/or response pipelines.

4.            Used to enrich the incoming request or outgoing response. For example, a call to get a country code.

5.            Used for real time request/response calls (Synchronous calls).

6.            OSB will hold a thread and not continue until the Service Callout completes.

7.            Can tie up resources and degrade performance under heavy loads.

Publish

1.            Can be synchronous or asynchronous

a.            If you are calling a business service with a Quality of Service of Best Effort , then it will be an asynchronous call.

b.            If you call a business service with a Quality of Service of Exactly Once or At Least Once, OSB will wait until the processing completes in the business service completes before proceeding and it is effectively a synchronous call.

c.            If you are calling a local proxy service, OSB will wait until the processing in the local proxy service completes and it is effectively a synchronous call.

2.            Can be invoked from the request and/or response pipelines.

3.            Best to use when you do not need to wait for a response from the process you are calling (Fire and Forget.... Asynchronous Calls)

OSB Message flow:

Nodes:


1)      Conditional Branching:

               We can use Conditional branching based on specific condition.

2)      Operational Branching:

               If our message flows define WSDL-based proxy services, we can use operation-specific branching is required. When we create an operational branch node in message flow, we can build branching logic based on the operations defined in the WSDL.

              We must use operational branching when a proxy service is based on a WSDL with multiple operations. We can consider using an operational branch node to handle message separately for each operation.

3) Pipeline Pair:

              A Pipeline pair node has a single request and single response in one top-level element. A pipeline pair node has a single (only one) descendant in a message flow. During request processing only request pipeline is executed when OSB process a pipeline pair node. The execution path is reversed when OSB process the response pipeline.

4) Route:

              A route node performs request/response communication with another service. It represents boundary between the request and response processing for proxy service. when a route node dispatches a request message, the request processing is considered complete. when route node receives a response message, the response processing begins. the route node supports conditional branching as well as request and response transformations. 

5) Stage:

            Request , Response pipelines and error handlers can contain Stage nodes, where we can configure actions to manipulate messages passing through the pipeline.

6)Error handler:

          It can be attached to any node or stage, to handle errors at that particular location.

Routing and Service Call-out in OSAB

--what are the criteria for choosing between one or the other (Routing action or Service Call-out action or Publish action)?

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

OSB 11g BEA-380000 , Not Implemented Error

When trying to invoke external Business Service from OSB Business Service Test Console getting following Error.

<con:fault xmlns:con="http://www.bea.com/wli/sb/context"> 
<con:errorCode>BEA-380000</con:errorCode> 
<con:reason>Not Implemented</con:reason> 
<con:location> 
<con:node>RouteNode1</con:node> 
<con:path>response-pipeline</con:path> 
</con:location> 
</con:fault> 

 Root Cause: In Business Service Advanced Configuration "Use Chunked Streaming Mode" was enabled.

 Resolution: Disable "Use Chunked Streaming Mode" as show below.