In order to effectively customize Microsoft Dynamics CRM, you must first have good understanding of the application's architecture. The system's architecture influences how and where you can customize the system components.
The key to understanding the Microsoft Dynamics CRM architecture as it relates to customization is the Microsoft Dynamics CRM platform. One way to understand the value of the Microsoft Dynamics CRM platform is to contrast it with the client/server (two-tier) architecture that has been around for more than two decades.
Client/Server Architecture
In client/server architecture, most of the application logic is found in the client. The client processes the information and the server is typically just the database that processes transactions and stores the data. The services that the database provides may be unappreciated now that users have become accustomed to them. However, consider the difficulty that developers may face if they had to devise their own methods to store, retrieve, and manage data without the database.
The database simplifies much of the complexity that a developer has to deal with and provides him or her with the means to interact with the data through available APIs using languages such as Transact-SQL. But the client/server architecture has many shortcomings and there is only so much that a database designed for general use can provide.
Microsoft Dynamics CRM's Multi-Tier Architecture
Microsoft Dynamics CRM is a web-based application that uses a multi-tier architecture. This structure provides many benefits that support scalability, flexibility, and extensibility that cannot be matched using client/server architecture.
MICROSOFT DYNAMICS CRM CUSTOMIZATION ARCHITECTURE
In this multi-tier design, the Microsoft Dynamics CRM platform serves as an intermediary between the software developer and the database. Just as the database provides important services in the client/server architecture, the Microsoft Dynamics CRM platform provides a set of CRM specific APIs that not only handles interaction with the database, but also provides all the building blocks for the Microsoft Dynamics CRM application.
The parts of the picture marked with a cogindicate places where the Microsoft Dynamics CRM customizer can interact with the platform through code, the UI, custom reports etc. This course concentrates on the part labeled Extendable Application. The other parts will be described briefly, but detailed treatment is beyond the scope of this course.
The Microsoft Dynamics CRM platform removes the complexity that developers may otherwise have to deal with and provides a rich environment for customizing the application. Because it is designed specifically for use as a Relationship Management platform, it can provide more specific features that programmers can use when they build applications that use it.
The Business Entity Components part of the platform is responsible for creating domain-specific objects. Examples of domain-specific objects in Microsoft Dynamics CRM include Contact, Lead, Opportunity, Account, and Business Unit. These objects are created in response to instructions from the Application platform, ultimately from the Microsoft Dynamics standard UI or from customization code.
The goal of the Microsoft Dynamics CRM platform is to implement the service rules by manipulating and combining the underlying domain-specific objects. The platform accomplishes this by:
· Controlling access to objects through security
· Controlling access to the database through the data access layer
· Raising events for workflow processes and custom business logic implementations
Except for reports, every application that interacts with Microsoft Dynamics CRM does so through Web services in the Microsoft Dynamics CRM platform. This includes the Workflow tools and solutions created by ISVs. In summary, think of the platform layer as providing the entire infrastructure that is required to implement a complete Microsoft Dynamics CRM (or Extended CRM) application.
Domain and Business Logic
The platform by itself does not impose business-specific logic. This layer imposes only generic domain constraints. It contains the components for an application, but by itself is nothing more than a collection of related objects. However, the interaction between these domain specific objects implements more extensible business logic for the organization. You can apply business logic at the platform through workflow processes and plug-ins; or through the UI using Dialogs or event scripts on Forms.
· Microsoft Dynamics CRM Workflow enables you to create automated business processes at the platform layer. Workflow processes perform actions based on rules set up by the business. Workflow processes are triggered by events within Microsoft Dynamics CRM when specific actions are performed and specified conditions are met. The Workflows apply the business logic using built in steps or by allowing developers to add their own custom code to carry out a step.
· Plug-ins refer to the ability to create business logic extensions using pre- and post-plug-ins available in the platform. Plug-ins are extension points made available by the Microsoft Dynamics CRM platform. There is a published set of events that a Plug-In can subscribe to. As part of the subscription, a developer must specify an event handler, which is a segment of customized code that runs in response to the system event. There are certain parts of the Microsoft Dynamics CRM application that include business logic that is not found in the platform and cannot be customized.
An example of this is the logic that converts a Lead into a Contact, Account, and Opportunity. This behavior occurs because the application interacts with the platform to create these new objects based on programmatic information stored in the Lead object. The platform creates the Lead, but the built-in business logic performed by the application converts the Lead to a Contact, Account, and Opportunity.
Database Access
The Microsoft Dynamics CRM platform has a Data Access layer to handle all interactions between the application and Microsoft SQL Server, which contains the Microsoft Dynamics CRM database.
Developers must not directly access or update the CRM database for the following reasons:
· It introduces the opportunity for invalid or corrupt data to be added to the database, which in turn can cause the Microsoft Dynamics CRM platform to function incorrectly.
The Microsoft Dynamics CRM database structure might change without notice in a future release.
