Capturing SOAP messages that serialization cannot handle
In my job I have to write the code which consumes third party web services. In the course of working with differing companies' web services I discovered that some of those would return invalid XML data. That data was invalid due to either from an outdated schema or had some subtle problem that would cause Microsoft's deserializer to throw an exception. Since I needed to see the data sent to me, I had to work around the de-serialization operation and access the raw SOAP message which Microsoft's code refuse to divulge to my web service. This article explains I was able to end-around Microsoft by creating a specific attribute tied to a method call that allows me to see the SOAP message before serialization and will log the message for access when needed.
- These steps are not how I coded it, but how you should proceed with the implementation.
- This article does not cover the whys or hows of C# web services. It only details the acquisition of SOAP data in exceptional circumstances.
- This problem occurred in a C# web service accessing a third party web service, hence the design taken below.
Step 1: Inserting a custom attribute into the proxy code
Since we are consuming a foreign web we either have to deal with Microsoft's generated proxy code or we have to create it by hand; regardless we need to find where the invoked call returns data. That is the location where we will place our specialized attribute.
If it is a generated proxy then you will need to look in the hidden file Reference.cs which resides in the web services folder. Once found, locate the primary method that returns data. That is the location were you will need to add the attribute that will handle the leg work of getting around the de-serialization situation.
public zzzResponse ProcessData(...
object results = this.Invoke(...
- If this is the generated proxy code, you will need to add the attribute every time the code is re-generated.
- You will need to add the reference to the namespace that the attribute code resides in as shown in future steps. The build process will remind you if you forget.
Step 2: Defining custom attribute SoapExtensionAttribute
The attribute is the hook for our data logging process. Here is the class which is the attribute with the appropriate overrides.
Step 3: Creating the SoapExtension
The SOAP extension will work with the flow of the handling of SOAP message in an autonomous fashion. Our goal is not to damage the data stream, only to look into it for data extraction.
Step 4: Logging the data
This is the step that really got to me. If your code is in a web service (mine was a web service calling a web service) how does one pass data between the SOAP process and the code accessing the proxy? In some situations such as ASP.NET one can put the message on the
HttpContext, but that wasn't an option for my code in a web service. The below code handles the situation of a null
HttpContext by placing the data in the
Remoting call context.
Step 5: Consuming the logged data
For my web service if the incoming data was invalid, my indication was either an exception thrown by the de-serializer or simply a
null return value by the data access method. At that point my code tries to do a post extract of the SOAP raw data and handles the message.
[Editor Note: Line breaks used to avoid scrolling.]
- Let me know if there is possibly a better way or things could be improved.