Es ist schon eine Weile her, dass ich mein erstes ereignisgesteuertes Szenario in SAP Business One implementiert habe. Seit ich angefangen habe, bin ich auf ein „Meer“ von Möglichkeiten/Plattformen/Diensten gestoßen, die so ziemlich den gleichen Ansatz bieten, wie man das erreichen kann, und von denen jeder seine eigenen Vor- und Nachteile hat.

Es besteht kein Zweifel daran, dass die Branche gut entwickelt ist und zahlreiche Möglichkeiten bietet, Dinge zu erledigen, und ich bin ein wenig „übereifrig“, wenn es darum geht, neue Technologien zu erlernen (schließlich ist das unser Brot und Butter). Aber wenn ich mich hinsetze, um einen Projektentwurf zu schreiben, versuche ich, mich an den „One-Stop“-Ansatz zu halten, bei dem die Wiederverwendung von Werkzeugen und Diensten, die in die B1-Anwendung selbst eingebettet sind, wahrscheinlich ganz oben auf meiner Liste stehen würde.

Diese Tools sind seither auf dem Markt und haben sich im Laufe der Jahre weiterentwickelt und sind nicht nur nicht veraltet, sondern haben auch ihre Fähigkeiten und Leistungen erweitert.

Verstehen Sie mich nicht falsch: Ich denke, dass die SAP BTP-Plattform beispielsweise unendlich viele Möglichkeiten bietet, wenn es um die Nutzung von REST-Webdiensten geht, die mit unseren SAP-Systemen interagieren können, und auch die Wiederverwendung einiger der leistungsfähigsten Konnektoren zur Integration mit anderen SAP-/Nicht-SAP-Systemen sowie zur Erweiterung unserer Geschäftsanwendungen und -prozesse ermöglicht. Das SAP BTP nutzt auch hochmoderne Dienste wie AI Builders und Fiori Apps Tools. Es geht hier also nicht darum, das SAP BTP, das seinen Platz zu Recht verdient hat, schlecht zu machen, sondern lediglich darum, festzustellen, dass das SAP BTP nicht das einzige Spiel in der Stadt ist.

Diejenigen von Ihnen, die versucht haben, sich durch diesen Ozean von Daten auf der SAP BTP-Plattform zu bewegen, haben wahrscheinlich schon erkannt, dass BTP sehr stark auf S4/HANA ausgerichtet ist und nicht speziell auf SAP Business One-Entwickler zugeschnitten ist.

Darüber hinaus weist das BTP einige offensichtliche Defizite auf:

1. Langwierige und mühsame Einrichtung – das Hinzufügen eines Abonnements/einer Instanz/einer Berechtigung kostet Zeit, und in den meisten Fällen klappt es nicht beim ersten Mal.
2. Die Preisstufen sind für KMU-Kunden einfach nicht geeignet. Solange Sie das „kostenlose“ Abonnement für nicht-produktive Umgebungen verwenden, sollte alles in Ordnung sein, aber sobald Sie in die „Pay-As-You-Go“-Abonnementstufen übergehen und in die Produktion gehen, wird es in den meisten Fällen zu einem „Overkill“ für jedes SMB-basierte Projekt und auch ziemlich kostspielig.
3. Es hat kein eingebautes Bewusstsein für die B1-Objekte. Wir können sie wie jede andere API verwenden und aufrufen, um ihr mitzuteilen, was wir abrufen wollen.

Kommen wir also gleich zur Sache: Wie können wir ein Ereignisweiterleitungsszenario implementieren und die erhaltenen Informationen nutzen, um andere B1-bezogene Lösungen auszulösen/zu erstellen, ohne die Dinge zu sehr zu verkomplizieren?

Normalerweise müssten wir Folgendes tun:

1. Einrichten einer SAP Event Mesh-Instanz auf BTP
2. Eine SAP CAP-Anwendung, die die Ereignisse in BTP verarbeitet (normalerweise für den Aufbau von
   Unternehmen
   -Grade-Dienste und -Anwendungen, was wiederum bei SAP B1 ein „Schlag ins Wasser“ ist)
3. Wir müssten einen zusätzlichen Schritt programmieren, um das Token abzurufen, damit wir uns gegenüber der SAP Event Mesh-Instanz auf der SAP BTP-Plattform authentifizieren können.

Die architektonische Übersicht würde wie folgt aussehen:

Wie wäre es, wenn ich Ihnen sage, dass wir den Teil überspringen können, in dem wir das BTP abonnieren und direkt zu unserem B1-Integrations-Framework (B1If) gehen, um diese Ereignisse zu konsumieren und sie weiter zu nutzen, um das Verhalten unserer B1-Anwendung mit Microsoft Azure zu erweitern?

Vorausgesetzt, Sie haben B1iF installiert und in Ihrer Umgebung korrekt eingerichtet, haben Sie einen guten Start hingelegt.

Ich würde Ihnen dringend raten, die folgenden Schritte zu unternehmen, um sicherzustellen, dass Sie alle Voraussetzungen erfüllen:

• Einrichten der B1iF-Entwicklungsumgebung.
• Verständnis der B1iF-Grundlagen und technischer Überblick.
• Einrichtung der SLD-Konfiguration für Ihr Unternehmen.
• Konfigurieren Sie die Konnektivität zum B1 Service Layer (wir möchten uns nicht nur auf die DI-API verlassen, die die „alte Generation“ der Erweiterungs-API für die Nutzung von SAP Business One-Daten und -Diensten ist)

** Wenn Sie Probleme mit der Konfiguration des B1iF haben, können Sie sich gerne an mich wenden, und ich werde Sie gerne beraten und unterstützen**

Schließlich möchten wir unseren B1iF Event Sender so einrichten, dass er Ereignisse auslöst.

Die B1iF-Best-Practices schreiben vor, dass wir uns an Folgendes halten:

1) Stellen Sie sicher, dass Sie auf das Integration Framework 2.0 statt 1.0 zugreifen:

Dies bringt mehrere entscheidende Vorteile mit sich:

• Hinzu kommt das Integrationsframework – alle Programmiermodelle können gleichzeitig und parallel laufen.
• Optimiert für Cloud Computing
• Integrierte Mehrmandantenfähigkeit – Mehr Flexibilität bei der Bereitstellung von Szenarien
• Entwickelt für alle Integrationsentwickler
  • Höhere Flexibilität
  • Mehr Kontrolle und Transparenz bei der Entwicklung von Integrationsinhalten
• „Klassische“ Entwickler fühlen sich durch die neue browserbasierte IDE wohler
• Bis zu 10 Mal schneller – läuft direkt auf der Integrationsplattform
• Ersetzt nicht das derzeitige Programmiermodell Migration bestehender Szenarienpakete nicht erforderlich, es sei denn, Sie möchten die Mandantenfähigkeit in Cloud-Umgebungen nutzen

2. Vergewissern Sie sich, dass alle Ihre SLD-Verbindungen korrekt getestet wurden:

Wenn eine dieser Verbindungen unterbrochen wird, gefährdet dies den Prozess und verhindert später die Kommunikation mit dem HANA-Server / Service Layer. Daher sollten Sie sicherstellen, dass alle Verbindungen fehlerfrei sind, und, falls dies nicht der Fall ist, die Verbindungszeichenfolgen neu konfigurieren.

3) Stellen Sie sicher, dass B1i-Ereignisse gefiltert werden, indem Sie zu Wartung -> B1 Event Filter navigieren und die Option „B1i User Filter Switched On“ (B1i-Benutzerfilter eingeschaltet ) aktivieren – so stellen Sie sicher, dass Sie alle Systemereignisse loswerden, die Sie nicht hören wollen.

Beachten Sie, dass Sie diese Konfiguration auch in die Version 1.X einbinden können, indem Sie sie direkt aus der Version 2.0 aufrufen (unter Extras ->Version 1) und zum Ereignissender-Assistenten navigieren.

Hier sollten Sie auch Ihre B1-Objekt-IDs für alle Objekte angeben, für die Sie Ereignisse abrufen möchten

Die vollständige Liste der B1-Objekte finden Sie am Ende dieses Themas

Alternativ können Sie diesen Wert auch direkt aus der Anwendung B1 abrufen, indem Sie den Abfragegenerator starten und die Spalte „<table_name>“.“ ObjType“ Spalte:

4) Der wichtigste Schritt besteht darin, zu testen, dass IHRE Ereignisse NICHT herausgefiltert werden, sondern an den B1 Event Monitor weitergeleitet werden, wenn Ihr Szenario ausgelöst wird.

In meinem Fall habe ich einfach einen Geschäftspartner erstellt und die Anzeige aktualisiert, um zu sehen, dass B1iF das Ereignis abfangen konnte:

Hinweis: Der Testlauf wird nur dann erfolgreich sein, wenn Sie sicherstellen, dass Sie eine neue Verteilung zum „Verteilungs-Panel“ Ihres Szenarios hinzufügen und ein gültiges Sender-/Empfängersystem aus Ihrem SLD zuweisen – dieses Fenster ist die neue (und coole!) Funktion in Version 2.0, die es Ihnen ermöglicht, einen einzigen Überblick über alle Ihre Szenario-Artefakte zu erhalten.

Sobald wir sicher sind, dass unser Ereignis-Sender unsere Ereignisse korrekt verarbeitet, können wir mit dem Aufbau unseres Szenarios in BizFlow fortfahren.

Nun ist es wichtig, dass wir genau verstehen, was wir hier erreichen wollen:

Wir möchten lediglich, dass B1iF jedes Ereignis, das unsere Filterkriterien erfüllt, an einen externen HTTP-WebHook-basierten Workflow in Form einer XML-Nutzlast weiterleitet, aus der wir dann Daten analysieren und abrufen können.

Das ist alles, was es zu sagen gibt!

Wenn Sie sich fragen „Warum?“, dann ist die Antwort ziemlich einfach:

Mit
Azure Logic Apps
und dem integrierten HTTP-Webhook-Connector können wir automatisierte Aufgaben und Workflows erstellen, die einen Service-Endpunkt abonnieren, indem sie eine Callback-URL registrieren, auf bestimmte Ereignisse warten und auf der Grundlage dieser Ereignisse ausgeführt werden, anstatt diesen Endpunkt regelmäßig zu überprüfen oder abzufragen.

Dies ist besonders nützlich und vorteilhaft in Fällen, in denen PaaS (Platforms as a Service) wie Microsoft-Azure pro Ausführung berechnet werden.

Stellen Sie sich einmal vor, wie viele Ausführungen innerhalb eines 24-Stunden-Zeitraums ausgelöst werden, wenn ein Workflow alle 15 Minuten ausgeführt werden soll (96 Ausführungen), im Vergleich zu 3 Ausführungen für die 3 neuen Geschäftspartner, die Sie erstellt haben, wenn der Workflow nur unmittelbar nach dem Hinzufügen des Geschäftspartnerdatensatzes zur B1-Datenbank ausgelöst.

Dies wirkt sich direkt auf den Verbrauch und damit auf die Höhe der Abrechnung am Monatsende aus.

Im nächsten Teil dieses Blogs werde ich die Logic App-Seite unseres Projekts behandeln.

Lassen Sie uns zunächst unser Szenario und die Szenarioschritte abschließen.

Unser BizFlow-Diagramm wird ein relativ einfaches Diagramm sein:

Wir betrachten einen typischen „asynchronen“ Prozessmodus, bei dem das Ereignis ausgelöst, abgerufen und dann an das Inbound Atom weitergeleitet wird, wo es dann über ein XSLT Atom transformiert wird, um in unserem HTTPCall Atom verwendet zu werden.

Beachten Sie, dass B1iF die Daten immer intern als XML verarbeitet. In unserem Fall möchten wir also nur die XML-Darstellung unseres Ereignisses vom Sendersystem (Ereignissender) abrufen und sie als Teil unseres HTTP-Aufrufkörpers verwenden.

Eine gute Möglichkeit, die Struktur der Nachrichten während der Laufzeit zu analysieren, ist die Verwendung des B1iF-Debuggers:

Unser XSL-Transformations-Atom muss nur angepasst werden, um die eingehende XML-Nutzlast des B1-Ereignisses zu holen, wo dann ein XPATH-Ausdruck zu unserem HTTPCall-Atom hinzugefügt wird.

Wir werden zu unserem HttpCall Atom zurückkehren, nachdem wir unsere Diskussion über Logic App (WebHook) in Teil 2 dieses Blogs abgeschlossen haben.

Lassen Sie uns zusammenfassen, was wir bisher erreicht haben:

1. Wir haben unser Hauptthema – Ereigniserstellung und Weiterleitung in SAP Business One – vorgestellt.
2. Wir haben einige der gängigsten Methoden zur Ereignisbehandlung behandelt und die Vor- und Nachteile der einzelnen Ansätze erläutert.
3. Wir sind einige der grundlegenden Einstellungen und Konfigurationen des SAP Business One Integration Frameworks durchgegangen
4. Wir haben über die neuen Verbesserungen der B1iF-Version 2.0 berichtet
5. Wir erhielten einen detaillierten Überblick über die Einrichtung des Ereignissenders und lernten, wie man erfolgreich Filterkriterien für B1-Objekte festlegt, für die man Ereignisse erhalten möchte
6. Wir haben gelernt, wie man eine Entwicklung über das „Deployment Panel“ unseres Szenarios einsetzt und ein SLD-Sender/Empfänger-System zuweist.
7. Wir haben HTTP WebHooks besprochen und verstanden, dass sie eine wichtige Rolle bei der Verringerung der Anzahl von Workflow-Ausführungen spielen, die sich letztendlich auf unsere Rechnungsstellung auswirken.
8. Wir haben die verschiedenen Schritte des Szenarios durchlaufen, um eine eingehende Nachricht (Ereignis) zu empfangen, sie zu verarbeiten und umzuwandeln und sie dann für HTTPCall Atom vorzubereiten.

Besuchen Sie uns auf der SAP Business One Community Blog Seite für Teil 2 der Implementierung eines Event-Forwarding Mechanismus mit SAP Business One B1iF und Microsoft Azure.

Liste der SAP Business One-Objekttypen