XPath dans SAP CPI à partir d'un payload d'exemple : XML et JSON vers XML

XPath est la façon dont SAP CPI lit une valeur dans un message XML : un numéro de commande vers une propriété, un statut vers une condition de Router, un nœud répété vers un Splitter. Le moyen le plus rapide de l'écrire correctement est de partir d'un vrai exemple du payload, pas de la description de l'interface.

Cet article montre où XPath est utilisé dans un iFlow, comment dériver des chemins d'un exemple XML, comment fonctionnent les namespaces, et comment les payloads JSON deviennent du XML, y compris pourquoi leurs chemins commencent par /root.

Où XPath est utilisé dans un iFlow

• Content Modifier : une ligne de header ou de propriété avec le type de source XPath lit une valeur dans le body. Le type de données détermine si vous obtenez du texte, comme java.lang.String, ou des nœuds.
• Router et Filter : les conditions de type XML sont des expressions XPath, par exemple /Orders/Order/Status = 'OPEN'.
• Splitter : l'expression XPath sélectionne le nœud qui se répète, un message par nœud.
• Gather, Aggregator et Content Enricher : XPath désigne les nœuds à combiner, à corréler ou à enrichir.

Chacune de ces étapes s'applique au body tel qu'il est à ce stade. Après un mapping ou un convertisseur, les chemins changent avec la structure.

D'un exemple XML à un XPath

Voici un petit exemple avec deux commandes :

<Orders>
  <Order status="OPEN">
    <Id>4711</Id>
    <Customer id="C-100">ACME</Customer>
    <Amount currency="EUR">1250.00</Amount>
  </Order>
  <Order status="CLOSED">
    <Id>4712</Id>
    <Customer id="C-200">Globex</Customer>
    <Amount currency="EUR">80.00</Amount>
  </Order>
</Orders>

Un chemin qui commence par / part de la racine ; //Id trouve les éléments Id n'importe où, ce qui est pratique mais plus lent sur de gros payloads.

Namespaces

Si les éléments du payload sont dans un namespace, un chemin sans préfixe ne trouve rien. Déclarez un préfixe pour chaque namespace dans la Runtime Configuration de l'iFlow, sous Namespace Mapping, sous la forme xmlns:ord=http://example.com/orders, et utilisez-le à chaque étape : /ord:Orders/ord:Order/ord:Id.

Le préfixe de votre mapping n'a pas besoin d'être celui du payload ; seule l'URI du namespace doit correspondre. Un XPath qui ne renvoie rien sur un payload que vous avez clairement sous les yeux trahit généralement un Namespace Mapping manquant.

Payloads JSON : XPath via le JSON to XML Converter

XPath fonctionne sur du XML : un message JSON est donc d'abord converti avec le JSON to XML Converter. Un objet JSON à plusieurs membres n'a pas d'élément racine unique ; l'option Add XML Root Element du convertisseur l'enveloppe donc dans un élément nommé root par défaut. Les chemins commencent alors par /root, et chaque élément d'un tableau devient un élément répété portant le nom du tableau :

{
  "orderId": "4711",
  "customer": { "id": "C-100", "name": "ACME" },
  "items": [
    { "sku": "A-1", "qty": 2 },
    { "sku": "B-7", "qty": 1 }
  ]
}

JSON to XML Converter (root element: root)

<root>
  <orderId>4711</orderId>
  <customer><id>C-100</id><name>ACME</name></customer>
  <items><sku>A-1</sku><qty>2</qty></items>
  <items><sku>B-7</sku><qty>1</qty></items>
</root>

/root/orderId              4711
/root/customer/name        ACME
/root/items/sku            A-1, B-7
/root/items[qty > 1]/sku   A-1

Si vous donnez un autre nom à la racine dans le convertisseur, adaptez la première étape de chaque chemin. Pour revenir au JSON après les étapes XPath, utilisez le XML to JSON Converter.

Pourquoi un XPath ne renvoie rien

• Un namespace non déclaré sous Namespace Mapping, ou un chemin sans son préfixe.
• Une mauvaise casse : les noms d'éléments et d'attributs sont sensibles à la casse en XPath.
• Un chemin écrit pour le payload d'avant qu'un mapping ou un convertisseur ne le modifie.
• Un chemin JSON sans l'étape /root, ou avec le nom par défaut alors que la racine a été renommée.
• Un mauvais type de données dans une ligne de Content Modifier : java.lang.String renvoie du texte, org.w3c.dom.NodeList renvoie des nœuds.

Vous intégrez ensuite les valeurs dans un body ? L'article sur les expressions Simple montre comment utiliser les propriétés que vous venez de lire, et l'article sur Postman et OpenAPI comment envoyer un body JSON à une API REST.

Ce qu'apporte Kitegra

L'extension de navigateur Kitegra écrit les chemins à partir de votre exemple. Fournissez-lui un payload d'exemple en XML ou en JSON, et elle suggère des expressions XPath dans les lignes XPath du Content Modifier, ainsi que dans Router, Filter, Splitter, Gather, Aggregator et Content Enricher. Pour un exemple JSON, les chemins suggérés partent de la racine du convertisseur, /root.

Les payloads d'exemple restent dans votre navigateur : Kitegra ne les enregistre jamais. L'extension n'enregistre, ne déploie et ne modifie jamais le contenu d'un iFlow, et votre tenant ne change que lorsque vous cliquez sur l'une de quatre actions nommées, qui peuvent être désactivées.

Pour voir le body que reçoit réellement une étape XPath, tracez le message étape par étape.

Sans compte Kitegra, elle fonctionne sur 5 iFlows par module. Le forfait Free en couvre 50, Starter 100 et Pro 300 ; Business n'a pas de limite. Comparez les forfaits.

Essayez-le dans votre prochain iFlow

Découvrez ce que fait Kitegra dans le designer de SAP Integration Suite, ou voyez-le aux côtés des autres extensions Chrome de Kitegra.

Questions fréquentes