Performance best practices
The following best practices can help you write code that performs better.
1.Use multiple threads
Add threading support to your application to break up the work across
multiple CPUs. This suggestion assumes that you are running your code on a
multiprocessor system.
2.Allow the system to create
GUIDs
Allow the system to automatically assign the GUID (Id) for you instead of
manually creating it yourself. This suggestion allows Microsoft Dynamics CRM to
take advantage of sequential GUIDs, which provide better SQL performance. The
following sample code shows how to call the Create method to obtain a system-assigned GUID.
// Instantiate an account object.Account account = new Account { Name = "Fourth Coffee" };
// Create an account record named Fourth Coffee and retrieve the GUID.accountId = serviceProxy.Create(account);
3.Use early-bound types
Use the Entity class when your code must work on entities
and attributes that aren’t known at the time the code is written. In addition,
if your custom code works with thousands of entity records, use of the Entity class results in slightly better performance
than the early-bound entity types. However, this flexibility has a disadvantage
because you cannot verify entity and attribute names at compile time. If your
entities are already defined at code time and slight performance degradation is
acceptable, you should use the early-bound types that you can generate by using
the CrmSvcUtil tool.
4.Disable plug-ins
If possible,
disable registered plug-ins before you run your application.
5.Write plug-ins that execute
faster
Always write
a plug-in that takes the least time to perform its intended task. For example,
the Execute method is frequently processed in Microsoft
Dynamics CRM. If you register a plug-in on that message, your plug-in can have
a significant performance impact on the system because it executes every time
that the Execute method is
processed, which frequently occurs.
If you
intend to register your plug-ins for synchronous execution, we recommend that
you design them to complete their operation in less than 10 seconds. It’s best
to minimize processing time in plug-ins to maintain interactivity of the client
applications that are connected to the same organization service that executes
the plug-in.
6.Limit the data you retrieve
When you use
the methods that retrieve data from the server, retrieve the minimum amount of
data that your application needs. You do this by specifying the column set,
which is the set of entity attributes to retrieve.
For example,
it is rarely a good idea to retrieve all the metadata with the RetrieveAllEntitiesRequest message, specifying the EntityFilters. All
entity filter for the EntityFilters property. Instead, you might achieve better
performance if you restrict the entity filter, or use one of the following
messages: RetrieveEntityRequest, RetrieveOptionSetRequest, RetrieveAttributeRequest, RetrieveRelationshipRequest or RetrieveMetadataChangesRequest. The RetrieveMetadataChanges message allows
for constructing a query to return just the metadata you need or the metadata
that has changed.
7.Limit operations that
cascade to related entities
When you use
the Update method or UpdateRequest message, do not set the OwnerId attribute on a record
unless the owner has actually changed. When you set this attribute, the changes
often cascade to related entities, which increases the time that is required
for the update operation.
8.Adjust proxy settings on the
client (on-premises only)
A proxy
server sits between a client application, such as a web browser, and the actual
target server. When a computer is in a LAN, it can use a proxy server to
connect to the Internet. In this case, the proxy server is combined with, or is
a part of, the gateway server and firewall server. The proxy can cache web
requests and serve multiple client requests by using its cached data. If the
requested data is not present in the cache of the proxy server, it forwards the
request to the actual server by using its own IP address. Here, the proxy
server acts on behalf of the client computer.
Although a
proxy server can act as a cache server and can help load a webpage faster, it
can sometimes decrease performance if it is used incorrectly. Frequently,
people avoid manual proxy configuration and use automatic proxy configuration.
This shortcut helps in load balancing the proxy servers, but depending on the
complexity of the configuration script, a significant delay can be experienced
when you use automatic proxy configuration.
When the
Microsoft Dynamics CRM server is installed, you can bypass the proxy server to
achieve better throughput. The server offers a local web address that requires
no proxy to be reached. You can select Bypass proxy
server for local addresses and provide the fully qualified
domain name of the Microsoft Dynamics CRM server in the exceptions list. This
gives better throughput when records are created by using the Microsoft
Dynamics CRM SDK.
9.Improve service channel
allocation performance
You can
establish a connection to the Microsoft Dynamics CRM web services and
authenticate users by using the OrganizationServiceProxy and DiscoveryServiceProxy service proxy classes. However, improper use
of these service proxy classes can sometimes reduce application performance.
Therefore, if you understand when and how to use the different client classes
that are available in the SDK, you can often obtain better application
performance.
When you
establish a Windows Communication Foundation (WCF) service channel by using a
service endpoint, for example, by using the organization web service, your
application must perform two time consuming operations: metadata download from
the endpoint and user authentication. You can improve performance if your
application performs these operations a minimum number of times for each
application session. The OrganizationServiceProxy constructor shown here performs both these
operations any time a service proxy object is created.
OrganizationServiceProxy (Uri uri, Uri homeRealmUri, ClientCredentials clientCredentials, ClientCredentials deviceCredentials)
You
typically obtain better performance if your application uses this constructor
to create an instance of the service proxy by using this constructor one time
during the application session and cache the returned reference for use in
different code paths within your application. Notice that the returned service
reference is not thread safe so multi-threaded applications will need to
allocate one instance per thread. Applications must also call Dispose on the service proxy
object before they terminate in order to free service channel allocated
resources.
The service
proxy class performs the metadata download and user authentication by using the
following class methods.
IServiceManagement<IOrganizationService> orgServiceManagement = ServiceConfigurationFactory.CreateManagement<IOrganizationService>(new Uri(organizationUrl))AuthenticationCredentials authCredentials = orgServiceManagement.Authenticate(credentials)
The CreateManagement<TService> method performs the metadata download while
the Authenticate method authenticates the user. The returned
objects from these methods are thread safe and can be statically cached by your
application. You can then use these objects to construct a service proxy object
that uses one of the other available constructors.
OrganizationServiceProxy (orgServiceManagement, authCredentials.ClientCredentials)OrganizationServiceProxy (orgServiceManagement, authCredentials.SecurityTokenResponse)
By caching the service management and authenticated credential objects,
your application can more efficiently construct the service proxy objects more
than one time per application session. If you enable early-bound types on OrganizationServiceProxy through one of the
EnableProxyTypes methods, you must do the
same on all service proxies that are created from the cached IServiceManagement<TService>
object. If your application uses the metadata, we recommend that it caches the
metadata that it retrieves and periodically calls the RetrieveTimestampRequest message to
determine whether it must refresh the cache.
In addition, monitor your WCF security token (Token) and refresh it
before it expires so that you do not lose the token and have to start over with
authentication. To check the token, create a custom class that inherits from
the OrganizationServiceProxy or DiscoveryServiceProxy class and that
implements the business logic to check the token. Or wrap the proxy classes in
a new class. Another technique is to explicitly check the token before each
call to the web service. Example code that demonstrates these techniques can be
found in the ManagedTokenDiscoveryServiceProxy,
ManagedTokenOrganizationServiceProxy,
and AutoRefreshSecurityToken
classes in the Helper code: ServerConnection class topic.
Customization best practices
The following best practices can help you customize and extend Microsoft
Dynamics CRM.
1.Best practices for Microsoft
Dynamics CRM Online
The Microsoft Dynamics CRM Online patterns &
principles for solution builders white paper download provide
guidance specifically about building solutions using Microsoft Dynamics CRM
Online.
2.Using custom entities and
attributes
Save space on your server by using these techniques:
·
Create custom attributes for existing
entities instead of creating a new entity.
·
Rename existing entities to make the entities
more meaningful.
3.When should you customize an
entity?
Customize a system entity, such as the opportunity entity, instead of
replacing it with a new custom entity so that you can use the many built-in
features in an existing entity. For example, the opportunity and case entities
have lookup fields to associate customers. Customers may be accounts or
contacts. You cannot create a custom entity that has the same type of lookup.
You can change the display name of a system entity to make it more meaningful
to your business.
4.When to use plug-ins vs.
workflow?
As a developer who is interested in extending or customizing Microsoft
Dynamics CRM, you can choose from several methods to perform your tasks. In
addition to adding client-side JavaScript code to a form or adding custom
ASP.NET pages, you can write a plug-in or create a custom workflow by using the
web interface that calls a custom workflow activity. How do you decide when to
use a plug-in and when to use a workflow? The technology that you use depends
on the task that you have to perform and who will author the customization.
For example, you must use a synchronous plug-in real-time workflow if you
want to execute custom code immediately before or after the core platform
operation executes and before the result of the operation is returned from the
platform. You cannot use an asynchronous workflow or asynchronous plug-in in
this situation because they are queued to execute after the core operation
finishes executing. Therefore, you cannot predict when they will run. If you
want to add custom functionality to Microsoft Dynamics CRM Online, workflows
and plug-ins are supported, but custom workflow activities are not.
Evaluate these technologies and select the one that best suits your
business objectives after you consider the deployment, performance, and
maintenance concerns of your plug-in or workflow solution.
The following table summarizes the characteristics of plug-ins and
workflows.
Criteria
|
Plug-in
|
Workflow
|
| Execution
before or after the core platform operation (Create, Update, Delete, and so
on) |
Executes
immediately before or after the core operation (synchronous).
Can also
be queued to execute after the core operation (asynchronous). |
Asynchronous
workflows are queued to execute after the core operation.
Real-time
workflows have similar characteristics to plug-ins. |
| Performance
impact on the server |
Synchronous
plug-ins can increase the platform response time because they are part of the
main platform processing.
Asynchronous
plug-ins have less impact on server response time because the code is run in
a different process. |
Asynchronous
workflows have less impact on server response time because the code is run in
a different process.
Real-time
workflows have similar performance characteristics to sandboxed plug-ins. |
| Security
restrictions |
To
register a plug-in with the platform requires a System Administrator or
System Customizer security role and membership in the Deployment
Administrator group. |
Users can
interactively create workflows in the web application.
However,
to register a custom workflow activity, the deploying user must have the same
security roles as those required for registering plug-ins. |
| Microsoft
Dynamics CRM version (SKU) support |
Supported
in Microsoft Dynamics CRM Online when registered in the sandbox. May be supported
in partner-hosted installations at the discretion of the partner. |
Workflows
are supported by all CRM deployments. Custom workflow activities are
supported in the sandbox of Microsoft Dynamics CRM Online, and in or outside
the sandbox for on-premises/IFD deployments. |
| Length of
processing time |
A plug-in
registered for synchronous or asynchronous execution is restricted to
complete its execution in a two-minute time limit. |
Works well
for either short or long processes. However, each activity in a workflow
cannot take longer than two minutes to complete. |
| Works when
the Dynamics CRM for Outlook client is offline |
Both
online and offline are supported. |
Workflows
do not execute when offline. |
| Process
and data persistence |
Plug-ins
execute until they are completed. Plug-ins must be written to be stateless
where no in-memory data is persisted. |
Asynchronous
workflows can be paused, postponed, canceled, and resumed through SDK calls
or by the user through the web application. The state of the workflow is
automatically saved before it is paused or postponed.
Real-time
workflows cannot have any wait states. They must execute to completion just
like plug-ins. |
| Impersonation |
Plug-ins
can perform data operations on behalf of another system user. |
Asynchronous
workflows cannot use impersonation, while real-time workflows can. Real-time
workflows can execute either as the owner of the workflow or as the calling
user. |
| Authoring |
Software
engineers or programmers can author plug-ins. |
Anyone,
including an end user, business analyst, or administrator can author
workflows if they have the proper permissions. |
There is no significant performance impact on the server between an
asynchronous plug-in and a workflow.
5.What type of workflow is
better?
From a performance perspective, is it better to create a single long
workflow or is it better to have multiple child workflows and call them in one
parent workflow? The child workflow approach achieves lower throughput, but it
is more manageable if you frequently change your workflow definition.
Compilation overhead is not a major concern because the workflow is compiled
only during publishing. However, Microsoft Dynamics CRM incurs overhead when it
starts each workflow instance. The overhead occurs when all entities that are
used in the workflow are retrieved and the child workflow is started in a
two-step process that includes a 'Workflow Expansion Task' and the actual
workflow instance. Therefore, for maximum throughput, use a single long
workflow.
6.How should you mark your
custom workflow activity as completed?
The return value from the Execute
method is used by the workflow runtime to mark the activity as “completed.” You
should use return base.Execute(executionContext) unless
the activity bypasses base class functionality. Avoid returning ActivityExecutionStatus.Closed.
7.How should you report
exceptions in custom workflow activities?
You should throw an InvalidPlugInExecutionException
in your code. This error will be shown in the workflow instance form.
8.Can you define custom
entities that are specific to business units?
Custom entities have privileges for each security role but not for each
business unit. To define custom entities that are visible only to specified
business units, you must create different security roles for each business unit
and grant privileges to the custom entity in the appropriate role.
Security best practices
Follow these guidelines to help protect your business data.
1.General
Best practices for securing your implementation of Microsoft Dynamics CRM
include the following:
·
Establish an approved security data plan for
your organization's Microsoft Dynamics CRM implementation.
·
Assign the least privileges required when you
set up your application pool.
·
Require that all users use strong passwords for
their accounts. For more information, search for “strong passwords” in Windows
Help.
2.Roles, privileges, and
access rights
Best practices for use of the Microsoft Dynamics CRM security model include
the following:
·
Strictly limit the number of people assigned
the System Administrator role. Never remove this role.
·
Create roles according to the security best
practice of least privilege, providing access to the minimum amount of business
data required for the task. Assign users the appropriate role for their job.
·
Create a new role with those specific
privileges and add the user to the new role if a user needs additional access
levels or rights. A user's rights are the union of all the roles to which he or
she has been assigned. Do not grant the original role privileges that are
needed by only one or several members.
·
Use sharing, when appropriate, to give
specific users specific rights on individual objects, instead of broader
privileges on all objects of a given type.
·
Use teams to create cross-functional groups
so that specific objects can be shared with the team.
·
Train users who have sharing access rights to
share the minimum information needed.
3.Avoid elevation of privilege
Elevation of privilege attacks occur when a user can assume the privileges
of a trusted account, such as an owner or administrator. Always run under
least-privileged user accounts and assign only needed permissions. Avoid using
administrative or owner accounts for executing code. This limits the amount of
damage that can occur if an attack succeeds. When performing tasks that require
additional permissions, use procedure signing or impersonation only for the
duration of the task.
Server-side development
Best practices for developing server-side code for Microsoft Dynamics CRM
include the following:
·
Do not modify the Microsoft Dynamics CRM
database by any means other than using the SDK because this bypasses the
Microsoft Dynamics CRM security model.
·
Plug-ins are running in an administrator's
context – you should know that this code may access information that the
logged-on user does not have access to.
·
For workflow assemblies, and plug-ins, avoid
writing code that takes a long time to execute. It is important that plug-in
code that is registered to execute synchronously returns as quickly as
possible.
·
If you are replicating Microsoft Dynamics CRM
data in your own data store, you are responsible for the security of the data.
If you use a plug-in to transmit the data, make sure that you register the
plug-in to execute after the core platform operation. Security privilege checks
for the logged-on user occur during the core platform operation.
·
Data that comes out of Microsoft Dynamics CRM
might not be safe for rendering. Data may have been injected with HTML tags
that are not secure.
·
Adhere to the requirement of not accessing
Microsoft Dynamics CRM databases directly through SQL Server Enterprise
Manager. Bypassing the SDK can open you up to SQL injection threats.
·
For Internet facing deployments, remember
that your solution is only as secure as the weakest link. After your
application is exposed to the Internet, it is open to security threats.
·
Use only languages that produce managed code
for the best security from buffer overruns, exceptions, and so on.
For more information about security, see the following topics:
Client-side development
Best practices for developing customizations for the CRM web application
and Microsoft Dynamics CRM for Outlook include the following:
·
Use web resources instead of pages that
require server-side processing whenever possible. If your requirements can only
be achieved by using server-side processing, adhere to the requirement that
your custom webpages are installed in a separate website from Microsoft
Dynamics CRM. Set the trust level for your site appropriately, depending on
your confidence level in the security of your code. This reduces the threat
from cross-site scripting and other threats.
·
For improved security, make sure that your
separate website runs on a different account from Microsoft Dynamics CRM. This
account should have the minimum access possible and one that does not have
direct access to the Microsoft databases. You can use a complex password that
doesn’t expire because no person signs in to this account – only in to your
application.
·
Avoid use of ActiveX controls because they
have known security problems.
·
Be aware of the limitations of client scripting.
·
Use plug-ins to apply business logic
regardless of how the data changes are made.
·
Always use a confirmation dialog box when you
delete records or apply sensitive changes, such as adding a new user to a
security role. You can use the Xrm.Utility.confirmDialog to display a dialog. This
helps prevent techniques such as click-jacking or UI redressing where a
malicious developer may embed your page in a seemingly innocuous page to trick
a user into performing actions that may compromise security or perform unwanted
actions on data.
Security best practices for your website include the following:
·
Don’t use anonymous access.
·
Use integrated Windows authentication, NTLM,
or Basic authentication over Transport Layer Security (TLS) or Secure Sockets
Layer (SSL).
·
Use TLS/SSL to avoid sending unencrypted data
over the network if your website is on a different computer than Microsoft
Dynamics CRM.
For more information, see the following:
ISV extensibility best
practices
One of the key tenets of ISV extensibility is that you should not assume
that your ISV solution is the only one installed. The following is a list of
best practices to follow.
1.Best practices for using the
Microsoft Dynamics CRM web services
You should put the Microsoft Dynamics CRM web service URLs into a configuration
file, for example, into an app.config file, so that your code is isolated from
changes to the URL. For example, there are different URLs for the three
Microsoft Dynamics CRM Online data centers throughout the world.
For on-disk plug-ins or custom workflow activities, place the assemblies in
the <installdir>\Server\bin\assembly folder.
3.Where should you put your
custom web applications or webpages?
Refer to the topic Implement single sign-on from an ASPX webpage or
IFRAME.
4.How do you execute a plug-in
when the web application’s grid view is updated?
Register the plug-in on the RetrieveMultipleRequest message request and
do not specify any entity type during the registration.
When should you create a new
website?
Create a new website for your code when any of the following applies:
·
Your application must be bound to a domain,
protocol, or port that is different from the Microsoft Dynamics CRM
application; or must run in a different application pool.
·
Your application can exist and be accessed on
its own. For example, a portal that interacts with Microsoft Dynamics CRM as
the server (by using web services) should be hosted as a new website.
·
Your application always uses Active Directory
or integrated Windows authentication (not IFD) and cross-domain scripting is
not an issue. For example, your application interacts with a back end by using
web services and interacts with Microsoft Dynamics CRM forms. A page hosted in
an IFRAME that is enclosed in Microsoft Dynamics CRM application that does not
interact with the Microsoft Dynamics CRM form falls into this category.
