Web Service Client stage - issue with xpath definition

hobocamp · Posted: Tue Apr 21, 2015 10:39 am

I don't see anything that I can directly relate to this problem I'm encountering when using a Web Service Client stage - so here goes -

I'm trying to call a web service from a vendor, who supplied the wsdl definitions for the various services we need to call.

The wsdl for this particular service is only two nodes - one gets loaded with an xml payload, and the other with a string.

After I've imported the wsdl, the xpath definition for the second node type is text(). But the first node has a type of "*". Of course if you run the job with that value, it results in an "invalid token" error.

The only thing I've been able to get to work is to set the value to text(), like the second node. However, with that, DataStage interprets the xml payload with ;gt and ;lt, instead of left and right brackets. The end result is that the web service call fails.

I know that this is the cause of the failure, because if I run a trace on the job, capture the payload, convert the gt and lt values to left and right brackets, and run it in SoapUI, the call works perfectly.

(On the other hand, if I capture the data as is, and run it in SoapUI, I get the same error that I get in DataStage, which is "Object reference not set to an instance of an object".)

Has anyone run into something similar when call web services?

Thanks!
Tom

eostic · Posted: Tue Apr 21, 2015 3:29 pm

I guess one question for starters is.....does it ever work in a soap testing tool? ...on the & escape characters, it's hard to say what is going on...but "maybe" the xml data element will h ...

What's this?

hobocamp · Posted: Tue Apr 21, 2015 6:30 pm

Hi Ernie - Thanks for your reply.

To answer your question - yep, it works perfectly in SoapUI, as long as I manually convert the < and %gt; to brackets (<>) first. (If I paste the soap envelope as is into SoapUI, I get the same error that DataStage produces.)

I had also tried setting the Data Element value to XML at the column level, but so far that has produced the same results.

JRodriguez · Posted: Tue Apr 21, 2015 10:22 pm

Hi Tom,
Recently I ran into a similar issue. In our case the web service payload was defined to generate the payload with a node string and that caused that the returned XML payload was xml escaped ( < --&lt and > --&gt). This depend entirely on the web service provider...

We ended up downloading the payload to disk and performing a global replace to fix the XML tags...and continue processing the XML

It looks like you are facing a similar web service weakly typed defined with anode string which always by definition will encode the XML payload

Good luck!!

hobocamp · Posted: Tue Apr 21, 2015 11:57 pm

Hi Julio -

Thanks for your response. What a frustrating issue this has been.

Would you mind giving me a few more details, such as how you went about determining that it was caused by the service, and how your workaround worked?

Thanks so much.

Tom

eostic · Posted: Wed Apr 22, 2015 4:57 am

You can provide the input payload yourself...use the WSTransformer Stage instead of the WS Client Stage, and have a dummy Transformer or RowGen in front of it (or dummy read from a file/database...wha ...

What's this?

hobocamp · Posted: Wed Apr 22, 2015 5:51 am

Hi Ernie -

By "payload that works", I was referring to the soa envelope I copied from the Trace log of the DS job. I copied that to notepad, converted all of the escape characters back to brackets, and posted the entire thing into SoapUI. The service worked correctly in that case. Make sense?

Tom

eostic · Posted: Wed Apr 22, 2015 9:48 am

Either way, the solution I outlined above will do the trick. Manage the payload entirely on your own using the user-defined message methodology...... ...and then work separately on ways to build ...

What's this?

hobocamp · Posted: Wed Apr 22, 2015 10:03 am

Thanks Ernie.

Couple of questions just to clarify -

-When you mentioned adding the 'working' payload to a derivation (inside a dummy transformer I'm assuming), do you mean the entire soa envelope content? I'm assuming yes.

-Also, you mentioned the input and xml output stage. You also mentioned having an output from that stage. What is the target for that output?

Thanks again.

Tom

eostic · Posted: Wed Apr 22, 2015 3:18 pm

I haven't done it in awhile, but if memory serves correctly, you just need the whole <body>. A decade or so ago I asked engineering to give us a default Table definition for this purpose...if ...

What's this?