Extending Dynamics CRM via Acquisition

Couple days ago Microsoft announced they acquired MarketingPilot – while I don’t know a lot specifically about MarketingPilot as a product, from a strategic point of view this is a big deal.  I don’t think it’s a big deal just because of the company acquired but because it signals to me a desire to fill product gaps by acquiring.  In the past, this was done via complicated alliances / IP licensing that just made it confusing to everyone should they use the built-in or the partner directly.  Acquisition is clean, product is absorbed into the core product and no confusion exists.  It’s also a fast way to fill gaps and add innovation in a proven way.

You can read the announcement by Bob Stutz the new corporate vice president for Dynamics CRM here

Choosing Smart Defaults for New Entities

When creating a new entity some of the choices you make will stick with you for the life of the entity.  Prior to CRM 2011 the general advice used to be turn on things if you think you might ever need them.  For example, Notes and Activities – in the past if you didn’t enable them there was not a supported way to enable them.

CRM 2011 changes this, most of the options like these in the Communication and Collaboration section can be enabled later.  The defaults though that come up have them enabled as you can see below:

The + sign next to an item indicates that once enabled it cannot be disabled later.  So what I recommend is unchecking all of them and only enabling it WHEN you need it.  Ideally in the future maybe the new entity form will get updated to not have those defaulted but until then take a few seconds and be smart about what you need!

CRM Client Extension Data Access Strategies

The following are the three primary options for accessing CRM data/services from a client side extension that is implemented as a web resource:

• REST endpoint that implements the OData protocol
• SOAP endpoint for web resources
• Commanding Pattern using either of the prior options

Each of these approaches can be used regardless of HTML (with scripting) or Silverlight client extensions. Keep in mind for standalone client applications there are other considerations not covered.

Synchronous vs. Asynchronous

Requests from the client extension to the CRM server requests can be made synchronous or asynchronously. The best practice is to use asynchronous requests to ensure the best user experience. Synchronous requests by nature can block the UI. Developers like Synchronous requests because it simplifies the programming model. Similar simplification of Async requests using C# async /await support or a similar library for scripting often times minimizes the programming challenges.

REST Endpoint using OData

The REST endpoint implements the OData protocol (http://www.odata.org) to allow flexible access to CRM data. This supports basic data access (Create, Retrieve, Update,Delete) but does not allow execution of CRM service requests like Start Workflow, or any Meta Data access.

Use When

• Low volume data access
• Client side control of transaction is not required. By client side control of transactions this means where you need deterministic control if all changes are made or rolled back.

Avoid Use When

• Interactions that require large number (typically > 10-25 at a time) requests to server
• Interactions that require all to work or all to fail – you need a client controlled transaction
• You need aggregate values – the SOAP endpoint is preferred then because you can run a Fetch Query
• You need formatted values that are returned from the SOAP service or Option Set labels – or at least understand you need to handle this yourself.

It’s worth noting that while OData provides a flexible query pattern but can be slightly bloated in the size of data it returns. This can be mitigated using $select or by qualifying the data being returned.

SOAP Endpoint

The SOAP endpoint extends to the client the CRM Organization service giving access to both data and service operations. This includes the ability to query and modify CRM metadata.

Use When

• You need access to CRM Services or Metadata
• For basic data access OData is not working
• When you want control of setting Related entities which can simulate a client side transaction. For example you could insert an Account and related Activities in one server interaction. This is only available for related entities to the primary entity being created/updated.

Note: SDK documents Deep Insert for the REST endpoint that can accomplish similar actions but it is not documented if this is within the scope of a transaction

• Low volume data and service access
• Client side control of transaction is not required beyond related entities

Avoid Use When

• Interactions that require large number (typically > 10-25 at a time) requests to server, this is similar to the REST endpoint
• Interactions that require all to work or all to fail – you need a client controlled transaction
• For basic data access unless OData is not meeting needs

Commanding Pattern

The commanding pattern allows a client side requests to be communicated to the server and processed by a plug-in. The plug-in can run in a transaction and can perform one or more CRM service operations all of which would be included in the transaction. This pattern is best used when client extensions need to perform many server interactions or need support for client controlled transactions. This pattern also moves the chatty requests from client side with high latency to server side with low latency improving the total time to perform multiple operations. Additionally, if you have existing server code performing business logic, this pattern allows easy reuse.

The mechanics of this approach is a custom entity is created. Let’s call it “ServerCommand”. It contains at a minimum a RequestData attribute and a ResponseData attribute. The client extension using either OData or SOAP creates a ServerCommand entity instance populating the RequestData attribute. Server side a plug-in is created and registered against the Pre-Operation Create on ServerCommand. The plug-in looks at the RequestData does whatever work it needs to do and places the results in ResponseData. That work could be one or more service calls or data operations. Because this is done in the Pre-Operation stage of the event pipeline the response is written to the database during the create operation requiring no extra updates. Back client side, using the ID returned from Create the client extension would perform a read operation to get the ResponseData that was created by the plug-in. Server side you do need to bulk delete the completed ServerCommand records at some point.

Use When

• You need client controlled transactions
• You need to perform several operations
• You need to server side logic
• You want to shift processing to the server

Avoid Use When

• You don’t need client controlled transactions
• You are only making a few calls

Mix and Match

While it would be nice to suggest one single approach for working with CRM data / services, however as client extensions become more complex a single approach is likely not optimal. By using a mixed approach you can take the best of each of the patterns above as needed to provide the best user experience and meet the demands of the client extension.

Using a manager style class or other client side code pattern that hides the details of the implementation for each interaction with the CRM server client side developers can isolate the code and choices and giving flexibility for future changes. This technique is also helpful in larger client extension developed by multiple developers or where many client side extensions need the same interactions with the CRM server.

Wow, you made it to the end   If you made it this far and have opinions drop me an e-mail.

Using Early Types across assemblies in plugins

It’s not uncommon for us to have are generated types in one assembly and have a plugin that uses the code that in another assembly.  When doing that CRM doesn’t do well with resolving the classes. 

To work around this you can give CRM a hint by setting the ProxyTypeAssembly.  To do this you must first get a reference to the IProxyTypeAssemblyProvider – we typically do this by casting the IOrganizationServiceFactory instance we get to that type and go from there.  Here’s an example of a helper method to get the Organization Service and setup the ProxyTypeAssembly prior to creation of the service instance.

public IOrganizationService CreateService(Guid? userID) 
{

            var factory = ServiceProvider.GetService(typeof(IOrganizationServiceFactory))
                        as IOrganizationServiceFactory;            
            var proxyProvider = factory as IProxyTypesAssemblyProvider;          
            proxyProvider.ProxyTypesAssembly = ProxyTypeAssembly;     

           return  factory.CreateOrganizationService(userID);            
}

ProxyTypeAssembly in this example would need to be the assembly that contains your generated classes.  Clearly I’ve stripped out any error handling and other good stuff from this method but you get the general idea.

Working with Field Level Security from a Plugin

Question: I was wondering if a plugin could update a field that is protected by Field Level Security (FLS), or if that is blocked in the platform

Answer: It Depends

If the plugin is running pre-operation stage and is modifying the entity image that is input parameters before the platform operation occurs then it doesn’t matter if the user that caused the operation to occur has permission to update the secured field the plugin will still be able to modify the value. It also doesn’t matter the context in which the plugin was registered to run in the plugin registration tool. The following is simple example of modifying new_secretcode that is enabled for field level security. This code was run from a plugin registered on create of account in the pre-operation stage.

var context = serviceProvider.GetService(typeof(IPluginExecutionContext)) as IPluginExecutionContext;

var target = context.InputParameters["Target"] as Entity;

target["new_secretcode"] = "1234";

To dive a little bit deeper let’s explore what happens when a plugin runs in post operation stage and attempts to create a record and populate the value of a secured field. For this example, I’ve modified the plugin to create a new account anytime a contact is created. As part of that it gets an organization service that runs in the context of the user that caused the platform operation to run. When run by the administration user the plugin fires and creates the account without any problem. When the contact was created by a user that did not have access to update secret code you would see the following error:

Here’s the revised code that is running when a contact is created and attempts to create the account and update the secured field:

var context = serviceProvider.GetService(typeof(IPluginExecutionContext)) as IPluginExecutionContext;

var target = new Entity("account");

target["name"] = "test 3";

target["new_secretcode"] = "1234";

var sf = serviceProvider.GetService(typeof(IOrganizationServiceFactory)) as IOrganizationServiceFactory;

var service = sf.CreateOrganizationService(Guid.Empty);

service.Create(target);

The key line to pay attention to above is the CreateOrganizationService call that we pass Guid.Empty. Passing Guid.Empty instructs the method to give back an organization service configured to run in the context of the user. If instead we passed null to that method the organization service would be configured to run in the system context and the plugin would be able to update the secured field.

Export–Missing Required Components

This has been happening for a while now, but I seem to see it come up more often.  The scenario is you just created a solution, added existing entity Contact to it.  You’ve added a single custom attribute  and added the attribute to the form.  You then go to export the solution to move it to another organization and you see the following dialog…

This is a valid dialog to see at this point, but not for why it is showing itself now.  The real purpose of this dialog is to inform you of a missing component, a dependency that is not included in your solution and if not already in the target organization will block the import of this solution.  As best I can tell what you are seeing above for this specific scenario is a bug…it shouldn’t be showing. 

The risk here is you get so accustomed to seeing it for system entities that aren’t an issue you might miss the real deal.  So stay focused look past the system entities and make sure you agree with what is on the list.  Which should be true components that you are dependent on.  By the way, one easy way to keep this list short is to build your solution as you go.  As you use existing components ,add existing of them to your solution.  If you create new components, create them from within the custom solution.  It makes for less work when you go to publish your solution in the future.

Security update for ASP.NET and CRM

Today Microsoft released a security update for a vulnerability with ASP.NET.  If you are using CRM via CRM Online this has already been patched for you.  If you are running CRM on-premise you need to take action.

The security advisory can be found here.  The urgency around this is related to details being released at a security conference yesterday.

Turn on Communication and Collaboration as needed in CRM 2011

In prior versions of CRM you had to decide at the time you created an entity if you wanted things like Notes, Activities etc. enabled.  Now in CRM 2011 you can defer that decision and make it anytime in the future.  When you had to make a final decision at time of entity creation it used to be always a good idea to turn them on if you “Think” you might ever need them.  Now, I would say the opposite, don’t turn them on till you need them.

Keep in mind that the + after the item indicates that once you turn it on it can’t be turned off.

Sometimes the toughest part of learning a new version is forgetting old version habits!