8969 a 02
Upcoming SlideShare
Loading in...5
×
 

8969 a 02

on

  • 1,765 views

 

Statistics

Views

Total Views
1,765
Views on SlideShare
1,765
Embed Views
0

Actions

Likes
1
Downloads
66
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

8969 a 02 8969 a 02 Document Transcript

  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • Extending Microsoft Dynamics® CRM 4.0 2-30