XMLtoJSON ポリシー

概要

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

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

特徴

代表的な仲介シナリオでは、受信リクエスト フローでの JSON to XML ポリシーを送信レスポンス フローでの XML to JSON ポリシーとペアにすることが多いです。ポリシーをこのように結び付けることで、XML のみをネイティブ サポートするバックエンド サービスに対して JSON API を公開できます。

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


サンプル

JSON と XML の間の変換についての詳細な説明は、http://community.apigee.com/articles/1839/converting-between-xml-and-json-what-you-need-to-k.html をご覧ください。

レスポンスを変換する

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

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


要素リファレンス

このポリシーで構成できる要素と属性を、以下に示します。

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

name 属性に加えて、管理 UI プロキシ エディタのポリシーに別のわかりやすい名前でラベルを付けるために使います。

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

なし

この要素を省略した場合、ポリシーの name 属性の値が使用されます

要否: 省略可
型: 文字列

<Source> 要素

JSON に変換したい XML メッセージを含む変数、リクエスト、またはレスポンスです。

ソース メッセージの HTTP Content-Type ヘッダーは、必ず application/xml に設定してください。そうしなかった場合、ポリシーが適用されません。

<Source> が定義されていない場合は、メッセージとして扱われます(ポリシーがリクエスト フローに添付されているときはメッセージがリクエストに解決され、ポリシーがレスポンス フローに添付されているときはレスポンスに解決されます)。

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

    <Source>response</Source>
    
デフォルト リクエストまたはレスポンス。ポリシーが API プロキシフローに追加されている場所によって決まります。
要否 省略可
メッセージ

<OutputVariable> 要素

XML to JSON 形式変換の出力を格納します。これは通常はソースと同じ値です。つまり、通常は XML レスポンスが JSON レスポンスに変換されます。

XML メッセージのペイロードは解析されて JSON に変換されます。XML 形式メッセージの HTTP Content-Type ヘッダーは application/json に設定されます。

OutputVariable が指定されていない場合、sourceOutputVariable として扱われます。たとえば、sourceresponse の場合、OutputVariable のデフォルトが response になります。

    <OutputVariable>response</OutputVariable>
    
デフォルト リクエストまたはレスポンス。ポリシーが API プロキシフローに追加されている場所によって決まります。
要否 この要素は、<Source> 要素で定義された変数が string 型の場合は必須です。
メッセージ

<Options>

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

<Format> を使用しない場合は <Options> が必須となります。

<Options>/<RecognizeNumber> 要素

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

    <RecognizeNumber>true</RecognizeNumber>
    

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

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

true の場合、以下に変換されます。

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

false の場合、以下に変換されます。

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

<Options>/<RecognizeBoolean> 要素

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

    <RecognizeBoolean>true</RecognizeBoolean>
    

以下の XML 例の場合:

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

true の場合、以下に変換されます。

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

false の場合、以下に変換されます。

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

<Options>/<RecognizeNull> 要素

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

    <RecognizeNull>true</RecognizeNull>
    

以下の XML の場合:

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

true の場合、以下に変換されます。

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

false の場合、以下に変換されます。

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

<Options>/<NullValue> 要素

変換されるメッセージ内の null 値を構成するものを示します。デフォルトの値は NULL です。

    <NullValue>NULL</NullValue>
    
デフォルト NULL
要否 省略可
文字列

<Options>/<NamespaceBlockName>
<Options>/<DefaultNamespaceNodeName>
<Options>/<NamespaceSeparator> 要素

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

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

NamespaceBlockNameDefaultNamespaceNodeNameNamespaceSeparator の各要素がそれぞれ #namespaces&*** に指定されている場合、次の JSON 構造が生成されます。

    {
        "a": {
            "#namespaces": {
                "&": "http://ns.com",
                "ns1": "http://ns1.com"
            },
            "ns1***b": "value"
        }
    }
    
デフォルト 上の例をご覧ください。
要否 省略可
ただし、<NamespaceBlockName> を指定すると、他の 2 つの要素も指定する必要があります。
Strings

<Options>/<TextAlwaysAsProperty>
<Options>/<TextNodeName> 要素

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

true に設定した場合、XML 要素の内容は文字列プロパティに変換されます。

    <TextAlwaysAsProperty>true</TextAlwaysAsProperty>
    <TextNodeName>TEXT</TextNodeName>
    

以下の XML の場合:

    <a>
      <b>value1</b>
      <c>value2<d>value3</d>value4</c>
    </a>
    

TextAlwaysAsPropertytrue に設定され、TextNodeNameTEXT に指定された場合、次の JSON 構造が生成されます。

    {
      "a": {
        "b": {
          "TEXT": "value1"
        },
        "c": {
          "TEXT": [
            "value2",
            "value4"
            ],
            "d": {
              "TEXT": "value3"
            }
          }
        }
    }
    

TextAlwaysAsPropertyfalse に設定され、TextNodeNameTEXT に指定された場合、次の JSON 構造が生成されます。

    {
      "a": {
        "b": "value1",
        "c": {
          "TEXT": [
            "value2",
            "value4"
          ],
          {
            "d": "value3",
          }
        }
    }
    
デフォルト <TextAlwaysAsProperty>: false
<TextNodeName>: なし
要否 省略可
<TextAlwaysAsProperty>: ブール値
<TextNodeName>: 文字列

<Options>/<AttributeBlockName>
<Options>/<AttributePrefix> 要素

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

値を JSON ブロックにグループ化して、属性名に接頭辞を追加できます。

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

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

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

両方の属性(AttributeBlockNameAttributePrefix)が XML to JSON の例で定義されているとおりに指定されている場合、次の 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"
        }
    }
    
デフォルト 上の例をご覧ください。
要否 省略可
文字列

<Options>/<OutputPrefix>
<Options>/<OutputSuffix> 要素

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

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

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

    <a>value</a>
    

両方の属性(OutputPrefixOutputSuffix)が XML to JSON の例で定義されているとおりに指定されている場合、次の JSON 構造が生成されます。

    PREFIX_{
        "a": "value"
    }_SUFFIX
    

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

    PREFIX_{
      "a" : "value"
    }
    

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

    {
      "a" : "value"
    }_SUFFIX
    

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

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

<Options>/<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"
                }
             }
          }
       }
    }
    

最初の 4 つのレベルを JSON レスポンスから除去したい場合は、<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 (レベル除去なし)
要否 省略可
整数

<Options>/<TreatAsArray>/<Path> 要素

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

これらの要素の組み合わせにより、XML ドキュメントの値を確実に JSON 配列に入れることができます。これは、たとえば子要素の数が(1 から複数まで)異なる可能性があり、値を常に配列内に入れるようにしたい場合に役立ちます。こうすることで、配列からデータを毎回同じように取得できるため、コードを安定させることができます。たとえば $.teachers.teacher.studentnames[0] は、配列内の値の数に関係なく、配列内で最初の生徒名の値を取得します。

少し前に戻って XML to JSON のデフォルト動作を見てみましょう。それから、<TreatAsArray>/<Path> を使用して出力をコントロールする方法を探しましょう。

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 ポリシーは自動的にこの値を、文字列の配列でなく、ひとつの文字列として扱います。これを、下の例で示します。

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

これまでの例では、同様のデータが、あるものは配列に、またあるものはひとつの文字列にと、さまざまな方法で変換されていました。そこで <TreatAsArray>/<Path> 要素を使用することにより、出力を制御できるようになります。たとえば、生徒名の値が 1 つしかなくても、常に配列に入れられるようにできます。このように構成するには、配列に入れたい値を持つ要素へのパスを、以下のようにして見つけます。

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

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

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

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

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

デフォルト なし
要否 省略可
String

属性

     <Options>
        <TreatAsArray>
            <Path unwrap="true">teachers/teacher/studentnames/name</Path>
        </TreatAsArray>
    </Options>
    
属性 説明 要否
unwrap

デフォルト: 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 出力で配列として扱わる点にご留意ください。

省略可 ブール値

その他の例と機能の説明については、Apigee コミュニティ の記事: https://community.apigee.com/content/kbentry/33374/new-edge-minifeature-the-treatasarray-option-in-th.html をご覧ください。

<Format>

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

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

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

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.comyahoogooglebadgerFish
要否 <Options> を使用していない場合は必須です。
文字列

スキーマ


エラー リファレンス

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

ランタイム エラー

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

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

デプロイエラー

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

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

障害変数

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

変数 説明
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 to XML: JSON to XML ポリシー