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

Zasada SOAPMessageValidation

Wyświetlasz dokumentację Apigee Edge.
Zapoznaj się z dokumentacją Apigee X. info

Zasada SOAPMessageValidation wykonuje te czynności:

Sprawdza, czy dowolna wiadomość XML jest zgodna ze schematami XSD.
Weryfikuje komunikaty SOAP na podstawie definicji WSDL.
Określa poprawność formatu komunikatów JSON i XML.

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

Informacje o zasadach weryfikacji wiadomości

Zalety

Weryfikacja wiadomości zapewnia te korzyści:

Natychmiast informuje deweloperów aplikacji korzystających z Twojego interfejsu API, czy ich żądania są niezgodne lub niekompletne.
Wskazuje problemy w żądaniach, np. nieprawidłowo zamknięte tagi XML.
Chroni usługi backendu, blokując wiadomości XML lub SOAP o strukturach, które mogą powodować nieprzewidywalne zachowania.
Skraca czas potrzebny na rozwiązywanie problemów, przeszukiwanie forów lub konsultacje z zespołem pomocy technicznej.
Zachęca deweloperów do zapoznania się z definicją schematu XML WSDL, aby wyeliminować błędy weryfikacji. Dzięki temu dobrze znane 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
Sprawdzanie poprawności żądania XML	Sprawdź żądanie XML do interfejsu API za pomocą zasady weryfikacji wiadomości.
Sprawdzanie poprawności żądania JSON	Sprawdź poprawność żądania JSON do interfejsu API za pomocą zasady weryfikacji wiadomości.

Element `<MessageValidation>`

Definiuje zasady weryfikacji wiadomości.

Wartość domyślna	Patrz karta Zasady domyślne poniżej.
Wymagany?	Opcjonalny
Typ	Obiekt złożony
Element nadrzędny	nie dotyczy
Elementy podrzędne	`<DisplayName>` `<Element>` `<ResourceURL>` `<SOAPMessage>` `<Source>`

Składnia

Element <MessageValidation> ma tę 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

Poniższy przykład pokazuje ustawienia domyślne po dodaniu do przepływu w interfejsie Edge zasady 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ższe przykłady pokazują, jak możesz używać zasad weryfikacji wiadomości:

1. Weryfikacja XSD

Za pomocą zasady weryfikacji wiadomości możesz zweryfikować ładunek żą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 wiadomości SOAP do wstępnego przepływu punktu końcowego serwera 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 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 szczegóły dotyczące żądania. 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ć podobnie do tej:

< 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. Sprawdzanie poprawności SOAP

Za pomocą zasady weryfikacji wiadomości możesz zweryfikować ładunek żądania wiadomości SOAP w odniesieniu do pliku WSDL.

Utwórz nowy plik zasobu 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ę weryfikacji wiadomości SOAP do wstępnego przepływu punktu końcowego proxy:
1. Ustaw atrybut version elementu <SOAPMessage> na wersję protokołu SOAP, pod kątem której chcesz przeprowadzić weryfikację. Na przykład: „1.1”:
```
...
  <SOAPMessage version="1.1"/>
...
```
2. Ustaw wartość elementu <Element> na element, który chcesz sprawdzić:
```
...
  <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 dziecka.
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 do serwera proxy interfejsu API żądanie POST 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 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 szczegóły dotyczące żądania. Jeśli na przykład używasz punktu końcowego 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łowy format XML/JSON

Za pomocą zasady weryfikacji wiadomości możesz sprawdzić, czy ładunek wiadomości JSON lub XML jest prawidłowo sformatowany (nie jest to to samo co weryfikacja). Zasady te zapewniają, że struktura i treść spełniają przyjęte standardy, w tym:

ma jeden element główny,
Treść nie zawiera niedozwolonych znaków
Obiekty i tagi są prawidłowo zagnieżdżone.
Tagi otwierający i zamykający pasują do siebie.

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

Dodaj zasadę weryfikacji wiadomości SOAP do wstępnego przepływu punktu końcowego 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ć, 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łowego 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>`

Używaj tego atrybutu w połączeniu z atrybutem name, aby oznaczyć zasadę w edytorze proxy interfejsu zarządzania inną, bardziej naturalnie brzmiącą nazwą.

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

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

Element <DisplayName> ma tę 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 do sprawdzenia. Jest to pierwszy element podrzędny elementu <Body> w kopercie żądania SOAP.

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

Element <Element> ma tę składnię:

Składnia

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

Przykład 1

Poniższy przykład określa pojedynczy element do zweryfikowania:

...
<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 weryfikowania wiadomości źródłowej.

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

Element <ResourceURL> ma tę 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 Twoim serwerze proxy interfejsu API. Nie może odwoływać się do zewnętrznych zasobów przez HTTP ani HTTPS.

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

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

Używanie plików XSD do weryfikacji

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

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 weryfikacji

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

Maksymalna głębokość importu schematu to 10. Jeśli przekroczysz tę liczbę zagnieżdżonych importów, zasady weryfikacji wiadomości nie zostaną spełnione.

`<SOAPMessage>`

Określa wersję protokołu SOAP, w odniesieniu do której zasady weryfikacji wiadomości przeprowadzają weryfikację.

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

Element <SOAPMessage> ma tę 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 weryfikowania wiadomości 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 weryfikowania wiadomości 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 (w języku angielskim).

`<Source>`

Określa 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 parametru <Source>, ta zasada domyślnie przyjmie wartość „message”, która odnosi się do pełnej wiadomości z żądaniem (w przypadku przepływu żądania) lub wiadomości z odpowiedzią (w przypadku przepływu odpowiedzi), w tym do dowolnego ładunku. Możesz też ustawić go na „request” lub „response”, aby odwoływać się do żądania lub odpowiedzi.

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

Element <Source> ma tę składnię:

Składnia

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

Przykład

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

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

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

Jeśli wartość to null: Edge zgłasza błąd steps.messagevalidation.SourceMessageNotAvailable.
Jeśli typ nie jest typem 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 zasad jest zdefiniowany przez schemat XML (.xsd). Schematy zasad są dostępne na GitHubie.

Zasada SOAPMessageValidation

Informacje o zasadach weryfikacji wiadomości

Zalety

Filmy

Element <MessageValidation>

Składnia

Domyślne zasady

Przykłady

1. Weryfikacja XSD

2. Sprawdzanie poprawności SOAP

3. Prawidłowy format 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

Używanie plików XSD do weryfikacji

Używanie plików WSDL do weryfikacji

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