Hallo Integrationsbegeisterte!

Willkommen zum zweiten Teil der Enterprise Integration mit Dell Boomi. Im ersten Teil (hier lesen, falls Sie es noch nicht getan haben) hatten wir unser Integrationsszenario festgelegt, den Ansatz in 7 Schritte unterteilt und auch den ersten Schritt der Lösung besprochen. In diesem Beitrag werden wir den zweiten Schritt besprechen:

1. Erhalten Sie die Liste der Produkte
2. Ermitteln Sie für jedes Produkt in der Liste, ob eine Nachbestellung erforderlich ist.
3. Wenn das Produkt nachbestellt werden muss, Informationen über den Lieferanten einholen
4. Erstellen Sie eine Liste der nachzubestellenden Produkte zusammen mit Lieferanteninformationen
5. Liste in csv-Format umwandeln
6. Liste per E-Mail an den Manager senden
7. Konfigurieren Sie den Prozess so, dass er jeden Tag ausgeführt wird

Zu diesem Zeitpunkt kommen die Produktdaten in Form von Dokumenten an. Im letzten Blog-Beitrag hatten wir bei der Ausführung des Prozesses im Testmodus festgestellt, dass wir für jedes Produkt in unserem Bestand eingehende Daten in Form von Dokumenten hatten. Jedes Dokument enthielt Details zu einem einzigen Produkt. Dies ist ein Unterschied zu dem, was wir in SAP CPI beobachtet hatten. Im Falle von CPI wurde die gesamte Produktliste abgerufen, und wir mussten einen Splitter Shape verwenden, um diese Liste in Nachrichten mit einzelnen Produktdetails aufzuteilen.

Beim Abrufen dieser Details mit unserem OData-Client haben wir Filter eingesetzt, um sicherzustellen, dass nur Produkte abgerufen werden, die nicht ausgelaufen sind und nicht bereits nachbestellt wurden.

Jetzt werden wir die Produkte auswählen, die nachbestellt werden müssen, so dass nur diese Produkte weiterverarbeitet werden. Die Angaben zu den anderen Produkten können wir getrost ignorieren. Um zu entscheiden, ob ein Produkt nachbestellt werden soll, prüfen wir, ob die auf Lager befindlichen Einheiten kleiner oder gleich dem Schwellenwert für die Nachbestellung dieses Produkts sind. Zu diesem Zweck wird eine Entscheidungsform verwendet.

Dies ist vergleichbar mit einem Message-Router-Shape in SAP CPI, bei dem der Ausführungspfad auf der Grundlage einer im Shape definierten Bedingung festgelegt wird. Allerdings gibt es hier einen großen Unterschied. Wenn wir in Boomi ein Entscheidungsshape hinzufügen, gibt es zwei Wege: wahr und falsch. Je nach Gültigkeit der angegebenen Bedingung wird der Weg wahr oder falsch gewählt. In SAP CPI können Sie mehr als nur zwei Routen haben, wenn Sie ein Router-Shape verwenden:

Dies kann sehr nützlich sein, wenn wir mit Szenarien konfrontiert sind, bei denen wir mehr als zwei Ergebnisse erwarten können. Außerdem können Sie in SAP CPI für jede Route (außer der Standardroute) eine Bedingung definieren, und diese Bedingungen werden in der auf der linken Seite angegebenen Reihenfolge ausgewertet. In Boomi hingegen geben wir nur eine Bedingung in Entscheidungsform an, und wir können nicht mehrere Routen und deren Reihenfolge der Auswertung angeben.

Was tun wir also, wenn wir mehrere Bedingungen für die Auswahl einer Route auswerten wollen? Ist das in Boomi nicht möglich, werden Sie fragen? Dies ist in Boomi sehr einfach mit Hilfe eines "Route" Shapes zu erreichen. Das Route-Shape sendet Dokumente auf der Grundlage des Wertes eines bestimmten Feldes durch verschiedene Ausführungspfade. Dieses Feld kann entweder aus einer Dokumenteigenschaft oder einem Datenprofil extrahiert werden. Mit dem Konzept der Datenprofile sind Sie bereits vertraut, und wir werden später in diesem Blogbeitrag über Dokumenteigenschaften sprechen.

Die nächste Frage, die Sie sich vielleicht stellen, ist: Was ist der Unterschied zwischen Route und Decision Shape? Nun, abgesehen von dem offensichtlichen Unterschied, dass das Shape "Route" mehrere Routen haben kann, das Shape "Entscheidung" dagegen nicht, ist es auch nichts wert, dass wir im Shape "Route" nicht zwei Profilwerte/Dokumenteneigenschaften vergleichen können. Der Vergleich in diesem Shape erfolgt anhand konstanter Werte, während das Decision-Shape diese Einschränkung nicht aufweist. In einem praktischen Szenario kann es vorkommen, dass wir eine Kombination aus Route und Decision Shapes verwenden. SAP CPI kombiniert die Funktionalität dieser beiden Shapes sehr geschickt in einem einzigen 'Router'-Shape. Das bedeutet jedoch nicht, dass dasselbe Ergebnis nicht auch in Boomi erzielt werden kann.

In unserem Szenario müssen wir auswerten, ob die auf Lager befindlichen Einheiten kleiner oder gleich dem Bestellschwellenwert für ein bestimmtes Produkt sind. Da beides Profilfelder sind und es nur zwei Ergebnisse geben kann, nämlich wahr oder falsch, werden wir ein Entscheidungsformular anstelle eines Routenformulars verwenden.

Sie können die Form der Entscheidung finden, indem Sie in der Leiste "Formen suchen" nach ihr suchen.

Ziehen Sie sie und platzieren Sie sie neben dem Verbindungsstück auf der Leinwand. Als nächstes werden wir diese Form konfigurieren.

Klicken Sie auf das Eingabefeld mit der Bezeichnung "Erster Wert" und wählen Sie als Typ "Profilelement".

Wir haben als Profiltyp XML ausgewählt. Wählen Sie dann das Profil aus, das im vorherigen Blogbeitrag mit Query Operation erstellt wurde. Wählen Sie das Element "UnitsInStock". Sobald dieser Parameterwert konfiguriert wurde, wiederholen Sie die Schritte, um das Element "ReorderLevel" für den zweiten Wert auszuwählen.

Wir haben den Vergleich als "Kleiner als oder gleich" ausgewählt. So haben wir die Entscheidungsform so eingerichtet, dass sie prüft, ob die auf Lager befindlichen Einheiten kleiner oder gleich dem Schwellenwert für die Nachbestellung dieses Produkts sind. Da wir nun die Meldungen herausgefiltert haben, die nicht nachbestellt werden müssen (falscher Pfad), können wir diese sicher verwerfen.

Diejenigen, die nachbestellt werden müssen, sollten weiterverarbeitet werden. Wir müssen für diese Produkte Lieferantendetails erhalten und dann Produkt- und Lieferantendetails zusammen in einem für Menschen lesbaren Format darstellen. Eine Möglichkeit besteht darin, die Produktdaten zu extrahieren und als Eigenschaften zu speichern. Auf diese Weise können wir diese gespeicherten Eigenschaften später abrufen und die Nachrichten entsprechend unseren Anforderungen gestalten. In SAP CPI hatten wir die Möglichkeit, diese Daten entweder in den Eigenschaften des Nachrichtenaustauschs oder in den Nachrichtenköpfen zu speichern. In Dell Boomi haben wir die folgenden Optionen:

1. Dokumenteneigenschaft: Dokumenteneigenschaften (auch Standarddokumenteneigenschaften genannt) enthalten anschlussspezifische Informationen wie Dateiname, Größe und alle anderen anschlussspezifischen Informationen, die verfügbar sind. Dokumenteigenschaften können als Wert in Parametern an den meisten Stellen, in der Zuordnungsfunktion "Dokumenteigenschaft abrufen" und im benutzerdefinierten Scripting abgerufen werden. Dokumenteigenschaften können in der Form "Set Properties", in der Zuordnungsfunktion "Set Document Property" und in benutzerdefinierten Skripten festgelegt werden.
2. Dynamische Dokumenteigenschaft: Dynamische Dokumenteigenschaften (DDP) sind temporäre Eigenschaften, die an ein Dokument gebunden sind (im Gegensatz zu denen, die an den Konnektor gebunden sind). Sie können einen beliebigen Namen haben und folgen dem Dokument durch den Prozess. DDPs werden für jedes Dokument festgelegt und abgerufen, wenn ein Stapel von Dokumenten ein Shape durchläuft, wie z.B. ein Set Properties oder Map
3. Prozesseigenschaft: Eine Prozesseigenschaft ist eine Sammlung von Schlüssel/Wertpaaren, die in einer tabellenartigen Struktur gespeichert sind. Wenn Sie globale Variablen haben oder bestimmte Prozesseigenschaften einschränken wollen, können Sie normalerweise eine Prozesseigenschaft [Tabelle] verwenden. Eine Prozesseigenschaft kann auf bestimmte zulässige Werte beschränkt werden, ansonsten kann sie grundsätzlich alles sein. Wenn Sie ihnen einen Wert geben, können Sie sie später überall abrufen. Wenn Sie den Wert festlegen, können Sie ihn für diese Ausführung speichern, bis die Ausführung beendet ist, und er wird dann auf den Standardwert zurückgesetzt.
4. Dynamische Prozesseigenschaften: Dynamische Prozesseigenschaften (DPP) sind Prozesseigenschaften, die so lange bestehen, wie der Prozess lebt. Sie können beliebig benannt werden und können so lange verwendet werden, wie Sie denselben Namen verwenden. DPPs nehmen den Wert des letzten Dokuments an, das sie erreicht hat. Wenn Sie einen Stapel von 5 Dokumenten zu einem Eigenschaftssatz führen, bei dem Sie die DPP als Element des Dokuments festlegen, wird die DPP den Wert des letzten Dokuments annehmen

Wir werden dynamische Dokumenteigenschaften verwenden, da die Details, die wir speichern wollen, spezifisch für die Dokumente und nicht prozess- oder verbindungsspezifisch sind. Zu diesem Zweck werden wir ein Shape mit festgelegten Eigenschaften verwenden. Sie können dieses Shape finden, indem Sie in der Shape-Suchleiste danach suchen.

Ziehen Sie sie und platzieren Sie sie neben dem Verbindungsstück auf der Leinwand. Als nächstes werden wir diese Form konfigurieren.

Klicken Sie unter Einzustellende Eigenschaften auf das Symbol 'Eigenschaft hinzufügen' (+). Wählen Sie im Popup-Fenster als Eigenschaftstyp "Dynamische Dokumenteigenschaft".

Geben Sie der Eigenschaft den Namen "ProductName" und klicken Sie auf Ok. Jetzt haben wir den Namen und den Typ der Eigenschaft festgelegt. Als nächstes werden wir die Parameter für diese Eigenschaft angeben.

Klicken Sie auf die Schaltfläche "Parameter hinzufügen" unter "Parameter", dann wird ein Popup-Fenster "Parameterwert" angezeigt.

Wählen Sie Typ als Profilelement, Profiltyp als XML, und wählen Sie dann das Profil aus, das während der OData-Abfrage erstellt wurde. Wählen Sie Produktname in dem Eingabefeld mit der Bezeichnung Element. Klicken Sie auf Ok.

Wiederholen Sie diese Schritte und fügen Sie die dynamische Dokumenteigenschaft für jedes Produktfeld in dem Dokument hinzu, das Sie speichern möchten.

Danach sieht der Prozess in etwa so aus:

Wir können den Prozess erneut testen, um zu prüfen, welche Dokumente durch diese Pfade fließen.

Schlussfolgerung

An dieser Stelle werden wir eine Pause einlegen, um die besprochenen Konzepte vollständig zu verstehen und zu würdigen. In diesem Blogbeitrag haben wir den zweiten Schritt unserer Lösung abgeschlossen. Wir haben uns mit den Shapes Decision Shape, Route Shape und Set Properties Shape vertraut gemacht und auch über die entsprechenden Shapes in SAP CPI gesprochen. Im nächsten Blogbeitrag werden wir die nächsten Schritte besprechen und mehr über die beteiligten Komponenten erfahren. Bis dahin, auf Wiedersehen und viel Spaß beim Lernen!