Вы просматриваете документацию Apigee Edge .
Перейти к документации Apigee X. info
Что
Политика ExtractVariables извлекает содержимое из запроса или ответа и присваивает значение переменной, равное этому содержимому. Вы можете извлечь любую часть сообщения, включая заголовки, пути URI, полезные данные JSON/XML, параметры форм и параметры запросов. Политика работает, применяя текстовый шаблон к содержимому сообщения и, при обнаружении совпадения, присваивает переменной указанное содержимое сообщения.
Хотя эта политика часто используется для извлечения информации из сообщения-запроса или ответа, ее также можно использовать для извлечения информации из других источников, включая сущности, созданные политикой AccessEntity , объекты XML или объекты JSON.
После извлечения указанного содержимого сообщения вы можете ссылаться на переменную в других политиках в рамках обработки запроса и ответа.
Видео
Посмотрите следующие видео, чтобы узнать больше о политике ExtractVariables.
| Видео | Описание |
|---|---|
| Извлечь переменные из полезной нагрузки XML | Извлеките переменные из полезной нагрузки XML с помощью политики извлечения переменных. |
| Извлечь переменные из полезной нагрузки JSON | Извлеките переменные из полезной нагрузки JSON с помощью политики извлечения переменных. |
| Извлечь переменные из параметров | Извлекайте переменные из параметров, таких как параметры запроса, заголовка, формы или URI. |
| Извлечение переменных из многозначных параметров | Извлечение переменных из многозначных параметров. |
| Извлечение переменных из параметра запроса (Classic Edge) | Извлекайте переменные из параметра запроса с помощью Classic Edge UI. |
| Извлечение переменных из полезной нагрузки XML или JSON (Classic Edge) | Извлекайте переменные из полезной нагрузки XML или JSON с помощью пользовательского интерфейса Classic Edge. |
Образцы
Эти примеры кода политики иллюстрируют, как извлекать переменные из следующих типов артефактов:
Эти ссылки ведут на рабочие примеры прокси-API, которые можно развернуть и запустить в Edge. Они используют ExtractVariables и находятся в репозитории Apigee api-platform-samples на GitHub. В файлах README объясняется, как использовать ExtractVariables в каждом случае, а также как развернуть и запустить каждый пример.
- Пример извлечения и назначения переменных (извлечение данных из сообщений JSON и XML)
- Образец сущности доступа
- Пример пагинации и кэширования
- Перенаправить целевой URL-адрес образца
- Пример составления политики мэшапа
<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 на 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>
<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>
<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 для создания аналитических отчетов на основе контента, см. раздел Анализ содержимого сообщений API с помощью пользовательской аналитики .
Объем
Переменные, заданные политикой ExtractVariables, имеют глобальную область действия. То есть, после того, как политика ExtractVariables определит новую переменную, к ней можно будет получить доступ из любой политики или кода на любом этапе выполнения (выполняемого после политики ExtractVariables). Это включает в себя:
- PreFlow: ProxyEndpoint и TargetEndpoint (запрос и ответ)
- PostFlow: ProxyEndpoint и TargetEndpoint (запрос и ответ)
- PostClientFlow: ProxyEndpoint (только ответ, с использованием политики ведения журнала сообщений )
- Потоки ошибок
О сопоставлении и создании переменных
Политика 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 | Внутреннее имя политики. Значение атрибута При необходимости используйте элемент | Н/Д | Необходимый |
continueOnError | Установите значение Установите значение | ЛОЖЬ | Необязательный |
enabled | Установите значение Установите значение | истинный | Необязательный |
async | Этот атрибут устарел. | ЛОЖЬ | Устарело |
Элемент <DisplayName>
Используйте в дополнение к атрибуту name , чтобы пометить политику в редакторе прокси-сервера пользовательского интерфейса управления другим именем на естественном языке.
<DisplayName>Policy Display Name</DisplayName>
| По умолчанию | Н/Д Если вы опустите этот элемент, будет использовано значение атрибута |
|---|---|
| Присутствие | Необязательный |
| Тип | Нить |
Элемент <Источник>
(Необязательно) Указывает переменную для анализа. Значение <Source> по умолчанию — message . Значение message зависит от контекста. В потоке запросов message преобразуется в сообщение запроса. В потоке ответов message преобразуется в сообщение ответа.
Хотя эта политика часто используется для извлечения информации из запроса или ответа, её можно использовать и для извлечения информации из любой переменной. Например, её можно использовать для извлечения информации из сущности, созданной политикой AccessEntity , из данных, возвращаемых политикой Service Callout , или извлечения информации из объекта XML или JSON.
Если <Source> не может быть разрешен или разрешен как тип, не являющийся сообщением, политика не ответит.
<Source clearPayload="true|false">request</Source>
| По умолчанию: | сообщение |
| Присутствие: | Необязательный |
| Тип: | Нить |
Атрибуты
| Атрибут | Описание | По умолчанию | Присутствие | Тип |
|---|---|---|---|---|
| clearPayload | Установите значение true , если вы хотите очистить полезную нагрузку, указанную в <Source>, после извлечения из нее данных. | ЛОЖЬ | Необязательный | Булевое значение |
элемент <VariablePrefix>
(Необязательно) Полное имя переменной создаётся путём объединения префикса <VariablePrefix> , точки и имени, указанного в фигурных скобках {фигурные скобки} в элементе <Pattern> или элементе <Variable> . Например: myprefix.id , myprefix.dbncode или myprefix.oauthtoken.
<VariablePrefix>myprefix</VariablePrefix>
Например, предположим, что значение имени — «пользователь».
- Если
<VariablePrefix>не указан, извлеченные значения присваиваются переменной с именемuser. - Если
<VariablePrefix>указан как myprefix, извлеченные значения присваиваются переменной с именемmyprefix.user.
| По умолчанию: | Н/Д |
| Присутствие: | Необязательный |
| Тип: | Нить |
Элемент <IgnoreUnresolvedVariables>
(Необязательно) Установите значение true , чтобы рассматривать любую неразрешимую переменную как пустую строку (null). Установите значение false , чтобы политика выдавала ошибку, если любая указанная переменная неразрешима.
<IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
| По умолчанию: | ЛОЖЬ |
| Присутствие: | Необязательный |
| Тип: | Булевое значение |
Если ссылка XPath не разрешена в <XMLPayload> , политика выдает следующую ошибку:
{ "fault":{ "faultstring":"Unresolved xpathpath in policypolicy_name .", "detail":{ "errorcode":"steps.extractvariables.InvalidXPath" } } }
Элемент <URIPath>
(Необязательно, но см. строку «Присутствие» в таблице ниже для получения дополнительной информации.) Извлекает значение из proxy.pathsuffix исходного сообщения запроса . Путь, применяемый к шаблону, — это proxy.pathsuffix, который не включает базовый путь для прокси-сервера API. Если исходное сообщение разрешается в тип сообщения response , этот элемент не выполняет никаких действий.
<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>. |
| Тип: | Н/Д |
Атрибуты
| Атрибут | Описание | По умолчанию | Присутствие | Тип |
|---|---|---|---|---|
| ignoreCase | Указывает, что при сопоставлении с шаблоном регистр нужно игнорировать. | ЛОЖЬ | Необязательный | Булевое значение |
элемент <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 для получения всех заголовков в массиве. | Н/Д | Необходимый | Нить |
элемент <FormParam>
(Необязательно, но см. строку «Присутствие» в таблице ниже для получения дополнительной информации.) Извлекает значение из указанного параметра формы указанного сообщения запроса или ответа . Параметры формы могут быть извлечены только в том случае, если заголовок 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. |
| Тип: | Н/Д |
Атрибуты
| Атрибут | Описание | По умолчанию | Присутствие | Тип |
|---|---|---|---|---|
| имя | Указывает имя переменной, которой будет присвоено извлеченное значение. | имя | Необходимый | Нить |
| тип | Указывает тип данных значения переменной. | Н/Д | Необязательный | Строка. Выберите из:
|
Элемент <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 | Установите значение | ЛОЖЬ | Необязательный | Булевое значение |
Элемент <XMLPayload>/<Namespaces>
(Необязательно) Указывает пространство имён, которое будет использоваться при оценке 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>
| По умолчанию: | Н/Д |
| Присутствие: | Необязательный |
| Тип: | Н/Д |
Атрибуты
| Атрибут | Описание | По умолчанию | Присутствие | Тип |
|---|---|---|---|---|
| имя | Указывает имя переменной, которой будет присвоено извлеченное значение. | имя | Необходимый | Нить |
| тип | Указывает тип данных значения переменной. | Булевое значение | Необязательный | Строка. Выберите из:
|
Элемент <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>
| По умолчанию: | Н/Д |
| Присутствие: | Необходимый |
| Тип: | Нить |
Ссылка на ошибку
В этом разделе описаны коды ошибок и сообщения об ошибках, которые возвращаются, а также переменные ошибок, которые устанавливаются Edge, когда эта политика вызывает ошибку. Эту информацию важно знать, если вы разрабатываете правила обработки ошибок. Дополнительные сведения см. в разделах Что нужно знать об ошибках политики и Обработка ошибок .
Ошибки выполнения
Эти ошибки могут возникнуть при выполнении политики.
| Код неисправности | Статус HTTP | Причина | Исправить |
|---|---|---|---|
steps.extractvariables.ExecutionFailed | 500 | Эта ошибка возникает, когда:
| build |
steps.extractvariables.ImmutableVariable | 500 | Переменная, используемая в политике, является неизменяемой. Политике не удалось установить эту переменную. | |
steps.extractvariables.InvalidJSONPath | 500 | Эта ошибка возникает, если в элементе JSONPath политики используется недопустимый путь JSON. Например, если полезные данные JSON не имеют объекта Name , но вы указываете Name в качестве пути в политике, возникает эта ошибка. | build |
steps.extractvariables.JsonPathParsingFailure | 500 | Эта ошибка возникает, когда политике не удается проанализировать путь JSON и извлечь данные из переменной потока, указанной в элементе Source . Обычно это происходит, если переменная потока, указанная в элементе Source , не существует в текущем потоке. | build |
steps.extractvariables.SetVariableFailed | 500 | Эта ошибка возникает, если политика не может установить значение переменной. Ошибка обычно возникает, если вы пытаетесь присвоить значения нескольким переменным, имена которых начинаются с одних и тех же слов во вложенном формате, разделенном точками. | build |
steps.extractvariables.SourceMessageNotAvailable | 500 | Эта ошибка возникает, если переменная сообщения , указанная в элементе Source политики:
| build |
steps.extractvariables.UnableToCast | 500 | Эта ошибка возникает, если политике не удалось преобразовать извлеченное значение в переменную. Обычно это происходит, если вы пытаетесь установить значение одного типа данных в переменную другого типа данных. | build |
Ошибки развертывания
Эти ошибки могут возникнуть при развертывании прокси-сервера, содержащего эту политику.
| Название ошибки | Причина | Исправить |
|---|---|---|
NothingToExtract | Если в политике нет элементов URIPath , QueryParam , Header , FormParam , XMLPayload или JSONPayload , развертывание прокси-сервера API завершится неудачей, поскольку нечего извлекать. | build |
NONEmptyPrefixMappedToEmptyURI | Эта ошибка возникает, если у политики есть префикс, определенный в элементе Namespace под элементом XMLPayload , но URI не определен. | build |
DuplicatePrefix | Эта ошибка возникает, если политика имеет один и тот же префикс, определенный более одного раза в элементе Namespace под элементом XMLPayload . | build |
NoXPathsToEvaluate | Если в политике нет элемента XPath в элементе XMLPayload , развертывание прокси-сервера API завершается с ошибкой. | build |
EmptyXPathExpression | Если политика содержит пустое выражение XPath в элементе XMLPayload , развертывание прокси-сервера API завершается неудачно. | build |
NoJSONPathsToEvaluate | Если в политике нет элемента JSONPath внутри элемента JSONPayload , развертывание прокси-сервера API завершается с ошибкой. | build |
EmptyJSONPathExpression | Если политика содержит пустое выражение XPath в элементе XMLPayload , развертывание прокси-сервера API завершается неудачей. | build |
MissingName | Если политика не имеет атрибута name ни в одном из элементов политики, таких как QueryParam , Header , FormParam или Variable , где он требуется, то развертывание прокси-сервера API не удастся. | build |
PatternWithoutVariable | Если в политике не указана переменная в элементе Pattern , развертывание прокси-сервера API не удастся. Элементу Pattern требуется имя переменной, в которой будут храниться извлеченные данные. | build |
CannotBeConvertedToNodeset | Если в политике есть выражение XPath , в котором тип Variable определен как nodeset , но это выражение невозможно преобразовать в nodeset, то развертывание прокси-сервера API завершается неудачей. | build |
JSONPathCompilationFailed | Политике не удалось скомпилировать указанный путь JSON. | |
InstantiationFailed | Не удалось реализовать политику. | |
XPathCompilationFailed | Если префикс или значение, используемые в элементе XPath , не являются частью ни одного из объявленных пространств имен в политике, развертывание прокси-сервера API завершается неудачей. | build |
InvalidPattern | Если определение элемента Pattern недопустимо в любом из элементов, таких как URIPath , QueryParam , Header , FormParam , XMLPayload или JSONPayload в политике, то развертывание прокси-сервера API завершается неудачно. | build |
Переменные неисправности
Эти переменные устанавливаются, когда эта политика вызывает ошибку во время выполнения. Дополнительные сведения см. в разделе Что нужно знать об ошибках политики .
| Переменные | Где | Пример |
|---|---|---|
fault.name=" fault_name " | fault_name — это имя ошибки, как указано в таблице ошибок времени выполнения выше. Имя неисправности — это последняя часть кода неисправности. | fault.name = "SourceMessageNotAvailable" |
extractvariables. policy_name .failed | policy_name — указанное пользователем имя политики, вызвавшей ошибку. | extractvariables.EV-ParseJsonResponse.failed = true |
Пример ответа об ошибке
{ "fault":{ "detail":{ "errorcode":"steps.extractvariables.SourceMessageNotAvailable" }, "faultstring":"request message is not available for ExtractVariable: EV-ParseJsonResponse" } }
Пример правила неисправности
<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 с помощью пользовательской аналитики