Anveo EDI Connect / Config / Mappings / Modellierung von Mapping-Workflows
This is an automatic translation. The original post is available in Englisch.

Modellierung von Mapping-Workflows

In Anveo EDI Connect verwenden Sie normalerweise mehrere Mappings, um einen EDI-Prozess zu modellieren. Im Folgenden werden wir uns sehr einfache und ein weiteres komplexeres Beispiel ansehen. Das Modul ist sehr flexibel und Sie können den Prozess so abbilden, wie Sie es wünschen, aber die folgenden Beispiele sind unsere empfohlene Art, den Prozess zu modellieren.

Bevor wir zu sehr ins Detail gehen, wollen wir ein paar Begriffe klären. Ein Mapping in Anveo EDI Connect kann ausgeführt werden. Dann gibt es das Konzept einer Datenbanktransaktion. Vereinfacht ausgedrückt, sammelt eine Datenbanktransaktion alle Änderungen an der Datenbank während einer Transaktion. Am Ende der Transaktion können die Daten entweder dauerhaft gespeichert werden, was als Datenbank-Commit bezeichnet wird. Oder die Änderungen können zurückgesetzt werden, d.h. alle während der Transaktion vorgenommenen Änderungen werden rückgängig gemacht und nicht gespeichert. Jede Ausführung eines Mappings erfolgt in einer eigenen Datenbanktransaktion. Tritt ein Fehler während der Mapping-Ausführung auf, wird die Transaktion zurückgerollt. Andernfalls wird die Transaktion bestätigt. (Dies gilt für die meisten Mappings. In Anveo EDI Connect gibt es Tabellen-Trigger, die beliebigen Code ausführen können. Wenn dieser Code einen COMMIT-Befehl enthält, kann das Modul die Änderungen nicht rückgängig machen. Dies kann zu unerwünschtem Verhalten führen).

Eingehender XML-Kundenauftrag

Wir verwenden in diesem Beispiel drei Mappings, um eine XML-Datei zu importieren. Dies ist das empfohlene Minimum. Im ersten Schritt werden wir die externe Datenstruktur auf Puffertabellen abbilden. Die Idee ist, die Daten zu importieren, auch wenn nicht alle Daten verarbeitet werden können. Dies ermöglicht es dem Endbenutzer, Fehler in der EDI-Transaktion zu korrigieren, ohne das Wissen über das externe Datenformat. Dies ist natürlich nur möglich, wenn es Datenfehler gibt, nicht wenn die Dateistruktur nicht geparst werden kann.

Der nächste Schritt ist die Überprüfung der Daten. Hier können Sie beliebige logische Prüfungen der Geschäftsdaten hinzufügen. Wir empfehlen, dies in einem separaten Schritt vor der Verarbeitung zu tun, um mehrere Fehlermeldungen zu sammeln und dem Endanwender ein vollständiges Fehlerprotokoll zu geben. Wenn Sie Daten aus der Systemtabelle nachschlagen müssen und diese persistieren wollen, würden wir das in einem vierten Schritt zwischen dem externen und dem Check-Mapping tun.

Der letzte Schritt ist die Erstellung des Microsoft Dynamics 365 Business Central-Dokuments. Wir tun dies in einem separaten Schritt, um Tabellensperren auf Systemtabellen so kurz wie möglich zu halten.

Ausgehende EDIFACT-Rechnung

Bei ausgehenden Dokumenten haben Sie in der Regel einige Werte, die nicht direkt in der Microsoft Dynamics 365 Business Central-Quelltabelle abgelegt sind. Um dem Endbenutzer die Möglichkeit zu geben, diese Daten zu sehen und die Abbildung des externen Datenformats zu vereinfachen, empfehlen wir, die Daten zunächst in eine Puffertabelle zu schreiben. In diesem Schritt können Sie Werte nachschlagen und Berechnungen durchführen.

Das Export-Mapping nimmt nur die gepufferten Daten und schreibt sie in das Zielformat.

EDI-Verfahren mit Bestätigung

Der Prozess muss nicht linear sein. Wenn Sie Bestätigungen senden müssen oder Daten gruppieren wollen, können Sie jederzeit mehrere Mappings aus einem Mapping heraus aufrufen. Sie können auch Bedingungen und bedingte Verzweigungen verwenden, um verschiedene Mappings basierend auf den Daten durchzuführen.

Wie Sie den Workflow einrichten

Auf die Details gehen wir später ein. Wenn Sie vorwärts springen wollen, verwenden wir zwei Techniken, um den Mapping-Workflow zu strukturieren. Die Geschäftsvorfälle und die Nachbearbeitung.