Soap response not working

Hello,
When you first get your object, first cast it to a String by mapping the Object variable to a new String variable. so:
[o] -> [s] -> [xmlNodeToDocument]

Good day.

Yemi Bedu

I’m looking for a place to do this. I can’t seem to do it in the web service connector directly, because the ‘data’ object doesn’t appear on the pipeline on the map step that puts the wmTestReturn on the pipeline. it just has a single map
pipeline in: pipeline out:
/respParms/wmTestReturn -> /wmTestReturn

so I can’t even find it in there to cast it. if I put that ws connector into another flow, the outer flow recognizes that the wmTestReturn will be an array (list) of column names, and another object called ‘data’ which, like I said, doesn’t seem to have any type.

some progress: inside the ws connector service, I changed the invocation of the soapRPC flow and dropped off the targetOutputSignature input. that also allows the soap connection to run. then if I cast the ‘data’ object into a string first, I just get ‘28’ as the value, which is only the first item. but trying to map ‘data’ into a string list, it doesn’t get anything.

I may end up having to digest the soap response myself with code, but if anyone knows how to get the complex return types out of a soap response into, say, a document in webMethods, that’s what I’m after.

tia.

Hello,

If: (your Object shows as an ObjectArray (note the extra pages on the variable))
then: you would map it to a StringArray
else: you will only be working with the first element.

if: (you only got the first value)
then: you must go back to how the Object was made and make sure it make it in the form of an ObjectArray and not just an Object.

This may be well all you need.
Good day.

Yemi Bedu

got it.

when I look on the output tab of the WS connector service (wmTest) in edit mode, there is no icon at all shown for the ‘data’ object. not a document, not a document list, nor string, nor string list, nor even the object or object list icon. and I’m unable to change this on the Output of the service.

if I RUN the service (I have to drop off the targetOutputSignature input to the soapRPC to do so), under wmTestReturn it looks like it returns ‘data’ as an object list. I can only get to this in edit mode if I nest the ws connector service inside a flow service.

so I have to have the flow service (wmTestTwo) call wmTest, and I map the wmTestReturn/data (it still has no icon in edit mode) to an object array on the pipeline out. when I run wmTestTwo, the object array on the pipeline has all the elements.

thanks for all the help, this is going to enable us to use webMethods with many more projects.

not entirely done.

attached is the WSDL code. as you can see, the 2nd part of the QueryBean type is that pesky ‘data’ object. you can see it is a complex type, ‘ArrayOfArrayOf_xsd_anyType’, which is a 2d array. the way I’ve done the ws connector service and the flow service now (mapping the no-type ‘data’ output element from wmTest to an object array element on the pipeline out), I’m able to get it as a 1d array.

but I really need to map it to a 2d object array element on the pipeline out…how could I do something like that?

thanks again.


wmTest.wsdl (3.4 k)

Hello,
I do not want to load your code in my development environment, so is there a free (even trial) version of software to look at this xml?
Beyond that, I would do this mapping set:
For,
Object -> String
ObjectArray -> StringList
ObjectArrayArray -> StringTable

You can push this object initial to a java service and then you can do a cast such as

if(idc.first(“object”)){
idc.insertAfter(“data2D”, (String) idc.getValue());
}

I’m anticipating using a java service like the one you mention because I tried to load it into a StringTable and didn’t get what I wanted.

As for looking at the xml, you could look at it with IE or any text editor. it’s just straight WSDL code.

if you want a nice graphical view of it, you can try the home (free) edition of XMLSpy from Altova, but I always find it better to just look at the plain XML since graphical tools sometimes mis-interpret things.