Using Dynamic Entities

Shan McArthur

As Vice President - Technology and Senior Architect of ADXSTUDIO CMS, Shan exhibits a profound dedication and proficiency in his field. Having specialized in the IT industry for over a decade, his experience and knowledge support his instrumental role in the architecture and ongoing development of the company's web development technology.

Other Links

ISV Developer Community

Windows Azure Links

	Jim Nakashima's Blog
	Steve Marx' Blog
	David Aiken's Blog

Using Dynamic Entities

Home / Microsoft Dynamics CRM / CRM Developer's Corner / Using Dynamic Entities

August 25, 2007 8:41 AM |

Permalink

Comments (0)

| Rate this article:

CRM SDK Introduction

The CRM SDK is a web service that generates a dynamic WSDL based on your current CRM schema. For example, if you create custom entities and add custom properties to entities, the WSDL will reflect those customizations. The CRM SDK will create a custom proxy class for your custom entities so that you can use the class and its properties as direct classes in your application. The CRM SDK also has another mode of operation that is called Dynamic Entities.

All CRM service requests that return entity references will have a property called ReturnDynamicEntities that you can set to true. When this flag is set, the CRM will return the result(s) as a reference to a DynamicEntity class. This class is a generic class that can be used with all in-the-box and custom entities. All properties are exposed as a property collection.

Problem with dynamic WSDL

The dynamic WSDL is cool and convenient on the surface, but it has an ugly consequence. CRM customizations can be made at any time, and when a customization is published, any web reference that was created using the older version of the schema will be susceptible to failure - unless access to the data is done using dynamic entities. The root of the problem is that properties change when the schema changes and an old schema will attempt to set properties that are no longer valid.

From a corporate or IT governance standpoint, using the static classes instead of dynamic entities represents a significant risk to the stability of the IT infrastructure for all applications connected to the CRM. All it takes is one CRM administrator to change a single attribute on a class to break integration with the accounting system or any other application that uses the CRM. However, if all access to the CRM data is done through dynamic entities, the only systems that would break would be the ones that had a reliance on attributes that are fundamentally changed.

It's a Contract

A web service is a contract, and changes to contracts should not be taken lightly and require that all parties of the contract agree to the change. The dynamic WSDL approach of the CRM runs against this concept in that it allows a CRM administrator to change the web service contract simply by customizing the CRM entities. As such, developers should avoid using all of the entity classes directly and only use the dynamic entity class as this 'contract' is not changed by CRM customization activities.

Developer Efficiency

There are other benefits using dynamic entities, including developer efficiency. It is much easier to create a utility library with high level functionality that can work against any CRM entity if the dynamic entity class is used. It is much more efficient for developers to learn how to use the dynamic entity class instead of the myriad of other direct classes that are generated through the dynamic web reference. Code is much more reusable if it is coded to the dynamic entity class. Finally, it is much easier to not have to continuously update the web references and recompile and deploy updated applications each time the CRM schema changes.

Tags