Pages

Tuesday, September 13, 2011

CRM 2011 and WSDL

CRM 2011 makes a dramatic change with the WSDL implementation compared to CRM 4.0.  The biggest difference?  The WSDL file you download is not a full definition of the service (for either Discovery or Organization). 

Instead it’s a very small and self-conscious (“lightweight”) WSDL that points back to the same service (and host) with an import directive for the full WSDL.  What does this accomplish?  Well, WSDL-imports are supposed to allow a WSDL definition to be modular with reusable and multi-authored definitions.  We really don’t see that being applied in CRM’s case in any sensible fashion (like importing out-of-the-box entity/attribute definitions separately from custom ones, or importing WSDLs with Solution-based scopes).  All it seems to do is complicate the retrieval of information we need for our application.

So, if you prefer or require the late-bound Entity class, and you don’t have local access to a CRM system.  Having a “full” WSDL file could help when you want to avoid…

  1. …deployment of the CRM DLLs.  This may be important when single-assembly functionality is imperative and assembly dependency deployment is a serious headache, such as CLR operations from SQL for integration projects.  Or maybe the target system doesn’t use or support .Net.
  2. …the code-generation tool.  Let’s face it, the code-generation tool is nice for simple and quick developments, there’s no argument about the excellence of many of its Utility methods.  However, it produces a lot more code than many will ever use—artificially inflating the assembly size unnecessarily.  And the code it produces isn’t without its own bugs.  Sometimes keeping things simple is its own reward.

So, when you need to have the “full” WSDL file, for your services, use links formatted like so:

Discovery Service

http[s]://<crmServer>/<crmOrg>/XRMServices/2011/Discovery.svc?wsdl=wsdl0

Organization Service

http[s]://<crmServer>/<crmOrg>/XRMServices/2011/Organization.svc?wsdl=wsdl0