Diese Seite wurde von der Cloud Translation API übersetzt.

SOAPMessageValidation-Richtlinie

Sie sehen die Dokumentation zu Apigee Edge.
Rufen Sie die Apigee X-Dokumentation auf. weitere Informationen

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

Diese Richtlinie lautet in der UI "SOAPMessageValidation" und validiert mehr als nur SOAP-Nachrichten. In diesem Abschnitt wird die Richtlinie als "MessageValidation-Richtlinie" bezeichnet.

Informationen zur MessageValidation-Richtlinie

Vorteile

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.

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 Standardrichtlinie Tab 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 Ihrem Ablauf in der Edge-Benutzeroberfläche eine Richtlinie zur Nachrichtenüberprüfung 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`	falsch	Optional	Ist das Element auf "false" gesetzt, wird ein Fehler zurückgegeben, wenn eine Richtlinie fehlschlägt. Dies ist für die meisten Richtlinien das erwartete Verhalten. Ist das Element auf "true" gesetzt, wird die Ausführung des Ablaufs auch nach dem Fehlschlagen einer Richtlinie fortgesetzt.
`enabled`	wahr	Optional	Auf "true" setzen, um die Richtlinie durchzusetzen. Auf "false" setzen, um die Richtlinie zu "deaktivieren". Die Richtlinie wird nicht durchgesetzt, selbst wenn sie mit einem Ablauf verknüpft ist.
`async`	falsch	Eingestellte Funktionen	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.

Erstellen Sie eine neue XSD-Ressourcendatei. 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>

Fügen Sie dem Pre-Flow Ihres Proxy-Endpunkts die SOAP-Nachrichtenvalidierungsrichtlinie 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>
```

Senden Sie eine POST-Anfrage mit Ihrem XML als Nachrichtennutzlast an Ihren API-Proxy, wie im folgenden Beispiel gezeigt:

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 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/note-payload.xml'

Sie sollten eine HTTP 200-Antwort erhalten. Je nach Zielendpunkt erhalten Sie möglicherweise weitere 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.

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>

Fügen Sie dem Pre-Flow Ihres Proxy-Endpunkts die SOAP-Nachrichtenvalidierungsrichtlinie 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. Legen Sie den Wert des Elements <Element> auf das Element fest, 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>
```

Senden Sie eine POST-Anfrage mit dem SOAP-Umschlag als Nachrichtennutzlast an Ihren API-Proxy, wie im folgenden Beispiel gezeigt:

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. Je nach Zielendpunkt erhalten Sie möglicherweise weitere 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:

Fügen Sie die MessageValidation-Richtlinie von SOAP dem Pre-Flow Ihres Proxy-Endpunkts hinzu.

Entfernen Sie die Elemente <ResourceURL>, <SOAPMessage> und <Element> aus 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>

Senden Sie eine POST-Anfrage an Ihren API-Proxy, wie im folgenden Beispiel gezeigt:
```
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 der Header Content-type auf "application/json" gesetzt ist.

Verwenden Sie XML als Nachrichtennutzlast und setzen Sie Content-type auf „application/xml“, um eine XML-Datei auf Wohlgeformtheit zu prüfen.

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?	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 <ResourceURL>-Element 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 für <ResourceURL> keinen Wert angeben, wird die Nachricht auf wohlgeformte JSON- oder XML-Dateien geprüft, wenn der Content-type-Header „application/json“ bzw. „application/xml“ ist.

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>

WSDLs zur Validierung verwenden

Eine WSDL-Datei muss mindestens ein Schema definieren. Wenn es nicht auf mindestens ein Schema verweist, schlägt die Richtlinie zur Nachrichtenüberprüfung fehl.

Die maximale Importtiefe für ein Schema beträgt 10. Wenn Sie diese Anzahl von verschachtelten Importen überschreiten, schlägt die Richtlinie zur Nachrichtenüberprüfung 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 <SOAPMessage>-Element 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

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

version

Keine

Optional

Die SOAP-Version, die diese Richtlinie zum Validieren von SOAP-Nachrichten verwendet.

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 "Nachricht" 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 die Richtlinie auch explizit auf "Anfrage" oder "Antwort" setzen, um auf die Anfrage oder Antwort zu verweisen.

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

Das <Source>-Element verwendet die folgende Syntax:

Syntax

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

Beispiel

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

Neben „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:

Wenn ein Nullwert: Edge gibt einen steps.messagevalidation.SourceMessageNotAvailable-Fehler aus.
Wenn kein Nachrichtentyp: Edge gibt einen steps.messagevalidation.NonMessageVariable-Fehler aus.

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

Fehlercodes

Von Edge-Richtlinien zurückgegebene Fehler haben ein konsistentes Format, wie in der Fehlercode-Referenz beschrieben.

In diesem Abschnitt werden die Fehlercodes und Fehlermeldungen beschrieben, die zurückgegeben werden, sowie die Fehlervariablen, die von Edge festgelegt werden, wenn diese 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 Problembehebung

Fehlercode	HTTP-Status	Ursache
`steps.messagevalidation.SourceMessageNotAvailable`	500	Dieser Fehler tritt bei einer Variablen auf, die im Element `<Source>` der Richtlinie angegeben ist: Der Wert liegt außerhalb des Bereichs (ist nicht in dem spezifischen Ablauf verfügbar, in dem die Richtlinie ausgeführt wird) oder Der Wert nicht aufgelöst werden kann (nicht definiert ist)
`steps.messagevalidation.NonMessageVariable`	500	Dieser Fehler tritt auf, wenn für das Element `<Source>` in der SOAPMessageValidation-Richtlinie eine Variable festgelegt ist, die nicht vom Typ message ist. Nachrichtentypvariablen stellen ganze HTTP-Anfragen und -Antworten dar. Die integrierten Edge-Flussvariablen `request`, `response` und `message` sind vom Typ „Nachricht“. Weitere Informationen zu Nachrichtenvariablen finden Sie in der Variablenreferenz.
`steps.messagevalidation.Failed`	500	Dieser Fehler tritt auf, wenn die SOAPMessageValidation-Richtlinie die Eingabe-Nachrichten-Nutzlast nicht gegen das XSD-Schema oder die WSDL-Definition validiert. Sie wird auch angezeigt, wenn die Nutzlastnachricht fehlerhaft formatierte JSON- oder XML-Daten enthält.

steps.messagevalidation.SourceMessageNotAvailable

500

Dieser Fehler tritt bei einer Variablen auf, die im Element <Source> der Richtlinie angegeben ist:

Der Wert liegt außerhalb des Bereichs (ist nicht in dem spezifischen Ablauf verfügbar, in dem die Richtlinie ausgeführt wird)
Der Wert nicht aufgelöst werden kann (nicht definiert ist)

steps.messagevalidation.NonMessageVariable

500

Dieser Fehler tritt auf, wenn für das Element <Source> in der SOAPMessageValidation-Richtlinie eine Variable festgelegt ist, die nicht vom Typ message ist.

Nachrichtentypvariablen stellen ganze HTTP-Anfragen und -Antworten dar. Die integrierten Edge-Flussvariablen request, response und message sind vom Typ „Nachricht“. Weitere Informationen zu Nachrichtenvariablen finden Sie in der Variablenreferenz.

steps.messagevalidation.Failed 500 Dieser Fehler tritt auf, wenn die SOAPMessageValidation-Richtlinie die Eingabe-Nachrichten-Nutzlast nicht gegen das XSD-Schema oder die WSDL-Definition validiert. Sie wird auch angezeigt, wenn die Nutzlastnachricht fehlerhaft formatierte JSON- oder XML-Daten enthält.

Bereitstellungsfehler

Diese Fehler können auftreten, wenn Sie einen Proxy bereitstellen, der diese Richtlinie enthält.

Fehlername	Ursache	Korrigieren
`InvalidResourceType`	Das Element `<ResourceURL>` in der SOAPMessageValidation-Richtlinie ist auf einen Ressourcentyp festgelegt, der von der Richtlinie nicht unterstützt wird.
`ResourceCompileFailed`	Das Ressourcenskript, auf das im `<ResourceURL>`-Element der SOAPMessageValidation-Richtlinie verwiesen wird, enthält einen Fehler, der die Kompilierung verhindert.
`RootElementNameUnspecified`	Das Element `<Element>` in der SOAPMessageValidation-Richtlinie enthält nicht den Namen des Stammelements.
`InvalidRootElementName`	Das Element `<Element>` in der SOAPMessageValidation-Richtlinie enthält einen Stammelementnamen, der nicht den XML-Regeln für gültige Elementnamen entspricht.

Schema

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

SOAPMessageValidation-Richtlinie

Informationen zur MessageValidation-Richtlinie

Vorteile

Videos

Element <MessageValidation>

Syntax

Standardrichtlinie

Beispiele

1: XSD-Validierung

2. SOAP-Validierung

3: Wohlgeformtes XML/JSON

Verweis auf untergeordnetes Element

<DisplayName>

Syntax

Beispiel

<Element>

Syntax

Beispiel 1

Beispiel 2

<ResourceURL>

Syntax

Beispiele

XSDs zur Validierung verwenden

WSDLs zur Validierung verwenden

<SOAPMessage>

Syntax

Beispiel

<Source>

Syntax

Beispiel

Fehlercodes

Laufzeitfehler

Bereitstellungsfehler

Schema

Weitere Informationen

Element `<MessageValidation>`

`<DisplayName>`

`<Element>`

`<ResourceURL>`

`<SOAPMessage>`

`<Source>`