As we want the callers not to be aware of the way we retrieve data, we have to passing back data to them in the form they expect it: “BusinessEntity” derived classes or collection of them. This may seems hard, but it isn’t. You can build the statement in way that it will produce data in XML, in a format that can be directly deserialized in entity instances.

So, let’s view how we can:

• Compose the SQL statements in such a way the will produce the xml we need
• Deserialize the data from xml to entities

Take a look at this query:

WITH XMLNAMESPACES
(
  'http://www.w3.org/2001/XMLSchema' as xsd
, 'http://www.w3.org/2001/XMLSchema-instance' as xsi
, 'http://schemas.microsoft.com/crm/2006/WebServices' as crm
)
SELECT name as 'crm:name'
     , accountid as 'crm:accountid'
     , donotphonename as 'crm:donotphone/@name'
     , donotphone as 'crm:donotphone'
     , address1_shippingmethodcodename as 'crm:address1_shippingmethodcode/@name'
     , address1_shippingmethodcode as 'crm:address1_shippingmethodcode'
     , modifiedbyname as 'crm:modifiedby/@name'
     , modifiedbydsc as 'crm:modifiedby/@dsc'
     , modifiedby as 'crm:modifiedby'
     , createdbyname as 'crm:createdby/@name'
     , createdbydsc as 'crm:createdby/@dsc'
     , createdby as 'crm:createdby'
     , statuscodename as 'crm:statuscode/@name'
     , statuscode as 'crm:statuscode'
     , statecodename as 'crm:statecode/@formattedValue'
     , statecode as 'crm:statecode'
  FROM Filteredaccount
   FOR XML PATH ('account')

The WITH XMLNAMESPACES, the field aliases and the FOR XML PATH do the magic, and we get data in this format:

<account xmlns:crm="http://schemas.microsoft.com/crm/2006/WebServices" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <crm:name>Adventure Works Ltd.</crm:name>
  <crm:accountid>E85D1177-EE17-DB11-87E4-0000E2998A6B</crm:accountid>
  <crm:modifiedby name="CRM Administrator" dsc="0">89A611D4-C7BD-DB11-A4E3-005056A80A71</crm:modifiedby>
  <crm:createdby name="CRM Administrator" dsc="0">89A611D4-C7BD-DB11-A4E3-005056A80A71</crm:createdby>
  <crm:statuscode name="Active">1</crm:statuscode>
  <crm:statecode formattedValue="Active">Active</crm:statecode>
</account>
<account xmlns:crm="http://schemas.microsoft.com/crm/2006/WebServices" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <crm:name>Contoso Inc.</crm:name>
  <crm:accountid>A00ED7BB-9D0D-DB11-9073-000C293F9D57</crm:accountid>
  <crm:donotphone name="Allow">0</crm:donotphone>
  <crm:modifiedby name="CRM Administrator" dsc="0">89A611D4-C7BD-DB11-A4E3-005056A80A71</crm:modifiedby>
  <crm:createdby name="CRM Administrator" dsc="0">89A611D4-C7BD-DB11-A4E3-005056A80A71</crm:createdby>
  <crm:statuscode name="Active">1</crm:statuscode>
  <crm:statecode formattedValue="Active">Active</crm:statecode>
</account>

That is exactly what you need to obtain, with the help of XmlSerializer, a collection of accounts:

XmlReader xmlReader = cmd.ExecuteXmlReader();
xmlReader.Read();

while (xmlReader.ReadState != ReadState.EndOfFile)
{
    xml = xmlReader.ReadOuterXml();
    StringReader reader = new StringReader(xml);

    account acc = serializer.Deserialize(reader) as account;
    accounts.Add(acc);
}

// convert accounts in a BusinessEntitesCollection...

Note that:
- the standard SQL syntax for a property is:

, property as ‘crm:property‘

- properties expressed by CRM object model in form of “Lookup” are splitted, on the views, in three columns:

, propertyname as ‘crm:property/@name‘
, propertydsc as ‘crm:property/@dsc‘
, property as ‘crm:property‘

- properties expressed by CRM object model in form of “Picklist” and “CrmBoolean” are splitted, on the views, in two columns:

, propertyname as ‘crm:property/@name‘
, property as ‘crm:property‘

- StatusCode and StateCode are the only further singularity.

Given these rules isn’t hard to build a class able to generate statements for any entity type. For an hard-core solution, add something able to translate a QueryExpression in SQL statements…

http://<yourservername>/mscrmservices/2006/crmservice.asmx.

I’m not going to spend words on the web service methods, they are basically CRUD operation. The most important think is, I think, the way your code interacts with the web service. Your code shouldn’t directly use the proxy class generated by Visual Studio, is better to wrap it in a class that, just to begin, exposes the same functionalities the proxy do. Than you can start to write your code against your wrapper and, at later time, introduce enhancement in your wrapper distributing the benefits of these enhancements to all the callers of your wrapper and without modifying them. These enhancements can include:

• Increase the performance of the HTTP/SOAP calls by implementing this simple but power solution. I already wrote about this, but it’s so powerful!
• Increase the data retrieving performance by substituting web service calls with database access (on filtered views). A will dedicate an entire post to this.
• Data caching, for data that isn’t critical and doesn’t change frequently.
• Data integrity constraints enforcement. Constraints you apply to your entity attributes are enforced only by the UI, not by the web service. But you can read those constraints from the MetadataService and apply them before passing data to CrmService. May be I will write a post even on this.

Here an example of how the wrapper can expose the functionalities the proxy do, with some little features…

public class CrmServiceClient
{
	public virtual BusinessEntity RetrieveEntity(string entityName, Guid entityId)
	{
		return RetrieveEntity(entityName, entityId, new AllColumns());
	}

	public virtual BusinessEntity RetrieveEntity(string entityName, Guid entityId, ColumnSetBase cols)
	{
		BusinessEntity entity = null;

		try
		{
			entity = m_CrmService.Retrieve(entityName, entityId, cols);
		}
		catch (SoapException ex)
		{
			LogException(ex);

			string msg = ExtractSoapExceptionMessage(ex);
			throw new Exception(msg);
		}
		catch (Exception ex)
		{
			LogException(ex);

			throw;
		}

		return entity;
	}

	// other mehods...
}

And here the way I implemented the HTTP/SOAP calls enhancement explained in the article I linked above (note the use I make of the ConnectionGroupName property to limit the security treats that may occur by setting UnsafeAuthenticatedConnectionSharing to true):

public class CrmServiceClient
{
	// other mehods...	

	private CrmService ActivateCrmService(NetworkCredential credentials, bool unsafeAuthentication)
	{
		CrmService service = new CrmService();
		service.Credentials = credentials;

		if (unsafeAuthentication)
		{
			service.UnsafeAuthenticatedConnectionSharing = true;
			service.ConnectionGroupName = CreateSecureGroupName(credentials);
		}

		return service;
	}

	private string CreateSecureGroupName(NetworkCredential credentials)
	{
		string toEncode = credentials.UserName + credentials.Password + credentials.Domain;
		Byte[] bytes = Encoding.UTF8.GetBytes(toEncode);

		SHA1Managed Sha1 = new SHA1Managed();
		Byte[] updHash = Sha1.ComputeHash(bytes);

		return Encoding.Default.GetString(updHash);
	}
}

I know there’s nothing special in these snippets, but consider this post as an intro. Something more interesting is coming soon.

When doing any Microsoft CRM development effort, Project Managers will need to work with our clients to gather requirements and design solutions within Microsoft CRM. Typically a large part of this effort is to develop a Functional Design Document or Vision Document that describes exactly what we are going to build on the Microsoft CRM Platform. These documents typically include screen mockups of what the final UI may look like. The process of creating these mockups can be very time consuming, but the results are well worth the effort.

To make this process easier we developed a set of 29 custom Visio shapes, that when used in conjunction with other Visio Windows XP User Interface shapes, allow our Project Managers to quickly and easily design mock CRM UI screens that meet almost any client requirement.

Link: Invoke Systems Visio Shapes for Microsoft CRM 3.0.

• Embedding Maps in CRM Forms
  

  Let’s add a map to the CRM form in an iframe and see where they are! This is actually really simple and all it requires is one HTML page and some changes in the form editor.

• Speed Racer – Call CRM at speeds that would impress even Trixie!
  

  The other day I was doing a bit of testing to find the fastest way to make rapid calls to CRM Web Services. The truth of the matter is that when you are calling CRM Web Services you are pretty much down to the metal; so the only places I found to make optimizations were at the .NET Web Service Request level and at the server level. The good news is that with a few very easy tweaks you can improve rapid CRM calls by almost 50%!

• Getting inside Microsoft CRM – Part I
  

  We will write our own CRM-host to get inside CRM and get access to the internal CRM-object model at runtime. This is fairly easy.

• Microsoft Dynamics CRM 3.0 List Web Part
  

  The List Web Part for Microsoft Dynamics CRM 3.0 provides a subset of the Microsoft CRM record list functionality. It allows users to view Microsoft CRM records as a list from a SharePoint dashboard, open records in Microsoft CRM 3.0 from the list, and connect Microsoft CRM Web Parts to filter different lists.

• Easy Microsoft CRM 3.0 data access using RSS
  

  Learn how you can combine Microsoft CRM and RSS technologies to set up dynamic business data feeds.

It supports customization in varioius way: from the simplest, as the workspace that every user can personalize or the web forms that can be edited, to the more sophisticated like the modifications that can be done to the business logic throught a relative easy-to-use graphical interface: you can edit native entities (such as Contact, Account, Case, etc…) by adding/modifyng fields and relations between entities and create your custom enties.
Substantially Microsoft CRM offers you a complete and powerful O/R Mapper with web based interface for entities editing plus a totally automated generation process of the web forms the will operate on to complete their tasks.

Further more CRM exposes a web service to support software interaction: basically it allows CRUD operations to be accomplished against the appllication datasource. The great thing here is that entities you design via the application web interface are immediately exposed by the web service: the WSDL contains all the entities definitions and, if you work with Visual Studio, you can, in seconds, obtain classes representing the entities in your application domain.

In some cases (take a look here) these features lead to the assumption that Microsoft CRM can be a development platform, or, at least, part of it; and Microsoft it’s self is supporting the idea. Is this a valid assumption? I think it may be. But if you are involved into the planning/design/development of an Enterprise Application, you must carefully evaluate what it can and what it cannot do. Some of its limits, in fact, make clear that it was not designed to be a development platform, and that this conviction emerged after it was released. I’m not saying that adopting Microsoft CRM as a development platform isn’t possible. May be is it in some cases. In making your choice you have to carefully match your requirements with what Microsoft offers and don’t offes.

Details like no transaction support, web service as the only channel for CRUD operations when interacting via software (only read can be run directly against the db) and the lack of a smart notifications/events system can assume, in a large application like an Enteprise one, great importance.

I will dedicate my next posts to analyze these limits and present my solutions to some of these.