A Microsoft Dynamics CRM 4.0 build may consist of many different parts and each of these parts can potentially be their own partial build.
If we consider the variations of components within any given build, a new to xRM/CRM network administrator can quickly become overwhelmed and as such this article is to help break down these pieces into manageable tidbits. Helping
the guru CRM/xRM infrastructure specialists to expand, simplify and offer choice to their wide variety of developers and users.
Tidbit One: The ORG or Database (set). In terms of Microsoft vocabulary the term ORG or ORGANZIATION is a key term to understand. This ORG is the container that holds not only future active data, but also key configuration
settings and configuration base data that might be needed with every rollout. The ORG contains the name of the organization which is using the software, the security and business unit hierarchy and names, the answers to the configuration questions, potentially
custom entities and more. When you initially install Microsoft Dynamics CRM you install an organization. Another term for organization is “tenant” which applies when you might have multiple organizations sharing the same Microsoft Dynamics CRM code base and
infrastructure. Many of the hosting companies have multi-tenant environments. You can create additional Orgs using the Microsoft Deployment Administration toolkit, but multiple tenants off the same code base is a little less common.
Tidbit Two: The Customizations or customization.xml file. Microsoft Dynamics CRM gives a power user the option to create new entities (table sets), attributes, security roles, views, and forms. The Power user
can also rename entities, attributes and views, as well as move attributes around on any given form. These customizations can be exported and are exported to a file called customizations.xml. This file can also be imported to a different Dynamics xRM/CRM Organization.
Customizations are additive and as such when imported into any org they are layered on top of what exists. This is important to understand given that attributes will never be deleted during a customization import and as such if you need attributes deleted
you need to take a different approach. A common risk area for deleted attributes is when an attribute needs to be changed from one type to another, for instance a type of nvarchar (text) to a type of picklist. The administrator wants to keep the same schema
name and display name, but yet the attribute needs to be deleted and recreated to change the type.
Another option in the world of customizations is to export partial customizations which might be a set of related entities. The trick to exporting and importing a partial set is to insure that you have bundled all the pieces. This includes not only the modified
entities, but the entities that might have relationships to those.
Tidbit Three: Extending Microsoft Dynamics CRM with code. Plugins are .Net assemblies, which can be registered in either the CRM database, the Global Assembly Cache (GAC) of each CRM server, or the file system of each
CRM server. In general, the preferred option in production environments is to register the plugin assembly in the database as it only has to be registered once, even in a multi-server deployment, and no extra deployment is required if importing an organization
onto other environments. In development environments the choice is not so clear cut, though. One additional point is that, if a plug-in assembly references other .Net assemblies, then these referenced assemblies must be deployed in the GAC or file system.
Tidbit Four: Custom workflows are very similar to plug-ins
and yet they do not have to be deployed in the same style. They are also asynchronous. The difference is the actual API call to register.
You can create custom workflow activities in Visual C# or Visual Basic .NET code by creating an assembly that contains a class derived from one of the Windows Workflow Foundation activities. This assembly is annotated with .NET attributes
to provide the metadata that Microsoft Dynamics CRM uses at runtime to link your code to the workflow engine. After you have created an assembly that contains one or more workflow activities, you register this assembly with Microsoft Dynamics CRM. This process
is the same as the process that is used to register a plug-in. The custom workflow activity can then be incorporated into a workflow by using the Workflow Designer found in the Microsoft Dynamics CRM Web application.
Microsoft Dynamics CRM 4.0 SDK
Tidbit five: ASP.Net applications are often associated with independent software vendors and as such purchased solution bundles are bundled and installed into the ISV Folder. They do not have to be third party
applications. In fact many Dynamics xRM/CRM rollouts include custom ASP.NET web pages. If you plan to access your ASP.NET page from an IFrame within CRM there are a few more special considerations as opposed to your typical ASP.NET install. One key factor
is will your ASP.NET page be available offline? In earlier versions of Dynamics CRM this just wasn’t a choice, but of course as all things CRM, change towards more advanced choices is inevitable. Now the majority of the CRM web service endpoint can be used
when the client is offline.
Tidbit Seven: Microsoft Dynamics CRM v2011
The above information is focused and accurate for Dynamics CRM 4.0, and should be reviewed if you are working with Dynamics CRM 2011. As a rough guide tidbits one, three and four are mostly relevant to v2011, but tidbits two and
five do not accurately reflect Dynamics CRM 2011. Dynamics CRM v2011 introduces unmanaged and managed solutions as well as many more advanced tools for the developer extending Dynamics CRM and bundling these extensions into packages.
There is some cool stuff (depending upon what you are looking for in the IFD space) here: www.bing.com/search