Header e proprietà sconosciuti in SAP CPI: intercettali prima che falliscano in silenzio

Un header mai impostato non ferma un iFlow di SAP CPI. L'espressione che lo legge restituisce un valore vuoto, una condizione del Router diventa falsa, un campo del payload resta vuoto e il messaggio prosegue. L'errore, se c'è, compare diversi step dopo o nel sistema ricevente.

Questo articolo spiega perché header ed exchange property mancanti falliscono in silenzio, le cause che si ripresentano di continuo, e i controlli che li intercettano prima che un messaggio ci inciampi.

Perché un nome mancante non genera un errore

Apache Camel tratta un header o una proprietà inesistente come vuoto, non come un errore. È comodo per i valori opzionali, ed è il motivo per cui un errore di battitura può restare in un iFlow per mesi. Quello che vedi dipende da dove viene letto il nome:

• Un valore di Content Modifier come ${property.orderId} diventa una stringa vuota.
• Una condizione di Router o Filter come ${header.orderType} = 'EXPRESS' risulta falsa, quindi il messaggio prende un'altra route, spesso quella di default.
• Un indirizzo di receiver come /orders/${property.orderId} chiama /orders/, e il sistema ricevente risponde con un errore che non menziona la proprietà mancante.
• In uno script Groovy, message.getHeader("orderId", String) restituisce null, e lo script fallisce più avanti con un errore di null pointer, oppure scrive il testo null nel payload.

Le cause tipiche

• Un errore di battitura, o maiuscole e minuscole sbagliate nel nome di una proprietà: i nomi delle exchange property distinguono tra maiuscole e minuscole, quindi orderID e orderId sono due proprietà diverse. I nomi degli header no.
• Uno spazio di troppo, per esempio ${header.orderId }: il nome con lo spazio è un altro nome.
• Un valore impostato su una sola route di un Router e letto dopo che le route si sono ricongiunte.
• Un header inviato dal chiamante ma non lasciato passare: un sender HTTPS fa passare solo gli header personalizzati elencati in Allowed Header(s), nella Runtime Configuration dell'iFlow.
• Una proprietà attesa da un altro iFlow: le exchange property non attraversano una chiamata ProcessDirect, solo gli header lo fanno (vedi l'articolo su ProcessDirect e JMS).
• Una riga di header che legge una proprietà creata nello stesso Content Modifier, che elabora la tabella degli header prima di quella delle proprietà.

Fai fallire un valore mancante in modo evidente

Per i valori senza i quali il flusso non può funzionare, fai fallire il flusso nel punto in cui servono, non tre step dopo. Basta un breve step Groovy all'inizio del flusso:

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
}

Il messaggio termina allora in errore con una frase che nomina la proprietà mancante, visibile nel log di elaborazione del messaggio. Per le condizioni del Router, dai alla route di default uno scopo chiaro: falla terminare in un evento Error End quando il messaggio deve sempre prendere una delle route, invece di lasciarlo proseguire su un percorso pensato come ripiego.

Durante i test, imposta il livello di log dell'iFlow su Trace. Il trace mostra header ed exchange property a ogni step, così vedi esattamente dove sparisce un valore.

Una checklist prima del deploy

1. Elenca ogni header e ogni proprietà che l'iFlow legge: in espressioni, condizioni, campi degli adapter e script.
2. Per ciascuno, trova lo step che lo imposta, su ogni percorso che arriva al punto in cui viene letto.
3. Confronta l'ortografia esatta, incluse maiuscole e minuscole per le proprietà ed eventuali spazi.
4. Per gli header che arrivano dal sender, verifica che siano in Allowed Header(s).
5. Per i valori passati da un altro iFlow, verifica che viaggino come header e non come proprietà.

Fatto a mano, questo controllo richiede parecchio tempo su un iFlow grande, ed è per questo che è il primo che vale la pena automatizzare.

Abitudini di naming che prevengono il problema

• Scegli uno stile, come camelCase, e usalo per ogni header e proprietà del package.
• Imposta i valori da cui dipende l'intero flusso in un unico Content Modifier vicino all'inizio, così c'è un solo posto dove guardare.
• Lascia i prefissi SAP_ e Camel a SAP e ad Apache Camel; dai ai tuoi nomi una forma diversa.
• Usa le proprietà per i valori che servono solo a questo iFlow, e gli header solo per i valori che devono uscirne.

L'articolo sulle espressioni Camel Simple spiega la sintassi dietro ogni nome di questo elenco.

Come aiuta Kitegra

L'estensione del browser Kitegra esegue questa checklist nel designer di SAP Integration Suite. Il suo pannello di lint segnala header e proprietà che nulla nell'iFlow imposta, un ${ non chiuso e spazi superflui nelle espressioni, prima del deploy.

Quando scrivi ${ o $, suggerisce solo nomi che l'iFlow definisce, compresi quelli impostati negli script Groovy e JavaScript, oltre agli header standard di SAP e Camel, così un errore di battitura è meno probabile fin dall'inizio. Un nome impostato solo su alcuni percorsi viene segnalato con «Impostato solo su alcuni percorsi». L'estensione non salva, non esegue il deploy e non modifica mai il contenuto di un iFlow, e il tuo tenant cambia solo quando fai clic su una di quattro azioni ben precise, che si possono disattivare.

Quando un valore è vuoto in fase di esecuzione, tracciare il messaggio step by step mostra header e proprietà prima di ogni step, e la checklist di revisione degli iFlow tratta gli errori di design che ci sono dietro.

Senza un account Kitegra funziona su 5 iFlow per modulo. Il piano Free ne copre 50, Starter 100 e Pro 300; Business non ha limiti. Confronta i piani.

Provalo nel tuo prossimo iFlow

Scopri cosa fa Kitegra nel designer di SAP Integration Suite, oppure guardalo accanto alle altre estensioni Chrome di Kitegra.

Domande frequenti