xslt

Verwenden Sie die xslt -Richtlinie, um eine XSLT-Transformation auf die Nutzdaten der API-Definition anzuwenden

Gateway-Unterstützung

Tabelle 1. Tabelle, in der angegeben wird, welche Gateways diese Richtlinie unterstützen, sowie die entsprechende Richtlinienversion
Gateway	Richtlinienversion
DataPower® Gateway (v5 compatible)	1.0.0
DataPower API Gateway	2.0.0 2.1.0 (DataPower API Gateway Version 10.0.4.0 oder höher)

In diesem Abschnitt wird beschrieben, wie Sie die Richtlinie in Ihrer OpenAPI -Quelle konfigurieren. Details zur Konfiguration der Richtlinie in der Assembly-Benutzerschnittstelle finden Sie unter XSLT.

Produktinfo

Die xslt-Richtlinie weist die folgende Struktur auf:

- xslt:
   version: version
   title: Title
   description: Description
   input: Input_True_False
   source: Transform

Hinweis: Bei Verwendung von DataPower API Gatewaymuss die Eingabe für die xslt -Richtlinie geparste Daten sein. Eine Möglichkeit, geparste Daten zu erzeugen, ist die Verwendung einer parse -Richtlinie vor einer xslt -Richtlinie in Ihrem Assembly-Ablauf, die eine explizite Steuerung der Parsing-Aktion ermöglicht.

Eigenschaften

In der folgenden Tabelle werden die Richtlinieneigenschaften beschrieben:

Tabelle 2. xslt Richtlinieneigenschaften
Eigenschaft	Erforderlich	Beschreibung	Datentyp
version	Ja	Die Versionsnummer der Richtlinie	Zeichenfolge
title	Ja	Der Titel der Richtlinie.	Zeichenfolge
description	Nein	Eine Beschreibung der Richtlinie.	Zeichenfolge
input	Nein	Gibt an, ob dieses XSLT-Eingabedokument die aktuellen Kontextnutzdaten verwendet oder ob keine Eingabe vorhanden ist. Der Standardwert ist `false`.	boolesch
serialize-output	Nein	Wenn diese Option auf `true` gesetzt ist, wird die Ausgabebaumstruktur, die von der XSLT-Richtlinie generiert wird, serialisiert. Der Inhalt von `message.body` wird mit den serialisierten Binärdaten statt mit der XML-Baumstruktur aktualisiert. Der Standardwert ist `false`.	boolesch
source	Ja	Die auszuführende XSLT-Umwandlungsquelle.	Zeichenfolge
xslt-version	Nein	Die Version des XSLT-Prozessors. Der Standardwert ist XSLT10.	Zeichenfolge
strict	Nein	Gibt an, ob die strikte XSLT-Fehlerprüfung aktiviert werden soll Bei nicht strengen Operationen wird versucht, nach bestimmten Fehlern, wie z. B. die Verwendung nicht deklarierter Variablen, das Aufrufen nicht deklarierter Voragen usw., eine normale Verarbeitung wiederherzustellen. Standardmäßig ist die strenge XSLT-Fehlerprüfung aktiviert.	boolesch
profile	Nein	Gibt an, ob die Profilerstellung für Style-Sheets aktiviert werden soll Diese Option sollte nicht in Produktionsumgebungen verwendet werden. Standardmäßig ist die Erstellung von Style-Sheet-Profilen inaktiviert.	boolesch
debug	Nein	Gibt an, ob das Style-Sheet, das XQuery-Script und das JSONiq-Script im Debugmodus ausgeführt werden. Wenn ein Style-Sheet, ein XQuery-Script oder ein JSONiq-Script im Debugmodus ausgeführt wird, wird eine angepasste Webseite generiert, anstatt die normale Ausgabe anzuzeigen. Die Webseite gibt genau an, was während der Ausführung passiert ist, einschließlich der Werte von Variablen und der Herkunft bestimmter Bestandteile der Ausgabe. Diese Option sollte nicht in Produktionsumgebungen verwendet werden. Der Debugmodus ist standardmäßig inaktiviert.	boolesch
stream	Nein	Gibt an, ob das Style-Sheet im Datenstrommodus ausgeführt werden muss Die Umsetzung des Dokuments beginnt, bevor die Eingabe vollständig syntaktisch analysiert wird. Nicht alle Style-Sheets können im Datenstrom übertragen werden. Wenn das Style-Sheet nicht gestreamt werden kann, wird ein Fehler generiert und die Eingabe wird nicht verarbeitet. Der Streaming-Modus ist standardmäßig inaktiviert.	boolesch
try-stream	Nein	Gibt an, ob versucht werden soll, das Style-Sheet im Datenstrommodus auszuführen. Die Umsetzung des Dokuments beginnt, bevor die Eingabe vollständig syntaktisch analysiert wird. Nicht alle Style-Sheets können im Datenstrom übertragen werden. Wenn das Style-Sheet nicht gestreamt werden kann, wird während der Kompilierung eine Warnung generiert und das Style-Sheet wird wie üblich in der gesamten Eingabe während der Ausführung gelesen. Standardmäßig ist der Versuch, das Style-Sheet im Streaming-Modus auszuführen, inaktiviert.	boolesch
minimum-escaping	Nein	Gibt an, ob die vom Style-Sheet während der Verarbeitung erzeugte Ausgabe mit Escapezeichen versehen werden soll. Minimales Versehen mit Escapezeichen ist besonders nützlich, wenn Sie nicht englischsprachige Zeichensätze verarbeiten. Standardmäßig ist das minimale Versehen mit Escapezeichen inaktiviert.	boolesch
stack-size	Nein	Die maximale Anzahl Byte, die der Stack beim Ausführen eines Style-Sheets oder anderer kompilierter Inhalte verwenden darf Diese Einstellung wird verwendet, um die unendliche Rekursion zu blockieren. Der Mindestwert ist 10 Kilobyte bzw. 10.240 Byte. Der Maximalwert ist 100 Megabyte bzw. 104.857.600 Byte. Der Standardwert ist 1 Megabyte bzw. 1.048.576 Byte.	ganze Zahl
wsi-validation	Nein	Das Validierungsverhalten für WSDL-Dateien, die auf Konformität mit Abschnitt 5 von WS-I Basic Profile (Version 1.0, April 2004) geprüft werden. Die Standardeinstellung ist Warnung. Ignorieren Inaktiviert die Konformitätsprüfung. Warnung Protokolliert Warnungen vor Verstößen. Fehlgeschlagen Erzwingt die Konformität. Schlägt fehl, wenn die Datei einen Verstoß enthält.	Zeichenfolge
wsdl-validate-body	Nein	Das Validierungsverhalten für `soap:Body`. Die Standardeinstellung ist Strikt. Streng Überprüft diesen Teil auf Basis der WSDL-Definition. Lässt nur Nachrichten zu, die diesen Teil enthalten und der WSDL-Definition entsprechen. Locker Überprüft diesen Teil auf Basis der WSDL-Definition. Wenn die Nachricht diesen Teil enthält und die WSDL-Definition diesen Teil nicht definiert, wird die Nachricht zugelassen. Enthält die Nachricht diesen Teil und definiert die WSDL-Definition diesen Teil, wird die Nachricht nur zugelassen, wenn eine Übereinstimmung vorliegt. Überspringen Inaktiviert die Validierung dieses Nachrichtenteils.	Zeichenfolge
wsdl-validate-headers	Nein	Das Validierungsverhalten für `soap:Header`. Die Standardeinstellung ist Lax. Streng Überprüft diesen Teil auf Basis der WSDL-Definition. Lässt nur Nachrichten zu, die diesen Teil enthalten und der WSDL-Definition entsprechen. Locker Überprüft diesen Teil auf Basis der WSDL-Definition. Wenn die Nachricht diesen Teil enthält und die WSDL-Definition diesen Teil nicht definiert, wird die Nachricht zugelassen. Enthält die Nachricht diesen Teil und definiert die WSDL-Definition diesen Teil, wird die Nachricht nur zugelassen, wenn eine Übereinstimmung vorliegt. Überspringen Inaktiviert die Validierung dieses Nachrichtenteils.	Zeichenfolge
wsdl-validate-faults	Nein	Gibt das Validierungsverhalten für das Fehlerdetail an. Die Standardeinstellung ist Strikt. Streng Überprüft diesen Teil auf Basis der WSDL-Definition. Lässt nur Nachrichten zu, die diesen Teil enthalten und der WSDL-Definition entsprechen. Locker Überprüft diesen Teil auf Basis der WSDL-Definition. Wenn die Nachricht diesen Teil enthält und die WSDL-Definition diesen Teil nicht definiert, wird die Nachricht zugelassen. Enthält die Nachricht diesen Teil und definiert die WSDL-Definition diesen Teil, wird die Nachricht nur zugelassen, wenn eine Übereinstimmung vorliegt. Überspringen Inaktiviert die Validierung dieses Nachrichtenteils.	Zeichenfolge
wsdl-wrapped-faults	Nein	Gibt an, ob Kompatibilität mit RPC-Wrappern erforderlich ist. Standardmäßig sind keine RPC-Wrapper erforderlich.	boolesch
allow-soap-enc-array	Nein	Gibt an, ob das Schema die meisten Verwendungen von Elementen mit`xsi:type='SOAP-ENC:Array'` , die mit SOAP 1.1 Abschnitt 5 konsistent sind, akzeptieren soll, auch wenn diese Attribute gegen die XML Schema-Spezifikation verstoßen. Normalerweise muss das Attribut `xsi:type` einen Typ benennen, der dem tatsächlichen Typ des Elements entspricht oder von diesem abgeleitet ist. Für Schemas, die mit dieser Option kompiliert werden, wird `xsi:type` speziell für den komplexen Typ 'Array' der SOAP 1.1 -Codierung akzeptiert, wenn der Elementtyp von `SOAP-ENC:Array`abgeleitet wird. Das Gegenteil ist der normal zulässige Fall. Standardmäßig werden Elemente mit `xsi:type='SOAP-ENC:Array'` nicht akzeptiert.	boolesch
validate-soap-enc-array	Nein	Gibt an, ob eine zusätzliche Schemaprüfung gemäß den Codierungsregeln in SOAP 1.1 Abschnitt 5 durchgeführt werden soll Wenn diese Option aktiviert ist, werden Member von SOAP-Arrays validiert, Attribute wie @id und @href sind zulässig, auch wenn sie vom Schema nicht zulässig sind, und @href-Werte werden überprüft, um sicherzustellen, dass sie über ein entsprechendes @id-Element verfügen. Die zusätzliche Validierung wird standardmäßig nicht ausgeführt.	boolesch
wildcards-ignore-xsi-type	Nein	Gibt an, ob `xs:any` -Elemente im Schema nur untergeordnete Elemente nach Namen validieren. Die XML Schema-Spezifikation erfordert, dass, wenn ein Platzhalterzeichen mit einem Element übereinstimmt, dieses Element jedoch keine Elementdeklaration hat, das Element stattdessen gemäß einem Attribut `xsi:type` für es validiert wird. Diese Option ignoriert diese `xsi:type` -Attribute. Sie sollte für Fälle wie die Validierung von SOAP-Envelopes verwendet werden, bei denen ein weiterer Validierungsschritt den mit dem Platzhalter übereinstimmenden Inhalt validiert, möglicherweise unter Verwendung der SOAP 1.1-Codierungsregeln. Standardmäßig werden `xsi:type` -Attribute nicht ignoriert.	boolesch
wsdl-strict-soap-version	Nein	Gibt an, ob die SOAP-Bindung in der WSDL strikt eingehalten werden soll Wenn diese Option aktiviert ist, werden nur Nachrichten, die an SOAP 1.2 gebunden sind, in SOAP 1.2-Envelopes angezeigt und nur Nachrichten, die an SOAP 1.1 gebunden sind, werden in SOAP 1.1-Envelopes angezeigt. Die strenge SOAP-Bindung ist standardmäßig inaktiviert.	boolesch
xacml-debug	Nein	Gibt an, ob XACML-Richtlinien mit Debuginformationen kompiliert werden sollen. Beachten Sie, dass die XACML-Debugnachrichten auch durch das Protokollereignis in der XACML-Kategorie gesteuert werden. Verwenden Sie die Debugprotokollstufe, um die vollständigen XACML-Debugnachrichten anzuzeigen. Die XACML-Richtlinien werden standardmäßig nicht mit Debuginformationen kompiliert.	boolesch
allow-xop-include	Nein	Gibt an, ob das Schema oder das WSDL-Dokument Nachrichten akzeptiert, bei denen base64-codierte binäre Inhalte entsprechend den MTOM/XOP-Spezifikationen optimiert wurden. Die XOP-Binäroptimierung ersetzt base64-encoded Binärdaten durch ein `xop:Include` -Referenzelement, das auf die nicht codierten Binärdaten in einem Anhang verweist. Für MTOM/XOP optimierte Nachrichten sind standardmäßig inaktiviert. Wenn diese Option inaktiviert ist, werden solche optimierten Nachrichten durch die Validierung des optimierten Formats abgelehnt. Die Zurückweisung erfolgt, da das Schema einen einfachen Typ angibt, der base64-encoded Daten wie `xs:base64Binary` oder `xs:string`akzeptiert, die Nachricht jedoch stattdessen ein Element `xop:Include` enthält. Wenn diese Option aktiviert ist, kann ein Element `xop:Include` anstelle des Inhalts für jeden einfachen Typ des XML-Schemas angezeigt werden, der base64-encoded Binärdaten validiert. Das Element `xop:Include` selbst wird gemäß dem integrierten Schema in `store:///schemas/xop.xsd`validiert.	boolesch

Sie können auch eine xslt -Richtlinie anwenden, indem Sie mit dem Assembly-Editor API Designer eine integrierte Richtlinie zur API hinzufügen. Weitere Informationen finden Sie unter XSLT im Abschnitt zu integrierten Richtlinien.

Beispiele für die OpenAPI -Definitionen von xslt -Richtlinien finden Sie unter Beispiele für XSLT-Richtlinien im Abschnitt zu integrierten Richtlinien.