Consuming a RESTful service from the OSB

In this recipe, we will show you how to consume an existing RESTful service from the OSB. We will reuse the service we have provided in the previous recipe and implement a proxy service/business service pair to expose it as a SOAP-based web service.

The business service is using the HTTP transport to invoke the RESTful service and a proxy service is exposing this as a SOAP-based web service, also using the HTTP transport.

In this recipe, we will only implement the RetrieveCustomerByCriteria operation.

Getting ready

Import the SoapUI project CustomerServiceCRM-soapui-project.xml from the location \chapter-5\getting-ready\exposing-restful-service\soapui into your SoapUI. Start the mock service CustomerServiceSOAP MockService.

Import the OSB project containing the implementation of the RESTful service into Eclipse OEPE from \chapter-5\solution\exposing-restful-service.

Import the base OSB project containing the right folder structure and the necessary XQuery transformations into Eclipse from \chapter-5\getting-ready\consuming-restful-service.

How to do it...

We will start with the business service, which will wrap the RESTful service. In Eclipse OEPE, perform the following steps:

In the business folder of the consuming-restful-service project, create a new business service and name it CustomerService.
On the General tab select Messaging Service for the Service Type.
Navigate to the Messaging tab and select XML for both the Request Message Type and the Response Message Type.
Navigate to the Transport tab, enter http://localhost:7001/exposing-restful-service/CustomerService into the Endpoint URI field and click Add.
The business service wrapping the RESTful service is in place. Let's now create the proxy service that will expose the SOAP-based interface. In Eclipse OEPE, perform the following steps:
In the proxy folder create a new proxy service and name it CustomerService.
On the General tab select WSDL Web Service for the Service Type and click Browse.
Navigate to the CustomerServiceCRM.wsdl from the wsdl folder and select the CustomerServiceSOAP (port).
Click OK and confirm the pop-up window with Yes.
Navigate to the Message Flow tab, insert an Operational Branch node and name it OperationalBranch.
Click on the first branch and select RetrieveCustomerByCriteria in the Operation drop-down listbox.
Insert a Route node into the RetrieveCustomerByCriteria branch and name it InvokeGetRoute.
Insert a Routing action into the Route node.
On the Properties tab of the Routing action, click Browse, select the CustomerService business service in the business folder and click OK.
Insert a Transport Header action into the Request Action flow of the Routing action.
On the Properties tab of the Transport Header action, enable the Pass all Headers option.
Insert an Insert action after the Transport Header action.
On the Properties tab of the Insert, click <Expression> and enter <http:http-method>GET</http:http-method> into the Expression field. Click OK.
Click on <XPath>, enter ./ctx:transport/ctx:request into the Expression field and click OK.
Enter outbound into the In Variable field.
Add another Insert action right after the one created above in step 16.
On the Properties tab of the Insert, click <Expression> and navigate to the XQuery Resources tab.
Click Browse, select the SoapToHttpGet.xq resource in the transformationfolder and click OK.
In the Variable Structures on the right, expand body | $body – RetrieveCustomerByCriteria (request) and drag the node RetrieveCustomerByCriteria to the Binding of the retrieveCustomerByCriteria1 variable.
Click on <XPath>, enter ./ctx:transport/ctx:request into the Expression field and click OK.
Enter outbound into the In Variable field.
Insert a Replace action into the Response Action flow.
On the Properties tab of the Replace action, enter body into the In Variable field.
Click <Expression>, navigate to the XQuery Resources tab and click Browse.
Select the HttpGetToSoap.xq resource in the transformation folder and click OK.
Enter $body/cus1:Customer into the Binding field of the customer1 variable.
Add a new namespace and enter cus1 into the prefix, http://www.somecorp.com/customer into the URI field and click OK.
Select the Replace node contents option.
By doing that the processing for the RetrieveCustomerByCriteria operation is complete. We won't implement the other operations of the Operational Branch in this recipe. It's a good practice to raise an error if a not-yet-supported operation is called. We can do this by adding a Raise Error action in the default branch:
Insert a Pipeline Pair node into the Default branch and name it UnsupportedOpPipeline.
Insert a Stage node into the Pipeline Pair and name it RaiseErrorStage.
Insert a Raise Error action into the RaiseErrorStage.
On the Properties tab of the Raise Error action, enter OPERATION_NOT_SUPPORTED into the Code field and The operation is not yet supported! into the Message field.
Deploy the project to the OSB server.
Our SOAP-based web service is now ready and can be tested. In the Service Bus console, perform the following steps:
In the Project Explorer navigate to the CustomerService proxy service inside the proxy folder and click on the Launch Test Console icon.
In the Available Operations drop-down listbox make sure to select the RetrieveCustomerByCriteria operation.
In the Payload field, enter id into the criteriaField and 100 into the criteriaValue element and click Execute.
The Response Document in the next window will show the result of our SOAP-based web service.

How it works...

In this recipe, we created a SOAP-based web service for an existing RESTful service. We have mapped the SOAP request into the corresponding RESTful message and vice versa.

On the business service, wrapping the RESTful service, the HTTP method is defined at development time (POST by default). However, through the use of the Transport Header action together with the two Insert actions, we are able to overwrite/define the HTTP method being used in a given call. In our case, where we only implemented the RetrieveCustomerByCriteria, it's the HTTP GET method we want to use.

The next screenshot shows the value of the metadata in the $outbound variable in the Routing action.

We can see that the value of the http-method and the query-parameters elements that have been added by the two Insert actions.

For the creation of the query-parameters in the XQuery script, we have reused the standard OSB XML Schema HttpTransport.xsd. In there the query-parameters structure is defined as a complex type.