First of all, create new OSB project under OSB application. Now create Rest proxy service that accept JSON message and send JSON as response, to do that right click and choose “REST” option and provide proxy name. In next screen you need to provide resource path for this rest proxy.
Now click on “Add a new Rest Method” option. Provide method name in next screen and choose “POST: method. Also choose “JSON” option for both request and response as we are dealing with JSON message here.
Add Pipeline where service type is REST and choose the proxy WADL file for the same. Ensure that expose as proxy option is unchecked.
In Expression, add below text.
var $request = process.body process.response= “Hello ” + $request.inputVal
Here $request is variable and process.body contains the request JSON data so I assign request JSON to request variable.
imputVal is the element name that we receive in request so to access that I used $request.inputVal expression and “Hello ” is appended to that and assigned to process.response.
Test the flow by using the request JSON and you see the response JSON as shown below.
we discovered a version mismatch issue in which two SOAP services on different versions (Service-A on SOAP 1.2 and Service-B on SOAP 1.1) were failing to communicate with each other. Here, we explain how to resolve this issue.
Difference between SOAP 1.1 and SOAP 1.2
Before diving into the solution, let’s look at the improvements SOAP Version 1.2 provides over SOAP 1.1.
Offers a clear processing model;
Provides improved interoperability with testing and implementation requirements;
Based on XML Information Set (i.e. It is specified as an Infoset, which is carried from one SOAP node to another, whereas SOAP 1.1 was based on XML 1.0 serialization.);
Offers protocol independence for developers by providing a binding framework;
Includes HTTP binding for improved integration to the World Wide Web;
Delivers a well-defined extensibility model; and
Provides improved support for Web standards.
WSDL changes observed in SOAP 1.2
Namespace Changes: SOAP 1.2 supports the following namespace definition:
2. SOAP 1.2 uses “application/soap+xml” as the Content Type, whereas SOAP 1.1 uses “text/xml”.
3. SOAP:Operation and SOAP Binding must be specified in SOAP 1.2 WSDL.
Now, to overcome the versioning mismatch issue mentioned above, we must follow these steps:
Generate the OSB Proxy as a Message Based Proxy service. This will be based on the XSD with only the “body” part with required parameters to call Service-A (SOAP 1.2) and Service-B (SOAP 1.1).
Create a Pipeline Service based on the same methodology explained in number 1, above.
In the Pipeline Service, navigate to Message Flow and add a Pipeline Pair – rename it per the process standards.
In the Request Pipeline node, add a Stage and rename it per process standards.
Inside the Stage, add a Service Callout, then browse for the Proxy Service for the wrapper of Service-A or the business service of Service-A. The Service Callout configuration is shown below with the required message to Service-A parameters assigned.
After the above Pipeline Pair is complete, add a Route Node.
Inside the Route Node, add a Routing Operation and configure the same for the Business Service of Service-B.
Inside the Request Actions, assign or replace the Body and Header to make a successful call for Business Service. The following snapshot illustrates this.
Global Attributes can be declared to share variables and information between all the Portals.
Out of the box, one of the attributes is the wcSessionTimeoutPeriod responsible for the session timeout. My friend Daniel already blogged about
accessing this on his blog entry.http://blog.vassit.co.uk/knowledge/access-global-custom-attributes
Way of accessing in EL is still working as following