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. Diese Funktion ist besonders wichtig, da Azure eine der wenigen unterstützten Lösungen für die Kommunikation des Laufzeitkontexts an externe Line-of-Business-Anwendungen (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 als Teil der gegenwärtigen Dataverse-Operation verarbeitet werden. Diese Verarbeitung wurde eingeleitet, als von einem Benutzer, Workflow oder einer Anwendung die Anforderung gestellt wurde, einen bestimmten Dataverse Vorgang auszuführen. 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 Ereignisausführungspipeline übergeben wird, und 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. Die Unterstützung solcher Datenformate ermöglicht plattformübergreifende Interoperabilität, bei der von Azure gehostete Nicht-.NET-Clients Daten vom Service Bus lesen können. Dataverse
Wichtig
Wenn die Größe der gesamten HTTP-Nutzlast 192 Kb überschreitet, werden die folgenden Eigenschaften entfernt:
ParentContext, InputParameters, PreEntityImages, PostEntityImages
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 empfohlen, das Plug-In für die asynchrone Ausführung zu registrieren, um eine optimale Systemleistung zu erzielen.
Ein Azure-fähiges Standard-Plug-In (OOB) ist verfügbar und kann registriert werden, indem ein Dienst Endpunkt mithilfe des Plug-In-Registrierungstools registriert wird. Dataverse 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 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. Wählen Sie in der Webanwendung Erweiterte Einstellungen, um die alte Dynamics 365-Benutzeroberfläche anzuzeigen. Als Nächstes Auswählen Einstellungen > Systemjobs.
Weitere Informationen zum 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 sorgt außerdem für Datensicherheit, sodass nur autorisierte Anwendungen auf die geposteten Dataverse Daten zugreifen können. Die Autorisierung Dataverse zum Posten des Datenkontexts im Servicebus 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 Ereignisdaten in Ihrer Azure Event Hubs-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 bei einer Azure Service Bus-Lösung Endpunkt registriert und beginnt aktiv mit dem Abhören des Dataverse Remote-Ausführungskontexts auf dem Service Bus.
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 einen destruktiven und einen nicht destruktiven Lesevorgang. Ein destruktiver Lesevorgang liest eine verfügbare Nachricht aus der Warteschlange, wonach die Nachricht entfernt wird. Ein zerstörungsfreier Lesevorgang entfernt keine Nachricht aus der Warteschlange.
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 auf einem Endpunkt kein aktiver Listener vorhanden ist, schlägt das Posten 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.
Event Hubs
Dieser Vertragstyp 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 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).