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.



InvalidOperationException: ‘date’ is an invalid value for the SoapElementAttribute.DataType property. The property may only be specified for primitive types.

InvalidOperationException: ‘date’ is an invalid value for the SoapElementAttribute.DataType property. The property may only be specified for primitive types.

You will get this error while consuming a webservice in BizTalk.

To resolve this, you need to make some changes to the WSDL file that you got from your business partner/department. Take the WSDL file and search for nillable=”true” type=”xsd:date”

Remove the nillable property for the date fields. This is because .Net doesnt support nillable date fields.

There is also one more option, instead of removing the nillable property, you can change the xsd:date type to xsd:datetime. This datatype in .Net will allow nullable implementation.


You will have to keep in mind, that if the partner/department updates the WSDL file then you need to do the above change before you generate the proxies out of this WSDL.


Failed to serialize the message part “XXX” into the type “XX” using namespace “XXX”. Please ensure that the message part stream is created properly.

Failed to serialize the message part “XXX” into the type “XX” using namespace “XXX”. Please ensure that the message part stream is created properly.

You would have got this error while consuming a webservice and trying to send a message to that webservice.


The request message that you have constructed does not really match the specification that is expected by the webservice. to put in simple words, the data types of 1 or many fields in the webservice is expecting a different value that is given value in the request message. Below are the list of items you can consider to re-construct your request message.

1. Some field in your webservice requires a integer field and you have passed a empty string in your request message.

2. Some field … requires a date field and you have passed a empty string or incorrect date format.

3. Some field … requires some enumeration value and you have not passed the right value.

There might be many more, but the base reason is the same.. your request message is not right and you will have to re-construct it. It might be really hard to this trial and error in BizTalk. So I would suggest using SOAP UI or an equivalent tool to first try sending a message and getting the response. If that is successfull, then we can try the same mapping in BizTalk.


A message sent to adapter “SOAP” on send port “XXXX” with URI “xxxxxx” is suspended

A message sent to adapter “SOAP” on send port “XXXX” with URI “xxxxxx” is suspended

Error details: Failed to load “” type.

Please verify the fully-qualified type name is valid. Details: “”.

The type must derive from System.Web.Services.Protocols.SoapHttpClientProtocol.

The type must have the attribute System.Web.Services.WebServiceBindingAttribute.

You get this error when you send a message using a SOAP adapter. And most importantly you didnt specify the proxy class in the SOAP send port configuration or you didnt select the auto generated web port types when binding your logical send port & receive ports in your orchestration.

1. If you have added your webservice as a reference to your project, then the wizard would have generated the web port types for you. All you have to do is to select the auto generated port types when you add the logical port to the orchestration. After that you will have to connect the send port and the receive ports to this port. This will allow using the proxy types being called when the SOAP message is processed by the SOAP adapter.

2. If you are not using the orchestration and doing a messageing only pattern, then you would have generated the proxy class assembly of the webservice. You will have to configure this assembly in the SOAP adapter send port configuration.



Catching fault messages in BizTalk 2010 when consuming WCF services

IN a happy day scenario, when you consume a WCF service in BizTalk, you will get the corresponding message type. However consider there is an exception thrown within the WCF service. Its hard to believe that the WCF send port instead of retrying or suspending the message, will just get the message. I enabled tracking message bodies on the send port and saw that I had got a SOAP fault message. Inside the SOAP fault message, I had details about the exception, WIERD.

There were posts in the internet which pointed me to implement the solution.

1. I created a fault operation in the Request/Response logical port. I set the type for the operation as BTS.soap_envelope_1__1.Fault

2. Added a scope shape and dragged the send/receive shapes within the scope.

3. Added a exception handler of the type of the fault operation i.e. BTS.soap_envelope_1__1.Fault.

4. Create a message which is again of the same type as discussed before and assign the exception variable to the message that we have created.

5. In the send port configuration, go to the Messages tab. In the inbound biztalk message body section, choose Path instead of the default Body radio button.

In the Body Path expression, you will have to set the list of all possible responses you will get

i.e. You will get the successful response as well as the failure response. You get a failure message within a fault node, so you will have to specify a xpath expression to extract the content that lies within the fault node. So you will have to specify like this /*[local-name()=’Fault’].

However you dont get a failure message everytime, rather you get the success message most of the time and sometimes get a failure message(this is how you design and implement the solution, for me its always the other way round 🙂 )

So to cope with that, you need to give a union xpath expression so that the WCF send port applies a or condition and picks up the nodes. so you need to write something like this /*[local-name()=’Fault’] | /*[local-name()=’ProcessStudentApplicationResponse’]

See the pipe | symbol which seperates the fault xpath expression and the success xpath expression.

5. So, now when a fault message is received by the BizTalk send port, the orchestration will understand that and the code within the exception handler will execute.

6. As we have assigned the exception variable to the message, we can access the fault details and can take necessary action.

Possible actions that you can take

1. Build a loop shape around this scope and retry until the message is sent. You can set a configurable value for retrying.

2. Use ESB exception framework by construct

If you dont implement the fault handling stuff when you consume the WCF service, then you wont have control in orchestration to handle that.

Publish Schemas/Orchestrations as webservice in BizTalk 2010

Beware that when you work in BizTalk 2010 and .Net framework 4, you should keep in mind that the biztalk assemblies has to be there in the new Assembly location(c:\Windows\Microsoft.NET\assembly\GAC_MSIL). Most importantly when you expose your schemas/orchestrations as WCF service, the application pool where you host your wcf service should run in .Net framework 4. Otherwise you will get a mesage type not found error when you receive the message in your receive location or if you would have configured a receive pipeline, it will report saying the pipeline is missing.



Exception has been thrown by the target of an invocation

You may get this error when you use BizTalk SAP adapter to call a BAPI in SAP.  This error mostly doesn’t occur in development machines and it usually happens  when you migrate the code to higher tiers(staging server or Production).

The interesting part about SAP is we have got out of box components to generate Schema structures for IDOC and BAPI’s. We also have SAP adapter to  communicate with SAP. When we want to communicate with SAP using IDOC mode, we don’t need to have any assemblies specific to the schemas. However, when we want BizTalk to call a BAPI in SAP, we need to have a dll in the below folder
[BizTalk SAP adapter Installed Directory]\Microsoft BizTalk Adapter v2.0 for mySAP Business Suite\Bin

Before you start sending messages from BizTalk to RFC, you need to first generate schemas from SAP. There are two modes
where you can either generate a schema from an IDOC or RFC. When you given your criteria and proceed to generate the schema, the tool generates a dll and places it in the above mentioned folder. Then you go forward and implement your business process and deploy your artifacts and test the application. But you should remember to copy this dll to the target machine where you will deploy the
application and where it will be used for testing or live production server.

Hope this will be helpfull for someone.

I didnt find a blog item anywhwere which could have saved me 2 hours of my time.