January 20, 2011 2 Comments
I am working on a project using WID/WPS/WESB v188.8.131.52 and was asked recently if a mediation flow could capture HTTP response codes from a back-end web service one-way operation.
Naturally my advice was that if an operation describes neither response nor faults, the client is not expected to care about what happens after the request is posted to the service.
Nonetheless, I set about providing a solution, which I would class as a ‘trick’, and hence worthy of a first post in this appropriately named blog.
In summary, the trick consists in calling the web service using an import with HTTP bindings using SOAP/HTTP data serialisation format and basically lying on the import interface. Shameless, but effective.
So, let me show you the trick in more detail.
Lets pretend we have a CustomerService with an addCustomer one-way operation that accepts a Customer as input. Go ahead and create a library named LB_Customer, an interface named CustomerService and a DataObject called Customer.
Then create a module called CustomerService with a Java SCA component just logging the Customer attributes and a web services export. I chose SOAP1.1/HTTP using JAX-RPC. Well, I had no choice. This is the standard in this project.
So, here’s the assembly:
Here’s the CustomerService interface:
And here’s the Customer data type:
Oh, and the very simple Java component code:
You can go ahead, deploy and test. We’re done with the pretence and we can move on to the real trick.
Now create a mediation module, call it MM_CustomerService and do not make the library a dependency. Within this mediation project create your own copy of the Customer data type and the CustomerService interface, but make the addCustomer operation request-response and create a new Response data type.
Here’s the mediation’s private CustomerService interface:
And here’s the Response data type, also private to the mediation:
The private Customer data type is an exact copy of the one in the library used by the target service.
At this point it might be worth showing you my business integration view, so you can check all your bits and pieces are in the right place:
Now comes the hack. You have to make sure the CustomerService interface which is part of the MM_CustomerService mediation project has the same namespace as the one in the library. So go ahead and change it. Go to the interface properties and change the namespace to http://LB_Customer/CustomerService. I told you there was some lying involved.
Now you can assign this interface to your mediation flow component, both as an interface and a reference. Then drop an import into the assembly, wire it to the mediation flow component’s reference and accept the creation of a matching interface on the import.
Right-click on the import and select Generate Binding…-> HTTP Binding. You will have to provide the endpoint URL. You can copy it from the binding tab on the properties for the web services export on the CustomerService assembly.
Here’s a screenshot of the complete assembly:
Go to the properties for the HttpImport, Binding tab, and select SOAP (HTTP) as the default data format. You will need to check the box to show deprecated data formats.
Here’s how you select the data binding:
And here’s the main Binding Properties tab:
Finally go to the Method bindings tab, select the addCustomer bound method and change the HTTP method from GET to POST.
Now let’s implement the mediation flow.
The request flow is a doddle. We simply let the message pass through:
The response flow requires a couple of XML transformations for the out and fail terminals:
The two transformations operate at message root level and map the StatusCode and ReasonPhrase from the smo HTTPHeader to the response body:
You can build, and deploy the two modules now.
Then test the mediation flow component. I’m assuming you’re more than familiar with the integration test client.
On this first run I can see in the Events pane that we invoked the http import and that the response fail terminal was fired, routing the response flow to the MapFail xml transform. You can also see the response values. HTTP status code 500
So this is rather good news! Yes, something is not quite right yet but it proves that we are doing what we are supposed to. Capturing HTTP response codes for a service which is, in WSDL/SOAP terms, one-way.
If you have a Console view to hand, you can flounder around for an explanation to this minor frustration, but I’d rather just save you time and show you the relevant log section:
So, it looks like we are missing a SOAPAction header.
I’m still in fits about understanding the purpose of this header. But I understand that there must be a SOAPAction HTTP header for this to work.
So, go back to the properties for the HTTP Import and add an HTTP header named SOAPAction. I used a single white space for its value as there must be a value present.
Now rebuild, republish and retest.
Sweet! We get a 200 OK and we can see in the log the target service doing the sysouts!
And one last thing you may want to do is to stop the CustomerServiceApp (on the Servers view) and retest. You will get the anticipated 404 Not Found:
That’s it, hope you enjoyed this magic trick and feel free to contribute comments and observations, particularly if you get a chance to try something similar on v7.