In a Sonic 8.0 Sonic Connect Web Service is it possible to capture the incoming (request) and outgoing (response) SOAP Envelopes?
In a Sonic 8.0 Sonic Connect Web Service Client is it possible to capture the outgoing (request) and incoming (response) SOAP Envelopes?
We are using Sonic 8.0 to replace an existing ESB where we do capture SOAP Envelopes. This has been a useful feature in diagnosing problems when communicating with trading partners.
In 8.0.1, you can go to Sonic Connect Editor in Workbench to enable a feature that prints out the entire inbound/outboud HTTP message to the container log.
* In Sonic Connect Editor, look for a service property called "..loggingFeatureEnabled", where and are service and port name in the WSDL, respectively.
* change the value to true.
* save the editor
* upload all
I have found and set the "loggingFeatureEnabled" property to "true" and don't see any output. For the container that the Sonic Connect Service is in (dev_ESBTest) I have:
- View Container Log
- Reset Container Log
- Posted a Web Service message from SoapUI.
- Sonic ESB 8.0.1 installed.
Am I looking in the right place?
We want to capture the SOAP envelopes in our application for later reference. How would we go about that?
Stephen's question did not appear to get an answer. I have a need also to gain programmatic access to the entire SOAP Envelope, more specifically the SOAP header elements - mainly for security implementations.
Does the SonicConnect service allow access to the SOAP headers? Thanks.
If your Sonic Connect Web Service (Client) artifacts were generated by 8.0.0 WorkBench, you will need to regenerate them.
If the SOAP headers are defined in the WSDL, they will be propagated to ESB message as message parts automatically. The message part's container ID will the localname of the SOAP header name. If the SOAP header are not defined in the WSDL, you will need to explicily bind them to ESB by using binding strategy bean. I think by "accessing the SOAP header programmatically", you mean you have a ESB Java service that reads the headers? Your Java service can access the ESB message parts that contains the SOAP headers.
Yes, by programmatic access, I was implying that I wanted to access the SOAP headers inside of a Java custom service mapped to the operations in the WSDL and the SonicConnect service. I will take a look at the binding strategy bean in conjunction with what is defined in the WSDL. Thanks.
When I didn't get an answer here I escalated to Progress support and got great help.
Firstly, I did get the SOAP Envelopes writing to the Container Log working, although this is not a satisfactory solution for my purposes.
Secondly, William is correct. If the SOAP Headers are defined in the WSDL they appear in the message as Parts, with the same name as the header. If you want to capture things like WS-Security or WS-Addressing headers you need to explicitly define them in the WSDL.
The purpose that we want to capture the SOAP Envelopes is primarily to help with the diagnostic process. All our Web Service interactions are with diverse trading partners. Among other value, we find with our current ESB that, when there are problems, it helps to be able to examine the entire SOAP Envelope and to send them to the trading partner. We are hopeful that this feature will be included in Sonic 8.1.
@Steve, can you elaborate on where you'd like the SOAP envolope to be captured? When the SOAP message is received and entered into ESB, the SOAP binding stuff should be stripped because ESB is protocol neutral. If all of the SOAP headers and payloads are propagated to ESB message, would you still need to see the SOAP envelope? As you know, the entire HTTP message is written to Container log (when the logging feature is enabled) for tracing/diagnose purpose. Thanks.
Here's the response to the same question I sent to Li at Progress Support:
- Add a Boolean Service Property, like: CaptureSoapEnvelopes
- Have the web service exchange add message parts with names like: ..SOAP.
"If all of the SOAP headers and payloads are propagated to ESB message, would you still need to see the SOAP envelope? "
The answer is: yes.
The main use of this capability is diagnosing problems. It is not uncommon for a trading partner to either:
- send us rubbish, and the messages parts may not be populated correctly, or
- claim that we didn't send the right data, or
- send stuff in the SOAP envelope that isn't documented in the WSDL they provide.
Being able to send them the the actual content delivered helps enormously in the integration arguments :-). Having it right there with the ESB Message is a lot better than having to dig through a myriad of SOAP envelopes in the Container Log.
@Steve, have you logged an issue with Tech Support?
Thanks for the responses guys.
We have built an Emergency Response exchange which ties multiple jurisdictional and agency systems together virtually. There is a lot of message traffic between systems and we audit/save raw messages. The capability to get the full SOAP message, not just have it logged to a container log, but available to extract and save to a database for a period of time is critical.
It is built and functioning under a competitor product at the moment but we are porting it to Progress offerings.
We prefer not to modify or add to the WSDL. Several vendors already use WSDLs that we would like to maintain in their current form. The binding strategy bean option is our next step. Does Sonic have some decent documentation on this or do we have to look at the CXF documentation and extrapolate to the ESB message passed by the SonicConnect service? Thanks.
Binding strategy binding bean is Sonic specific. A default binding strategy bean is generated for each WS operation whether it is a WS client (invoking use case) or service (exposing use case). The strategy beans for exposing use case can be found in spring.xml. The beans for invoking use case can be found in the .esbcamel files which are located in the .services hidden directory in the WorkBench project. So, once you find the bean, you just need to add "bindingRule" in the bean.
The bean name made by the WSDL service, port, and operation name. You can't miss it. Here is a bean may look like:
Hope this help. Thanks guys for your feedbacks. We will see what we can do regarding carrying SOAP envelope in ESB message.