From step 1 to step 6, we created an Azure service bus, a queue, and a shared access policy. Throughout the process, ensure that the names are generic but that they make sense in your context. In step 3, ensure that the pricing tier capabilities meets your non-functional requirements.

In step 7, the Send claim is necessary for one-way communication.

In step 9 to step 13, we registered the endpoint in our Dynamics 365 instance and registered a step to pass the context when an account name is updated. In step 11, the default message format is .NET binary, which works well if your consumer is a .NET application capable of reading a .NET binary object. For consumers written in other languages (JAVA, Python, or any other language that can connect to an Azure Service Bus), change the value to the more universal JSON or XML options.

In step 13, we registered the step as Asynchronous, which is the only possible option. If you try to register your step as synchronous, you will receive the following error:

Behind the scenes, Dynamics 365 has an internal plug-in named ServiceBusPlugin that sends the plugin context as RemotePluginContext when the Account Name attribute is updated. The context will sit in the Azure Service Bus queue and wait until it is consumed. We'll cover a consumer example code in Consuming messages from an Azure Service Bus later in this chapter.