this is w.r.t to rest services in wm9.6, particularly w.r.t receiving the payload from the incoming HTTP request message.
lot depends on the content-type of the request message
if content-type=application/json ; based on the configurations (server.cnf, or query string in request), the payload must appears in my service’s pipeline as jsonStream, jsonBytes or parsed variables.
issue1: if i declare variable with name jsonStream, i could process it. but when i savepipeline, i dont see these pipeline variables in my saved pipeline file
if content-type=text/xml ; based on the configurations (server.cnf, or query string in request), or the service properties, or the payload must appears in my service’s pipeline as xmlStream, xmlBytes or node(parsed xml object)
issue1: except for xmlBytes, i dont see xmlStream or node in my service’s pipeline.
i might be missing w.r.t some configuration, not sure whats it. please help me
irrespective of content-type of the http request message, i would expect either bytes or stream available for me in service’s pipeline to process it.
issue3: when i savepipeline, i dont see any pipeline variable with the http payload
let me know your experiences/issues and possible configurations to definitely make http payload appear service’s pipeline
fml2 is right. Plus, what you see in your pipeline is directly dependent on the content handler that is used to process the message. The content handler is typically chosen based on the value of the content-type or accept HTTP header. Take a look at the IS Admin guide as it has a whole section on content handlers.
Regarding your XML issue, if you’re setting the content type to text/xml and you’re posting the XML message in the body of the HTTP request, you should most definitely be getting a XML node in the pipeline. If you’re not, then something is missing. Another way to get an XML node in your pipeline is, for example, to post the XML from an HTML form. In this case, you should name that field in the form $xmldata. When the IS gets an HTML form post, which has content-type of application/x-www-form-urlencoded, it knows to look for an $xmldata variable.
this is mostly happening. not sure how to figure it out or is it bug in the product?
another way to get an XML node in your pipeline is, for example, to post the XML from an HTML form. In this case, you should name that field in the form $xmldata. When the IS gets an HTML form post, which has content-type of application/x-www-form-urlencoded, it knows to look for an $xmldata variable
this i have done as work-around. but this is not a correct way of handling the text/xml or text/plain payload
It definitely shouldn’t be a bug. I also have 9.6 installed and it works fine without any fixes. I use soapUI for testing scenarios like this and I must say that the IS responds as expected to the different content types I provide.
How are you posting your XML? Perhaps you could use soapUI or just use the pub.client:http service to help you figure out what’s going on.
Last but not least, I also like using TCP trace tools when trying to debug through issues like this. Designer (Eclipse, actually) comes with one. Just open the TCP/IP Monitor view.
Thank for the clarification that its works for you. I will debug my side whats going wrong.
Yes, i’ve used SOAP UI/Chrome browser apps/firefox plugin apps for the Rest clients. Even written IS http client as you suggested. Also used TCP Monitor on Eclipse(Designer).
After all these, i’ve posted my queries on tech communities.
If you’re sending the XML via an HTTP Post and you’re using REST, you should have a service called _post or _default inside your REST service’s folder. Can you confirm that? Also, are you using the REST directive? In other words, does you URL look like this: http://:/rest/.?