Azure-Integration
Microsoft Dataverse unterstützt die Integration in Azure. Entwickler können Plug-Ins mit Dataverse registrieren, die Laufzeit-Nachrichtendaten, die als Ausführungskontext bekannt sind, an eine oder mehrere Azure-Lösungen in der Cloud weitergeben können. Dies ist besonders wichtig, da Azure eine von zwei unterstützten Lösungen für die Kommunikation von Laufzeitkontexten ist, die in einem Plug-in an externe Geschäftsanwendungen (LOB, Line-of-Business) geliefert werden. Die andere Lösung ist die externe Kunden-Endpunkt-Zugriffskapazität von einem Plug-In, das im Sandkasten angemeldet 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 als Teil der gegenwärtigen Dataverse-Operation verarbeitet werden. Diese Verarbeitung wurde initiiert, als eine Anforderung zur Durchführung eines bestimmten Vorgangs von einem Benutzer, Workflow oder einer Anwendung an die Dynamics 365-Plattform gestellt wurde. Der Datenkontext wird an alle Plug-ins oder angepassten Workflow-Aktivitäten weitergegeben, die bei der Ereignis-Pipeline registriert sind, um die spezifische Anfrage und Tabellenkombination auszuführen, die gerade verarbeitet wird. Der Datenkontext ist vom Typ IPluginExecutionContext, wenn er entlang der Ereignis-Ausführungspipeline weitergegeben wird, und vom Typ RemoteExecutionContext, wenn er an den Service Bus gesendet 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. Dies ermöglicht plattformübergreifende Interoperabilität, bei der mit Azure gehostete Nicht-.NET-Clients-Dataverse-Daten vom Service-Bus lesen können.
Wichtig
Wenn die Größe der gesamten HTTP-Nutzlast 192 Kb überschreitet, werden die folgenden Eigenschaften entfernt:
Einige Operationen enthalten diese Eigenschaften nicht.
- Wenn die Größe der Nutzlast unter 192Kb liegt, nachdem die zusätzlichen Daten entfernt wurden, wird der vom System gesendeten BrokeredMessage eine zusätzliche
MessageMaxSizeExceeded-Eigenschaft hinzugefügt. Dadurch wird angegeben, dass einige der Daten abgeschnitten wurde. - Wenn die Größe der Nutzlast 192 Kb überschreitet, nachdem die zusätzlichen Daten entfernt wurden, wird ein Fehler generiert wird die Meldung wird nicht gesendet.
Weitere Informationen zu den zuvor beschriebenen Technologien finden Sie unter:
Plug-Ins
Plug-Ins sind eine von zwei Methoden, die angewendet werden, um die Message zu posten, die den Datenkontext zu Azure Service Bus enthält. Die andere Methode ist eine benutzerdefinierte Workflowaktivität. Es gibt zwei Typen von Plug-Ins, die durch die Dataverse-Azure-Verbindungsfunktion unterstützt werden: benutzerdefinierte und vordefinierte (OOB). In beiden Fällen wird es empfohlen, dass Sie die Plug-Ins registrieren, damit sie für beste Systemleistung asynchron ausgeführt werden.
Ein Azure-fähiges OOB-Plug-in ist mit Dataverse versehen und kann mit dem Plug-in Registration Tool registriert werden. Dieses Plug-In wird in vollständiger Vertrauensstellung mit der Dataverse-Plattform ausgeführt. 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 durchgeführt wird, benachrichtigt es den asynchronen Service durch einen Service-Endpunktmitteilungsservice (IServiceEndpointNotificationService), um den gegenwärtigen Anfragedatenkontext zu Azure Service Bus zu posten.
Sie können auch Ihr eigenes benutzerdefiniertes “Azure-fähiges” Plug-In schreiben. Das benutzerdefinierte Plug-In wird im Modus der teilweisen Vertrauenswürdigkeit in der Sandbox ausgeführt. Ein benutzerdefiniertes Plug-In kann das Posten des Datenkontext zum Service-Bus durch den Service-Endpunktbenachrichtigungsservice einleiten. Das Hinzufügen von Code zum Aufrufen dieses Dienstes macht 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 Plug-Ins können benutzerdefinierte Workflowaktivitäten geschrieben werden, um das Posten des aktuellen Anfragemessage-Datenkontexts zu Azure Service Bus zu schreiben, indem der Service-Endpunktbenachrichtigungservice verwendet wird. Weitere Informationen: Workflowerweiterungen
Asynchroner Service
Wenn der asynchrone Service vom Service-Endpunktbenachrichtigungsservice benachrichtigt wird, behandelt er das Posten des Datenkontexts der Anfragemessage, die derzeit von der Ereignisausführungspipeline zu 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.
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 Dynamics 365-Daten zugreifen können. Die Autorisierung von Dataverse zum Veröffentlichen des Datenkontexts für den Service-Bus und für Listener-Anwendungen zum Lesen wird durch 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 es mindestens eine Lösung in einem Azure Service Bus-Lösungskonto geben, bei dem die Lösung einen oder mehrere Service-Endpunkte enthält. Für einen Relay-Endpunkt-Vertrag muss eine Listener-Anwendung, die „Dataverse-taware“ ist, aktiv auf dem Endpunkt für die Dataverse-Anfrage auf dem Service Bus lauschen. Für einen Warteschlangenendpunktvertrag muss ein Listener nicht aktiv überwachen. Ein Listener wird Dataverse-fähig, wenn er mit dem Microsoft.Xrm.Sdk-Assembly verknüpft wird, damit der Typ RemoteExecutionContext definiert ist. Weitere Informationen: 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 Event-Daten in Ihrer Azure Event Hub-Lösung.
Dataverse-zu-Service-Bus-Szenario
Identifizieren wir nun ein Szenario, das die vorher erwähnten Verbingungskomponenten implementiert. Als Voraussetzung wurde SAS so konfiguriert, dass es Dataverse als unterstützten Aussteller akzeptiert, und die Azure Service Bus-Lösung ist mit Regeln konfiguriert, die es Dataverse erlauben, zu dem Endpunkt zu veröffentlichen, wo der Listener ist.
Das folgende Diagramm zeigt die physischen Elemente an, die das Szenario bilden.
Die Ereignisreihenfolge in diesem Diagramm ist die folgende:
Eine Listener-Anwendung wird an einem Azure Service Bus-Lösungsendpunkt registriert und beginnt, aktiv auf den Dataverse-Remote-Ausführungskontext auf dem Service Bus zu lauschen.
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.
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 Endpunkt der Lösung konfigurieren Sie einen Vertrag, der die Behandlung dieser „Nachrichten“ des entfernten Ausführungskontexts auf dem Service Bus und die Sicherheit definiert, die für diesen Endpunkt verwendet werden soll. Service-Bus-Nachrichten werden an einem Endpunkt unter Verwendung eines der hier aufgeführten unterstützten Verträge empfangen.
Warteschlange
Ein Warteschlangenvertrag bietet eine Nachrichtenwarteschlange in der Cloud. Mit einem Warteschlangenendpunktvertrag muss ein Listener nicht aktiv Nachrichten auf dem Endpunkt überwachen. 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. Bei einem nicht-destruktiven Lesevorgang wird die Nachricht nicht aus der Warteschlange entfernt.
Die Art der Warteschlange, die von Dataverse unterstützt wird, wird persistente Warteschlange genannt. Persistente Warteschlangen bieten eine lange aber begrenzte Nachrichtenverfügbarkeit als per Code angegeben werden kann.
Unidirektional
Ein unidirektionaler Vertrag benötigt einen aktiven Listener. Wenn an einem Endpunkt kein aktiver Listener vorhanden ist, schlägt der Post an den Service Bus fehl. Dataverse versucht in exponentiell immer größeren Zeitspannen zu posten, bis die asynchrone Systemaufgabe, die die Anfrage postet, schließlich abgebrochen wird und der Status wieder auf Fehler festgelegt wird.
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
Ähnlich wie eine Warteschlange, mit dem Unterschied, dass ein oder mehrere Listener den Empfang von Nachrichten von dem Thema abonnieren können.
-Ereignishub
Diese Vertragsart gilt für Azure Event Hub-Lösungen.
Wichtig
Um diese Verträge nutzen zu können, müssen Sie Ihre Listener-Anwendungen mit dem Azure SDK v1.7 oder höher schreiben.
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 aufgetreten ist, nachdem ein Posting an den Service Bus versucht wurde, überprüfen Sie den Status des zugehörigen Systemjobs in der Webanwendung, um weitere Informationen über den Fehler zu erhalten. Wenn der Service-Bus ausgefallen ist oder ein Listener/Endpunkt nicht verfügbar ist, wird die aktuelle Nachricht, die in Dataverse verarbeitet wird, nicht an den Bus gesendet. Der asynchrone Service versucht weiterhin, die Nachricht in einem exponenziellen Muster zu veröffentlichen, wobei er versucht, die Veröffentlichung erst oft und dann in länger werdenden Intervallen durchzuführen. Bei einem internen Dataverse-Fehler werden keine Message-Veröffentlichungen versucht. Bei einem externen Servicebus- oder Netzwerkfehler befindet sich der jeweilige Systemauftrag in einem "Wartezustand".
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).
Feedback
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Tickets als Feedbackmechanismus für Inhalte auslaufen lassen und es durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unter: https://aka.ms/ContentUserFeedback.
Feedback senden und anzeigen für