Navigate to the new Azure portal and sign in with your subscription administrator account.Setup Azure Event Hub Namespace and Event Hub in the New Azure Portal Below I have outlined the process in using the new Azure portal as Service Bus management has recently launched in preview to create an Event Hubs Namespace, Event Hub, then Register it with CRM and validate everything works with Service Bus Explorer. MSDN has provided a walkthrough with the classic Azure portal using a queue. Using JSON will cut the message size in nearly half from the same XML message. Another improvement is you can have the message format of the data context sent in XML and also now JSON. Also with this release support has now been added for all of the Azure Service Bus types Queues, Topics and now Event Hubs.
#CRM 2016 DOWNLOAD UPDATE#
With Dynamics CRM 2016 Spring Update this process has become extremely easy with the support for the modern authentication, Shared Access Signatures (SAS). You had to weave through a number of steps to get it all setup and it was prone to errors. Previously using the Azure Service Bus was more complex as the integration relied on the old (now deprecated) Azure ACS functionality. Over the next few blog posts I will explore some of the use cases I have and are looking to use the service bus with, items like near real-time integrations, ADXStudio cache invalidations, search indexes, and more. You need to have the right use case for using the service endpoint though, and choosing which type of Azure Service Bus to send it to will also depend on what your use case is. If we can offload some of that logic processing elsewhere then we can improve the overall performance of the CRM system. So why would you want to send this to a service endpoint like the Azure Service Bus? Often the CRM asynchronous service is over taxed it is responsible for so much in the CRM system now. I have posted a sample contact create data context in JSON here so you can get an idea of all the data it contains as well as its format. It is the same data context that you work with when building a plugin so it also will contain your input parameters, pre and post images, the execution depth, the entity logical name, and what CRM message is being executed (create, update, delete, etc.).
Things like a newly created contact ID, the created by system user ID, any option sets that had a default value, and a lot more. So if you were to create a contact with first name and last name, the data context would contain that data as well as any other default data as part of the create itself. The data context contains all of the business data that is processed as part of the CRM message. An often forgotten feature is its ability to notify a service endpoint with the data context of the particular CRM message that it is registered on. You should also be aware that CrmSvcUtil.exe version 8.0.0.0 has additional assembly dependencies.CRM developers and even end users know of the asynchronous service in CRM the service is usually associated with workflow processes or plugins. Don't forget to also replace the assemblies and CrmSvcUtil.exe in the Files folder of the WiX Installer Project with the version 7.0.0.0 or version 8.0.0.0 files. There is also somewhere in the code, I can't remember exactly where, that explicitly references Microsoft.IdentityModel types, which have to be changed to System.IdentityModel types. That means that you have to use Reflexil to remove the Microsoft.IdentityModel reference and add the System.IdentityModel reference. But note that version 8.0.0.0 references System.IdentityModel and not Microsoft.Identity if you're going to change the versions to 8.0.0.0. If you want, you can use Reflexil to change the version of the Dynamics CRM assemblies that are referenced (it is just and ) to version 7.0.0.0 or 8.0.0.0. I also changed it to work with the 8.0.0.0 assemblies and CrmSvcUtil.exe, but discovered that the version 8.0.0.0 CrmSvcUtil.exe requires the ConnectionString, either in the or as a command line parameter.
#CRM 2016 DOWNLOAD CODE#
I believe that my own CrmSvcUtil.exe Code Generation Extension is better - the one I refer to in this blog. I actually did change it to use the version 7.0.0.0 assemblies and CrmSvcUtil.exe to test the Code Generation Extension using .dll, but I wasn't impressed with the resulting Entities.cs. I have deliberately left the version 6.0.0.0 Dynamics CRM assemblies and CrmSvcUtil.exe in, as I did not see a benefit to changing them to version 7.0.0.0 or version 8.0.0.0.