Diese Seite gilt für Apigee und Apigee Hybrid.
Apigee Edge-Dokumentation aufrufen
Was
Diese Richtlinie konvertiert Nachrichten aus dem erweiterbaren Markup Language-Format (XML) in die JavaScript Object Notation (JSON). Dadurch haben Sie mehrere Möglichkeiten, die Konvertierung von Nachrichten zu steuern.
Angenommen, der Intent ist die Konvertierung einer XML-formatierten Antwort in eine JSON-formatierte Antwort. In diesem Fall wird die Richtlinie an einen Antwortablauf angehängt (z. B. Response / ProxyEndpoint / PostFlow).
Diese Richtlinie ist eine Standardrichtlinie, die in jeder Umgebung bereitgestellt werden kann. Informationen zu Richtlinientypen und zur Verfügbarkeit bei jedem Umgebungstyp finden Sie unter Richtlinientypen.
Info
In einem typischen Vermittlungsszenario wird eine JSON-zu-XML-Richtlinie für den eingehenden Anfragefluss häufig mit einer XML-zu-JSON-Richtlinie im ausgehenden Antwortfluss kombiniert. Durch die Kombination der Richtlinien kann eine JSON API für Back-End-Dienste verfügbar gemacht werden, die nativ nur XML unterstützen.
In Szenarien, in denen APIs von verschiedenen Client-Anwendungen genutzt werden, die JSON oder XML erfordern, kann das Antwortformat dynamisch festgelegt werden. Dazu konfigurieren Sie die Ausführungen der JSON-zu-XML- und XML-zu-JSON-Richtlinien nach Bedingungen. Eine Implementierung dieses Szenarios finden Sie unter Ablaufvariablen und -bedingungen.
Beispiele
Ausführliche Informationen zum Konvertieren von JSON und XML finden Sie in diesem Artikel.
Antwort konvertieren
<XMLToJSON name="ConvertToJSON"> <Options> </Options> <OutputVariable>response</OutputVariable> <Source>response</Source> </XMLToJSON>
Diese Konfiguration – die Minimalkonfiguration, die für die Konvertierung von XML in JSON erforderlich ist – verwendet eine XML-formatierte Antwort als Quelle und erstellt dann eine JSON-formatierte Nachricht, die in die response
OutputVariable eingetragen wird. Apigee verwendet den Inhalt dieser Variable automatisch als Nachricht für den nächsten Verarbeitungsschritt.
Elementverweis
Die folgenden Elemente und Attribute können Sie für diese Richtlinie konfigurieren:
<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>-Attribute
<XMLtoJSON async="false" continueOnError="false" enabled="true" name="XML-to-JSON-1">
In der folgenden Tabelle werden Attribute beschrieben, die für alle übergeordneten Richtlinienelemente gelten:
Attribut | Beschreibung | Standard | Presence |
---|---|---|---|
name |
Der interne Name der Richtlinie. Der Wert des Attributs Optional können Sie das Element |
– | Erforderlich |
continueOnError |
Legen Sie Legen Sie |
false | Optional |
enabled |
Setzen Sie den Wert auf Legen Sie |
true | Optional |
async |
Dieses Attribut wurde verworfen. |
false | Verworfen |
<DisplayName>-Element
Wird zusätzlich zum Attribut name
verwendet, um die Richtlinie im Proxy-Editor der Verwaltungs-UI mit einem anderen Namen in einer natürlichen Sprache zu versehen.
<DisplayName>Policy Display Name</DisplayName>
Standard |
– Wenn Sie dieses Element weglassen, wird der Wert des Namensattributs |
---|---|
Presence | Optional |
Typ | String |
<Source>-Element
Die Variable, die die XML-Nachricht angibt, die in JSON konvertiert werden soll.
Der HTTP-Inhaltstyp-Header der Quellnachricht muss auf application/xml
gesetzt sein, andernfalls wird die Richtlinie nicht erzwungen.
Wenn <Source>
nicht definiert ist, wird sie als message
behandelt. Diese löst sich in request
auf, wenn die Richtlinie an einen Anfragefluss angehängt ist, oder in response
, wenn die Richtlinie an einen Antwortablauf angehängt ist.
Wenn die Quellvariable nicht aufgelöst werden kann oder in einen Nicht-Nachrichtentyp aufgelöst wird, gibt die Richtlinie einen Fehler aus.
<Source>response</Source>
Standard | Der Wert des Source -Elements |
---|---|
Präsenz | Optional |
Typ | Meldung |
<OutputVariable>-Element
Gibt an, wo die Ausgabe der XML-zu-JSON-Formatkonvertierung gespeichert werden soll. Dieses Element ist in der Regel nicht in der Richtlinienkonfiguration enthalten.
Apigee analysiert die Nutzlast der in Source
angegebenen XML-Nachricht, konvertiert sie in JSON, speichert das Ergebnis in der Nutzlast von OutputVariable
und setzt den HTTP-Content-Type-Header der OutputVariable
-Nachricht auf application/json
.
Wenn OutputVariable
nicht angegeben wird, wird standardmäßig der Wert Source
verwendet. Beispiel: Wenn source
response
ist, dann wird OutputVariable
standardmäßig auf response
gesetzt.
<OutputVariable>response</OutputVariable>
Standard | die in Source angegebene Nachricht |
---|---|
Präsenz | Optional |
Typ | Meldung |
<Options>
Mit Optionen können Sie die XML-zu-JSON-Umwandlung steuern. Verwenden Sie entweder die Gruppe <Options>
, mit der Sie bestimmte Konvertierungseinstellungen hinzufügen können, oder verwenden Sie das Element <Format>
, mit dem Sie eine Vorlage mit vordefinierten Optionen referenzieren können. Sie können nicht sowohl <Options>
als auch <Format>
verwenden.
<Options>
ist erforderlich, wenn <Format>
nicht verwendet wird.
<RecognizeNumber>-Element
Bei „true“ behalten Zahlenfelder in der XML-Nutzlast ihr ursprüngliches Format bei.
<RecognizeNumber>true</RecognizeNumber>
Betrachten Sie folgendes XML-Beispiel:
<a> <b>100</b> <c>value</c> </a>
Wenn RecognizeNumber
den Wert true
hat, wird dies gemäß der Richtlinie in Folgendes umgewandelt:
{ "a": { "b": 100, "c": "value" } }
Wenn RecognizeNumber
den Wert false
hat, wird dies gemäß der Richtlinie in Folgendes umgewandelt:
{ "a": { "b": "100", "c": "value" } }
Standard | false |
---|---|
Präsenz | Optional |
Typ | Boolesch |
<RecognizeBoolean>-Element
Erlaubt es der Konvertierung, boolesche Richtig/Falsch-Werte beizubehalten, anstatt die Werte in Strings umzuwandeln.
<RecognizeBoolean>true</RecognizeBoolean>
Für das folgende XML-Beispiel gilt:
<a> <b>true</b> <c>value</c> </a>
Wenn RecognizeBoolean
den Wert true
hat, wird dies gemäß der Richtlinie in Folgendes umgewandelt:
{ "a": { "b": true, "c": "value" } }
Wenn RecognizeBoolean
den Wert false
hat, wird dies gemäß der Richtlinie in Folgendes umgewandelt:
{ "a": { "b": "true", "c": "value" } }
Standard | false |
---|---|
Präsenz | Optional |
Typ | Boolesch |
<RecognizeNull>-Element
Hiermit können leere Werte in Nullwerte konvertiert werden.
<RecognizeNull>true</RecognizeNull>
Für die folgende XML-Datei:
<a> <b></b> <c>value</c> </a>
Wenn RecognizeNull
true
ist und es keine NullValue
-Option gibt, wird diese XML-Datei in Folgendes umgewandelt:
{ "a": { "b": null, "c": "value" } }
Wenn RecognizeNull
den Wert false
hat, wird diese XML-Datei in Folgendes konvertiert:
{ "a": { "b": {}, "c": "value" } }
Standard | false |
---|---|
Präsenz | Optional |
Typ | Boolesch |
<NullValue>-Element
Gibt den Wert an, in den erkannte Nullwerte in der Quellnachricht konvertiert werden sollen. Der Standardwert ist null
. Diese Option ist nur wirksam, wenn RecognizeNull
wahr ist.
<NullValue>not-present</NullValue>
Für die folgende XML-Datei:
<a> <b></b> <c>value</c> </a>
Wenn RecognizeNull
true
ist und NullValue
nicht angegeben ist, wird diese XML in Folgendes umgewandelt:
{ "a": { "b": null, "c": "value" } }
Wenn RecognizeNull
true
und NullValue
not-present
ist, wird diese XML-Datei in Folgendes konvertiert:
{ "a": { "b": "not-present", "c": "value" } }
Standard | null |
---|---|
Präsenz | Optional |
Typ | String |
Namespace-Optionen
Standardmäßig werden mit dieser Richtlinie XML-Namespaces aus der generierten JSON-Datei entfernt. Wenn Sie angeben möchten, dass Namespaces im XML-Dokument in die generierte JSON-Datei übersetzt werden sollen, verwenden Sie diese Elemente zusammen.
<NamespaceBlockName>#namespaces</NamespaceBlockName> <DefaultNamespaceNodeName>&</DefaultNamespaceNodeName> <NamespaceSeparator>***</NamespaceSeparator>
Betrachten Sie folgendes XML-Beispiel:
<a xmlns="http://ns.com" xmlns:ns1="http://ns1.com"> <ns1:b>value</ns1:b> </a>
Ist NamespaceSeparator
nicht angegeben, so wird die folgende JSON-Struktur generiert:
{ "a": { "b": "value" } }
Wenn die Elemente NamespaceBlockName
, DefaultNamespaceNodeName
und NamespaceSeparator
als #namespaces
, &
bzw. ***
angegeben werden, wird die folgende JSON-Struktur generiert:
{ "a": { "#namespaces": { "&": "http://ns.com", "ns1": "http://ns1.com" }, "ns1***b": "value" } }
Standard | – Wenn <NamespaceBlockName> nicht angegeben ist, generiert die Richtlinie eine JSON-Ausgabe, die sich nicht auf XML-Namespaces bezieht, unabhängig davon, ob die Quellnachricht auf Namespaces verweist. |
---|---|
Präsenz | Optional Wenn Sie <NamespaceBlockName> angeben, müssen Sie auch die anderen beiden Elemente angeben. |
Typ | Strings |
Textoptionen
Verwenden Sie diese Elemente zusammen.
<TextAlwaysAsProperty>true|false</TextAlwaysAsProperty> <TextNodeName>TEXT</TextNodeName>
Wenn die Richtlinie auf ein XML-Element stößt, das nur einen einzigen Textknoten als untergeordnetes Element enthält, wird der Textinhalt dieses XML-Elements in eine Eigenschaft im JSON-Hash umgewandelt.
Wenn die Richtlinie auf ein XML-Element stößt, das mehrere untergeordnete Elemente mit gemischten Inhalten enthält, können Sie mit diesen Optionen die JSON-Ausgabe aller untergeordneten Textknoten steuern.
Betrachten Sie beispielsweise diese Richtlinienkonfiguration:
<XMLToJSON name='XMLToJSON-1'> <Options> <TextAlwaysAsProperty>???</TextAlwaysAsProperty> <TextNodeName>#text</TextNodeName> </Options> </XMLToJSON>
Für die angegebenen XML-Eingabedaten werden je nachdem, ob TextAlwaysAsProperty
true
oder false
ist, die folgenden Ausgaben generiert:
XML-Eingabe | JSON-Ausgabe | |
---|---|---|
wenn TextAlwaysAsProperty = false |
wenn 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" } } } |
Standard | <TextAlwaysAsProperty> : false<TextNodeName> : (leerer String) |
---|---|
Präsenz | Optional |
Typ | <TextAlwaysAsProperty> : Boolean<TextNodeName> : String |
Attributoptionen
Mit diesen Elementen können Sie Attributwerte in einem JSON-Block gruppieren und Präfixe an die Attributnamen anhängen.
<AttributeBlockName>FOO_BLOCK</AttributeBlockName> <AttributePrefix>BAR_</AttributePrefix>
Betrachten Sie folgendes XML-Beispiel:
<a attrib1="value1" attrib2="value2"/>
Wenn beide Attribute (AttributeBlockName
als auch AttributePrefix
) so angegeben werden, wie im Beispiel XML zu JSON definiert, wird die folgende JSON-Struktur generiert:
{ "a": { "FOO_BLOCK": { "BAR_attrib1": "value1", "BAR_attrib2": "value2" } } }
Wenn nur AttributeBlockName
angegeben ist, wird folgende JSON-Struktur generiert:
{ "a": { "FOO_BLOCK": { "attrib1": "value1", "attrib2": "value2" } } }
Wenn nur AttributePrefix
angegeben ist, wird folgende JSON-Struktur generiert:
{ "a": { "BAR_attrib1": "value1", "BAR_attrib2": "value2" } }
Ist keines von beiden angegeben, so wird folgende JSON-Struktur generiert:
{ "a": { "attrib1": "value1", "attrib2": "value2" } }
Standard | Keine. |
---|---|
Präsenz | Optional |
Typ | String |
<OutputPrefix>- und <OutputSuffix>-Elemente
Verwenden Sie diese Elemente zusammen, um dem generierten JSON ein Präfix und/oder Suffix hinzuzufügen.
<OutputPrefix>PREFIX_</OutputPrefix> <OutputSuffix>_SUFFIX</OutputSuffix>
Betrachten Sie folgendes XML-Beispiel:
<a>value</a>
Angenommen, die Richtlinienkonfiguration sieht so aus:
<XMLToJSON name='XMLToJSON-4'> <Options> <OutputPrefix>{ "result": </OutputPrefix> <OutputSuffix>}</OutputSuffix> </Options> </XMLToJSON>
Die folgende JSON-Struktur wird generiert:
{ "result": { "a": "value" } }
Sie können OutputPrefix
und/oder OutputSuffix
weglassen.
Mit diesen Elementen kann ungültiges JSON generiert werden. Verwenden Sie beispielsweise diese Richtlinienkonfiguration:
<XMLToJSON name='XMLToJSON-4'> <Options> <OutputPrefix>PREFIX_</OutputPrefix> </Options> </XMLToJSON>
Die Richtlinie generiert Folgendes, was keine gültige JSON-Datei ist:
PREFIX_{ "a" : "value" }
Wenn in der Konfiguration weder OutputPrefix
noch OutputSuffix
angegeben ist, wird von der Richtlinie die folgende JSON-Struktur generiert:
{ "a": "value" }
Standard | Siehe Beispiele oben. |
---|---|
Präsenz | Optional |
Typ | String |
<StripLevels>-Element
<Options> <StripLevels>4</StripLevels> </Options>
Manchmal haben XML-Nutzlasten (z. B. SOAP) viele übergeordnete Ebenen, die Sie nicht in das konvertierte JSON-Format aufnehmen möchten. Im Folgenden sehen Sie eine Beispiel-SOAP-Antwort mit vielen Ebenen:
<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>
Es gibt vier Stufen, bevor du zum Bundesland, zum Ort, zur Beschreibung und zum Temperaturbereich gelangst.
Ohne <StripLevels>
würde die konvertierte JSON-Antwort so aussehen:
{ "Envelope" : { "Body" : { "GetCityWeatherByZIPResponse" : { "GetCityWeatherByZIPResult" : { "State" : "CO", "City" : "Denver", "Description" : "Sunny", "Temperature" : "62" } } } } }
Um diese ersten vier Ebenen aus der JSON-Antwort zu entfernen, legen Sie <StripLevels>4</StripLevels>
fest. Das Ergebnis würde folgende JSON-Datei zur Verfügung stellen:
{ "State" : "CO", "City" : "Denver", "Description" : "Sunny", "Temperature" : "62" }
Sie können Ebenen bis zum ersten Element entfernen, das mehrere untergeordnete Elemente enthält. Was bedeutet das? Sehen wir uns ein komplexeres JSON-Beispiel an:
{ "Envelope" : { "Body" : { "GetCityForecastByZIPResponse" : { "GetCityForecastByZIPResult" : { "ResponseText" : "City Found", "ForecastResult" : { "Forecast" : [ { "ProbabilityOfPrecipiation" : { "Nighttime" : "00", "Daytime" : 10 } ...
Ebene 3 ist in diesem Beispiel GetCityForecastByZIPResponse
, das nur ein untergeordnetes Element hat. Wenn Sie also <StripLevels>3</StripLevels>
verwenden (die ersten drei Ebenen entfernen), würde die JSON-Datei so aussehen:
{ "GetCityForecastByZIPResult" : { "ResponseText" : "City Found", "ForecastResult" : { "Forecast" : [ { "ProbabilityOfPrecipiation" : { "Nighttime" : "00", "Daytime" : 10 } ...
Beachten Sie, dass GetCityForecastByZIPResult
mehrere untergeordnete Elemente hat. Da dies das erste Element mit mehreren untergeordneten Elementen ist, können Sie diese letzte Ebene mithilfe von <StripLevels>4</StripLevels>
entfernen. Dadurch erhalten Sie die folgende JSON:
{ "ResponseText" : "City Found", "ForecastResult" : { "Forecast" : [ { "ProbabilityOfPrecipiation" : { "Nighttime" : "00", "Daytime" : 10 } ...
Da Ebene 4 die erste Ebene ist, die mehrere untergeordnete Elemente enthält, können Sie keine tieferliegende Ebenen entfernen. Wenn Sie die Ebenen 5, 6, 7 zu entfernen versuchen, erhalten Sie weiterhin obige Antwort.
Standard | 0 (keine Ebenenentfernung) |
---|---|
Präsenz | Optional |
Typ | Ganzzahl |
<TreatAsArray>/<Path>-Element
<Options> <TreatAsArray> <Path unwrap="true">teachers/teacher/studentnames/name</Path> </TreatAsArray> </Options>
Mit dieser Elementkombination können Sie dafür sorgen, dass Werte aus einem XML-Dokument immer in ein JSON-Array umgewandelt werden. Dies kann nützlich sein, wenn die Anzahl der untergeordneten Elemente für unterschiedliche Nutzlasten variiert. Standardmäßig werden in Apigee mehrere untergeordnete Elemente mit demselben Namen in ein JSON-Array und einzelne untergeordnete Elemente in ein JSON-Primitive umgewandelt. Mit der Option TreatAsArray
können Sie dafür sorgen, dass untergeordnete Elemente immer in ein JSON-Array umgewandelt werden.
Mit TreatAsArray
lässt sich die Struktur des nachfolgenden Codes, der die Ausgabe verarbeitet, verbessern, da Daten aus dem Array jedes Mal auf die gleiche Weise zurückgegeben werden. Wenn Sie beispielsweise einen JSONPath von $.teachers.teacher.studentnames.name[0]
auswerten, wird der Wert für den Vornamen immer gleich zurückgegeben, unabhängig davon, ob das ursprüngliche XML-Element ein oder mehrere name
-Elemente enthält.
Wir sehen uns noch einmal das Standardverhalten von XML-zu-JSON an und untersuchen, wie Sie die Ausgabe mit <TreatAsArray>/<Path>
steuern.
Wenn ein XML-Dokument ein Element mit mehreren Vorkommen enthält (was passieren kann, wenn das XML-Schema maxOccurs='unbounded'
für das Element angibt), werden diese Werte durch die Richtlinie „XML-zu-JSON“ automatisch in ein Array eingefügt. Beispiel: Der folgende XML-Block
<teacher> <name>teacherA</name> <studentnames> <name>student1</name> <name>student2</name> </studentnames> </teacher>
...wird automatisch in die folgende JSON-Datei ohne spezielle Richtlinienkonfiguration konvertiert:
{ "teachers" : { "teacher" : { "name" : "teacherA", "studentnames" : { "name" : [ "student1", "student2" ] } } } }
Beachten Sie, dass die beiden Namen der Schüler in einem Array enthalten sind.
Ist jedoch nur ein Schüler im XML-Dokument vorhanden, so wird dieser Wert in der Richtlinie „XML-zu-JSON“ automatisch als einzelner String und nicht als String-Array behandelt, wie im folgenden Beispiel gezeigt:
{ "teachers" : { "teacher" : { "name" : "teacherA", "studentnames" : { "name" : "student1" } } } }
In den vorherigen Beispielen wurden ähnliche Daten einmal in ein Array, einmal in einen einzelnen String konvertiert. Mit dem Element <TreatAsArray>/<Path>
können Sie die Ausgabe so steuern, dass die Namen der Schüler immer in ein Array umgewandelt werden, auch wenn es nur einen Wert gibt. Konfigurieren Sie dazu den Pfad zu dem Element, dessen Werte Sie in ein Array umwandeln möchten. Beispiel:
<Options> <TreatAsArray> <Path>teachers/teacher/studentnames/name</Path> </TreatAsArray> </Options>
Die Konfiguration oben würde den JSON-Code so generieren:
{ "teachers" : { "teacher" : { "name" : "teacherA", "studentnames" : { "name" : ["student1"] } } } }
Beachten Sie, dass „Student1“ jetzt in einem Array enthalten ist. Unabhängig davon, ob es sich um einen oder mehrere Studenten handelt, können Sie diese in Ihrem Code mit folgendem JSONPath-Wert abrufen:
$.teachers.teacher.studentnames.name[0]
Das <Path>
-Element verfügt außerdem über ein unwrap
-Attribut, das im nächsten Abschnitt erläutert wird.
Standard | – |
---|---|
Präsenz | Optional |
Typ | String |
Attribute
<Options> <TreatAsArray> <Path unwrap="true">teachers/teacher/studentnames/name</Path> </TreatAsArray> </Options>
Attribut | Beschreibung | Präsenz | Typ |
---|---|---|---|
entpacken |
Standardwert: false Das Element wird aus der JSON-Ausgabe entfernt. Verwenden Sie diese Option, um die JSON-Datei zu optimieren oder zu „verpacken“ und damit den JSON-Pfad zu reduzieren, der zum Abrufen von Werten erforderlich ist. Beispielsweise können Sie anstelle von Hier ein JSON-Beispiel: { "teachers" : { "teacher" : { "name" : "teacherA", "studentnames" : { "name" : [ "student1", "student2" ]}... In diesem Beispiel könnten Sie vermuten, dass die Elemente <TreatAsArray> <Path unwrap="true">teachers/teacher</Path> <Path unwrap="true">teachers/teacher/studentnames/name</Path> </TreatAsArray> Das Attribut { "teachers" : [{ "name" : "teacherA", "studentnames" : ["student1","student2"] }]... Da sich das Element |
Optional | Boolesch |
Weitere Beispiele und eine Schritt-für-Schritt-Anleitung finden Sie in diesem Google Cloud Community-Artikel.
<Format>
Mit dem Format können Sie die Umwandlung von XML in JSON steuern. Geben Sie den Namen einer vordefinierten Vorlage ein, die eine bestimmte Kombination der in diesem Thema beschriebenen Optionen enthält.
Vordefinierte Formate sind xml.com
, yahoo
, google
und badgerFish
.
Verwenden Sie entweder das <Format>
-Element oder die <Options>
-Gruppe. Sie können nicht sowohl <Format>
als auch <Options>
verwenden.
Im Folgenden finden Sie die Formatdefinitionen der einzelnen vordefinierten Vorlagen.
xml.com
<RecognizeNull>true</RecognizeNull> <TextNodeName>#text</TextNodeName> <AttributePrefix>@</AttributePrefix>
yahoo
<RecognizeNumber>true</RecognizeNumber> <TextNodeName>content</TextNodeName>
<TextNodeName>$t</TextNodeName> <NamespaceSeparator>$</NamespaceSeparator> <TextAlwaysAsProperty>true</TextAlwaysAsProperty>
badgerFish
<TextNodeName>$</TextNodeName> <TextAlwaysAsProperty>true</TextAlwaysAsProperty> <AttributePrefix>@</AttributePrefix> <NamespaceSeparator>:</NamespaceSeparator> <NamespaceBlockName>@xmlns</NamespaceBlockName> <DefaultNamespaceNodeName>$</DefaultNamespaceNodeName>
Element-Syntax:
<Format>yahoo</Format>
Standard | (keine) |
---|---|
Zulässige Werte | Einer der folgenden Werte:xml.com , yahoo , google , badgerFish |
Präsenz | Optional, aber erforderlich, wenn <Options> nicht verwendet wird. |
Typ | String |
Schemas
Fehlerreferenz
In diesem Abschnitt werden die zurückgegebenen Fehlercodes und Fehlermeldungen beschrieben, die von Apigee festgelegt werden, wenn die Richtlinie einen Fehler auslöst. Diese Informationen sind wichtig, wenn Sie Fehlerregeln zur Verarbeitung von Fehlern entwickeln. Weitere Informationen finden Sie unter Was Sie über Richtlinienfehler wissen müssen und Fehler beheben.
Laufzeitfehler
Diese Fehler können bei Ausführung der Richtlinie auftreten.
Fehlercode | HTTP-Status | Ursache | Diverse Fehlerkorrekturen |
---|---|---|---|
steps.xmltojson.ExecutionFailed |
ExecutionFailed |
Dieser Fehler tritt auf, wenn die Eingabenutzlast (XML) leer ist oder die Eingabe-XML ungültig oder fehlerhaft ist. | build |
steps.xmltojson.InCompatibleTypes |
ExecutionFailed |
Dieser Fehler tritt auf, wenn der Typ der im Element <Source> definierten Variable und das Element <OutputVariable> nicht identisch sind. Der Typ der im Element <Source> enthaltenen Variablen muss mit dem Typ der im Element <OutputVariable> enthaltenden Variable übereinstimmen.
|
build |
steps.xmltojson.InvalidSourceType |
ExecutionFailed |
Dieser Fehler tritt auf, wenn der Typ der Variablen zum Definieren des Elements <Source> ungültig ist. Gültige Variablentypen sind "message" und "string". |
build |
steps.xmltojson.OutputVariableIsNotAvailable |
ExecutionFailed |
Dieser Fehler tritt auf, wenn die im <Source> -Element der XML-zu-JSON-Richtlinie angegebene Variable den Typ "String" aufweist und das Element <OutputVariable> nicht definiert ist.
Das Element <OutputVariable> ist obligatorisch, wenn die im Element <Source> definierte Variable vom Typ "String" ist. |
build |
steps.xmltojson.SourceUnavailable |
ExecutionFailed |
Dieser Fehler tritt auf, wenn die im Element <Source> der XML-zu-JSON-Richtlinie angegebene Variable message entweder:
|
build |
Bereitstellungsfehler
Diese Fehler können auftreten, wenn Sie einen Proxy mit dieser Richtlinie bereitstellen.
Fehlername | Ursache | Diverse Fehlerkorrekturen |
---|---|---|
EitherOptionOrFormat |
Ist eines der Elemente <Options> oder <Format> in der "XML-to-JSON"-Richtlinie nicht deklariert, schlägt die Bereitstellung des API-Proxys fehl. |
build |
UnknownFormat |
Wenn für das Element <Format> in der "XML-to-JSON"-Richtlinie ein unbekanntes Format definiert ist, schlägt die Bereitstellung des API-Proxys fehl. Vordefinierte Formate sind: xml.com , yahoo , google und badgerFish .
|
build |
Fehlervariablen
Diese Variablen werden bei Laufzeitfehlern festgelegt. Weitere Informationen finden Sie unter Was Sie über Richtlinienfehler wissen müssen.
Variablen | Wo | Beispiel |
---|---|---|
fault.name="fault_name" |
fault_name ist der Name des Fehlers, der in der obigen Tabelle Laufzeitfehler aufgeführt ist. Der Fehlername ist der letzte Teil des Fehlercodes. | fault.name = "SourceUnavailable" |
xmltojson.policy_name.failed |
policy_name ist der benutzerdefinierte Name der Richtlinie, die den Fehler ausgelöst hat. | xmltojson.XMLtoJSON-1.failed = true |
Beispiel für eine Fehlerantwort
{ "fault": { "faultstring": "XMLToJSON[XMLtoJSON-1]: Source xyz is not available", "detail": { "errorcode": "steps.xml2json.SourceUnavailable" } } }
Beispiel für eine Fehlerregel
<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>
Weitere Informationen
JSON zu XML: JSON-zu-XML-Richtlinie