Criterio di SOAPMessageValidation

Questa pagina si applica ad Apigee e Apigee hybrid.

Visualizza documentazione di Apigee Edge.

Il criterio SOAPMessageValidation comporta le seguenti operazioni:

• Convalida qualsiasi messaggio XML in base agli schemi XSD
• Convalida i messaggi SOAP in base a una definizione WSDL
• Determina la corretta formattazione dei messaggi JSON e XML

Il nome di questo criterio nella UI è SOAPMessageValidation, ma consente di convalidare che semplici messaggi SOAP. In questa sezione, il criterio viene chiamato criterio di convalida dei messaggi.

Questo criterio è un criterio standard e può essere implementato in qualsiasi tipo di ambiente. Per informazioni sui tipi di criteri e sulla disponibilità per ciascun tipo di ambiente, consulta Tipi di criteri.

Informazioni sulle norme di convalida dei messaggi

Vantaggi

La convalida dei messaggi offre i seguenti vantaggi:

• Comunica immediatamente agli sviluppatori di app che utilizzano la tua API se i loro Le richieste sono non conformi o 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 comportamenti imprevedibili.
• Riduce il tempo dedicato alla risoluzione dei problemi, alla ricerca nei forum o alla consulenza con all'assistenza tecnica.
• Incoraggia gli sviluppatori a familiarizzare con lo schema XML WSDL definizione per eliminare errori di convalida, rendendo gli schemi XML ben compresi un componente chiave della documentazione dell'API.

Video

Guarda i seguenti video per saperne di più sulle norme di MessageValidation:

Video	Descrizione
Convalida della richiesta XML	Convalida la richiesta XML per un'API utilizzando il criterio MessageValidation.
Convalida la richiesta JSON	Convalida la richiesta JSON per un'API utilizzando il criterio MessageValidation.

Elemento <MessageValidation>

Definisce il criterio MessageValidation.

Valore predefinito	Consulta la scheda Criterio predefinito 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>

Criterio predefinito

L'esempio seguente mostra le impostazioni predefinite quando aggiungi un criterio di convalida dei messaggi al flusso nell'interfaccia utente di Apigee:

<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	Predefinito	Obbligatorio?	Descrizione
name	N/D	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ò superare i 255 caratteri. Se vuoi, utilizza l'elemento <DisplayName> per etichettare il criterio nell'editor proxy dell'interfaccia utente di gestione con un nome diverso in linguaggio naturale.
continueOnError	falso	Facoltativo	Imposta su false per restituire un errore quando un criterio non va a buon fine. Questo è un comportamento previsto per la maggior parte dei criteri. Imposta su true per continuare l'esecuzione del flusso anche dopo un fallimento del criterio. Vedi anche: Le regole di errore vengono attivate SOLO in uno stato di errore (informazioni su continueOnError) Gestione degli errori all'interno del flusso corrente
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	falso	Ritirato	Questo attributo è stato ritirato.

Esempi

I seguenti esempi mostrano alcuni modi in cui è possibile utilizzare il campo MessageValidation norme:

1: Convalida XSD

Puoi utilizzare il criterio di convalida dei messaggi per convalidare il payload di una richiesta di messaggio XML in base a uno schema XSD.

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

2. Aggiungi il criterio di convalida dei messaggi SOAP al pre-flusso dell'endpoint proxy:
   1. Specifica la posizione del file di risorse XSD con <ResourceURL> . Ad esempio:

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

   2. Rimuovi gli elementi <SOAPMessage> e <Element> dalla definizione dei criteri.

   La definizione del criterio dovrebbe avere il seguente aspetto:

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

3. Invia una richiesta POST al proxy API con il tuo XML come 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>'

   Nota 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 dettagli aggiuntivi 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 usare il criterio Message Validation per convalidare il payload di richiesta di messaggi SOAP rispetto a un WSDL.

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

2. Aggiungi il criterio di convalida dei messaggi SOAP al pre-flusso dell'endpoint proxy:
   1. Imposta l'attributo version dell'elemento <SOAPMessage> su del protocollo SOAP da utilizzare per la convalida. Ad esempio: "1,1":

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

   2. Imposta il valore dell'elemento <Element> sull'elemento da convalidare:

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

      <Element> specifica il primo elemento secondario dell'elemento <Body> nell'involucro della richiesta SOAP.

      Imposta l'attributo namespace sullo spazio dei nomi per l'elemento secondario.

   3. Specifica la posizione del file della risorsa WSDL con l'elemento <ResourceURL>. Ad esempio:

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

   La definizione del criterio dovrebbe avere il seguente aspetto:

   <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. Invia una richiesta POST al proxy API con la busta SOAP come payload dei messaggi, come illustrato 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 dettagli aggiuntivi sulla richiesta. Ad esempio, se utilizzi http://httpbin.org/post come endpoint target, la risposta dovrebbe essere simile a:

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

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

• È presente un solo elemento radice
• I contenuti non contengono caratteri illegali
• Oggetti e tag sono nidificati correttamente
• Corrispondenza dei tag di inizio e di fine

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

1. Aggiungi il criterio SOAP Message Validation al pre-flusso dell'endpoint proxy.
2. Rimuovi <ResourceURL>, <SOAPMessage>, ed elementi <Element> dalla definizione del criterio.

   La definizione delle tue norme dovrebbe avere il seguente aspetto:

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

3. 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 ben formattato, dovresti ricevere un messaggio di errore steps.messagevalidation.Failed.

Riferimento all'elemento secondario

Questa sezione descrive gli elementi secondari di <MessageValidation>.

<DisplayName>

Da utilizzare insieme all'attributo name per etichettare il criterio nell'editor proxy dell'interfaccia utente di gestione con un nome diverso e più naturale.

L'elemento <DisplayName> è comune a tutti i criteri.

Valore predefinito	N/D
Obbligatorio?	Facoltativo. Se ometti <DisplayName>, viene utilizzato il valore dell'attributo name del criterio.
Tipo	Stringa
Elemento principale	<PolicyElement>
Elementi secondari	Nessuno

La sintassi dell'elemento <DisplayName> è la seguente:

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 del messaggio da convalidare. Questo è il primo figlio 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ù <Element> elementi:

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

L'elemento <Element> prevede 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 file 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>, il messaggio viene controllato per verificare che non ci siano errori di formato JSON o XML se l'intestazione Content-type è application/json oppure application/xml, rispettivamente.

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

Utilizzo di XSD per la convalida

Se il payload XML che convalidi con il criterio MessageValidation fa riferimento un altro schema, devi aggiungere xsd come prefisso al file XSD incluso schemaLocation.

Il seguente schema di esempio è 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>

Nota: puoi includere o importare gli XSD solo se sono file di risorse nel tuo proxy API. Non puoi includere file XSD esterni.

Utilizzo di WSDL per la convalida

Un file WSDL deve definire almeno uno schema. Se non fa riferimento ad almeno uno schema, il criterio MessageValidation non va a buon fine.

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

<SOAPMessage>

Definisce la versione SOAP in base alla quale viene convalidato il criterio MessageValidation.

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> prevede i seguenti attributi:

Attributo	Predefinito	Obbligatorio?	Descrizione
version	Nessuno	Facoltativo	La versione SOAP utilizzata da questo criterio per convalidare i messaggi SOAP. I valori validi sono: "1,1" "1,2" "1,1/1,2"

Per ulteriori informazioni, consulta Da SOAP/1.1 a SOAP versione 1.2 in 9 punti.

<Source>

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

Se non imposti <Source>, questo criterio è impostato sul valore predefinito message, che si riferisce all'intera messaggio di richiesta (in un flusso di richiesta) o messaggio di risposta (in un flusso di risposta), inclusi eventuali il 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 <Source> al nome di qualsiasi messaggio nel tuo flusso. Se lo fai, però, devi creare un messaggio personalizzato con questo nome nel flusso prima dell'esecuzione di questo criterio. In caso contrario, riceverai un messaggio di errore.

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

• Se un valore null:Apigee genera un Errore steps.messagevalidation.SourceMessageNotAvailable.
• Se è un tipo diverso da messaggio:Apigee genera un Errore steps.messagevalidation.NonMessageVariable.

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

Codici di errore

Questa sezione descrive i codici di errore e i messaggi di errore restituiti e le variabili di errore impostate da Apigee quando questo criterio attiva un errore. Queste informazioni sono importanti se stai sviluppando regole di errore per gestire gli errori. Per scoprire di più, consulta Informazioni importanti sugli errori relativi alle norme e Gestione degli errori.

Errori di runtime

Questi errori possono verificarsi durante l'esecuzione del criterio.

Hai bisogno di aiuto per risolvere un errore? Fai clic su nella colonna Correzione per informazioni dettagliate sulla risoluzione dei problemi.

Utilizza Monitoraggio API per esaminare i codici di errore e diagnosticare i problemi più rapidamente. Per un esempio, consulta Configurare un avviso relativo a un codice di errore dei criteri. Consulta la sezione Riferimento ai codici di errore per un elenco completo di tutti i codici di errore che puoi gestire con il monitoraggio dell'API.

Codice guasto	Stato HTTP	Causa	Correggi
steps.messagevalidation.SourceMessageNotAvailable	500	Questo errore si verifica se una variabile specificata nell'elemento <Source> del criterio è: fuori ambito (non disponibile nel flusso specifico in cui viene eseguito il criterio) o non può essere risolto (non è definito)
steps.messagevalidation.NonMessageVariable	500	Questo errore si verifica se l'elemento <Source> nel criterio SOAPMessageValidation è impostato su una variabile non di tipo message. Le variabili di tipo di messaggio rappresentano intere richieste e risposte HTTP. Le variabili di flusso Apigee integrate request, response e message sono di tipo messaggio. Per scoprire di più sulle variabili dei messaggi, consulta la sezione Riferimento alle variabili.
steps.messagevalidation.Failed	500	Questo errore si verifica se il criterio SOAPMessageValidation non riesce a convalidare il payload del messaggio di input in base allo schema XSD o alla definizione WSDL. Si verifica anche se nel messaggio del payload è presente JSON o XML con formato errato.

Errori di deployment

Questi errori possono verificarsi quando esegui il deployment di un proxy contenente questo criterio.

Hai bisogno di aiuto per risolvere un errore? Fai clic su accanto alla descrizione della causa dell'errore per visitare la pagina di risoluzione dei problemi.

Nome dell'errore	Causa	Correggi
InvalidResourceType	L'elemento <ResourceURL> nel criterio SOAPMessageValidation è impostato su un tipo di risorsa non supportato dal criterio.
ResourceCompileFailed	Lo script della risorsa a cui si fa riferimento nell'elemento <ResourceURL> del criterio SOAPMessageValidation contiene un errore che ne impedisce la compilazione.
RootElementNameUnspecified	L'elemento <Element> nel criterio SOAPMessageValidation non contiene il nome dell'elemento principale.
InvalidRootElementName	L'elemento <Element> nel criterio SOAPMessageValidation contiene un nome dell'elemento principale che non rispetta le regole XML per la denominazione degli elementi validi.

Schemi

Ogni tipo di criterio è definito da uno schema XML (.xsd). Come riferimento, gli schemi di criteri sono disponibili su GitHub.

Argomenti correlati

• Minaccia XML Norme sulla protezione
• Criterio da XML a JSON
• Criteri da JSON a XML
• Minaccia JSON Norme sulla protezione