Mapping values into WS invocation

Posted by Admin on 11-Nov-2008 12:08

I have a web service that takes two input parameters and I want to get the values of those two input parameters from two different header values of an XQMessage and I am simply stumped on how to do this.

My WSDL is as follows:

As you can see, in the usual WSDL style, the input message has a single part that is a complex type containing two elements, "p1" and "p2".

When I create a step in an esbp and point to this wsdl and then go to the request mappings I have two issues:

1. First, I had hoped that the parameters_IN would be expandable to show "p1" and "p2" - after all, the schema for parameters is available.

2. Then I thought perhaps I could use the "Transformation into Parameter" capabilities to build up the XML. But then there seems to be no way to take multiple parts of the incoming XQMessage and combine them into some XML that I can then tie to parameters_IN

(see attached screenshot)

So fundamentally my questions are:

1. Is there any way within an ESB Invocation to build up the WS input xml from parts of the XQMessage?

2. If not, what would I use in the esbp prior to the WS invocation step to pull values from the XQMessage and build up the XML that will, in the next step, be input into the WS invocation step?



All Replies

Posted by jet on 13-Nov-2008 09:00


If I were to attempt to put something together to accomplish this, I would have an XML Transformation service as the step prior to the WS Invocation.

You could use an instance of the service to spawn a new XQMessage within your XSLT. I'm fairly confident the MQ7.6 documentation (potentially prior documentation too) has information/examples in it on how to create a new XQMessage from within an XSLT. You could use the com.sonicsw.xq.service.xform.HeaderExtension class within your XSLT to pull the header values you need for the input params, and plop them into your XML that is going to be the of your new XQMessage you could create in the XSLT.

Alternatively, you could use the same XQMessage (not create a new one) and modify it via JavaScript rules (function rule() ) that would execute within your JavaScript when the XML Transformation service receives the msg. Your JavaScript can also pull the header values (XQMessage.getHeaderValue("header_name") and you can create new content/replace msg part in the msg to build your new XML. Your XSLT that would be applied could potentially modify the XML further or do nothing with it (return null from JavaScript).



This thread is closed