Как управлять выполнением прокси-сервера с помощью процессов

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

Любая модель программирования приложений включает способ управления потоком обработки. В прокси API это делается с помощью потоков. В потоки можно добавлять логику, условные операторы, обработку ошибок и т. д. С помощью потоков вы можете управлять тем, что и когда происходит.

Потоки – это последовательные этапы обработки запроса к API. Когда вы добавляете логику прокси, например для проверки ключа API, вы добавляете ее как шаг в последовательность, заданную потоком. Когда вы задаете условие, чтобы указать, будет ли выполняться логика и когда именно, вы добавляете условие в процесс.

В приведенном ниже примере конфигурации потока определяется поток, в котором правило VerifyAPIKey выполняется, если путь входящего запроса заканчивается на / и HTTP-метод запроса – GET.

<Flow name="Get Food Carts">
    <Description>Get Food Carts</Description>
    <Request>
        <Step>
            <Name>Verify-API-Key</Name>
        </Step>
    </Request>
    <Condition>(proxy.pathsuffix MatchesPath "/") and (request.verb = "GET")</Condition>
</Flow>

Значение Verify-API-Key в элементе <Name> потока позволяет включить в прокси-сервер правило, настроенное в другом месте с помощью XML-кода, например такого:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<VerifyAPIKey async="false" continueOnError="false" enabled="true" name="Verify-API-Key">
    <DisplayName>Verify API Key</DisplayName>
    <Properties/>
    <APIKey ref="request.header.x-api-key"/>
</VerifyAPIKey>

Как спроектировать последовательность выполнения процесса

Вы можете структурировать потоки так, чтобы логика выполнялась в правильной последовательности по пути обработки.

При выборе места для добавления логики сначала нужно решить, будет ли это конечная точка прокси или целевая конечная точка. Код прокси-сервера API делится на код, который взаимодействует с клиентом прокси-сервера (конечная точка прокси-сервера), и необязательный код, который взаимодействует с целевым бэкендом прокси-сервера (конечная точка цели).

Оба конечных пункта содержат потоки, как описано ниже.

Вы настраиваете поток с помощью XML-кода, в котором указываете, что и в каком порядке должно происходить. На иллюстрации ниже показано, как потоки упорядочиваются последовательно в конечной точке прокси и целевой конечной точке:

Прокси-конечная точка и целевая конечная точка содержат потоки, которые можно расположить в следующем порядке:

Выполнение кода в первую очередь с помощью PreFlow

PreFlow полезен, когда нужно убедиться, что определенный код выполняется до того, как произойдет что-либо ещё.

В конечной точке прокси-сервера PreFlow – это отличное место для кода, который аутентифицирует клиента и ограничивает трафик от клиентов. В целевой конечной точке, где начинается подготовка к отправке запроса в целевой сервис, PreFlow подходит для выполнения первых шагов по подготовке к отправке запроса.

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

В приведенном ниже примере правила SpikeArrest и Quota выполняются до того, как обработка переходит к условным потокам.

<PreFlow name="MyPreFlow">
    <Request>
        <Step>
            <Name>Spike-Arrest</Name>
        </Step>
        <Step>
            <Name>Quota</Name>
        </Step>
    </Request>
    <Response/>
</PreFlow>

Условное выполнение кода с помощью условного потока

Между PreFlow и PostFlow можно разместить потоки, которые выполняются при определенных условиях. Это позволяет настроить несколько последовательностей логики, но выполнять только одну из них в зависимости от состояния прокси-сервера. Условный поток не является обязательным, если всю логику можно выполнить в PreFlow или PostFlow и условия не требуются (другими словами, поддерживается только один путь через конечную точку).

Каждый поток содержит условие, которое проверяет разные значения состояния. Таким образом, выполнение программы разветвляется в зависимости от условий. Например, вы можете захотеть преобразовать XML в JSON только в том случае, если приложение, отправившее запрос, запущено на мобильном устройстве.

В этом случае ограничения квоты применяются только к запросам GET с шаблоном URI /issue/** (/issue/ с любым содержимым URI после последней косой черты).

<Flow name="MyFlow">
    <Description/>
    <Request>
        <Step>
            <Name>Quota</Name>
        </Step>
    </Request>
    <Response/>
    <Condition>(proxy.pathsuffix MatchesPath "/issue/**") and (request.verb = "GET")</Condition>
</Flow>

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

Примеры использования сопоставления с шаблоном в условиях приведены в разделе Сопоставление с шаблоном.

Выполнение кода после основной логики с помощью PostFlow

PostFlow – это отличное место для выполнения действий после основной логики конечной точки и до завершения обработки конечной точки. PostFlow выполняется после условных потоков и PreFlow.

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

В следующем примере правило AssignMessage с названием SetResponseHeaders задает заголовки ответного сообщения до того, как Apigee Edge отправит ответ клиенту.

<PostFlow>
    <Response>
        <Step>
            <Name>SetResponseHeaders</Name>
        </Step>
    </Response>
 </PostFlow>

Выполнение кода после того, как клиент получит ответ от вашего прокси-сервера с PostClientFlow

В PostClientFlow можно включить следующие правила:

• Правила в отношении уточнений
• Правила в отношении уточнений^*
• Правила MessageLogging
• Правила в отношении объектов уточнений

^* Правило FlowCallout может вызывать только общие потоки, которые сами соответствуют критериям для PostClientFlow (т. е. содержат только совместимые правила).

Если вы добавите такой поток, он будет выполняться последним, после того как клиенту будет отправлен ответ.

PostClientFlow подходит для окончательной регистрации. Вы также можете регистрировать временные метки начала и окончания сообщения с ответом.

Ниже приведен пример PostClientFlow с прикрепленным правилом MessageLogging.

    ...
    <PostFlow name="PostFlow">
        <Request/>
        <Response/>
    </PostFlow>
    <PostClientFlow>
        <Request/>
        <Response>
            <Step>
                <Name>Message-Logging-1</Name>
            </Step>
        </Response>
    </PostClientFlow>
    ...

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

• Справочник по конфигурации прокси-сервера API
• Статья сообщества Tutorial : Apigee Edge - Post Client Flow

Как добавить логику в процессы

Чтобы добавить логику в прокси, нужно добавить правила в потоки прокси. Как и потоки, содержимое потока выполняется последовательно.

В приведенном ниже примере конфигурации потока используются три правила (настроенные в других XML-файлах). Правило, на которое ссылается Verify-API-Key, выполняется до правила, на которое ссылается Remove-API-Key. После этого выполняется правило, представленное Quota.

<Flow name="Get Food Cart Menus">
    <Description>Get Food Cart Menus</Description>
    <Request>
        <Step>
            <Name>Verify-API-Key</Name>
        </Step>
        <Step>
            <Name>Remove-API-Key</Name>
        </Step>
        <Step>
            <Name>Quota</Name>
        </Step>
    </Request>
    <Condition>(proxy.pathsuffix MatchesPath "/") and (request.verb = "GET")</Condition>
</Flow>

В консоли Apigee Edge эта последовательность правил представлена в виде строки значков, где каждый значок соответствует определенному правилу.

Отладка потоков

Инструмент Apigee Edge Trace позволяет в графическом виде отслеживать, как логика в вашем прокси-сервере API выполняется после запроса. Инструмент показывает, как обрабатывается запрос и формируется ответ. В нем не показано, как разделены PreFlow, условные потоки и PostFlow.

Подробнее об использовании инструмента Trace…

Обработка ошибок в процессах

Вы можете вызывать ошибки в разных местах прокси-сервера API, в том числе в потоках.

В приведенном ниже примере показан фрагмент ответа из PreFlow в целевой конечной точке. Иными словами, это код, который выполняется сразу после получения ответа от целевого бэкенда. В примере ошибка возникает, если целевой сервис возвращает код ответа, отличный от 200 (успех).

<PreFlow name="PreFlow">
    <Response>
        <Step>
            <Name>RaiseFault</Name>
            <Condition>(response.status.code GreaterThan "200")</Condition>
        </Step>
    </Response>
</PreFlow>

Подробнее о том, как обрабатывать ошибки…