Using Dynamic 365 Service Endpoints - Part 2

In the previous post, we discussed using Service Endpoints and how they can be used to integrate with other systems via a Azure Service Bus Queue.

There are other ways that Service Points can be used for integrating with other systems.

1. Topic

Integrating with a Topic is very similar to integrating with a Queue, except that multiple systems can consume the same message.

Let's say we wanted to integrate with our customer's Audit service and a third party system, then we would use a Topic to ensure that both systems would get the messages


2. One-Way Listener

This requires an active listener.If there is no active listener on an endpoint, the post to the service bus fails. Dynamics 365 will retry the post in exponentially larger and larger time spans until the asynchronous system job that is posting the request is eventually aborted and its status is set to Failed

The utility of this is beyond me given that the operation will always succeed in Dynamics due to endpoint steps requiring to be asynchronous. I might be misunderstanding how this works though.

A sample can be found here


3. Two-Way Listener

A two-way contract is similar to a one-way contract except that a string value can be returned from the listener to the plug-in or custom workflow activity that initiated the post.

This seems like a more interesting proposition as the other system can send information back to Dynamics 365, e.g. return the result of a calculation

A sample can be found here


4. REST Listener

A REST contract is similar to a two-way contract on a REST endpoint.

A sample can be found here


5. Event Hub

This contract type applies to Azure Event Hub solutions.

Using Dynamic 365 Service Endpoints - Part 1

Dynamics 365 offers various possibilities for integrating with 3^rd party systems, one of them is using a Service Endpoint, which is a fancy way of calling the Azure Service Bus, which can be used for integrating with 3^rd party systems.

In reality things are a bit more complicated and will be discussed in a future post.

In this example we will create a Service Bus queue that will receive any new Search Engines so that these can be processed by a single 3^rd party system.

1. Create Azure Service Bus Queue

From the Azure Portal

1. Create a Namespace




2. Create a Queue




3. Add SAS Policy

2. Register Service Endpoint

In order to register a Service Endpoint we will need the connection details for the Queue, which can be obtained from the Azure Portal.

1. Register New Endpoint




2. Add Connection Details




3. Complete Registration



The Message Format is important as the code needed to read the messages will be different depending on the format.











Register New Step


Bear in mind that it needs to be registered against the service endpoint itself.



This is what we've ended up with

3. Test

We create a new Search Engine



We can see that the message has been sent on Azure Portal



4. Processing Queue Messages

The code used to process the Queue messages can be found here and the full VS Solution can be found here.

Some of the code has been pilfered from the CRM Samples and updated it to work with the latest version, at the time of writing of Azure Service Bus.

The verbosity of the messages is peculiar and it would be nice to be able to do something similar to plug-in  (Pre/Pro)EntityImages, namely just send a few parameters.

In this highly contrived exampled we might just need to send two parameters (name and url) to our 3_rd party system, yet ~ 5 KB of data are sent.