SOAPMessageValidation-Richtlinie

Diese Seite gilt für Apigee und Apigee Hybrid.

Apigee Edge-Dokumentation aufrufen

Die SOAPMessageValidation-Richtlinie führt Folgendes aus:

• Validiert alle XML-Nachrichten anhand ihrer XSD-Schemas
• Überprüft SOAP-Nachrichten anhand einer WSDL-Definition
• Bestimmt die Wohlgeformtheit von JSON- und XML-Nachrichten

Auch wenn der Name dieser Richtlinie in der UI SOAPMessageValidation lautet, validiert die Richtlinie mehr als nur SOAP-Nachrichten. In diesem Abschnitt wird die Richtlinie als MessageValidation-Richtlinie bezeichnet.

Die MessageValidation-Richtlinie bietet folgende Vorteile:

• Informiert umgehend App-Entwickler, die Ihre API verwenden, wenn ihre Anfragen nicht konform oder unvollständig sind.
• Zeigt Probleme in Anfragen an, z. B. XML-Tags, die nicht ordnungsgemäß geschlossen sind.
• Schützt Back-End-Dienste durch Blockieren von XML- oder SOAP-Nachrichten mit Strukturen, die unvorhersehbares Verhalten verursachen können.
• Reduziert den Zeitaufwand für die Fehlerbehebung, die Suche in Foren oder die Beratung durch den technischen Support.
• Entwickler dazu animieren, sich mit der WSDL-Definition des XML-Schemas vertraut zu machen, indem Sie wohlbekanntes XML zu einer Schlüsselkomponente Ihrer API-Dokumentation machen.

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.

Videos

In den folgenden Videos erfahren Sie mehr über die MessageValidation-Richtlinie:

Video	Beschreibung
XML-Anfrage validieren	Validieren Sie die XML-Anfrage für eine API mithilfe der MessageValidation-Richtlinie.
JSON-Anfrage validieren	Validieren Sie die JSON-Anfrage für eine API mithilfe der MessageValidation-Richtlinie.

Element <MessageValidation>

Definiert die MessageValidation-Richtlinie.

Standardwert	Siehe Tab Standardrichtlinie unten.
Erforderlich?	Optional
Typ	Komplexes Objekt
Übergeordnetes Element	–
Untergeordnete Elemente	<DisplayName> <Element> <ResourceURL> <SOAPMessage> <Source>

Syntax

Das <MessageValidation>-Element verwendet die folgende Syntax:

<MessageValidation
  continueOnError="[false|true]"
  enabled="[true|false]"
  name="policy_name"
>
    <!-- All MessageValidation child elements are optional -->
    <DisplayName>policy_display_name</DisplayName>
    <Element namespace="element_namespace">element_to_validate</Element>
    <SOAPMessage version="[ 1.1 | 1.2 | 1.1/1.2 ]"/>
    <Source>message_to_validate</Source>
    <ResourceURL>validation_WSDL_or_XSD</ResourceURL>

</MessageValidation>

Standardrichtlinie

Das folgende Beispiel zeigt die Standardeinstellungen, wenn Sie in der Apigee-UI Ihrem Ablauf eine MessageValidation-Richtlinie hinzufügen:

<MessageValidation continueOnError="false" enabled="true" name="SOAP-Message-Validation-1">
  <DisplayName>SOAP Message Validation-1</DisplayName>
  <Properties/>
  <Element namespace="http://sample.com">sampleObject</Element>
  <SOAPMessage/>
  <Source>request</Source>
  <ResourceURL>wsdl://SOAP-Message-Validation-1.wsdl</ResourceURL>
</MessageValidation>

Dieses Element hat folgende Attribute, die allen Richtlinien gemeinsam sind:

Attribut	Standard	Erforderlich?	Beschreibung
name	-	Erforderlich	Der interne Name der Richtlinie. Der Wert des Attributs name kann Buchstaben, Ziffern, Leerzeichen, Bindestriche, Unterstriche und Punkte enthalten. Dieser Wert darf 255 Zeichen nicht überschreiten. Optional können Sie das Element <DisplayName> verwenden, um die Richtlinie im Proxy-Editor der Verwaltungs-UI mit einem anderen Namen in einer natürlichen Sprache zu versehen.
continueOnError	false	Optional	Legen Sie false fest, um einen Fehler zurückzugeben, wenn eine Richtlinie fehlschlägt. Dies ist für die meisten Richtlinien das erwartete Verhalten. Legen Sie true fest, damit die Ablaufausführung auch nach dem Fehlschlagen einer Richtlinie fortgesetzt wird. Weitere Informationen: Fehlerregeln werden NUR im Fehlerzustand ausgelöst (über continueOnError) Umgang mit Fehlern im aktuellen Ablauf
enabled	wahr	Optional	Setzen Sie den Wert auf true, um die Richtlinie zu erzwingen. Legen Sie false fest, um die Richtlinie zu deaktivieren. Die Richtlinie wird nicht durchgesetzt, selbst wenn sie mit einem Ablauf verknüpft ist.
async	false	Verworfen	Dieses Attribut wurde verworfen.

Beispiele

Die folgenden Beispiele zeigen einige Möglichkeiten, wie Sie die MessageValidation-Richtlinie verwenden können:

1: XSD-Validierung

Sie können die MessageValidation-Richtlinie verwenden, um die Nutzlast einer XML-Nachrichtenanfrage mit einem XSD-Schema zu validieren.

1. Erstellen Sie eine neue XSD-Ressourcendatei. Zum Beispiel, note-schema.xsd:

   <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
     <xs:element name="note">
       <xs:complexType>
         <xs:sequence>
           <xs:element name="to" type="xs:string"/>
           <xs:element name="from" type="xs:string"/>
           <xs:element name="heading" type="xs:string"/>
           <xs:element name="body" type="xs:string"/>
         </xs:sequence>
       </xs:complexType>
     </xs:element>
   </xs:schema>

2. Fügen Sie die MessageValidation-Richtlinie von SOAP dem Pre-Flow Ihres Proxy-Endpunkts hinzu:
   1. Geben Sie den Speicherort Ihrer XSD-Ressourcendatei mit dem Element <ResourceURL> an. Beispiel:

      ...
        <ResourceURL>xsd://note-schema.xsd</ResourceURL>
      ...

   2. Entfernen Sie die Elemente <SOAPMessage>, <Element> anhand der Richtliniendefinition.

   Ihre Richtliniendefinition sollte so aussehen:

   <MessageValidation continueOnError="false"
       enabled="true" name="validateXMLRequest">
     <DisplayName>My XML Validator</DisplayName>
     <Properties/>
     <Source>request</Source>
     <ResourceURL>xsd://note-schema.xsd</ResourceURL>
   </MessageValidation>

3. Senden Sie eine POST-Anfrage mit Ihrer XML als Nachrichtennutzlast an Ihren API-Proxy, wie das folgende Beispiel zeigt:

   curl -v -X POST -H 'Content-Type: application/xml' http://my-test.apigee.net/v1/xsd-mock
     -d '<note>
     <to>Fred Rogers</to>
     <from>Nick Danger</from>
     <heading>Greetings from my neighborhood</heading>
     <body>Just writing to say hello.</body>
   </note>'

   Beachten Sie, dass für den Content-type-Header der Wert application/xml festgelegt ist.

   Sie können auch eine Datendatei für die Nutzlast erstellen und mit einem Befehl wie diesem referenzieren:

   curl -v -X POST -H 'Content-type: application/xml' http://my-test.apigee.net/v1/xsd-mock
     --data '@../examples/note-payload.xml'

Sie sollten eine HTTP 200-Antwort erhalten. Abhängig von Ihrem Zielendpunkt erhalten Sie möglicherweise zusätzliche Details zur Anfrage. Wenn Sie zum Beispiel http://httpbin.org/post als Zielendpunkt verwenden und eine -v-Ausgabe (ausführlich) angeben, sollte die Antwort in etwa so aussehen:

< HTTP/1.1 200 OK
< Date: Wed, 16 May 2018 21:24:54 GMT
< Content-Type: application/xml
< Content-Length: 431
< Connection: keep-alive
< Server: gunicorn/19.8.1
< Access-Control-Allow-Origin: *
< Access-Control-Allow-Credentials: true
< Via: 1.1 vegur
{
  "args":{},
  "data":"<note><to>fred</to><from>nick</from><heading>hello</heading>
    <body>Just writing to say hello.</body></note>",
  "files":{},
  "form":{},
  "headers": {
    "Accept":"*/*",
    "Connection":"close",
    "Content-Length":"106",
    "Content-Type":"application/xml",
    "Host":"httpbin.org",
    "User-Agent":"curl/7.58.0"
  },
  "json":null,
  "origin":"10.1.1.1, 104.154.179.1",
  "url":"http://httpbin.org/post"
}

Fügen Sie ein anderes Tag in den Text Ihrer Anfrage ein, um zu prüfen, ob die XSD-Validierung funktioniert. Beispiel:

curl -v -X POST -H 'Content-Type: application/xml' http://my-test.apigee.net/v1/xsd-mock
  -d '<note>
  <to>Fred Rogers</to>
  <from>Nick Danger</from>
  <heading>Greetings from my neighborhood</heading>
  <body>Just writing to say hello.</body>
  <badTag>Not good</badTag>
</note>'

Sie sollten einen Validierungsfehler erhalten.

2. SOAP-Validierung

Sie können die MessageValidation-Richtlinie zum Validieren der Nutzlast einer SOAP-Nachrichtenanfrage anhand einer WSDL verwenden.

1. Erstellen Sie eine neue WSDL-Ressourcendatei. Zum Beispiel "example-wsdl.wsdl":

   Vollständige WSDL-Datei ansehen

   <?xml version="1.0" encoding="UTF-8"?>
   <wsdl:definitions targetNamespace="https://example.com/gateway"
       xmlns:tns="https://example.com/gateway"
       xmlns:types="https://example.com/gateway/types"
       xmlns:xsd="http://www.w3.org/2001/XMLSchema"
       xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
       xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/">
     <wsdl:types>
       <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
           targetNamespace="https://example.com/gateway/types"
           elementFormDefault="qualified">
         <xsd:element name="MyType">
           <xsd:complexType>
             <xsd:sequence>
               <xsd:element name="ID" nillable="false" minOccurs="1" maxOccurs="1"/>
             </xsd:sequence>
           </xsd:complexType>
         </xsd:element>
       </xsd:schema>
       <schema attributeFormDefault="unqualified" elementFormDefault="qualified"
           targetNamespace="https://example.com/gateway"
           xmlns="http://www.w3.org/2001/XMLSchema">
         <xsd:import namespace="https://example.com/gateway/types"/>
         <element name="getID">
           <complexType>
             <sequence>
               <element ref="types:MyType"/>
             </sequence>
           </complexType>
         </element>
       </schema>
     </wsdl:types>
   
     <wsdl:message name="getRequest">
       <wsdl:part name="getRequest" element="tns:getID"/>
     </wsdl:message>
     <wsdl:message name="getResponse">
       <wsdl:part name="getResponse" element="tns:getID"/>
     </wsdl:message>
   
     <wsdl:portType name="PortType">
       <wsdl:operation name="get">
         <wsdl:input name="methodRequest" message="tns:getRequest"/>
         <wsdl:output name="methodResponse" message="tns:getResponse"/>
       </wsdl:operation>
     </wsdl:portType>
   
     <wsdl:service name="Gateway">
       <wsdl:port name="GatewaySoap" binding="tns:SoapBinding">
         <wsdlsoap:address location="https://example.com/gateway"/>
       </wsdl:port>
     </wsdl:service>
   
     <wsdl:binding name="SoapBinding" type="tns:PortType">
       <wsdlsoap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
   
       <wsdl:operation name="get">
         <wsdlsoap:operation soapAction="get"/>
         <wsdl:input name="methodRequest"/>
         <wsdl:output name="methodResponse"/>
       </wsdl:operation>
   
     </wsdl:binding>
   </wsdl:definitions>

2. Fügen Sie die MessageValidation-Richtlinie von SOAP dem Pre-Flow Ihres Proxy-Endpunkts hinzu:
   1. Setzen Sie das Attribut version des Elements <SOAPMessage> auf die Version des SOAP-Protokolls, das Sie zur Validierung verwenden möchten. Zum Beispiel 1.1:

      ...
        <SOAPMessage version="1.1"/>
      ...

   2. Setzen Sie den Wert des Elements <Element> auf das Element, das Sie validieren möchten:

      ...
        <Element namespace="https://example.com/gateway">getID</Element>
      ...

      <Element> gibt das erste untergeordnete Element unter <Body> im Envelope der SOAP-Anfrage an.

      Setzen Sie das Attribut namespace auf den Namespace für dieses untergeordnete Element.

   3. Geben Sie den Speicherort Ihrer WSDL-Ressourcendatei mit dem Element <ResourceURL> an. Beispiel:

      ...
        <ResourceURL>wsdl://example-wsdl.wsdl</ResourceURL>
      ...

   Ihre Richtliniendefinition sollte so aussehen:

   <MessageValidation continueOnError="false"
       enabled="true" name="validateSOAPRequest">
     <DisplayName>My SOAP Validator</DisplayName>
     <Properties/>
     <Source>request</Source>
     <SOAPMessage version="1.1"/>
     <Element namespace="https://example.com/gateway">getID</Element>
     <ResourceURL>wsdl://example-wsdl.wsdl</ResourceURL>
   </MessageValidation>

3. Senden Sie eine POST-Anfrage mit dem SOAP-Envelope als Nachrichtennutzlast an Ihren API-Proxy, wie das folgende Beispiel zeigt:

   curl -v -X POST -H 'Content-Type: application/xml' http://my-test.apigee.net/v1/xsd-mock
     -d '<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
       xmlns:prox="https://example.com/gateway" xmlns:typ="https://example.com/gateway/types">
     <soapenv:Header/>
     <soapenv:Body>
       <prox:getID>
         <typ:MyType>
           <typ:ID>42</typ:ID>
         </typ:MyType>
       </prox:getID>
     </soapenv:Body>
   </soapenv:Envelope>'

   Beachten Sie, dass der Header Content-type auf "application/xml" gesetzt ist.

   Sie können auch eine Datendatei für die Nutzlast erstellen und mit einem Befehl wie diesem referenzieren:

   curl -v -X POST -H 'Content-type: application/xml' http://my-test.apigee.net/v1/xsd-mock
     --data '@../examples/soap-payload.xml'

Sie sollten eine HTTP 200-Antwort erhalten. Abhängig von Ihrem Zielendpunkt erhalten Sie möglicherweise zusätzliche Details zur Anfrage. Wenn Sie beispielsweise http://httpbin.org/post als Zielendpunkt verwenden, sollte die Antwort in etwa so aussehen:

< HTTP/1.1 200 OK
< Date: Wed, 16 May 2018 21:24:54 GMT
< Content-Type: application/xml
< Content-Length: 431
< Connection: keep-alive
< Server: gunicorn/19.8.1
< Access-Control-Allow-Origin: *
< Access-Control-Allow-Credentials: true
< Via: 1.1 vegur
{
  "args":{},
  "data":"<note><to>fred</to><from>nick</from><heading>hello</heading>
    <body>Just writing to say hello.</body></note>",
  "files":{},
  "form":{},
  "headers": {
    "Accept":"*/*",
    "Connection":"close",
    "Content-Length":"106",
    "Content-Type":"application/xml",
    "Host":"httpbin.org",
    "User-Agent":"curl/7.58.0"
  },
  "json":null,
  "origin":"10.1.1.1, 104.154.179.1",
  "url":"http://httpbin.org/post"
}

3: Wohlgeformtes XML/JSON

Mit der MessageValidation-Richtlinie können Sie überprüfen, ob die Nutzlast einer JSON- oder XML-Nachricht wohlgeformt ist (nicht dasselbe wie Validierung). Die Richtlinie stellt sicher, dass die Struktur und der Inhalt anerkannten Standards entsprechen, einschließlich:

• Es gibt ein einziges Stammelement.
• Der Inhalt enthält keine unzulässigen Zeichen.
• Objekte und Tags sind ordnungsgemäß verschachtelt.
• Start- und End-Tags stimmen überein.

So prüfen Sie eine wohlgeformte XML- oder JSON-Nutzlast:

1. Fügen Sie die MessageValidation-Richtlinie von SOAP dem Pre-Flow Ihres Proxy-Endpunkts hinzu.
2. Entfernen Sie die Elemente <ResourceURL>, <SOAPMessage> und <Element> anhand der Richtliniendefinition.

   Ihre Richtliniendefinition sollte so aussehen:

   <MessageValidation async="false" continueOnError="false"
       enabled="true" name="validateXMLRequest">
     <DisplayName>My JSON Checker</DisplayName>
     <Properties/>
     <Source>request</Source>
   </MessageValidation>

3. Senden Sie eine POST-Anfrage an Ihren API-Proxy, wie das folgende Beispiel zeigt:

   curl -v -X POST -H 'Content-Type: application/json' http://my-test.apigee.net/v1/xsd-mock
     -d '{
   "note": {
     "to": "Fred Rogers",
     "from": "Nick Danger",
     "header": "Greetings from my neighborhood",
     "body": "Just writing to say hello."
     }
   }'

   Beachten Sie, dass für den Content-type-Header der Wert application/json festgelegt ist.

   Um eine XML-Datei auf Wohlgeformtheit zu prüfen, verwenden Sie XML als Nachrichtennutzlast und setzen Sie Content-type auf application/xml.

Sie sollten eine HTTP 200-Antwort erhalten. Wenn Sie eine Nachrichtennutzlast senden, die kein korrekt formatiertes XML- oder JSON-Format enthält, sollten Sie den Fehler steps.messagevalidation.Failed erhalten.

Verweis auf untergeordnetes Element

In diesem Abschnitt werden die untergeordneten Elemente von <MessageValidation> beschrieben.

<DisplayName>

Wird zusätzlich zum Attribut name verwendet, um die Richtlinie im Proxy-Editor der Verwaltungs-UI mit einem anderen, natürlicher klingenden Namen zu versehen.

Das Element <DisplayName> ist für alle Richtlinien gleich.

Standardwert	–
Erforderlich?	Optional. Wenn Sie <DisplayName> weglassen, wird der Wert des Attributs name der Richtlinie verwendet.
Typ	String
Übergeordnetes Element	<PolicyElement>
Untergeordnete Elemente	Keine

Das <DisplayName>-Element verwendet die folgende Syntax:

Syntax

<PolicyElement>
  <DisplayName>POLICY_DISPLAY_NAME</DisplayName>
  ...
</PolicyElement>

Beispiel

<PolicyElement>
  <DisplayName>My Validation Policy</DisplayName>
</PolicyElement>

Das <DisplayName>-Element hat keine Attribute oder untergeordneten Elemente.

<Element>

Gibt das zu validierende Element in der Nachricht an. Dies ist das erste untergeordnete Element unter <Body> im Envelope der SOAP-Anfrage.

Standardwert	sampleObject
Erforderlich?	Optional
Typ	String
Übergeordnetes Element	<MessageValidation>
Untergeordnete Elemente	Keine

Das Element <Element> verwendet die folgende Syntax:

Syntax

...
  <Element namespace="element_namespace">element_to_validate</Element>
...

Beispiel 1

Im folgenden Beispiel wird ein einzelnes zu validierendes Element definiert:

...
<Element namespace="https://example.com/gateway">getID</Element>
...

Beispiel 2

Sie können mehrere Elemente für die Überprüfung angeben, indem Sie mehrere <Element>-Elemente hinzufügen:

...
<Element namespace="https://example.com/gateway">getID</Element>
<Element namespace="https://example.com/gateway">getDetails</Element>
...

Das <Element>-Element hat die folgenden Attribute:

Attribut	Standard	Erforderlich?	Beschreibung
namespace	"http://sample.com"	Optional	Definiert den Namespace des zu validierenden Elements.

<ResourceURL>

Gibt das XSD-Schema oder die WSDL-Definition an, die zur Validierung der Quellnachricht verwendet werden soll.

Standardwert	wsdl://display_name.wsdl
Erforderlich?	Optional
Typ	String
Übergeordnetes Element	<MessageValidation>
Untergeordnete Elemente	Keine

Das Element <ResourceURL> verwendet die folgende Syntax:

Syntax

...
  <ResourceURL>[wsdl|xsd]://validation_WSDL_or_XSD</ResourceURL>
...

Beispiele

Für eine XML-Datei:

...
<ResourceURL>xsd://note-schema.xsd</ResourceURL>
...

Für eine WSDL-Datei:

...
<ResourceURL>wsdl://example-wsdl.wsdl</ResourceURL>
...

Der Wert von <ResourceURL> muss auf eine Ressourcendatei in Ihrem API-Proxy verweisen. Er kann nicht über HTTP oder HTTPS auf externe Ressourcen verweisen.

Wenn Sie keinen Wert für <ResourceURL> angeben, wird die Nachricht auf wohlgeformte JSON oder XML überprüft, wenn der Content-type-Header application/json oder application/xml.

Das <ResourceURL>-Element hat keine untergeordneten Elemente oder Attribute.

XSDs zur Validierung verwenden

Wenn die XML-Nutzlast, die Sie mit der MessageValidation-Richtlinie validieren, auf ein anderes Schema verweist, müssen Sie der enthaltenen XSD-Datei im Attribut schemaLocation das Präfix xsd voranstellen.

Das folgende Beispielschema besteht aus mehreren XSD-Dateien:

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
    elementFormDefault="qualified" attributeFormDefault="unqualified">
  <xs:include schemaLocation="xsd://note-schema.xsd"/>
  <xs:include schemaLocation="xsd://letter-schema.xsd"/>
  <xs:include schemaLocation="xsd://user-schema.xsd"/>
</xs:schema>

Hinweis: Sie können XSDs nur einschließen oder importieren, wenn es sich um Ressourcendateien in Ihrem API-Proxy handelt. Externe XSD-Dateien können nicht aufgenommen werden.

WSDLs zur Validierung verwenden

Eine WSDL-Datei muss mindestens ein Schema definieren. Wenn sie nicht auf mindestens ein Schema verweist, schlägt die MessageValidation-Richtlinie fehl.

Die maximale Importtiefe für ein Schema beträgt 10. Wenn Sie diese Anzahl von verschachtelten Importen überschreiten, schlägt die MessageValidation-Richtlinie fehl.

<SOAPMessage>

Definiert die SOAP-Version, die zur Validierung der MessageValidation-Richtlinie verwendet wird.

Standardwert	–
Erforderlich?	Optional
Typ	–
Übergeordnetes Element	<MessageValidation>
Untergeordnete Elemente	Keine

Das Element <SOAPMessage> verwendet die folgende Syntax:

Syntax

...
  <SOAPMessage version="[ 1.1 | 1.2 | 1.1/1.2 ]"/>
...

Beispiel

...
<SOAPMessage version="1.1"/>
...

Das <SOAPMessage>-Element hat die folgenden Attribute:

Attribut	Standard	Erforderlich?	Beschreibung
version	Keine	Optional	Die SOAP-Version, die von dieser Richtlinie zum Validieren der SOAP-Nachrichten verwendet wird. Gültige Werte sind: "1.1" "1.2" "1.1/1.2"

Weitere Informationen finden Sie unter Von SOAP/1.1 zu SOAP-Version 1.2 in 9 Punkten.

<Source>

Gibt die zu validierende Quellnachricht an. Der Wert dieses Elements ist der Name der Nachricht, die Sie überprüfen möchten.

Wenn Sie <Source> nicht festlegen, wird diese Richtlinie standardmäßig auf message gesetzt. Dies bezieht sich auf die gesamte Anfragenachricht (in einem Anfrageablauf) oder auf die Antwortnachricht (in einem Antwortablauf), einschließlich der Nutzlast. Sie können sie auch explizit auf request oder response setzen, um auf die Anfrage oder Antwort zu verweisen.

Standardwert	Anfrage
Erforderlich?	Optional
Typ	String
Übergeordnetes Element	<MessageValidation>
Untergeordnete Elemente	Keine

Das Element <Source> verwendet die folgende Syntax:

Syntax

...
  <Source>message_to_validate</Source>
...

Beispiel

...
<Source>request</Source>
...

Zusätzlich zu message, request und response können Sie den Wert von <Source> auf den Namen einer beliebigen Nachricht in Ihrem Ablauf festlegen. In diesem Fall müssen Sie jedoch vor dem Ausführen dieser Richtlinie eine benutzerdefinierte Nachricht mit diesem Namen erstellen. Andernfalls erhalten Sie eine Fehlermeldung.

Wenn der Wert von <Source> nicht im Nachrichtenfluss aufgelöst werden kann oder in einen Nicht-Nachrichtentyp aufgelöst wird, tritt einer der folgenden Fälle ein:

• Bei einem Nullwert: Apigee gibt einen steps.messagevalidation.SourceMessageNotAvailable-Fehler aus.
• Bei einem Nicht-Nachrichtentyp: Apigee gibt einen steps.messagevalidation.NonMessageVariable-Fehler aus.

Das <Source>-Element hat keine Attribute oder untergeordneten Elemente.

Fehlercodes

This section describes the fault codes and error messages that are returned and fault variables that are set by Apigee when this policy triggers an error. This information is important to know if you are developing fault rules to handle faults. To learn more, see What you need to know about policy errors and Handling faults.

Runtime errors

These errors can occur when the policy executes.

Need help resolving an error? Click in the Fix column for detailed troubleshooting information.

Use API Monitoring to investigate fault codes and diagnose issues faster. See Set up a policy fault code alert for an example. See Fault code reference for a complete list of all fault codes that you can handle with API Monitoring.

Fault code	HTTP status	Cause	Fix
steps.messagevalidation.SourceMessageNotAvailable	500	This error occurs if a variable specified in the <Source> element of the policy is either: out of scope (not available in the specific flow where the policy is being executed) or can't be resolved (is not defined)
steps.messagevalidation.NonMessageVariable	500	This error occurs if the <Source> element in the SOAPMessageValidation policy is set to a variable which is not of type message. Message type variables represent entire HTTP requests and responses. The built-in Apigee flow variables request, response, and message are of type message. To learn more about message variables, see the Variables reference.
steps.messagevalidation.Failed	500	This error occurs if the SOAPMessageValidation policy fails to validate the input message payload against the XSD schema or WSDL definition. It will also occur if there is malformed JSON or XML in the payload message.

Deployment errors

These errors can occur when you deploy a proxy containing this policy.

Need help resolving an error? Click next to the error's cause description to visit the troubleshooting page.

Error name	Cause	Fix
InvalidResourceType	The <ResourceURL> element in the SOAPMessageValidation policy is set to a resource type not supported by the policy.
ResourceCompileFailed	The resource script referenced in the <ResourceURL> element of the SOAPMessageValidation policy contains an error that prevents it from compiling.
RootElementNameUnspecified	The <Element> element in the SOAPMessageValidation policy does not contain the root element's name.
InvalidRootElementName	The <Element> element in the SOAPMessageValidation policy contains a root element name that does not adhere to XML rules for valid element naming.

Schemas

Jeder Richtlinientyp wird durch ein XML-Schema (.xsd) definiert. Zu Referenzzwecken sind Richtlinienschemas auf GitHub verfügbar.

Weitere Informationen

• XMLThreatProtection-Richtlinie
• "XML-to-JSON"-Richtlinie
• "JSON-to-XML"-Richtlinie
• JSON-Richtlinie zum Schutz vor Bedrohungen