Ta strona została przetłumaczona przez Cloud Translation API.

Zasada SOAPMessageValidation

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

Zasada SOAPMessageValidation:

Sprawdzanie zgodności dowolnej wiadomości XML ze schematami XSD
Sprawdzanie komunikatów SOAP pod kątem zgodności z definicją WSDL
Określa poprawność sformatowania komunikatów JSON i XML.

Chociaż nazwa tej zasady w interfejsie to „Weryfikacja wiadomości SOAP”, zasada sprawdza więcej niż tylko wiadomości SOAP. W tej sekcji te zasady są nazywane „zasadami dotyczącymi weryfikacji wiadomości”.

Zasady weryfikacji wiadomości

Zalety

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, np. tagi XML, które nie są prawidłowo zamknięte.
chroni usługi backendowe, blokując wiadomości XML lub SOAP o strukturach, które mogą powodować nieprzewidywalne działanie.
Skraca czas poświęcany na rozwiązywanie problemów, wyszukiwanie informacji na forach lub konsultacje z zespołem pomocy technicznej.
Zachęca deweloperów do zapoznania się z definicją schematu XML w WSDL, aby wyeliminować błędy walidacji. Dzięki temu dobrze zrozumiane schematy XML staną się kluczowym elementem dokumentacji interfejsu API.

Filmy

Aby dowiedzieć się więcej o zasadach weryfikacji wiadomości, obejrzyj te filmy:

Wideo	Opis
Weryfikowanie żądania XML	Sprawdź żądanie XML interfejsu API za pomocą zasady weryfikacji wiadomości.
Sprawdzanie żądania JSON	Zweryfikuj żądanie JSON interfejsu API za pomocą zasady walidacji wiadomości.

Element `<MessageValidation>`

Określa zasady weryfikacji wiadomości.

Wartość domyślna	Zobacz kartę Domyślne zasady poniżej.
Wymagany?	Opcjonalnie
Typ	Obiekt złożony
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>

Domyślne zasady

Ten przykład pokazuje ustawienia domyślne, gdy dodasz do przepływu w interfejsie Edge politykę weryfikacji wiadomości:

<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

Poniżej znajdziesz kilka przykładów sposobów korzystania z zasad weryfikacji wiadomości:

1. Walidacja XSD

Zasady weryfikacji wiadomości możesz wykorzystać do zweryfikowania ładunku żądania wiadomości XML w odniesieniu do schematu XSD.

Utwórz nowy plik zasobu 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ę weryfikacji komunikatów SOAP do wstępnego przepływu danych w usługach proxy:

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

Definicja zasad powinna wyglądać 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, podając kod XML jako ładunek 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 ma wartość „application/xml”.

Możesz też utworzyć plik danych dla ładunku i odwoływać 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'

Powinieneś otrzymać odpowiedź HTTP 200. W zależności od docelowego punktu końcowego możesz otrzymać dodatkowe informacje o żądaniu. Jeśli np. używasz punktu końcowego docelowego http://httpbin.org/post i podajesz 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 sprawdzanie XSD działa, spróbuj wstawić inny tag w 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 wiadomości możesz użyć do zweryfikowania ładunku żądania wiadomości SOAP na podstawie pliku WSDL.

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

Wyświetlanie pełnego pliku 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 regułę weryfikacji komunikatów SOAP do wstępnego przepływu w węźle pośredniczącym:
1. Ustaw atrybut version elementu <SOAPMessage> na wersję protokołu SOAP, pod kątem której chcesz przeprowadzić walidację. Na przykład:
```
...
  <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 w elemencie <Body> w kopercie żądania SOAP.
  
  Ustaw atrybut namespace na nazwę przestrzeni dla 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 zasad powinna wyglądać 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 pokazano 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 ma wartość „application/xml”.

Możesz też utworzyć plik danych dla ładunku i odwoływać 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'

Powinieneś otrzymać odpowiedź HTTP 200. W zależności od docelowego punktu końcowego możesz otrzymać dodatkowe informacje o żądaniu. Jeśli np. jako docelowego punktu końcowego używasz adresu 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 kod XML/JSON

Zasady weryfikacji wiadomości umożliwiają sprawdzenie, czy ładunek wiadomości w formacie JSON lub XML jest poprawnie sformułowany (nie jest to to samo co walidacja). Zasady te zapewniają, że struktura i treść są zgodne z akceptowanymi standardami, w tym:

Jest tylko jeden element główny.
Treść nie zawiera niedozwolonych znaków.
obiekty i tagi są prawidłowo zagnieżdżone,
Tagi początkowy i końcowy są takie same.

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

Dodaj regułę weryfikacji komunikatów SOAP do pre-flow punktu końcowego w usłudze proxy.

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

Definicja zasad powinna wyglądać 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 pokazano 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 ma wartość „application/json”.

Aby sprawdzić poprawność pliku XML, użyj XML jako ładunku wiadomości i ustaw wartość Content-type na „application/xml”.

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

Odwołanie do elementu podrzędnego

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

`<DisplayName>`

Oprócz atrybutu name możesz użyć innej, bardziej naturalnie brzmiącej nazwy, aby oznaczyć zasadę w edytorze proxy w interfejsie zarządzania.

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

Wartość domyślna	nie dotyczy
Wymagany?	Opcjonalnie: Jeśli pominiesz parametr `<DisplayName>`, zostanie użyta 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 w elemencie <Body> w kopercie żądania SOAP.

Wartość domyślna	sampleObject
Wymagany?	Opcjonalnie
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

W tym przykładzie zdefiniowano pojedynczy element do zweryfikowania:

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

Przykład 2

Aby zweryfikować więcej niż jeden element, dodaj wiele 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”	Opcjonalnie	Określa przestrzeń nazw elementu, który ma zostać zweryfikowany.

`<ResourceURL>`

Określa schemat XSD lub definicję WSDL, która ma być używana do sprawdzania poprawności wiadomości źródłowej.

Wartość domyślna	wsdl://`display_name`.wsdl
Wymagany?	Opcjonalnie
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 pliku WSDL:

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

Wartość <ResourceURL> musi wskazywać plik zasobów w Twoim interfejsie proxy API. Nie może ono odwoływać się do zasobów zewnętrznych przez HTTP ani HTTPS.

Jeśli nie określisz wartości parametru <ResourceURL>, wiadomość zostanie sprawdzona pod kątem poprawności 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.

Sprawdzanie poprawności za pomocą plików XSD

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

Ten 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 sprawdzania poprawności

Plik WSDL musi definiować co najmniej 1 schemat. Jeśli nie odwołuje się do co najmniej jednego schematu, zasada weryfikacji wiadomości nie przechodzi weryfikacji.

Maksymalna głębia importu schematu wynosi 10. Jeśli przekroczysz tę liczbę, zasady weryfikacji wiadomości nie zostaną zastosowane.

`<SOAPMessage>`

Określa wersję SOAP, według której zasady weryfikacji wiadomości przeprowadzają weryfikację.

Wartość domyślna	nie dotyczy
Wymagany?	Opcjonalnie
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	Opcjonalnie	Wersja SOAP, której używa ta zasada do sprawdzania poprawności wiadomości SOAP. Prawidłowe wartości to: „1.1”. „1.2”. „1.1/1.2”.

version

Brak

Opcjonalnie

Wersja SOAP, której używa ta zasada do sprawdzania poprawności wiadomości SOAP.

Prawidłowe wartości to:

„1.1”.
„1.2”.
„1.1/1.2”.

Więcej informacji znajdziesz w artykule Przejście z wersji SOAP 1.1 na SOAP 1.2 w 9 punktach.

`<Source>`

Identyfikuje wiadomość źródłową, która ma zostać zweryfikowana. Jego wartość to nazwa wiadomości, którą chcesz zweryfikować.

Jeśli nie ustawisz wartości parametru <Source>, ta zasada zostanie domyślnie ustawiona na „message” (wiadomość), co oznacza pełną wiadomość żądania (w przepływie żądania) lub odpowiedź (w przepływie odpowiedzi), w tym ładunek. Możesz też ustawić go jako „request” (żądanie) lub „response” (odpowiedź), aby odwoływać się do żądania lub odpowiedzi.

Wartość domyślna	żądanie
Wymagany?	Opcjonalnie
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 wartości „message” (wiadomość), „request” (żądanie) i „response” (odpowiedź) możesz ustawić wartość <Source> na nazwę dowolnej wiadomości w Twoim przepływie. Jeśli to zrobisz, musisz utworzyć wiadomość niestandardową z tą nazwą w swojej ścieżce przed wykonaniem tej zasady. W przeciwnym razie pojawi się błąd.

Jeśli wartość <Source> nie może zostać rozwiązana w przepływie wiadomości lub jest typu innego niż wiadomość, występuje jedna z tych sytuacji:

Jeśli wartość jest pusta: przeglądarka Edge zwróci błąd steps.messagevalidation.SourceMessageNotAvailable.
Jeśli typ nie jest wiadomością: przeglądarka Edge zwraca 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 tabeli 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 zasad jest definiowany przez schemat XML (.xsd). Informacje na temat schematów zasad znajdziesz na GitHubie.

Zasada SOAPMessageValidation

Zasady weryfikacji wiadomości

Zalety

Filmy

Element <MessageValidation>

Składnia

Domyślne zasady

Przykłady

1. Walidacja XSD

2. Walidacja SOAP

3. Prawidłowo sformatowany kod XML/JSON

Odwołanie do elementu podrzędnego

<DisplayName>

Składnia

Przykład

<Element>

Składnia

Przykład 1

Przykład 2

<ResourceURL>

Składnia

Przykłady

Sprawdzanie poprawności za pomocą plików XSD

Używanie plików WSDL do sprawdzania poprawności

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