Capture SOAP Envelope in Sonic Connect

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

* shutdown

* upload all

* restart

HTH

Thanks William

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.

@Stephen

If your Sonic Connect Web Service (Client) artifacts were generated by 8.0.0 WorkBench, you will need to regenerate them.

@Chris

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.

Hi Chris

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.

Regards

Steve

@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.

Hi William

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. 

o   Example:

§  VehiclePingService.VehiclePingOperation.SOAP.IN 

§  VehiclePingService.VehiclePingOperation.SOAP.OUT

Regards

Steve

Hi William

"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.

Regards

Steve

@Steve, have you logged an issue with Tech Support?

@William, @Steve,

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.

@William

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:

"ServiceName.OperationName.Invoke.BindingStrategy" class="com.progress.sonic.esb.camel.SoapBindingStrategy">

  "inBindingRules">   

  "outBindingRules">   

Hope this help.  Thanks guys for your feedbacks.  We will see what we can do regarding carrying SOAP envelope in ESB message.

Hi Chris

What a relief to to find I'm not the only one asking for this.

Hi William

The tech support call number is W102090134

Regards

Steve

William, thanks for the responses.  The binding strategy in and out rules seem simple enough.  We will be dealing with a SOAP Header construct such as this below:

    "http://schemas.xmlsoap.org/soap/envelope/">
        023A-9912-9283-DEAD-BEEF
   

How do you handle a SOAP header mapping, such as the construct, which is not a simple name/value but is a complex type versus simple type for both incoming (request) and outgoing (response)?

@Chris, your binding rule may look like this.

@William

Thanks.  I take it the elements that should be the child/children of , such as need to be the content of that part, exactly as we want it placed into the element in the header, so:

023A-9912-9283-DEAD-BEEF, OR

023A-9912-9283-DEAD-BEEF ?

The namespace appeared to be accounted for by the namespace you included in the braces in the binding reference above.

If your inbound SOAP message has a header such as:

   
        023A-9912-9283-DEAD-BEEF
   

And you have a binding rule as follow:

The SOAP header will be bound to XQ Message part, content id "Part1", (content type is "text/xml") and the content will be:

     023A-9912-9283-DEAD-BEEF