Integration Ihrer lokalen Dateisysteme mit SAP Business One und Microsoft Azure

Wir sind uns alle bewusst, wie schnell sich die Technologie weiterentwickelt.

Täglich entstehen neue Tools und Dienste, die uns mehr Inhalte bieten, als wir wahrscheinlich konsumieren können.

Dieser „Trend“ ist in Wirklichkeit kein Trend, sondern der übliche Lauf der Dinge. Solange wir uns auf das konzentrieren, was wir erreichen wollen, können wir sogar sehr von diesen „Revolutionen“ profitieren, denen wir immer wieder begegnen.

Nichtsdestotrotz werden die meisten von uns (einschließlich meiner Wenigkeit) den alten „Legacy Approach“ nie ganz aufgeben, der in gewisser Weise den Ton angegeben und seit Jahren die Grundlage für viele der neuen Ansätze gelegt hat, die wir heute verwenden.

Die einzige Frage, die sich stellt, ist, wie wir den Fortschritt nutzen und neuere und fortschrittlichere Ansätze mit alten Ansätzen kombinieren können, um unsere organisatorischen Aufgaben zu erleichtern und Prozesse zu beschleunigen, damit wir unsere Arbeit effizienter erledigen können.

Das Szenario

Stellen Sie sich zum Beispiel vor, Ihr Unternehmen hat eine große Anzahl von Teilenummern, die in einem Lager gelagert werden, und Ihr Lagerverwalter muss mit dem MRP-Modul von SAP Business One einen wöchentlichen MRP-Empfehlungsbericht erstellen.

Auch wenn ich in diesem Blog nicht auf die MRP-Konzepte eingehen werde (vielleicht lohnt es sich, dies demnächst zu tun …), wissen diejenigen unter Ihnen, die das MRP-Modul tatsächlich verwenden, bereits, dass man für die Erstellung eines zuverlässig MRP-Empfehlungsberichtist es unerlässlich, dass Ihre MRP-Prognosen regelmäßig gewartet in SAP Business One – vor allem, wenn sich die Verkaufsprognosen ständig ändern.

Möglicherweise muss Ihr Bestandscontroller auf die Dispositionsprognose in SAP Business One zurückgreifen und die prognostizierten Werte für jede Ihrer SKUs/Lagerorte ändern.

Mit einigen der Expertentools von SAP Business One kommen Sie vielleicht etwas schneller ans Ziel. Diese Tools sind jedoch so konzipiert, dass sie ein tiefes Verständnis der Tabellenschemata von SAP Business One erfordern und bei falscher Handhabung zu schweren Schäden führen können.

Und um die Sache noch etwas interessanter zu machen, füge ich dem Geschäftsszenario eine weitere Komplexitätsebene hinzu – nehmen wir an, dass die prognostizierten Werte NICHT in SAP Business One generiert werden, sondern in eine „Flat File“ (*.CSV) aus anderen SAP/Non-SAP-Systemen extrahiert werden, wie z. B. SAP-ECC oder sogar ein SAP S/4HANA-System oder vielleicht eine von Ihnen verwendete Web-Schnittstelle. Angenommen, Ihr Inventory Controller möchte die Ausgabedatei einfach nur in seinem lokalen Dateisystem ablegen und weiß, dass dies im Hintergrund von einem automatisierten Prozess erledigt wird, der die Werte an die richtige Stelle in SAP Business One schiebt – und damit sicherstellt, dass seine MRP-Empfehlungen Bericht berücksichtigt die letzten Änderungen an den prognostizierten Verkaufswerten, und er kann seinen Tag mit der Erledigung anderer Aufgaben fortsetzen.

Klingt kompliziert? Nun, es ist kein „Kinderspiel“, aber es ist definitiv machbar mit den Tools, die Microsoft Azure und die erstaunliche Power Platform uns zu bieten haben.

Wie dies erreicht werden könnte

Als erstes müssen wir verstehen, dass unser lokales Dateisystem (On-Premises Data Source) in der Lage sein muss, mit Azure zu kommunizieren, und dass Azure in der Lage sein muss, auf unsere lokale Ordnerstruktur zu hören.

Dies kann durch die Installation und Konfiguration des „On-Premises Data Gateway“ auf Ihrem lokalen Rechner erreicht werden.

Das Daten-Gateway vor Ort fungiert als „Brücke“.

Es ermöglicht einen schnellen und sicheren Datentransfer zwischen lokalen Daten, also Daten, die sich nicht in der Cloud befinden, und verschiedenen Microsoft Cloud Services auf Azure, für die Microsoft vorgefertigte Konnektoren anbietet.

Das folgende Diagramm veranschaulicht die Funktionsweise des On-Premises Data Gateway und zeigt die zugrunde liegende Architektur:

Der erste Schritt ist also das Herunterladen und Installieren des On-Premises Gateway. Bitte beachten Sie, dass Microsoft jeden Monat ein neues Update für Daten-Gateways veröffentlicht.

Microsoft stellt eine recht übersichtliche Dokumentation zur Installation und Konfiguration des Gateways zur Verfügung, so dass ich hier nicht Schritt für Schritt vorgehen werde. Aber wir werden die Grundlagen und auch einige MEINE EIGENEN bewährten Verfahren behandeln, während ich an einigen meiner Lösungen gearbeitet habe.

Die gesamte Dokumentation finden Sie hier:

Einige Best Practices für die Installation der Gateway-Instanz auf Ihrem lokalen Rechner:

1. einen Wiederherstellungsschlüssel verwenden – man weiß nie, wann die Wiederherstellungsoption nützlich sein könnte, und anstatt die Instanz neu zu erstellen, können Sie sie ganz einfach wiederherstellen.

2. Stellen Sie sicher, dass Sie auch eine Gateway-Instanz auf Azure erstellen

3. Wenn Sie das Gateway richtig eingerichtet haben, sollten Sie sehen können, dass die Ressource für Sie verfügbar ist:

4. Wenn die Installation des On-Premise-Gateways abgeschlossen ist, hat es seinen eigenen Standarddienstnamen (Konto):

Dieses Konto sollte auf den lokalen Benutzer auf dem Computer, auf dem das Gateway installiert wurde, geändert werden, vorzugsweise auf ein Administratorkonto.

Wichtiger Hinweis: Verwenden Sie nicht das lokale Administratorkonto – es sollte deaktiviert und durch ein alternatives Konto ersetzt werden, das Mitglied der lokalen Admins-Gruppe auf dem Server ist. Das lokale Administratorkonto ist das erste, auf das es Hacker bei einer Datenverletzung abgesehen haben.

Sobald Sie auf „Konto ändern“ klicken, wird ein Dialog angezeigt, der Ihnen vorschlägt, das Gateway neu zu starten, wodurch die Anmeldedaten zurückgesetzt werden:

Sie haben nun zwei Möglichkeiten:

Als Erstes öffnen Sie die Eingabeaufforderung und geben „WHOAMI“ ein, um den lokalen Benutzer auf dem Rechner zu ermitteln
Am sichersten ist es, zu den Systemeigenschaften zu navigieren und den „Gerätenamen“ zu übernehmen, der im Grunde der „Computername“ ist, der als „lokaler Domänenname“ dient:

Wenn alles gut gegangen ist, sollten Sie sich bei dem neuen Dienstnamen anmelden können und die Änderungen sehen:

5. Bitte beachten Sie, dass der Rechner ständig mit dem Internet verbunden sein muss, wenn Sie ihn als Datenquelle nutzen wollen, die ständig mit Azure „spricht“ und Informationen austauscht.

Wenn die Möglichkeit besteht, dass diese Gateway-Instanz irgendwann nicht mehr verfügbar ist, sollten Sie in Erwägung ziehen, diese Gateway-Instanz zu einem „Cluster“ hinzuzufügen, wenn hohe Verfügbarkeit erforderlich ist.

6. Der Benutzername, den Sie für die Installation des On-Premise Data Gateway verwenden, muss ein lokaler Computerbenutzer sein, d. h. Sie können keine Cloud-Benutzer (wie Azure AD, M365) verwenden, um den Fluss auszulösen, selbst wenn dieser Benutzer derjenige ist, mit dem Sie sich bei Ihrem Computer anmelden. Ich würde empfehlen, „Administrator“ zu aktivieren oder einen anderen lokalen Benutzer mit administrativen Rechten einzurichten.

Nachdem wir nun die Verbindung zwischen unserem lokalen Dateisystem und Azure eingerichtet haben, können wir zum nächsten Schritt übergehen – der Erstellung der erforderlichen Logik, damit die MRP-Prognosewerte in SAP Business One aktualisiert werden können.

In diesem Fall wäre es am besten, eine Logic App zu erstellen, die auf Ihren lokalen zugeordneten Ordner „hört“ (wir werden dies bald behandeln), so dass unser Ablauf ausgelöst wird, sobald eine neue Datei in diesem Ordner abgelegt wird.

Dieser Ansatz, bei dem wir auf Ereignisse reagieren, anstatt den Ordner regelmäßig abzufragen, garantiert weniger Ausführungen, was zu geringeren verbrauchsabhängigen Gebühren führt (vor allem, wenn Sie die „Consumption“ Logic Apps und nicht die „Standard“ Apps verwenden). Azure Logic Apps bieten eine ganze Reihe integrierter Konnektoren, um unser lokales Dateisystem zu verwalten.

Für unser Szenario müssten wir mit zwei beginnen:

Der „Auslöser“ – der Connector „lauscht“ auf unseren lokalen Ordner – „Wenn eine Datei erstellt wird (nur Eigenschaften)„.
Die „Aktion“ – dieser Konnektor holt den tatsächlichen Inhalt unserer Datei (Comma Separated Delimited content) – “ Get file content“.

Bevor wir sie nutzen können, muss eine Verbindung zu unserem On-Premise Data Gateway hergestellt werden:

Sobald wir die Verbindung authentifiziert haben, können wir sowohl den Auslöser als auch die Aktion verwenden.

Der Trigger wird, wie der Name schon sagt, nur dann ausgelöst, wenn eine neue Datei in dem von uns zugeordneten lokalen Ordner abgelegt wird – diese Datei enthält die Prognosewerte, die wir in SAP Business One aktualisieren möchten.

Die Dateistruktur, in der die Prognosewerte erfasst werden, könnte wie folgt aussehen:

Für produktive Lösungen würde ich auch vorschlagen, eine Namenskonvention für diese Datei zu finden und eine Logik hinzuzufügen, die überprüft, ob die Namenskonvention eingehalten wird. Dadurch wird verhindert, dass der Fluss jedes Mal ausgelöst wird, wenn jemand „irgendeine Datei“ in diesem Ordner ablegt. Auf diese Logik werde ich später in diesem Blog eingehen.

Wenn wir uns erfolgreich bei unserem Gateway angemeldet und es aktiviert haben, sollten wir in der Lage sein, eine CSV-Datei in den Ordner zu legen und zu prüfen, ob unsere Logic App das neue Ereignis erkennt.

Wenn Sie es richtig eingerichtet haben, sollten Sie unter „Trigger History“ folgendes sehen:

Und dann einen Blick auf die Logic App zu werfen:

Wie Sie sehen können, wird der Inhalt unserer CSV-Datei nun von der Aktion „Get_file_content“ abgerufen.

Wenn Sie aus irgendeinem Grund feststellen, dass die neu erstellte Datei von Ihrer Logic-Anwendung nicht erkannt wird, überprüfen Sie den Abschnitt „API-Verbindung“ in Ihrer Logic-Anwendung, um sicherzustellen, dass Sie den Dateipfad korrekt zugeordnet und alle erforderlichen Anmeldeinformationen angegeben haben, damit sich die Anwendung erfolgreich über das Gateway bei Ihrem lokalen Dateisystem anmelden kann:

Zusammenfassung der Integration Ihrer lokalen Dateisysteme mit SAP Business One und Microsoft Azure – Teil 1

Wir haben uns mit einigen grundlegenden Konzepten von „Legacy“-Ansätzen befasst und mit der Notwendigkeit, lokale Dateisysteme in unsere Lösungen zu integrieren, um Daten von/nach unserem SAP Business One-System zu lesen/schreiben.
Wir haben ein Geschäftsszenario vorgeschlagen, bei dem die Prognosewerte für eine große Anzahl von Artikeln regelmäßig und mit geringem Aufwand in SAP Business One aktualisiert werden müssen, während die Quelldaten ein anderes SAP/Non-SAP-System^{eines Drittanbieters} sein könnten.
Wir haben auch grundlegende Konzepte behandelt, wie man das On-Premise Data Gateway installiert und konfiguriert, um die Konnektivität zwischen jedem lokalen Rechner und Azure Logic Apps herzustellen.
Wir haben das Ereignis „Dateierstellung“ getestet, um zu sehen, ob unsere Logic App es erkennen und den Inhalt der Datei abrufen kann.

Was Sie bei der Integration Ihrer lokalen Dateisysteme mit SAP Business One und Microsoft Azure erwarten können – Teil 2

Hinzufügen einer Validierung zum Dateinamen, um unerwünschte Dateien herauszufiltern, die in unserem Ordner abgelegt werden und unsere Logic App auslösen
Konvertierung des Dateiinhalts in einen lesbaren JSON-Body, mit dem wir arbeiten können
Konvertierung von Wochennummern in Daten, die den ersten Arbeitstag der Woche darstellen, an dem eine Prognose für einen Artikel erstellt werden kann. Dies liegt daran, dass der SAP Business One Service Layer nur Daten akzeptieren kann, wenn er die Aktualisierung der Wochenprognose aufruft, im Gegensatz zur B1-Benutzeroberfläche.
Generierung der Nutzlast für die Vorhersage und Einbindung der Vorhersagegenerierung in unsere Lösung
Abdeckung einiger Konzepte zur Fehlerbehandlung

Teil 2 finden Sie auf der Blog-Seite der SAP Business One Community!