Cette page a été traduite par l'API Cloud Translation.

Règle SOAPMessageValidation

Vous consultez la documentation Apigee Edge.
Accéder à la documentation d'Apigee X en savoir plus

La règle SOAPMessageValidation effectue les opérations suivantes :

Valide tout message XML par rapport à son schéma XSD.
Valide les messages SOAP par rapport à une définition WSDL.
Détermine le bon format des messages JSON et XML.

Bien que le nom de cette règle dans l'interface utilisateur soit "Validation de message SOAP", la règle valide plus que de simples messages SOAP. Cette section fait référence à la règle appelée "règle de validation de message".

À propos de la règle de validation de message

Avantages

La validation des messages offre les avantages suivants :

Informe immédiatement les développeurs d'applications qui utilisent votre API si leurs requêtes sont non conformes ou incomplètes.
Identifie les problèmes dans les requêtes, tels que les balises XML qui ne sont pas correctement fermées.
Protège les services de backend en bloquant les messages XML ou SOAP comportant des structures susceptibles de provoquer un comportement imprévisible.
Réduit le temps passé à dépanner, rechercher sur des forums ou consulter le support technique.
Encourage les développeurs à se familiariser avec la définition WSDL du schéma XML afin d'éliminer les erreurs de validation, faisant des schémas XML bien compris un composant clé de la documentation de votre API.

Vidéos

Regardez les vidéos suivantes pour en savoir plus sur la règle de validation de message :

Vidéo	Description
Valider la requête XML	Validez la requête XML pour une API à l'aide de la règle de validation de message.
Valider la requête JSON	Validez la requête JSON pour une API à l'aide de la règle de validation de message.

Élément `<MessageValidation>`

Définit la règle de validation de message.

Valeur par défaut	Consultez l'onglet Règles par défaut ci-dessous.
Obligatoire ?	Facultatif
Type	Objet complexe
Élément parent	N/A
Éléments enfants	`<DisplayName>` `<Element>` `<ResourceURL>` `<SOAPMessage>` `<Source>`

Syntaxe

L'élément <MessageValidation> utilise la syntaxe suivante :

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

Règle par défaut

L'exemple suivant montre les paramètres par défaut lorsque vous ajoutez une stratégie de validation de message à votre flux dans l'interface utilisateur Edge:

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

Cet élément possède les attributs suivants qui sont communs à toutes les règles :

Attribut	Par défaut	Obligatoire ?	Description
`name`	N/A	Obligatoire	Nom interne de la règle. La valeur de l'attribut `name` peut contenir des lettres, des chiffres, des espaces, des tirets, des traits de soulignement et des points. Cette valeur ne peut pas dépasser 255 caractères. Vous pouvez également utiliser l'élément `<DisplayName>` pour ajouter un libellé à la règle dans l'éditeur de proxy de l'interface utilisateur de gestion avec un nom différent, en langage naturel.
`continueOnError`	faux	Facultatif	Défini sur "false" pour renvoyer une erreur en cas d'échec d'une règle. Il s'agit du comportement attendu pour la plupart des règles. Défini sur "true" pour que l'exécution du flux se poursuive même après l'échec d'une règle.
`enabled`	vrai	Facultatif	Défini sur "true" pour appliquer la règle. Défini sur "false" pour "désactiver" la règle. La règle ne sera pas appliquée même si elle reste associée à un flux.
`async`	faux	Obsolète	Cet attribut est obsolète.

Exemples

Les exemples suivants illustrent certaines des manières d'utiliser la règle de validation de message :

1 : Validation XSD

Vous pouvez utiliser la règle de validation de message pour valider la charge utile d'une requête de message XML par rapport à un schéma XSD.

Créez un fichier de ressources XSD. Par exemple, "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>

Ajoutez la stratégie de validation de message SOAP au flux préalable de votre point de terminaison de proxy :
1. Spécifiez l'emplacement de votre fichier de ressources XSD à l'aide de l'élément <ResourceURL>. Exemple :
```
...
  <ResourceURL>xsd://note-schema.xsd</ResourceURL>
...
```
2. Supprimez les éléments <SOAPMessage> et <Element> de la définition de règle.
Votre définition de règle devrait ressembler à ceci :
```
<MessageValidation continueOnError="false"
    enabled="true" name="validateXMLRequest">
  <DisplayName>My XML Validator</DisplayName>
  <Properties/>
  <Source>request</Source>
  <ResourceURL>xsd://note-schema.xsd</ResourceURL>
</MessageValidation>
```

Envoyez une requête POST à votre proxy d'API avec votre XML comme charge utile du message, comme le montre l'exemple suivant :

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>'

Notez que l'en-tête Content-type est défini sur "application/xml".

Vous pouvez également créer un fichier de données pour la charge utile et le référencer avec une commande semblable à celle-ci :

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

Vous devriez recevoir une réponse HTTP 200. Selon votre point de terminaison cible, vous pouvez recevoir des informations supplémentaires sur la requête. Par exemple, si vous utilisez http://httpbin.org/post comme point de terminaison cible et que vous spécifiez la sortie -v (verbose), la réponse doit ressembler à ce qui suit :

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

Pour vérifier que votre validation XSD fonctionne, essayez d'insérer un autre tag dans le corps de votre requête. Exemple :

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>'

Vous devriez recevoir une erreur de validation.

2 : Validation SOAP

Vous pouvez utiliser la règle de validation de message pour valider la charge utile d'une requête de message SOAP par rapport à un WSDL.

Créez un fichier de ressources WSDL. Par exemple, "example-wsdl.wsdl" :

Afficher le WSDL complet

<?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>

Ajoutez la stratégie de validation de message SOAP au flux préalable de votre point de terminaison de proxy :
1. Définissez l'attribut version de l'élément <SOAPMessage> sur la version du protocole SOAP par rapport auquel vous souhaitez effectuer la validation. Par exemple, "1.1" :
```
...
  <SOAPMessage version="1.1"/>
...
```
2. Définissez la valeur de l'élément <Element> sur l'élément que vous souhaitez valider :
```
...
  <Element namespace="https://example.com/gateway">getID</Element>
...
```
  <Element> spécifie le premier enfant sous l'élément <Body> de l'enveloppe de la requête SOAP.
  
  Définissez l'attribut namespace sur l'espace de noms de cet enfant.
3. Spécifiez l'emplacement de votre fichier de ressources WSDL avec l'élément <ResourceURL>. Exemple :
```
...
  <ResourceURL>wsdl://example-wsdl.wsdl</ResourceURL>
...
```
Votre définition de règle devrait ressembler à ceci :
```
<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>
```

Envoyez une requête POST à votre proxy d'API avec l'enveloppe SAML comme charge utile du message, comme le montre l'exemple suivant :

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>'

Notez que l'en-tête Content-type est défini sur "application/xml".

Vous pouvez également créer un fichier de données pour la charge utile et le référencer avec une commande semblable à celle-ci :

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

< 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 : XML/JSON bien formé

Vous pouvez utiliser la règle de validation de message pour confirmer qu'une charge utile de message JSON ou XML est correctement formée (diffère de la validation). La règle garantit que la structure et le contenu sont conformes aux normes acceptées, y compris :

Il existe un seul élément racine.
Il n'y a pas de caractères non autorisés dans le contenu.
Les objets et les tags sont correctement imbriqués.
Les tags de début et de fin correspondent.

Pour rechercher une charge utile XML ou JSON bien formée, procédez comme suit :

Ajoutez la règle de validation de message SOAP au flux préliminaire de votre point de terminaison de proxy.

Supprimez les éléments <ResourceURL>, <SOAPMessage> et <Element> de la définition de la stratégie.

Votre définition de règle devrait ressembler à ceci :

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

Envoyez une requête POST à votre proxy d'API, comme le montre l'exemple suivant :
```
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."
  }
}'
```
Notez que l'en-tête Content-type est défini sur "application/json".

Pour vérifier qu'un fichier XML est bien formé, utilisez XML comme charge utile du message et définissez Content-type sur "application/xml".

Vous devriez recevoir une réponse HTTP 200. Lorsque vous envoyez une charge utile de message qui ne contient pas de fichier XML ou JSON correctement formaté, vous devez recevoir une erreur steps.messagevalidation.Failed.

Référence d'élément enfant

Cette section décrit les éléments enfants de <MessageValidation>.

`<DisplayName>`

Utilisez-le, en plus de l'attribut name, pour appliquer un libellé à la règle dans l'éditeur de proxys de l'interface de gestion en utilisant un nom différent et plus naturel.

L'élément <DisplayName> est commun à toutes les règles.

Valeur par défaut	N/A
Requis ?	Facultatif. Si vous omettez `<DisplayName>`, la valeur de l'attribut `name` de la règle est utilisée.
Type	Chaîne
Élément parent	<`PolicyElement`>
Éléments enfants	Aucun

L'élément <DisplayName> utilise la syntaxe suivante :

Syntaxe

<PolicyElement>
  <DisplayName>policy_display_name</DisplayName>
  ...
</PolicyElement>

Exemple

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

L'élément <DisplayName> ne comporte aucun attribut ni élément enfant.

`<Element>`

Spécifie l'élément dans le message à valider. Il s'agit du premier enfant sous l'élément <Body> dans l'enveloppe de la requête SOAP.

Valeur par défaut	sampleObject
Obligatoire ?	Facultatif
Type	Chaîne
Élément parent	`<MessageValidation>`
Éléments enfants	Aucun

L'élément <Element> utilise la syntaxe suivante :

Syntaxe

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

Exemple 1

L'exemple suivant définit un seul élément à valider :

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

Exemple 2

Vous pouvez spécifier plusieurs éléments à valider en ajoutant plusieurs éléments <Element> :

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

L'élément <Element> possède les attributs suivants :

Attribut	Par défaut	Obligatoire ?	Description
`namespace`	"http://sample.com"	Facultatif	Définit l'espace de noms de l'élément à valider.

`<ResourceURL>`

Identifie le schéma XSD ou la définition WSDL à utiliser pour valider le message source.

Valeur par défaut	wsdl://`display_name`.wsdl
Obligatoire ?	Facultatif
Type	Chaîne
Élément parent	`<MessageValidation>`
Éléments enfants	Aucun

L'élément <ResourceURL> utilise la syntaxe suivante :

Syntaxe

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

Exemples

Pour un fichier XML :

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

Pour un fichier WSDL :

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

La valeur de <ResourceURL> doit pointer vers un fichier de ressources dans votre proxy d'API. Cet élément ne peut pas faire référence à des ressources externes via HTTP ou HTTPS.

Si vous ne spécifiez pas de valeur pour <ResourceURL>, le système vérifie que JSON ou XML est bien formé dans le message si l'en-tête Content-type est "application/json" ou "application/xml".

L'élément <ResourceURL> n'a pas d'éléments enfants ni d'attributs.

Utiliser des fichiers XSD pour la validation

Si la charge utile XML que vous validez avec la règle de validation de message fait référence à un autre schéma, vous devez préfixer le fichier XSD inclus avec xsd dans l'attribut schemaLocation.

L'exemple de schéma suivant est composé de plusieurs fichiers XSD :

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

Utiliser des fichiers WSDL pour la validation

Un fichier WSDL doit définir au moins un schéma. S'il ne fait pas référence à au moins un schéma, la règle de validation de message échoue.

La profondeur maximale d'importation pour un schéma est de 10. Si vous dépassez ce nombre d'importations imbriquées, la règle de validation de message échoue.

`<SOAPMessage>`

Définit la version SOAP par rapport à laquelle la règle de validation de message procède à la validation.

Valeur par défaut	N/A
Obligatoire ?	Facultatif
Type	N/A
Élément parent	`<MessageValidation>`
Éléments enfants	Aucun

L'élément <SOAPMessage> utilise la syntaxe suivante :

Syntaxe

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

Exemple

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

L'élément <SOAPMessage> possède les attributs suivants :

Attribut Par défaut Obligatoire ? Description

Attribut	Par défaut	Obligatoire ?	Description
`version`	Aucun	Facultatif	Version SOAP utilisée par cette stratégie pour valider les messages SOAP. Les valeurs possibles sont les suivantes : "1.1" "1.2" "1.1/1.2"

version

Aucun

Facultatif

Version SOAP utilisée par cette stratégie pour valider les messages SOAP.

Les valeurs possibles sont les suivantes :

"1.1"
"1.2"
"1.1/1.2"

Pour plus d'informations, voir De la version SOAP 1.1 à la version SOAP 1.2 en 9 points.

`<Source>`

Identifie le message source à valider. La valeur de cet élément correspond au nom du message que vous souhaitez valider.

Si vous ne définissez pas <Source>, cette règle est définie par défaut sur "message", qui fait référence au message de requête complet (dans un flux de requête) ou au message de réponse (dans un flux de réponse), y compris les charges utiles. Vous pouvez également définir explicitement cette valeur sur "request" ou "response" pour faire référence à la requête ou à la réponse.

Valeur par défaut	requête
Obligatoire ?	Facultatif
Type	Chaîne
Élément parent	`<MessageValidation>`
Éléments enfants	Aucun

L'élément <Source> utilise la syntaxe suivante :

Syntaxe

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

Exemple

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

En plus de "message", "request" et "response", vous pouvez définir la valeur de <Source> sur le nom d'un message de votre flux. Dans ce cas, vous devez toutefois créer un message personnalisé portant ce nom dans votre flux avant que cette règle ne s'exécute. Sinon, vous obtiendrez une erreur.

Si la valeur de <Source> ne peut pas être résolue dans le flux de messages ou est résolue dans un type non-message, l'un des événements suivants se produit :

Si la valeur est nulle:Edge génère une erreur steps.messagevalidation.SourceMessageNotAvailable.
Pour les autres types de messages:Edge génère une erreur steps.messagevalidation.NonMessageVariable.

L'élément <Source> ne comporte aucun attribut ni élément enfant.

Codes d'erreur

Les erreurs renvoyées par les stratégies Edge suivent un format cohérent, comme décrit dans la documentation de référence sur les codes d'erreur.

Cette section décrit les codes d'erreur et les messages d'erreur renvoyés, ainsi que les variables d'erreur définies par Edge lorsque cette stratégie déclenche une erreur. Ces informations sont importantes si vous développez des règles de défaillance afin de gérer les pannes. Pour en savoir plus, consultez les pages Ce que vous devez savoir à propos des erreurs liées aux règles et Gérer les pannes.

Erreurs d'exécution

Ces erreurs peuvent se produire lors de l'exécution de la règle.

Code d'erreur État HTTP Cause Solution

Code d'erreur	État HTTP	Cause
`steps.messagevalidation.SourceMessageNotAvailable`	500	Cette erreur se produit si une variable spécifiée dans l'élément `<Source>` de la règle est : hors de portée (non disponible dans le flux spécifique où la règle est exécutée) ; ou impossible à résoudre (non définie),
`steps.messagevalidation.NonMessageVariable`	500	Cette erreur se produit si l'élément `<Source>` de la règle SOAPMessageValidation est défini sur une variable qui n'est pas du type message. Les variables de type Message représentent des requêtes et des réponses HTTP entières. Les variables de flux Edge intégrées `request`, `response` et `message` sont de type message. Pour en savoir plus sur les variables de message, consultez la documentation de référence sur les variables.
`steps.messagevalidation.Failed`	500	Cette erreur se produit si la règle SOAPMessageValidation ne parvient pas à valider la charge utile du message d'entrée par rapport au schéma XSD ou à la définition WSDL. Elle se produira également si le message de charge utile contient des syntaxes JSON ou XML incorrectes.

steps.messagevalidation.SourceMessageNotAvailable

500

Cette erreur se produit si une variable spécifiée dans l'élément <Source> de la règle est :

hors de portée (non disponible dans le flux spécifique où la règle est exécutée) ;
impossible à résoudre (non définie),

steps.messagevalidation.NonMessageVariable

500

Cette erreur se produit si l'élément <Source> de la règle SOAPMessageValidation est défini sur une variable qui n'est pas du type message.

Les variables de type Message représentent des requêtes et des réponses HTTP entières. Les variables de flux Edge intégrées request, response et message sont de type message. Pour en savoir plus sur les variables de message, consultez la documentation de référence sur les variables.

steps.messagevalidation.Failed 500 Cette erreur se produit si la règle SOAPMessageValidation ne parvient pas à valider la charge utile du message d'entrée par rapport au schéma XSD ou à la définition WSDL. Elle se produira également si le message de charge utile contient des syntaxes JSON ou XML incorrectes.

Erreurs de déploiement

Ces erreurs peuvent se produire lorsque vous déployez un proxy contenant cette règle.

Nom de l'erreur	Cause	Corriger
`InvalidResourceType`	L'élément `<ResourceURL>` de la stratégie SAMLMessageValidation est défini sur un type de ressource non compatible avec la stratégie.
`ResourceCompileFailed`	Le script de ressource référencé dans l'élément `<ResourceURL>` de la stratégie SAMLMessageValidation contient une erreur qui empêche sa compilation.
`RootElementNameUnspecified`	L'élément `<Element>` de la règle SOAPMessageValidation ne contient pas le nom de l'élément racine.
`InvalidRootElementName`	L'élément `<Element>` de la stratégie SAMLMessageValidation contient un nom d'élément racine qui ne respecte pas les règles XML pour une dénomination valide des éléments.

Schémas

Chaque type de règle est défini par un schéma XML (.xsd). Pour référence, des schémas de règles sont disponibles sur GitHub.

Règle SOAPMessageValidation

À propos de la règle de validation de message

Avantages

Vidéos

Élément <MessageValidation>

Syntaxe

Règle par défaut

Exemples

1 : Validation XSD

2 : Validation SOAP

3 : XML/JSON bien formé

Référence d'élément enfant

<DisplayName>

Syntaxe

Exemple

<Element>

Syntaxe

Exemple 1

Exemple 2

<ResourceURL>

Syntaxe

Exemples

Utiliser des fichiers XSD pour la validation

Utiliser des fichiers WSDL pour la validation

<SOAPMessage>

Syntaxe

Exemple

<Source>

Syntaxe

Exemple

Codes d'erreur

Erreurs d'exécution

Erreurs de déploiement

Schémas

Articles associés

Élément `<MessageValidation>`

`<DisplayName>`

`<Element>`

`<ResourceURL>`

`<SOAPMessage>`

`<Source>`