Integration ausgehender Daten

  • 5 Minuten

Die Integration ausgehender Daten übernimmt Daten von Microsoft Dataverse und stellt sie anderen Systemen zur Verfügung.

Dataverse-Ereignisveröffentlichung

Dataverse bietet ein Ereignismodell für die Integration in andere Systeme. Dataverse unterstützt das Auslösen von benutzerdefiniertem Code und externen Aktionen, wenn Ereignisse auf der Plattform erkannt werden. Dieses Ereignismodell wird als Ereignisframework bezeichnet. Das Ereignisframework bietet Ihnen die Möglichkeit, benutzerdefinierten Code zu registrieren, der als Reaktion auf bestimmte Ereignisse ausgeführt werden soll. Normalerweise verwenden Sie das Ereignisframework, um benutzerdefinierten Plug-In-Code auszulösen. Sie können es jedoch auch für die Integration in andere Systeme verwenden.

Stellen Sie sicher, dass Sie mit den folgenden Konzepten vertraut sind, um das Ereignisframework für Ihre Lösung zu verwenden:

  • Die verfügbaren Ereignisse
  • Art der Verarbeitung des Ereignisses
  • Welche Art von Daten sind beim Eintreten des Ereignisses verfügbar?
  • Welche Zeit- und Ressourcenbeschränkungen gelten?
  • Wie wird die Leistung überwacht?

Zusätzlich können Sie die verschiedenen Phasen angeben:

  • Vorabvalidierung – Beim Erstbetrieb tritt diese Phase vor dem Betrieb des Hauptsystems auf. Mit dieser Phase können Sie Logik einbinden, mit der sich der Vorgang vor der Datenbanktransaktion abbrechen lässt. Diese Phase tritt vor der Durchführung sämtlicher Sicherheitsprüfungen auf, um zu überprüfen, ob der aufrufende oder angemeldete Benutzer berechtigt ist, den gewünschten Vorgang durchzuführen.
  • Vor dem Betrieb – Tritt vor Betrieb des Hauptsystems und während der Datenbanktransaktion auf Wenn Sie die Werte einer in einer Nachricht enthaltenen Tabelle ändern möchten, tun Sie dies in dieser Phase.
  • Hauptbetrieb – Nur zur internen Verwendung, außer bei Anbietern benutzerdefinierter APIs und benutzerdefinierter virtueller Tabellendaten
  • Nach dem Betrieb – Tritt nach Betrieb des Hauptsystems und während der Datenbanktransaktion auf Mit dieser Phase können Sie die Eigenschaften der Nachricht ändern, bevor sie an den Anrufer zurückgeht.

Hinweis

Die Integration verwendet normalerweise die Phase „Nach Betrieb“und den asynchronen Betriebsmodus.

Das Ereignisframework kann Folgendes auslösen:

  • Plug-Ins
  • Klassische Workflows
  • Power Automate-Cloud-Flows
  • Nachrichten an Azure Service Bus und Azure Event Hub
  • Webhooks

Ereignis im Vergleich zu Batch

Lösungsarchitekten sollten die Daten kategorisieren, die in Dataverse erforderlich sind. Eine Schlüsselkategorie ist ereignis‑ oder batchbasiert. Das folgende Diagramm vergleicht diese beiden Ansätze.

Diagramm der Ansätze für ausgehende Integration

Push-Muster

Die ereignisbasierte Verarbeitung ist dem Push-Muster zugeordnet. Ein Ereignis in Dataverse führt einen Prozess aus, der eine Verbindung zum externen System herstellt und die Daten in diesem System aktualisiert. Bei der direkten Verknüpfung mit einem anderen System müssen Lösungsarchitekten sicherstellen, dass sie keine Leistungsprobleme für beide Systeme verursachen und kein eng gekoppeltes System erstellen.

Wichtig

Wenn Sie Plug-Ins verwenden, muss der Lösungsarchitekt das Zwei-Minuten-Zeitlimit für die Plug-In-Verarbeitung kennen.

Pull-Muster

Das Pull-Muster verwendet externe Ereignisse vom anderen System oder einen geplanten Trigger, um einen Datensatz aus Dataverse abzurufen und den zurückgegebenen Datensatz zu verarbeiten.

Hinweis

Der Wiederholungs-Trigger in Power Automate wird oft im Pull-Muster verwendet.

Änderungsnachverfolgung

Mit der Funktion zur Änderungsnachverfolgung in Dataverse können Sie die Daten effizient synchronisieren, indem Sie feststellen, welche Daten sich seit der letzten Synchronisierung der Daten geändert haben. Ohne Änderungsnachverfolgung ist es schwierig, einen zuverlässigen und effizienten Mechanismus zu erstellen, um festzustellen, in welchen Zeilen sich Änderungen in Dataverse ergeben haben.

Wenn Sie Daten mit Änderungsnachverfolgung abrufen, wird eine Reihe von Deltaänderungen von Dataverse zurückgegeben.

Hinweis

Die Änderungsnachverfolgung muss in der Tabelle aktiviert sein.

Azure-Integration

Die Dataverse-Plattform unterstützt die ausgehende Integration in Azure. Dataverse kann Nachrichten an Azure-Dienste durch Verwendung des Ereignisframeworks senden, wie in der folgenden Abbildung dargestellt.

Diagramm der Integrationen mit Azure

Service Bus

Ein Service, den Dataverse in seinen Microsoft Azure Service Bus integrieren kann.

Mit Azure Service Bus können Sie Anwendungen und Dienste voneinander entkoppeln. Dies bietet die folgenden Vorteile:

  • Lastenausgleichsarbeit zwischen konkurrierenden Arbeiten
  • Routing und Übertragung von Daten sind sicherer und kontrollierbarer über Service- und Anwendungsgrenzen hinweg
  • Koordination von Transaktionsarbeiten, die ein hohes Maß an Zuverlässigkeit erfordern

Azure Service Bus kann einen sichereren und zuverlässigeren Kommunikationskanal zwischen Dataverse-Laufzeitdaten und externe cloudbasierte oder lokale Branchenanwendungen (LOB) bereitstellen, wie in der folgenden Abbildung dargestellt.

Diagramm der Integrationen mit Azure Service Bus

Wie im vorherigen Bild gezeigt, wurde in Azure eine Azure Service Bus-Ressource erstellt. Es wurde ein Listener-Prozess entwickelt, der darauf wartet, dass Nachrichten auf einem Azure Service Bus veröffentlicht werden. In Dataverse wurde der Azure Service Bus-Endpunkt durch die Verwendung des Plug-In-Registrierungstools registriert. Es wurde ein Schritt definiert, bei dem der Plug-In-Kontext für den Service Bus als Nachricht freigegeben wird, wenn ein Ereignis eintritt, wie das Erstellen einer Zeile in Dataverse.

Der Listener-Prozess kann die Nachricht automatisch lesen und die Details des Ereignisses aus dem Kontext extrahieren (welche Tabelle, ID der Zeile, Benutzer, der das Ereignis ausgelöst hat, die Liste der Datenänderungen usw.) und die entsprechende Verarbeitung dieser Daten ausführen.

Bei dem Listener-Prozess kann es sich um Folgendes handeln:

  • Ein C#-Programm, das auf einem lokalen System ausgeführt wird, das den Service Bus nach neuen Nachrichten abfragt
  • Eine App in Microsoft Azure Logic Apps, die automatisch ausgelöst wird, wenn eine neue Nachricht veröffentlicht wird
  • Eine Funktion in Microsoft Azure Functions, die automatisch ausgelöst wird, wenn eine neue Nachricht veröffentlicht wird

Die Integration in Azure Service Bus ist nützlich, wenn die Wahrscheinlichkeit besteht, dass das andere System nicht verfügbar ist oder nur eingeschränkt in der Lage ist, große Nachrichtenmengen zu verarbeiten, da die Nachrichten in die Warteschlange gestellt werden können, sodass das empfangende System die Nachrichten so schnell wie möglich verarbeiten kann.

Sie können eine Nachricht auf zwei Arten an den Service Bus senden:

  • Kein Code – Erstellen Sie einen Schritt für das Ereignis in Dataverse für den Azure Service Bus-Endpunkt. Der Plug-In-Implementierungskontext wird auf den Service Bus übertragen.
  • Code – Erstellen und registrieren Sie ein Plug-In in Dataverse. Dadurch wird der Azure Service Bus-Endpunkt aufgerufen. Die Nachricht, die an den Service Bus gesendet wird, kann angepasst werden.

Azure Service Bus kann für folgende Aktionen verwendet werden:

  • Zuverlässige und flexible Cloud-Apps mit Messaging erstellen
  • Ihre Anwendung vor vorübergehenden Spitzenauslastungen schützen
  • Nachrichten an mehrere unabhängige Betriebssysteme verteilen
  • Ihre Anwendungen voneinander trennen
  • Geordnete Nachrichten erstellen, die auf mehrere Leser skaliert sind

Relay

Microsoft Azure Relay ist ein Dienst, der zuvor Teil von Azure Service Bus war, aber in einen eigenen Dienst unterteilt wurde.

Der Azure Relay-Dienst vereinfacht die enge Integration zwischen Systemen, indem er Ihnen hilft, Dienste, die sich in einem Unternehmensnetzwerk befinden, sicherer für die Public Cloud verfügbar zu machen. Sie können die Dienste verfügbar machen, ohne eine Firewall-Verbindung zu öffnen und ohne intrusive Änderungen an einer Unternehmensnetzwerkinfrastruktur vorzunehmen.

Azure Relay unterstützt die folgenden Szenarien zwischen lokalen Diensten und Anwendungen, die in der Cloud oder in einer anderen lokalen Umgebung ausgeführt werden:

  • Traditionelle Einweg-, Anforderungs-/Antwort- und Peer-to-Peer-Kommunikation
  • Ereignisverteilung im Internetbereich, um Veröffentlichungs-/Abonnementszenarien zu ermöglichen
  • Bidirektionale und ungepufferte Socket-Kommunikation über Netzwerkgrenzen hinweg

Wichtig

Mit Azure Relay können zwei Systeme verbunden werden, ohne dass eine direkte Verbindung erforderlich ist. Azure Relay folgt einem Anforderungs-/Antwortmuster, sodass das aufrufende System eine Antwort wie ein Datenelement oder eine Erfolgsnachricht vom anderen System empfangen kann.

Event Hubs

Bei Microsoft Azure Event Hubs handelt es sich um eine Big Data-Streamingplattform und einen Ereigniserfassungsdienst. Mit diesem Dienst können Millionen von Ereignissen pro Sekunde empfangen und verarbeitet werden. Daten, die an einen Event Hub gesendet werden, können mithilfe eines beliebigen Echtzeit-Analyseanbieters oder von Batch-/Speicheradaptern transformiert und gespeichert werden.

Mehrere andere Systeme können Ereignisse abonnieren, die von Event Hubs verarbeitet werden. Darüber hinaus können Event Hubs Ereignisse mithilfe von Consumergruppen filtern, sodass Systeme die für sie relevanten Ereignisse nur in ihrem eigenen Tempo empfangen.

Diagramm der Azure Event Hubs

Hinweis

Themen in Azure Service Bus bieten eine ähnliche Methode für Systeme zum Abonnieren gefilterter Nachrichten.

Sie sollten die Verwendung von Azure Event Hubs in Betracht ziehen, wenn Sie mehrere Abonnenten benötigen.

Ein Beispiel für die Verwendung von Event Hubs ist das Veröffentlichen von Ereignissen, um Analysen zu streamen, die wiederum einen Microsoft Power BI-Dataset zur Visualisierung auffüllen.

Webhooks und Azure Functions

Dataverse unterstützt das Aufrufen eines Webhooks mit dem Ereignisframework. Webhooks werden beim Plug-In-Registrierungstool registriert und können durch ein bestimmtes Ereignis in einem Schritt ausgelöst werden.

Webhooks ist ein leichtes HTTP-Muster zum Verbinden von Web-APIs und -Diensten mit einem Veröffentlichungs-/Abonnement-Modell. Webhook-Absender benachrichtigen Empfänger über Ereignisse, indem sie Anforderungen an Empfängerendpunkte mit einigen Informationen zu den Ereignissen senden. Webhooks sind einfach ein Muster, das mithilfe einer Vielzahl von Technologien angewendet werden kann. Sie müssen keine bestimmten Frameworks, Plattformen oder Programmiersprachen verwenden.

Webhooks ermöglichen Entwicklern die Integration von Dataverse-Daten mit ihrem eigenen benutzerdefinierten Code, der auf externen Diensten gehostet wird. Mithilfe des WebHooks-Modells können Sie Ihren Endpunkt mithilfe eines Authentifizierungsheaders oder von Parameterschlüsseln für Abfragezeichenfolgen sichern. Dieser Ansatz ist einfacher als das SAS-Authentifizierungsmodell, das von der Azure Service Bus-Integration verwendet wird.

Azure Functions bietet eine hervorragende Möglichkeit, mithilfe von Webhooks eine Lösung bereitzustellen.

Bei der Entscheidung zwischen dem WebHooks-Modell und der Azure Service Bus-Integration sollten Sie die folgenden Faktoren berücksichtigen:

  • Azure Service Bus funktioniert für die Verarbeitung in großem Maßstab und bietet einen vollständigen Warteschlangenmechanismus, wenn Dataverse viele Ereignisse verbreitet.
  • Webhooks können nur bis zu dem Punkt skaliert werden, an dem Ihr gehosteter Webdienst die Nachrichten verarbeiten kann.
  • Webhooks ermöglicht synchrone und asynchrone Schritte. Azure Service Bus ermöglicht nur asynchrone Schritte.
  • Webhooks senden POST-Anforderungen mit JSON-Nutzdaten und können von jeder Programmiersprache oder Webanwendung verwendet werden, die überall gehostet wird.
  • Das WebHooks-Modell und der Azure Service Bus können über ein Plug-In oder eine benutzerdefinierte Workflowaktivität aufgerufen werden.

Prozessintegration: Power Automate im Vergleich zu Azure Logic Apps

Power Automate Cloud-Flows basieren auf Azure Logic Apps und beide können im Allgemeinen dieselben Anforderungen erfüllen. Beide unterscheiden sich jedoch in einigen Punkten. Als Lösungsarchitekt sollten Sie überlegen, wann Sie Power Automate-Cloud-Flows oder Logic Apps verwenden:

Power Automate umfasst die folgenden Funktionen:

  • Dataverse-Konnektor hat mehr Funktionen
  • Er ist als Teil einer Lösung paketiert
  • Führt RPA mit Desktop-Flows aus
  • Verwendet den Konnektor „Genehmigungen“
  • Umfasst einen Konnektor zum Senden von Benachrichtigungen
  • Die Anzahl der monatlichen Flowausführungen ist begrenzt

Logic Apps enthalten die folgenden Funktionen:

  • Führt die Unternehmensintegration einschließlich EDI durch
  • Hat eine höhere Leistung
  • Kann mithilfe von Azure-Tools einfacher überwacht werden
  • Hat eine bessere Fehlerbehandlung
  • Kann nicht in Lösungen paketiert werden
  • Verfügt über ein verbrauchsabhängiges oder festes Preismodell über ein Azure-Abonnement