January Blog Series: New & Best Practices
Insights from: Arturo Bimrose (Fullscope CRM Architect)
A popular buzzword in the Microsoft Dynamics CRM space today is "portal." A "CRM portal" can vary in meaning, but in its simplest form it can be taken as this: an application that provides ancillary access to the data within a CRM system.
Various companies, including Microsoft, have published and continue to develop strong offerings for the interpretation of what constitutes a portal. Still, the decision between whether to buy or build a portal solution can be a difficult one given the uniqueness of requirements often found in portal specifications. Custom development is often required in addition to, or entirely in place of, out-of-the-box solutions or frameworks now available on the market.
This is the first blog in a series about portal development for Microsoft Dynamics CRM. This one will focus on the introductory high-level architectural considerations that many existing solutions available deal with and that must also be understood for custom portal development. Non-developers with rudimentary technical knowledge of Dynamics CRM and web technologies should be able to follow most of this blog.
The Simple Design
A simple portal of the web variety is an ASP.NET application that uses the Microsoft Dynamics CRM database as an operational data store through performing its create, read, update and delete (CRUD) operations by using a WCF service (Click here for more information) provided with Dynamics CRM known as the Organization service. The diagram below shows a relatively agnostic (i.e. web forms vs. MVC) architectural depiction.
Consider the following areas:
Even though database read access (in a restricted fashion, more on this below) is supported in an on-premises deployment, the Organization service is the only supported option for creates, updates and deletes. While it provides robust and secure transfer of data options, the WCF service can reach a tipping point with high traffic. The above architecture assumes a moderate concurrent user count and volume of reads and writes to CRM as an operational data store.Reading CRM data from an external application can be performed using three query APIs with varying flexibility, usability and to lesser extent performance. Austin Jones' piece on the limitations of each is dated but still relevant and valid: Dynamics CRM 2011 SDK Query Limitations by API (remember that the OData service is not accessible from external applications). There is an ongoing debate between lobbyists of QueryExpression and FetchXML over performance. While findings posted online are mostly inconclusive, many favor FetchXML.
Authentication and Authorization
A major point in the specification of any CRM portal is the authentication model. Making use of the underlying CRM User credentialing built on Active Directory (AD) is a clear option and is possible with both online and on-premises deployments (Azure AD and OAuth for the former). Benefits include the ability to leverage the access levels and security roles in CRM as well as parity between CRM and portal credentialing (which might be relevant to those developing a single sign on (SSO) solution).
One of most common benefits and reasons for building a CRM portal is to expose data in CRM to users outside the CRM User base. For example: a manufacturing company is storing the information of its distributors on the Account entity in CRM. These distributors might use a self-service portal to perform tasks like updating their address and entering order information, all of which is stored directly in CRM. For many reasons it makes little sense to provision a license and AD user for each distributor. A better approach would be to develop a portal authentication solution that incorporates the Account entity and uses a single service CRM/AD account to impersonate the (in theory) infinite distributors for the purposes of CRM CRUD operations.
A CRM portal is no exception to the woes of scalability. As stated earlier, the concurrent user figures and related volume of CRUD operations should be important concerns for portal developers and implementers of purchased solutions no matter the size of the enterprise using Dynamics CRM.
Lightening the load on the Organization service can be achieved fairly easily by using the caching and state management options available with an ASP.NET application and by making use of the filtered views provided in SQL with Dynamics CRM.
Caching in the portal ASP.NET application level
More information on state management can be found here: ASP.NET State Management Overview. A good example for cached data would be states used in addresses, which might be stored as entities or a on an option set (drop-down) field in CRM. Another could be a list of valid/active portal users in a custom authentication model (i.e. the GUIDs of Contact entities).
Accessing the CRM database directly by making use of filtered views
Microsoft Dynamics CRM provides "filtered views" as the supported method for querying SQL directly in an on-premises deployment. Querying the base tables directly is unsupported. In contrast to the base tables, filtered views keep the integrity of the CRM security model and manage the complexity of the base schema, which is intricate for some entities like those of type Customer and even more so Activity.
Authentication is an issue when attempting to use the filtered views. If the portal authenticates using an AD account and that user is a CRM User with access to the data, then the query execution should work fine. But if the user account executing the SQL is not a valid CRM User with CRM security model privileges to read the data, then issues will likely arise. Even if the Windows or SQL authentication is correct, the Dynamics CRM architecture relies on the SQL session user to deliver functionality like its security model where it requires a user ID to perform joins with a table known as PrincipalObjectAccess among others. There are a few workarounds floating around online for this particular issue that involve impersonation by way of the EXECUTE AS statement or setting of the CONTEXT_INFO value, which would enable developers to make this work: John Bailey's Accessing Dynamics CRM filtered views using a SQL Server account and Ankit Shah's Dynamics CRM 2011 On-premises - Use "Execute AS" to call custom stored procedures.
This blog does not address the controversial topic of whether or not filtered views are better or faster for accessing data than the Organization service. As stated earlier, the primary reasoning given for using filtered views in this particular scenario of portal building is to alleviate the Organization service of traffic.
Hopefully this brief blog has helped shed some light on the major technical elements related to CRM portals. Future posts will deep dive into topics relating to portal code optimization, authentication models, data access best practices, and architectures where an intermediate database is incorporated so that CRM is not the operational data store.