Azure Service Bus-Integration

Microsoft Dataverse unterstützt die Integration in Azure. Entwickler können Plug-Ins mit Dataverse registrieren, die Laufzeitnachrichtendaten, die als Ausführungskontext bezeichnet werden, an eine oder mehrere Azure-Lösungen in der Cloud übergeben. Diese Funktion ist besonders wichtig, da Azure eine der wenigen unterstützten Lösungen für die Übermittlung des Laufzeitkontexts an externe Geschäftsanwendungen (LOB) ist.

Der Azure Service Bus bietet einen sicheren und zuverlässigen Kommunikationskanal zwischen Dataverse-Laufzeitdaten und externen cloudbasierten Line-of-Business (LOB)-Anwendungen. Diese Funktion ist besonders nützlich, um unterschiedliche Dataverse-Systeme oder andere Dataverse-Server mit Änderungen der Geschäftsdaten zu synchronisieren.

Schlüsselelemente der Verbindung

Die Schlüsselelemente, die die Verbindung zwischen Dataverse und dem Azure Service Bus implementieren, werden später beschrieben. Ein Diagramm im nächsten Abschnitt zeigt diese Elemente in Betrieb.

Datenkontext

Der Datenkontext enthält die Geschäftsdaten, die der aktuelle Dataverse-Vorgang verarbeitet. Ein Benutzer, Ein Workflow oder eine Anwendung initiiert diese Verarbeitung, wenn er einen bestimmten Dataverse-Vorgang anfordert. Die Ereignispipeline übergibt den Datenkontext an alle Plug-Ins oder benutzerdefinierten Workflowaktivitäten, die für die Ausführung in der spezifischen Anforderungs- und Tabellenkombination registriert sind, die die Pipeline derzeit verarbeitet. Der Datenkontext ist vom Typ IPluginExecutionContext, wenn er durch die Ereignisausführungspipeline geleitet wird, und vom Typ RemoteExecutionContext, wenn er an den Servicebus übergeben wird.

Der Datenkontext, der in der Message enthalten ist, die zu Azure Service Bus übergeben wird, kann zusätzlich zum binären Standard-.NET Format in XML oder JSON formatiert werden. Die Unterstützung solcher Datenformate ermöglicht plattformübergreifende Interoperabilität, bei der mit Azure gehostete Nicht-.NET-Clients Dataverse-Daten vom Service-Bus lesen können.

Weitere Informationen zu den zuvor beschriebenen Technologien finden Sie unter:

• Ereignisausführungspipeline
• Schreiben einer Listener-Anwendung für eine Microsoft Azure-Lösung.

Plug-Ins

Plug-Ins sind eine von zwei Methoden, mit denen Sie die Veröffentlichung der Nachricht initiieren können, die den Datenkontext enthält, im Azure Service Bus. Die andere Methode ist eine benutzerdefinierte Workflowaktivität. Das Dataverse-Azure-Verbindungsfeature unterstützt zwei Arten von Plug-Ins: Out-of-Box (OOB) und benutzerdefiniert. Registrieren Sie in beiden Fällen das Plug-In für die asynchrone Ausführung, um eine optimale Systemleistung zu erzielen.

Ein Azure-fähiges Standard-Plug-In (OOB) ist verfügbar. Registrieren Sie ihn bei Dataverse, indem Sie einen Dienstendpunkt mithilfe des Plug-In-Registrierungstools registrieren. Sie müssen einen Plugin-„Schritt“ in der Ereignis-Ausführungspipeline registrieren, der die Kombination aus Nachricht und Tabelle identifiziert, die das Plugin zur Ausführung und Durchführung der Posting-Benachrichtigung auslöst. Wenn das Plug-In ausgeführt wird, informiert es den asynchronen Dienst über einen Service-Endpunkt-Benachrichtigungsdienst (IServiceEndpointNotificationService), um den aktuellen Anfragedatenkontext an den Azure Service Bus zu übertragen.

Sie können auch Ihr eigenes benutzerdefiniertes Plug-In schreiben, das Azure-fähig ist. Das benutzerdefinierte Plug-In wird in der Sandbox ausgeführt. Ein benutzerdefiniertes Plug-In kann die Übermittlung des Datenkontextes an den Service-Bus über den Benachrichtigungsdienst des Service-Endpunkts einleiten. Durch Hinzufügen von Code zum Aufrufen dieses Diensts wird das Plug-In azure-fähig.

Weitere allgemeine Informationen zu Plug-Ins finden Sie unter Schreiben eines Plug-Ins. Weitere Informationen zu Azure-fähigen Plug-Ins finden Sie unter Schreiben eines benutzerdefinierten Azure-fähigen Plug-Ins.

Benutzerdefinierte Workflowaktivitäten

Ähnlich wie bei Plug-Ins können Sie benutzerdefinierte Workflowaktivitäten schreiben, um den aktuellen Anforderungsdatenkontext mithilfe des Dienstendpunkt-Benachrichtigungsdienstes an den Azure Service Bus zu senden. Weitere Informationen finden Sie unter Workflowerweiterungen.

Asynchroner Service

Sobald der Dienstendpunktbenachrichtigungsdienst den asynchronen Dienst benachrichtigt, überträgt dieser den Datenkontext der Anforderungsnachricht, die derzeit von der Ereignisausführungspipeline an den Azure Service Bus verarbeitet wird. Jede Veröffentlichung wird durch einen Systemauftrag des asynchronen Services ausgeführt. Ein Benutzer kann den Status der einzelnen Systemaufträge mithilfe der Systemaufträge-Ansicht der Power Apps-Webanwendung anzeigen. Wählen Sie in der Webanwendung Erweiterte Einstellungen aus, um die Legacy-Oberfläche Dynamics 365 anzuzeigen. Wählen Sie Einstellungen>Systemaufträge.

Weitere Informationen über den asynchronen Dienst finden Sie unter Asynchroner Dienst.

Microsoft Azure Service Bus

Der Service-Bus verteilt den Anforderungsmeldungs-Datenkontext zwischen Dataverse und Azure Service Bus-Lösungs-Listener-Anwendungen. Der Service-Bus bietet auch Datensicherheit, damit nur autorisierte Anwendungen auf die geposteten Dataverse Daten zugreifen können. Die Autorisierung von Dataverse zum Bereitstellen des Datenkontexts an den Servicebus und für Listeneranwendungen zum Lesen wird von Azure Shared Access Signatures (SAS) verwaltet.

Weitere Informationen über den Service Bus finden Sie unter Service Bus. Weitere Informationen zur Service Bus-Authentifizierung finden Sie unter: Service Bus-Authentifizierung und -Autorisierung.

Microsoft Azure-Lösung

Damit die Dataverse- und Azure-Verbindung funktioniert, muss ein Azure Service Bus-Lösungskonto mindestens eine Lösung enthalten, und diese Lösung muss mindestens einen Dienstendpunkt enthalten. Bei einem Relay-Endpunkt-Vertrag muss eine Listeneranwendung, die „Dataverse-aware“ ist, aktiv auf den Endpunkt für die Dataverse-Anforderung im Service Bus lauschen. Für einen Warteschlangenendpunktvertrag muss ein Listener nicht aktiv zuhören. Sie machen einen Listener Dataverse-fähig, indem Sie ihn mit der Microsoft.Xrm.Sdk Assembly verknüpfen, sodass er den RemoteExecutionContext Typ definiert. Weitere Informationen finden Sie unter Einen Listener für eine Microsoft Azure-Lösung schreiben.

Dataverse unterstützt das Senden von Ereignisdaten an eine Azure-Ereignis-Hub-Lösung. Weitere Informationen zu Event Hubs finden Sie unter Arbeiten mit Ereignisdaten in Ihrer Azure Event Hubs-Lösung.

Dataverse-zu-Service-Bus-Szenario

In diesem Szenario werden die zuvor erwähnten Verbindungskomponenten implementiert. Konfigurieren Sie als Voraussetzung SAS so, dass Dataverse als unterstützter Aussteller erkannt wird, und konfigurieren Sie die Azure Service Bus-Lösung mit Regeln, damit Dataverse an den Endpunkt senden kann, in dem sich der Listener befindet.

Das folgende Diagramm zeigt die physischen Elemente an, die das Szenario bilden.

Die Ereignisreihenfolge in diesem Diagramm ist die folgende:

1. Registrieren Sie eine Listeneranwendung auf einem Azure Service Bus-Lösungsendpunkt. Der Listener beginnt aktiv auf den Dataverse-Remoteausführungskontext im ServiceBus zuzuhören.

2. Ein Benutzer führt einen Vorgang in Dataverse aus, der die Ausführung des registrierten OOB-Plug-Ins oder eines benutzerdefinierten Azure-fähigen Plug-Ins auslöst. Das Plug-in initiiert ein Posting des aktuellen Anfragedatenkontextes an den Service Bus durch einen asynchronen Service System Job.

3. Die von Dataverse veröffentlichten Ansprüche werden authentifiziert. Der Service-Bus leitet dann den entfernten Ausführungskontext an den Listener weiter. Der Listener verarbeitet die Kontextinformationen und führt einige geschäftliche Aufgaben mit diesen Informationen durch. Der Service Bus benachrichtigt den asynchronen Dienst über ein erfolgreiches Posting und legt den zugehörigen Systemjob auf einen abgeschlossenen Status fest.

Einrichten eines Vertrags zwischen Dataverse und einer Azure-Lösung

Für jeden Lösungsendpunkt konfigurieren Sie einen Vertrag, der die Behandlung dieser Remoteausführungskontext-"Nachrichten" im ServiceBus und die Sicherheit definiert, die der Endpunkt verwenden soll. Ein Endpunkt empfängt ServiceBus-Nachrichten mithilfe eines der hier aufgeführten unterstützten Verträge.

Warteschlange

Ein Warteschlangenvertrag bietet eine Nachrichtenwarteschlange in der Cloud. Wenn Sie einen Warteschlangenvertrag verwenden, muss ein Listener nicht aktiv auf Nachrichten auf dem Endpunkt lauschen. Für Warteschlangen gibt es destruktive und nicht-destruktive Lesevorgänge. Ein destruktiver Lesevorgang liest eine verfügbare Nachricht aus der Warteschlange, wonach die Nachricht entfernt wird. Ein nicht destruktiver Lesevorgang entfernt keine Nachricht aus der Warteschlange.

Dataverse unterstützt eine persistente Warteschlange. Beständige Warteschlangen weisen eine lange, aber begrenzte Nachrichtenverfügbarkeitsdauer auf, die Sie im Code angeben können.

Unidirektional

Ein Einwegvertrag erfordert einen aktiven Listener. Wenn an einem Endpunkt kein aktiver Listener vorhanden ist, wird die Nachricht an den Service Bus nicht zugestellt. Dataverse wiederholt den Beitrag in exponentiell größeren und größeren Zeiträumen, bis der asynchrone Systemauftrag, der die Anforderung veröffentlicht, schließlich abgebrochen wird und der Status auf "Fehlgeschlagen" festgelegt ist.

Bidirektional

Ein zweiseitiger Vertrag ist ähnlich wie ein einseitiger Vertrag, außer dass ein String-Wert vom Listener an das Dataverse-Plug-in oder die angepasste Workflow-Aktivität zurückgegeben werden kann, die den Post initiiert hat.

REST

Ein REST-Vertrag ist einem bidirektionalen Vertrag auf einem REST-Endpunkt ähnlich.

Thema

Ein Thema ähnelt einer Warteschlange, mit der Ausnahme, dass ein oder mehrere Listener den Empfang von Nachrichten aus dem Thema abonnieren können.

Event Hubs

Diese Vertragsart gilt für Azure Event Hubs-Lösungen.

Die Identifikation der Sicherheit, die ein Vertrag verwendet, ist Teil seiner Konfiguration. Ein Vertrag kann die Transportsicherheit verwenden, die Transport Layer Security (TLS) oder Secure Sockets Layer (SSL) (HTTPS) verwendet.

Die Claims-Authentifizierung wird für den sicheren Zugriff auf den Service Bus verwendet. Der für die Authentifizierung am Service Bus verwendete Claim wird in Dataverse generiert und mit dem in der Konfigurationsdatenbank Dataverse angegebenen AppFabricIssuer-Zertifikat signiert.

Verwaltung von Laufzeitfehlern

Wenn ein Fehler auftritt, nachdem eine Nachricht an den Service Bus versucht wurde, überprüfen Sie den Status des zugehörigen Systemauftrags in der Webanwendung, um weitere Informationen über den Fehler zu erhalten. Wenn der Dienstbus nicht verfügbar ist oder ein Listener oder Endpunkt nicht verfügbar ist, wird die aktuelle Nachricht, die in Dataverse verarbeitet wird, nicht an den Bus gepostet. Der asynchrone Dienst versucht weiterhin, die Nachricht in einem exponentiellen Muster zu veröffentlichen, in dem sie versucht, zuerst häufig und dann in längeren und längeren Abständen zu posten. Bei einem internen Dataverse-Fehler werden Nachrichtenübermittelungen nicht versucht. Bei einem externen Servicebus oder Netzwerkfehler befindet sich der zugehörige Systemauftrag in einem Wartezustand .