The OrganizationServiceProxy and DiscoveryServiceProxy service proxy classes provide the ability to establish a connection to and communicate with the available Microsoft Dynamics 365/CRM services. However, improper use of these API's can potentially reduce application performance. Therefore, if you understand when and how to effectively leverage these service client API's, available in the SDK, you can optimize communication traffic between your application the Dynamics 365/CRM server.
When you establish a Windows Communication Foundation (WCF) service channel by using one of the service endpoints, for example, the Organization.svc, your application must perform two additional, time-consuming operations: 1) metadata download from the endpoint and 2) 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 below performs both of these operations, in addition to allocating a new service channel, every time a service proxy object is created.
new OrganizationServiceProxy(new Uri(this.orgServiceUrl), null, this.Credentials, null)
A first step towards improving performance is to minimize the number of times your application uses this constructor to create an instance of the service proxy. If possible, use this constructor only 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 two previously mentioned operations, metadata download and user authentication, by using the following public methods available as client API's.
IServiceManagement<IOrganizationService> sm = ServiceConfigurationFactory
this.Credentials = sm.Authenticate(this.Credentials);
The CreateManagement 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.
As a more efficient alterntive, you can then use these objects to construct a service proxy object via one of the other constructor overloads (depending on the authentication scenario):
These constructor overloads bypass the two aforementioned operations and use the referenced service management and authentication credentials passed as method arguments. By caching the service management and authenticated credential objects, your application can more efficiently construct the service proxy objects and allocate multiple service channels as necessary over the lifetime of an application session without repeating the costly (and redundant) operations.
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 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.