Enterprise Integration mit SAP CPI (Teil 2 von 4)

In diesem Teil lernen wir Splitter, Groovy Script, Message Body, Headers und Exchange Properties kennen, während wir einen Integration Flow zur Steuerung des Meldebestands (Reorder Point, ROP) entwickeln.

Hallo Technologie-Reisende!

Willkommen zum zweiten Teil von Enterprise Integration mit SAP CPI. Im ersten Teil (hier nachlesen, falls noch nicht geschehen) haben wir unser Integrationsszenario erarbeitet, das Vorgehen in 7 Schritte aufgeteilt und außerdem die ersten beiden Schritte der Lösung besprochen.

1. Die Integration so konfigurieren, dass sie täglich läuft
2. Die Liste der Produkte beziehen
3. Für jedes Produkt in der Liste feststellen, ob eine Nachbestellung erforderlich ist
4. Falls das Produkt nachbestellt werden muss, die Lieferanteninformationen beziehen
5. Eine Liste der nachzubestellenden Produkte samt Lieferanteninformationen erstellen
6. Die Liste in das CSV-Format konvertieren
7. Die Liste per E-Mail an den Filialleiter senden

Dabei haben wir das Start Timer und das Request Reply Shape kennengelernt, während wir sie in unserem Integration Flow eingesetzt haben.

An diesem Punkt haben wir die Liste der Produkte, für die noch keine Bestellung ausgelöst wurde. Wir müssen uns den Lagerbestand und den Meldebestand der Produkte ansehen, um zu beurteilen, ob sie nachbestellt werden müssen. Statt die gesamte Produktliste auf einmal zu verarbeiten, teilen wir die Liste in einzelne Produkte auf und führen die Bewertung Produkt für Produkt durch.

Dieser Schritt lässt sich weiter in 2 Teile zerlegen:

1. Ein einzelnes Produkt aus der bezogenen Produktliste herausgreifen
2. Feststellen, ob dieses Produkt nachbestellt werden muss

Ein einzelnes Produkt aus der bezogenen Produktliste herausgreifen

(Verwendete technische Konzepte: Splitter)

Um die Liste für die Bewertung in einzelne Produkte aufzuteilen, verwenden wir einen Splitter.

Ein Splitter ist eine Gruppe von Shapes, mit denen eine zusammengesetzte Nachricht in einzelne Nachrichten aufgeteilt wird. In SAP CPI gibt es verschiedene Splitter-Varianten, etwa den Iterating Splitter, den General Splitter, den EDI Splitter und weitere. Am häufigsten kommen General und Iterating Splitter zum Einsatz, die beide ein allgemeines Dokument in seine Bestandteile zerlegen. Der Unterschied zwischen beiden besteht darin, dass der General Splitter die umschließenden Tags in den Einzelnachrichten beibehält, der Iterating Splitter hingegen nicht. Um diesen Unterschied zu verdeutlichen, betrachten wir ein Beispiel.

Angenommen, die Produktliste wird so geführt:

<Products>
    <Product>
        <Id>1</Id>
        <Name>Biscuit</Name>
    </Product>
    <Product>
        <Id>2</Id>
        <Name>Tea</Name>
    </Product>
    <Product>
        <Id>3</Id>
        <Name>Coffee</Name>
    </Product>
</Products>

Liste der Produkte

Wir können diese Liste entweder mit einem General oder mit einem Iterative Splitter in einzelne Produkte aufteilen. Sehen wir uns das Ergebnis beider Varianten an, um den Unterschied klarer zu verstehen.

Bei Verwendung eines General Splitter mit Aufteilung auf Product erhalten wir das einzelne Produkt so:

<Products>
    <Product>
        <Id>1</Id>
        <Name>Biscuit</Name>
    </Product>
</Products>

Ergebnis: bei Verwendung des General Splitter

Wie Sie sehen, ist das umschließende <Products>-Tag auch nach dem Splitten vorhanden.

Wenn wir einen Iterative Splitter verwenden und auf Product aufteilen, erhalten wir das folgende Ergebnis. Beachten Sie, dass das umschließende <Products>-Tag hier fehlt.

<Product>
    <Id>1</Id>
    <Name>Biscuit</Name>
</Product>

Ergebnis: bei Verwendung des Iterative Splitter

In einem komplexeren Szenario mit tieferer Verschachtelung der Tags fällt der Unterschied deutlich stärker aus, und Sie müssen anhand der Frage entscheiden, welchen Splitter Sie benötigen, ob Sie die umschließenden Tags behalten wollen oder nicht.

Nachdem wir die Grundlagen von Splittern besprochen haben, sehen wir uns die Konfiguration des Splitters für unser Szenario an.

Klicken Sie auf Routing ->Splitter->General Splitter.

Platzieren Sie das Splitter-Shape zwischen dem Request Reply Shape und dem End Message Shape:

Wir hätten hier ebenso gut einen Iterative Splitter verwenden können, aber unser Szenario ist so einfach, dass es kaum einen Unterschied macht. Die Splitter-Konfiguration sieht so aus:

Konfiguration für den Splitter

Wir wollen die Liste in einzelne Produkte zerlegen, und da die Liste im XML-Format vorliegt, können wir dafür einen XPath-Ausdruck verwenden. Deshalb haben wir Expression Type auf Xpath gesetzt. Die Produktdetails sind vom Tag <Product> umschlossen und alle Produkte von <Products>. Daher lautet der verwendete XPath Expression: /Products/Product. Außerdem wollen wir immer nur die Details eines Produkts auf einmal verarbeiten, deshalb setzen wir den Parameter Grouping auf 1. Wenn wir Streaming aktivieren, wartet der Splitter nicht, bis der komplette Datensatz geladen ist, bevor er mit dem Splitten beginnt. Sobald die Daten in kleinere Teile zerlegt sind, werden diese Teile sequenziell verarbeitet. Besteht keine Abhängigkeit zwischen diesen Teilen, können wir Parallel Processing aktivieren. Für unser Szenario aktivieren wir die parallele Verarbeitung, da die Daten jedes Produkts unabhängig darauf geprüft werden, ob eine Nachbestellung nötig ist. Die Parameter Number of Concurrent Processes und Timeout belassen wir auf den Standardwerten. Es kann passieren, dass in einem dieser Teile eine Exception auftritt. Indem wir Stop on Exception aktivieren, stellen wir sicher, dass die übrigen Teile nicht weiter verarbeitet werden.

Nachdem wir den Splitter konfiguriert haben, wird die in den vorherigen Schritten bezogene Produktliste in einzelne Produkte aufgeteilt. Der nächste Schritt besteht darin, zu beurteilen, ob das Produkt nachbestellt werden muss. Dafür verwenden wir ein Groovy Script.

Feststellen, ob dieses Produkt nachbestellt werden muss

(Verwendete technische Konzepte: Groovy Script)

Scripting ist eine der mächtigsten Funktionen von SAP CPI. Wenn sich keines der vorhandenen Shapes so konfigurieren lässt, dass es die Daten gemäß unseren Anforderungen verarbeitet, können wir ein Script entwickeln, das unsere Logik umsetzt.

In unserem Szenario verwenden wir ein Groovy Script, um zu beurteilen, ob ein Produkt nachbestellt werden muss. Um Ihrem Integration Flow ein Groovy Script hinzuzufügen, klicken Sie auf Message Transformers->Script->Groovy Script

Platzieren Sie das Shape zwischen dem General Splitter und dem End Message Shape.

An diesem Punkt haben wir das Shape in unseren Integration Flow eingefügt, aber dem Groovy Script Shape ist noch kein Script hinterlegt. Um ein Script hinzuzufügen, klicken Sie auf das Shape und dann auf das +-Symbol rechts daneben.

unser iFlow mit Splitter und Groovy Script

Wenn Sie auf die +-Schaltfläche klicken, wird dem Shape ein neues Script hinzugefügt:

Wie Sie sehen, enthält dieses Script eine Methode namens 'processData', die die eingehende Message als Argument entgegennimmt und die Message nach der Verarbeitung zurückgibt. Zudem ist die Methode in 3 Abschnitte unterteilt: Body, Headers und Properties. Jede Message im Integration Flow besitzt unter anderem einen Body, Message Headers und Message Exchange Properties. Der Message Body enthält den Payload. In unserem Szenario enthält er die Produktdaten, die wir in einem vorherigen Schritt mit dem Request Reply Shape bezogen haben.

Message Headers enthalten in der Regel Metadaten und lassen sich zusammen mit den Message Exchange Properties nutzen, um Daten abzulegen, die nicht Teil des Body sind, aber für die Verarbeitung benötigt werden. Beispielsweise können wir nach der Bewertung der Produktdaten einen Parameter in Headers/Properties ablegen, der anzeigt, ob eine Nachbestellung erforderlich ist.

Der Unterschied zwischen Daten im Header und Daten in einer Property liegt im Gültigkeitsbereich. In einer Property gespeicherte Daten existieren nur, solange sich die Message in der Middleware befindet, und werden nicht an den Receiver weitergegeben, während im Header gespeicherte Daten an den Receiver weitergereicht werden.

Nachfolgend das Script, das wir verwenden:

import com.sap.gateway.ip.core.customdev.util.Message;
import groovy.util.XmlSlurper ;
import java.util.HashMap;
import groovy.xml.XmlUtil;

def Message processData(Message message) {
       def body = message.getBody(java.lang.String) as String;
       def reorderLevel;
       def unitsInStock;
       def product= new XmlSlurper().parseText(body);
       reorderLevel=product.Product.ReorderLevel.text().toInteger();
       unitsInStock=product.Product.UnitsInStock.text().toInteger();
       if(unitsInStock<=reorderLevel){
          message.setProperty("needsReorder", "true");
       }
       else{
           message.setProperty("needsReorder", "false");
       }
       return message;
}

In diesem Script beziehen wir zunächst den Message Body mit den Produktdetails als String. Beachten Sie, dass das Script Shape hinter dem Splitter platziert wurde. Der Message Body enthält daher jeweils die Details eines einzelnen Produkts, und mehrere solcher Segmente werden parallel verarbeitet.

Wir wandeln den String-Body mit dem XML Slurper in einen XML-Node um. Der XML Slurper wandelt den String in einen Dokumentenbaum um, der sich ähnlich wie mit XPath-Ausdrücken durchlaufen lässt.

Wir lesen den Reorder Level und die Units in Stock der Produkte aus und vergleichen sie. Ist der Lagerbestand kleiner oder gleich dem Meldebestand, der hier als Schwellenwert dient, setzen wir die Message Exchange Property needsReorder auf true. Andernfalls setzen wir sie auf false. Mit diesem Script können wir also bestimmen, ob ein Produkt nachbestellt werden muss oder nicht.

Sanft, keine Eile! -Portia, Der Kaufmann von Venedig

Getreu der Tugend, langsam und stetig voranzuschreiten, legen wir hier eine Pause ein. In diesem Blogbeitrag haben wir Splitter kennengelernt und auch die Unterschiede zwischen General und Iterative Splitter. Außerdem haben wir beim Aufbau unseres Integration Flow Groovy Script, Message Headers und Exchange Properties kennengelernt. Im nächsten Blogbeitrag setzen wir unsere Reise durch die Enterprise Integration mit SAP CPI fort. Bis dahin: auf Wiedersehen und viel Freude beim Lernen!