I've got a custom service that reformats an incoming SOAP document, then sends it to a a WS service. Occasionally, the receiving web service is down, resulting in the receiving Tomcat sending a HTML "application not available" response. This gets consumed by the WS service, which fails to parse it as a SOAP message (because it isn't). When the next downstream process receives the message, it's a SonicESB.Fault message, containing only the parse failure and a stack trace.
Is there some way to configure the WS service to include the original Tomcat response in the fault message? It's very inconvenient to have a SOAP fault occur, but receive nothing but the stack trace from the parsing failure. Is it how I've configured the WS service? Could I send it differently in order to receive the "app not available" response? With my lack of experience I'm not sure which direction I should be looking for a workaround. Any help would be greatly appreciated!
Hi Jim
Is the WS service Sonic connect or are you using the older V7 web service stack?
Thanks
-Mahesh
We're running V7.6. I'd like to upgrade, but our Sonic license is through a third-party software provider, so until they tell me I can upgrade, I'm stuck.
Jim can you send the itinerary and the stack trace.
Peter
I'm not sure what physical parts constitute the itinerary, but I see that there is an "itinerary" element in the .esbp file, so I'm including that. The other file is the stack trace, packaged into SOAP fault format, and dropped into a directory by a subsequent process that I added at the FAULT EP for the web service call. I've also included the .esbws file, 'cause it seemed pertinent.
The process I uploaded transforms an incoming SOAP document into a different format (step 1), then sends it to the remote web service (step 2). This fails when the remote service is down - it's a Tomcat app, so Tomcat sends an HTTP Status 503 response - and it's this response that generates the SOAP fault. Sonic sends along the SOAP fault, but apparently doesn't keep any part of the Tomcat HTTP response. How can I retrieve/retain the original, non-SOAP HTTP response?
Thanks,
Jim
Looks like the ESB process is formatting SOAP Envelope directly? Then sending this SOAP envelope to a JMS endpoint.(JNDI) using a .esbws/wsdl based on the SendToJMS example.
If this is the case, is there a reason that the ESB process doesn't call the Tomcat-based SOAP Web Service Tomcat directly (you drag the wsdl exposed by the Tomcat WS directly onto the itinerary, select an operation, then map the itinerary message to WSDL parts) What is different here is we let the framework format the SOAP envelope - your itinerary deals in parts.
What is the queue name referenced by the JNDI address supplied in the ESB jndi header? On the broker is the destination set up for HTTP Direct basic? If so setting it up for HTTP direct SOAP should make all HTTP fault be returned to the itinerary in SOAP Fault format.
First, thank you for the VERY helpful response! We obtained Sonic 14 months ago, and hired an outside consultant/contractor to design and develop all of the Sonic processing for our ERP re-implementation project. I didn't begin any Sonic-related training until last December, when I was enrolled in the Progress web-based training curriculum. I started learning Java in April.
Yes, the ESB process is formatting the SOAP envelope directly. Why this was done, I do not know. (We parted ways with our consultant in June, not under the best of circumstances.) I suspect it might have to do with the fact that each message/document type we send up has a different WSDL/web service call, and the consultant wanted to avoid changing the ESB app every time a new document was created. (I don't even know if that is a valid concern; when one is still learning what is possible, understanding what is good practice is almost impossible without outside advice!)
As to your other questions: the queue name is "SampleQ1", and under the broker the destination is set up for HTTP Direct Basic. This last point seems to me to be the first thing to try: if simply changing that definition to HTTP Direct Soap makes the HTTP fault come all the way back to the ESB-WS exit endpoint, then I'll be extremely happy. The other issue (calling the remote web service directly using the WSDL) is less clear, mostly because of my tenuous grasp of Web Service and WSDL concepts.
Again, thanks for your feedback!
Regards,
Jim
Changing the routing definition from "HTTP Direct Basic" to "HTTP Direct SOAP" did what I hoped it would do. When the target Tomcat-based app is down, I now receive a SonicESB.Fault XML response, with the of "This application is not currently available".
Thanks again for your help!