Google utilizza la tecnologia AI per tradurre i contenuti nella tua lingua preferita. Le traduzioni generate dall'AI potrebbero contenere errori.

Norme di SOAPMessageValidation

Stai visualizzando la documentazione di Apigee Edge.
Consulta la documentazione di Apigee X. info

La policy SOAPMessageValidation esegue le seguenti operazioni:

Convalida qualsiasi messaggio XML in base ai relativi schemi XSD
Convalida i messaggi SOAP rispetto a una definizione WSDL
Determina la correttezza della formattazione dei messaggi JSON e XML

Sebbene il nome di questa policy nell'interfaccia utente sia "Convalida dei messaggi SOAP", la policy convalida non solo i messaggi SOAP. Questa sezione fa riferimento alla policy come "policy di convalida dei messaggi".

Informazioni sulla policy di convalida dei messaggi

Vantaggi

La convalida dei messaggi offre i seguenti vantaggi:

Informa immediatamente gli sviluppatori di app che utilizzano la tua API se le loro richieste non sono conformi o sono incomplete.
Individua i problemi nelle richieste, ad esempio i tag XML non chiusi correttamente.
Protegge i servizi di backend bloccando i messaggi XML o SOAP con strutture che potrebbero causare un comportamento imprevedibile.
Riduce il tempo impiegato per la risoluzione dei problemi, la ricerca nei forum o la consultazione con l'assistenza tecnica.
Incoraggia gli sviluppatori a familiarizzare con la definizione WSDL dello schema XML per eliminare gli errori di convalida, rendendo gli schemi XML ben compresi un componente chiave della documentazione dell'API.

Video

Guarda i seguenti video per scoprire di più sulla policy di convalida dei messaggi:

Video	Descrizione
Convalida la richiesta XML	Convalida la richiesta XML per un'API utilizzando la policy Message Validation.
Convalida la richiesta JSON	Convalida la richiesta JSON per un'API utilizzando la policy Message Validation.

Elemento `<MessageValidation>`

Definisce la policy Message Validation.

Valore predefinito	Consulta la scheda Policy predefinita di seguito
Obbligatorio?	Facoltativo
Tipo	Oggetto complesso
Elemento principale	n/a
Elementi secondari	`<DisplayName>` `<Element>` `<ResourceURL>` `<SOAPMessage>` `<Source>`

Sintassi

L'elemento <MessageValidation> utilizza la seguente sintassi:

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

Policy predefinita

L'esempio seguente mostra le impostazioni predefinite quando aggiungi una policy di convalida dei messaggi al tuo flusso nell'interfaccia utente di 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>

Questo elemento ha i seguenti attributi comuni a tutti i criteri:

Attributo	Predefinita	Obbligatorio?	Description (Descrizione)
`name`	N/A	Obbligatorio	Il nome interno del criterio. Il valore dell'attributo `name` può contenere lettere, numeri, spazi, trattini, trattini bassi e punti. Questo valore non può contenere più di 255 caratteri. Facoltativamente, utilizza l'elemento `<DisplayName>` per etichettare il criterio nell'editor del proxy dell'interfaccia utente di gestione con un nome diverso in linguaggio naturale.
`continueOnError`	false	Facoltativo	Imposta su "false" per restituire un errore quando un criterio non va a buon fine. Si tratta di un comportamento previsto per la maggior parte dei criteri. Impostalo su "true" per far sì che l'esecuzione del flusso continui anche dopo l'esito negativo di un criterio.
`enabled`	true	Facoltativo	Imposta su "true" per applicare il criterio. Imposta su "false" per "disattivare" il criterio. Il criterio non verrà applicato anche se rimane collegato a un flusso.
`async`	false	Deprecazione	Questo attributo è obsoleto.

Esempi

I seguenti esempi mostrano alcuni dei modi in cui puoi utilizzare la policy di convalida dei messaggi:

1: convalida XSD

Puoi utilizzare la policy Message Validation per convalidare il payload di una richiesta di messaggio XML rispetto a uno schema XSD.

Crea un nuovo file di risorse XSD. Ad esempio, "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>

Aggiungi la policy SOAP Message Validation al pre-flusso dell'endpoint proxy:

Specifica la posizione del file di risorse XSD con l'elemento <ResourceURL>. Ad esempio:
```
...
  <ResourceURL>xsd://note-schema.xsd</ResourceURL>
...
```
Rimuovi gli elementi <SOAPMessage> e <Element> dalla definizione della policy.

La definizione della policy dovrebbe essere simile alla seguente:

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

Invia una richiesta POST al proxy API con il tuo XML come payload del messaggio, come mostrato nell'esempio seguente:

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

Tieni presente che l'intestazione Content-type è impostata su "application/xml".

Puoi anche creare un file di dati per il payload e farvi riferimento con un comando simile al seguente:

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

Dovresti ricevere una risposta HTTP 200. A seconda dell'endpoint di destinazione, potresti ricevere ulteriori dettagli sulla richiesta. Ad esempio, se utilizzi http://httpbin.org/post come endpoint di destinazione e specifichi l'output -v (dettagliato), la risposta dovrebbe essere simile alla seguente:

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

Per verificare che la convalida XSD funzioni, prova a inserire un altro tag nel corpo della richiesta. Ad esempio:

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

Dovresti ricevere un errore di convalida.

2: convalida SOAP

Puoi utilizzare la policy Message Validation per convalidare il payload di una richiesta di messaggio SOAP rispetto a un WSDL.

Crea un nuovo file di risorse WSDL. Ad esempio, "example-wsdl.wsdl":

Visualizza WSDL completo

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

Aggiungi la policy SOAP Message Validation al pre-flow dell'endpoint proxy:
1. Imposta l'attributo version dell'elemento <SOAPMessage> sulla versione del protocollo SOAP rispetto alla quale vuoi eseguire la convalida. Ad esempio: "1.1":
```
...
  <SOAPMessage version="1.1"/>
...
```
2. Imposta il valore dell'elemento <Element> sull'elemento che vuoi convalidare:
```
...
  <Element namespace="https://example.com/gateway">getID</Element>
...
```
  <Element> specifica il primo elemento secondario sotto l'elemento <Body> nella busta della richiesta SOAP.
  
  Imposta l'attributo namespace sullo spazio dei nomi per l'elemento secondario.
3. Specifica la posizione del file di risorse WSDL con l'elemento <ResourceURL>. Ad esempio:
```
...
  <ResourceURL>wsdl://example-wsdl.wsdl</ResourceURL>
...
```
La definizione della policy dovrebbe essere simile alla seguente:
```
<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>
```

Invia una richiesta POST al proxy API con la busta SOAP come payload del messaggio, come mostrato nell'esempio seguente:

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

Tieni presente che l'intestazione Content-type è impostata su "application/xml".

Puoi anche creare un file di dati per il payload e farvi riferimento con un comando simile al seguente:

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

Dovresti ricevere una risposta HTTP 200. A seconda dell'endpoint di destinazione, potresti ricevere ulteriori dettagli sulla richiesta. Ad esempio, se utilizzi http://httpbin.org/post come endpoint di destinazione, la risposta dovrebbe essere simile alla seguente:

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

Puoi utilizzare la policy Message Validation per verificare che il payload di un messaggio JSON o XML sia nel formato corretto (non è la stessa cosa della convalida). Le norme garantiscono che la struttura e i contenuti soddisfino gli standard accettati, tra cui:

Esiste un solo elemento root
Non sono presenti caratteri non ammessi nei contenuti
Gli oggetti e i tag sono nidificati correttamente
I tag di apertura e chiusura corrispondono

Per verificare la presenza di un payload XML o JSON nel formato corretto:

Aggiungi la policy SOAP Message Validation al pre-flow dell'endpoint proxy.

Rimuovi gli elementi <ResourceURL>, <SOAPMessage> e <Element> dalla definizione della policy.

La definizione della policy dovrebbe essere simile alla seguente:

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

Invia una richiesta POST al proxy API, come mostrato nell'esempio seguente:
```
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."
  }
}'
```
Nota che l'intestazione Content-type è impostata su "application/json".

Per verificare la correttezza di un file XML, utilizza XML come payload del messaggio e imposta Content-type su "application/xml".

Dovresti ricevere una risposta HTTP 200. Quando invii un payload del messaggio che non contiene XML o JSON nel formato corretto, dovresti ricevere un errore steps.messagevalidation.Failed.

Riferimento dell'elemento secondario

Questa sezione descrive gli elementi secondari di <MessageValidation>.

`<DisplayName>`

Utilizzalo in aggiunta all'attributo name per etichettare la policy nell'editor proxy dell'interfaccia utente di gestione con un nome diverso e più naturale.

L'elemento <DisplayName> è comune a tutte le policy.

Valore predefinito	n/a
Obbligatorio?	Facoltativo. Se ometti `<DisplayName>`, viene utilizzato il valore dell'attributo `name` della policy.
Tipo	Stringa
Elemento principale	<`PolicyElement`>
Elementi secondari	Nessuno

L'elemento <DisplayName> utilizza la seguente sintassi:

Sintassi

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

Esempio

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

L'elemento <DisplayName> non ha attributi o elementi secondari.

`<Element>`

Specifica l'elemento nel messaggio da convalidare. Questo è il primo elemento secondario dell'elemento <Body> nella busta della richiesta SOAP.

Valore predefinito	sampleObject
Obbligatorio?	Facoltativo
Tipo	Stringa
Elemento principale	`<MessageValidation>`
Elementi secondari	Nessuno

L'elemento <Element> utilizza la seguente sintassi:

Sintassi

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

Esempio 1

L'esempio seguente definisce un singolo elemento da convalidare:

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

Esempio 2

Puoi specificare più di un elemento da convalidare aggiungendo più elementi <Element>:

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

L'elemento <Element> ha i seguenti attributi:

Attributo	Predefinito	Obbligatorio?	Descrizione
`namespace`	"http://sample.com"	Facoltativo	Definisce lo spazio dei nomi dell'elemento da convalidare.

`<ResourceURL>`

Identifica lo schema XSD o la definizione WSDL da utilizzare per convalidare il messaggio di origine.

Valore predefinito	wsdl://`display_name`.wsdl
Obbligatorio?	Facoltativo
Tipo	Stringa
Elemento principale	`<MessageValidation>`
Elementi secondari	Nessuno

L'elemento <ResourceURL> utilizza la seguente sintassi:

Sintassi

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

Esempi

Per un file XML:

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

Per un WSDL:

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

Il valore di <ResourceURL> deve puntare a un file di risorse nel proxy API. Non può fare riferimento a risorse esterne tramite HTTP o HTTPS.

Se non specifichi un valore per <ResourceURL>, viene verificato se il messaggio è in formato JSON o XML corretto se l'intestazione Content-type è rispettivamente "application/json" o "application/xml".

L'elemento <ResourceURL> non ha elementi o attributi secondari.

Utilizzo di XSD per la convalida

Se il payload XML che convalidi con la policy Message Validation fa riferimento a un altro schema, devi anteporre al file XSD incluso xsd nell'attributo schemaLocation.

Lo schema di esempio seguente è composto da più 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>

Utilizzo dei file WSDL per la convalida

Un WSDL deve definire almeno uno schema. Se non fa riferimento ad almeno uno schema, la policy di convalida dei messaggi non va a buon fine.

La profondità massima di importazione per uno schema è 10. Se superi questo numero di importazioni nidificate, la policy di convalida dei messaggi non va a buon fine.

`<SOAPMessage>`

Definisce la versione SOAP rispetto alla quale la policy MessageValidation esegue la convalida.

Valore predefinito	n/a
Obbligatorio?	Facoltativo
Tipo	n/a
Elemento principale	`<MessageValidation>`
Elementi secondari	Nessuno

L'elemento <SOAPMessage> utilizza la seguente sintassi:

Sintassi

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

Esempio

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

L'elemento <SOAPMessage> ha i seguenti attributi:

Attributo Predefinito Obbligatorio? Descrizione

Attributo	Predefinito	Obbligatorio?	Descrizione
`version`	Nessuno	Facoltativo	La versione SOAP utilizzata da questa policy per convalidare i messaggi SOAP. I valori validi sono: "1.1" "1.2" "1.1/1.2"

version

Nessuno

Facoltativo

La versione SOAP utilizzata da questa policy per convalidare i messaggi SOAP.

I valori validi sono:

"1.1"
"1.2"
"1.1/1.2"

Per saperne di più, consulta From SOAP/1.1 to SOAP Version 1.2 in 9 points.

`<Source>`

Identifica il messaggio di origine da convalidare. Il valore di questo elemento è il nome del messaggio che vuoi convalidare.

Se non imposti <Source>, questa policy viene impostata per impostazione predefinita su "message", che si riferisce al messaggio di richiesta completo (in un flusso di richiesta) o al messaggio di risposta (in un flusso di risposta), incluso l'eventuale payload. Puoi anche impostarlo esplicitamente su "request" o "response" per fare riferimento alla richiesta o alla risposta.

Valore predefinito	richiesta
Obbligatorio?	Facoltativo
Tipo	Stringa
Elemento principale	`<MessageValidation>`
Elementi secondari	Nessuno

L'elemento <Source> utilizza la seguente sintassi:

Sintassi

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

Esempio

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

Oltre a "message", "request" e "response", puoi impostare il valore di <Source> sul nome di qualsiasi messaggio nel tuo flusso. In questo caso, però, devi creare un messaggio personalizzato con quel nome nel flusso prima dell'esecuzione di questa policy. In caso contrario, riceverai un errore.

Se il valore di <Source> non può essere risolto nel flusso di messaggi o viene risolto in un tipo non di messaggio, si verifica una delle seguenti condizioni:

Se un valore è null: Edge genera un errore steps.messagevalidation.SourceMessageNotAvailable.
Se non è un tipo di messaggio: Edge genera un errore steps.messagevalidation.NonMessageVariable.

L'elemento <Source> non ha attributi o elementi secondari.

Codici di errore

Gli errori restituiti dalle policy Edge seguono un formato coerente, come descritto nel Riferimento ai codici di errore.

This section describes the fault codes and error messages that are returned and fault variables that are set by Edge 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.

Fault code HTTP status Cause Fix

Fault code	HTTP status	Cause
`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 Edge 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.

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)
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 Edge 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.

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.

Schemi

Ogni tipo di policy è definito da uno schema XML (.xsd). Per riferimento, gli schemi delle policy sono disponibili su GitHub.

Norme di SOAPMessageValidation

Informazioni sulla policy di convalida dei messaggi

Vantaggi

Video

Elemento <MessageValidation>

Sintassi

Policy predefinita

Esempi

1: convalida XSD

2: convalida SOAP

3: XML/JSON ben formati

Riferimento dell'elemento secondario

<DisplayName>

Sintassi

Esempio

<Element>

Sintassi

Esempio 1

Esempio 2

<ResourceURL>

Sintassi

Esempi

Utilizzo di XSD per la convalida

Utilizzo dei file WSDL per la convalida

<SOAPMessage>

Sintassi

Esempio

<Source>

Sintassi

Esempio

Codici di errore

Runtime errors

Deployment errors

Schemi

Argomenti correlati

Elemento `<MessageValidation>`

`<DisplayName>`

`<Element>`

`<ResourceURL>`

`<SOAPMessage>`

`<Source>`