Een listenertoepassing schrijven voor een Microsoft Azure-oplossing
Gepubliceerd: januari 2017
Is van toepassing op: Dynamics 365 (online), Dynamics 365 (on-premises), Dynamics CRM 2016, Dynamics CRM Online
In dit onderwerp wordt beschreven hoe u een listenertoepassing voor een Microsoft Azure-oplossing schrijft die Microsoft Dynamics 365-berichten kan lezen en verwerken die zijn geplaatst op de Microsoft Azure Service Bus. U moet als voorwaarde wel leren hoe u een Microsoft Azure Service Bus listener schrijft voordat u de details over een Microsoft Dynamics 365 listener probeert te begrijpen. Zie de Azure Service Bus-documentatie voor meer informatie.
In dit onderwerp
Een wachtrijlistener schrijven
Schrijf listener in één of twee richtingen of een REST-listener
Berichten filteren
Lees de gegevenscontext in verschillende gegevensindelingen
Een wachtrijlistener schrijven
Een berichtenwachtrij is een wachtplaats voor berichten die bij een eindpunt van een servicebus zijn ontvangen. Een wachtrijlistener is een toepassing die deze berichten in de wachtrij leest en verwerkt. Aangezien de servicebusberichten worden opgeslagen in een wachtrij, moet een listener niet actief luisteren om berichten in de wachtrij te ontvangen. Een wachtrijlistener kan worden gestart nadat berichten zijn aangekomen in de wachtrij en deze berichten nog steeds verwerkt. Andere types listeners die in de volgende sectie worden besproken, moeten actief luisteren of missen de kans om een bericht te lezen. Deze berichten kunnen voortkomen uit Microsoft Dynamics 365 of uit een andere bron. .
Belangrijk
Let er bij het schrijven van een wachtrijlistener op dat elke berichtkopactie wordt gecontroleerd om te bepalen of het bericht afkomstig is van Microsoft Dynamics 365. Voor uitleg over hoe u dit kunt doen, zie Berichten filteren.
U kunt een bericht vernietigend lezen met behulp van Ontvangen in de modus ReceiveAndDelete, waarbij het bericht wordt gelezen en verwijderd uit de wachtrij, of het bericht niet-destructief lezen met behulp van de modus PeekLock, waarbij het bericht wordt gelezen maar nog steeds beschikbaar is in de wachtrij. De voorbeeldcode van de continue wachtrijlistener in deze SDK voert een vernietigende lezing uit. Voor meer informatie over het lezen van berichten uit een wachtrij, zie Berichten ontvangen uit een wachtrij.
Een onderwerp is vergelijkbaar met een wachtrij maar implementeert een model voor publiceren/aanmelden. Een of meer listeners kunnen zich aanmelden bij het onderwerp en ontvangen berichten uit de wachtrij.Meer informatie:Wachtrijen, Onderwerpen en Abonnementen
Belangrijk
Om deze wachtrij- of onderwerpcontracten te gebruiken, moet u uw listenertoepassingen schrijven met behulp van Azure SDK versie 1.7 of hoger.
Het gebruik van wachtrijen en onderwerpen in uw ontwerp van multisysteemsoftware kan leiden tot het loskoppelen van systemen. Als de listenertoepassing ooit niet beschikbaar is, loopt de berichtlevering van Microsoft Dynamics 365 nog steeds door en kan de listenertoepassing het wachtrijbericht blijven verwerken wanneer deze weer online is.Meer informatie:Wachtrijen, Onderwerpen en Abonnementen
Schrijf listener in één of twee richtingen of een REST-listener
Naast de eerder beschreven wachtrijlistener, kunt u een listener schrijven voor drie andere servicebuscontracten die door Microsoft Dynamics 365 worden ondersteund: unidirectioneel, bidirectioneel, en REST. Een unidirectionele listener kan een bericht lezen en verwerken dat op de servicebus werd geplaatst. Een bidirectionele listener kan hetzelfde doen, maar kan ook een tekenreeks met informatie terugsturen naar Dynamics 365. Een REST listener is hetzelfde als de bidirectionele listener behalve dat deze werkt met een REST eindpunt. Houd er rekening mee dat deze listeners actief moeten luisteren op een service-eindpunt om een bericht te lezen dat over de servicebus wordt verzonden. Als de listener niet luistert wanneer Microsoft Dynamics 365 probeert om een bericht op de servicebus te plaatsen, wordt het bericht niet verzonden.
Het schrijven van een listener wordt gestructureerd rond wat gekend staat als ABC: adres, binding en contract. De volgende informatie identificeert de ABC's van een unidirectionele listener.
Adres: service URI
Binding: WS2007HttpRelayBinding
Contract: IServiceEndpointPlugin
Nadat uw listener bij een eindpunt is geregistreerd, wordt de Execute methode van de listener opgeroepen wanneer een bericht wordt geplaatst op de servicebus, afkomstig van Microsoft Dynamics 365. De Execute-methode retourneert geen gegevens van de methodeoproep. Voor meer informatie, zie het voorbeeld van een unidirectionele listener, Voorbeeld: Unidirectionele listener.
Een bidirectionele listener wordt op een gelijkaardige manier gecodeerd als een unidirectionele listener. De ABC's van een bidirectionele listener zijn als volgt:
Adres: service URI
Binding: WS2007HttpRelayBinding
Contract: ITwoWayServiceEndpointPlugin
Voor dit bidirectionele contract retourneert de methode Uitvoeren een rekenreeks van de methodeaanroep. Voor meer informatie, zie het voorbeeld van een bidirectionele listener, Voorbeeld: Tweerichtingslistener.
Een REST listener wordt op een gelijkaardige manier gecodeerd als een bidirectionele listener. De ABC's van een REST listener zijn als volgt:
Adres: service URI
Binding: WebHttpRelayBinding
Contract: IWebHttpServiceEndpointPlugin
Voor het REST contract retourneert de Execute methode een rekenreeks van de methodeoproep. Raadpleeg het REST listenervoorbeeld, Voorbeeld: REST-listener voor meer informatie. Merk op dat er in het REST listenervoorbeeld een exemplaar wordt gemaakt van WebServiceHost en niet van ServiceHost zoals in het voorbeeld met de bidirectionele listener.
Notitie
Als u de gebruiksklare (ServiceBusPlugin) plug-in met een bidirectionele of REST listener gebruikt, gebruikt de plug-in geen tekenreeksgegevens die de listener retourneert. Echter, een aangepaste Azure-bewuste invoegtoepassing kan deze informatie gebruiken.
Als u de listenervoorbeelden uitvoert, is het uitgeversgeheim waar u om wordt gevraagd de Microsoft Azure Service Bus beheersleutel. De WS2007 Federation HTTP binding gebruikt de "token"-modus en het WS-Trust 1.3 protocol.
Berichten filteren
Er wordt een eigenschappenverzameling met aanvullende informatie toegevoegd aan alle geregelde berichteigenschappen die worden verzonden vanuit Microsoft Dynamics 365 en Dynamics 365 (online). De eigenschappenverzameling, beschikbaar met wachtrij-, relais- en onderwerpcontracteindpunten, bevat de volgende informatie:
Organisatie URI
Gebruiker-id aanroepen
Gebruikers-id initiëren
Logische naam entiteit
Aanvraagnaam
Deze informatie identificeert de organisatie, de gebruiker, de entiteit, en de berichtaanvraag die wordt verwerkt door Microsoft Dynamics 365 wat ertoe leidde dat het servicebusbericht werd geplaatst. De beschikbaarheid van deze eigenschappen duidt erop dat het bericht is verzonden van Microsoft Dynamics 365. Uw listenercode kan bepalen hoe die het bericht moet worden verwerkt, op basis van deze waarden.
Lees de gegevenscontext in verschillende gegevensindelingen
De gegevenscontext van de huidige Microsoft Dynamics 365-bewerking wordt doorgegeven aan de listenertoepassing van uw Azure-oplossing in de tekst van een servicebusbericht. In voorgaande versies werd alleen een binaire indeling van .NET ondersteund. Voor platformoverschrijdende (niet-.NET) interoperabiliteit kunt u nu een van de volgende drie gegevensindelingen voor de berichttekst opgeven: .NET binair, JSON of XML. Deze indeling is opgegeven in het kenmerk MessageFormat van de entiteit ServiceEndpoint.
Notitie
Deze functie werd geïntroduceerd in update 1 van CRM Online 2016 en in CRM 2016 Service Pack 1 (on-premises).
Bij de ontvangst van berichten kan uw listenertoepassing de gegevenscontext in de berichttekst lezen op basis van het inhoudstype van het bericht. Voorbeeldcode hiervoor wordt hieronder gegeven.
var receivedMessage = inboundQueueClient.Receive(TimeSpan.MaxValue);
if (receivedMessage.ContentType = "application/msbin1")
{
RemoteExecutionContext context = receivedMessage.GetBody<RemoteExecutionContext>();
}
else if (receivedMessage.ContentType = "application/json")
{
//string jsonBody = new StreamReader(receivedMessage.GetBody<Stream>(), Encoding.UTF8).ReadToEnd();
RemoteExecutionContext contextFromJSON = receivedMessage.GetBody<RemoteExecutionContext>(
new DataContractJsonSerializer(typeof(RemoteExecutionContext)));
}
else if (receivedMessage.ContentType = "application/xml")
{
//string xmlBody = new StreamReader(receivedMessage.GetBody<Stream>(), Encoding.UTF8).ReadToEnd();
RemoteExecutionContext contextFromXML = receivedMessage.GetBody<RemoteExecutionContext>(
new DataContractSerializer(typeof(RemoteExecutionContext)));
}
Zie ook
Azure-extensies voor Microsoft Dynamics 365
Een aangepaste Azure-bewuste invoegtoepassing schrijven
Voorbeeld: persistente wachtrijlistener
Voorbeeld: Unidirectionele listener
Voorbeeld: Tweerichtingslistener
Voorbeeld: REST-listener
Werken met Dynamics 365-gegevens in uw Azure-oplossing
Werken met Dynamics 365-gebeurtenisgegevens in uw Azure Event Hub-oplossing
Microsoft Dynamics 365
© 2017 Microsoft. Alle rechten voorbehouden. Auteursrecht