The CRM 2011 Endpoints

With CRM 2011 there is a new webpage in your organization which gives you the information about all the endpoints available to interact with the CRM server. You simply need to navigate to Settings –> Customizations –> Developer Resources and you will see a page similar to this:



These are the different resources available from this page:

Organization Information

This section provides you with some useful information about your CRM organization:

Organization Unique Name: When you install CRM you can specify the organization unique name. However, with CRM Online, you don’t have full control on this unique name. That is why Microsoft provides you with the unique name in this page as it can be useful, for example, if you contact Microsoft Support about an incident in CRM Online, it is always good to provide your Organization Unique Name. Sometimes this name is a GUID, but fortunately Microsoft has provided the capability to select and copy the name to your clipboard from this page.

Windows Azure AppFabric Certificate: If you plan to use Windows Azure integration this section will be useful to you. You will need to obtain a public certificate and configure it in CRM. Once this is done, you will see this section on your CRM organization “Developer Resources” page and you will be able to download the certificate and see which is the issuing authority. For CRM Online, a public certificate from crm.dynamics.com is already available for you to download and is already configured. You can find out more details about the Windows Azure integration with CRM here: http://msdn.microsoft.com/en-us/library/gg309340.aspx. Note that this section will be hidden until you have successfully configured a public certificate for your CRM deployment.

Developer Center: The developer center is simply a link to documentation, tools, forums and other public sources of information that are useful for the CRM developer: http://go.microsoft.com/fwlink/?LinkID=201190

 

Service Endpoints

This section provides you with an overview of all the supported service endpoints to access data or metadata from your CRM organization and/or deployment.

Discovery Service: The Discovery Service (SOAP protocol) provides information about the organizations available in your deployment. You can query the Discovery Service to get the URL of your organizations. This service is particularly useful for multi-tenant deployments and CRM Online organizations. You can learn more about the methods available from the Discovery Service here: http://technet.microsoft.com/en-us/library/microsoft.xrm.sdk.discovery.idiscoveryservice.aspx

Organization Service: The Organization Service (SOAP Protocol) is the primary web service can be used to access data and metadata in your organization. There are a number of “Messages” (or requests) that this service accepts to manipulate the business data as well as the metadata of your organization. For a complete list of supported messages see here: http://technet.microsoft.com/en-us/library/gg309482.aspx

Organization Data Service: This Open Data (OData) Web service provides access to the business data of your organization by exposing a REST API. This link opens the Conceptual Schema Definition Language (CSDL) document that describes how to access your data by using this API. For more information, see Use the REST Endpoint with Ajax and JScript Web Resources, Use the REST Endpoint with Silverlight Web Resources, and Use the REST Endpoint with Ajax and JScript Web Resources.

Also note that for backwards compatibility, the CRM4 asmx endpoints are still supported in CRM 2011, but you should avoid using them since they are only provided for backwards compatibility.

Setting up your development environment for a CRM 2011 project

Following a series of recent articles I have posted about solutions, I wanted to share some information about how you can set up an efficient development environment for your CRM 2011 project. Managing the solution synchronization among multiple environments (dev, test, prod, et.) is not always straight forward and it depends on multiple factors such as the scope of your project and the size of your team. In general, I have found an environment topology that facilitates an efficient development team and applies to most CRM projects:

Note that in the table above, each of the “environments” are not necessarily separate servers. If you have a multi-tenant CRM server you could host one or more of these environments in the same box. the only caveat is that you need to make sure that an activity happening in one environment will not interfere with an activity in another environment. For example, all environments in which the developers need to debug on the server side should be separate box since you don’t want to block testers and Business Analysts due to the debugging session in one of the CRM organizations. Thus, as a minimum, the “Individual Development Boxes” should be separate CRM servers.

Remember this is not applicable 100% all of the time exactly as shown, but it is a good start to define your development environment strategy.

Cannot delete components of managed solutions

With the introduction of managed solutions in CRM 2011, I have noticed that it is common in the CRM community to perceive a sense of "danger" in managed solutions. While it is true that managed solutions can give you a lot of pain in some scenarios, it is also true that some of that pain can be avoided by understanding exactly what managed solutions are about, what are their limitations and dangers. I have challenged colleagues to explain to me why they prefer to not use managed solutions and I found out that in some cases it came down to a miss-use of the managed solution concept, in some other cases it was simply fear and lack of trust for new features while in other cases they pointed out a particular disadvantage of managed solutions.

The one valid problem that most people find in managed solutions (which you don't have with unmanaged solutions) is the inability to delete solution components. Once you install a managed solution, you will never be able to delete the following components:
    • Entities
    • Attributes
    • Relationship
    • OptionSets
    • Reports
   
So what should you do if you run into that situation? In my experience, most enterprises will anyway not allow the deletion of any production data and because deleting entities/attributes will delete all the related data, this scenario is usually not allowed by the business anyway. However, if you run into this scenario and you really need to delete those components from a managed solution then you have two options:

    1. Uninstall the managed solution: You can always remove the components from the originating unmanaged solution, then uninstall the managed solution and re-install the new version of the managed solution which does not contain the unwanted components. This option can be long and tedious and will certainly delete all your data related to the solution so it is usually unacceptable to do so.
    2. Hide the unwanted components: You can always hide the components so they become invisible to the end user. For example, you can remove the entities from the sitemap, remove attributes from forms and views and hide the reports. However, these components still exist and can be visible from Advanced Find. Additionally, you can revoke privileges to all users for the entities that you are hiding.
   
   
I also hope Microsoft will in the near future remove this limitation. I would be interested to find out from other community peers if they have other specific scenarios for which managed solutions are a problem and help identify potential improvements that Microsoft should look at.

Managed or unmanaged solutions in CRM 2011: Best Practices

When it comes to the solutions framework in CRM 2011 the question I get asked the most often is: “Should I use a managed or unmanaged solution?” and like all questions around best practices the answer is often “it depends”. The differences between the two are quite fundamental; however, there is still plenty of confusion in the community around this. A Microsoft colleague once gave a great analogy I would like to quote: Think of unmanaged solutions as source code and think of managed solutions as compiled, versioned and signed assemblies.

Unmanaged solutions
Similar to source code when writing a program, unmanaged solutions is your only choice during development: Every solution was once an unmanaged solution just like any binary was once source code. As long as your solution remains unmanaged, it is “open” (editable) so you can add/remove/edit components, update the publisher, the configuration and the managed properties of the solution. You will also be able to update the version of the solution and you will be able to export it. Additionally, if you are working on a multi-language solution, you can export and import the solution translation labels. Since CRM solutions now contain the translation labels in the same zip file, you should always import your labels into the unmanaged version of the solution; this way, each time you export the solution it will contain all the labels so you will not need to repeat the translation steps for every environment.
Another typical use of unmanaged solutions is to work as an integration solution to which multiple developers or teams contribute with different components. However, once your solution is ready to go into UAT or production, the solution should be installed as managed because it will no longer need to be editable, this will allow a more rigorous release control because it will force all updates to be made in a development environment and then promoted to UAT/Production as opposed to making direct changes in production environments (a fundamental best practice in IT).

Managed solutions
These are similar to .net assemblies in the sense that you do not directly edit a managed solution; it is “closed” to development. Additionally, managed solutions provide a sort of read-only signature which includes the version and the publisher of the solution. You should always make use of a consistent publisher to uniquely identify you or your company as the entity that released the solution; there are also additional privileges granted to the solution when the publisher matches the publisher of an existing managed solution in the system and it works in a similar (but more primitive) way as strong name validation in .net assemblies.
One of the advantages of leveraging managed solutions is the managed properties feature. Managed properties allow you to restrict changes in the solution by an unauthorized publisher. This is particularly useful if you have an undisciplined IT department that does not apply a thorough change management process when making changes to a solution. By making use of managed properties you can ensure that you (as the solution publisher) will remain in full control of the solution and prevent other from making breaking changes to your solution.
Another great feature of managed solutions is that it is able to create layers of customizations. In the unmanaged model, all customizations are at the same layer, so making any customization will overwrite what is currently in the system. However, managed solutions have the capability to keep track of which customizations belong to which solution. To the end user, only the top layer (latest solution installed) is visible, but under that layer there can be multiple layers of customizations so you can build a solution on top of another solution without mixing up all the changes. You can think of this capability as using reference assemblies in .net. You can develop a solution by referencing an existing managed solution. The end result is that you will have two solutions (one depends on another) but there can be a clear distinction of which customizations belong to which solution. Solution layering also means that you can revert-back to a previous system state. If you uninstall a solution, all its components will be removed but the customizations from other solutions in a lower layer will surface back.

To summarize, these are some of the reasons why I very much prefer to use managed solutions in all environments that are not development environments:

• Solutions can be installed into multiple layers.
• You can build solutions on top of other solutions (solution-level dependencies).
• Additional change management control.
• Option to turn on managed properties on solution components.
• Capability to uninstall a solution and roll-back to a previous customization state.
• Solution publisher can truly own solution components.

The only disadvantage I have found so far with managed solutions is that certain solution components, such as entities, attributes and reports cannot be deleted directly once they are managed. In order to delete such components from managed solutions you need to follow a set of steps described here. Feel free to add your personal experiences to this post!