Чтобы переводить контент на ваш предпочитаемый язык, Google использует технологии на основе искусственного интеллекта. Переводы от ИИ могут содержать ошибки.

Правило SOAPMessageValidation

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

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

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

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

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

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

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

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

Видео

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

Видео	Описание
Проверка XML-запроса	Проверьте XML-запрос для API с помощью правила Message Validation.
Проверка запроса 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

Вы можете использовать правило Message Validation, чтобы проверить полезную нагрузку запроса 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 Message Validation в предварительный поток конечной точки прокси-сервера:
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

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

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

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

Чтобы проверить, правильно ли сформирована полезная нагрузка XML или JSON, выполните следующие действия:

Добавьте правило SOAP Message Validation в предварительный поток конечной точки прокси-сервера.
Удалите элементы <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-запроса.

Значение по умолчанию	sampleObject
Обязательно?	Необязательно
Тип	Строка
Родительский элемент	`<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, которую вы проверяете с помощью правила Message Validation, ссылается на другую схему, вы должны добавить префикс 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"

Дополнительную информацию можно найти в статье From SOAP/1.1 to SOAP Version 1.2 in 9 points.

`<Source>`

Определяет исходное сообщение, которое нужно проверить. Значение этого элемента – название сообщения, которое вы хотите проверить.

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

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

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

Синтаксис

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

Пример

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

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

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

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

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

Коды ошибок

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

This section describes the fault codes and error messages that are returned and fault variables that are set by Edge when this policy triggers an error. This information is important to know if you are developing fault rules to handle faults. To learn more, see What you need to know about policy errors and Handling faults.

Runtime errors

These errors can occur when the policy executes.

Fault code HTTP status Cause Fix

Fault code	HTTP status	Cause
`steps.messagevalidation.SourceMessageNotAvailable`	500	This error occurs if a variable specified in the `<Source>` element of the policy is either: out of scope (not available in the specific flow where the policy is being executed) or can't be resolved (is not defined)
`steps.messagevalidation.NonMessageVariable`	500	This error occurs if the `<Source>` element in the SOAPMessageValidation policy is set to a variable which is not of type message. Message type variables represent entire HTTP requests and responses. The built-in Edge flow variables `request`, `response`, and `message` are of type message. To learn more about message variables, see the Variables reference.
`steps.messagevalidation.Failed`	500	This error occurs if the SOAPMessageValidation policy fails to validate the input message payload against the XSD schema or WSDL definition. It will also occur if there is malformed JSON or XML in the payload message.

steps.messagevalidation.SourceMessageNotAvailable

500

This error occurs if a variable specified in the <Source> element of the policy is either:

out of scope (not available in the specific flow where the policy is being executed)
can't be resolved (is not defined)

steps.messagevalidation.NonMessageVariable

500

This error occurs if the <Source> element in the SOAPMessageValidation policy is set to a variable which is not of type message.

Message type variables represent entire HTTP requests and responses. The built-in Edge flow variables request, response, and message are of type message. To learn more about message variables, see the Variables reference.

steps.messagevalidation.Failed 500 This error occurs if the SOAPMessageValidation policy fails to validate the input message payload against the XSD schema or WSDL definition. It will also occur if there is malformed JSON or XML in the payload message.

Deployment errors

These errors can occur when you deploy a proxy containing this policy.

Error name	Cause	Fix
`InvalidResourceType`	The `<ResourceURL>` element in the SOAPMessageValidation policy is set to a resource type not supported by the policy.
`ResourceCompileFailed`	The resource script referenced in the `<ResourceURL>` element of the SOAPMessageValidation policy contains an error that prevents it from compiling.
`RootElementNameUnspecified`	The `<Element>` element in the SOAPMessageValidation policy does not contain the root element's name.
`InvalidRootElementName`	The `<Element>` element in the SOAPMessageValidation policy contains a root element name that does not adhere to XML rules for valid element naming.

Схемы

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

Правило SOAPMessageValidation

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

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

Видео

Элемент <MessageValidation>

Синтаксис

Правило по умолчанию

Примеры

1: проверка XSD

2. Проверка SOAP

3: правильно оформленный XML/JSON

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

<DisplayName>

Синтаксис

Пример

<Element>

Синтаксис

Пример 1

Пример 2

<ResourceURL>

Синтаксис

Примеры

Как использовать XSD для проверки

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

<SOAPMessage>

Синтаксис

Пример

<Source>

Синтаксис

Пример

Коды ошибок

Runtime errors

Deployment errors

Схемы

Статьи по теме

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

`<DisplayName>`

`<Element>`

`<ResourceURL>`

`<SOAPMessage>`

`<Source>`