The document describes the architecture of Microsoft Dynamics CRM. It identifies four main extensibility points: web service programming, custom workflow activities, plug-ins, and client programming. It also describes the two Outlook clients and how the offline client works. Finally, it explains that Microsoft Dynamics CRM uses a metadata-driven architecture with platform and application layers to store entity definitions and customizations separately from code.

1. Chapter 2: Microsoft Dynamics CRM Architecture
CHAPTER 2: MICROSOFT DYNAMICS CRM
ARCHITECTURE
Objectives
The objectives are:
• Identify the extensibility points within the Microsoft Dynamics CRM
Architecture .
• Locate Microsoft Dynamics CRM Outlook clients within the
Microsoft Dynamics CRM Architecture.
• Enumerate the layers of the Microsoft Dynamics CRM application
and their responsibilities.
• Identify specific responsibilities of the Application Layer .
• Identify specific responsibilities of the Platform Layer .
• Identify deployment considerations that may impact the extensibility
of Microsoft Dynamics CRM.
Introduction
Microsoft Dynamics® CRM is built on technologies designed to work now and
into the future, protecting business value and providing an integrated
environment that can be extended across systems and platforms. The .NET
architecture of Microsoft Dynamics CRM combines with Microsoft® Windows
Server™ and Microsoft® Active Directory®, Microsoft® SQL Server®, Microsoft®
Exchange Server, and Microsoft® BizTalk® Server families to help ensure:
• High performance.
• Tight security.
• Rich messaging functionality.
• Efficient, affordable customizations and integrations.
Because it is built on .NET technologies, users can access Microsoft Dynamics
CRM through a Web application that is running in Microsoft® Internet Explorer
and through a Microsoft® Outlook® client. Microsoft Dynamics CRM offers
tightly integrated sales, customer service, and marketing functionality.
There are many details of the Microsoft Dynamics CRM architecture and design
that may be interesting to software architects from a design perspective. But this
course focuses on how the architecture affects practical decisions that developers
make when planning and creating solutions that solve business problems with
Microsoft Dynamics CRM.
2-1

2. Extending Microsoft Dynamics® CRM 4.0
Extensibility Points
FIGURE 2.1 FIGURE 2-1: MICROSOFT DYNAMICS CRM 4.0 EXTENSIBILITY
ARCHITECTURE
Outside the customization tools that are included in Microsoft Dynamics CRM,
four extensibility points are identified for this course. These are the focus of this
topic. These extensibility points are as follows:
• Web Service Programming
• Custom Workflow Activities
• Plug-ins
• Client Programming
Web Service Programming
The Microsoft Dynamics CRM Web application and any other client applications
provided with Microsoft Dynamics CRM, such as Deployment Manager, use
APIs available through Microsoft Dynamics CRM Web services to perform
actions in Microsoft Dynamics CRM.
When writing code to perform actions in Microsoft Dynamics CRM, use APIs
documented in the Microsoft Dynamics CRM SDK. These Web services provide
strongly typed access to all entities in Microsoft Dynamics CRM, including
custom entities and attributes.
2-2

3. Chapter 2: Microsoft Dynamics CRM Architecture
Custom Workflow Activities
The Microsoft Dynamics CRM Asynchronous Service runs on the Microsoft
Dynamics CRM Server. This service responds to events, schedules events, and
runs processes. Workflow rules can include actions which invoke class methods
that are contained in .NET assemblies.
Plug-ins
Use Plug-ins to register .NET assemblies to subscribe to a published set of events
and to have the code run when the event occurs. Plug-ins are the way that custom
business logic, including data integration with other systems, can be achieved.
Client Programming
All client programming code is stored as metadata in the Microsoft Dynamics
CRM database. This enables the client programming to be transported easily
from one deployment to another and also for the code to function in the Outlook
client.
Microsoft Dynamics CRM does not support modification of the files included in
the application. All client code must be added in the locations specified in the
Software Development Kit (SDK). Customizations must be made using the tools
provided in the Web application, by importing customizations in an XML file or,
in some circumstances, by editing customization files.
When forms are rendered in either the Web or Outlook clients, the code is
included and is executed on the client computer when the designated events
occur.
Microsoft Office Outlook Clients
There are two Outlook clients for Microsoft Dynamics CRM:
• The Microsoft Dynamics CRM for Microsoft Office Outlook
• The Microsoft Dynamics CRM for Microsoft Office Outlook with
Offline Access
Microsoft Dynamics CRM for Microsoft Office Outlook
This client can only be used when connected to the Microsoft Dynamics CRM
Server through the network. It allows for multiple users to access Microsoft
Dynamics CRM through Outlook on the same computer. A simple way to
understand it is that it provides access to the Microsoft Dynamics CRM Web
application through Outlook.
2-3

4. Extending Microsoft Dynamics® CRM 4.0
Microsoft Dynamics CRM for Microsoft Office Outlook
with Offline Access
This client supports offline use. The user interacts with Microsoft Dynamics
CRM data in Outlook just like the Microsoft Dynamics CRM for Microsoft
Office Outlook client. To support offline use, the Microsoft Dynamics CRM for
Microsoft Office Outlook with Offline Access client uses a local version of the
Microsoft Dynamics CRM Web application hosted on a local Web server. This
local Web server can only be used for the local instance of the Outlook client to
access Microsoft Dynamics CRM. A SQL Server 2005 Express database
provides data storage.
When the offline client is synchronized, any customizations applied on the
Microsoft Dynamics CRM server are transferred to the local Microsoft Dynamics
CRM application.
The Client programming model includes methods to determine which client is
being used and whether the user is online or offline. Developers can use these
criteria to disable functionality that requires a connection to the network.
Workflow rules are not included in the offline client, but plug-ins can be
deployed to the offline client. Workflow rules and Plug-ins are applied when the
user synchronizes data.
In Microsoft Dynamics CRM Web Service Programming can be performed on
the local version of the Microsoft Dynamics CRM application in the Microsoft
Dynamics CRM for Microsoft Office Outlook with Offline Access client. This
behavior is an improvement upon previous versions of Microsoft Dynamics
CRM, which did not provide a supported way to access CRM programmatically
in the offline client.
Layers
Microsoft Dynamics CRM uses a metadata driven architecture to provide the
flexibility to create custom entities and additional system entity attributes and
also to make upgrades and enable transportation of customizations easier. This
allows for changes in the data structure without requiring any change to code in
the Microsoft Dynamics CRM Platform or applications.
Metadata-driven Architecture
Platform Metadata
All the information necessary for Microsoft Dynamics CRM Server to operate is
stored in the Microsoft Dynamics CRM metadata. This includes information
about:
• Entities
• Attributes
2-4

5. Chapter 2: Microsoft Dynamics CRM Architecture
• Mappings
• Relationships
Application Metadata
The Microsoft Dynamics CRM Web application also uses metadata to store:
• Form Customizations
• Client-side code
• SiteMap configurations
• Custom buttons, menu and navigation items
In a multi-tenant implementation of Microsoft Dynamics CRM, multiple
organizations can be created. Each organization's metadata is maintained
independently from all other organizations.
Divisions of Layers
The design of Microsoft Dynamics CRM 4.0 can be discussed at many different
levels of depth. There are different physical and logical components that may be
organized several different ways. The most appropriate division of these layers
depends on the depth of the analysis and type of task being performed.
The most common division is into the following horizontal layers:
• Application
• Platform
• Database
This division can be implemented physically within Microsoft Dynamics CRM,
with different servers being configured for different roles, which map to the
logical layers as follows:
• The Application layer is implemented in the Application Server role.
• The Platform layer is implemented in the Platform Server role.
• The Database layer is implemented on the Microsoft SQL Server.
Application Layer
As a Web application Microsoft Dynamics CRM runs within Internet
Information Server (IIS). Transactions are initiated when users submit forms by
clicking the different types of ‘save’ buttons on forms found in the application.
The Microsoft Dynamics CRM Application includes logic that controls security
and data validation. When the Microsoft Dynamics CRM pages are presented
within Internet Explorer, custom logic that can be attached to events and data
validation logic is included on the client.
2-5

6. Extending Microsoft Dynamics® CRM 4.0
This lesson includes the following topics:
• Application Level Security discusses how security is applied
related to:
o Forms and Navigation
o No Field Level Security
• Data Validation discusses how the Application layer enforces:
o Data Integrity
o Data Validity
• Business Logic discusses the kinds of business logic that is applied
in the application layer.
• Metadata driven UI discusses how metadata is used in the
application layer.
Forms and Navigation
When they use Microsoft Dynamics CRM, users should never receive a message
saying they do not have permissions to perform an action. This is because the
individual user's security metadata is used by Microsoft Dynamics CRM to select
which parts of the application are displayed and how the user can interact with
the application.
The individual user's security metadata refers to the security roles that are
assigned to the user. This controls the data the user can view and the actions he
or she can perform specific to areas of the application:
• Navigation: If the user does not have access to read Opportunities in
Microsoft Dynamics CRM - that user does not see Opportunities in
the application navigation. If the user does not have privileges to
perform Customization, the Customization area is not displayed.
• Forms: The Microsoft Dynamics CRM supports read-only and also
writable forms for entities. For example, if a user can view
Opportunities but cannot update them, the application displays
opportunities in a special ‘read-only’ form where all the input fields
are disabled. Users who cannot view a particular record do not see
the record returned in any view or report - they are never aware that
it exists.
No Field Level Security
Microsoft Dynamics CRM Security is set at the entity level. In Microsoft
Dynamics CRM there is no mechanism provided to implement field level
security based on security roles. If there is sensitive data that needs to be stored
in Microsoft Dynamics CRM that is related to a particular entity, it is recommend
to create a separate custom entity and to configure security separately for that
entity.
2-6

7. Chapter 2: Microsoft Dynamics CRM Architecture
NOTE: Use DHTML in the OnLoad event to hide fields, tabs or sections in a
form that is based on user security roles. But this method is not supported and
will not completely hide the data from users. Users can still access data in fields
using the Print, Advanced Find, or Export to Microsoft® Excel capabilities.
Data Validation
The Microsoft Dynamics CRM application provides data validation for
information entered in forms. Data validation is performed by using DHTML on
the client to improve performance. This represents a best practice that can be
applied to create Web applications that use the Microsoft Dynamics CRM
platform.
This data validation represents two types:
• Data Integrity
• Data Validity
Data Integrity
Data Integrity
Some entities require a relationship to exist. For example, Opportunities must be
related to either a Contact or an Account. The application uses mapping to make
this easier when a new record is created or by preventing a record from being
saved when required fields are not provided.
The Microsoft Dynamics CRM platform is ultimately responsible for data
integrity. The application supports the requirements of the platform in the
following ways:
• Mapping: The mapping capabilities that make the entry of relational
data easier can also be customized to include additional fields, which
should be copied to new records created in Microsoft Dynamics
CRM. This customization is performed by using the customization
tools in the Web application.
• Constraints: Constraints can be set on individual fields to make
them required. This prevents users from saving a record unless data
is included in the field.
2-7

8. Extending Microsoft Dynamics® CRM 4.0
Data Validity
Data Validity
Only valid data can be entered through the Microsoft Dynamics CRM
application. This is controlled by using various DHTML methods to test the data
that is entered in each field. Whenever the data in a field is changed, the validity
of the data is checked. The data must represent a valid data type expected by the
Microsoft Dynamics CRM platform. Invalid values are rejected. Most
customizable fields can be configured by modifying attribute properties to set
specific validity settings that may vary within implementations.
The Microsoft Dynamics CRM platform is ultimately responsible for data
validity. The application supports the requirements of the platform so that users
will not experience errors originating from the Microsoft Dynamics CRM
Platform.
Business Logic
The term ‘business logic’ refers to the intrinsic processes that are built into
Microsoft Dynamics CRM. For example:
• Accounts can be active or inactive.
• Service cases follow a resolution process when they are completed.
• Opportunities must be assigned to a user and related to either a
Contact or Account record.
Business Logic in the Application Layer
Business Logic in the Application Layer
The Microsoft Dynamics CRM platform includes most of the business logic to
implement the application. The application layer must reflect the business logic
that is defined in the platform.
However, the Microsoft Dynamics CRM application includes some business
logic that is not defined in the platform. One example of this business logic
illustrates how custom applications can use a similar approach to add
functionality on the Microsoft Dynamics CRM platform.
Convert Lead
A good example is the ability to convert leads into Accounts, Contacts and
Opportunities. The Microsoft Dynamics CRM platform does not include a
method called “Convert Lead,” but this functionality is included in the Microsoft
Dynamics CRM application. The user is provided with a button to convert a lead.
When this is done the user can make choices about exactly which new objects to
create.
2-8

9. Chapter 2: Microsoft Dynamics CRM Architecture
The Microsoft Dynamics CRM application then calls the Create method on each
of the new objects.
API Building Blocks
API building blocks
When working with the methods documented in the Microsoft Dynamics CRM
SDK Server Programming guide specific messages can be located to execute
business actions on objects. To convert an Order to an Invoice, or to close a
service case, for example.
If a specific message cannot be located to perform a business task, the logic
needed in the application can be included by combining different messages. If
desired, this can be done in Plug-ins, Custom Workflow Activities or in a stand-
alone application that may be integrated into Microsoft Dynamics CRM.
This is very important when working with custom entities because only messages
for basic and security operations are generated by Microsoft Dynamics CRM. It
may be desirable to create methods in an application for specialized business
logic operations for custom entities.
Metadata-driven User Interface
A very important achievement in the Microsoft Dynamics CRM application, is
the framework to deliver a fully metadata driven user interface. Metadata from
security roles are used to control which parts of the application are shown to
individual users, but this is just one way that metadata is used. Another key
feature enabled by using a metadata driven design, is the customization
framework. Some of the UI areas controlled by metadata include the following:
• The form layout.
• The presentation of attributes in the forms.
• The code that is associated with form and field events.
• How navigation options are presented.
• How custom buttons, menu items and navigation areas are presented.
• The type of form that is presented to the user.
Microsoft Dynamics CRM supports multiple languages within the user-interface,
such that a user may see labels and other text in a different language from
another user. These languages and the associated labels are also stored within the
metadata. The language edition of Microsoft Dynamics CRM Server that is
installed by the organization is considered its base language. The organization
can then install Multilingual User Interface (MUI) language packs for additional
languages if they are requested by any of the users.
2-9

10. Extending Microsoft Dynamics® CRM 4.0
When one or more MUI language packs are installed, each user can select which
language he or she wishes to use when accessing the application and online Help
files. This enables each user to personalize his or her Microsoft Dynamics CRM
experience. For example, one user in the organization may view the Microsoft
Dynamics CRM in Spanish, and another may view it in French.
Each MUI language pack contains all of the translated UI labels based on the
package's respective language. These translated labels are stored within the
metadata.
How it Works
How it works
If opening one of the .aspx pages that present a form in Microsoft Dynamics
CRM the type of page that most ASP.NET developers expect is not found. Much
of the page is rendered using custom controls.
NOTE: These controls were not created for reuse. There is no documentation for
re-using them or creating controls that inherit from them. These controls may
change without notice in future versions and any attempt to include them in
development projects is unwise and unsupported.
These controls are designed to receive data in XML from the Microsoft
Dynamics CRM platform and transform the data using XSLT in combination
with any metadata that applies to the control. The form used to display CRM data
is generated by controls such as these.
Platform Layer
The Platform Layer includes the following component functionality:
• Web Services describes how Web services are the only mechanism
to programmatically perform actions in Microsoft Dynamics CRM
beyond a simple retrieval of data.
• Entity Definitions describes how the platform stores definitions of
all the entities, attributes and relationships defined for that
implementation. This lesson also includes a demonstration of the
Metadata browser.
• Platform Security describes how the platform is ultimately
responsible for enforcing security in Microsoft Dynamics CRM.
• Platform Business Logic describes how Microsoft Dynamics CRM
Business logic is applied in the platform and how it can be extended.
• Data Access Components introduces how the platform interacts
with the Database layer and some of the methods available for
developers to retrieve data through the platform.
2-10

11. Chapter 2: Microsoft Dynamics CRM Architecture
Web Services
Web services provide the main way that applications can interact with the
Microsoft Dynamics CRM platform. These Web services not only allow business
transaction to be applied, they provide metadata that describes each
implementation of Microsoft Dynamics CRM. Through these Web services, the
platform provides all the information a developer must have to interact with a
Microsoft Dynamics CRM implementation.
Web services enable the development of distributed applications, with an
emphasis on interoperability. This design is typically described as a Service
Oriented Architecture (SOA). The decision to use SOA for the Microsoft
Dynamics CRM platform reflects the growing popularity of Web services and the
degree that Microsoft is committed to them.
Interoperability
Interoperability
This course does not provide an explanation of Web services, or the underlying
technologies such as SOAP, or XML that are used by them because the design of
the Microsoft Dynamics CRM 4.0 SDK has greatly simplified working with Web
services in Microsoft Dynamics CRM, using Visual Studio .NET. Although this
course only shows the most common ways that developers can extend Microsoft
Dynamics CRM using Microsoft technologies, understand that Web services
represent an open standard that allows interoperability from many technologies.
Earlier Versions
Earlier Versions
For the most part, Microsoft Dynamics CRM 4.0 is backward compatible with
Microsoft Dynamics CRM 3.0 . Existing application code can be easily extended
to use the new or improved Microsoft Dynamics CRM Web services, requiring
only a recompile and redeployment.
Alternatively, the Microsoft Dynamics CRM 3.0 Web service endpoints are
retained, which allows most existing code written for the Microsoft Dynamics
CRM 3.0 Web services to work with Microsoft Dynamics CRM 4.0.
Details can be found in the Microsoft Dynamics CRM SDK under Upgrading
from Microsoft Dynamics CRM 3.0
NOTE: Microsoft Dynamics CRM 3.0 customization xml files are not compatible
with Microsoft Dynamics CRM 4.0.
2-11

12. Extending Microsoft Dynamics® CRM 4.0
New SDK
New SDK
In Microsoft Dynamics CRM 4.0 the term SDK frequently refers to both the
documentation and the features that enable developers to work with Microsoft
Dynamics CRM.
The Microsoft Dynamics CRM 4.0 SDK is focused on messages and constructing
requests that meet the developer's needs. The Microsoft Dynamics CRM 4.0
SDK provides significant advantages for the developer. These include the
following:
• IntelliSense support in Visual Studio
• Dynamically generated WSDL
• Strong typing
• Design/Compile time errors
• Versioned schema and Web services
Microsoft Dynamics CRM provides three Web services:
• CrmService
• MetadataService
• CrmDiscoveryService
There is an additional Deployment SDK, which includes the Deployment Web
service.
CrmService: The main Web service for the Microsoft Dynamics CRM SDK is
CrmService.
This Web service contains the methods needed to write code against all the
entities in the system, either for data retrieval or modification. There are six
common methods, and there is another method, the Execute method, used
specifically to execute business logic.
MetadataService: This Web service allows access to information about the
entity, attribute, and relationship definitions in a Microsoft Dynamics CRM
organization. It can be used to retrieve metadata, but can also be used to modify
the metadata.
CrmDiscoveryService: Unlike the other two Web services which work at the
organization level, the CrmDiscoveryService is a global installation-level service.
This service provides information about all Microsoft Dynamic CRM
organizations within an installation.
2-12

13. Chapter 2: Microsoft Dynamics CRM Architecture
Microsoft Dynamics CRM 4.0 provides three different endpoints for the
CrmDiscoveryService; one for each authentication method, namely Active
Directory, Passport (used in Windows Live) and Web Form (used for Internet-
Facing Deployments).
Entity Definitions
The Platform layer needs to know about entity definitions and be able to manage
changes to the entity, while maintaining entity integrity. This is handled in the
following ways:
Entity Metadata: Because of the built-in capability of the Microsoft Dynamics
CRM schema to be extended, the platform must maintain a complete definition
of every entity, entity attribute, and relationship defined in an implementation.
Dynamic Schema: The ability of the platform to know about changes that are
applied to it enables the platform to protect itself from changes to the underlying
data structures. All entities, attributes, and relationships are stored as metadata.
That is why it is unsupported to access the SQL databases directly, except for
filtered views. To keep the logical entity definitions synchronized with the
physical database definitions, the platform must apply all changes to the
database.
Entity Definition
Entity Definition
The entity definition used by Microsoft Dynamics CRM includes how a given
attribute can be used. For example, some attributes like primary keys are ‘write
once’ (Valid for Create). After they are set, they should never be updated. Others
are ‘read-only’ (not Valid for Update), such as createdby or createdon. These
attributes are set by the platform and should not be modified.
Business Defined Rules: Other attributes should comply with business-defined
rules, such as constraints set on the attribute to make it ‘Business Required.’
Other Data: Data that is used by the system such as Entity Type codes, validity
options, and relationships are stored and used by the platform.
BusinessEntity
Business Entity
All Microsoft Dynamics CRM entities inherit from an abstract base class named
BusinessEntity. Objects of this type are used to perform general operations
common to all entities.
2-13

14. Extending Microsoft Dynamics® CRM 4.0
Metadata Browser
Metadata Browser
The Microsoft Dynamics CRM Metadata browser provides a manual way to
browse some of the metadata in Microsoft Dynamics CRM. The metadata
browser is available at http://server/organization/sdk/list.aspx
Platform Security
As described in Application Level Security , the Application layer provides one
level of security by preventing the user from viewing data or performing actions
based on security metadata. The platform also provides an additional security
check. Because the platform is designed for developers to build on, it does not
assume that the developer has already performed a pre-emptive security check.
Therefore, it performs another security check before servicing requests from any
application.
A good understanding of the Microsoft Dynamics CRM Security Model is
important, before developing extensions for Microsoft Dynamics CRM. The
Microsoft Dynamics CRM Security model is documented in Appendix A of the
Microsoft Dynamics CRM SDK.
This course does not provide a detailed explanation of the security model, but it
is recommended to become familiar with it, in particular, to understand:
• Role-based Security
• Object-based Security
• Security Principals
• Licenses
• Security Dependencies
Role-based Security
Role-based Security
Users are assigned roles which define the privileges available to them. The
platform checks for a user's privilege and rejects the operation if the user does not
have the necessary privilege. Table 2-1 lists the privileges available for most
entity types.
Privilege Description
Create Create an entity instance.
Read View entities.
Write Change entities instances.
Delete Remove an entity instance.
2-14

15. Chapter 2: Microsoft Dynamics CRM Architecture
Privilege Description
Append Associate a selected entity instance to another entity
instance.
Append To To associate another entity instance to this entity instance.
Assign Give ownership of an entity instance to another user.
Share Give access to entity instances to another user and
maintaining ownership.
Reparent Assign a different parent to an entity instance.
Enable/Disable Give or take away privileges.
TABLE 2-1: MICROSOFT DYNAMICS CRM PRIVILEGES
Privileges are combined with an access level. The Access Level uses the
ownership of the object and the organization structure of the implementation to
determine whether the user can apply privileges on a specific object.
There are four different Access Levels. The terminology used in the SDK differs
from the terminology in the Application.
SDK Access level name Application Name
Global Organization
Deep Parent: Child Business Units
Local Business unit
Basic User
None None Selected
TABLE 2-2: ACCESS LEVELS
Object -based Security
One of the goals of the Microsoft Dynamics CRM Security model is to support
data sharing. Users who have the share privilege on a particular entity instance
(object) can grant other users access rights for that object that can override
Access Level restrictions. However, sharing cannot grant a user a privilege if
they have no privileges at all on that entity. If the user does not belong to a role
that provides some level of access, sharing cannot provide that privilege. For
example, if a user does not have Read privileges on Accounts and an account is
shared with that user, the user will not be able to see that account.
Access rights: When an object is shared, certain access rights can be granted to
enable a particular user, or members of a team to perform actions on that object.
2-15

16. Extending Microsoft Dynamics® CRM 4.0
Security Principals
Security Principals
Entities in Microsoft Dynamics CRM are either owned by the organization or by
users. Instances of user-owned entities must be assigned a user as an owner.
Entity instances can be shared with other users and with teams. Both of these
represent types of Security Principals. A Security principal is a user or team that
can own or access an entity instance. Although a team cannot own an entity
instance, sharing an entity instance with a team makes it available to all the
members of the team that have access to that privilege.
Security Dependencies
Security Dependencies
Sometimes security dependencies exist because there must be more than one
access right to perform a given action. For example, if there is the CREATE
access right for accounts, an instance of the account entity can be created.
However, unless there also is READ access for the accounts, an instance of the
account entity cannot be created, and it is not possible to be the owner of that
new account instance.
Platform Business Logic
Besides the important business logic that is part of Microsoft Dynamics CRM,
such as requiring Opportunities to be associated with a Customer or that each
user owned object is assigned to a valid user, the platform enables custom
business logic through Plug-ins. The Workflow engine provides another method
to include custom business logic in the platform.
The Platform is responsible for raising events which enable event handlers to
respond and apply additional business logic. There are three primary users for
these events:
• Standard Business Logic
• Plug-ins
• Workflow
2-16

17. Chapter 2: Microsoft Dynamics CRM Architecture
Standard Business Logic
Standard Business Logic
Microsoft Dynamics CRM includes some standard behavior that represents the
business logic found in the Platform. Some examples of the default business
logic found in Microsoft Dynamics CRM include the following:
• Cascading behaviors: When an account is re-assigned, all the
objects related to it are also re-assigned to the new account owner if
the relationship settings are set to Parental. Cascading behaviors and
entity relationship settings are discussed in detail in the training
course A Customization and Configuration in Microsoft Dynamics
CRM 4.0.
• Automatic Sharing: When an object is re-assigned, the object is
automatically shared with the former owner if the System Setting
“Share reassigned entities with original owner” is set to Yes.
Plug-ins
Microsoft Dynamics CRM exposes a simple extension mechanism for
implementing the custom platform-based business logic “Plug-in” model. With
this model, developers are not limited to creating custom business logic only in
the application or through workflow processes; they can also construct business
logic that runs in the context of a call, but in response to a particular event.
Pre and Post Event Plug-ins: This extension mechanism exposes a Plug-in
interface based on a simple pipeline model. The pipeline model allows for both
“pre” and “post” interceptions for basic data persistence operations. The platform
metadata stores information about each entity. This information can be used to
track:
• The list of Plug-in handlers.
• The class names.
• Whether a given handler is required for an action.
For example, the account entity can have several registered handlers. These
handlers are stored in call order, which is determined by priority. When an action
occurs, the platform examines the metadata for registered event handlers. This
information is specified when a plug-in is registered. If a handler is registered for
notification, the platform creates the handler object and calls the correct handler
method, passing the details of the entity instance.
2-17

18. Extending Microsoft Dynamics® CRM 4.0
Workflow
The workflow subsystem's goal is to process system events and run processes.
The workflow system consists of:
• A graphical user interface within the Microsoft Dynamics CRM Web
application for creating and monitoring workflow processes.
• The Asynchronous Service, a Microsoft Windows service that
responds to events, schedules events, and runs processes. The
Asynchronous Service is available in the Services utility in Windows
Administrative Tools. This service is installed during Microsoft
Dynamics CRM Server installation and is configured to be started
automatically.
• A set of messages for accessing instances of workflow rules.
• Workflow Activities which are used to write modules that provide
interaction between Workflow rules and external systems, or that
provide custom logic.
Custom Workflow Activities
If the workflow activities supplied with Microsoft Dynamics CRM 4.0 are not
sufficient for the workflow requirements, it is possible to create and deploy
custom workflow activities that can be called from within a workflow.
Custom workflow activities are supported only in Microsoft Dynamics CRM
4.0, not in Microsoft Dynamics CRM Live.
Data Access Components
Except for reports using Microsoft Dynamics CRM Filtered views , all
interaction with the database occurs through the platform. The platform includes
data access components which use the Microsoft Dynamics CRM metadata to
construct Transact-SQL statements to apply transactions against the Microsoft
Dynamics CRM database.
Data Access Methods
In the description used in this course the Data Access Components are grouped
together with the platform, but technically there is some separation. Microsoft
Dynamics CRM internally uses an object-based data management layer to shield
the platform code from the data access code. Queries can be constructed using
QueryExpression, QueryByAttribute and the FetchXML query language
2-18

19. Chapter 2: Microsoft Dynamics CRM Architecture
Building Queries: A QueryExpression is used to build a query that contains
data filters and search conditions that define the scope of a database search. A
QueryExpression is used for single-entity searches, for example, searching for all
accounts that match certain search criteria. QueryExpression provides a strongly
typed approach to building queries that can be executed. To save a query, convert
it to Fetch using a QueryExpressionToFetchXml request and save it as a
userquery. Because QueryExpression is strongly typed, Microsoft IntelliSense
support is available for the QueryExpression object within Visual Studio .NET.
Database Layer
Because the Microsoft Dynamics CRM Platform controls transactions against the
database, any programming directly against the database other than retrieving
data from filtered views is not supported. Because direct interaction with the
database is not supported - a full description of the structure of the CRM database
is not directly relevant to the developer. The developer should concern
himself/herself with the Entity definitions stored in the Platform metadata instead
of how the physical database stores this information. The database structure can
change in future releases of Microsoft Dynamics CRM.
In an initial Microsoft Dynamics CRM 4.0 implementation there are two
databases. The databases are created when Microsoft Dynamics CRM is installed
and are created by using the name of the organization. The databases are as
follows:
• <organizationname>_MSCRM
• MSCRM_CONFIG
If further organizations are created a corresponding
<organizationname>_MSCRM database will be created. However, there will just
be the one MSCRM_CONFIG database.
MSCRM Database
The <organization name>_MSCRM database stores the data for the entities
defined in the Microsoft Dynamics CRM platform. This is the customer data.
Supported Actions: Other than retrieving data from specified filtered views
within this database, there are no actions, other than regular database
maintenance such as backups, supported.
Mutable Database Structure: The whole architecture of Microsoft Dynamics
CRM is designed to enable changes - even radical changes, to the structure of the
database in any future release. Building a solution that depends on custom
triggers, stored procedures, views or any other modification to the database is
unsupported and likely to be broken in a future release.
Upgrade: The upgrade process is likely to delete an earlier database and replace
it with the latest version. Expect that any changes to the database will be lost
during an upgrade.
2-19

20. Extending Microsoft Dynamics® CRM 4.0
Filtered Views : The only supported action to include in an extension is to use
the Filtered Views in the <organization name>_MSCRM database. These views
use the naming convention Filtered<Entity Name>.
These views are provided to enable an ODBC or OLE DB compliant application
to use Microsoft Dynamics CRM data in reports. Microsoft Dynamics CRM
includes SQL Server reporting services as the reporting solution.
These views are designed to use the user's domain account credentials to replicate
the view permissions enforced by the CRM Platform. Queries against these views
only return records that the user can access through the Microsoft Dynamics
CRM application or any application built upon the Microsoft Dynamics CRM
platform.
MSCRM_CONFIG
The MSCRM_CONFIG Database is used to store the global CRM configuration
settings and this enables the support of multi-tenancy.
Deployment Considerations
Microsoft Dynamics CRM 4.0 supports many different deployment scenarios,
some of which may affect the extent, or ease, with which Microsoft Dynamics
CRM can be extended. The main considerations are:
• Deployment model. On-Premise, Service Provider or Windows
Online
• Authentication method
• Multi-tenancy deployments
• Multi-language deployments
Deployment Model
Many Microsoft Dynamics CRM 4.0 deployments are installed and managed at
the end-customer's location; this is known as an On-Premise implementation. In
this scenario, there are no additional limitations on the extensibility of Microsoft
Dynamics CRM, other than the customer's requirements, and whether or not
proposed extensions are supported.
Another deployment model is to make use of Windows Online, in which
Microsoft hosts the CRM servers. This imposes restrictions on extending
Microsoft Dynamics CRM, namely that it is not permitted to deploy plug-ins or
custom workflow activities within such a deployment.
2-20

21. Chapter 2: Microsoft Dynamics CRM Architecture
There is a third deployment model in the Service Provider model. This is similar
to the Windows Live model, except a third party service provider hosts the CRM
servers. In this scenario, the service provider typically specifies what type of
extensions is permitted. They also typically define the authentication method.
This deployment model is often referred to as an Internet Facing Deployment
(IFD).
Authentication Method
Microsoft Dynamics CRM 4.0 supports three different authentication methods;
Active Directory authentication, Passport authentication and Web Form
authentication. Which method is used depends primarily on the deployment
model, as follows, but other factors may be involved:
• On-Premise deployments typically uses Active Directory
authentication, but may use Web form authentication.
• Windows Live deployments always uses Passport authentication.
• Service Provider deployments can use either Active Directory or
Web form authentication.
The choice of authentication method can have two impacts on extending
Microsoft Dynamics CRM:
• A different URL is required for each authentication method to access
the CrmDiscoveryService.
• If writing custom Web applications, the authentication method will
affect how a user can be impersonated.
Multi-Tenancy
Multi-tenancy refers to the ability for one Microsoft Dynamics CRM installation
to host multiple independent organizations. In most cases any extensions to
Microsoft Dynamics CRM are specific to one organization, and the structure of
the Microsoft Dynamics CRM databases and Web services allows for easy
separation of each organization.
An important point is that the organization name must be specified for all calls to
the CrmService and MetadataService Web services. Therefore any custom code
must be structured such that information is available where necessary.
Multi-Language
One Microsoft Dynamics CRM organization may have multiple language packs
installed, which allows different users to see metadata-driven information (such
as picklists and field labels) in different languages.
This can impact code that uses and displays metadata to a user, as such code
should be aware of that user's preferred language , and render the appropriate
labels.
2-21

22. Extending Microsoft Dynamics® CRM 4.0
Demonstration: Using the Metadata Browser
Scenario
You are developing an extension for Microsoft Dynamics CRM for an
organization that has customized its implementation.
Goal
Become familiar with the entity. You want to know:
• What is the entity (object) type code.
• Which attributes can be used when you are creating or updating an
instance of this entity.
• The length of the Name attribute.
• How a custom entity called “Opportunity Details” is related to the
entity.
• What is the entity (object) type code for Opportunity Details?
Steps
This demonstration includes the following steps:
1. Open the Metadata browser.
2. Import the Opportunity Details custom entity.
3. Note how Opportunity Details is related to Opportunities.
Step 1: Open the Metadata Browser
1. In the Run window, enter
http://crm/AdventureWorksCycle/sdk/list.aspx.
2. Locate the opportunity entity in the entity column and then click the
graphic in the definition column.
3. Locate the following information:
o The Object Type Code.
o Which attributes are not Valid for Create or Valid for Update?
o What is the length of the name attribute?
2-22

23. Chapter 2: Microsoft Dynamics CRM Architecture
Step 2: Import the Details Custom Entity
1. Import the OpportunityDetail.xml file located at C:Class
MaterialsExtendingCh. 2
If you are not familiar with importing Customizations refer to Export
or Import customized Entities, templates or navigation in the on line
help.
2. Open the metadata browser and locate the new_opportunitydetail
entity.
Step 3: Note how Details is related to Opportunities
1. Open the entity definition.
2. Locate the relationship that connects to new_opportunitydetail.
3. Open new_opportunitydetail entity definition and locate the entity
(object) type code.
Summary
This course provided an overview of the Microsoft Dynamics CRM Architecture.
Microsoft Dynamics CRM is designed to provide a scalable, SOA platform to
support Microsoft Dynamics CRM clients and solutions built by developers.
Microsoft Dynamics CRM provides several extensibility points. These points are
the focus of the rest of this course. They include the following:
• Web Service Programming
• Custom Workflow Activities
• Plug-ins
• Client Programming
The Microsoft Dynamics CRM Outlook clients provide a deep integration with
Outlook. The Microsoft Dynamics CRM 4.0 Laptop Client for Outlook provides
a local version of the Microsoft Dynamics CRM platform for offline use.
Microsoft Dynamics CRM uses a metadata driven architecture that is designed to
enforce security, make customizations easier, and enable smooth transition
during upgrades.
2-23

24. Extending Microsoft Dynamics® CRM 4.0
Microsoft Dynamics CRM can be divided into several different physical or
logical layers. The most important divisions for developers creating extensions to
Microsoft Dynamics CRM are the Application and Platform layers.
• Application Layer: The Application layer is a client that is built on
the Microsoft Dynamics CRM platform. It uses security metadata to
display functional areas that users have privileges to view. It also
uses metadata to enable easy form and view customizations. The
application includes limited business logic.
• Platform Layer: The Platform layer is the heart of Microsoft
Dynamics CRM. It contains the Web Service APIs that provide the
only integration point to perform transactions in Microsoft Dynamics
CRM. It generates the events that drive all business logic performed
in the platform. It defines the available entities and enforces security.
Finally, the platform contains data access components that interact
with the Microsoft Dynamics CRM databases. Developers can build
queries that use these components to retrieve data from Microsoft
Dynamics CRM.
• Database Layer: The Microsoft Dynamics CRM Databases support
the use of special filtered views for retrieval of data from ODBC or
OLEDB compliant applications. Any other direct interaction or
modification to the Microsoft Dynamics CRM databases is
unsupported.
2-24

25. Chapter 2: Microsoft Dynamics CRM Architecture
Test Your Knowledge
Test your knowledge with the following questions.
1. Which of the following represent Microsoft Dynamics CRM 4.0
Extensibility points for Developers? (Select all that apply.)
( ) Web Service Programming
( ) Custom Workflow Activities
( ) Plug-ins
( ) Client Programming
2. Which of the following components can be found on the Microsoft 4.0
Desktop client for Microsoft Office Outlook?
( ) A SQL Server 2005 Express Edition database
( ) A local Web server
( ) A local version of the Microsoft Dynamics CRM Web application
( ) None of the above
3. What characteristic of the Microsoft Dynamics CRM design lets you create
custom entities and additional system entity attributes and also make
upgrades easier and enable transportation of customizations?
( ) N-Tier Architecture
( ) Service Oriented Architecture
( ) Metadata Driven Architecture
( ) All of the above
4. Which of the following are areas controlled by Application Level security?
(Select all that apply.)
( ) The ability to move through different areas of the application
( ) When a record will appear in a read-only form
( ) When a particular field is hidden or disabled for a user
( ) All the above
5. Which of the following represent the data validation performed by the
Application?
( ) Data Integrity
( ) Data validity
( ) Enforcing Constraints
( ) All of the above
2-25

26. Extending Microsoft Dynamics® CRM 4.0
6. Which of the following are true?
( ) Each Microsoft Dynamics CRM 4.0 entity has a separate dedicated Web
service
( ) All Microsoft Dynamics CRM Entities inherit from an abstract base class
named BusinessEntity
( ) To read the Microsoft Dynamics CRM metadata you must query the
<organization name>_MSCRM database
( ) Integrations with Microsoft Dynamics CRM must use Microsoft
technologies
7. Which of the following represent advantages found in the Microsoft
Dynamics CRM 4.0 SDK? (Select all that apply.)
( ) IntelliSense® support in Visual Studio
( ) A dynamically generated WSDL
( ) Strong typing
( ) Design/Compile time errors
8. Task: Match the SDK Access level name with the Application Name.
_____ 1. Global a. User
_____ 2. Deep b. Business unit
_____ 3. Local c. Parent: Child Business Units
_____ 4. Basic d. None Selected
_____ 5. None e. Organization
2-26

27. Chapter 2: Microsoft Dynamics CRM Architecture
Quick Interaction: Lessons Learned
Take a moment and write down three key points you have learned from this
chapter:
1.
2.
3.
2-27

28. Extending Microsoft Dynamics® CRM 4.0
Solutions
Test Your Knowledge
1. Which of the following represent Microsoft Dynamics CRM 4.0
Extensibility points for Developers? (Select all that apply.)
(√) Web Service Programming
(√) Custom Workflow Activities
(√) Plug-ins
(√) Client Programming
2. Which of the following components can be found on the Microsoft 4.0
Desktop client for Microsoft Office Outlook?
( ) A SQL Server 2005 Express Edition database
( ) A local Web server
( ) A local version of the Microsoft Dynamics CRM Web application
(•) None of the above
3. What characteristic of the Microsoft Dynamics CRM design lets you create
custom entities and additional system entity attributes and also make
upgrades easier and enable transportation of customizations?
( ) N-Tier Architecture
( ) Service Oriented Architecture
(•) Metadata Driven Architecture
( ) All of the above
4. Which of the following are areas controlled by Application Level security?
(Select all that apply.)
(√) The ability to move through different areas of the application
(√) When a record will appear in a read-only form
( ) When a particular field is hidden or disabled for a user
( ) All the above
5. Which of the following represent the data validation performed by the
Application?
( ) Data Integrity
( ) Data validity
( ) Enforcing Constraints
(•) All of the above
2-28

29. Chapter 2: Microsoft Dynamics CRM Architecture
6. Which of the following are true?
( ) Each Microsoft Dynamics CRM 4.0 entity has a separate dedicated Web
service
(•) All Microsoft Dynamics CRM Entities inherit from an abstract base class
named BusinessEntity
( ) To read the Microsoft Dynamics CRM metadata you must query the
<organization name>_MSCRM database
( ) Integrations with Microsoft Dynamics CRM must use Microsoft
technologies
7. Which of the following represent advantages found in the Microsoft
Dynamics CRM 4.0 SDK? (Select all that apply.)
(√) IntelliSense® support in Visual Studio
(√) A dynamically generated WSDL
(√) Strong typing
(√) Design/Compile time errors
8. Task: Match the SDK Access level name with the Application Name.
a. User
e 1: Global
b. Business unit
c 2: Deep
c. Parent: Child Business Units
b 3: Local
d. None Selected
a 4: Basic
e. Organization
d 5: None
2-29

30. Extending Microsoft Dynamics® CRM 4.0
2-30