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

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!

• 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.

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.

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.

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.

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

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!

Silverlight has always been a good fit for extending the Microsoft Dynamics CRM user experience.  CRM 2011 takes that a step further by providing first class support including the ability to host Silverlight content as web resources on the server.  Silverlight can be used for a little widget on a form to a full blown rich page of content.  In fact, we start out the book by talking about where it is a good fit and where it isn’t.

The Silverlight + CRM book takes the best parts of our Silverlight Jumpstart book and adds a ton of CRM specific content.  In fact I think its safe to say right now it’s the most CRM + Silverlight content found anywhere.  We cover everything from where Silverlight can be used with CRM to how to use OData and the WCF services to perform data and service actions.  You can read the full table of contents here.

If you’ve purchased one of our other books check your e-mail we sent you a really good discount.  If you haven’t bought one of our books or are just too lazy to look in your email here’s some codes to help you along as well.

You can find the book site at http://www.silverlightpluscrm.com

Finally, I know a number of you have been asking me about updates to our full CRM book CRM as a Rapid Application Development Platform. We have been crazy busy working on that as well. In fact, last night was another late night!  Part of what takes so long is not just updating content but making sure we cover new CRM 2011 features.  Got ideas for either of these books of stuff we should cover?  Send it over but only if you don’t mind if we write about it!

Next, I setup the response detail and choose a response type of Option Set.  First of all, don’t confuse choosing Option Set here with anything to do with the Contact entity that has a real OptionSet attribute on it for the contacts favorite color. There is not currently anyway that you can pull those values  and reuse them here to avoid duplication.  Trust me I’ve suggested that be changes so hopefully we will see it in the future where you can simply reuse the values!

Notice that the Data Type is set by default to Text.  This is where a lot of people fail to make the important change.  You must set this to integer if you want to have any luck ever assigning the value collected to an OptionSet field on an entity.  Another great reason to make sure you change it right away is the fact that you can’t change it after the prompt and response is saved unless you delete it and start over.  You have been warned!

In the mean time you need to setup your favorite colors using the Response Values section of the form as you can see below.

So for our example we’ve added Red, Green and Blue or RGB!  The Value field on the right is really important if you are trying to collect values that will be used to set OptionSet values on an entity if that is the case these values must match the values of the attribute OptionSet.  So for example  they may be like 100,0001 or some large number to keep them unique if that is the case you MUST use the same values here if you ever expect it to work.

Once you take care of those two things using Dialogs to collect OptionSet values is possible.  Hopefully in the future Dialogs will be enhanced so we can reuse the OptionSet values from the global definition.  

What other features would you like to see Dialogs have?