Extending Microsoft Dynamics CRM 4.0
- Limitations and Licensing Considerations
- Customization Options by CRM Version
- Customizing Navigation
- Form Events
- IFrames
- Examples
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Extending Microsoft Dynamics CRM means many things. To some, it is simply using built-in features of Microsoft Dynamics CRM, such as onChange events (JavaScript events available on CRM forms) to format data a certain way after it has been input. To others, it is building complex systems that interact with the CRM platform for internal applications (such as backend human resources or enterprise resource planning [ERP]/accounting systems) via the creation of plug-ins and/or usage of middleware applications for managing synchronization (usually BizTalk or Scribe applications).
This chapter covers both options, but first we review what it means to extend Microsoft Dynamics CRM and examine some necessary factors you must consider before performing any of the included customizations.
As mentioned in Chapter 1, "Extending Microsoft Dynamics CRM Explained," extending Microsoft Dynamics CRM can be accomplished via any of the following:
- Custom logic via plug-in development
- Source-to-source integration (web services integration)
- Custom application integration using IFrames
- CRM JScript to extend across various forms
- Workflow
While a large portion of this chapter addresses how you can make modifications to Microsoft Dynamics CRM when you know the user base, browser version, and requirements, it is important to consider what it means when these environmental variables are unknown, or when the application needs to cross domains or be available to a wide array of users. If this is your situation, it is worthwhile to consider an xRM platform approach.
This chapter also includes customization examples that relate both to the client side and to the server end. And to show what it means to extend Microsoft Dynamics CRM with other internal applications (such as other CRM systems or other line-of-business applications), we also delve into some sophisticated models of integration within this chapter.
Limitations and Licensing Considerations
Microsoft Dynamics CRM 4.0 is licensed on either a per-named user or per-device model. (This is somewhat dissimilar from some of Microsoft's ERP offerings that have a licensing model of concurrency.) Therefore, each and every user who accesses Microsoft Dynamics CRM 4.0 must be identified and set up in Microsoft Dynamics CRM as a valid user with a valid role. End-user licensing is referred to as client access licenses (CALs). Figure 3.1 shows how users are administered in Microsoft Dynamics CRM 4.0.
)
Figure 3.1 Microsoft Dynamics CRM administration of users.
Figure 3.2 shows the device model that is commonly used in call center and manufacturing organizations, where multiple users may use the same computer (but not at the same time).
)
Figure 3.2 Microsoft Dynamics CRM with a single-device CAL.
In Figure 3.2, it is important to remember that all three users listed will need to be added to Microsoft Dynamics CRM as valid users (as shown in Figure 3.1). However, instead of purchasing three separate CALs, one for each user, only one CAL must be purchased.
Contrast Figure 3.2 with Figure 3.3, which shows three figures, and therefore requires three CALs.
)
Figure 3.3 Microsoft Dynamics CRM with three named-user CALs.
The end result from both of these examples is the following:
- From a licensing perspective, you will have either one CAL (a device CAL) or three named-user CALs.
- From a CRM administration perspective, you will have three users set up and configured with valid roles in Microsoft Dynamics CRM.
This example is included to show the extension of Microsoft Dynamics CRM when a valid user is required (which is often the case when building components that integrate with Microsoft Dynamics CRM).
A frequent mistake that amateur integrators make is to just take advantage of an existing user CAL and use that CAL as the hard-coded authentication/integration credentials. Although this is not necessarily a problem (and several of our examples include such a method), it is important to realize that Microsoft recognizes such usage as a method of access, and it may therefore place the organization in license-compliance risk. This is especially true if the system is designed to perform any level of integration with any application that delivers data outside of the domain.
In addition, it is important to remember that Microsoft Dynamics CRM CALs are instance based, and with multiple on-premise servers (such as with a server farm), only the single-user CAL is required, regardless of the number of actual CRM servers.
As stated previously, Microsoft has positioned Microsoft Dynamics CRM as a platform and has therefore developed a licensing model for it that enables access to it without requiring a license for every user. But, a license is required if data is going to be accessed across the organizational domain; this method of access is referred to as using the connector model or connector licensing.
External Connector License
The Microsoft External Connector license allows organizations to extend Microsoft Dynamics CRM data both across disparate applications and across the domain.
Although it is nothing more than a licensing mechanism, it is important to understand and is included within the context of this book because it is a necessary license when performing several of the integration options mentioned.
The External Connector license is available in two different formats for Microsoft Dynamics CRM:
- Full External Connector
- Limited External Connector
The intention of the Limited External Connector is to allow interaction on a read-only level with the Microsoft Dynamics CRM data, whereas the Full External Connector allows full read/write on the Microsoft Dynamics CRM data. (The cost of the license reflects the restriction levels; the Limited External Connector is approximately one-third the cost of the Full External Connector.)
Connection Options
Finally, it is appropriate to mention that the method of access is completely optional to the end user. There are three ways to interact with Microsoft Dynamics CRM data:
- Microsoft Dynamics CRM web services
- SQL Server CRM filtered views
- SQL Server CRM tables
Microsoft Dynamics CRM web services allow applications to consume CRM business rules and data directly from the CRM web server. In some cases, this is the preferred method, and creating a connection directly to the SQL Server database is impractical.
SQL Server CRM filtered views (see Figure 3.4) are similar to CRM web services in that they're designed to be used by end users who are performing integrations, because they enforce security roles, which are important when considering integration applications that can be used by a variety of users in an organization. In addition, the views can be used for read-only access, but should not be used for write access.
)
Figure 3.4 Microsoft Dynamics CRM SQL filtered views.
Although our discussion references all the methods listed previously, be sure to understand the implications of using one versus the other.