You can connect the Dynamics 365 for Customer Engagement application to the Azure platform by coupling the event execution pipeline of the Customer Engagement application to the Azure service bus. Once you set up this connection, you can send data processed as part of the operation of the current customer engagement application to the service bus. The Azure Service Bus solution of “Customer Engagement application enabled” can listen and read Dynamics 365 for Customer Engagement application data from the service bus.
This connection between the Dynamics 365 for Customer Engagement application and the Azure platform provides a secure and reliable channel for communicating the runtime data of the Customer Engagement application to an external cloud-based line of business (LOB) application.
Important elements of the connection
The main elements that implement the connection between Dynamics 365 for Customer Engagement application and Azure Service Bus are described below. The figure in the next section shows these elements in operation.
The data context contains the business data being processed as part of the current Customer Engagement application operation. This process was initiated when a request was made from a user, workflow, or application to perform a specific operation on the Dynamics 365 for Customer Engagement application platform. The data context is passed to all plug-in or custom workflow activities that are registered in the event pipeline to run with the specific request and entity combination currently being processed. The data context is of type IPluginExecutionContext when passed along the event execution pipeline and of type RemoteExecutionContext when it is sent to the service bus.
The data context contained within the message posted to Azure Service Bus can be formatted as XML or JSON in addition to the default .NET binary format. This enables cross-platform interoperability where non-.NET clients hosted on Azure can read the data of the Customer Engagement application from the service bus. This feature was introduced in CRM Online 2016 Update 1 and CRM 2016 Service Pack 1 (on-premises).
Plugins are one of two methods used to initiate the sending of messages containing data contexts to the Azure Service Bus. Another way is custom workflow activity. Dynamics 365 for Customer Engagement the Azure connection features supported by the application include two types of plug-ins: out-of-box (OOB) and custom. In either case, we recommend that you register to run the plug-in asynchronously to get the best system performance.
The Azure compatible OOB plug-in is included with the customer engagement application and can be registered using the SDK download plug-in registration tool. This plugin runs completely in trust with the Dynamics 365 for Customer Engagement application platform. You need to register the plugin ‘step’ in the event notification pipeline. It identifies a combination of messages and entities that the plug-in triggers to execute and execute post notifications. When executed, the plug-in notifies the asynchronous service via the service endpoint notification service (IServiceEndpointNotificationService) and sends the current request data context to the Azure service bus.
You can also create your own custom plug-in for Azure. The custom plugin runs in partial trust mode within the sandbox. Custom plug-ins can start sending data contexts to the data bus through the service endpoint notification service. If you add code to call this service, the plugin will be “Azure enabled”.
Custom workflow activity
Like the plug-in, you can write a custom workflow activity to start sending the current request message data context to the Azure service bus using the service endpoint notification service (IServiceEndpointNotificationService).
When notified by the service endpoint notification service, the asynchronous service handles sending the data context of the request message currently being processed by the event execution pipeline to the Azure service bus. Each post is executed by a system job of asynchronous service. Users can view the status of each system job using the System Jobs view of the Dynamics 365 for Customer Engagement application Web application.
Microsoft Azure Service Bus
The service bus relays the request message data context between the Dynamics 365 for Customer Engagement application and the Azure Service Bus solution listener application. The service bus also provides data security so that only approved applications can access the data of the posted Dynamics 365 for Customer Engagement application. The approval of the Dynamics 365 for Customer Engagement application for posting data engagement to the service bus and for the listener application to read it is managed by Azure Shared Access Signatures (SAS).
Microsoft Azure Solution
For the Customer Engagement-Azure connection to work, at least one solution is required for the Azure Service Bus solution account. This solution includes one or more service endpoints. In the case of a relay endpoint contract, the “customer engagement-ready” listener application must be actively listening on the endpoint for customer engagement requests on the service bus. For queue endpoint contracts, listeners do not need to actively listen. As the type RemoteExecutionContext is defined, the listener is “customer engaged” by linking it to Microsoft.Xrm.Sdkassembly.
Sign a contract between Dynamics 365 for Customer Engagement application and Azure solution
For each solution endpoint, configure the contract to define the processing of this remote execution context “message” on the service bus and the security that it needs to use on that endpoint. The service bus message is received at the endpoint using one of the supported contracts listed here.
The queue contract provides a message queue in the cloud. With queue contracts, listeners do not need to actively listen for messages on endpoints. In the case of queues, there are destructive reading and nondestructive reading. A destructive read reads the available messages from the queue, and the message is deleted. For nondestructive reads, messages cannot be deleted from the queue.
The type of queue supported by Dynamics 365 for customer engagement applications is called a persistent queue. The persistent queue has a long message finite duration that can be specified in the code.
A one-way agreement requires an active listener. Posting to the service bus will fail if there are no active listeners on the endpoint. The Dynamics 365 for Customer Engagement app retries posting over a longer period exponentially until the asynchronous system job sending the request is finally aborted and its status is set to “failed”.
An interactive contract is similar to a one-way contract, except that the string value can be returned to the plug-in or custom workflow activity that originated the post from the listener.
The REST agreement is similar to an interactive contract at the REST endpoint.
It is similar to a queue except that one or more listeners can subscribe to receive messages from topics.
This contract type applies to the Azure Event Hub solution.
Claim authentication is used for secure access to the service bus. The charges used to authenticate to the service bus are generated by the Dynamics 365 for Customer Engagement application and signed by the AppFabricIssuer certificate specified in the Dynamics 365 for Customer Engagement application configuration database.
Managing run-time errors
If an error occurs after attempting to post to the service bus, check the status of the relevant system job in the Dynamics 365 for Customer Engagement application Web application for details of the error. If the service bus is down or the listener / endpoint is not available, the current message being processed by the customer engagement application in Dynamics 365 will not be sent to the bus. The asynchronous service keeps trying to post messages in an exponential pattern. At first we post frequently and then we try to post at longer intervals. In the case of internal error of Dynamics 365 for Customer Engagement application, message posting will not be attempted. In the case of an external service bus or network error, the associated system job will be in the “wait” state. rity45 \l