Schreiben einer Listeneranwendung für eine Azure-Lösung

In diesem Thema wird beschrieben, wie Sie eine Azure-Lösungslisteneranwendung schreiben, die Microsoft Dataverse-Nachrichten lesen kann, die im Azure Service Bus gepostet wurden. Als Voraussetzung sollten Sie sich mit dem Schreiben eines Azure Service Bus-Listeners vertraut machen, bevor Sie versuchen, die Besonderheiten eines Dataverse-Listeners zu erlernen. Weitere Informationen finden Sie in der Azure Service Bus-Dokumentation.

Einen Warteschlangenlistener schreiben

Eine Nachrichtenwarteschlange ist ein Repository von Nachrichten, die an einem ServiceBus-Endpunkt empfangen wurden. Ein Warteschlangenlistener ist eine Anwendung, die diese in die Warteschlange gestellten Nachrichten liest und verarbeitet. Da die Servicebus-Nachrichten in einer Warteschlange gespeichert sind, muss ein Listener nicht aktiv auf Nachrichten lauschen, die in der Warteschlange empfangen werden. Ein Warteschlangenlistener kann gestartet werden, nachdem die Nachrichten in der Warteschlange angekommen sind und diese Nachrichten dennoch verarbeiten. Andere im nächsten Abschnitt besprochene Listener müssen aktiv zuhören oder sie verpassen die Möglichkeit, eine Nachricht zu lesen. Diese Nachrichten können aus Dataverse oder aus einer anderen Quelle stammen.

Sie können eine destruktive Nachricht mit dem Receive im ReceiveMode.ReceiveAndDelete-Modus lesen, bei dem die Nachricht gelesen und aus der Warteschlange entfernt wird, oder einen nicht-destruktiven Lesevorgang mit dem ReceiveMode.PeekLock-Modus durchführen, bei dem die Nachricht gelesen, aber weiterhin in der Warteschlange verfügbar ist. Weitere Informationen zum Lesen von Nachrichten aus einer Warteschlange finden Sie unter "Empfangen von Nachrichten aus einer Warteschlange".

Ein Thema ähnelt einer Warteschlange, implementiert aber ein Veröffentlichungs-/Abonnementmodell. Ein oder mehrere Listener können das Thema abonnieren und Nachrichten aus der Warteschlange empfangen. Weitere Informationen: Warteschlangen, Themen und Abonnements

Die Verwendung von Warteschlangen und Themen in Ihrem Multisystem-Softwaredesign kann zur Entkopplung von Systemen führen. Wenn die Listeneranwendung jemals nicht verfügbar ist, ist die Nachrichtenübermittlung von Dataverse weiterhin erfolgreich, und die Listeneranwendung kann die Verarbeitung der Warteschlangennachricht fortsetzen, wenn sie wieder online ist. Weitere Informationen: Warteschlangen, Themen und Abonnements

Einen unidirektionalen, bidirektionalen oder REST-Listener programmieren.

Zusätzlich zu den zuvor beschriebenen Warteschlangenlistenern können Sie einen Listener für drei andere Servicebus-Verträge schreiben, die von Dataverse unterstützt werden: unidirektionale, bidirektionale und REST-Verträge. Ein unidirektionaler Listener kann eine Nachricht lesen und verarbeiten, die an den Service Bus übermittelt wurde. Ein bidirektionaler Listener kann das ebenso, kann aber auch eine Zeichenfolge mit einigen Informationen an Dataverse zurückgeben. Ein REST-Listener ist identisch mit dem bidirektionale Listener, mit der Ausnahme, dass er mit einem REST-Endpunkt funktioniert. Beachten Sie, dass diese Listener aktiv an einem Dienstendpunkt lauschen müssen, um eine Nachricht zu lesen, die über den Servicebus gesendet wird. Wenn der Listener nicht lauscht, wenn Dataverse versucht, eine Nachricht an den Servicebus zu senden, 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).

Eindirektionaler Listener

• Adresse: Dienst-URI

• Bindung: WS2007HttpRelayBinding

• Vertrag: IServiceEndpointPlugin

Nachdem Ihr Listener bei einem Endpunkt registriert wurde, wird die Listenermethode Execute immer dann aufgerufen, wenn eine Nachricht von Dataverse in den ServiceBus gepostet wird. Die Execute Methode gibt keine Daten aus dem Methodenaufruf zurück. Weitere Informationen finden Sie im Beispiel für einen unidirektionalen Listener, Beispiel: Unidirektionaler Listener.

Zweidirektionaler Listener

• Adresse: Dienst-URI

• Bindung: WS2007HttpRelayBinding

• Vertrag: ITwoWayServiceEndpointPlugin

Für diesen bidirektionalen Vertrag gibt die Execute Methode eine Zeichenfolge aus dem Methodenaufruf zurück. Weitere Informationen finden Sie im Beispiel für den Zwei-Wege-Listener, Beispiel: Zwei-Wege-Listener.

REST-Listener

• Adresse: Dienst-URI

• Bindung: WebHttpRelayBinding

• Vertrag: IWebHttpServiceEndpointPlugin

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

Filtern von Nachrichten

Es gibt einen Eigenschaftsbehälter mit zusätzlichen Informationen zu jeder Eigenschaft der im Broker gespeicherten Nachrichten-Eigenschaften, die aus Dataverse gesendet wird. Der Eigenschaftenbehälter, der mit den Endpunkten von Warteschlangen, Weiterleitungen und Themenverträgen verfügbar ist, enthält die folgenden Informationen:

• Organisations-URI
• Aufrufen der Benutzer-ID
• Initiieren der Benutzer-ID
• Logischer Tabellenname
• Anforderungsname

Diese Informationen identifizieren die Organisation, den Benutzer, die Tabelle und die Nachrichtenanforderung, die von Dataverse verarbeitet wird, was dazu führte, dass die ServiceBus-Nachricht gepostet wurde. Die Verfügbarkeit dieser Eigenschaften gibt an, dass die Nachricht von Dataverse gesendet wurde. Ihr Listenercode kann entscheiden, wie die Nachricht basierend auf diesen Werten verarbeitet werden soll.

Lesen des Datenkontexts in mehreren Datenformaten

Der Datenkontext aus dem aktuellen Dataverse-Vorgang wird an Ihre Azure-Lösungslisteneranwendung im Textkörper einer ServiceBus-Nachricht übergeben. In früheren Versionen wurde nur ein .NET-Binärformat unterstützt. Für plattformübergreifende Interoperabilität (non-.NET) können Sie nun eines von drei Datenformaten für den Nachrichtentext angeben: .NET Binary, JSON oder XML. Dieses Format wird in der Spalte "MessageFormat " der ServiceEndpoint-Tabelle angegeben.

Beim Empfangen von Nachrichten kann Ihre Listeneranwendung den Datenkontext im Nachrichtentext basierend auf dem Inhaltstyp der Nachricht lesen, wie im Codebeispiel gezeigt.

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
Schreiben eines benutzerdefinierten Azure-fähigen Plug-Ins
Beispiel: Einweg-Hörer
Beispiel: Bidirektionaler Listener
Beispiel: REST-Listener
Mit Dataverse-Daten in Ihrer Azure-Lösung arbeiten
Arbeiten mit Dataverse-Ereignisdaten in Ihrer Azure Event Hub-Lösung