Google używa technologii AI do tłumaczenia treści na Twój preferowany język. Tłumaczenia wygenerowane przez AI mogą zawierać błędy.

Zasada SOAPMessageValidation

Wyświetlasz dokumentację Apigee Edge.
Otwórz dokumentację Apigee X. info

Zasada SOAPMessageValidation wykonuje te czynności:

Sprawdza poprawność dowolnej wiadomości XML pod kątem schematów XSD
Weryfikuje komunikaty SOAP pod kątem definicji WSDL
Określa poprawność formatowania wiadomości JSON i XML

Chociaż nazwa tej zasady w interfejsie to „Weryfikacja komunikatów SOAP”, zasada ta weryfikuje nie tylko komunikaty SOAP. W tej sekcji zasada ta jest nazywana „zasadą sprawdzania poprawności wiadomości”.

Zasady sprawdzania poprawności wiadomości

Korzyści

Weryfikacja wiadomości zapewnia te korzyści:

Natychmiast informuje deweloperów aplikacji, którzy korzystają z Twojego interfejsu API, jeśli ich żądania są niezgodne lub niekompletne.
Wskazuje problemy w żądaniach, takie jak nieprawidłowo zamknięte tagi XML.
Chroni usługi backendu, blokując wiadomości XML lub SOAP o strukturach, które mogą powodować nieprzewidywalne zachowanie.
Skraca czas poświęcany na rozwiązywanie problemów, przeszukiwanie forów lub konsultacje z zespołem pomocy technicznej.
Zachęca deweloperów do zapoznania się z definicją WSDL schematu XML, aby wyeliminować błędy weryfikacji. Dzięki temu dobrze zrozumiane schematy XML stają się kluczowym elementem dokumentacji API.

Filmy

Aby dowiedzieć się więcej o zasadzie sprawdzania poprawności wiadomości, obejrzyj te filmy:

Wideo	Opis
Sprawdzanie poprawności żądania XML	Sprawdź żądanie XML dla interfejsu API za pomocą zasady sprawdzania poprawności wiadomości.
Sprawdzanie poprawności żądania JSON	Sprawdź poprawność żądania JSON dla interfejsu API za pomocą zasady sprawdzania poprawności wiadomości.

Element `<MessageValidation>`

Definiuje zasadę weryfikacji wiadomości.

Wartość domyślna	Zobacz kartę Zasady domyślne poniżej.
Wymagane?	Opcjonalny
Typ	Złożony obiekt
Element nadrzędny	nie dotyczy
Elementy podrzędne	`<DisplayName>` `<Element>` `<ResourceURL>` `<SOAPMessage>` `<Source>`

Składnia

Element <MessageValidation> używa tej składni:

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

Zasada domyślna

Poniższy przykład pokazuje ustawienia domyślne, gdy dodajesz zasadę weryfikacji wiadomości do przepływu w interfejsie 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>

Ten element ma te atrybuty, które są wspólne dla wszystkich zasad:

Atrybut	Domyślnie	Wymagany?	Description
`name`	Nie dotyczy	Wymagane	Wewnętrzna nazwa zasady. Wartość atrybutu `name` może zawierać litery, cyfry, spacje, łączniki, podkreślenia i kropki. Ta wartość nie może przekraczać 255 znaków. Opcjonalnie użyj elementu `<DisplayName>`, aby oznaczyć zasadę w edytorze proxy interfejsu zarządzania inną nazwą w języku naturalnym.
`continueOnError`	fałsz	Opcjonalnie	Ustaw wartość „false”, aby wyświetlać błąd, gdy zasada nie działa. To prawidłowy proces w przypadku większości zasad. Ustaw wartość „true”, aby kontynuować wykonywanie przepływu nawet po wystąpieniu błędu.
`enabled`	prawda	Opcjonalnie	Ustaw wartość „true”, aby egzekwować zasadę. Ustaw wartość „false”, aby wyłączyć zasadę. Zasada nie będzie egzekwowana, nawet jeśli pozostanie powiązana z przepływem.
`async`	fałsz	Wycofano	Ten atrybut został wycofany.

Przykłady

Oto kilka przykładów zastosowania zasady sprawdzania poprawności komunikatów:

1. Walidacja XSD

Zasady weryfikacji wiadomości możesz użyć do sprawdzenia ładunku żądania wiadomości XML pod kątem schematu XSD.

Utwórz nowy plik zasobów XSD. Na przykład „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>

Dodaj zasadę SOAP Message Validation do procesu wstępnego punktu końcowego proxy:

Określ lokalizację pliku zasobów XSD za pomocą elementu <ResourceURL>. Na przykład:
```
...
  <ResourceURL>xsd://note-schema.xsd</ResourceURL>
...
```
Usuń elementy <SOAPMessage> i <Element> z definicji zasad.

Definicja zasady powinna wyglądać mniej więcej tak:

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

Wyślij żądanie POST do serwera proxy interfejsu API z kodem XML jako ładunkiem wiadomości, jak pokazano w tym przykładzie:

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

Zwróć uwagę, że nagłówek Content-type jest ustawiony na „application/xml”.

Możesz też utworzyć plik danych dla ładunku i odwołać się do niego za pomocą polecenia podobnego do tego:

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

Powinna pojawić się odpowiedź HTTP 200. W zależności od docelowego punktu końcowego możesz otrzymać dodatkowe informacje o żądaniu. Jeśli na przykład używasz http://httpbin.org/post jako docelowego punktu końcowego i określisz dane wyjściowe -v (szczegółowe), odpowiedź powinna wyglądać mniej więcej tak:

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

Aby sprawdzić, czy walidacja XSD działa, spróbuj wstawić inny tag do treści żądania. Na przykład:

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

Powinien pojawić się błąd weryfikacji.

2. Walidacja SOAP

Zasady sprawdzania poprawności wiadomości możesz użyć do sprawdzenia ładunku żądania wiadomości SOAP pod kątem WSDL.

Utwórz nowy plik zasobów WSDL. Na przykład „example-wsdl.wsdl”:

Wyświetl pełny plik WSDL

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

Dodaj zasadę walidacji komunikatów SOAP do procesu wstępnego punktu końcowego proxy:
1. Ustaw atrybut version elementu <SOAPMessage> na wersję protokołu SOAP, którą chcesz zweryfikować. Na przykład „1.1”:
```
...
  <SOAPMessage version="1.1"/>
...
```
2. Ustaw wartość elementu <Element> na element, który chcesz zweryfikować:
```
...
  <Element namespace="https://example.com/gateway">getID</Element>
...
```
  <Element> określa pierwszy element podrzędny elementu <Body> w kopercie żądania SOAP.
  
  Ustaw atrybut namespace na przestrzeń nazw tego elementu podrzędnego.
3. Określ lokalizację pliku zasobu WSDL za pomocą elementu <ResourceURL>. Na przykład:
```
...
  <ResourceURL>wsdl://example-wsdl.wsdl</ResourceURL>
...
```
Definicja zasady powinna wyglądać mniej więcej tak:
```
<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>
```

Wyślij żądanie POST do serwera proxy interfejsu API z kopertą SOAP jako ładunkiem wiadomości, jak w tym przykładzie:

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

Zwróć uwagę, że nagłówek Content-type jest ustawiony na „application/xml”.

Możesz też utworzyć plik danych dla ładunku i odwołać się do niego za pomocą polecenia podobnego do tego:

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

Powinna pojawić się odpowiedź HTTP 200. W zależności od docelowego punktu końcowego możesz otrzymać dodatkowe informacje o żądaniu. Jeśli na przykład jako docelowego punktu końcowego używasz http://httpbin.org/post, odpowiedź powinna wyglądać mniej więcej tak:

< 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: prawidłowo sformatowany plik XML/JSON;

Możesz użyć zasady weryfikacji wiadomości, aby potwierdzić, że ładunek wiadomości JSON lub XML jest poprawnie sformatowany (nie jest to to samo co weryfikacja). Zasady te zapewniają, że struktura i treść spełniają przyjęte standardy, w tym:

Jest tylko 1 element główny.
Treść nie zawiera niedozwolonych znaków.
Obiekty i tagi są prawidłowo zagnieżdżone.
Tagi początkowe i końcowe są zgodne.

Aby sprawdzić, czy ładunek XML lub JSON jest prawidłowo sformatowany:

Dodaj zasadę SOAP Message Validation do procesu wstępnego punktu końcowego serwera proxy.

Usuń elementy <ResourceURL>, <SOAPMessage> i <Element> z definicji zasady.

Definicja zasady powinna wyglądać mniej więcej tak:

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

Wyślij żądanie POST do serwera proxy interfejsu API, jak w tym przykładzie:
```
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."
  }
}'
```
Zwróć uwagę, że nagłówek Content-type jest ustawiony na „application/json”.

Aby sprawdzić, czy plik XML jest poprawnie sformatowany, użyj XML jako ładunku wiadomości i ustaw Content-type na „application/xml”.

Powinna pojawić się odpowiedź HTTP 200. Jeśli wyślesz ładunek wiadomości, który nie zawiera prawidłowo sformatowanego kodu XML lub JSON, powinien pojawić się błąd steps.messagevalidation.Failed.

Dokumentacja elementu podrzędnego

W tej sekcji opisano elementy podrzędne elementu <MessageValidation>.

`<DisplayName>`

Używaj go razem z atrybutem name, aby oznaczyć zasadę w edytorze serwera proxy interfejsu zarządzania inną, bardziej naturalnie brzmiącą nazwą.

Element <DisplayName> jest wspólny dla wszystkich zasad.

Wartość domyślna	nie dotyczy
Wymagane?	Opcjonalnie: Jeśli pominiesz parametr `<DisplayName>`, używana jest wartość atrybutu `name` zasady.
Typ	Ciąg znaków
Element nadrzędny	<`PolicyElement`>
Elementy podrzędne	Brak

Element <DisplayName> używa tej składni:

Składnia

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

Przykład

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

Element <DisplayName> nie ma atrybutów ani elementów podrzędnych.

`<Element>`

Określa element w wiadomości, który ma zostać zweryfikowany. Jest to pierwszy element podrzędny elementu <Body> w kopercie żądania SOAP.

Wartość domyślna	sampleObject
Wymagane?	Opcjonalny
Typ	Ciąg znaków
Element nadrzędny	`<MessageValidation>`
Elementy podrzędne	Brak

Element <Element> używa tej składni:

Składnia

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

Przykład 1

Poniższy przykład definiuje pojedynczy element do sprawdzenia:

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

Przykład 2

Możesz określić więcej niż 1 element do sprawdzenia, dodając kilka elementów <Element>:

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

Element <Element> ma te atrybuty:

Atrybut	Domyślny	Wymagany?	Opis
`namespace`	"http://sample.com"	Opcjonalny	Określa przestrzeń nazw elementu, który ma zostać zweryfikowany.

`<ResourceURL>`

Określa schemat XSD lub definicję WSDL, które mają być używane do sprawdzania poprawności wiadomości źródłowej.

Wartość domyślna	wsdl://`display_name`.wsdl
Wymagane?	Opcjonalny
Typ	Ciąg znaków
Element nadrzędny	`<MessageValidation>`
Elementy podrzędne	Brak

Element <ResourceURL> używa tej składni:

Składnia

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

Przykłady

W przypadku pliku XML:

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

W przypadku WSDL:

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

Wartość <ResourceURL> musi wskazywać plik zasobu w serwerze proxy interfejsu API. Nie może odwoływać się do zasobów zewnętrznych przez HTTP lub HTTPS.

Jeśli nie podasz wartości dla <ResourceURL>, wiadomość zostanie sprawdzona pod kątem prawidłowego formatu JSON lub XML, jeśli nagłówek Content-type to odpowiednio „application/json” lub „application/xml”.

Element <ResourceURL> nie ma elementów podrzędnych ani atrybutów.

Używanie plików XSD do walidacji

Jeśli ładunek XML, który sprawdzasz za pomocą zasady weryfikacji wiadomości, odwołuje się do innego schematu, musisz dodać prefiks xsd do dołączonego pliku XSD w atrybucie schemaLocation.

Poniższy przykładowy schemat składa się z kilku plików 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>

Używanie plików WSDL do walidacji

Plik WSDL musi definiować co najmniej 1 schemat. Jeśli nie odwołuje się do co najmniej 1 schematu, zasada sprawdzania poprawności wiadomości nie działa.

Maksymalna głębokość importu schematu wynosi 10. Jeśli przekroczysz tę liczbę zagnieżdżonych importów, zasada walidacji wiadomości nie zadziała.

`<SOAPMessage>`

Określa wersję SOAP, z którą zasada weryfikacji wiadomości przeprowadza weryfikację.

Wartość domyślna	nie dotyczy
Wymagane?	Opcjonalny
Typ	nie dotyczy
Element nadrzędny	`<MessageValidation>`
Elementy podrzędne	Brak

Element <SOAPMessage> używa tej składni:

Składnia

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

Przykład

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

Element <SOAPMessage> ma te atrybuty:

Atrybut Domyślny Wymagany? Opis

Atrybut	Domyślny	Wymagany?	Opis
`version`	Brak	Opcjonalny	Wersja protokołu SOAP, której ta zasada używa do sprawdzania poprawności komunikatów SOAP. Prawidłowe wartości to: "1.1" "1.2" "1.1/1.2"

version

Brak

Opcjonalny

Wersja protokołu SOAP, której ta zasada używa do sprawdzania poprawności komunikatów SOAP.

Prawidłowe wartości to:

"1.1"
"1.2"
"1.1/1.2"

Więcej informacji znajdziesz w artykule From SOAP/1.1 to SOAP Version 1.2 in 9 points (Od SOAP/1.1 do SOAP w wersji 1.2 w 9 punktach).

`<Source>`

Identyfikuje wiadomość źródłową, która ma zostać zweryfikowana. Wartością tego elementu jest nazwa wiadomości, którą chcesz zweryfikować.

Jeśli nie ustawisz <Source>, ta zasada będzie domyślnie ustawiona na „message”, co odnosi się do pełnego komunikatu żądania (w przepływie żądania) lub komunikatu odpowiedzi (w przepływie odpowiedzi), w tym do ładunku. Możesz też wyraźnie ustawić wartość „request” lub „response”, aby odwołać się do żądania lub odpowiedzi.

Wartość domyślna	żądanie
Wymagane?	Opcjonalny
Typ	Ciąg znaków
Element nadrzędny	`<MessageValidation>`
Elementy podrzędne	Brak

Element <Source> używa tej składni:

Składnia

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

Przykład

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

Oprócz „message”, „request” i „response” możesz ustawić wartość <Source> na nazwę dowolnej wiadomości w przepływie. Jeśli to zrobisz, przed wykonaniem tej zasady musisz utworzyć w przepływie komunikat niestandardowy o tej nazwie. W przeciwnym razie pojawi się błąd.

Jeśli wartość <Source> nie może zostać rozpoznana w przepływie wiadomości lub jest rozpoznawana jako typ inny niż wiadomość, występuje jedna z tych sytuacji:

Jeśli wartość jest pusta: Edge zwraca błąd steps.messagevalidation.SourceMessageNotAvailable.
Jeśli typ nie jest wiadomością: Edge zgłasza błąd steps.messagevalidation.NonMessageVariable.

Element <Source> nie ma atrybutów ani elementów podrzędnych.

Kody błędów

Błędy zwracane przez zasady Edge mają spójny format opisany w dokumentacji kodów błędów.

W tej sekcji opisujemy kody błędów i komunikaty o błędach, które są zwracane, oraz zmienne błędów ustawiane przez Edge, gdy ta zasada wywołuje błąd. Te informacje są ważne, jeśli opracowujesz reguły dotyczące błędów do obsługi takich błędów. Więcej informacji znajdziesz w sekcjach Co musisz wiedzieć o błędach zasad i Postępowanie w przypadku błędów.

Błędy w czasie wykonywania

Te błędy mogą wystąpić podczas wykonywania zasady.

Kod błędu Stan HTTP Przyczyna Napraw

Kod błędu	Stan HTTP	Przyczyna
`steps.messagevalidation.SourceMessageNotAvailable`	500	Ten błąd występuje, jeśli zmienna określona w elemencie `<Source>` zasady ma jedną z tych wartości: poza zakresem (niedostępne w konkretnym procesie, w którym jest wykonywana zasada) lub Nie można rozwiązać (nie określono)
`steps.messagevalidation.NonMessageVariable`	500	Ten błąd występuje, jeśli element `<Source>` w zasadzie SOAPMessageValidation jest ustawiony na zmienną, która nie jest typu komunikat. Zmienne typu wiadomości reprezentują całe żądania i odpowiedzi HTTP. Wbudowane zmienne przepływu Edge `request`, `response` i `message` mają typ komunikatu. Więcej informacji o zmiennych wiadomości znajdziesz w dokumentacji zmiennych.
`steps.messagevalidation.Failed`	500	Ten błąd występuje, jeśli zasada SOAPMessageValidation nie sprawdza poprawności ładunku wejściowego wiadomości w odniesieniu do schematu XSD lub definicji WSDL. Ten błąd może wystąpić również wtedy, gdy w wiadomości z ładunkiem występuje nieprawidłowy format JSON lub XML.

steps.messagevalidation.SourceMessageNotAvailable

500

Ten błąd występuje, jeśli zmienna określona w elemencie <Source> zasady ma jedną z tych wartości:

poza zakresem (niedostępne w konkretnym procesie, w którym jest wykonywana zasada)
Nie można rozwiązać (nie określono)

steps.messagevalidation.NonMessageVariable

500

Ten błąd występuje, jeśli element <Source> w zasadzie SOAPMessageValidation jest ustawiony na zmienną, która nie jest typu komunikat.

Zmienne typu wiadomości reprezentują całe żądania i odpowiedzi HTTP. Wbudowane zmienne przepływu Edge request, response i message mają typ komunikatu. Więcej informacji o zmiennych wiadomości znajdziesz w dokumentacji zmiennych.

steps.messagevalidation.Failed 500 Ten błąd występuje, jeśli zasada SOAPMessageValidation nie sprawdza poprawności ładunku wejściowego wiadomości w odniesieniu do schematu XSD lub definicji WSDL. Ten błąd może wystąpić również wtedy, gdy w wiadomości z ładunkiem występuje nieprawidłowy format JSON lub XML.

Błędy wdrażania

Te błędy mogą wystąpić podczas wdrażania serwera proxy zawierającego te zasady.

Nazwa błędu	Przyczyna	Napraw
`InvalidResourceType`	Element `<ResourceURL>` w zasadzie SOAPMessageValidation jest ustawiony na typ zasobu, który nie jest obsługiwany przez tę zasadę.
`ResourceCompileFailed`	Skrypt zasobów, do którego odwołuje się element `<ResourceURL>` zasady SOAPMessageValidation, zawiera błąd uniemożliwiający mu kompilowanie.
`RootElementNameUnspecified`	Element `<Element>` w zasadzie SOAPMessageValidation nie zawiera nazwy elementu głównego.
`InvalidRootElementName`	Element `<Element>` w zasadzie SOAPMessageValidation zawiera nazwę elementu głównego, która jest niezgodna z regułami XML dotyczącymi prawidłowych nazw elementów.

Schematy

Każdy typ zasady jest definiowany przez schemat XML (.xsd). Schematy zasad są dostępne na GitHubie.

Zasada SOAPMessageValidation

Zasady sprawdzania poprawności wiadomości

Korzyści

Filmy

Element <MessageValidation>

Składnia

Zasada domyślna

Przykłady

1. Walidacja XSD

2. Walidacja SOAP

3: prawidłowo sformatowany plik XML/JSON;

Dokumentacja elementu podrzędnego

<DisplayName>

Składnia

Przykład

<Element>

Składnia

Przykład 1

Przykład 2

<ResourceURL>

Składnia

Przykłady

Używanie plików XSD do walidacji

Używanie plików WSDL do walidacji

<SOAPMessage>

Składnia

Przykład

<Source>

Składnia

Przykład

Kody błędów

Błędy w czasie wykonywania

Błędy wdrażania

Schematy

Powiązane artykuły

Element `<MessageValidation>`

`<DisplayName>`

`<Element>`

`<ResourceURL>`

`<SOAPMessage>`

`<Source>`