Freigeben über


Listener für eine Microsoft Azure-Lösung schreiben

 

Veröffentlicht: November 2016

Gilt für: Dynamics CRM 2015

In diesem Thema wird beschrieben, wie Sie einen Listener schreiben, der Microsoft Dynamics CRM 2015-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

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. Wenn Sie einen Warteschlangenlistener schreiben, ist es wichtig, jede einzelne Nachrichtenkopfaktion zu überprüfen, um zu bestimmen, ob die Meldung von Microsoft Dynamics 365 stammt.

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:Warteschlangen, Themen und Abonnements

Wichtig

Persistente Warteschlangen und Themen werden unterstützt. Nachrichtenpufferwarteschlangen werden nicht unterstützt. Um diese Verträge zu verwenden, müssen Ihre Listener-Anwendungen mithilfe der SDK Azure-Version 1.7 oder 1.8 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.

Nachrichtenpufferlistener aktualisieren, um persistente Warteschlangen zu verwenden

Im folgenden Verfahren werden die allgemeinen Schritte aufgeführt, die Sie ausführen, um eine Listener-Anwendung, die Nachricht aus einem Nachrichtenpuffer abruft, auf eine Listener-Anwendung zu aktualisieren, die Nachricht aus einer persistenten Warteschlange empfängt.

  1. Erstellen Sie auf dem Microsoft Azure-Portal und in derselben Lösung eine Warteschlange im gleichen Pfad, der auch für den Nachrichtenpuffer verwendet wurde.

  2. Installieren Sie die Microsoft Azure-SDK-Version 1.7 oder 1.8 auf dem Entwicklungscomputer.

  3. Aktualisieren Sie den Listenercode, indem Sie die verknüpften Klassen und die Methoden des Nachrichtenpuffers entfernen, und ersetzen Sie sie anschließend mit QueueClient und Empfangen. Stellen Sie sicher, dass Sie den gewünschten LesemodusRetrieveAndDelete oder das gewünschte PeekLock verwenden. Weitere Informationen zum Lesen von Nachrichten in einer Warteschlange finden Sie unter Warteschlangen, Themen und Abonnements.

  4. Erstellen Sie die Listener-Anwendung.

Keinerlei Microsoft Dynamics 365-Konfigurationsänderungen sind erforderlich, wenn der Warteschlangenendpunkt denselben Lösungspfad wie der Nachrichtenpuffer verwendet.

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 CRM 2015 und CRM Online gesendet wird, hinzugefügt wird. Der Eigenschaftenbehälter, der mit den Endpunkten persistenter Warteschlangen und Themenverträgen verfügbar ist, enthält die folgenden Informationen.

  • Organisation Url

  • 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. Ihr Listenercode kann auf Grundlage dieser Informationen wählen, dass eine empfangene Meldung verarbeitet wird.Weitere Informationen:Beispiel: Ausführen mehrerer Anforderungen

Siehe auch

Azure-Erweiterungen für Microsoft Dynamics CRM 2015
Schreiben eines benutzerdefinierten Azure-Plug-Ins
Beispiel: Persistenter Warteschlangenlistener
Beispiel: Eindirektionaler Listener
Beispiel: Bidirektionaler Listener
Beispiel: REST-Listener
Senden von Microsoft Dynamics CRM 2015-Daten über den Azure Service Bus

© 2017 Microsoft. Alle Rechte vorbehalten. Copyright