Enterprise Integration mit Dell Boomi (Teil 2 von 5)

Hallo Integrations-Enthusiasten!

Willkommen zum zweiten Teil von Enterprise Integration mit Dell Boomi. Im ersten Teil (hier lesen, falls noch nicht geschehen) hatten wir unser Integrationsszenario festgelegt, das Vorgehen in 7 Schritte unterteilt und außerdem den ersten Schritt der Lösung besprochen. In diesem Beitrag besprechen wir den zweiten Schritt:

1. Die Liste der Produkte abrufen
2. Für jedes Produkt in der Liste ermitteln, ob eine Nachbestellung erforderlich ist
3. Wenn ein Produkt nachbestellt werden muss, die Lieferanteninformationen abrufen
4. Eine Liste der nachzubestellenden Produkte samt Lieferanteninformationen erstellen
5. Die Liste in das CSV-Format konvertieren
6. Die Liste per E-Mail an den Manager senden
7. Den Prozess so konfigurieren, dass er täglich läuft

An diesem Punkt kommen die Produktdetails in Form von Dokumenten herein. Im letzten Blogpost hatten wir beim Ausführen des Prozesses im Test Mode beobachtet, dass für jedes Produkt in unserem Bestand eingehende Daten in Form von Dokumenten vorlagen. Jedes Dokument enthielt die Details genau eines Produkts. Das unterscheidet sich von dem, was wir in SAP CPI beobachtet hatten. Bei CPI wurde die gesamte Produktliste abgerufen und wir mussten eine Splitter Shape verwenden, um diese Liste in Nachrichten mit einzelnen Produktdetails aufzuteilen.

Beim Abrufen dieser Details über unseren OData Client hatten wir Filter gesetzt, um sicherzustellen, dass nur Produkte abgerufen werden, die nicht ausgelistet und nicht bereits nachbestellt sind.

Nun wählen wir die Produkte aus, die nachbestellt werden müssen, sodass nur diese Produkte weiterverarbeitet werden. Die Details der übrigen Produkte können gefahrlos ignoriert werden. Um zu entscheiden, ob ein Produkt nachbestellt werden soll, prüfen wir, ob der Lagerbestand kleiner oder gleich dem Reorder Threshold für dieses Produkt ist. Dafür verwenden wir eine Decision Shape.

Das ähnelt einer Message Router Shape in SAP CPI, bei der der Ausführungspfad auf Basis einer in der Shape definierten Bedingung entschieden wird. Es gibt hier aber einen wesentlichen Unterschied. Wenn wir in Boomi eine Decision Shape hinzufügen, kommt sie mit zwei Routen: true und false. Je nach Gültigkeit der angegebenen Bedingung wird die true- oder die false-Route genommen. In SAP CPI können Sie beim Einsatz einer Router Shape mehr als nur zwei Routen haben:

Das kann sehr nützlich sein, wenn wir auf Szenarien treffen, in denen mehr als zwei Ergebnisse zu erwarten sind. Außerdem können Sie in SAP CPI für jede Route (außer der Default-Route) eine Bedingung definieren, und diese Bedingungen werden in der links angegebenen Reihenfolge ausgewertet. In Boomi hingegen geben wir in der Decision Shape nur eine einzige Bedingung an und können weder mehrere Routen noch deren Auswertungsreihenfolge festlegen.

Was tun wir also, wenn wir für die Auswahl einer Route mehrere Bedingungen auswerten wollen? Lässt sich das in Boomi nicht erreichen, fragen Sie? Das ist in Boomi mit einer "Route" Shape sehr leicht möglich. Die Route Shape sendet Dokumente abhängig vom Wert eines angegebenen Feldes durch unterschiedliche Ausführungspfade. Dieses Feld kann entweder aus einer Document Property oder aus einem Data Profile extrahiert werden. Mit dem Konzept der Data Profiles sind Sie bereits vertraut, über Document Properties sprechen wir später in diesem Blogpost.

Die nächste Frage, die Sie sich vielleicht stellen: Was ist der Unterschied zwischen Route und Decision Shape? Abgesehen von dem offensichtlichen Unterschied, dass die Route Shape mehrere Routen haben kann, die Decision Shape hingegen nicht, ist auch erwähnenswert, dass wir in der Route Shape keine zwei Profilwerte bzw. Document Properties miteinander vergleichen können. Der Vergleich erfolgt in dieser Shape gegen konstante Werte, während die Decision Shape diese Einschränkung nicht hat. In der Praxis werden wir am Ende häufig eine Kombination aus Route und Decision Shapes verwenden. SAP CPI kombiniert die Funktionalität beider Shapes sehr geschickt in einer einzigen "Router" Shape. Das bedeutet allerdings nicht, dass sich dasselbe Ergebnis in Boomi nicht erzielen ließe.

In unserem Szenario müssen wir prüfen, ob der Lagerbestand kleiner oder gleich dem Reorder Threshold für ein bestimmtes Produkt ist. Da beides Profilfelder sind und es nur zwei Ergebnisse geben kann, true oder false, verwenden wir eine Decision Shape statt einer Route Shape.

Sie finden die Decision Shape, indem Sie in der Leiste "Search Shapes" danach suchen.

Ziehen Sie sie per Drag-and-drop neben den Connector auf die Canvas. Als Nächstes konfigurieren wir diese Shape.

Klicken Sie auf das mit "First Value" beschriftete Eingabefeld und wählen Sie als Typ "Profile element".

Wir haben als Profile Type "XML" gewählt. Wählen Sie dann das Profil, das im vorherigen Blogpost von der Query Operation erstellt wurde. Wählen Sie als Element "UnitsInStock". Sobald dieser Parameterwert konfiguriert ist, wiederholen Sie die Schritte, um für den zweiten Wert das Element "ReorderLevel" auszuwählen.

Als Vergleich haben wir "Less Than or Equal To" gewählt. Damit haben wir die Decision Shape so eingerichtet, dass sie prüft, ob der Lagerbestand kleiner oder gleich dem Reorder Threshold für dieses Produkt ist. Nachdem wir nun die Nachrichten herausgefiltert haben, die keine Nachbestellung erfordern (False-Pfad), können wir diese gefahrlos verwerfen.

Diejenigen, die nachbestellt werden müssen, sollen weiterverarbeitet werden. Wir müssen für diese Produkte die Lieferantendetails abrufen und dann Produkt- und Lieferantendetails gemeinsam in einem menschenlesbaren Format darstellen. Ein möglicher Weg besteht darin, die Produktdetails zu extrahieren und als Properties zu speichern. So können wir diese gespeicherten Properties später abrufen und Nachrichten gemäß unserer Anforderung bilden. In SAP CPI hatten wir die Möglichkeit, diese Daten entweder in Message Exchange Properties oder in Message Headers zu speichern. In Dell Boomi haben wir die folgenden Optionen:

1. Document Property: Document Properties (auch Standard Document Properties genannt) enthalten connectorspezifische Informationen wie Dateiname, Größe und alle sonstigen verfügbaren connectorspezifischen Informationen. Document Properties lassen sich an den meisten Stellen als Wert in Parametern abrufen, über die Map-Funktion "Get Document Property" sowie über Custom Scripting. Document Properties können in der Set Properties Shape, über die Map-Funktion "Set Document Property" und über Custom Scripting gesetzt werden.
2. Dynamic Document Property: Dynamic Document Properties (DDP) sind temporäre Properties, die an ein Dokument gebunden sind (statt an den Connector). Sie können einen beliebigen Namen haben und folgen dem Dokument durch den Prozess. DDPs werden pro Dokument gesetzt und abgerufen, wenn ein Batch von Dokumenten eine Shape wie Set Properties oder Map durchläuft.
3. Process Property: Eine Process Property ist eine Sammlung von Schlüssel-Wert-Paaren, die in einer tabellenartigen Struktur gespeichert werden. Wenn Sie globale Variablen haben oder bestimmte Process Properties einschränken möchten, können Sie üblicherweise eine Process Property [Table] verwenden. Eine Process Property kann auf bestimmte erlaubte Werte eingeschränkt werden, ansonsten kann sie im Grunde alles enthalten. Wenn Sie ihr einen Wert geben, können Sie ihn später überall abrufen. Wenn Sie den Wert setzen, wird er für diese Ausführung gespeichert, bis die Ausführung endet, danach fällt er auf den Standardwert zurück.
4. Dynamic Process Property: Dynamic Process Properties (DPP) sind Process Properties, die so lange existieren wie der Prozess. Sie können beliebig benannt werden und lassen sich verwenden, solange Sie denselben Namen verwenden. DPPs nehmen den Wert des zuletzt angekommenen Dokuments an. Wenn ein Batch von 5 Dokumenten eine Set Properties Shape durchläuft, in der Sie die DPP auf ein Element des Dokuments setzen, enthält die DPP den Wert des letzten Dokuments.

Wir verwenden Dynamic Document Properties, weil die Details, die wir speichern möchten, dokumentspezifisch sind und nicht prozess- oder connectorspezifisch. Dafür verwenden wir eine Set Properties Shape. Sie finden diese Shape, indem Sie in der Leiste "Search Shapes" danach suchen.

Ziehen Sie sie per Drag-and-drop neben den Connector auf die Canvas. Als Nächstes konfigurieren wir diese Shape.

Klicken Sie unter "Properties to Set" auf das Symbol "Add Property" (+). Wählen Sie im Popup als Property Type "Dynamic Document Property".

Geben Sie als Property Name "ProductName" an und klicken Sie dann auf "Ok". Damit haben wir Name und Typ der Property festgelegt. Als Nächstes geben wir die Parameter für diese Property an.

Klicken Sie unter "Parameters" auf die Schaltfläche "Add Parameter", dann sehen Sie ein Popup "Parameter Value".

Wählen Sie als Type "Profile Element", als Profile Type "XML" und wählen Sie dann das Profil, das während der OData Query Operation erstellt wurde. Wählen Sie im mit "Element" beschrifteten Eingabefeld "Product Name". Klicken Sie auf "Ok".

Wiederholen Sie diese Schritte und fügen Sie für jedes Produktfeld im Dokument, das wir sichern möchten, eine Dynamic Document Property hinzu.

Danach sieht der resultierende Prozess in etwa so aus:

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

Fazit

Hier legen wir eine Pause ein, um die besprochenen Konzepte vollständig zu verstehen und zu würdigen. In diesem Blogpost haben wir den zweiten Schritt unserer Lösung abgeschlossen. Wir haben die Decision Shape, die Route Shape und die Set Properties Shape kennengelernt und außerdem über die entsprechenden Shapes in SAP CPI gesprochen. Im nächsten Blogpost besprechen wir die nächsten Schritte und lernen mehr über die beteiligten Komponenten. Bis dahin: Auf Wiedersehen und viel Freude beim Lernen!