Azure-Integration in Microsoft Dynamics CRM

 

Veröffentlicht: November 2016

Gilt für: Dynamics CRM 2015

Soe können Microsoft Dynamics CRM 2015 und Microsoft Dynamics CRM Online 2015-Update mit der Microsoft Azure-Plattform verbinden durch Anschließen der Dynamics 365-Ereignisausführungspipeline an das Microsoft Azure Service Bus. Mit dieser Verbindung können Daten, die als Teil der gegenwärtigen Dynamics 365-Operation verarbeitet werden, zum Service-Bus hinzugefügt werden.Microsoft Azure Service Bus-Lösungen, die "Dynamics 365-fähig” sind, können auf die Daten vom Service-Bus mithilfe vom Microsoft Dynamics 365 hören und diese lesen. Die veröffentlichten Daten RemoteExecutionContext-Klasseninstanz gespeichert, d.h. in einer erweiterten Version von IExecutionContext, die zur Laufzeit an asynchrone Microsoft Dynamics 365-Plug-ins übergeben wird.

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

In diesem Thema

Wichtige Elemente der Verbindung

Ein CRM-zuSevicebus-Szenario

Einrichten eines Vertrags zwischen CRM 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, sind die folgenden.

• Asynchroner Service
  Der asynchrone Service veröffentlicht den Microsoft Dynamics 365-Remoteausführungskontext zu Microsoft Azure Service Bus. Jede Veröffentlichung wird durch einen Systemauftrag des asynchronen Services ausgeführt. Ein Benutzer kann den Status der einzelnen Systemaufträge mithilfe der Microsoft Dynamics 365-Webanwendung anzeigen.

• Plug-Ins
  Es gibt zwei Typen asynchroner registrierter Plug-Ins, die durch die Verbindungsfunktion unterstützt werden: vordefiniertes (OOB), die Plug-Ins, die in Dynamics 365 verfügbar snd, und angepasste. Weitere Informationen zur Verwendung asynchroner Plug-Ins mit Microsoft Azure finden Sie unter Auf den Benachrichtigungsservice zugreifen.

  Ein Azure-fähiges Plug-In wird mit Dynamics 365 bereitgestellt. Dieses Plug-In wird in vollständiger Vertrauensstellung mit der Microsoft Dynamics 365 ausgeführt. Bei Registrierung mit Microsoft Dynamics 365 kann das Plug-In den asynchronen Service informieren, um den Kontext der aktuellen Anfrage zum Microsoft Azure Service Bus zu veröffentlichen. Ein Entwickler muss einen Schritt auf diesem Plug-In registrieren, der die Zielnachricht und die Entität identifiziert, um die Servicebusveröffentlichungsfunktion zu aktivieren.

  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 und kann alle Microsoft Dynamics CRM SDK-Methoden aufrufen. Ein benutzerdefiniertes Plug-In kann die Veröffentlichung des Microsoft Dynamics 365-Kontexts zum Servicebus initiieren, indem einige Standardcodezeilen eingefügt werden, die den asynchronen Service auffordern, den Anfragekontext zu veröffentlichen. Dieser cloudspezifische Codes macht die Plug-Ins "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
  Benutzerdefinierte Workflowaktivitäten können erstellt werden, um den Datenkontext der aktuellen Anforderung zum Microsoft Azure Service Bus zu veröffentlichen.Weitere Informationen:Beispiel: Azure-fähige benutzerdefinierte Workflowaktivität.

• Microsoft Azure Service Bus
  Der Servicebus verteilt den Remoteausführungskontext zwischen Microsoft Dynamics 365- und Microsoft Azure Service Bus-Lösungslistenern. Der Microsoft Azure Active Directory-Zugriffssteuerungsdienst (ACS) verwaltet die anspruchsbasierte Authentifizierungssicherheit.

• Microsoft Azure-Lösung
  Damit die Dynamics 365 und 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 ein Listener, der "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:Listener für eine Microsoft Azure-Lösung schreiben

  Die Lösungsregeln müssen so konfiguriert werden, dass der Microsoft Dynamics 365-Remoteausführungskontext zum Servicebus veröffentlicht werden kann. Dazu muss ACS die Dynamics 365-Bereitstellung als unterstützten Aussteller anerkennen.Weitere Informationen:Konfigurieren der Azure-Integration in Microsoft Dynamics CRM 2015.

Wichtig

Zur Entwicklung eines Lösungslisteners für die Microsoft Azure-Plattform müssen Sie die Microsoft AzureSDK-Version 1.7 oder 1.8 auf Ihrem Entwicklungscomputer.

Ein CRM-zuSevicebus-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. Ein Listener 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 Anfragekontexts zum Servicebus.

3. ACS authentifiziert die von Microsoft Dynamics 365 veröffentlichten Ansprüche. 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 CRM 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.

  Es gibt zwei Arten von Warteschlangen, die in Microsoft Dynamics 365unterstützt werden: Nachrichtenpufferwarteschlange und persistente Warteschlange. Bei Nachrichtenpufferwarteschlangen werden Nachrichten in der Warteschlange automatisch gelöscht, wenn sie nicht in der vorkonfigurierten Zeit gelesen werden, die in der Regel nicht mehr als 10 Minuten beträgt. Persistente Warteschlangen bieten eine viel längere 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, zeigt Microsoft Dynamics 365 an, wenn der Service-Bus fehlschlägt.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 ähnelt einem unidirektionalen vertrag, mit dem Unterschied, dass vom Listener ein Zeichenfolgenwert an Microsoft Dynamics 365 zurückgegeben werden kann.

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

Wichtig

Um diese Verträge zu verwenden, müssen Ihre Listener-Anwendungen mithilfe der Microsoft AzureSDK-Version 1.7 oder 1.8 schreiben.

Nachrichtenpufferwarteschlangen sind als veraltet markiert und werden in einer zukünftigen Version von Microsoft Dynamics CRM SDK nicht unterstützt.

Die Identifikation der Sicherheit, die ein Vertrag verwendet, ist Teil seiner Konfiguration. Ein Vertrag kann die Transportsicherheit verwenden, die SSL (Secure Sockets Layer) (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 CRM 2015
Konfigurieren der Azure-Integration in Microsoft Dynamics CRM 2015
Schreiben von Plug-Ins, um Geschäftsprozesse zu erweitern
Asynchroner Service in Microsoft Dynamics CRM 2015
AsyncOperation (Systemauftrags-) Entität

© 2017 Microsoft. Alle Rechte vorbehalten. Copyright