Hi all,
I have a soap-msg coming in thru document literal service. now when i run the called wrapper service thru a wM web service connector it all runs fine. Also if I do a savePipeline/restorePipeline (when called from the external application)and receive the data and run it from there all the results look good. The problem comes when the external app call this directly it gets an internal application error which I am throwing thru my serivice.
The problem really becomes worse when i try to debug it thru the savePipeline.

This is how my service looks (i/p is soapRequestData - String)
savePipeline
restorePipelin
map(maps the soapRequestData to a tempsoapdata variable)
savePipeline(just to see if the data is mapped to this tempsoapdata var)
restorePipeline
----
-----
----
Do take into consideration that when the service is called directly i have the savePipeline on and while tracing it I have the restorePipeline on.
Now when I come to the last restorePipeline I would expect to see my soapRequestData coming in as request being mapped to the tempsoapdata var. But this does not happen (I do not see the tempsoapdata though I can see the input as a string variable of soapRequestData)and hence the external application is seeing the error.
The map in the 3rd step is just a simple map from the input soapRequestData var to the tempsoapdata var. Does anyone have any idea as to why webM is doing this (not mapping this value to this temp var)? I am assuming this is the problen and hence my next steps in the flow dont map anythign from the input request soadRequestData. Now mind you when I trace this service with the first resorePipeline it works right till the end. Hows that possible? Also tried something different. If I have a savePipeline and restorePipeline both on the external app receives a success. All is fine. but then do I really need to do a savePipeline and restorePipeline. Isnt that a big overhead on performance?

Thanks in advance
Bala

That flow service doesn’t look exactly correct for providing a doc/literal web service. Have you check the other threads here and the examples. The input signature as well as the first steps are not correct if your intention is to host the doc/literal web service (provide the implementation)

Mark,
I just jotted down the first few steps that I am using for my document literal stuff and this stuff works from an external tool like XRay. Only when call from an external application like websphere it does not work. This is exactly how it is implemented as said in documentation. And beleive me it works. If you want details here it goes.
the input to the wrapper service is a object by the name soapRequestData and output is soapResponseData

• pub.flow:savePipeline
• pub.flow:restorePipeline
• MAP
• pub.flow:savePipeline
• pub.flow:restorePipeline
• MAP
• pub.soap.utils:stringToSoapData
• pub.soap.utils:getBody (====== Extract body from SOAP request)
• pub.xml:xmlNodeToDocument(====== Convert body to document)
• INVOKE receiveSoapData (my actual processing service)
• MAP (map output to document)
• pub.xml:documentToXMLString (====== Convert response document into XML string)
• pub.xml:xmlStringToXMLNode(====== Convert response XML string to node)
• pub.soap.utils:createSoapData (create the soap data to send the response)
• pub.soap.utils:addBodyEntry(=== Add response node to soapResponseData)

Hope this clarifies. But my problem still lies at the begining of the service itself as I am not able to see anything inthe pipeline if I map soapRequestData to anything though it shows me the data in soapRequestData.

Thx in adv
Bala

Bala,

Are you attempting to map an object variable to a string variable? To save the soap message temporarily, use pub.soap.utils:soapDataToString. Then map the resulting “string” variable to some temporary variable.

For debugging this type of error, I usually use a utility to capture the incoming request and then create a test harness that has as its first line pub.soap.utils:stringToSoapData to create a soapRequestData object variable from the captured request message.

You didn’t mention what release of IS you are using, but I can assure you that, while a bit clunky, the doc/lit wrapper service approach will work well and consistently if coded correctly. If the client constructs the correct soap request and submits it to the default soap processor and you have the universal name settings configured correctly, your service will be invoked. Lots of things to go wrong in that last sentence. I wasted a couple of days once only to find out that my universal name settings were causing the soap request to go to an old, test version of the wrapper service instead of to the one I intended.

Mark

Mark,
I am a bit new to the SOAP world and havent used the SOAP Doc/Literal before agreed. I am using wm IS 6.5 with the following fixes
IS_6-5_Fix4
IS_6-5_Fix7
IS_6-5_Fix12
IS_6-5_Fix14
IS_6-5_Fix37
IS_6-5_Fix40
IS_6-5_Fix45
IS_Tomcat_6-5_Fix1
TNS_6-5_Fix15
IS_6-5_Fix52
IS_6-5_Fix53
IS_6-5_Fix56

Now if you have seen my flow I am using the stringToSoapData. But my problem is I am not seeing any output in the pipeline (if I put a savepipeline there) thats when I started all these experiments. In the end I figured out that if I do a savePipeline and then a restorePipeline keeping both of them enabled as the first 2 steps in my service my flow runs perfectly fine. All the namespace and everything are fine I have tested this with the webMethods connector as well as an external tool called XRay. its just that when it is called from webshere that its not working directly but if I do this savePipeline and restorePipeline thing as my first 2 steps it works
Another question - if anyone could answer . Does the requesting client need to specify that the soap data has to be mapped to a variable called soapRequestData (which is the input to my wrapper service) ?

thx in advance to anyone who can hel.

Bala

Mark,
I tried to use the pub.soap.utils:soapDataToString as soon as I get the soaprequestData. But it gives me an error on that step saying “Parameter soapData must be a valid soapData”. So what I am thinking now is its not recognizing the input as an object of soapData. Becoz if it was it would have been able to convert the soapData to string. Instead the service that I am using stringToSoapData works fine. Does that mean that webMethods is defaulting the soapData it gets in the input to string??

Bala

If your soap client (Websphere, I think) is posting a valid soap request with content-type text/xml to the IS default soap port, then the default soap processor will examine the soap request, extract the QName and attempt to lookup a service to invoke using that service’s universal name properties. Assuming all of that happens, your service will be invoked with an object variable called “soapRequestData”.

Attempting to map a string value into soapRequestData directly in a test harness will not work. You need to either convert the string to soapData using pub.soap.utils:stringToSoapData or use the other built-in services to construct your soap message.

Remember also, that savePipelineToFile won’t save object variables.

If your soap client is getting an internal server error, just check your IS error log to see what might be causing the issue. Capturing the soap request using a utility and using that xml string to construct a soapRequestData object should allow you to test from a test harness stepping into your wrapper service.

Nuke all of your save/restore pipeline statements. I think they are complicating your life unecessarily in this case.

Mark

Mark,
just a question ? I have been getting the data as > and < for > and < signs. Do you reckon that can be causing the issue? Because what I did was asked the websphere person to send them as proper XML tags (> , <)and looks like it works. your feedback is appreciated. I always thot that wm understands that.

Bala

Mark,
I took care of htat by doing the following 3 steps and looks like it works now
pub.soap.utils:soapDataToString
pub.string:HTMLDecode
pub.soap.utils:stringToSoapdata
and then calling the
pub.soap.utils:getBody

this makes it work now.

Thx for all the support.

Bala