Эта страница переведена с помощью Cloud Translation API.

Политика SOAPMessageValidation

Вы просматриваете документацию Apigee Edge .
Перейдите к документации Apigee X. информация

Политика SOAPMessageValidation выполняет следующие действия:

Проверяет любое XML-сообщение на соответствие его схемам XSD.
Проверяет сообщения SOAP на соответствие определению WSDL.
Определяет правильность формата сообщений JSON и XML.

Хотя название этой политики в пользовательском интерфейсе — «Проверка сообщений SOAP», эта политика проверяет не только сообщения SOAP. В этом разделе эта политика называется «политикой проверки сообщений».

О политике проверки сообщений

Преимущества

Проверка сообщения дает следующие преимущества:

Немедленно информирует разработчиков приложений, использующих ваш API, если их запросы не соответствуют требованиям или являются неполными.
Выявляет проблемы в запросах, например теги XML, которые не закрыты должным образом.
Защищает серверные службы , блокируя сообщения XML или SOAP с помощью структур, которые могут вызвать непредсказуемое поведение.
Сокращает время, затрачиваемое на устранение неполадок, поиск по форумам или консультации со службой технической поддержки.
Побуждает разработчиков ознакомиться с определением WSDL схемы XML, чтобы исключить ошибки проверки, что делает понятные схемы XML ключевым компонентом документации API.

Видео

Посмотрите следующие видеоролики, чтобы узнать больше о политике проверки сообщений:

Видео	Описание
Проверка XML-запроса	Проверьте запрос XML для API с помощью политики проверки сообщений.
Подтвердить запрос JSON	Проверьте запрос JSON для API с помощью политики проверки сообщений.

Элемент `<MessageValidation>`

Определяет политику проверки сообщений.

Значение по умолчанию	См. вкладку «Политика по умолчанию» ниже.
Необходимый?	Необязательный
Тип	Сложный объект
Родительский элемент	н/д
Дочерние элементы	`<DisplayName>` `<Element>` `<ResourceURL>` `<SOAPMessage>` `<Source>`

Синтаксис

Элемент <MessageValidation> использует следующий синтаксис:

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

Политика по умолчанию

В следующем примере показаны настройки по умолчанию при добавлении политики проверки сообщений в поток в пользовательском интерфейсе 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>

Этот элемент имеет следующие атрибуты, общие для всех политик:

Атрибут	По умолчанию	Необходимый?	Описание
`name`	Н/Д	Необходимый	Внутреннее имя политики. Значение атрибута `name` может содержать буквы, цифры, пробелы, дефисы, символы подчеркивания и точки. Это значение не может превышать 255 символов. При необходимости используйте элемент `<DisplayName>` , чтобы пометить политику в редакторе прокси-сервера пользовательского интерфейса управления другим именем на естественном языке.
`continueOnError`	ЛОЖЬ	Необязательный	Установите значение «false», чтобы возвращать ошибку при сбое политики. Это ожидаемое поведение для большинства политик. Установите значение «true», чтобы выполнение потока продолжалось даже после сбоя политики.
`enabled`	истинный	Необязательный	Установите значение «true», чтобы применить политику. Установите значение «false», чтобы «отключить» политику. Политика не будет применяться, даже если она остается присоединенной к потоку.
`async`	ЛОЖЬ	Устаревший	Этот атрибут устарел.

Примеры

В следующих примерах показаны некоторые способы использования политики проверки сообщений:

1: Проверка XSD

Вы можете использовать политику проверки сообщений для проверки полезных данных запроса XML-сообщения на соответствие схеме XSD.

Создайте новый файл ресурсов XSD. Например, «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>

Добавьте политику проверки сообщений SOAP в предварительный поток конечной точки прокси-сервера:
1. Укажите расположение файла ресурсов XSD с помощью элемента <ResourceURL> . Например:
```
...
  <ResourceURL>xsd://note-schema.xsd</ResourceURL>
...
```
2. Удалите элементы <SOAPMessage> и <Element> из определения политики.
Определение вашей политики должно выглядеть следующим образом:
```
<MessageValidation continueOnError="false"
    enabled="true" name="validateXMLRequest">
  <DisplayName>My XML Validator</DisplayName>
  <Properties/>
  <Source>request</Source>
  <ResourceURL>xsd://note-schema.xsd</ResourceURL>
</MessageValidation>
```
Отправьте запрос POST на свой прокси-сервер API, указав XML в качестве полезной нагрузки сообщения, как показано в следующем примере:
```
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>'
```
Обратите внимание, что для заголовка Content-type установлено значение «application/xml».
Вы также можете создать файл данных для полезной нагрузки и ссылаться на него с помощью команды, аналогичной следующей:
```
curl -v -X POST -H 'Content-type: application/xml' http://my-test.apigee.net/v1/xsd-mock
  --data '@../examples/note-payload.xml'
```

Вы должны получить ответ HTTP 200 . В зависимости от вашей целевой конечной точки вы можете получить дополнительные сведения о запросе. Например, если вы используете http://httpbin.org/post в качестве целевой конечной точки и указываете вывод -v (подробный), ответ должен быть похож на следующий:

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

Чтобы убедиться, что ваша проверка XSD работает, попробуйте вставить другой тег в тело вашего запроса. Например:

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

Вы должны получить ошибку проверки.

2. Проверка SOAP

Вы можете использовать политику проверки сообщений для проверки полезных данных запроса сообщения SOAP на соответствие WSDL.

Создайте новый файл ресурсов WSDL. Например, «example-wsdl.wsdl»:

Посмотреть полный 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>

Добавьте политику проверки сообщений SOAP в предварительный поток конечной точки прокси-сервера:
1. Задайте для атрибута version элемента <SOAPMessage> версию протокола SOAP, проверку которого вы хотите выполнить. Например, «1.1»:
```
...
  <SOAPMessage version="1.1"/>
...
```
2. Установите значение элемента <Element> для элемента, который вы хотите проверить:
```
...
  <Element namespace="https://example.com/gateway">getID</Element>
...
```
  <Element> указывает первого дочернего элемента элемента <Body> в конверте запроса SOAP.
  Установите атрибут namespace в пространство имен для этого дочернего элемента.
3. Укажите расположение файла ресурсов WSDL с помощью элемента <ResourceURL> . Например:
```
...
  <ResourceURL>wsdl://example-wsdl.wsdl</ResourceURL>
...
```
Определение вашей политики должно выглядеть следующим образом:
```
<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>
```
Отправьте запрос POST на прокси-сервер API с конвертом SOAP в качестве полезной нагрузки сообщения, как показано в следующем примере:
```
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>'
```
Обратите внимание, что для заголовка Content-type установлено значение «application/xml».
Вы также можете создать файл данных для полезной нагрузки и ссылаться на него с помощью команды, аналогичной следующей:
```
curl -v -X POST -H 'Content-type: application/xml' http://my-test.apigee.net/v1/xsd-mock
  --data '@../examples/soap-payload.xml'
```

Вы должны получить ответ HTTP 200 . В зависимости от вашей целевой конечной точки вы можете получить дополнительные сведения о запросе. Например, если вы используете http://httpbin.org/post в качестве целевой конечной точки, ответ должен быть похож на следующий:

< 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

Вы можете использовать политику проверки сообщений, чтобы убедиться, что полезные данные сообщения JSON или XML правильно сформированы (это не то же самое, что проверка ). Политика гарантирует, что структура и содержание соответствуют принятым стандартам, в том числе:

Существует один корневой элемент
В контенте нет нелегальных символов.
Объекты и теги правильно вложены
Начальный и конечный теги совпадают.

Чтобы проверить правильность формата полезных данных XML или JSON:

Добавьте политику проверки сообщений SOAP в предварительный поток конечной точки прокси-сервера.
Удалите элементы <ResourceURL> , <SOAPMessage> и <Element> из определения политики.
Определение вашей политики должно выглядеть следующим образом:
```
<MessageValidation async="false" continueOnError="false"
    enabled="true" name="validateXMLRequest">
  <DisplayName>My JSON Checker</DisplayName>
  <Properties/>
  <Source>request</Source>
</MessageValidation>
```
Отправьте запрос POST на свой прокси-сервер API, как показано в следующем примере:
```
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."
  }
}'
```
Обратите внимание, что для заголовка Content-type установлено значение «application/json».
Чтобы проверить XML-файл на правильность формата, используйте XML в качестве полезных данных сообщения и задайте для Content-type значение «application/xml».

Вы должны получить ответ HTTP 200 . Когда вы отправляете полезные данные сообщения, которые не содержат корректного XML или JSON, вы должны получить ошибку steps.messagevalidation.Failed .

Ссылка на дочерний элемент

В этом разделе описаны дочерние элементы <MessageValidation> .

`<DisplayName>`

Используйте в дополнение к атрибуту name , чтобы пометить политику в редакторе прокси-сервера пользовательского интерфейса управления другим, более естественным именем.

Элемент <DisplayName> является общим для всех политик.

Значение по умолчанию	н/д
Необходимый?	Необязательный. Если вы опустите `<DisplayName>` , будет использовано значение атрибута `name` политики.
Тип	Нить
Родительский элемент	< `PolicyElement` >
Дочерние элементы	Никто

Элемент <DisplayName> использует следующий синтаксис:

Синтаксис

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

Пример

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

Элемент <DisplayName> не имеет атрибутов или дочерних элементов.

`<Element>`

Указывает элемент сообщения для проверки. Это первый дочерний элемент элемента <Body> в конверте запроса SOAP.

Значение по умолчанию	образецОбъект
Необходимый?	Необязательный
Тип	Нить
Родительский элемент	`<MessageValidation>`
Дочерние элементы	Никто

Элемент <Element> использует следующий синтаксис:

Синтаксис

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

Пример 1

В следующем примере определяется один проверяемый элемент:

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

Пример 2

Вы можете указать более одного элемента для проверки, добавив несколько элементов <Element> :

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

Элемент <Element> имеет следующие атрибуты:

Атрибут	По умолчанию	Необходимый?	Описание
`namespace`	"http://sample.com"	Необязательный	Определяет пространство имен проверяемого элемента.

`<ResourceURL>`

Идентифицирует схему XSD или определение WSDL, которые будут использоваться для проверки исходного сообщения.

Значение по умолчанию	wsdl:// `display_name` .wsdl
Необходимый?	Необязательный
Тип	Нить
Родительский элемент	`<MessageValidation>`
Дочерние элементы	Никто

Элемент <ResourceURL> использует следующий синтаксис:

Синтаксис

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

Примеры

Для XML-файла:

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

Для WSDL:

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

Значение <ResourceURL> должно указывать на файл ресурсов в вашем прокси-сервере API. Он не может ссылаться на внешние ресурсы через HTTP или HTTPS.

Если вы не укажете значение для <ResourceURL> , сообщение проверяется на правильность формата JSON или XML, если заголовок Content-type имеет значение «application/json» или «application/xml» соответственно.

Элемент <ResourceURL> не имеет дочерних элементов или атрибутов.

Использование XSD для проверки

Если полезные данные XML, которые вы проверяете с помощью политики проверки сообщений, ссылаются на другую схему, вы должны добавить к включенному файлу XSD префикс xsd в атрибуте schemaLocation .

Следующий пример схемы состоит из нескольких 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>

Использование WSDL для проверки

WSDL должен определять хотя бы одну схему. Если она не ссылается хотя бы на одну схему, политика проверки сообщения не выполняется.

Максимальная глубина импорта для схемы — 10. Если вы превысите это количество вложенных импортов, политика проверки сообщений завершится сбоем.

`<SOAPMessage>`

Определяет версию SOAP, по которой проверяется политика проверки сообщений.

Значение по умолчанию	н/д
Необходимый?	Необязательный
Тип	н/д
Родительский элемент	`<MessageValidation>`
Дочерние элементы	Никто

Элемент <SOAPMessage> использует следующий синтаксис:

Синтаксис

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

Пример

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

Элемент <SOAPMessage> имеет следующие атрибуты:

Атрибут По умолчанию Необходимый? Описание

Атрибут	По умолчанию	Необходимый?	Описание
`version`	Никто	Необязательный	Версия SOAP, которую эта политика использует для проверки сообщений SOAP. Допустимые значения: "1,1" "1,2" «1,1/1,2»

version

Никто

Необязательный

Версия SOAP, которую эта политика использует для проверки сообщений SOAP.

Допустимые значения:

"1,1"
"1,2"
«1,1/1,2»

Дополнительную информацию см. в разделе «От SOAP/1.1 к SOAP версии 1.2 в 9 пунктах» .

`<Source>`

Идентифицирует исходное сообщение, которое необходимо проверить. Значением этого элемента является имя сообщения, которое вы хотите проверить.

Если вы не задали <Source> , эта политика по умолчанию имеет значение «сообщение», которое относится к полному сообщению запроса (в потоке запросов) или ответному сообщению (в потоке ответов), включая любую полезную нагрузку. Вы также можете явно установить для него значение «запрос» или «ответ», чтобы ссылаться на запрос или ответ.

Значение по умолчанию	запрос
Необходимый?	Необязательный
Тип	Нить
Родительский элемент	`<MessageValidation>`
Дочерние элементы	Никто

Элемент <Source> использует следующий синтаксис:

Синтаксис

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

Пример

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

Помимо «сообщения», «запроса» и «ответа», вы можете установить значение <Source> для имени любого сообщения в вашем потоке. Однако если вы это сделаете, вам необходимо создать настраиваемое сообщение с таким именем в своем потоке, прежде чем эта политика будет выполнена. В противном случае вы получите ошибку.

Если значение <Source> не может быть разрешено в потоке сообщений или преобразуется в тип, не являющийся сообщением, происходит одно из следующих событий:

Если нулевое значение: Edge выдает ошибку steps.messagevalidation.SourceMessageNotAvailable .
Если тип не-сообщения: Edge выдает ошибку steps.messagevalidation.NonMessageVariable .

Элемент <Source> не имеет атрибутов или дочерних элементов.

Коды ошибок

Ошибки, возвращаемые политиками Edge, имеют единообразный формат, как описано в справочнике по кодам ошибок .

В этом разделе описаны коды ошибок и сообщения об ошибках, которые возвращаются, а также переменные ошибок, которые устанавливаются Edge, когда эта политика вызывает ошибку. Эту информацию важно знать, если вы разрабатываете правила обработки ошибок. Дополнительные сведения см. в разделах Что нужно знать об ошибках политики и Обработка ошибок .

Ошибки выполнения

Эти ошибки могут возникнуть при выполнении политики.

Код неисправности Статус HTTP Причина Исправить

Код неисправности	Статус HTTP	Причина
`steps.messagevalidation.SourceMessageNotAvailable`	500	Эта ошибка возникает, если переменная, указанная в элементе `<Source>` политики: вне области действия (недоступно в конкретном потоке, в котором выполняется политика) или не может быть решено (не определено)
`steps.messagevalidation.NonMessageVariable`	500	Эта ошибка возникает, если для элемента `<Source>` в политике SOAPMessageValidation установлена переменная, которая не имеет типа message . Переменные типа сообщения представляют собой все HTTP-запросы и ответы. Встроенные переменные потока Edge `request` , `response` и `message` имеют тип message. Дополнительные сведения о переменных сообщения см. в справочнике по переменным .
`steps.messagevalidation.Failed`	500	Эта ошибка возникает, если политике SOAPMessageValidation не удается проверить полезную нагрузку входного сообщения на соответствие схеме XSD или определению WSDL. Это также произойдет, если в сообщении полезной нагрузки имеется неверный формат JSON или XML.

steps.messagevalidation.SourceMessageNotAvailable

500

Эта ошибка возникает, если переменная, указанная в элементе <Source> политики:

вне области действия (недоступно в конкретном потоке, в котором выполняется политика)
не может быть решено (не определено)

steps.messagevalidation.NonMessageVariable

500

Эта ошибка возникает, если для элемента <Source> в политике SOAPMessageValidation установлена переменная, которая не имеет типа message .

Переменные типа сообщения представляют собой все HTTP-запросы и ответы. Встроенные переменные потока Edge request , response и message имеют тип message. Дополнительные сведения о переменных сообщения см. в справочнике по переменным .

steps.messagevalidation.Failed 500 Эта ошибка возникает, если политике SOAPMessageValidation не удается проверить полезную нагрузку входного сообщения на соответствие схеме XSD или определению WSDL. Это также произойдет, если в сообщении полезной нагрузки имеется неверный формат JSON или XML.

Ошибки развертывания

Эти ошибки могут возникнуть при развертывании прокси-сервера, содержащего эту политику.

Название ошибки	Причина	Исправить
`InvalidResourceType`	Элементу `<ResourceURL>` в политике SOAPMessageValidation присвоен тип ресурса, не поддерживаемый этой политикой.
`ResourceCompileFailed`	Сценарий ресурса, указанный в элементе `<ResourceURL>` политики SOAPMessageValidation, содержит ошибку, препятствующую его компиляции.
`RootElementNameUnspecified`	Элемент `<Element>` в политике SOAPMessageValidation не содержит имени корневого элемента.
`InvalidRootElementName`	Элемент `<Element>` в политике SOAPMessageValidation содержит имя корневого элемента, которое не соответствует правилам XML для допустимого именования элементов.

Ошибки выполнения

Эти ошибки могут возникнуть при выполнении политики.

Код неисправности Статус HTTP Причина Исправить

Код неисправности	Статус HTTP	Причина
`steps.messagevalidation.SourceMessageNotAvailable`	500	Эта ошибка возникает, если переменная, указанная в элементе `<Source>` политики: вне области действия (недоступно в конкретном потоке, в котором выполняется политика) или не может быть решено (не определено)
`steps.messagevalidation.NonMessageVariable`	500	Эта ошибка возникает, если для элемента `<Source>` в политике SOAPMessageValidation установлена переменная, которая не имеет типа message . Переменные типа сообщения представляют собой все HTTP-запросы и ответы. Встроенные переменные потока Edge `request` , `response` и `message` имеют тип message. Дополнительные сведения о переменных сообщения см. в справочнике по переменным .
`steps.messagevalidation.Failed`	500	Эта ошибка возникает, если политике SOAPMessageValidation не удается проверить полезную нагрузку входного сообщения на соответствие схеме XSD или определению WSDL. Это также произойдет, если в сообщении полезной нагрузки имеется неверный формат JSON или XML.

steps.messagevalidation.SourceMessageNotAvailable

500

Эта ошибка возникает, если переменная, указанная в элементе <Source> политики:

вне области действия (недоступно в конкретном потоке, в котором выполняется политика)
не может быть решено (не определено)

steps.messagevalidation.NonMessageVariable

500

Ошибки развертывания

Эти ошибки могут возникнуть при развертывании прокси-сервера, содержащего эту политику.

Название ошибки	Причина	Исправить
`InvalidResourceType`	Элементу `<ResourceURL>` в политике SOAPMessageValidation присвоен тип ресурса, не поддерживаемый этой политикой.
`ResourceCompileFailed`	Сценарий ресурса, указанный в элементе `<ResourceURL>` политики SOAPMessageValidation, содержит ошибку, препятствующую его компиляции.
`RootElementNameUnspecified`	Элемент `<Element>` в политике SOAPMessageValidation не содержит имени корневого элемента.
`InvalidRootElementName`	Элемент `<Element>` в политике SOAPMessageValidation содержит имя корневого элемента, которое не соответствует правилам XML для допустимого именования элементов.

Схемы

Каждый тип политики определяется схемой XML ( .xsd ). Для справки: схемы политик доступны на GitHub.

Политика SOAPMessageValidation

О политике проверки сообщений

Преимущества

Видео

Элемент <MessageValidation>

Синтаксис

Политика по умолчанию

Примеры

1: Проверка XSD

2. Проверка SOAP

3. Правильно сформированный XML/JSON

Ссылка на дочерний элемент

<DisplayName>

Синтаксис

Пример

<Element>

Синтаксис

Пример 1

Пример 2

<ResourceURL>

Синтаксис

Примеры

Использование XSD для проверки

Использование WSDL для проверки

<SOAPMessage>

Синтаксис

Пример

<Source>

Синтаксис

Пример

Коды ошибок

Ошибки выполнения

Ошибки развертывания

Ошибки выполнения

Ошибки развертывания

Схемы

Связанные темы

Элемент `<MessageValidation>`

`<DisplayName>`

`<Element>`

`<ResourceURL>`

`<SOAPMessage>`

`<Source>`