XMLtoJSON ポリシー

このページは Apigee と Apigee ハイブリッドに適用されます。

Apigee Edge のドキュメントはこちらをご覧ください。

ポリシー アイコン

内容

このポリシーでは、メッセージを拡張マークアップ言語（XML）形式から JavaScript Object Notation（JSON）に変換します。これにより、メッセージの変換方法を制御するための選択肢が多くなります。

XML 形式のレスポンスを JSON 形式のレスポンスに変換することが目的であると仮定した場合、このポリシーはレスポンス フロー（たとえば Response / ProxyEndpoint / PostFlow）に接続されます。

このポリシーは、標準ポリシーであり、任意の環境タイプにデプロイできます。すべてのユーザーがポリシーや環境のタイプを知る必要はありません。ポリシータイプと各環境タイプでの利用可否については、ポリシータイプをご覧ください。

概要

代表的なメディエーションのシナリオでは、多くの場合、受信リクエスト フローでの JSON to XML ポリシーは、送信レスポンス フローでの XML to JSON ポリシーとペアで使用されます。ポリシーを結合することで、XML のみをネイティブにサポートするバックエンド サービスに対して JSON API を公開できます。

JSON または XML を必要とする可能性がある多様なクライアント アプリで API が使用されるシナリオでは、JSON to JSON ポリシーを条件付きで実行することによって、レスポンスの形式を JSON から XML に動的に設定できます。このシナリオの実装については、フロー変数と条件をご覧ください。

サンプル

JSON と XML の間の変換について詳しくは、こちらの記事をご覧ください。

レスポンスを変換する

<XMLToJSON name="ConvertToJSON">
  <Options>
  </Options>
  <OutputVariable>response</OutputVariable>
  <Source>response</Source>
</XMLToJSON>

この構成（XML を JSON に変換するために必要な最小限の構成）では、XML 形式のレスポンス メッセージをソースとして受け取り、response OutputVariable に入力された JSON 形式のメッセージが作成されます。Apigee では、この変数の内容が次の処理ステップのメッセージとして自動的に使用されます。

要素リファレンス

このポリシーで構成できる要素と属性は、以下のとおりです。

<XMLToJSON async="false" continueOnError="false" enabled="true" name="XML-to-JSON-1">
    <DisplayName>XML to JSON 1</DisplayName>
    <Source>response</Source>
    <OutputVariable>response</OutputVariable>
    <Options>
        <RecognizeNumber>true</RecognizeNumber>
        <RecognizeBoolean>true</RecognizeBoolean>
        <RecognizeNull>true</RecognizeNull>
        <NullValue>NULL</NullValue>
        <NamespaceBlockName>#namespaces</NamespaceBlockName>
        <DefaultNamespaceNodeName>&</DefaultNamespaceNodeName>
        <NamespaceSeparator>***</NamespaceSeparator>
        <TextAlwaysAsProperty>true</TextAlwaysAsProperty>
        <TextNodeName>TEXT</TextNodeName>
        <AttributeBlockName>FOO_BLOCK</AttributeBlockName>
        <AttributePrefix>BAR_</AttributePrefix>
        <OutputPrefix>PREFIX_</OutputPrefix>
        <OutputSuffix>_SUFFIX</OutputSuffix>
        <StripLevels>2</StripLevels>
        <TreatAsArray>
            <Path unwrap="true">teachers/teacher/studentnames/name</Path>
        </TreatAsArray>
    </Options>
    <!-- Use Options or Format, not both -->
    <Format>yahoo</Format>
</XMLToJSON>

<XMLtoJSON> 属性

<XMLtoJSON async="false" continueOnError="false" enabled="true" name="XML-to-JSON-1">

次の表に、すべてのポリシーの親要素に共通する属性を示します。

属性 説明 デフォルト 要否
name

ポリシーの内部名。name 属性の値には、英字、数字、スペース、ハイフン、アンダースコア、ピリオドを使用できます。この値は 255 文字を超えることはできません。

管理 UI プロキシ エディタで <DisplayName> 要素を追加して、ポリシーのラベルに使用する別の自然言語名を指定することもできます。

 なし 必須
continueOnError

ポリシーが失敗したときにエラーを返す場合は、false に設定します。これは、ほとんどのポリシーで想定される動作です。

ポリシーが失敗した後もフローの実行を続行する場合は、true に設定します。関連項目:

 false 省略可
enabled

ポリシーを適用するには、true に設定します。

ポリシーを無効にするには、false に設定します。ポリシーがフローに接続されている場合でも適用されません。

 true 省略可
async

この属性は非推奨となりました。

 false 非推奨

<DisplayName> 要素

管理 UI プロキシ エディタで name 属性と一緒に使用して、ポリシーのラベルに使用する自然言語名を指定します。

<DisplayName>Policy Display Name</DisplayName>
デフォルト

なし

この要素を省略した場合、ポリシーの name 属性の値が使用されます。
要否 省略可
タイプ 文字列

<Source> 要素

JSON に変換する XML メッセージを指定する変数。

ソース メッセージの HTTP Content-type ヘッダーを application/xml に設定する必要があります。設定されていない場合、ポリシーは適用されません。

<Source> が定義されていない場合は、message として処理されます（ポリシーがリクエスト フローに接続されている場合は request、ポリシーがレスポンス フローに接続されている場合は response に解決されます）。

ソース変数を解決できない場合、あるいはメッセージ以外のタイプに解決される場合、ポリシーによってエラーが返されます。

<Source>response</Source>
デフォルト Source 要素の値
要否 省略可
型 メッセージ

<OutputVariable> 要素

XML から JSON 形式への変換の出力を保存する場所を指定します。通常、この要素はポリシー構成に含まれません。

Apigee は、Source で指定された XML メッセージのペイロードを解析し、JSON に変換します。結果を OutputVariable のペイロードに格納して、OutputVariable メッセージの HTTP Content-type ヘッダーを application/json に設定します。

OutputVariable が指定されていない場合、デフォルトで Source の値が使用されます。たとえば、source が response である場合、OutputVariable のデフォルトは response になります。

<OutputVariable>response</OutputVariable>
デフォルト Source で指定されたメッセージ
要否 省略可
型 メッセージ

<Options>

Options により、XML から JSON への変換を制御できます。特定の変換設定を追加できる <Options> グループ、または事前定義オプションのテンプレートを参照できる <Format> 要素を使用します。<Options> と <Format> の両方を使用することはできません。

<Format> を使用しない場合は <Options> が必要です。

<RecognizeNumber> 要素

true の場合、XML ペイロードの数値フィールドでは元の形式が維持されます。

<RecognizeNumber>true</RecognizeNumber>

以下の XML の例を考えてみましょう。

<a>
  <b>100</b>
  <c>value</c>
</a>

RecognizeNumber が true の場合、ポリシーは次のように変換します。

{
    "a": {
        "b": 100,
        "c": "value"
    }
}

RecognizeNumber が false の場合、ポリシーは次のように変換します。

{
  "a": {
    "b": "100",
    "c": "value"
  }
}
デフォルト false
要否 省略可
型 ブール値

<RecognizeBoolean> 要素

変換の際に true / false ブール値が維持され、文字列に変換されません。

<RecognizeBoolean>true</RecognizeBoolean>

次の XML 例の場合、以下のように変換されます。

<a>
  <b>true</b>
  <c>value</c>
</a>

RecognizeBoolean が true の場合、ポリシーは次のように変換します。

{
    "a": {
        "b": true,
        "c": "value"
    }
}

RecognizeBoolean が false の場合、ポリシーは次のように変換します。

{
    "a": {
        "b": "true",
        "c": "value"
    }
}
デフォルト false
要否 省略可
型 ブール値

<RecognizeNull> 要素

空の値を null 値に変換できます。

<RecognizeNull>true</RecognizeNull>

以下の XML の場合:

<a>
  <b></b>
  <c>value</c>
</a>

RecognizeNull が true で、NullValue オプションがない場合、この XML は次のように変換されます。

{
  "a": {
    "b": null,
    "c": "value"
  }
}

RecognizeNull が false の場合、この XML は次のように変換されます。

{
  "a": {
    "b": {},
    "c": "value"
  }
}
デフォルト false
要否 省略可
型 ブール値

<NullValue> 要素

ソース メッセージで認識された null 値を変換する値を示します。デフォルトでは、値は null です。このオプションは、RecognizeNull が true の場合にのみ有効です。

<NullValue>not-present</NullValue>

以下の XML の場合:

<a>
  <b></b>
  <c>value</c>
</a>

RecognizeNull が true で、NullValue が指定されていない場合、この XML は次のように変換されます。

{
  "a": {
    "b": null,
    "c": "value"
  }
}

RecognizeNull が true で、NullValue が not-present の場合、この XML は次のように変換されます。

{
  "a": {
    "b": "not-present",
    "c": "value"
  }
}
デフォルト null
要否 省略可
タイプ 文字列

名前空間オプション

デフォルトでは、このポリシーは生成される JSON の XML 名前空間を省略します。XML ドキュメント内の名前空間を生成 JSON に変換するように指定するには、これらの要素を一緒に使用します。

<NamespaceBlockName>#namespaces</NamespaceBlockName>
<DefaultNamespaceNodeName>&</DefaultNamespaceNodeName>
<NamespaceSeparator>***</NamespaceSeparator>

以下の XML の例を考えてみましょう。

<a xmlns="http://ns.com" xmlns:ns1="http://ns1.com">
  <ns1:b>value</ns1:b>
</a>

NamespaceSeparator が指定されていない場合、次の JSON 構造が生成されます。

{
    "a": {
        "b": "value"
    }
}

NamespaceBlockName 要素、DefaultNamespaceNodeName 要素、NamespaceSeparator 要素がそれぞれ #namespaces、&、*** として指定されている場合、次の JSON 構造が生成されます。

{
    "a": {
        "#namespaces": {
            "&": "http://ns.com",
            "ns1": "http://ns1.com"
        },
        "ns1***b": "value"
    }
}
デフォルト なし。<NamespaceBlockName> が指定されていない場合、ソース メッセージが名前空間を参照しているかどうかに関係なく、XML 名前空間を参照しない出力 JSON が生成されます。
要否 省略可
ただし、<NamespaceBlockName> を指定する場合は、その他の 2 つの要素も指定する必要があります。
型 文字列

テキスト オプション

これらの要素を一緒に使用します。

      <TextAlwaysAsProperty>true|false</TextAlwaysAsProperty>
      <TextNodeName>TEXT</TextNodeName>

子として単一のテキストノードのみを含む XML 要素がポリシーで検出されると、その XML 要素のテキスト コンテンツが JSON ハッシュのプロパティに変換されます。

混合コンテンツの複数の子を含む XML 要素がポリシーで検出された場合、これらのオプションを使用すると、子テキストノードの出力 JSON を制御できます。

たとえば、次のポリシー構成について考えてみます。

<XMLToJSON name='XMLToJSON-1'>
  <Options>
    <TextAlwaysAsProperty>???</TextAlwaysAsProperty>
    <TextNodeName>#text</TextNodeName>
  </Options>
</XMLToJSON>

指定された XML 入力に対して、TextAlwaysAsProperty が true か false かに応じて、ポリシーは次の出力を生成します。

XML 入力 JSON 出力
TextAlwaysAsProperty が false の場合 TextAlwaysAsProperty が true の場合 

<a>value1</a>



{
  "a": "value1"
}
 

{
  "a": {
    "#text": "value1"
  }
}
 

<a>value1
  <b>value2</b>
</a>
 

{
  "a": {
    "#text": "value1\n",
    "b": "value2"
  }
}
 

{
  "a": {
    "#text": "value1\n",
    "b": {
      "#text": "value2"
    }
  }
}
デフォルト <TextAlwaysAsProperty>: false
<TextNodeName>: （空白文字列）
要否 省略可
型 <TextAlwaysAsProperty>: ブール値
<TextNodeName>: 文字列

属性オプション

これらの要素を組み合わせることで、属性値を JSON ブロックにグループ化し、属性名に接頭辞を追加できます。

<AttributeBlockName>FOO_BLOCK</AttributeBlockName>
<AttributePrefix>BAR_</AttributePrefix>

以下の XML の例を考えてみましょう。

<a attrib1="value1" attrib2="value2"/>

XML to JSON の例で定義されているように、両方の属性（AttributeBlockName と AttributePrefix）が指定されている場合、次の JSON 構造が生成されます。

{
  "a": {
    "FOO_BLOCK": {
      "BAR_attrib1": "value1",
      "BAR_attrib2": "value2"
    }
  }
}

AttributeBlockName のみを指定すると、次の JSON 構造が生成されます。

{
    "a": {
        "FOO_BLOCK": {
            "attrib1": "value1",
            "attrib2": "value2"
        }
    }
}

AttributePrefix のみを指定すると、次の JSON 構造が生成されます。

{
    "a": {
        "BAR_attrib1": "value1",
        "BAR_attrib2": "value2"
    }
}

どちらも指定されていない場合、次の JSON 構造が生成されます。

{
    "a": {
        "attrib1": "value1",
        "attrib2": "value2"
    }
}
デフォルト なし。
要否 省略可
タイプ 文字列

<OutputPrefix> 要素と <OutputSuffix> 要素

これらの要素を一緒に使用して、生成された JSON に接頭辞や接尾辞を適用します。

<OutputPrefix>PREFIX_</OutputPrefix>
<OutputSuffix>_SUFFIX</OutputSuffix>

以下の XML の例を考えてみましょう。

<a>value</a>

ポリシー構成が次のようになっているとします。

<XMLToJSON name='XMLToJSON-4'>
  <Options>
    <OutputPrefix>{ "result": </OutputPrefix>
    <OutputSuffix>}</OutputSuffix>
  </Options>
</XMLToJSON>

次の JSON 構造が生成されます。

{
  "result": {
    "a": "value"
  }
}

OutputPrefix と OutputSuffix の一方または両方を省略できます。

これらの要素を使用すると、無効な JSON が生成される可能性があります。たとえば、このポリシー構成を使用すると、次のようになります。

<XMLToJSON name='XMLToJSON-4'>
  <Options>
    <OutputPrefix>PREFIX_</OutputPrefix>
  </Options>
</XMLToJSON>

ポリシーによって次のものが生成されますが、これは有効な JSON ではありません。

PREFIX_{
  "a" : "value"
}

構成で OutputPrefix も OutputSuffix も指定されていない場合、ポリシーは次の JSON 構造を生成します。

{
  "a": "value"
}
デフォルト 上述の例をご覧ください。
要否 省略可
タイプ 文字列

<StripLevels> 要素

<Options>
    <StripLevels>4</StripLevels>
</Options>

SOAP などの XML ペイロードには、変換後の JSON に含めたくない親レベルが多数あることがあります。以下の例では、SOAP レスポンスに多数のレベルが含まれています。

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/Schemata-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <soap:Body>
      <GetCityWeatherByZIPResponse xmlns="http://ws.cdyne.com/WeatherWS/">
          <GetCityWeatherByZIPResult>
              <State>CO</State>
              <City>Denver</City>
              <Description>Sunny</Description>
              <Temperature>62</Temperature>
          </GetCityWeatherByZIPResult>
      </GetCityWeatherByZIPResponse>
  </soap:Body>
</soap:Envelope>

State、City、Description、および Temperature レベルに達するまでに 4 つのレベルがあります。<StripLevels> を使用しない場合、変換後の JSON レスポンスは次のようになります。

{
   "Envelope" : {
      "Body" : {
         "GetCityWeatherByZIPResponse" : {
            "GetCityWeatherByZIPResult" : {
               "State" : "CO",
               "City" : "Denver",
               "Description" : "Sunny",
               "Temperature" : "62"
            }
         }
      }
   }
}

JSON レスポンスの最初の 4 つのレベルを削除する場合は、<StripLevels>4</StripLevels> を設定します。これにより、次の JSON が生成されます。

{
  "State" : "CO",
  "City" : "Denver",
  "Description" : "Sunny",
  "Temperature" : "62"
}

削除できるレベルは、複数の子を含んでいる最初の要素までです。これは何を意味するのでしょうか。より複雑な JSON の例を見てみましょう。

{
   "Envelope" : {
      "Body" : {
         "GetCityForecastByZIPResponse" : {
            "GetCityForecastByZIPResult" : {
               "ResponseText" : "City Found",
               "ForecastResult" : {
                  "Forecast" : [
                     {
                        "ProbabilityOfPrecipiation" : {
                           "Nighttime" : "00",
                           "Daytime" : 10
                        }  ...

この例のレベル 3 は GetCityForecastByZIPResponse です。子要素は 1 つだけです。したがって、<StripLevels>3</StripLevels> を使用する（最初の 3 つのレベルを削除する）場合、JSON は次のようになります。

{
   "GetCityForecastByZIPResult" : {
      "ResponseText" : "City Found",
      "ForecastResult" : {
         "Forecast" : [
            {
               "ProbabilityOfPrecipiation" : {
                  "Nighttime" : "00",
                  "Daytime" : 10
               }  ...

GetCityForecastByZIPResult には複数の子要素があります。これが複数の子要素を持つ最初の要素であるため、この最後のレベルを <StripLevels>4</StripLevels> を使用して削除できます。これにより、JSON は次のようになります。

{
   "ResponseText" : "City Found",
   "ForecastResult" : {
      "Forecast" : [
         {
            "ProbabilityOfPrecipiation" : {
               "Nighttime" : "00",
               "Daytime" : 10
            }  ...

レベル 4 が複数の子要素を含んだ最初のレベルであるため、これより下のレベルは削除できません。削除レベルを 5、6、7 のように設定しても、レスポンスは引き続き上述のようになります。

デフォルト 0 （レベル削除なし）
要否 省略可
タイプ 整数

<TreatAsArray>/<Path> 要素

<Options>
    <TreatAsArray>
        <Path unwrap="true">teachers/teacher/studentnames/name</Path>
    </TreatAsArray>
</Options>

この要素の組み合わせにより、XML ドキュメントの値が常に JSON 配列に変換されるようになります。これは、子要素の数がペイロードごとに異なる場合に便利です。Apigee のデフォルトの動作では、同じ名前の複数の子要素は JSON 配列に変換され、単一の子要素は JSON プリミティブに変換されます。TreatAsArray オプションを使用すると、子要素が常に JSON 配列に変換されるようになります。

TreatAsArray を使用すると、配列のデータが毎回同じ方法で返されるため、出力を処理する後続のコードの構造を改善できます。たとえば、$.teachers.teacher.studentnames.name[0] という JSONPath を評価すると、元の XML に 1 つ以上の name 要素が含まれていても、一貫した名前の値が返されます。

XML to JSON のデフォルトの動作を確認し、<TreatAsArray>/<Path> を使用して出力を制御する方法を見てみましょう。

XML ドキュメントに複数回出現する要素が含まれている場合（これは、XML スキーマで要素に maxOccurs='unbounded' が指定されている場合に発生する可能性があります）、XML to JSON ポリシーは自動的にそれらの値を配列に配置します。たとえば、次の XML ブロックを見てみましょう。

<teacher>
    <name>teacherA</name>
    <studentnames>
        <name>student1</name>
        <name>student2</name>
    </studentnames>
</teacher>

これは、特殊なポリシー構成なしで、以下の JSON に自動的に変換されます。

{
  "teachers" : {
    "teacher" : {
      "name" : "teacherA",
      "studentnames" : {
        "name" : [
          "student1",
          "student2"
        ]
      }
    }
  }
}

2 人の生徒名が配列に入っています。

ただし、1 人の生徒しか XML ドキュメントに存在しない場合、XML to JSON ポリシーでは自動的にこの値は、下の例で示されているように、文字列の配列でなく、1 つの文字列として扱われます。

{
  "teachers" : {
    "teacher" : {
      "name" : "teacherA",
      "studentnames" : {
        "name" : "student1"
      }
    }
  }
}

これまでの例では、同様のデータが、あるものは配列に、あるものは 1 の文字列にと、さまざまな方法で変換されていました。<TreatAsArray>/<Path> 要素を使用すると、値が 1 つしかない場合でも生徒名が常に配列に変換されるように出力を制御できます。このように構成するには、次のように、配列に入れたい値を含む要素のパスを特定します。

<Options>
    <TreatAsArray>
        <Path>teachers/teacher/studentnames/name</Path>
    </TreatAsArray>
</Options>

上述の構成によって、次のような JSON が生成されます。

{
  "teachers" : {
    "teacher" : {
      "name" : "teacherA",
      "studentnames" : {
        "name" : ["student1"]
      }
    }
  }
}

student1 が配列の中に入るようになりました。これで、生徒が 1 人か複数かにかかわらず、次の JSONPath を使用してコード内の JSON 配列から取得できます。$.teachers.teacher.studentnames.name[0]

<Path> 要素にも unwrap 属性があります。これについては次のセクションで説明します。

デフォルト 該当なし
要否 省略可
タイプ 文字列

属性

 <Options>
    <TreatAsArray>
        <Path unwrap="true">teachers/teacher/studentnames/name</Path>
    </TreatAsArray>
</Options>
属性 説明 要否 種類
ラップ解除

デフォルト: false

JSON 出力から要素を削除します。これを使用することで、JSON を合理化、つまりフラット化（「ラップ解除」）します。値を取得するために必要な JSONPath も短くなります。たとえば、$.teachers.teacher.studentnames.name[*] の代わりに、JSON をフラット化し、$.teachers.studentnames[*] を使用できます。

以下に JSON の例を示します。


{
  "teachers" : {
      "teacher" : {
          "name" : "teacherA",
          "studentnames" : {
              "name" : [
                 "student1",
                 "student2"
              ]}...

この例では、teacher 要素と生徒名の name 要素は不要になりそうなものです。そのため、これらは削除またはラップ解除できます。<Path> 要素を構成する方法は次のとおりです。


<TreatAsArray>
    <Path unwrap="true">teachers/teacher</Path>
    <Path unwrap="true">teachers/teacher/studentnames/name</Path>
</TreatAsArray>

unwrap 属性を true に設定し、ラップ解除する要素のパスを指定します。JSON 出力は次のようになります。


{
  "teachers" : [{
      "name" : "teacherA",
      "studentnames" : ["student1","student2"]
      }]...

<Path> 要素は <TreatAsArray> 要素内にあるため、パス内の両方の要素が JSON 出力では配列として扱われます。

 任意 ブール値

その他の例と機能のチュートリアルについては、こちらの Google Cloud コミュニティの記事をご覧ください。

<Format>

Format により、XML から JSON への変換を制御できるようになります。このトピックで説明した特定の Options 要素の組み合わせが含まれている、事前定義テンプレートの名前を入力します。事前定義された形式には次のものがあります。xml.com、yahoo、google、badgerFish。

<Format> 要素か <Options> グループのいずれかを使用します。<Format> と <Options> の両方は使用できません。

以下は、それぞれの事前定義テンプレートの Format の定義です。

xml.com

<RecognizeNull>true</RecognizeNull>
<TextNodeName>#text</TextNodeName>
<AttributePrefix>@</AttributePrefix>

Yahoo

<RecognizeNumber>true</RecognizeNumber>
<TextNodeName>content</TextNodeName>

google

<TextNodeName>$t</TextNodeName>
<NamespaceSeparator>$</NamespaceSeparator>
<TextAlwaysAsProperty>true</TextAlwaysAsProperty>

badgerFish

<TextNodeName>$</TextNodeName>
<TextAlwaysAsProperty>true</TextAlwaysAsProperty>
<AttributePrefix>@</AttributePrefix>
<NamespaceSeparator>:</NamespaceSeparator>
<NamespaceBlockName>@xmlns</NamespaceBlockName>
<DefaultNamespaceNodeName>$</DefaultNamespaceNodeName>

要素の構文:

<Format>yahoo</Format>
デフォルト （なし）
有効な値 次のいずれか:
xml.com、yahoo、google、badgerFish
要否 省略可。ただし、<Options> を使用しない場合は必須。
型 文字列

スキーマ

エラー リファレンス

このセクションでは、このポリシーによってエラーがトリガーされたときに返される障害コードとエラー メッセージ、Apigee によって設定される障害変数について説明します。これは、障害に対処する障害ルールを作成するうえで重要な情報です。詳細については、ポリシーエラーについて知っておくべきことと障害の処理をご覧ください。

ランタイム エラー

このエラーは、ポリシーの実行時に発生することがあります。

障害コード HTTP ステータス 原因 修正
steps.xmltojson.ExecutionFailed ExecutionFailed このエラーは、入力ペイロード（XML）が空の場合、または入力 XML が無効か形式が正しくない場合に発生します。
steps.xmltojson.InCompatibleTypes ExecutionFailed このエラーは、<Source> 要素で定義された変数の型と、<OutputVariable> 要素で定義された変数の型が異なる場合に発生します。<Source> 要素に含まれる変数の型と <OutputVariable> 要素に含まれる変数の型は一致している必要があります。
steps.xmltojson.InvalidSourceType ExecutionFailed このエラーは、<Source> 要素の定義に使用される変数の型が無効な場合に発生します。有効な変数の型は message と string です。
steps.xmltojson.OutputVariableIsNotAvailable ExecutionFailed このエラーは、XML to JSON ポリシーの <Source> 要素で指定された変数が String 型であり、<OutputVariable> 要素が定義されていない場合に発生します。<Source> 要素で定義された変数が文字列型の場合、<OutputVariable> 要素は必須です。
steps.xmltojson.SourceUnavailable ExecutionFailed このエラーは、XML to JSON ポリシーの <Source> 要素で指定された message 変数が、次のいずれかである場合に発生します。
  • 範囲外（ポリシーが実行されている特定のフローで使用できない）
  • 解決不能（未定義）

デプロイエラー

以下のエラーは、このポリシーを含むプロキシをデプロイするときに発生することがあります。

エラー名 原因 修正
EitherOptionOrFormat <Options> または <Format> のいずれかの要素が XML to JSON ポリシーに宣言されていない場合、API プロキシのデプロイは失敗します。
UnknownFormat XML to JSON ポリシー内の <Format> 要素に不明な形式が定義されている場合、API プロキシのデプロイは失敗します。事前定義された形式には、xml.com、yahoo、google、badgerFish があります。

障害変数

ランタイム エラーが発生すると、次の変数が設定されます。詳細については、ポリシーエラーについて知っておくべきことをご覧ください。

変数 説明 例
fault.name="fault_name" fault_name は、上記のランタイム エラーの表に記載されている障害の名前です。障害名は、障害コードの最後の部分です。 fault.name = "SourceUnavailable"
xmltojson.policy_name.failed policy_name は、障害が発生したポリシーのユーザー指定の名前です。 xmltojson.XMLtoJSON-1.failed = true

エラー レスポンスの例

{
  "fault": {
    "faultstring": "XMLToJSON[XMLtoJSON-1]: Source xyz is not available",
    "detail": {
      "errorcode": "steps.xml2json.SourceUnavailable"
    }
  }
}

障害ルールの例

<faultrule name="VariableOfNonMsgType"></faultrule><FaultRule name="XML to JSON Faults">
    <Step>
        <Name>AM-SourceUnavailableMessage</Name>
        <Condition>(fault.name Matches "SourceUnavailable") </Condition>
    </Step>
    <Step>
        <Name>AM-BadXML</Name>
        <Condition>(fault.name = "ExecutionFailed")</Condition>
    </Step>
    <Condition>(xmltojson.XMLtoJSON-1.failed = true) </Condition>
</FaultRule>

関連トピック

JSON から XML: JSON to XML ポリシー