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

Artikel
09/02/2024

In diesem Thema wird beschrieben, wie eine Azure-Lösungslisteneranwendung geschrieben wird, die an Azure Service Bus gepostete Nachrichten lesen kann Microsoft Dataverse . Sie sollten sich zunächst damit vertraut machen, wie Sie einen Azure Service Bus-Listener schreiben, bevor Sie sich den Besonderheiten eines Dataverse-Listeners zuwenden. Weitere Informationen bietet die Dokumentation zu Azure Service Bus.

Einen Warteschlangenlistener schreiben

Eine Nachrichten-Warteschlange ist ein Repository für Nachrichten, die an einem Service Bus-Endpunkt empfangen werden. Ein Warteschlangenlistener ist eine Anwendung, die diese Nachrichten in der Warteschlange liest und verarbeitet. Da die Service Bus-Nachrichten in einer Warteschlange gespeichert werden, muss ein Listener nicht aktiv darauf warten, dass Nachrichten in der Warteschlange empfangen werden. Ein Warteschlangenlistener kann gestartet werden, nachdem Nachrichten in der Warteschlange eingetroffen sind, und diese Nachrichten weiterhin verarbeiten. Andere im nächsten Abschnitt besprochene Zuhörertypen müssen aktiv zuhören, sonst verpassen sie die Gelegenheit, eine Nachricht zu lesen. Diese Nachrichten können von Dataverse oder einer anderen Quelle stammen.

Wichtig

Wenn Sie einen Warteschlangen-Listener schreiben, überprüfen Sie jede einzelne Nachrichtenkopfaktion, um zu bestimmen, ob die Nachricht von Dataverse stammt. Informationen dazu finden Sie unter Filtermeldungen.

Sie können mit dem Modus Receive im Modus ReceiveMode.ReceiveAndDelete einen destruktiven Lesevorgang für Nachrichten durchführen, bei dem die Nachricht gelesen und aus der Warteschlange entfernt wird. Alternativ können Sie mit dem Modus ReceiveMode.PeekLock einen nicht destruktiven Lesevorgang durchführen, bei dem die Nachricht gelesen wird, aber weiterhin in der Warteschlange verfügbar ist. Weitere Informationen zum Lesen von Nachrichten aus einer Warteschlange finden Sie unter Wie man Nachrichten aus einer Warteschlange empfängt.

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

Um diese Warteschlangen oder Themen nutzen zu können, müssen Sie Ihre Listener-Anwendungen mit dem Azure SDK schreiben.

Die Verwendung von Warteschlangen und Themen in Ihrem Multisystem-Software-Entwurf kann zu einem Entkoppeln von Systemen führen. Sollte die Listener-Anwendung einmal nicht verfügbar sein, ist die Nachrichtenübermittlung dennoch erfolgreich und die Listener-Anwendung kann mit der Verarbeitung der Warteschlangennachricht fortfahren, wenn sie wieder online ist. Dataverse Weitere Informationen: Warteschlangen, Themen und Abonnements

Unidirektionalen, bidirektionalen oder REST-Listener schreiben

Zusätzlich zum zuvor beschriebenen Warteschlangen-Listener können Sie einen Listener für drei weitere von Dataverse unterstützte Service Bus-Verträge schreiben: unidirektional, bidirektional und REST. Ein einseitiger Listener kann eine Nachricht lesen und verarbeiten, die an den Service Bus gesendet wird. Ein bidirektionaler Listener kann das ebenso, kann aber auch eine Zeichenfolge mit einigen Informationen an Dataverse 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 aktiv an einem Service-Endpunkt lauschen müssen, um eine über den Service-Bus gesendete Nachricht zu lesen. Wenn der Listener nicht zuhört, wenn Dataverse versucht, eine Nachricht an den Service-Bus 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: Service-URI
Bindung: WS2007HttpRelayBinding
Vertrag: IServiceEndpointPlugin

Nachdem Ihr Listener bei einem Endpunkt registriert ist, wird die Execute-Methode des Listeners immer dann aufgerufen, wenn eine Nachricht von Dataverse an den Service-Bus gesendet wird. Die Execute-Methode gibt keine Daten vom Methodenaufruf zurück. Weitere Informationen finden Sie im Einweg-Listener-Beispiel, Beispiel: Einseitiger Listener.

Zweidirektionaler Listener

Adresse: Service-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: Service-URI
Bindung: WebHttpRelayBinding
Vertrag: IWebHttpServiceEndpointPlugin

Für den REST-Vertrag gibt die Methode Execute einen String aus dem Methodenaufruf zurück. Sehen Sie sich das REST-Listener-Beispiel, Beispiel: REST-Listener, für weitere Informationen. Beachten Sie, dass im Beispiel für REST-Listener ein WebServiceHost instanziiert wird und kein ServiceHost, wie im bidirektionalen Beispiel.

Hinweis

Wenn Sie das sofort einsatzbereite Plug-In „Endpunkt“ mit einem bidirektionalen oder REST-Listener verwenden, verwendet das Plug-In keine vom Listener zurückgegebenen Zeichenfolgendaten. Ein benutzerdefiniertes Azure-kompatibles Plug-In kann jedoch diese Informationen nutzen.

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

Nachrichten filtern

Zu jeder vermittelten Nachricht wird ein Eigenschaftenbehälter mit zusätzlichen Informationen hinzugefügt: Eigenschaften eigenschaft gesendet von Dataverse. Der Eigenschaftenbehälter, der mit den Endpunkten von Warteschlangen, Weiterleitungen und Themenverträgen verfügbar ist, enthält die folgenden Informationen:

Organisations-URI
ID des aufrufenden Benutzers
ID des initialisierenden Benutzers
Logischer Name der Tabelle
Anforderungsname

Diese Information identifiziert die Organisation, den Benutzer, die Tabelle und die Nachrichtenanforderung, die von Dataverse verarbeitet wird und die dazu geführt hat, dass die Service-Bus-Nachricht gesendet wurde. Die Verfügbarkeit dieser Eigenschaften zeigt an, dass die Nachricht aus Dataverse gesendet wurde. Ihr Listener kann entscheiden, wie Mitteilung basierend auf dieser Werte verarbeitet werden.

Lesen Sie den Datenkontext in mehreren Formaten

Der Datenkontext aus dem aktuellen Dataverse-Vorgang wird im Body einer Service Bus-Nachricht an Ihre Azure-Lösungs-Listener-Anwendung übergeben. 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 in der Spalte MessageFormat der ServiceEndpoint Tabelle angegeben.

Beim Empfangen von Nachrichten kann Ihre Listener-Anwendung 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-Plug-Ins
Beispiel: Eindirektionaler Listener
Beispiel: Bidirektionaler Listener
Beispiel: REST-Listener
Mit Dataverse-Daten in Ihrer Azure-Lösung arbeiten
Mit Dataverse-Ereignisdaten in Ihrer Azure Event Hub-Lösung arbeiten