Breaking news from around the world
Get the Bing + MSN extension
Choose your path Increase your proficiency with the Dynamics 365 applications that you already use and learn more about the apps that interest you. Up your game with a learning path tailored to today's Dynamics 365 masterminds and designed to prepare you for industry-recognized Microsoft certifications.
Visit Microsoft Learn
2019 release wave 2 Discover the latest updates and new features to Dynamics 365 planned through March 2020
Release overview guides and videos Release Plan | View virtual launch event
Ace your Dynamics 365 deployment with packaged services delivered by expert consultants. | Explore service offerings
Connect with the ISV success team on the latest roadmap, developer tool for AppSource certification, and ISV community engagements | ISV self-service portal
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Program | Finance TechTalks | Customer Engagement TechTalks | Talent TechTalks | Upcoming TechTalks
I've done this: https://docs.microsoft.com/en-us/dynamics365/customer-engagement/developer/walkthrough-configure-azure-sas-integration and registered a create custom entity step against it. (the invisible out-of-the-box plugin)
Now, assuming I can write an Azure listener, it seems there needs to be more than just the program. All that information that I entered to register the Azure Service Bus endpoint needs to be known to the listener so that it knows where to listen. The CRM documentation falls short of walking one through to the end of deploying the listener.
Anyone's guidance would be greatly appreciated.
This walkthrough explains how to register an Azure-aware Plugin using the Plugin Registration Tool.
If you plan to use any other Azure messaging entity other than a queue, for example a relay, there must be a listener application actively listening to the specified solution endpoint for Dynamics 365 for Customer Engagement to successfully post to the Azure Service Bus. This article explains how to write a listener application for a Azure solution.
In fact one of those articles is the same one I posted. I’m looking for the article on how to publish, deploy and activate a listener on the other side of the Azure Bus Endpoint.
In the listener project one downloads from github, the code has a main() method where a command-line, console app allows the investigator to type in the security pieces for the Service Bus Endpoint. No where does it describe how to configure a real listener to work WITHOUT this human intervention.
I found this https://ansrikanth.com/2017/04/17/two-way-communication-between-crm-and-azure-service-bus/
ansrikanth fills in a bunch of details that only someone much smarter than I could get from the Microsoft documentation. I haven't had time to get to the next page but, he promises to answer the questions about activating the listener there...
my Azure plumber decided there was some reason to go with a queue on the endpoint rather than the virtual path. Anyway, the queue seems to want to deliver a "Message" object instead of a RemoteExecutionContext. It allows us to caste the message to an REContext but, when we do so the subsequent Microsoft.Xrm.Tooling.Connector.CrmServiceClient breaks -- it fails to make a connection.
However, if we caste it to string, the Connector works but we don't have a Context object.
Can anyone flesh out the middleware in this arrangement?
Business Applications communities