Политика ExtractVariables

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

Что

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

Хотя вы часто используете эту политику для извлечения информации из сообщения запроса или ответа, вы также можете использовать ее для извлечения информации из других источников, включая сущности, созданные политикой AccessEntity , объекты XML или объекты JSON.

После извлечения указанного содержимого сообщения вы можете ссылаться на переменную в других политиках в рамках обработки запроса и ответа.

Видео

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

Видео Описание
Извлечение переменных из полезных данных XML Извлеките переменные из полезных данных XML с помощью политики извлечения переменных.
Извлечение переменных из полезных данных JSON Извлеките переменные из полезных данных JSON, используя политику извлечения переменных.
Извлечение переменных из параметров Извлекайте переменные из параметров, таких как параметры запроса, заголовка, формы или URI.
Извлечение переменных из многозначных параметров Извлечение переменных из многозначных параметров.
Извлечение переменных из параметра запроса (Classic Edge) Извлеките переменные из параметра запроса с помощью классического пользовательского интерфейса Edge.
Извлечение переменных из полезных данных XML или JSON (Classic Edge) Извлекайте переменные из полезных данных XML или JSON с помощью классического пользовательского интерфейса Edge.

Образцы

Эти примеры кода политики иллюстрируют, как извлечь переменные из следующих типов артефактов:

GitHub

Эти ссылки указывают на рабочие образцы прокси-серверов API, которые вы можете развернуть и запустить в Edge. Они используют ExtractVariables и расположены в репозитории API-платформы-образцов Apigee на GitHub. В файлах README объясняется, как ExtractVariables используется в каждом случае, а также как развертывать и запускать каждый образец.

URI

<ExtractVariables name="ExtractVariables-1">
   <DisplayName>Extract a portion of the url path</DisplayName>
   <Source>request</Source>
   <URIPath>
      <Pattern ignoreCase="true">/accounts/{id}</Pattern>
   </URIPath>
   <VariablePrefix>urirequest</VariablePrefix>
   <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
</ExtractVariables>

Рассмотрим пример кода политики, приведенный выше. Элемент <URIPath> сообщает политике ExtractVariables извлекать информацию из пути URI. Элемент <Pattern> определяет шаблон, который будет применяться к пути URI. Шаблон рассматривается как простой шаблон, в котором фигурные скобки обозначают изменяющуюся часть пути URI.

Имя устанавливаемой переменной определяется значением, указанным в элементе <VariablePrefix> , а также значением, заключенным в фигурные скобки {} в элементе <Pattern> . Эти два значения соединяются промежуточной точкой, в результате чего, например, получается имя переменной urirequest.id . Если элемент <VariablePrefix> отсутствует, то имя переменной — это просто значение, заключенное в фигурные скобки.

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

GET http://org1-test.apigee.net/svc1/accounts/12797282

Предположим, что базовый путь для прокси-сервера API — /svc1 . Когда Apigee Edge применяет приведенный выше код политики ExtractVariables к этому входящему запросу, он устанавливает для переменной urirequest.id значение 12797282 . После того как Apigee Edge выполнит политику, последующие политики или код в потоке обработки могут обратиться к переменной с именем urirequest.id , чтобы получить строковое значение 12797282 .

Например, следующая политика AssignMessage встраивает значение этой переменной в полезные данные нового сообщения запроса:

<AssignMessage async="false" continueOnError="false" enabled="true" name="AssignPayload">
 <DisplayName>AssignPayload</DisplayName>
  <Set>
   <Payload contentType="text/xml">
    <IdExtractedFromURI>{urirequest.id}</IdExtractedFromURI>
   </Payload>
  </Set>
  <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
  <AssignTo createNew="true" transport="http" type="request">newRequest</AssignTo>
</AssignMessage>

Параметры запроса

<ExtractVariables name="ExtractVariables-2">
   <DisplayName>Extract a value from a query parameter</DisplayName>
   <Source>request</Source>
   <QueryParam name="code">
      <Pattern ignoreCase="true">DBN{dbncode}</Pattern>
   </QueryParam>
   <VariablePrefix>queryinfo</VariablePrefix>
   <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
</ExtractVariables>

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

GET http://org1-test.apigee.net/accounts/12797282?code=DBN88271

Когда Apigee Edge применяет приведенный выше код политики ExtractVariables к этому входящему запросу, он устанавливает для переменной queryinfo.dbncode значение 88271 . После того как Apigee Edge выполнит политику, последующие политики или код в потоке обработки могут обратиться к переменной с именем queryinfo.dbncode , чтобы получить строковое значение 88271 .

Теперь вы можете получить доступ к переменной queryinfo.dbncode в своем прокси. Например, следующая политика AssignMessage копирует его в полезные данные запроса:

<AssignMessage async="false" continueOnError="false" enabled="true" name="GetURIPath">
 <DisplayName>GetQP</DisplayName>
  <Set>
   <Payload contentType="text/xml">
    <ExtractQP>{queryinfo.dbncode}</ExtractQP>
   </Payload>
  </Set>
  <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
  <AssignTo createNew="false" transport="http" type="request"/>
</AssignMessage>

Несколько параметров

<ExtractVariables name="ExtractVariables-2">
   <DisplayName>Extract a value from a query parameter</DisplayName>
   <Source>request</Source>
   <QueryParam name="w">
      <Pattern ignoreCase="true">{firstWeather}</Pattern>
   </QueryParam>
   <QueryParam name="w.2">
     <Pattern ignoreCase="true">{secondWeather}</Pattern>
   </QueryParam>
   <VariablePrefix>queryinfo</VariablePrefix>
 <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
</ExtractVariables>

Предположим, ваш дизайн API позволяет вам указывать несколько параметров запроса с одним и тем же именем. Эту политику можно использовать для извлечения значения нескольких экземпляров параметра запроса «w». Для ссылки на эти параметры запроса в политике ExtractVariables вы используете индексы, где первый экземпляр параметра запроса не имеет индекса, второй имеет индекс 2, третий — индекс 3 и т. д.

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

GET http://org1-test.apigee.net/weather?w=Boston&w=Chicago

Когда Apigee Edge применяет приведенный выше код политики ExtractVariables к этому входящему запросу, он устанавливает для переменной queryinfo.firstWeather значение Boston , а для переменной queryInfo.secondWeather . SecondWeather — значение Chicago .

Теперь вы можете получить доступ к переменным queryinfo.firstWeather и queryinfo. SecondWeather в своем прокси. Например, следующая политика AssignMessage копирует его в полезные данные запроса:

<AssignMessage async="false" continueOnError="false" enabled="true" name="GetURIPath">
 <DisplayName>GetQP</DisplayName>
  <Set>
   <Payload contentType="text/xml">
    <ExtractQP1>{queryinfo.firstWeather}</ExtractQP1>
    <ExtractQP2>{queryinfo.secondWeather}</ExtractQP2>
   </Payload>
  </Set>
  <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
  <AssignTo createNew="false" transport="http" type="request"/>
</AssignMessage>

Заголовки

<ExtractVariables name='ExtractVariable-OauthToken'>
  <Source>request</Source>
  <Header name="Authorization">
    <Pattern ignoreCase="false">Bearer {oauthtoken}</Pattern>
  </Header>
  <VariablePrefix>clientrequest</VariablePrefix>
  <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
</ExtractVariables>

Предположим, что ваш API использует токены носителя OAuth v2.0. Рассмотрим приведенный выше пример кода политики, работающий с запросом, содержащим токен OAuth v2.0, который включает в себя такой заголовок: Authorization: Bearer TU08xptfFfeM7aS0xHqlxTgEAdAM.

Предположим, что вы как разработчик API хотите использовать значение токена (но не весь заголовок) в качестве ключа при поиске в кэше. Вы можете использовать приведенный выше код политики ExtractVariables для извлечения токена.

Когда Apigee Edge применяет приведенный выше код политики ExtractVariables к этому заголовку, он устанавливает для переменной clientrequest.oauthtoken значение TU08xptfFfeM7aS0xHqlxTgEAdAM .

Теперь вы можете получить доступ к переменной clientrequest.oauthtoken в своем прокси. Например, следующая политика AssignMessage копирует его в полезные данные запроса:

<AssignMessage async="false" continueOnError="false" enabled="true" name="GetURIPath">
 <DisplayName>GetHeader</DisplayName>
  <Set>
   <Payload contentType="text/xml">
    <ExtractHeader>{clientrequest.oauthtoken}</ExtractHeader>
   </Payload>
  </Set>
  <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
  <AssignTo createNew="false" transport="http" type="request"/>
</AssignMessage>

JSON

<ExtractVariables name="ExtractVariables-3">
   <Source>response</Source>
   <JSONPayload>
      <Variable name="latitude" type="float">
         <JSONPath>$.results[0].geometry.location.lat</JSONPath>
      </Variable>
      <Variable name="longitude" type="float">
         <JSONPath>$.results[0].geometry.location.lng</JSONPath>
      </Variable>
   </JSONPayload>
   <VariablePrefix>geocoderesponse</VariablePrefix>
</ExtractVariables>
<JSONPayload> $

Рассмотрим следующую полезную нагрузку ответа JSON:

{
  "results": [{
    "geometry": {
      "location": {
        "lat": 37.42291810,
        "lng": -122.08542120
      },
      "location_type": "ROOFTOP",
      "viewport": {
        "northeast": {
          "lat": 37.42426708029149,
          "lng": -122.0840722197085
        },
        "southwest": {
          "lat": 37.42156911970850,
          "lng": -122.0867701802915
        }
      }
    }
  }]
}

Когда Apigee Edge применяет приведенный выше код политики ExtractVariables к этому сообщению JSON, он устанавливает две переменные: geocoderesponse.latitude и geocoderesponse.longitude . Обе переменные используют один и тот же префикс переменной geocoderesponse . Суффикс для этих переменных указывается явно атрибутом name элемента <Variable> .

Переменная geocoderesponse.latitude получает значение 37.42291810 . Переменная geocoderesponse.longitude получает значение -122.08542120 .

Теперь вы можете получить доступ к переменной geocoderesponse.latitude в своем прокси. Например, следующая политика AssignMessage копирует его в заголовок с именем «latitude» в ответе:

<AssignMessage async="false" continueOnError="false" enabled="true" name="GetURIPath">
  <DisplayName>GetJSONVar</DisplayName>
  <Add>
    <Headers>
      <Header name="latitude">{geocoderesponse.latitude}</Header>
    </Headers>
  </Add> 
  <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
  <AssignTo createNew="false" transport="http" type="response"/> 
</AssignMessage>

XML

<ExtractVariables name="ExtractVariables-4">
   <Source>response</Source>
   <XMLPayload>
      <Namespaces>
         <Namespace prefix="dir">urn:43BFF88D-D204-4427-B6BA-140AF393142F</Namespace>
      </Namespaces>
      <Variable name="travelmode" type="string">
         <XPath>/dir:Directions/dir:route/dir:leg/dir:step/@mode</XPath>
      </Variable>
      <Variable name="duration" type="string">
         <XPath>/dir:Directions/dir:route/dir:leg/dir:step/dir:duration/dir:value</XPath>
      </Variable>
      <Variable name="timeunit" type="string">
         <XPath>/dir:Directions/dir:route/dir:leg/dir:step/dir:duration/dir:text</XPath>
      </Variable>
   </XMLPayload>
   <VariablePrefix>directionsresponse</VariablePrefix>
</ExtractVariables>
<XMLPayload>

Рассмотрим следующую полезную нагрузку ответа XML:

<Directions xmlns="urn:43BFF88D-D204-4427-B6BA-140AF393142F">
   <status>OK</status>
   <route>
      <summary>I-40 W</summary>
      <leg>
         <step mode="DRIVING">
            <start_location>
               <lat>41.8507300</lat>
               <lng>-87.6512600</lng>
            </start_location>
            <end_location>
               <lat>41.8525800</lat>
               <lng>-87.6514100</lng>
            </end_location>
            <duration>
                <value>19</value>
                <text>minutes</text>
            </duration>
         </step>
      </leg>
   </route>
</Directions>

Когда Apigee Edge применяет приведенный выше код политики ExtractVariables к этому XML-сообщению, он устанавливает три переменные: directionsresponse.travelmode, directionsresponse.duration и directionsresponse.timeunit . Все переменные используют один и тот же префикс directionsresponse . Суффикс этих переменных явно указывается в атрибуте name элемента <Variable> .

Переменная directionsresponse.travelmode получает значение DRIVING . Переменная directionsresponse.duration получает значение 19 . Переменная directionsresponse.timeunit получает значение minutes .

Теперь вы можете получить доступ к переменной directionresponse.travelmode в своем прокси. Например, следующая политика AssignMessage копирует его в заголовок с именем «tmode» в ответе:

<AssignMessage async="false" continueOnError="false" enabled="true" name="GetURIPath">
  <DisplayName>GetXMLVar</DisplayName>
  <Add>
    <Headers>
      <Header name="tmode">{directionsresponse.travelmode}</Header>
    </Headers>
  </Add>
  <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
  <AssignTo createNew="false" transport="http" type="request"/>
</AssignMessage>

О политике ExtractVariables

Разработчики API создают прокси-серверы API, которые ведут себя по-разному в зависимости от содержимого сообщений, включая заголовки, пути URI, полезные данные и параметры запроса. Часто прокси извлекает некоторую часть этого содержимого для использования в операторе условия. Для этого используйте политику ExtractVariables.

При определении политики ExtractVariables вы можете выбрать:

  • Имена переменных, которые необходимо установить
  • Источник переменных
  • Сколько переменных извлечь и установить

При выполнении политика применяет текстовый шаблон к содержимому и, обнаружив совпадение, устанавливает значение назначенной переменной с содержимым. Другие политики и код могут затем использовать эти переменные для обеспечения динамического поведения или отправки бизнес-данных в Edge API Analytics.

Чтобы узнать, как можно использовать ExtractVariables для создания отчетов Analytics на основе контента, см. раздел Анализ содержимого сообщений API с помощью пользовательской аналитики .

Объем

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

О сопоставлении и создании переменных

Политика ExtractVariables извлекает информацию из запроса или ответа и записывает эту информацию в переменную. Для каждого типа информации, которую вы можете извлечь, например пути URI или данных XML, вы указываете соответствующий шаблон и имя переменной, используемой для хранения извлеченной информации.

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

Сопоставление путей URI, параметров запроса, заголовков, параметров формы и переменных.

При извлечении информации из пути URI, параметров запроса, заголовков, параметров формы и переменных вы используете тег <Pattern> , чтобы указать один или несколько шаблонов для сопоставления. Например, в следующем примере политики показан один шаблон соответствия для пути URI:

<ExtractVariables name="ExtractVariables-1">
   <Source>request</Source>
   <URIPath>
      <Pattern ignoreCase="true">/a/{pathSeg}</Pattern>
   </URIPath>
   <VariablePrefix>urirequest</VariablePrefix>
   <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
</ExtractVariables>

В этом примере для переменной urirequest.pathSeg установлено значение, указанное в суффиксе proxy.path после «/a/». Например, предположим, что базовый путь для вашего прокси API — /basepath/v1 . При входящем запросе на http://myCo.com/basepath/v1/a/b переменной присваивается значение «b».

Указание нескольких шаблонов

Вы можете указать несколько шаблонов для сопоставления, соответствующих тегам <Pattern> , где:

  • Все шаблоны проверяются на соответствие.
  • Если ни один из шаблонов не соответствует, политика ничего не делает и переменные не создаются.
  • Если совпадает более одного шаблона, для извлечения используется шаблон с самыми длинными сегментами пути.
  • Если два совпадающих шаблона имеют одинаковые самые длинные сегменты пути, то для извлечения используется шаблон, указанный первым в политике.

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

<ExtractVariables name="ExtractVariables-1">
   <Source>request</Source>
   <URIPath>
      <Pattern ignoreCase="true">/a/{pathSeg}</Pattern>
      <Pattern ignoreCase="true">/a/b/{pathSeg}</Pattern>
      <Pattern ignoreCase="true">/a/b/c/{pathSeg}</Pattern>
   </URIPath>
   <VariablePrefix>urirequest</VariablePrefix>
   <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
</ExtractVariables>

Предположим, что для прокси-сервера API с базовым путем /basepath/v1 URL-адрес входящего запроса к прокси-серверу API имеет следующую форму:

http://myCo.com/basepath/v1/a/b

В этом примере первый шаблон соответствует URI, а переменной urirequest.pathSeg присвоено значение «b».

Если URL-адрес запроса:

http://myCo.com/basepath/v1/a/b/c/d

...тогда третий шаблон соответствует, и переменной urirequest.pathSeg присваивается значение «d».

Указание шаблонов с несколькими переменными

В шаблоне сопоставления можно указать несколько переменных. Например, вы указываете шаблон соответствия с двумя переменными:

<ExtractVariables name="ExtractVariables-1">
   <Source>request</Source>
   <URIPath>
      <Pattern ignoreCase="true">/a/{pathSeg}</Pattern>
      <Pattern ignoreCase="true">/a/b/{pathSeg}</Pattern>
      <Pattern ignoreCase="true">/a/{pathSeg1}/c/{pathSeg2}</Pattern>
   </URIPath>
   <VariablePrefix>urirequest</VariablePrefix>
   <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
</ExtractVariables>

Опять же, предположим, что прокси-сервер API с базовым путем /basepath/v1 для URL-адреса входящего запроса:

http://myCo.com/basepath/v1/a/b/c/d

... переменная urirequest.pathSeg1 имеет значение «b», а переменная urirequest.pathSeg2 имеет значение «d».

Сопоставление нескольких экземпляров в шаблоне

Вы также можете сопоставлять шаблоны, когда существует несколько экземпляров элемента с одинаковым именем. Например, вы можете сделать запрос, содержащий несколько параметров запроса или несколько заголовков с одним и тем же именем. Следующий запрос содержит два параметра запроса с именем «w»:

http://myCo.com/basepath/v1/a/b/c/d?w=1&w=2

Чтобы ссылаться на эти параметры запроса в политике ExtractVariables, вы используете индексы, где первый экземпляр параметра запроса не имеет индекса, второй имеет индекс 2, третий — индекс 3 и т. д. Например, следующая политика извлекает значение второго параметра запроса с именем «w» в запросе:

<ExtractVariables name="ExtractVariables-1">
   <Source>request</Source>
   <QueryParam name="w.2">
      <Pattern ignoreCase="true">{secondW}</Pattern>
   </QueryParam>
   <VariablePrefix>urirequest</VariablePrefix>
   <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
</ExtractVariables>

Переменная urirequest. SecondW имеет значение «2». Если второй параметр запроса в запросе опущен, переменная urirequest. SecondW пуста. Используйте индексацию каждый раз, когда в запросе имеется несколько элементов с одинаковым именем.

Использование специальных символов в шаблоне

При сопоставлении путей URI вы можете использовать в шаблоне подстановочные знаки «*» и «**», где:

  • «*» соответствует любому сегменту пути
  • «**» соответствует нескольким сегментам пути.

Например, вы указываете шаблоны для элемента <URIPath> , как показано ниже:

<URIPath>
  <Pattern ignoreCase="true">/a/*/{id}</Pattern>
  <Pattern ignoreCase="true">/a/**/{id}</Pattern>
</URIPath>

Первый шаблон сопоставляет запросы с суффиксами пути (часть пути URI, следующего за базовым путем), например «/a/b/c», «/a/foo/bar» и т. д. Второй шаблон соответствует любому количеству сегментов пути после «/a/», например «/a/foo/bar/baz/c», а также «/a/b/c» и «/a/foo/bar».

При указании шаблонов для запроса параметров, заголовков и параметров формы символ «*» указывает на соответствие любому количеству символов. Например, при сопоставлении заголовка укажите шаблон как:

*;charset={кодировка}

Этот шаблон соответствует значениям «text/xml;charset=UTF-16» и «application/xml;charset=ASCII».

Если значение, переданное в политику ExtractVariables, содержит специальный символ, например «{», используйте символ «%», чтобы экранировать его. В следующем примере символы «{» и «}» в шаблоне экранируются, поскольку они используются в качестве буквальных символов в значении параметра запроса:

<QueryParam>
  <Pattern ignoreCase="true">%{user%} {name}</Pattern>
</QueryParam>

В этом примере шаблон соответствует значению «{user} Steve», но не значению «user Steve».

Сопоставление JSON и XML

При извлечении данных из JSON и XML вы указываете в политике один или несколько тегов <Variable> . Тег <Variable> указывает имя целевой переменной, в которой хранится извлеченная информация, а также JsonPath (JSON) или XPATH (XML) для извлеченной информации.

Все теги <Variable> в политике оцениваются, поэтому вы можете заполнить несколько переменных из одной политики. Если тег <Variable> не дает допустимого поля в JSON или XML, соответствующая переменная не создается.

В следующем примере показана политика ExtractVariables, которая заполняет две переменные из тела ответа JSON:

<ExtractVariables name="ExtractVariables-3">
   <Source>response</Source>
   <JSONPayload>
      <Variable name="latitude" type="float">
         <JSONPath>$.results[0].geometry.location.lat</JSONPath>
      </Variable>
      <Variable name="longitude" type="float">
         <JSONPath>$.results[0].geometry.location.lng</JSONPath>
      </Variable>
   </JSONPayload>
   <VariablePrefix>geocoderesponse</VariablePrefix>
</ExtractVariables>

Запись в одну и ту же переменную в нескольких местах

Будьте осторожны при выборе имен переменных для установки. Политика выполняется последовательно от первого шаблона извлечения до последнего. Если политика записывает значение в одну и ту же переменную из нескольких мест, последняя запись в политике определяет значение переменной. (Это может быть то, что вы хотите.)

Например, вы хотите извлечь значение токена, которое можно передать либо в параметре запроса, либо в заголовке, как показано ниже:

<!-- If token only in query param, the query param determines the value. 
     If token is found in both the query param and header, header sets value. -->
<QueryParam name="token">
  <Pattern ignoreCase="true">{tokenValue}</Pattern>
</QueryParam>
 
<!-- Overwrite tokenValue even if it was found in query parameter. -->
<Header name="Token">
  <Pattern ignoreCase="true">{tokenValue}</Pattern>
</Header>

Управление тем, что происходит, когда совпадений не происходит

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

Один из вариантов — установить для <IgnoreUnresolvedVariables> значение true в политике, которая ссылается на переменную, чтобы настроить политику для обработки любой неразрешимой переменной как пустой строки (null):

<IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>

Ссылка на элемент

Ссылка на элемент описывает элементы и атрибуты политики ExtractVariables.

<ExtractVariables async="false" continueOnError="false" enabled="true" name="Extract-Variables-1">
   <DisplayName>Extract Variables 1</DisplayName>
   <Source clearPayload="true|false">request</Source>
   <VariablePrefix>myprefix</VariablePrefix>
   <IgnoreUnresolvedVariables>true|false</IgnoreUnresolvedVariables>
   <URIPath>
      <Pattern ignoreCase="false">/accounts/{id}</Pattern>
   </URIPath>
   <QueryParam name="code">
      <Pattern ignoreCase="true">DBN{dbncode}</Pattern>
   </QueryParam>
   <Header name="Authorization">
      <Pattern ignoreCase="false">Bearer {oauthtoken}</Pattern>
   </Header>
   <FormParam name="greeting">
      <Pattern>hello {user}</Pattern>
   </FormParam>
   <Variable name="request.content">
       <Pattern>hello {user}</Pattern>
   </Variable>
   <JSONPayload>
      <Variable name="name">
         <JSONPath>{example}</JSONPath>
      </Variable>
   </JSONPayload>
   <XMLPayload stopPayloadProcessing="false">
      <Namespaces/>
      <Variable name="name" type="boolean">
         <XPath>/test/example</XPath>
      </Variable>
   </XMLPayload>
</ExtractVariables>

Атрибуты <ExtractVariables>

<ExtractVariables async="false" continueOnError="false" enabled="true" name="Extract-Variables-1">

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

Атрибут Описание По умолчанию Присутствие
name

Внутреннее имя политики. Значение атрибута name может содержать буквы, цифры, пробелы, дефисы, подчеркивания и точки. Это значение не может превышать 255 символов.

При необходимости используйте элемент <DisplayName> , чтобы пометить политику в редакторе прокси-сервера пользовательского интерфейса управления другим именем на естественном языке.

Н/Д Необходимый
continueOnError

Установите значение false , чтобы возвращать ошибку в случае сбоя политики. Это ожидаемое поведение для большинства политик.

Установите значение true , чтобы выполнение потока продолжалось даже после сбоя политики.

ЛОЖЬ Необязательный
enabled

Установите значение true , чтобы обеспечить соблюдение политики.

Установите значение false , чтобы отключить политику. Политика не будет применена, даже если она останется привязанной к потоку.

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

Этот атрибут устарел.

ЛОЖЬ Устарело

Элемент <DisplayName>

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

<DisplayName>Policy Display Name</DisplayName>
По умолчанию

Н/Д

Если вы опустите этот элемент, будет использовано значение атрибута name политики.

Присутствие Необязательный
Тип Нить

Элемент <Источник>

(Необязательно) Указывает переменную для анализа. Значение <Source> по умолчанию равно message . Значение message является контекстно-зависимым. В потоке запросов message преобразуется в сообщение запроса. В потоке ответов message преобразуется в ответное сообщение.

Хотя вы часто используете эту политику для извлечения информации из сообщения запроса или ответа, вы можете использовать ее для извлечения информации из любой переменной. Например, вы можете использовать его для извлечения информации из сущности, созданной политикой AccessEntity , из данных, возвращаемых политикой Service Callout , или извлечения информации из объекта XML или JSON.

Если <Source> невозможно разрешить или он разрешается в тип, не являющийся сообщением, политика не сможет ответить.

<Source clearPayload="true|false">request</Source>
По умолчанию: сообщение
Присутствие: Необязательный
Тип: Нить

Атрибуты

Атрибут Описание По умолчанию Присутствие Тип
очиститьПолезная нагрузка

Установите значение true , если вы хотите очистить полезную нагрузку, указанную в <Source>, после извлечения из нее данных.

Используйте параметр <clearPayload> только в том случае, если исходное сообщение не требуется после выполнения ExtractVariables. Установка значения true освобождает память, используемую сообщением.

ЛОЖЬ

Необязательный логическое значение

Элемент <VariablePrefix>

(Необязательно) Полное имя переменной создается путем соединения <VariablePrefix> , точки и имени, определенного вами в {фигурных скобках} в элементе <Pattern> или элементе <Variable> . Например: myprefix.id , myprefix.dbncode или myprefix.oauthtoken.

<VariablePrefix>myprefix</VariablePrefix>

Например, предположим, что значение имени — «пользователь».

  • Если <VariablePrefix> не указан, извлеченные значения присваиваются переменной с именем user .
  • Если <VariablePrefix> указан как myprefix, извлеченные значения присваиваются переменной с именем myprefix.user .
По умолчанию: Н/Д
Присутствие: Необязательный
Тип: Нить

Элемент <IgnoreUnresolvedVariables>

(Необязательно) Установите значение true , чтобы рассматривать любую неразрешимую переменную как пустую строку (ноль). Установите значение false если вы хотите, чтобы политика выдавала ошибку, когда любая ссылочная переменная неразрешима.

<IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
По умолчанию: ЛОЖЬ
Присутствие: Необязательный
Тип: логическое значение

Если ссылка XPath не разрешена в <XMLPayload> , политика выдает следующую ошибку:

{
   "fault":{
      "faultstring":"Unresolved xpath path in policy policy_name.",
      "detail":{
         "errorcode":"steps.extractvariables.InvalidXPath"
      }
   }
}

Элемент <URIPath>

(Необязательно, но дополнительную информацию см. в строке «Присутствие» в таблице ниже.) Извлекает значение из proxy.pathsuffix сообщения источника запроса . Путь, примененный к шаблону, — это суффикс proxy.path, который не включает базовый путь для прокси-сервера API. Если исходное сообщение преобразуется в сообщение типа ответа , то этот элемент ничего не делает.

<URIPath>
   <Pattern ignoreCase="false">/accounts/{id}</Pattern>
</URIPath>

Можно использовать несколько элементов <Pattern> :

<URIPath>
   <Pattern ignoreCase="false">/accounts/{id}</Pattern>
   <Pattern ignoreCase="false">/accounts/{id}/transactions/{index}</Pattern>
</URIPath>
По умолчанию: Н/Д
Присутствие: Необязательный. Однако необходимо включить хотя бы одно из следующих значений: <URIPath> , <QueryParam> , <Header> , <FormParam> , <JSONPayload> или <XMLPayload>.
Тип: Н/Д

Атрибуты

Атрибут Описание По умолчанию Присутствие Тип
игнорировать регистр Указывает игнорировать регистр при сопоставлении с образцом.

ЛОЖЬ

Необязательный логическое значение

Элемент <QueryParam>

(Необязательно, но дополнительную информацию см. в строке «Присутствие» в таблице ниже.) Извлекает значение из указанного параметра запроса исходного сообщения запроса . Если исходное сообщение преобразуется в сообщение типа ответа , то этот элемент ничего не делает.

<QueryParam name="code">
   <Pattern ignoreCase="true">DBN{dbncode}</Pattern>
</QueryParam>

Если несколько параметров запроса имеют одно и то же имя, используйте индексы для ссылки на параметры:

<QueryParam name="w.2">
   <Pattern ignoreCase="true">{secondW}</Pattern>
</QueryParam>
По умолчанию: Н/Д
Присутствие: Необязательный. Однако необходимо включить хотя бы одно из следующих значений: <URIPath> , <QueryParam> , <Header> , <FormParam> , <JSONPayload> или <XMLPayload>.
Тип: Н/Д

Атрибуты

Атрибут Описание По умолчанию Присутствие Тип
имя Указывает имя параметра запроса. Если несколько параметров запроса имеют одно и то же имя, используйте индексированные ссылки, при которых первый экземпляр параметра запроса не имеет индекса, второй имеет индекс 2, третий — индекс 3 и т. д.

Н/Д

Необходимый Нить

Элемент <Заголовок>

(Необязательно, но дополнительную информацию см. в строке «Присутствие» в таблице ниже.) Извлекает значение из указанного заголовка HTTP указанного запроса или ответного сообщения. Если несколько заголовков имеют одно и то же имя, их значения сохраняются в массиве.

<!-- The name is the actual header name. -->
<Header name="Authorization">
<!-- Provide a name for your new custom variable here. -->
   <Pattern ignoreCase="false">Bearer {oauthtoken}</Pattern>
</Header>

Если несколько заголовков имеют одно и то же имя, используйте индексы для ссылки на отдельные заголовки в массиве:

<Header name="myHeader.2">
   <Pattern ignoreCase="true">{secondHeader}</Pattern>
</Header>

Или следующее, чтобы перечислить все заголовки в массиве:

<Header name="myHeader.values">
   <Pattern ignoreCase="true">{myHeaders}</Pattern>
</Header>
По умолчанию: Н/Д
Присутствие: Необязательный. Однако необходимо включить хотя бы одно из следующих значений: <URIPath> , <QueryParam> , <Header> , <FormParam> , <JSONPayload> или <XMLPayload>.
Тип: Н/Д

Атрибуты

Атрибут Описание По умолчанию Присутствие Тип
имя Указывает имя заголовка, из которого извлекается значение. Если несколько заголовков имеют одно и то же имя, используйте индексированные ссылки, где первый экземпляр заголовка не имеет индекса, второй имеет индекс 2, третий — индекс 3 и т. д. Используйте .values , чтобы получить все заголовки в массиве.

Н/Д

Необходимый Нить

Элемент <ФормаПарам>

(Необязательно, но дополнительную информацию см. в строке «Присутствие» в таблице ниже.) Извлекает значение из указанного параметра формы указанного запроса или ответного сообщения. Параметры формы можно извлечь только в том случае, если заголовок Content-Type указанного сообщения имеет значение application/x-www-form-urlencoded .

<FormParam name="greeting">
    <Pattern>hello {user}</Pattern>
</FormParam>
По умолчанию: Н/Д
Присутствие: Необязательный. Однако необходимо включить хотя бы одно из следующих значений: <URIPath> , <QueryParam> , <Header> , <FormParam> , <JSONPayload> или <XMLPayload>.
Тип: Н/Д

Атрибуты

Атрибут Описание По умолчанию Присутствие Тип
имя Имя параметра формы, из которого извлекается значение.

Н/Д

Необходимый Нить

Элемент <Переменная>

(Необязательно, но дополнительную информацию см. в строке «Присутствие» в таблице ниже.) Указывает имя переменной, из которой нужно извлечь значение.

<Variable name="myVar">
    <Pattern>hello {user}</Pattern>
</Variable>

Чтобы извлечь два значения из переменной:

<Variable name="myVar">
   <Pattern>hello {firstName} {lastName}</Pattern>
</Variable>
По умолчанию: Н/Д
Присутствие: Необязательный. Однако необходимо включить хотя бы одно из следующих значений: <URIPath> , <QueryParam> , <Header> , <FormParam> , <JSONPayload> или <XMLPayload>.
Тип: Н/Д

Атрибуты

Атрибут Описание По умолчанию Присутствие Тип
имя Имя переменной, из которой извлекается значение.

Н/Д

Необходимый Нить

Элемент <JSONPayload>

(Необязательно, но дополнительную информацию см. в строке «Присутствие» в таблице ниже.) Указывает сообщение в формате JSON, из которого будет извлечено значение переменной. Извлечение JSON выполняется только в том случае, если заголовок Content-Type сообщения имеет значение application/json .

<JSONPayload>
   <Variable name="name" type="string">
      <JSONPath>{example}</JSONPath>
   </Variable>
</JSONPayload>
По умолчанию: Н/Д
Присутствие: Необязательный. Однако необходимо включить хотя бы одно из следующих значений: <URIPath> , <QueryParam> , <Header> , <FormParam> , <JSONPayload> или <XMLPayload>.
Тип: Н/Д

Элемент <JSONPayload>/<Variable>

(Обязательно в элементе JSONPayload.) Указывает переменную, которой присваивается извлеченное значение. Вы можете включить несколько тегов <Variable> в элемент <JSONPayload> для заполнения нескольких переменных.

<Variable name="name" type="string">
   <JSONPath>{example}</JSONPath>
</Variable>
По умолчанию: Н/Д
Присутствие: Требуется в элементе JSONPayload.
Тип: Н/Д

Атрибуты

Атрибут Описание По умолчанию Присутствие Тип
имя

Указывает имя переменной, которой будет присвоено извлеченное значение.

имя

Необходимый Нить
тип Указывает тип данных значения переменной. Н/Д Необязательный

Нить. Выберите из:

  • нить
  • логическое значение
  • целое число
  • длинный
  • плавать
  • двойной
  • набор узлов (возвращает фрагмент JSON)

Элемент <JSONPayload>/<Variable>/<JSONPath>

(Обязателен в элементе JSONPayload:Variable.) Указывает путь JSON, используемый для извлечения значения из сообщения в формате JSON.

<Variable name="name">
   <JSONPath>$.rss.channel.title</JSONPath>
</Variable>
По умолчанию: Н/Д
Присутствие: Необходимый
Тип: Нить

Элемент <XMLPayload>

(Необязательно, но дополнительную информацию см. в строке «Присутствие» в таблице ниже.) Указывает сообщение в формате XML, из которого будет извлечено значение переменной. Полезные данные XML извлекаются только в том случае, если заголовок Content-Type сообщения имеет значение text/xml , application/xml или application/*+xml .

<XMLPayload stopPayloadProcessing="false">
  <Namespaces>
     <Namespace prefix="apigee">http://www.apigee.com</Namespace>
     <Namespace prefix="gmail">http://mail.google.com</Namespace>
  </Namespaces>
  <Variable name="name" type="boolean">
     <XPath>/apigee:test/apigee:example</XPath>
  </Variable>
</XMLPayload>
По умолчанию: Н/Д
Присутствие: Необязательный. Однако необходимо включить хотя бы одно из следующих значений: <URIPath> , <QueryParam> , <Header> , <FormParam> , <JSONPayload> или <XMLPayload>.
Тип: Н/Д

Атрибуты

Атрибут Описание По умолчанию Присутствие Тип
stopPayloadProcessing

Установите значение true , чтобы остановить оценку XPath после заполнения одной переменной. Это означает, что в политике заполняется только одна переменная.

ЛОЖЬ

Необязательный логическое значение

Элемент <XMLPayload>/<Пространства имен>

(Необязательно) Указывает пространство имен, которое будет использоваться при оценке XPath. Если вы используете пространства имен в выражениях XPath, вы должны объявить пространства имен здесь, как показано в следующем примере.

<XMLPayload stopPayloadProcessing="false">
  <Namespaces>
     <Namespace prefix="apigee">http://www.apigee.com</Namespace>
     <Namespace prefix="gmail">http://mail.google.com</Namespace>
  </Namespaces>
  <Variable name="legName" type="string">
    <XPath>/apigee:Directions/apigee:route/apigee:leg/apigee:name</XPath>
  </Variable>
</XMLPayload>

Если вы не используете пространства имен в выражениях XPath, вы можете опустить или закомментировать элемент <Namespaces> , как показано в следующем примере:

<XMLPayload stopPayloadProcessing="false">
  <!-- <Namespaces/> -->
  <Variable name="legName" type="string">
    <XPath>/Directions/route/leg/name</XPath>
  </Variable>
</XMLPayload>
По умолчанию: Н/Д
Присутствие: Необязательный
Тип: Нить

Атрибуты

Атрибут Описание По умолчанию Присутствие Тип
prefix

Префикс пространства имен.

Н/Д

Необходимый Нить

Элемент <XMLPayload>/<Variable>

(Необязательно) Указывает переменную, которой будет присвоено извлеченное значение.

<Variable name="name" type="boolean">
   <XPath>/test/example</XPath>
</Variable>
По умолчанию: Н/Д
Присутствие: Необязательный
Тип: Н/Д

Атрибуты

Атрибут Описание По умолчанию Присутствие Тип
имя

Указывает имя переменной, которой будет присвоено извлеченное значение.

имя

Необходимый Нить
тип Указывает тип данных значения переменной. логическое значение Необязательный

Нить. Выберите из:

  • нить
  • логическое значение
  • целое число
  • длинный
  • плавать
  • двойной
  • набор узлов (возвращает фрагмент XML)

Элемент <XMLPayload>/<Variable>/<XPath>

(Обязателен в элементе XMLPayload:Variable.) Указывает XPath, определенный для переменной. Поддерживаются только выражения XPath 1.0.

<Variable name="name" type="boolean">
   <XPath>/test/example</XPath>
</Variable>

Пример с пространством имен. Если вы используете пространства имен в выражениях XPath, вы должны объявить пространства имен в разделе <XMLPayload><Namespaces> политики.

<Variable name="name" type="boolean">
   <XPath>/foo:test/foo:example</XPath>
</Variable>
По умолчанию: Н/Д
Присутствие: Необходимый
Тип: Нить

Ссылка на ошибку

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
steps.extractvariables.ExecutionFailed 500

This error occurs when:

  • The input payload (JSON, XML) is empty.
  • The input (JSON, XML, etc) passed to the policy is invalid or malformed.
steps.extractvariables.ImmutableVariable 500 A variable used in the policy is immutable. The policy was unable to set this variable.
steps.extractvariables.InvalidJSONPath 500 This error occurs if an invalid JSON path is used in the JSONPath element of the policy. For example, if a JSON payload does not have the object Name, but you specify Name as the path in the policy, then this error occurs.
steps.extractvariables.JsonPathParsingFailure 500 This error occurs when the policy is unable to parse a JSON path and extract data from the flow variable specified in Source element. Typically this happens if the flow variable specified in the Source element does not exist in the current flow.
steps.extractvariables.SetVariableFailed 500 This error occurs if the policy could not set the value to a variable. The error generally happens if you try to assign values to multiple variables whose names start with the same words in a nested dot-separated format.
steps.extractvariables.SourceMessageNotAvailable 500 This error occurs if the message 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.extractvariables.UnableToCast 500 This error occurs if the policy was unable to cast the extracted value to a variable. Typically this happens if you attempt to set the value of one data type to a variable of another data type.

Deployment errors

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

Error name Cause Fix
NothingToExtract If the policy does not have any of the elements URIPath, QueryParam, Header, FormParam, XMLPayload, or JSONPayload, the deployment of the API Proxy fails, because there's nothing to extract.
NONEmptyPrefixMappedToEmptyURI This error occurs if the policy has a prefix defined in the Namespace element under the XMLPayload element, but no URI is defined.
DuplicatePrefix This error occurs if the policy has the same prefix defined more than once in the Namespace element under the XMLPayload element.
NoXPathsToEvaluate If the policy does not have the XPath element within the XMLPayload element, then the deployment of the API proxy fails with this error.
EmptyXPathExpression If the policy has an empty XPath expression within the XMLPayload element, then the deployment of the API proxy fails.
NoJSONPathsToEvaluate If the policy does not have the JSONPath element within the JSONPayload element, then the deployment of the API proxy fails with this error.
EmptyJSONPathExpression If the policy has an empty XPath expression within the XMLPayload element, then the deployment of the API proxy fails.
MissingName If the policy does not have the name attribute in any of the policy elements like QueryParam, Header, FormParam or Variable, where it is required, then the deployment of the API proxy fails.
PatternWithoutVariable If the policy does not have a variable specified within the Pattern element, then the deployment of the API proxy fails. The Pattern element requires the name of the variable in which extracted data will be stored.
CannotBeConvertedToNodeset If the policy has an XPath expression where the Variable type is defined as nodeset, but the expression cannot be converted to nodeset, then the deployment of the API proxy fails.
JSONPathCompilationFailed The policy could not compile a specified JSON Path.
InstantiationFailed The policy could not be instantiated.
XPathCompilationFailed If the prefix or the value used in the XPath element is not part of any of the declared namespaces in the policy, then the deployment of the API proxy fails.
InvalidPattern If the Pattern element definition is invalid in any of the elements like URIPath, QueryParam, Header, FormParam, XMLPayload or JSONPayload within the policy, then the deployment of the API proxy fails.

Fault variables

These variables are set when this policy triggers an error at runtime. For more information, see What you need to know about policy errors.

Variables Where Example
fault.name="fault_name" fault_name is the name of the fault, as listed in the Runtime errors table above. The fault name is the last part of the fault code. fault.name = "SourceMessageNotAvailable"
extractvariables.policy_name.failed policy_name is the user-specified name of the policy that threw the fault. extractvariables.EV-ParseJsonResponse.failed = true

Example error response

{
   "fault":{
      "detail":{
         "errorcode":"steps.extractvariables.SourceMessageNotAvailable"
      },
      "faultstring":"request message is not available for ExtractVariable: EV-ParseJsonResponse"
   }
}

Example fault rule

<FaultRule name="Extract Variable Faults">
    <Step>
        <Name>AM-CustomErrorMessage</Name>
        <Condition>(fault.name = "SourceMessageNotAvailable") </Condition>
    </Step>
    <Condition>(extractvariables.EM-ParseJsonResponse.failed = true) </Condition>
</FaultRule>

Схемы

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

Анализируйте содержимое сообщений API с помощью пользовательской аналитики.

Справочник переменных