Espressioni Camel Simple in SAP CPI: header, proprietà e ${…} con esempi

Quasi ogni valore dinamico di un iFlow di SAP Cloud Integration (SAP CPI) è scritto in Simple, il linguaggio di espressioni di Apache Camel: un header nell'indirizzo di un receiver, una proprietà in un Content Modifier, una data nel nome di un file, una condizione su un Router. La sintassi è breve, ${…}, ed è facile sbagliare un dettaglio senza accorgersene.

Questo articolo presenta le espressioni che userai ogni giorno, l'ordine in cui un Content Modifier le valuta, la differenza tra header ed exchange property, e gli errori che fanno sì che un'espressione non restituisca nulla senza alcun avviso.

Che cos'è un'espressione Simple in SAP CPI

SAP Integration Suite esegue ogni iFlow su Apache Camel. Quando uno step viene eseguito, Camel sostituisce ogni ${…} del campo con un valore del messaggio corrente: un header, una exchange property, il body o una funzione integrata, come la data corrente. Il testo attorno all'espressione resta invariato, quindi Order-${header.orderId}.xml diventa Order-4711.xml.

Puoi scrivere espressioni Simple nei valori di tipo Expression di un Content Modifier e nel body del messaggio, nei campi di indirizzo e di query di molti adapter receiver, nelle condizioni di tipo Non-XML di Router e Filter, e in campi come l'oggetto di una mail o il nome di un file SFTP. I parametri esternalizzati sembrano simili ma sono un'altra cosa: {{receiverHost}} viene sostituito una sola volta, al deploy dell'iFlow, mentre ${…} viene valutato per ogni messaggio.

Le espressioni che userai ogni giorno

Una manciata di espressioni copre la maggior parte degli iFlow, e si mescolano liberamente con il testo. Il body di un Content Modifier, per esempio, può costruire un intero documento XML a partire da header, proprietà e funzioni:

<Order>
  <Id>${property.orderId}</Id>
  <Customer>${header.customerId}</Customer>
  <ReceivedOn>${date:now:yyyy-MM-dd}</ReceivedOn>
  <Flow>${camelId}</Flow>
  <MessageLog>${property.SAP_MessageProcessingLogID}</MessageLog>
</Order>

Come un Content Modifier valuta header, proprietà e body

Un Content Modifier elabora le sue schede in un ordine fisso: prima la tabella Message Header, poi la tabella Exchange Property, infine il Message Body. All'interno di ogni tabella le righe vengono elaborate dall'alto verso il basso.

Quest'ordine decide che cosa un'espressione può vedere. Una riga di proprietà può leggere un header creato prima nello stesso Content Modifier, e il body può usare entrambi. Una riga di header non può leggere una proprietà creata dallo stesso Content Modifier, perché quando l'header viene valutato la proprietà non esiste ancora: legge invece un valore vuoto. Se ti serve, imposta la proprietà in un Content Modifier precedente, oppure sposta il valore nella tabella degli header, che viene prima.

• Tipo di origine Expression: il valore è un'espressione Simple, per esempio ${date:now:yyyyMMdd}-${header.orderId}.
• Tipo di origine Header o Property: copia un altro header o un'altra proprietà per nome, senza ${…} attorno.
• Tipo di origine XPath: legge un valore da un body XML (vedi l'articolo su XPath linkato più sotto).
• I tipi di origine Constant, Local Variable, Global Variable e Number Range coprono valori fissi e valori memorizzati.

Header o exchange property: quale usare

Un header viaggia con il messaggio. Gli adapter receiver possono passare gli header al sistema che chiami, e gli header attraversano una chiamata ProcessDirect verso un altro iFlow. Una exchange property resta all'interno dell'exchange dell'iFlow corrente e non viene mai inviata da sola a un receiver.

Due dettagli causano la maggior parte delle sorprese. I nomi degli header non distinguono tra maiuscole e minuscole, quindi ${header.OrderID} e ${header.orderid} leggono lo stesso header. I nomi delle exchange property invece sì, quindi ${property.OrderID} e ${property.orderId} sono due proprietà diverse, e la seconda potrebbe semplicemente non esistere.

• Usa una proprietà per i valori che servono solo a questo iFlow: ID, contatori, flag, copie salvate del payload.
• Usa un header per i valori che un adapter o l'iFlow successivo devono ricevere, e rimuovi gli header che non devono uscire dal tenant.
• Non mettere valori grandi negli header: viaggiano con ogni chiamata.

Condizioni Simple in Router e Filter

In una route del Router o in un Filter di tipo Non-XML, la condizione è un'espressione Simple confrontata con un valore. Gli operatori più usati sono =, !=, >, >=, <, <=, contains, in e regex, combinati con and oppure or. I valori di testo vanno tra apici singoli:

${header.orderType} = 'EXPRESS'
${property.amount} > 1000 and ${header.country} in 'DE,AT,CH'
${header.CamelHttpResponseCode} != '200'

Se l'header o la proprietà di una condizione non esiste, la condizione è semplicemente falsa e il messaggio prende un'altra route, spesso quella di default. L'articolo su header e proprietà sconosciuti mostra come intercettarlo prima che arrivi in produzione.

Come aiuta Kitegra

Kitegra è un'estensione del browser per il designer di SAP Integration Suite. Scrivi ${ o $ in un campo del designer e ti elenca i nomi adatti a quel punto dell'iFlow: header e proprietà impostati nei Content Modifier, negli script Groovy e JavaScript e in altri punti dell'iFlow, header ed espressioni standard di SAP e Camel, parametri {{…}}, variabili e nomi di Data Store. Un nome impostato solo su alcuni percorsi viene segnalato con «Impostato solo su alcuni percorsi».

Il suo pannello di lint segnala un ${ non chiuso, spazi superflui dentro un'espressione, e header o proprietà che nulla nell'iFlow imposta. Per le righe XPath, un payload di esempio ti dà anche suggerimenti di percorso, come spiega l'articolo su XPath. 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.

Per vedere i valori che le tue espressioni producono davvero, traccia un messaggio step by step e leggi header e proprietà prima di ogni step.

Senza un account Kitegra funziona su 5 iFlow per modulo. Il piano Free ne copre 50, Starter 100 e Pro 300. Con i piani per team ogni membro ha Pro, con 300 iFlow per modulo su Startup Team e nessun limite su Growth Team e Scale Team. Durante il lancio di Kitegra, tutti gli strumenti sono aperti a chiunque abbia effettuato l'accesso, anche con il piano Free. 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