SAP CI - Datenpersistenz: Variablen und Number Ranges

Wie die meisten Middlewares verbinden wir SAP CI (auch bekannt als SAP Cloud Integration = früher CPI) mit ETL-Operationen: Daten extrahieren, transformieren und laden. Das erweckt den Eindruck, dass Daten SAP CI nur durchlaufen und dort keine Daten gespeichert werden. In den meisten Fällen mag das zutreffen, doch es gibt bestimmte Situationen, in denen wir auch auf SAP CI Daten persistieren wollen.

Zum Beispiel möchten wir vielleicht das Datum des letzten erfolgreichen Laufs eines bestimmten IFlows (Integration Flow) speichern. Das kann erforderlich sein, weil wir dieses Datum in einem anderen IFlow oder in einer weiteren Ausführung desselben IFlows verwenden, etwa um Daten auf Basis dieses Datums abzurufen. Manch einer wird einwenden, dass wir doch einfach in die Message Processing Logs des Tenants schauen können, um das Datum der letzten Ausführung zu finden, oder? Und wenn dem so ist, warum sollten wir diese Daten überhaupt speichern? Aber nicht jede Ausführung ist zwangsläufig erfolgreich, und deshalb lässt sich das Datum des letzten erfolgreichen Laufs nicht direkt aus den Message Processing Logs ermitteln.

Als weiteres Beispiel nehmen wir an, dass es innerhalb eines IFlows mehrere Ausführungspfade gibt und der gewählte Pfad anhand der Eingangsdaten entschieden wird.

Wir möchten den Zeitstempel nur dann speichern, wenn zuletzt Pfad 1 genommen wurde. Für Pfad 2 und Pfad 3 müssen wir diese Information nicht speichern. Ein Blick in die Message Logs hilft uns dann nicht mehr weiter. In solchen Fällen (und in vielen weiteren) benötigen wir einen Mechanismus, um Daten auf CI zu persistieren.

Glücklicherweise bietet SAP CI bereits Funktionen zur Datenpersistenz. Unter der Operations-Sicht Ihres CI-Tenants finden Sie einen Abschnitt mit dem Titel „Manage Stores“. Dort sind die verschiedenen Optionen zur Datenpersistenz von SAP CI zusammengefasst. Schauen wir sie uns eine nach der anderen an.

Variablen

Kommen wir zurück auf das eingangs beschriebene Szenario: Wir möchten das Datum des letzten erfolgreichen Laufs eines bestimmten IFlows speichern. Dafür können wir eine Variable verwenden.

Anlegen einer Variablen

In unserem IFlow müssen wir dazu eine ‚Write Variables‘-Shape einbinden. Mit einem einfachen Camel-Ausdruck wie unten gezeigt können wir Werte in Variablen ablegen. Beachten Sie bitte, dass wir die Variable nicht vorher in der Operations-Sicht anlegen mussten.

Wie bereits besprochen, möchten wir diesen Wert eventuell nur für einen bestimmten Ausführungspfad von mehreren speichern. In dem Fall können wir diese Shape ausschließlich in diesem Pfad platzieren.

Auslesen des Variablenwerts

Um die in Variablen gespeicherten Werte zu lesen, müssen wir die Variablen lediglich wie unten gezeigt referenzieren. Das ist auch in den Message Exchange Properties möglich.

Variablen in der Operations-Sicht prüfen

Um den Wert dieser Variablen einzusehen, gehen Sie in der Operations-Sicht unter Manage Stores auf ‚Variables‘. Sie können die Variable anhand ihres Namens und der ID des zugehörigen Integration Flows identifizieren. Wir können diese Variable im selben IFlow lesen und einen anderen Wert zurückschreiben. Das liegt daran, dass der Gültigkeitsbereich dieser Variablen auf genau diesen IFlow beschränkt ist.

So sieht der Bildschirm Manage Variables aus. Sie sehen eine Liste aller Variablen dieses Tenants samt ihrer Sichtbarkeit, dem Namen des zugehörigen Integration Flows (im Fall von lokalen Variablen), den zugehörigen Datumsangaben und den verfügbaren Optionen.

Gültigkeitsbereich/Sichtbarkeit von Variablen

Variablen haben standardmäßig einen lokalen Gültigkeitsbereich. Das heißt, sie sind nur für einen einzigen IFlow sichtbar und zugänglich.

Aber was, wenn wir diesen Wert aus einem anderen IFlow lesen oder womöglich sogar ändern wollen? In dem Fall müssen wir eine globale Variable verwenden. Wie der Name schon sagt, ist der Gültigkeitsbereich dieser Variablen nicht auf einen einzigen IFlow beschränkt. Diese Variable kann von jedem IFlow gelesen und geändert werden.

Wann ist so etwas nützlich? Zum Beispiel dann, wenn der von einem IFlow geschriebene Wert von einem anderen IFlow für dessen Verarbeitung genutzt werden soll.

Da globale Variablen nicht auf einen IFlow beschränkt sind, ist bei ihnen unter Manage Stores keine IFlow-ID hinterlegt.

Können mehrere Variablen denselben Namen haben?

Ebenfalls zu beachten: Sie können mehrere lokale Variablen mit demselben Namen haben. Das ist möglich, weil sie sich über ihre IFlow-IDs unterscheiden lassen. Für globale Variablen ist das nicht möglich.

Können lokale Variablen denselben Namen wie eine globale Variable haben?

Ja, wir können mehrere lokale Variablen mit demselben Namen haben. Dieser Name kann mit dem einer globalen Variablen übereinstimmen.

Beim Lesen eines Variablenwerts geben wir an, ob wir den Wert einer lokalen oder einer globalen Variablen erhalten möchten. Doppelte Namen sind also kein Problem.

Was passiert, wenn wir Variablen referenzieren, die nicht existieren?

Wenn wir eine Variable referenzieren, die nicht existiert, oder einen falschen Namen angeben, wird kein Wert ausgelesen und der Header beziehungsweise die Property faktisch auf null gesetzt.

Alternativ können wir beim Referenzieren von Variablen Standardwerte angeben, die in solchen Fällen verwendet werden. Existiert die Variable nicht, wird dieser Wert als Ersatz herangezogen und als String-Objekt behandelt.

Löschen einer Variablen

Variablen lassen sich im Bildschirm ‚Manage Variable‘ in der Operations-Sicht Ihres CI-Tenants löschen, indem Sie auf das Löschsymbol rechts neben der Variablenkachel klicken.

Aufbewahrungsdauer einer Variablen

Der Wert einer Variablen wird 400 Tage ab dem Datum der letzten Änderung dieser Variablen gespeichert.

Number Ranges

Kommen wir nun zum nächsten Thema: Number Ranges. Wir wissen bereits, dass es sich um eine Form der Datenpersistenz handelt, aber was genau leisten sie, und was unterscheidet sie?

Number Ranges fungieren als Sequenzen, die unter anderem zur Kennzeichnung von Nachrichten genutzt werden können. Nehmen wir an, in einem bestimmten Integrationsszenario müssen alle Nachrichten an das Zielsystem eine eindeutige Sequenznummer tragen. Genau hier ist eine Number Range nützlich.

Number Ranges anlegen

Vor der Verwendung müssen Number Ranges angelegt werden, wobei Folgendes anzugeben ist:

• Name: Vergeben Sie einen eindeutigen Namen, über den diese Number Range referenziert wird.
• Description: Nicht verpflichtend, aber generell eine gute Praxis, um künftige Verwirrung zu vermeiden.
• Minimum value: Ein nicht negativer Integer-Wert mit maximal 14 Zeichen. Strings/Zeichen sind hier nicht zulässig.
• Minimum value: Ein nicht negativer Integer-Wert mit maximal 14 Zeichen. Strings/Zeichen sind hier nicht zulässig.
• Field Length: Die Länge der von dieser Number Range zurückgegebenen Sequenznummer.
• Rotate: Wird der Maximalwert erreicht, wird der erste Wert als nächste Nummer der Sequenz gewählt.

Number Ranges verwenden

Number Ranges lassen sich verwenden, indem man sie in Message Headers/Exchange Properties referenziert.

Number Ranges können je nach Anforderung eingesetzt werden. Sollen sie nur unter bestimmten Bedingungen und nicht bei jeder Ausführung genutzt werden, können sie innerhalb des zu diesen Bedingungen passenden Pfades referenziert werden, um unnötigen Verbrauch von Nummern in der Sequenz zu vermeiden. Das lässt sich beispielsweise über Router umsetzen.

Kann dieselbe Number Range in mehreren IFlows referenziert werden?

Ja, aber bedenken Sie: Immer wenn sie während einer Ausführung referenziert wird, erhöht sich der Wert um 1. Wenn Sie dieselbe Number Range für mehrere Integration Flows verwenden, kann das zu Verwirrung über scheinbar übersprungene Werte führen. Erwarten die Zielsysteme zudem eine lückenlose Sequenz, wird die Nutzung derselben Number Range in mehreren Integration Flows problematisch.

Kann dieselbe Number Range an mehreren Stellen im selben IFlow referenziert werden?

Ja, auch das ist möglich. Allerdings müssen wir dann mit übersprungenen Werten rechnen. Wird eine Number Range zum Beispiel während einer Ausführung zweimal referenziert, erhöht sich ihr Wert um 2. Unter Berücksichtigung dessen kann dieselbe Number Range mehrfach referenziert und sogar dazu genutzt werden, Schritte von n statt nur 1 zu erzeugen.

Kann der nächste Wert einer Number Range geändert werden?

Wir können den nächsten Wert einer Number Range manuell auf einen bestimmten Wert setzen. Das ist zwar in der Regel nicht empfehlenswert, kann aber in seltenen Fällen angebracht sein. Erreichen lässt sich das über das Bearbeiten der Number Range unter Operations view->Number Ranges.

Was passiert, wenn wir eine Number Range referenzieren, die nicht existiert?

Wenn wir eine Number Range referenzieren, die nicht existiert, oder einen falschen Namen angeben, wird eine Exception im folgenden Format ausgelöst:

com.sap.it.rt.adapter.http.api.exception.HttpResponseException: An internal server error occured: Error while fetching next value for number range: NumberRangeName.

Das unterscheidet sich deutlich davon, was bei fehlenden Variablen passiert, die schlicht null-Werte zurückgeben.

Löschen einer Number Range

Number Ranges lassen sich löschen, indem Sie im Bildschirm ‚Manage Number Ranges‘ in der Operations-Sicht Ihres CI-Tenants auf den Undeploy-Button klicken.

Aufbewahrungsdauer einer Number Range

Number Ranges haben keine feste Aufbewahrungsdauer. Sie bleiben erhalten, bis sie undeployed werden.

Variablen statt Number Ranges verwenden

Wenn man darüber nachdenkt, lassen sich Number Ranges durch Variablen ersetzen. In einem Integration Flow können wir Message Headers/Properties so setzen, dass sie ihren Wert aus Variablen beziehen (und einen Standardwert für den Fall des Fehlens festlegen). Nach der Verwendung kann der Wert je nach Anforderung erhöht oder verringert und in die Variable zurückgeschrieben werden.

Pro:

• Werte lassen sich nicht nur erhöhen, sondern auch verringern. Damit können wir zum Beispiel einen Countdown umsetzen.
• Für komplexere Szenarien lässt sich eine eigene Logik implementieren. Beispiel: Wir können Werte auf Basis bestimmter Bedingungen sowohl erhöhen als auch verringern.
• Mit lokalen Variablen können wir die Nutzung einer so umgesetzten Sequenz einschränken. So hat nur ein bestimmter IFlow Zugriff auf eine Sequenz.
• Wir können die Sequenzwerte jederzeit nach Bedarf über eine in unserem IFlow implementierte Logik ändern.
• Wir können Standardwerte vergeben, die bei Fehlen der angegebenen Variablen genutzt werden.

Contra:

• Die Verantwortung für das Erhöhen/Verringern der Werte liegt beim CI-Entwickler. Er muss alle Möglichkeiten berücksichtigen, damit die korrekte Sequenz eingehalten wird.
• Wir können den Wert von Variablen nicht manuell setzen, wie es bei Number Ranges möglich war.

Ob man das so umsetzen sollte oder nicht, ist diskutabel und bleibt am besten dem Ermessen der Leserinnen und Leser überlassen. In diesem Blogbeitrag haben wir zwei Formen der Datenpersistenz in SAP Cloud Integration und die Unterschiede zwischen ihnen kennengelernt. Das ist alles, was man wissen muss, um mit Variablen und Number Ranges in SAP Cloud Integration zu starten. Im nächsten Beitrag besprechen wir die dritte Form der Datenpersistenz, die Data Stores, und einige weitere interessante Szenarien.