サンプルペイロードから書く SAP CPI の XPath：XML と JSON から XML への変換

XPath は、SAP CPI が XML メッセージから値を読み取る方法です。プロパティに入れる注文番号、Router の条件に使うステータス、Splitter で使う繰り返しノードなどです。XPath を素早く正しく書くには、インターフェースの説明からではなく、実際のペイロードのサンプルから始めるのがいちばんです。

この記事では、iFlow で XPath を使う場所、XML サンプルからパスを導く方法、名前空間の仕組み、そして JSON ペイロードが XML に変換される仕組みを説明します。そのパスが /root で始まる理由も扱います。

iFlow で XPath を使う場所

• Content Modifier：ソースタイプ XPath の header 行またはプロパティ行が、ボディから値を読み取ります。データ型によって、java.lang.String のようなテキストを得るか、ノードを得るかが決まります。
• Router と Filter：タイプ XML の条件は XPath 式です。例：/Orders/Order/Status = 'OPEN'。
• Splitter：XPath 式で繰り返しノードを選び、ノードごとに 1 件のメッセージにします。
• Gather、Aggregator、Content Enricher：XPath で、結合・相関付け・エンリッチの対象となるノードを指します。

どれも、そのステップの時点のボディに対して実行されます。マッピングやコンバーターの後では、構造とともにパスも変わります。

XML サンプルから XPath へ

次は 2 件の注文を含む小さなサンプルです。

<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>

/ で始まるパスはルートから始まります。//Id はどこにある Id 要素でも見つけるので便利ですが、大きなペイロードでは遅くなります。

名前空間

ペイロードの要素が名前空間に属している場合、接頭辞のないパスでは何も見つかりません。iFlow の Runtime Configuration の Namespace Mapping で、各名前空間に接頭辞を xmlns:ord=http://example.com/orders の形式で宣言し、すべてのステップで使います：/ord:Orders/ord:Order/ord:Id。

マッピングの接頭辞はペイロードの接頭辞と同じである必要はなく、一致すべきなのは名前空間の URI だけです。中身がはっきり見えているペイロードに対して XPath が何も返さないときは、たいてい Namespace Mapping が欠けています。

JSON ペイロード：JSON to XML Converter を通して XPath を使う

XPath は XML に対して働くため、JSON メッセージはまず JSON to XML Converter で変換します。メンバーが複数ある JSON オブジェクトには単一のルート要素がないので、コンバーターの Add XML Root Element オプションがそれを 1 つのルート要素で包みます。デフォルトの名前は root です。そのためパスは /root で始まり、配列の各要素は配列名を持つ繰り返し要素になります。

{
  "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

コンバーターでルートに別の名前を付けた場合は、すべてのパスの最初のステップをそれに合わせて変えてください。XPath のステップの後で JSON に戻すには、XML to JSON Converter を使います。

XPath が何も返さない理由

• 名前空間が Namespace Mapping で宣言されていない、またはパスに接頭辞がない。
• 大文字と小文字の誤り：XPath では要素名と属性名は大文字と小文字を区別します。
• マッピングやコンバーターで変わる前のペイロードに合わせて書いたパス。
• JSON のパスに /root のステップがない、またはルートの名前を変えた後もデフォルト名のまま。
• Content Modifier の行のデータ型の誤り：java.lang.String はテキストを、org.w3c.dom.NodeList はノードを返します。

読み取った値を後でボディに組み込みますか？ Simple 式の記事では読み取ったプロパティの使い方を、Postman と OpenAPI の記事では JSON ボディを REST API に送る方法を紹介しています。

Kitegra でできること

ブラウザー拡張機能 Kitegra は、サンプルからパスを書き出します。XML または JSON のサンプルペイロードを渡すと、Content Modifier の XPath 行と、Router、Filter、Splitter、Gather、Aggregator、Content Enricher で XPath 式を候補表示します。JSON のサンプルでは、候補のパスはコンバーターのルートである /root から始まります。

サンプルペイロードはブラウザーの中にとどまります。Kitegra がそれを保存することはありません。拡張機能が iFlow の内容を保存、デプロイ、編集することはありません。tenant が変更されるのは、名前の付いた 4 つの操作のいずれかをクリックしたときだけで、これらの操作はオフにすることもできます。

XPath のステップが実際に受け取るボディを確認するには、メッセージをステップごとにトレースしてください。

Kitegra アカウントがなくても、モジュールごとに 5 つの iFlow で使えます。Free プランは 50、Starter は 100、Pro は 300 まで対応し、Business は上限なしです。プランを比較する。

次の iFlow で試してみましょう

Kitegra が SAP Integration Suite のデザイナーで何をするのかを読むか、Kitegra のほかの Chrome 拡張機能と並べて確認できます。

よくある質問