Freigeben über

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

  • Artikel

Dieses Thema beschreibt, wie Sie eine Listener-Anwendung für eine Azure-Lösung schreiben, die Microsoft Dataverse-Nachrichten lesen und verarbeiten kann, die an den Azure Service Bus gepostet werden. 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 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 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.

Mit Empfangen im Modus ReceiveMode.ReceiveAndDelete können Sie eine Nachricht destruktiv lesen. Dabei wird die Nachricht gelesen und aus der Warteschlange entfernt. Im Modus ReceiveMode.PeekLock wird eine Nachricht nicht destruktiv gelesen. In diesem Fall wird die Nachricht zwar gelesen, bleibt jedoch in der Warteschlange verfügbar. 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. Wenn die Listener-Anwendung ggf. nicht verfügbar ist, findet die Nachrichtenzustellung aus Dataverse 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

Zusätzlich zu dem zuvor beschriebenen Warteschlangen-Listener können Sie einen Listener für drei andere Service-Bus-Verträge schreiben, die von Dataverse unterstützt werden: Einweg, Zweiweg 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

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

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

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

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-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

Es gibt einen Eigenschaftsbehälter mit zusätzlichen Informationen zu jeder Eigenschaft der im Broker gespeicherten Nachrichteneigenschaften, 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
  • 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.

Wenn sie Mitteilungen empfängt, kann Ihre Listeneranwendung den Datenkontext im Nachrichtentextkörper basierend auf dem contentType 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
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

Hinweis

Können Sie uns Ihre Präferenzen für die Dokumentationssprache mitteilen? Nehmen Sie an einer kurzen Umfrage teil. (Beachten Sie, dass diese Umfrage auf Englisch ist.)

Die Umfrage dauert etwa sieben Minuten. Es werden keine personenbezogenen Daten erhoben. (Datenschutzbestimmungen).