Политика SOAPMessageValidation

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

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

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

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

Элемент <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.

  1. Создайте новый файл ресурсов 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>
  2. Добавьте политику проверки сообщений 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>
  3. Отправьте запрос 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.

  1. Создайте новый файл ресурсов WSDL. Например, "example-wsdl.wsdl":
  2. Добавьте политику проверки сообщений 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>
  3. Отправьте запрос 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:

  1. Добавьте политику проверки сообщений SOAP в предварительный поток конечной точки прокси-сервера.
  2. Удалите элементы <ResourceURL> , <SOAPMessage> и <Element> из определения политики.

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

    <MessageValidation async="false" continueOnError="false"
    enabled="true" name="validateXMLRequest">
  <DisplayName>My JSON Checker</DisplayName>
  <Properties/>
  <Source>request</Source>
</MessageValidation>
  3. Отправьте запрос 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"

Для получения дополнительной информации см. От SOAP/1.1 до SOAP версии 1.2 в 9 пунктах .

<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, имеют единый формат, описанный в справочнике по кодам ошибок .

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

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

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

Код неисправности Статус 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.

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

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

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

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

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

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

Код неисправности Статус 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.

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

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

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

Схемы

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

Похожие темы