DEEP DIVE – 2-Jahres Review: Kopplung zwischen einer AS400 und Dynamics 365

Anforderung

Die Aufgabenstellung lautete wie folgt:

Der Kunde betreibt eine IBM AS400 für die Kunden-Stammdatenverwaltung, die Produktionssteuerung und die Buchhaltung und Rechnungslegung.

Im Zuge der Einführung einer Dynamics 365 Sales Cloud-Lösung sollen bestimmte Stammdaten aus der AS400 regelmäßig in das Dynamics-System übertragen werden. Die AS400 bleibt das führende System.

Übermittelt werden:

  • Firmen-Stammdaten
  • Texte (Schlüssel und Bezeichnungen)
  • Artikel-Stammdaten (Produktschlüssel und -bezeichnungen)

Des Weiteren werden über eine spezielle Branchen-Software Angebote erstellt. Diese Angebote sollen ebenfalls nach Dynamics 365 Sales überführt werden.

Der Datenverkehr soll gesichert erfolgen und keinen direkten Zugriff von der Public Cloud in das lokale Netzwerk benötigen.

Gefragt war zudem eine Lösung mit möglichst geringen Implementierungs- und Betriebskosten.

Lösung

 

Das folgende Bild zeigt die gewählte Lösungsarchitektur

 

 

Schritt 1: Übertragung der Daten vom Kundenserver nach Dynamics über Logic Apps Funktionen

Die Stammdaten werden per csv-Export aus der AS400 in einem festgelegten Pickup-Verzeichnis auf dem Kunden-Server zur Verfügung gestellt. Für die Angebotsdaten erfolgt der Export aus der Angebots-Software als Text-Datei. Über Azure Logic Apps-Funktionen werden die Dateien aufgenommen und die Daten in die Dynamics Interims-Tabellen übertragen.

Die Übertragung vom Unternehmens-Server in die Cloud erfolgt über das Microsoft Data Gateway, das die Übertragung per TLS-Protokoll absichert. Die Logic Apps Funktionen scannen das Pick-up Verzeichnis in zeitlich definierten und vom Kunden bestimmbaren Intervallen auf neue Dateien. In diesem Fall erfolgt der Verzeichnis-Scan für den Stammdatenimport alle 5 Minuten, derjenige für den Angebotsimport einmal pro Minute. (Die Logic Apps Funktionen sind NICHT Bestandteil dieses Beitrags.)

Schritt 2: Übertragung der Daten aus den Interims-Tabellen in die Produktiv-Entitäten

Die folgende Beschreibung bezieht sich auf den Dynamics-internen Daten-Import, d.h. den Import von AS400-Daten und Angebots-Daten aus den Interims-Tabellen für die Stamm- und Angebots-Daten in die Dynamics-Entitäten „Firmen“, „Texte“, „Artikel“ und „Angebote“ und „Angebotspositionen“.

Die Interims-Tabellen nehmen die Daten aus den AS400- und Angebots-Exporten 1:1 auf. Jegliche Logik für den Import in die Dynamics-Entitäten liegt im Dynamics-internen Import.

Diese Import-Architektur wurde gewählt, um

  • einen direkten Import in die Produktiv-Entitäten zu vermeiden
  • die Logik innerhalb von Dynamics-Komponenten (Workflows, WorkflowActivitites ) abzubilden statt diese – teilweise komplexen Funktionen – in die Logic Apps zu verlagern
  • Prüf- und Überwachungsmechanismen etablieren zu können
  • im Fehlerfall den Import innerhalb des Dynamics Systems neu anstoßen zu können

Nach Abschluss des Importes der Datensätze über die Azure Logic Apps in die Interimstabellen werden Workflows getriggert, die die Datensätze aus den Interimstabellen in die Dynamics 365 Sales Tabellen „Firmen“, „Texte“, „Artikel“, „Angebote“ und „Angebotspositionen“ übertragen. Insert und Update der Datensätze erfolgen über Workflow-Activities, die in den Workflows aufgerufen werden.

Eine Dynamics-seitige Einschränkung ist hierbei, dass Workflows maximal 2 Minuten laufen und dann über einen Timeout abgebrochen werden. Da die Workflows beim Import der Firmen-Daten regelmäßig länger als 2 Minuten benötigten, war eine Aufteilung der importieren Datensätze notwendig.

So wurden jeweils eine bestimmte Anzahl Firmen-Datensätze gelesen und verarbeitet und anschließend ein weiterer Workflow gestartet bis alle Datensätze verarbeitet waren.
Hierbei ist zu beachten, dass es auch hier eine Dynamics-seitige Einschränkung gibt: Der gleiche Workflow kann innerhalb einer Stunde maximal 7 mal aufgerufen werden, ansonsten wird der Workflow mit einer „infinite-loop“-Warnung abgebrochen:

„This workflow job was canceled because the workflow that started it included an infinite loop. Correct the workflow logic and try again. For information about workflow“.

Siehe auch: https://crmbook.powerobjects.com/system-administration/processes/workflows/:

Infinite loops

[…] Microsoft Dynamics 365 has run-time logic to find and stop workflows that have entered an infinite loop. The system automatically stops the workflow

There is a loop detection mechanism in CRM for Dynamics 365 which would cancel processes/plugins that create infinite loops as the one above. The maximum depth for a recurrence/loop is 8; however, the depth is reset after 10 minutes of inactivity

Zu Beginn des Projektes passte der Import der Firmendaten genau in diese Rahmenbedingungen. Zwei Jahre später traten vermehrt Fehler auf, da die Anzahl der Datensätze größer, die Updates umfangreicher wurden. Die Laufzeit des Workflows reichte nicht aus, eine Reduzierung der in einem Workflow verarbeiteten Datensätze führte zu Überschreitung der maximal zulässigen Aufrufe innerhalb einer Stunde.

Um diese Probleme zu vermeiden, wurde von einem Fullset-Update auf ein Änderungs-Update umgestellt, d.h.: über die Azure Logic Apps wurden nur noch die in einem bestimmten Zeitrahmen geänderten Firmen-Datensätze bereitgestellt, nicht mehr – wie zu Beginn des Projektes vom Kunden ausdrücklich gewünscht – ALLE Firmen-Datensätze. Für die Überwachung des AS400-Importes wurden entsprechende Dynamics Ansichten erstellt, die regelmäßig vom Kunden geprüft werden:

Im Fall eines fehlgeschlagenen Angebots-Importes wird über die Logic Apps eine Benachrichtigung per E-Mail an den Systemadministrator versendet.

Durch die Nutzung des Microsoft Data Gateway und der Logic App Funktionen blieb der Implementierungsaufwand im Rahmen. Die Betriebskosten für die Azure-Funktionen setzen sich zusammen aus einer Grundgebühr für den Azure-Service und –Speicher und einer variablen Komponente für die Datenzugriffe, abhängig von der Nutzungshäufigkeit.

WordPress Cookie Plugin von Real Cookie Banner