XML - Alexander Development

Accessing raw SOAP requests/responses from Dynamics CRM web services in C#

Lucas Alexander — Thu, 21 Feb 2013 00:00:00 GMT

One of the things I have always found frustrating about WCF is that it effectively hides the actual SOAP message XML requests and responses in web service calls. From a Dynamics CRM perspective, I can think of at least three good reasons it would be nice to be able to access the raw XML generated and consumed by clients built with the SDK:

Display retrieved results with XSL like I demonstrated in this client-side FetchXML example
Log the raw messages for QA, auditing or regulatory reasons
Process the XML to easily generate "wrapper" interfaces

In this post I will show how to capture client requests and service responses for interfaces built with the CRM SDK as well as interfaces that use a WSDL-based proxy using a client message inspector.

The message inspector class

The easiest way to capture the actual SOAP messages is to use a client message inspector object (IClientMessageInspector). The BeforeSendRequest and AfterReceiveReply methods of the client message inspector will give you the SOAP request and response as string objects that you can process however you want. Here is a class called MyInspector that stores requests and responses in list objects called sentMessages and receivedMessages respectively MyInspector.cs (1.55 kb). The original source for this code is http://social.msdn.microsoft.com/Forums/en-US/wcf/thread/fa3f4c55-5835-43f2-892f-737b4bccb598.

Using the message inspector

Once you have your message inspector ready, you have to have to update the behaviors for the destination endpoint to use it. If you are using the SDK, all you have to do is instantiate a new MyInspector object and then add it to your OrganizationServiceProxy's ServiceConfiguration.CurrentServiceEndpoint behaviors. The code below contains a helper function that creates a new OrganizationServiceProxy object and adds the message inspector.

static OrganizationServiceProxy createProxy(string orgUri, string username, string password)  
{  
ClientCredentials credentials = new ClientCredentials();  
Uri organizationUri = new Uri(orgUri);  
  
IServiceConfiguration config =  
ServiceConfigurationFactory.CreateConfiguration(  
organizationUri);  
  
credentials.UserName.UserName = username;  
credentials.UserName.Password = password;  
  
OrganizationServiceProxy serviceProxy = new OrganizationServiceProxy(config, credentials);  
  
MyInspector inspector = new MyInspector();  
serviceProxy.ServiceConfiguration.CurrentServiceEndpoint.Behaviors.Add(inspector);  
  
return serviceProxy;  
}

If you are using WSDL-based proxy, adding the message inspector is slightly different, but just as simple. As with the SDK, you first have to instantiate a new MyInspector object, but you then add it to your WCF client's Endpoint.Behaviors object. The code below shows an version of the ExecuteWhoAmI method from the CRM SDK WsdlBasedProxies sample with the message inspector added.

private static void ExecuteWhoAmI(ClientCredentials credentials, string serviceUrl)  
{  
using (OrganizationServiceClient client = new OrganizationServiceClient("CustomBinding_IOrganizationService",  
new EndpointAddress(serviceUrl)))  
{  
ApplyCredentials(client, credentials);  
MyInspector inspector = new MyInspector();  
client.Endpoint.Behaviors.Add(inspector);  
  
OrganizationRequest request = new OrganizationRequest();  
request.RequestName = "WhoAmI";  
  
OrganizationResponse response = (OrganizationResponse)client.Execute(request);  
  
foreach (KeyValuePair result in response.Results)  
{  
if ("UserId" == result.Key)  
{  
Console.WriteLine("User ID: {0}", result.Value);  
break;  
}  
}  
}  
}

Accessing the messages

Once you have added the message inspector to your endpoint behaviors, you are ready to call the CRM web service and access the request and response messages. Here is an updated version of the ExecuteWhoAmI method that writes the request and response messages to the console:

private static void ExecuteWhoAmI(ClientCredentials credentials, string serviceUrl)  
{  
using (OrganizationServiceClient client = new OrganizationServiceClient("CustomBinding_IOrganizationService",  
new EndpointAddress(serviceUrl)))  
{  
ApplyCredentials(client, credentials);  
MyInspector inspector = new MyInspector();  
client.Endpoint.Behaviors.Add(inspector);  
  
OrganizationRequest request = new OrganizationRequest();  
request.RequestName = "WhoAmI";  
  
OrganizationResponse response = (OrganizationResponse)client.Execute(request);  
  
foreach (KeyValuePair result in response.Results)  
{  
if ("UserId" == result.Key)  
{  
Console.WriteLine("User ID: {0}", result.Value);  
break;  
}  
}  
  
Console.WriteLine("****REQUEST****");  
foreach (string sent in inspector.sentMessages)  
{  
Console.WriteLine(sent);  
Console.WriteLine();  
  
}  
  
Console.WriteLine("****RESPONSE****");  
foreach (string received in inspector.receivedMessages)  
{  
Console.WriteLine(received);  
Console.WriteLine();  
}  
Console.ReadLine();  
}  
}

Misadventures with CRM 2011 web services and ADFS

Lucas Alexander — Sun, 17 Feb 2013 00:00:00 GMT

I think the Dynamics CRM 2011 SDK is swell for interoperability, but I wanted to get a closer look at how the actual web service calls work, so I decided to access the sandbox CRM instance my company provides using a WSDL-based proxy as described here. Because the SDK has several examples for connecting to CRM instances using different kinds of authentication in the SDK\SampleCode\CS\WsdlBasedProxies directory, I figured this would be a piece of cake. As it turns out, I was wrong.

Disclaimer: before asking anyone read through to the end of this post, let me say I think the problem I ran into may be fairly specific to my organization's ADFS setup because despite a lot of web searches, I couldn't find anything that specifically addressed my issue from a Dynamics CRM perspective. On the other hand, if you are having the same problem I did, maybe this post will save you some time.

Because my CRM sandbox instance is an Internet-facing (IFD) deployment, I looked at the ifd project in the SDK's wsdlbasedproxies solution and followed the setup instructions. I ran into a problem almost immediately. After creating service references for the Discovery and Organization services, the next instruction is:

In the "" node, locate the "" node. This node allows the user to specify which Issuer should be used when issuing a token. The various STS endpoints will be present in the commented out "alternativeIssuedTokenParameters" node. In my example, UserNameMixed is used. In order to use UserNameMixed, the "binding" and "bindingConfiguration" attributes need to be updated to match the node in "alternativeIssuedTokenParameters". The easiest way to find this endpoint is to search for "https://adfs.contoso.com:555/adfs/services/trust/13/usernamemixed". In the generated configuration file, you'll find: Copy this node and replace the current issuer node in the "" node.

Well, in my app.config file, there was no alternativeIssuedTokenParameters node. All I had was these two elements in my CustomBinding_IOrganizationService and CustomBinding_IDiscoveryService bindings:

I figured what the heck, let's try to run the sample in debug mode anyway and see if it works. Spoiler alert: it didn't. Instead of connecting to CRM, I got a Windows CardSpace (never heard of it before) screen pop up asking me if I wanted to send a card to the site. Seeing as the SDK readme doc had made of mention of CardSpace, I figured something must be misconfigured, so I closed the window and stopped debugging.

It took me a while to figure it out (I'm a developer, not a networking guy), but I finally realized that my WCF client knew it should be using a token from the SOMEDOMAIN.COM STS to talk to CRM, but it didn't know how to get one. After some fruitless searching, I stumbled upon a post by the MCS UK dev team called "Federated Security: How to setup and call a WCF service secured by ADFS 2.0." At first I looked at programmatically getting a token, but then I decided it would be much simpler to take the config-based approach described in this MSDN tutorial: http://msdn.microsoft.com/en-us/gg557876. Also, the config-based approach is what should have been happening in the SDK sample anyway.

To get the issuer element of my bindings right, I first created a service reference for the address in the issuerMetadata element. As soon as I did, my app.config file was updated with lots of binding and endpoints that looked like what was described in the SDK sample setup file, so I figured I must be on the right track.

Knowing that my sandbox CRM instance used the "/adfs/services/trust/13/username" endpoint for getting a token from the ADFS STS (thanks to watching Fiddler while a desktop application that uses the SDK connected to my CRM instance), I searched in the updated app.config file for that string, and I found this element:

Next, I commented out the existing issuer and issuerMetadata elements in my CRM service bindings and replaced them with the address, binding, binding configuration and identity details from the STS endpoint like so:

After that, I ran the sample project in debug mode, and it worked perfectly.

Why did this happen?

I will readily admit I don't understand the ins and outs of ADFS. I get the point of it and the basics of how it works, but I certainly don't know why the configuration of my CRM instance would lead to these results. All I can say at this point is that I'm glad I've got it working, and I'll know what to do in the future if a problem like this ever comes up again.