Azure-Integration in Microsoft Dynamics 365

 

Veröffentlicht: Januar 2017

Gilt für: Dynamics 365 (online), Dynamics 365 (on-premises), Dynamics CRM 2016, Dynamics CRM Online

Soe können Microsoft Dynamics 365 (online und lokal) mit der Microsoft Azure-Plattform verbinden durch Anschließen der Dynamics 365-Ereignisausführungspipeline an das Microsoft Azure Service Bus. Wenn die Verbindung konfiguriert ist, können Daten, die als Teil der gegenwärtigen Dynamics 365-Operation verarbeitet werden, zum Service-Bus gepostet werden.Microsoft Azure Service Bus-Lösungen, die "Dynamics 365-fähig" sind, können auf die Daten vom Microsoft Dynamics 365 Service-Bus hören und sie lesen.

Diese Verbindung zwischen Microsoft Dynamics 365 und der Microsoft Azure-Plattform bietet einen sicheren und zuverlässigen Kanal für die Kommunikation von Dynamics 365-Laufzeitdaten an externe cloudbasierte LOB-Anwendungen.

In diesem Thema

Wichtige Elemente der Verbindung

Ein Dynamics 365-zu-Servicebus-Szenario

Einrichten eines Vertrags zwischen Dynamics 365 und einer Azure-Lösung

Verwaltung der Laufzeitfehler

Wichtige Elemente der Verbindung

Die Schlüsselelemente, die die Verbindung zwischen Microsoft Dynamics 365 und dem Microsoft Azure Service Bus implementieren, werden unten 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 Dynamics 365-Operation verarbeitet werden. Diese Verarbeitung wurde initiiert, als eine Anfrage von einem Benutzer, Workflow oder einer Anwendung zur Durchführung eine bestimmte Operation an die Dynamics 365-Plattform gestellt wurde. Der Datenkontext wird allen Plug-Ins oder benutzerdefinierten Workflow-Aktivitäten weitergeleitet, die für die Ereignis-Pipeline registriert wurden, um bei der spezifischen Anfragen- und Entitätskombination, die derzeit verarbeitet wird, ausgeführt zu werden. Der Datenkontext ist vom Typ IPluginExecutionContext, wenn er entlang der Ereignisausführungspipeline weitergeleitet wird und RemoteExecutionContext wenn er zum Service-Bus bekannt übergeben wird.

  Der Datenkontext, der in der Message enthalten ist, die zu Microsoft 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 Dynamics 365-Daten vom Service-Bus lesen können.Diese Funktion wurde mit CRM Online 2016-Update 1 und CRM 2016 Service Pack 1 (lokal) eingeführt..

  Weitere Informationen zu die Technologien, die oben beschrieben werden, finden Sie in: Nachvollziehen des Datenkontexts, der an einem Plug-In übergeben wird, Ereignisausführungspipeline und Schreiben einer Listener-Anwendung für eine Microsoft Azure-Lösung.

• Plug-Ins
  Plug-Ins sind eine von zwei Methoden, die angewendet werden, um die Message zu posten, die den Datenkontext zu Microsoft Azure Service Bus enthält. Die andere Methode ist eine benutzerdefinierte Workflowaktivität. Es gibt zwei Typen von Plug-Ins, die durch die Dynamics 365-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 wird mit Dynamics 365 bereitgestellt und kann unter Verwendung des Plug-In-Registrierungstools im SDK-Download registriert werden. Dieses Plug-In wird in vollständiger Vertrauensstellung mit der Microsoft Dynamics 365 ausgeführt. Sie müssen in der Ereignisausführungspipeline einen Plug-In-"Schritt" registrieren, in dem die Message und Entitätskombination identifiziert werden, die die Ausführung des Plug-Ins auslöst, um die Postingmitteilung durchzuführen. Wenn das Plug-In durchgeführt wird, benachrichtigt es den asynchronen Service durch einen Service-Endpunktmitteilungsservice (IServiceEndpointNotificationService), um den gegenwärtigen Anfragedatenkontext zu Microsoft 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. Durch das Hinzufügen von Code, um diesen Service aufzurufen, wird das Plug-In "Azure-fähig". Weitere Informationen zu Plug-Ins im Allgemeinen finden Sie unter Schreiben eines Plug-Ins. Weitere Informationen zu Azure-fähigen Plug-Ins finden Sie unter Schreiben eines benutzerdefinierten Azure-Plug-Ins.

• Benutzerdefinierte Workflowaktivitäten
  Ähnlich wie Plug-Ins können benutzerdefinierte Workflowaktivitäten geschrieben werden, um das Posten des aktuellen Anfragemessage-Datenkontexts zu Microsoft Azure Service Bus zu schreiben, indem der Service-Endpunktbenachrichtigungservice verwendet wird (IServiceEndpointNotificationService).Weitere Informationen:Beispiel: Azure-fähige benutzerdefinierte Workflowaktivität.

• 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 Microsoft 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 Microsoft Dynamics 365-Webanwendung anzeigen.

  Weitere Informationen zu des asynchronen Service finden Sie unter Asynchroner Service in Microsoft Dynamics 365

• Microsoft Azure Service Bus
  Der Service-Bus verteilt den Anfragemessage-Datenkontext zwischen Microsoft Dynamics 365 und Microsoft 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. Autorisierung von Microsoft Dynamics 365 zum Posten des Datenkontexts zum Service-Bus und für Listener-Anwendungen zum Lesen wird entweder durch Microsoft Azure Active Directory-Zugriffssteuerungsdienst (ACS) oder Microsoft Azure Shared Access Signatures (SAS) verwaltet.

  Hinweis

  Über SAS-Autorisierung: Diese Funktion wurde mit CRM Online 2016-Update 1 und CRM 2016 Service Pack 1 (lokal) eingeführt.-SAS ist eine modernere Form der Autorisierung und weist bessere Leistung auf, wenn es mit ACS verglichen wird.

  Weitere Informationen zu der Service-Bus finden Sie unter Service-Bus.Weitere Informationen zu-Service-Bus-Autorisierung siehe Service-Bus-Authentifizierung und -Autorisierung.

• Microsoft Azure-Lösung
  Damit die Dynamics 365-Azure Verbindung funktioniert, muss sich mindestens eine Lösung in einem Microsoft Azure Service Bus-Lösungskonto befinden, wo die Lösung einen oder mehrere Serviceendpunkte enthält. Für einen Relayendpunktvertrag muss eine Listener-Anwendung, die "Dynamics 365-fähig" ist, aktiv den Endpunkt auf die Dynamics 365-Anfrage auf dem Servicebus überwachen. Für einen Warteschlangenendpunktvertrag muss ein Listener nicht aktiv überwachen. Ein Listener wird "Dynamics 365-fähig", wenn er mit dem Microsoft.Xrm.Sdk-Assembly verknüpft wird, damit der Typ RemoteExecutionContext definiert ist.Weitere Informationen:Schreiben einer Listener-Anwendung für eine Microsoft Azure-Lösung

  Microsoft Dynamics 365 unterstützt das Senden der Ereignisdaten zu einer Azure Event Hubs-Lösung.Diese Funktion wurde mit CRM Online 2016-Update 1 und CRM 2016 Service Pack 1 (lokal) eingeführt.. Informationen zu Weitere Informationen zu-Ereignishubs finden Sie unter Arbeiten mit Dynamics 365-Ereignisdaten in Ihrer Azure-Ereignishub-Lösung.

Ein Dynamics 365-zu-Servicebus-Szenario

Identifizieren wir nun ein Szenario, das die vorher erwähnten Verbingungskomponenten implementiert. Als Voraussetzung wurde ACS so konfiguriert, dass es Microsoft Dynamics 365 als unterstützten Aussteller akzeptiert, und die Microsoft Azure Service Bus-Lösung ist mit Regeln konfiguriert, die Microsoft Dynamics 365 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:

1. Eine Listener-Anwendung ist auf einem Microsoft Azure Service Bus-Lösungsendpunkt registriert und beginnt, aktiv den Microsoft Dynamics 365-Remoteausführungskontext auf dem Servicebus zu überwachen.

2. Ein Benutzer führt einen Vorgang in Microsoft Dynamics 365 aus, der die Ausführung des registrierten OOB-Plug-Ins oder eines benutzerdefinierten Azure-fähigen Plug-In auslöst. Das Plug-In initiiert eine Veröffentlichung über einen asynchronen Servicesystemauftrag des aktuellen Datenkontexts zum Servicebus.

3. Die von Microsoft Dynamics 365 veröffentlichten Ansprüche werden authentifiziert. Der Servicebus verteilt dann den Remoteausführungskontext an den Listener. Der Listener verarbeitet die Kontextinformationen und führt einige geschäftliche Aufgaben mit diesen Informationen durch. Der Servicebus informiert den asynchronen Service über die erfolgreiche Veröffentlichung und setzt den jeweiligen Systemauftrag auf den Status "abgeschlossen".

Einrichten eines Vertrags zwischen Dynamics 365 und einer Azure-Lösung

Für jeden Lösungsendpunkt konfigurieren Sie einen Vertrag, der die Verarbeitung dieser "Nachrichten" des Remoteausführungskontexts auf dem Servicebus regelt, sowie die Sicherheit, die auf diesem Endpunkt verwendet werden soll. Servicebusnachrichten werden an einem Endpunkt mithilfe 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 Microsoft Dynamics 365 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 es keinen aktiven Listener auf einem Endpunkt gibt, schlägt das Posten zum Service-Bus fehl.Microsoft Dynamics 365 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 bidirektionaler Vertrag ähnelt einem unidirektionalen Vertrag, außer dass ein Zeichenfolgewert vom Listener zum Plug-In oder der benutzerdefinierten Workflowaktivität zurückgegeben werden kann, die den Post eingeleitet haben.

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

• Thema
  Ähnlich wie eine Warteschlange, mit dem Unterschied, dass ein oder mehrere Listener den Empfang von Nachrichten von dem Thema abonnieren können.

• Event Hub
  Diese Vertragsart trifft auf Microsoft Azure-Ereignishublösungen zu.

Wichtig

Um diese Verträge zu verwenden, müssen Sie Ihre Listener-Anwendungen mithilfe der Microsoft Azure SDK-Version 1.7 oder neuer 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 Anspruchsauthentifizierung wird für den sicheren Zugriff auf den Servicebus verwendet. Der zur Authentifizierung des Servicebusses verwendete Anspruch wird in Microsoft Dynamics 365 generiert und vom AppFabricIssuer-Zertifikat signiert, das in der Microsoft Dynamics 365-Konfigurationsdatenbank angegeben ist.

Verwaltung der Laufzeitfehler

Wenn Fehler auftrat, nachdem eine Veröffentlichung auf dem Servicebus versucht wurde, prüfen Sie den Status des Systemauftrags in der Microsoft Dynamics 365-Webanwendung auf weitere Informationen zum Fehler. Wenn der Servicebus ausgefallen ist oder kein Listener/Endpunkt/ein verfügbar ist, wird die aktuelle Meldung, die in Microsoft Dynamics 365 verarbeitet wird, nicht zum Bus veröffentlicht. 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 Microsoft Dynamics 365-Fehler werden keine Nachrichtenveröffentlichungen versucht. Bei einem externen Servicebus- oder Netzwerkfehler befindet sich der jeweilige Systemauftrag in einem "Wartezustand".

Siehe auch

Azure-Erweiterungen für Microsoft Dynamics 365
Konfigurieren der Azure-Integration in Microsoft Dynamics 365
Schreiben von Plug-Ins, um Geschäftsprozesse zu erweitern
Asynchroner Service in Microsoft Dynamics 365
AsyncOperation (Systemauftrags-) Entität

Microsoft Dynamics 365

© 2017 Microsoft. Alle Rechte vorbehalten. Copyright