Unbekannte Header und Properties in SAP CPI erkennen, bevor sie still scheitern

Ein Header, der nie gesetzt wird, hält einen iFlow in SAP CPI nicht an. Der Ausdruck, der ihn liest, gibt einen leeren Wert zurück, eine Router-Bedingung wird falsch, ein Feld in der Payload bleibt leer, und die Nachricht läuft weiter. Der Fehler, falls es einen gibt, zeigt sich einige Schritte später oder erst im empfangenden System.

Dieser Artikel erklärt, warum fehlende Header und Exchange Properties still scheitern, welche Ursachen immer wieder vorkommen und welche Prüfungen sie finden, bevor es eine Nachricht tut.

Warum ein fehlender Name keinen Fehler auslöst

Apache Camel behandelt einen Header oder eine Property, die nicht vorhanden ist, als leer, nicht als Fehler. Für optionale Werte ist das praktisch, und genau deshalb kann ein Tippfehler monatelang in einem iFlow überleben. Was Sie sehen, hängt davon ab, wo der Name gelesen wird:

• Ein Content-Modifier-Wert wie ${property.orderId} wird zu einem leeren String.
• Eine Router- oder Filter-Bedingung wie ${header.orderType} = 'EXPRESS' ergibt false, sodass die Nachricht eine andere Route nimmt, oft die Default-Route.
• Eine Receiver-Adresse wie /orders/${property.orderId} ruft /orders/ auf, und das empfangende System antwortet mit einem Fehler, der die fehlende Property nicht erwähnt.
• In einem Groovy-Skript gibt message.getHeader("orderId", String) null zurück, und das Skript scheitert später mit einer NullPointerException oder schreibt den Text null in die Payload.

Die üblichen Ursachen

• Ein Tippfehler oder falsche Groß-/Kleinschreibung in einem Property-Namen: Namen von Exchange Properties unterscheiden Groß- und Kleinschreibung, daher sind orderID und orderId zwei verschiedene Properties. Header-Namen tun das nicht.
• Ein überzähliges Leerzeichen, zum Beispiel ${header.orderId }: Der Name mit Leerzeichen ist ein anderer Name.
• Ein Wert, der nur auf einer Route eines Routers gesetzt, aber erst gelesen wird, nachdem die Routen wieder zusammenlaufen.
• Ein Header, den der Aufrufer sendet, der aber nicht durchgelassen wird: Ein HTTPS-Sender gibt nur die benutzerdefinierten Header weiter, die unter Allowed Header(s) in der Runtime Configuration des iFlows stehen.
• Eine Property, die aus einem anderen iFlow erwartet wird: Exchange Properties gelangen nicht über einen ProcessDirect-Aufruf, nur Header (siehe den Artikel zu ProcessDirect und JMS).
• Eine Header-Zeile, die eine Property liest, die im selben Content Modifier angelegt wird – dieser verarbeitet die Header-Tabelle vor der Property-Tabelle.

Einen fehlenden Wert laut scheitern lassen

Bei Werten, ohne die der Flow nicht funktioniert, sollte er dort scheitern, wo sie gebraucht werden, nicht drei Schritte später. Ein kurzer Groovy-Schritt am Anfang des Flows genügt:

import com.sap.gateway.ip.core.customdev.util.Message

def Message processData(Message message) {
    def orderId = message.getProperty("orderId")
    if (orderId == null || orderId.toString().trim().isEmpty()) {
        throw new IllegalStateException("Exchange property orderId is not set")
    }
    return message
}

Die Nachricht endet dann mit einem Fehler und einem Satz, der die fehlende Property nennt, sichtbar im Message Processing Log. Geben Sie bei Router-Bedingungen der Default-Route einen klaren Zweck: Lassen Sie sie in einem Error End Event enden, wenn keine Route je verfehlt werden darf, statt die Nachricht auf einem Pfad weiterlaufen zu lassen, der als Notlösung gedacht war.

Setzen Sie beim Testen das Log-Level des iFlows auf Trace. Der Trace zeigt die Header und Exchange Properties bei jedem Schritt, sodass Sie genau sehen, wo ein Wert verschwindet.

Eine Checkliste vor dem Deployment

1. Listen Sie jeden Header und jede Property auf, die der iFlow liest: in Ausdrücken, Bedingungen, Adapterfeldern und Skripten.
2. Suchen Sie für jeden Namen den Schritt, der ihn setzt, und zwar auf jedem Pfad, der zur lesenden Stelle führt.
3. Vergleichen Sie die Schreibweise exakt, einschließlich Groß-/Kleinschreibung bei Properties und etwaiger Leerzeichen.
4. Prüfen Sie bei Headern, die vom Sender kommen, ob sie in Allowed Header(s) stehen.
5. Prüfen Sie bei Werten aus einem anderen iFlow, ob sie als Header übertragen werden, nicht als Properties.

Von Hand dauert das bei einem großen iFlow eine Weile – deshalb ist es die erste Prüfung, die sich zu automatisieren lohnt.

Namenskonventionen, die das Problem verhindern

• Wählen Sie einen Stil, etwa camelCase, und verwenden Sie ihn für jeden Header und jede Property im Package.
• Setzen Sie die Werte, von denen der ganze Flow abhängt, in einem Content Modifier nahe am Anfang, damit es eine Stelle zum Nachsehen gibt.
• Überlassen Sie die Präfixe SAP_ und Camel SAP und Apache Camel; geben Sie Ihren eigenen Namen eine andere Form.
• Verwenden Sie Properties für Werte, die nur dieser iFlow braucht, und Header nur für Werte, die ihn verlassen müssen.

Der Artikel über Camel Simple Expressions erklärt die Syntax hinter jedem Namen in dieser Liste.

Wie der Kitegra hilft

Die Browser-Erweiterung Kitegra arbeitet diese Checkliste im Designer der SAP Integration Suite ab. Ihr Lint-Bereich meldet Header und Properties, die nirgends im iFlow gesetzt werden, ein nicht geschlossenes ${ und überzählige Leerzeichen in Ausdrücken – noch vor dem Deployment.

Wenn Sie ${ oder $ tippen, schlägt sie nur Namen vor, die der iFlow definiert, einschließlich Namen aus Groovy- und JavaScript-Skripten, dazu die Standard-Header von SAP und Camel – ein Tippfehler wird so von vornherein unwahrscheinlicher. Ein Name, der nur auf manchen Pfaden gesetzt wird, ist mit „Nur auf einigen Pfaden gesetzt“ markiert. Die Erweiterung speichert, deployt oder bearbeitet nie den Inhalt eines iFlows, und Ihr Tenant ändert sich nur, wenn Sie auf eine von vier benannten Aktionen klicken, die sich abschalten lassen.

Ist ein Wert zur Laufzeit leer, zeigt das schrittweise Tracen der Nachricht die Header und Properties vor jedem Schritt, und die Checkliste für das iFlow-Review behandelt die Designfehler dahinter.

Ohne Kitegra-Konto funktioniert sie für 5 iFlows je Modul. Der Tarif Free umfasst 50, Starter 100 und Pro 300; Business hat kein Limit. Tarife vergleichen.

Probieren Sie ihn im nächsten iFlow aus

Lesen Sie, was der Kitegra im Designer der SAP Integration Suite leistet, oder sehen Sie ihn neben den anderen Chrome-Erweiterungen von Kitegra.

Häufige Fragen