Sending Soap with Attachments (SwA) using BizTalk – Part 1

This is a continuation to my previous article. Please have a look if you hadn’t seen it.

Sending Soap with Attachments (SwA) using BizTalk

Below are the steps that we have to follow for this exercise.

1. Create a custom message encoder which can send XML as an attachment in the SOAP envelope message.

2. Create a WCF service which can send the SOAP message with attachment.

3. Create the BizTalk application which can consume the custom WCF service.

Steps are easy isn’t. In this post we will only cover Step 1.

As I have told in the previous post, this custom encoder has been developed by Austrin interoperablity council and they have published the code in Codeplex. I have taken this code and removed some hard coded stuff and placed it in configurable properties.

I have uploaded the full source code below.


Sending Soap with Attachments (SwA) using BizTalk

Soap With attachments is a very old technique and is still used in lot of legacy systems. More new technologies has emerged like MTOM which is widely used within the WCF arena. That said, there is no out of the box support within WCF to send a SOAP message with attachments.

An Austrian Microsoft Interoperability Council had a challenge to consume a webservice which expects to send a SOAP message with attachments.

They have developed a custom encoder which can add the zip message as an attachment in the outgoinh SOAP envelope.

However I had a different challenge in consuming a webservice which requires me to send a soap payload which has an XML attachment. So I had to modify the custom encoder in such a way that I can attach a XML document. I had lot more challenges. The webservice which I had to consume was written in Java and the field appears as xsd:hexBinary in the WSDL file. So there is no way I can add a service reference / web reference to my project. I did tried that, but when I tried to send the message, the server was rejecting the message. The reason for this is Visual studio when generating the client code for the service, puts the type as xsd:base64binary.

So, I had to code the datacontracts, messagecontracts and servicecontracts based on the WSDL. Then I plugged in the code to use the encoder to attach the XML message. There is no direct way to do this from BizTalk. I wrote this entire logic in a WCF Service which acts as a client to the Target web service and acts as a Server for BizTalk. BizTalk application will consume this WCF service and send the SOAP message with attachment.

I am going to present an article with walkthrough in the next post.


Using Fiddler to view HTTPS data when consuming a service from a WCF Client

There might be an instance during your development period or early testing period to see the data that is going over the wire when you send something over HTTP or HTTPS protocol. There are many tools in the market to sniff through the wire and show you the entire raw message that goes through and comes in. This is otherwise called as Man in the middle attack. As a simple case, You have a WCF client that has to speak to a third party webservice which is hosted using HTTP protocol. All you have to do sniff is to add a proxy address in the binding of your WCF config file. This will route all the messages via the Fiddler.

However if the third party service is hosted using HTTPS protocol and a certificate is attached to it, then it is little bit complex. When you follow the same process, you will get the below error.

Could not establish trust relationship for the SSL/TLS secure channel with XXXXX

In the inner exception you will get The remote certificate is invalid according to the validation procedure

This is because for the WCF client, fiddler act as a service provider and the certificate that fiddler provides is not present in the Trusted Root Certification Authorities.

You can read this URL to have a better understanding of what happens under the covers when you use fiddler.

I will describe the steps that is required to to use Fiddler in a WCF service.

1. First download and install fiddler if you dont have it.

2. After it has been succesfully installer, go to Tools-> Fiddler Options

2.1 HTTPS Tab :

Check if Capture HTTPS CONNECTs and Decrypt HTTPS traffic is enabled.

Click the button EXPORT FIDDLER ROOT CERTIFICATE TO DESKTOP. This will export the fiddler certificate to the desktop. ( I will tell you how to add this certificate to the certificate store.)

2.2 Connections Tab:

In the fiddler listens on port textbox, provide 8888 as the port number. If this port is already used, then give a port number which is not used.

After making the above changes, click OK.

3. Now open a browser and type http://localhost:8888 ( or the port number that you have given in the connections tab). This will initiate the fiddler service.

4. Go to your WCF config file and add a new binding. Within that add a custombinding and choose httpstransport. The config should be like this.

<binding name=”SampleBinding”>
<httpsTransport maxReceivedMessageSize=”62914560″ authenticationScheme=”Anonymous”
maxBufferSize=”62914560″ useDefaultWebProxy=”false” proxyAddress=”http://localhost:8888
proxyAuthenticationScheme=”Anonymous” />

You would then add this binding to the client section.

<endpoint name=”testEndpoint”
bindingConfiguration =”FISBinding”

This would make the traffic from the service go via the Fiddler. However as I said before you will get the following error.

Could not establish trust relationship for the SSL/TLS secure channel with XXXXX

In the inner exception you will get The remote certificate is invalid according to the validation procedure

To resolve this, all you have to do this is,

Import the certificate that we have exported in step number 2.1 to the Trusted Root Certification Authorities. Also when you should import this to the Computer account and not the user account.