Freigeben über

Schreiben einer Listener-Anwendung für eine Microsoft Azure-Lösung

  • Artikel

 

Veröffentlicht: Januar 2017

Gilt für: Dynamics 365 (online), Dynamics 365 (on-premises), Dynamics CRM 2016, Dynamics CRM Online

In diesem Thema wird beschrieben, wie Sie eine Microsoft Azure-Lösungslisteneranwendung schreiben, die Microsoft Dynamics 365-Nachrichten lesen und verarbeiten kann, die für Microsoft Azure Service Bus veröffentlicht werden. Sie sollten sich zunächst damit vertraut machen, wie Sie einen Microsoft Azure Service Bus-Listener schreiben, bevor Sie sich den Besonderheiten eines Microsoft Dynamics 365-Listeners zuwenden. Weitere Informationen bietet die Dokumentation zu Azure Service Bus und der Beispielcode.

In diesem Thema

Warteschlangenlistener schreiben

Unidirektionalen, bidirektionalen oder REST-Listener schreiben

Nachrichten filtern

Lesen Sie den Datenkontext in mehreren Formaten

Warteschlangenlistener schreiben

Eine Nachrichtenwarteschlange ist eine Sammlung von Nachrichten, die an einem Servicebusendpunkt empfangen wurden. Ein Warteschlangenlistener ist eine Anwendung, die diese Nachrichten in der Warteschlange liest und verarbeitet. Da die Servicebusnachrichten in einer Warteschlange gespeichert werden, muss ein Listener nicht aktiv lauschen, damit Nachrichten in einer Warteschlange empfangen werden können. Ein Warteschlangenlistener kann gestartet werden, nachdem die Nachrichten in der Warteschlange angekommen sind und diese Nachrichten dennoch verarbeiten. Andere im nächsten Abschnitt behandelte Listener müssen aktiv lauschen, oder sie verpassen die Gelegenheit, die Nachricht zu lesen. Diese Meldungen können von Microsoft Dynamics 365 oder einer anderen Quelle stammen.

Wichtig

Wenn Sie einen Warteschlangenlistener schreiben, überprüfen Sie jede einzelne Nachrichtenkopfaktion, um zu bestimmen, ob die Meldung von Microsoft Dynamics 365 stammt. Informationen dazu finden Sie unter Nachrichten filtern.

Mit Empfangen im Modus ReceiveAndDelete können Sie eine Nachricht destruktiv lesen. Dabei wird die Nachricht gelesen und aus der Warteschlange entfernt. Im Modus PeekLock können Sie eine Nachricht auch nicht destruktiv lesen. In diesem Fall wird die Nachricht zwar gelesen, bleibt jedoch in der Warteschlange verfügbar. Der in diesem SDK bereitgestellte Beispielcode des persistenten Warteschlangenlisteners führt einen destruktiven Lesevorgang durch. Weitere Informationen zum Lesen von Nachrichten in einer Warteschlange finden Sie unter How to Receive Messages from a Queue (in englischer Sprache).

Ein Thema ähnelt einer Warteschlange, aber implementiert eine Veröffentlichungs-/Abonnementmodell. Mindestens ein Listener kann ein Thema abonnieren und Nachrichten aus seiner Warteschlange empfangen.Weitere Informationen:Warteschlanglen, Themen und Abonnements

Wichtig

Um diese Warteschlangen oder Themen zu verwenden, müssen Ihre Listener-Anwendungen mithilfe der SDK Azure-Version 1.7 oder höher schreiben.

Die Verwendung von Warteschlangen und Themen in Ihrem Multisystem-Software-Entwurf kann zu einem Entkoppeln von Systemen führen. Wenn die Listener-Anwendung ggf. überhaupt nicht verfügbar ist, findet die Nachrichtenzustellung aus Microsoft Dynamics 365 dennoch statt. Die Listener-Anwendung kann mit der Verarbeitung der Warteschlangennachricht fortfahren, wenn sie wieder online ist.Weitere Informationen:Warteschlangen, Themen und Abonnements

Unidirektionalen, bidirektionalen oder REST-Listener schreiben

Neben den zuvor beschriebenen Warteschlangenlistener können Sie einen Listener für drei weitere Servicebusverträge schreiben, die von Microsoft Dynamics 365 wie folgt unterstützt werden: unidirektional, bidirektional und REST . Ein unidirektionaler Listener kann eine vom Servicebus veröffentlichte Meldung lesen und verarbeiten. Ein bidirektionaler Listener kann das ebenso, kann aber auch eine Zeichenfolge mit einigen Informationen an Dynamics 365 zurückgeben. Ein REST-Listener ist dasselbe wie der bidirektionale Listener, außer dass er mit einem REST-Endpunkt arbeitet. Beachten Sie, dass diese Listener an einem Dienstendpunkt aktiv lauschen müssen, um eine Meldung zu lesen, die über den Servicebus gesendet wurde. Wenn der Listener nicht lauscht, wenn Microsoft Dynamics 365 versucht, eine Meldung auf dem Servicebus bereitzustellen, wird die Nachricht nicht gesendet.

Das Schreiben eines Listeners strukturiert sich in Aktionen, die unter dem Begriff "ABC" zusammengefasst werden: Adresse, Bindung, Vertrag (engl. Contract). Die folgenden Informationen identifizieren die ABCs eines unidirektionalen Listeners.

Nachdem der Listener bei einem Endpunkt registriert ist, wird die Execute-Methode des Listeners aufgerufen, wenn von Microsoft Dynamics 365 eine Meldung auf dem Servicebus bereitgestellt wird. Die Execute-Methode gibt keine Daten vom Methodenaufruf zurück. Weitere Informationen bietet das unidirektionale Listenerbeispiel unter Beispiel: Eindirektionaler Listener.

Ein bidirektionaler Listener ist in ähnlicher Weise codiert als ein unidirektionaler Listener. Die ABCs eines bidirektionalen Listeners lauten wie folgt:

Für diesen bidirektionalen Vertrag gibt die Execute-Methode eine Zeichenfolge aus dem Methodenaufruf zurück. Weitere Informationen bietet das bidirektionale Listenerbeispiel unter Beispiel: Bidirektionaler Listener.

Ein REST-Listener ist in ähnlicher Weise codiert als ein bidirektionaler Listener. Die ABCs eines REST-Listeners lauten wie folgt:

Für den REST-Vertrag gibt die Execute-Methode eine Zeichenfolge aus dem Methodenaufruf zurück. Weitere Informationen bietet das REST-Listenerbeispiel unter Beispiel: REST-Listener. Beachten Sie, dass im REST-Listenerbeispiel ein WebServiceHost instanziiert wird und kein ServiceHost wie im bidirektionalen Beispiel.

Hinweis

Falls das vordefinierte (ServiceBusPlugin) Plug-In mit einem bidirektionalen Listener oder REST-Listener verwendet wird, verwendet das Plug-In keine vom Listener zurückgegebene Zeichenfolgendaten. Ein benutzerdefiniertes Azure- bewusstes Plug-In kann jedoch diese Informationen nutzen.

Wenn Sie die Listenerbeispiele ausführen, werden Sie aufgefordert, als Ausstellergeheimnis den Microsoft Azure Service Bus-Verwaltungsschlüssel anzugeben. Die WS2007 Federation HTTP-Bindungs verwendet den "Token"-Modus und das WS-Trust 1.3-Protokoll.

Nachrichten filtern

Es gibt einen Eigenschaftenbehälter mit zusätzlichen Informationen, der zu jeder Brokernachricht-Eigenschaft, die von Microsoft Dynamics 365 und Dynamics 365 (online) gesendet wird, hinzugefügt wird. Der Eigenschaftenbehälter, der mit den Endpunkten von Warteschlangen, Weiterleitungen und Themenverträgen verfügbar ist, enthält die folgenden Informationen:

  • Organisation URI

  • ID des aufrufenden Benutzers

  • ID des initialisierenden Benutzers

  • Logischer Entitätsname

  • Anforderungsname

Diese Informationen identifizieren die Organisation, den Benutzer, die Entität und die von Microsoft Dynamics 365 verarbeitete Nachrichtenanforderung für die Bereitstellung der Servicebusnachricht. Die Verfügbarkeit dieser Eigenschaften zeigt an, dass die Mitteilung von Microsoft Dynamics 365 gesendet wurde. Ihr Listener kann entscheiden, wie Mitteilung basierend auf dieser Werte verarbeitet werden.

Lesen Sie den Datenkontext in mehreren Formaten

Der Datenkontext der aktuellen Microsoft Dynamics 365-Operation wird Ihrer Azure-Lösungslisteneranwendung im Textkörper einer Service-Busmitteilung weitergeleitet. In den vorhergehenden Versionen wurde nur ein binäres .NET-Format unterstützt. Für plattformübergreifende (nicht .NET) Interoperabilität können Sie jetzt eins von drei Datenformaten für den Nachrichtentextkörper angeben: binär .NET, JSON oder XML. Dieses Format wird im MessageFormat-Attribut der ServiceEndpoint-Entität angegeben.

Hinweis

Diese Funktion wurde mit CRM Online 2016-Update 1 und CRM 2016 Service Pack 1 (lokal) eingeführt.

Wenn sie Mitteilungen empfängt, kann Ihre Listeneranwendung den Datenkontext im Nachrichtentextkörper basierend auf dem Inhaltstyp der Mitteilung lesen. Beispielcode dafür wird unten angezeigt.

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)));
}

Siehe auch

Azure-Erweiterungen für Microsoft Dynamics 365
Schreiben eines benutzerdefinierten Azure-Plug-Ins
Beispiel: Persistenter Warteschlangenlistener
Beispiel: Eindirektionaler Listener
Beispiel: Bidirektionaler Listener
Beispiel: REST-Listener
Arbeiten mit Dynamics 365 Daten in Ihrer Azure-Lösung
Arbeiten mit Dynamics 365-Ereignisdaten in Ihrer Azure-Ereignishub-Lösung

Microsoft Dynamics 365

© 2017 Microsoft. Alle Rechte vorbehalten. Copyright