Справочник по конфигурации потока

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

В этом разделе представлена ​​справочная информация об XML-элементах, используемых для определения потоков прокси-сервера API.

Иерархия и синтаксис

Следующие примеры демонстрируют иерархию элементов и синтаксис элементов конфигурации потока:

Иерархия элементов

В следующем примере показана иерархия элементов конфигурации потока внутри элементов <ProxyEndpoint> и <TargetEndpoint> :

<ProxyEndpoint | TargetEndpoint>
    <PreFlow>
          <Request>
                <Step>
                    <Condition>
                    <Name>
          <Response>
                <Step>
                    <Condition>
                    <Name>
          <Description>
    <Flows>
          <Flow>
                <Description>
                <Condition>
                <Request>
                      <Step>
                          
                <Response>
                      <Step>
                          
          <Description>
    <PostFlow>
          <Request>
                <Step>
                    
          <Response>
                <Step>
                    
          <Description>
    <PostClientFlow> (<ProxyEndpoint> only)
          <Response>
                
          <Description>

      // Additional configuration elements

</ProxyEndpoint | TargetEndpoint>

Синтаксис

В следующем примере показан синтаксис элементов конфигурации потока. Каждый из этих элементов подробно описан в следующих разделах:

<!-- ProxyEndpoint flow configuration file -->
<ProxyEndpoint ... >
  ...
  <PreFlow name="flow_name">
    <Description>flow_description</Description>
    <Request>
      <Step>
        <Condition>property operator "value"</Condition>
        <Name>policy_name</Name>
      </Step>
      ...
    </Request>
    <Response>
      <Step>
        <Condition>property operator "value"</Condition>
        <Name>policy_name</Name>
      </Step>
      ...
    </Response>
  </PreFlow>
  <Flows name="flow_name">
    <Flow name="conditional_flow_name">
      <Description>flow_description</Description>
      <Condition>property operator "value"</Condition>
      <Request>
        <Step>
          <Condition>property operator "value"</Condition>
          <Name>policy_name</Name>
        </Step>
        ...
      </Request>
      <Response>
        <Step>
          <Condition>property operator "value"</Condition>
          <Name>policy_name</Name>
        </Step>
        ...
      </Response>
    </Flow>
  </Flows>
  <PostFlow name="flow_name">
    <Description>flow_description</Description>
    <Request>
      <Step>
        <Condition>property operator "value"</Condition>
        <Name>policy_name</Name>
      </Step>
      ...
    </Request>
    <Response>
      <Step>
        <Condition>property operator "value"</Condition>
        <Name>policy_name</Name>
      </Step>
      ...
    </Response>
  </PostFlow>
  <PostClientFlow name="flow_name">
    <Description>flow_description</Description>
    <Response>
      <Step>
        <Condition>property operator "value"</Condition>
        <Name>policy_name</Name>
      </Step>
      ...
    </Response>
  </PostClientFlow>
  ...
</ProxyEndpoint>

<!-- TargetEndpoint flow configuration file -->
<TargetEndpoint ... >
  ...
  <PreFlow name="flow_name">
    <Description>flow_description</Description>
    <Request>
      <Step>
        <Condition>property operator "value"</Condition>
        <Name>policy_name</Name>
      </Step>
      ...
    </Request>
    <Response>
      <Step>
        <Condition>property operator "value"</Condition>
        <Name>policy_name</Name>
      </Step>
      ...
    </Response>
  </PreFlow>
  <Flows name="flow_name">
    <Flow name="conditional_flow_name">
      <Description>flow_description</Description>
      <Condition>property operator "value"</Condition>
      <Request>
        <Step>
          <Condition>property operator "value"</Condition>
          <Name>policy_name</Name>
        </Step>
        ...
      </Request>
      <Response>
        <Step>
          <Condition>property operator "value"</Condition>
          <Name>policy_name</Name>
        </Step>
        ...
      </Response>
    </Flow>
    ...
  </Flows>
  <PostFlow name="flow_name">
    <Description>flow_description</Description>
    <Request>
      <Step>
        <Condition>property operator "value"</Condition>
        <Name>policy_name</Name>
      </Step>
      ...
    </Request>
    <Response>
      <Step>
        <Condition>property operator "value"</Condition>
        <Name>policy_name</Name>
      </Step>
      ...
    </Response>
  </PostFlow>
  ...
</TargetEndpoint>

Эти элементы используются для определения этапов выполнения PreFlow, Conditional Flow, PostFlow и PostClientFlow.

<Condition>

Определяет оператор, который обрабатывается во время выполнения. Если оператор оценивается как истинный, то выполняется шаг или поток, связанный с условием. Если оператор оценивается как ложный, то шаг или поток игнорируется.

Тип Нить
Родительский элемент(ы) <Flow>
<Step>
Дочерний(е) элемент(ы) Никто

В зависимости от того, поместите ли вы элемент в элемент <Flow> или <Step> , вы можете применить условие к конкретному шагу или ко всему процессу целиком:

// Condition can apply to just one step:        // Or to the flow:
<Flows>                                         <Flows>
  <Flow>                                          <Flow>
    <Step>                                          <Condition>
      <Condition>                                   <Step>
      <Name>                                          <Name>
      ...                                             ...
    ...                                             ...
  ...                                             ...
</Flows>                                        </Flows>

Если условие в рамках шага <Step> истинно, Edge выполняет этот шаг. Если условие ложно, Edge пропускает шаг.

Если условие в потоке <Flow> истинно, Edge обрабатывает все шаги потока. Если условие ложно, Edge пропускает весь поток.

Синтаксис

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

<Condition>property operator "value"</Condition>

Где:

property
Свойство переменной потока, которое вы хотите использовать в своем условии. Например, переменная потока request имеет свойства с именами path и content . Чтобы использовать их в условии, укажите свойство flow_variable [точка] property_name :
request.path
request.content

Полный список переменных потока и их свойств см. в справочнике по переменным потока .

operator
Конструкция, определяющая способ оценки вашего условия. К распространённым операторам относятся:
>     greater than           <=    less than or equal to
<     less than              >=    greater than or equal to
=     equals                 &&    and
!=    not equals             ||    or

~~    JavaRegex
~     Matches
/~    MatchesPath

Полный список см. в разделе «Операторы» в справочнике «Условия».

" value "
Значение, относительно которого оценивается свойство переменной потока. Обычно это базовый тип, например, целое число или строка. Например, 200 или "/cat". Значение может включать подстановочные знаки, такие как звездочки и другие символы для сопоставления с шаблоном, как описано в разделе "Сопоставление с шаблоном с помощью условных операторов" .

Пример 1

В следующем примере проверяется, имеет ли свойство verb переменной потока request значение "GET":

<!-- api-platform/reference/examples/flow-segments/condition-1.xml -->
<ProxyEndpoint name="default">
  <PreFlow name="my-preFlows">
    <Description>My first PreFlow</Description>
    <Request>
      <Step>
        <Condition>request.verb = "GET"</Condition>
        <Name>Log-Request-OK</Name>
      </Step>
    </Request>
  </PreFlow>
  ...
</ProxyEndpoint>

Если запрос имеет тип "GET", то в этом примере выполняется политика "Log-Request-OK".

Пример 2

В следующем примере проверяется код ответа:

<!-- api-platform/reference/examples/flow-segments/condition-2.xml -->
<ProxyEndpoint name="default">
  <PreFlow name="my-preFlows">
    <Description>My first PreFlow</Description>
    <Response>
      <Step>
        <Condition>response.status.code LesserThanOrEquals 300</Condition>
        <Name>Log-Response-OK</Name>
      </Step>
      <Step>
        <Condition>response.status.code GreaterThan 300</Condition>
        <Name>Log-Response-NOT-OK</Name>
      </Step>
    </Response>
  </PreFlow>
  ...
</ProxyEndpoint>

В зависимости от значения кода выполняется разная политика.

Атрибуты

Элемент <Condition> не имеет атрибутов.

Дочерние элементы

Элемент <Condition> не имеет дочерних элементов.

<Description>

Описывает процесс в удобочитаемом виде. Используйте этот элемент для предоставления информации о процессе себе или другим разработчикам. Описание не отображается для внешнего просмотра.

Тип Нить
Родительский элемент(ы) <Flow>
<PreFlow>
<PostFlow>
Дочерний(е) элемент(ы) Никто

Синтаксис

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

<Description>flow_description</Description>

Пример

В следующем примере показан элемент <Description> , который определяет назначение потока: 

<!-- api-platform/reference/examples/flow-segments/description-1.xml -->
<ProxyEndpoint name="default">
  <Flows name="my-conditional-flows">
    <Flow name="reports">
      <Request>
        <Description>Based on the path suffix, determine which flow to use</Description>
        <Step>
          <Condition>proxy.pathsuffix MatchesPath "/reports"</Condition>
          <Name>XML-to-JSON-1</Name>
        </Step>
        <Step>
          <Condition>proxy.pathsuffix MatchesPath "/forecasts"</Condition>
          <Name>XML-to-JSON-1</Name>
        </Step>
      </Request>
    </Flow>
  </Flows>
  ...
</ProxyEndpoint>

Атрибуты

Элемент <Description> не имеет атрибутов.

Дочерние элементы

Элемент <Description> не имеет дочерних элементов.

<Flow>

Определяет пользовательский набор шагов, которые выполняет Edge.

Тип Сложный объект
Родительский элемент(ы) <Flows>
Дочерний(е) элемент(ы) <Condition>
<Description>
<Request>
<Response>

При желании можно указать <Condition> для <Flow> . В этом случае Edge будет выполнять шаги потока только в том случае, если условие истинно. В противном случае Edge пропустит весь поток.

Элемент <Flows> может содержать несколько элементов <Flow> , каждый со своим условием и шагами. При наличии нескольких элементов <Flow> Edge выполняет только первый из них, в котором нет условия или условие оценивается как истинное.

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

Синтаксис

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

<Flow name="conditional_flow_name">
  <Description>flow_description</Description>
  <Condition>property operator "value"</Condition>
  <Request>
    <Step>
      <Condition>property operator "value"</Condition>
      <Name>policy_name</Name>
    </Step>
    ...
  </Request>
  <Response>
    <Step>
      <Condition>property operator "value"</Condition>
      <Name>policy_name</Name>
    </Step>
    ...
  </Response>
</Flow>

Все дочерние элементы <Flow> являются необязательными.

Пример 1

В следующем примере показан простой <Flow> , который всегда выполняет политику "Log-Message-OK": 

<!-- api-platform/reference/examples/flow-segments/flow-1.xml -->
<ProxyEndpoint name="default">
  <Flows name="my-flow">
    <Flow>
      <Request>
        <Step>
          <Name>Log-Message-OK</Name>
        </Step>
      </Request>
    </Flow>
  </Flows>
  ...
</ProxyEndpoint>

Пример 2

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

<!-- api-platform/reference/examples/flow-segments/flow-2.xml -->
<ProxyEndpoint name="default">
  <Flows name="my-conditional-flows">
    <Flow name="reports">
      <Request>
        <Description>Based on the path suffix, determine which flow to use</Description>
        <Step>
          <Condition>proxy.pathsuffix MatchesPath "/reports"</Condition>
          <Name>XML-to-JSON-1</Name>
        </Step>
        <Step>
          <Condition>proxy.pathsuffix MatchesPath "/forecasts"</Condition>
          <Name>Verify-Auth-1</Name>
        </Step>
      </Request>
    </Flow>
  </Flows>
  ...
</ProxyEndpoint>

Пример 3

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

<!-- api-platform/reference/examples/flow-segments/flows-2.xml -->
<ProxyEndpoint name="default">
  <Flows>
    <Flow name="my-flow-1">
      <Response>
        <Step>
          <Condition>response.status.code = 200</Condition>
          <Name>Assign-Message-1</Name>
        </Step>
      </Response>
    </Flow>
    <Flow name="my-flow-2">
      <Response>
        <Step>
          <Condition>response.status.code >= 400</Condition>
          <Name>Assign-Message-2</Name>
        </Step>
      </Response>
    </Flow>
    <Flow name="my-flow-3">
      <Response>
        <Step>
          <Condition>response.status.code >= 300</Condition>
          <Name>Assign-Message-3</Name>
        </Step>
      </Response>
    </Flow>
  </Flows>
  ...
</ProxyEndpoint>

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

Атрибуты

В следующей таблице описаны атрибуты элемента <Flow> :

Атрибут Тип Описание
name Нить (Обязательно) Уникальный идентификатор для потока. Например, "My-Conditional-Flow-1". Имя не может содержать пробелов или других специальных символов.

Дочерние элементы

В следующей таблице описаны дочерние элементы <Flow> :

Дочерний элемент Тип Описание
<Condition> Нить Определяет условное выражение, которое обрабатывается во время выполнения. Если выражение истинно, то выполняется поток (и все его шаги). Если выражение ложно, то поток (и все его шаги) игнорируются.
<Description> Нить Предоставляет краткое описание процесса. Это описание не отображается внешне.
<Request> Сложный объект Определяет шаги и условия для сегмента запроса.
<Response> Сложный объект Определяет шаги и условия для сегмента ответа.

<Flows>

Содержит ноль или более элементов <Flow> .

Тип Сложный объект
Родительский элемент(ы) <ProxyEndpoint>
<TargetEndpoint>
Дочерний(е) элемент(ы) <Flow>

Если в элементах <Flows> присутствует несколько элементов <Flow> , будет выполнен только один элемент <Flow> . Это будет первый поток, который либо не имеет <Condition> , либо условие которого истинно.

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

Синтаксис

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

<Flows name="flow_name">
  <Flow name="conditional_flow_name">
    <Description>flow_description</Description>
    <Condition>property operator "value"</Condition>
    <Request>
      <Step>
        <Condition>property operator "value"</Condition>
        <Name>policy_name</Name>
      </Step>
      ...
    </Request>
    <Response>
      <Step>
        <Condition>property operator "value"</Condition>
        <Name>policy_name</Name>
      </Step>
      ...
    </Response>
  </Flow>
</Flows>

Все дочерние элементы <Flows> являются необязательными.

Пример 1

В следующем примере показан простой элемент <Flows> с одним элементом <Flow> : 

<!-- api-platform/reference/examples/flow-segments/flows-1.xml -->
<ProxyEndpoint name="default">
  <Flows name="my-conditional-flows">
    <Flow name="reports">
      <Request>
        <Description>Based on the path suffix, determine which flow to use</Description>
        <Step>
          <Condition>proxy.pathsuffix MatchesPath "/reports"</Condition>
          <Name>XML-to-JSON-1</Name>
        </Step>
        <Step>
          <Condition>proxy.pathsuffix MatchesPath "/forecasts"</Condition>
          <Name>Verify-Auth-1</Name>
        </Step>
      </Request>
    </Flow>
  </Flows>
  ...
</ProxyEndpoint>

Edge выполняет одну из этих политик на основе суффикса пути, который он получает из переменной потока proxy . Если суффикс пути не соответствует ни одному из условий, Edge не выполняет этот поток.

Пример 2

В следующем примере показано несколько элементов <Flow> внутри <Flows> , каждый со своим собственным <Condition> : 

<!-- api-platform/reference/examples/flow-segments/flows-2.xml -->
<ProxyEndpoint name="default">
  <Flows>
    <Flow name="my-flow-1">
      <Response>
        <Step>
          <Condition>response.status.code = 200</Condition>
          <Name>Assign-Message-1</Name>
        </Step>
      </Response>
    </Flow>
    <Flow name="my-flow-2">
      <Response>
        <Step>
          <Condition>response.status.code >= 400</Condition>
          <Name>Assign-Message-2</Name>
        </Step>
      </Response>
    </Flow>
    <Flow name="my-flow-3">
      <Response>
        <Step>
          <Condition>response.status.code >= 300</Condition>
          <Name>Assign-Message-3</Name>
        </Step>
      </Response>
    </Flow>
  </Flows>
  ...
</ProxyEndpoint>

Edge выполняет только первый поток в сегменте, условие которого истинно. После этого Edge пропускает остальные потоки в сегменте.

Пример 3

В следующем примере показан " <Flow> по умолчанию": 

<!-- api-platform/reference/examples/flow-segments/flows-3.xml -->
<ProxyEndpoint name="default">
  <Flows>
    <Flow name="my-conditional-flow-1">
      <Response>
        <Step>
          <Condition>response.status.code = 200</Condition>
          <Name>Assign-Message-1</Name>
        </Step>
      </Response>
    </Flow>
    <Flow name="my-conditional-flow-2">
      <Response>
        <Step>
          <Condition>response.header.someheader = "42"</Condition>
          <Name>Assign-Message-2</Name>
        </Step>
      </Response>
    </Flow>
    <Flow name="my-default-flow">
      <Response>
        <Step>
          <Name>Assign-Message-3</Name>
        </Step>
      </Response>
    </Flow>
  </Flows>
  ...
</ProxyEndpoint>

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

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

Атрибуты

Элемент <Flows> не имеет атрибутов.

Дочерние элементы

Элемент <Flows> имеет следующие дочерние элементы:

Дочерний элемент Тип Описание
<Flow> Сложный объект Схема, определяющая один из возможных наборов шагов в рамках условного потока.

<Name>

Указывает идентификатор политики, которая должна быть выполнена в рамках <Flow> .

Тип Нить
Родительский элемент(ы) <Step>
Дочерний(е) элемент(ы) Никто

Синтаксис

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

<Name>policy_name</Name>

Пример

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

<!-- api-platform/reference/examples/flow-segments/name-1.xml -->
<ProxyEndpoint name="default">
  <Flows name="my-conditional-flows">
    <Flow name="reports">
      <Request>
        <Description>Based on the path suffix, determine which flow to use</Description>
        <Step>
          <Condition>proxy.pathsuffix MatchesPath "/reports"</Condition>
          <Name>XML-to-JSON-1</Name>
        </Step>
        <Step>
          <Condition>proxy.pathsuffix MatchesPath "/forecasts"</Condition>
          <Name>Verify-Auth-1</Name>
        </Step>
      </Request>
    </Flow>
  </Flows>
  ...
</ProxyEndpoint>

Атрибуты

Элемент <Name> не имеет атрибутов.

Дочерние элементы

Элемент <Name> не имеет дочерних элементов.

<PostFlow>

Определяет шаги, которые необходимо предпринять в постфактуме запроса и ответа.

Тип Сложный объект
Родительский элемент(ы) <ProxyEndpoint>
<TargetEndpoint>
Дочерний(е) элемент(ы) <Description>
<Request>
<Response>

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

Синтаксис 

<PostFlow name="flow_name">
  <Description>flow_description</Description>
  <Request>
    <Step>
      <Condition>property operator "value"</Condition>
      <Name>policy_name</Name>
    </Step>
    ...
  </Request>
  <Response>
    <Step>
      <Condition>property operator "value"</Condition>
      <Name>policy_name</Name>
    </Step>
    ...
  </Response>
</PostFlow>

Пример

В следующем примере показана процедура PostFlow с определенными шагами как для запроса, так и для ответа: 

<!-- api-platform/reference/examples/flow-segments/postflow-1.xml -->
<ProxyEndpoint name="default">
  <PostFlow name="my-postflows">
    <Description>My first PostFlow</Description>
    <Request>
      <Step>
        <Condition>request.verb = "GET"</Condition>
        <Name>Log-Request-OK</Name>
      </Step>
    </Request>
    <Response>
      <Step>
        <Name>Set-Response-Headers</Name>
      </Step>
    </Response>
  </PostFlow>
  ...
</ProxyEndpoint>

Атрибуты

В следующей таблице описаны атрибуты элемента <PostFlow> :

Атрибут Тип Описание
name Нить Уникальный идентификатор для потока (уникальный в пределах конечной точки). Например, "My-PostFlow-1". Значение не может содержать пробелы или другие специальные символы.

Дочерние элементы

В следующей таблице описаны дочерние элементы <PostFlow> :

Дочерний элемент Тип Описание
<Description> Нить Дает краткое описание процесса.
<Request> Сложный объект Определяет политики, которые должны быть выполнены во время обработки запроса после его завершения.
<Response> Сложный объект Определяет политики, которые должны быть выполнены в процессе обработки ответа (PostFlow).

<PostClientFlow>

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

Тип Сложный объект
Родительский элемент(ы) <ProxyEndpoint>
Дочерний(е) элемент(ы) <Description>
<Response>

Синтаксис

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

<PostClientFlow name="flow_name">
  <Description>flow_description</Description>
  <Response>
    <Step>
      <Condition>property operator "value"</Condition>
      <Name>policy_name</Name>
    </Step>
    ...
  </Response>
</PostClientFlow>

Все дочерние элементы <PostClientFlow> являются необязательными.

Пример

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

<!-- api-platform/reference/examples/flow-segments/postclientflow-1.xml -->
<ProxyEndpoint name="default">
  <PostClientFlow name="my-postclientflows">
    <Description>My first PostClientFlow. Processed after the response is sent back to the client.</Description>
    <Response>
      <Step>
        <Name>Message-Logging-OK</Name>
      </Step>
    </Response>
  </PostClientFlow>
  ...
</ProxyEndpoint>

Атрибуты

В следующей таблице описаны атрибуты элемента <PostClientFlow> :

Атрибут Тип Описание
name Нить Уникальный идентификатор для потока. Имя не может содержать пробелов или других специальных символов. Например, "My-PostClientFlow-1".

Дочерние элементы

В следующей таблице описаны дочерние элементы <PostClientFlow> :

Дочерний элемент Тип Описание
<Description> Нить Дает краткое описание процесса.
<Response> Сложный объект Определяет политики, которые должны быть выполнены в процессе обработки ответа (PostFlow).

<PreFlow>

Определяет политики, которые должны быть выполнены на этапе предварительного выполнения запроса и ответа.

Тип Сложный объект
Родительский элемент(ы) <ProxyEndpoint>
<TargetEndpoint>
Дочерний(е) элемент(ы) <Description>
<Request>
<Response>

Синтаксис

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

<PreFlow name="flow_name">
  <Description>flow_description</Description>
  <Request>
    <Step>
      <Condition>property operator "value"</Condition>
      <Name>policy_name</Name>
    </Step>
    ...
  </Request>
  <Response>
    <Step>
      <Condition>property operator "value"</Condition>
      <Name>policy_name</Name>
    </Step>
    ...
  </Response>
</PreFlow>

Все дочерние элементы <PreFlow> являются необязательными.

Пример

В следующем примере показана предварительная обработка запроса (PreFlow) с определенными потоками запроса и ответа: 

<!-- api-platform/reference/examples/flow-segments/preflow-1.xml -->
<ProxyEndpoint name="default">
  <PreFlow name="my-preFlows">
    <Description>My first PreFlow</Description>
    <Request>
      <Step>
        <Condition>request.verb = "GET"</Condition>
        <Name>Log-Request-OK</Name>
      </Step>
    </Request>
    <Response>
      <Step>
        <Condition>response.status.code LesserThanOrEquals 300</Condition>
        <Name>Log-Response-OK</Name>
      </Step>
      <Step>
        <Condition>response.status.code GreaterThan 300</Condition>
        <Name>Log-Response-NOT-OK</Name>
      </Step>
    </Response>
  </PreFlow>
  ...
</ProxyEndpoint>

Атрибуты

В следующей таблице описаны атрибуты элемента <PreFlow> :

Атрибут Тип Описание
name Нить Уникальный идентификатор для потока. Имя не может содержать пробелов или других специальных символов. Например, "My-PreFlow-1".

Дочерние элементы

В следующей таблице описаны дочерние элементы <PreFlow> :

Дочерний элемент Тип Описание
<Description> Нить Дает краткое описание процесса.
<Request> Сложный объект Определяет политики, которые должны быть выполнены на этапе предварительной обработки запроса.
<Response> Сложный объект Определяет политики, которые должны быть выполнены в ходе предварительной обработки ответа.

<Request>

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

Тип Сложный объект
Родительский элемент(ы) <Flow>
<PreFlow>
<PostFlow>
Дочерний(е) элемент(ы) <Condition>
<Step>

Синтаксис

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

<Request>
  <Step>
    <Condition>property operator "value"</Condition>
    <Name>policy_name</Name>
  </Step>
  ...
</Request>

Все дочерние элементы <Request> являются необязательными.

Пример

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

<!-- api-platform/reference/examples/flow-segments/request-1.xml -->
<ProxyEndpoint name="default">
  <PreFlow name="my-preFlows">
    <Description>My first PreFlow</Description>
    <Request>
      <Step>
        <Condition>request.verb = "GET"</Condition>
        <Name>Log-Request-OK</Name>
      </Step>
    </Request>
  </PreFlow>
  <PostFlow name="my-postflows">
    <Description>My first PostFlow</Description>
    <Request>
      <Step>
        <Condition>request.verb = "GET"</Condition>
        <Name>Log-Request-OK</Name>
      </Step>
    </Request>
  </PostFlow>
  ...
</ProxyEndpoint>

Атрибуты

Элемент <Request> не имеет атрибутов.

Дочерние элементы

В следующей таблице описаны дочерние элементы <Request> :

Дочерний элемент Тип Описание
<Condition> Сложный объект Определяет, будут ли выполнены шаги в рамках сегмента запроса.
<Step> Нить Указывает политику, которая должна быть выполнена в рамках сегмента запроса.

<Response>

Определяет политики, которые должны быть выполнены на этапе ответа в рамках потока.

Тип Сложный объект
Родительский элемент(ы) <Flow>
<PreFlow>
<PostClientFlow>
<PostFlow>
Дочерний(е) элемент(ы) <Condition>
<Step>

Синтаксис

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

<Response>
  <Step>
    <Condition>property operator "value"</Condition>
    <Name>policy_name</Name>
  </Step>
  ...
</Response>

Все дочерние элементы <Response> являются необязательными.

Пример

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

<!-- api-platform/reference/examples/flow-segments/response-1.xml -->
<ProxyEndpoint name="default">
    <PreFlow name="my-preFlows">
        <Description>My first PreFlow</Description>
        <Response>
            <Step>
                <Condition>response.status.code LesserThanOrEquals 300</Condition>
                <Name>Log-Response-OK</Name>
            </Step>
            <Step>
                <Condition>response.status.code GreaterThan 300</Condition>
                <Name>Log-Response-NOT-OK</Name>
            </Step>
        </Response>
    </PreFlow>
    <PostFlow name="my-postflows">
        <Description>My first PostFlow</Description>
        <Response>
            <Step>
                <Name>Set-Response-Headers</Name>
            </Step>
        </Response>
    </PostFlow>
  ...
</ProxyEndpoint>

Атрибуты

Элемент <Response> не имеет атрибутов.

Дочерние элементы

В следующей таблице описаны дочерние элементы элемента <Response> :

Дочерний элемент Тип Описание
<Condition> Нить Определяет, будут ли выполнены шаги в рамках сегмента ответа.
<Step> Нить Указывает политику, которая должна быть выполнена в сегменте ответа.

<Step>

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

Тип Сложный объект
Родительский элемент(ы) <Request>
<Response>
Дочерний(е) элемент(ы) <Condition>
<Name>

В <Flow> может быть определено более одного шага, и эти шаги выполняются в том порядке, в котором они определены в XML-файле потока.

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

Синтаксис

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

<Step>
  <Condition>property operator "value"</Condition>
  <Name>policy_name</Name>
</Step>

На каждом <Step> может быть только одно <Condition> и одно <Name> , но в <Flow> может быть несколько этапов.

Все дочерние элементы <Step> являются необязательными.

Пример 1

В следующем примере показан один шаг с условием и один шаг без условия: 

<!-- api-platform/reference/examples/flow-segments/step-1.xml -->
<ProxyEndpoint name="default">
  <PostFlow name="my-postflows">
      <Description>My first PostFlow</Description>
      <Request>
          <Step>
              <Condition>request.verb = "GET"</Condition>
              <Name>Log-Request-OK</Name>
          </Step>
      </Request>
      <Response>
          <Step>
              <Name>Set-Response-Headers</Name>
          </Step>
      </Response>
  </PostFlow>
  ...
</ProxyEndpoint>

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

Пример 2

Следующий пример демонстрирует несколько шагов в одном сегменте: 

<!-- api-platform/reference/examples/flow-segments/step-2.xml -->
<ProxyEndpoint name="default">
    <PostFlow name="PostFlow">
        <Response>
            <Step>
                <Name>Assign-Message-1</Name>
            </Step>
            <Step>
                <Name>Assign-Message-2</Name>
            </Step>
        </Response>
    </PostFlow>
  ...
</ProxyEndpoint>

Шаги без условия всегда выполняются.

Атрибуты

Элемент <Step> не имеет атрибутов.

Дочерние элементы

В следующей таблице описаны дочерние элементы элемента <Step> :

Дочерний элемент Тип Описание
<Condition> Нить Определяет условное выражение для шага, обрабатываемого во время выполнения. Если выражение истинно, Edge выполняет этот шаг. Если выражение ложно, Edge пропускает этот шаг.
<Name> Нить Указывает идентификатор политики, которая должна быть выполнена в текущем потоке.
,

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

В этом разделе представлена ​​справочная информация об XML-элементах, используемых для определения потоков прокси-сервера API.

Иерархия и синтаксис

Следующие примеры демонстрируют иерархию элементов и синтаксис элементов конфигурации потока:

Иерархия элементов

В следующем примере показана иерархия элементов конфигурации потока внутри элементов <ProxyEndpoint> и <TargetEndpoint> :

<ProxyEndpoint | TargetEndpoint>
    <PreFlow>
          <Request>
                <Step>
                    <Condition>
                    <Name>
          <Response>
                <Step>
                    <Condition>
                    <Name>
          <Description>
    <Flows>
          <Flow>
                <Description>
                <Condition>
                <Request>
                      <Step>
                          
                <Response>
                      <Step>
                          
          <Description>
    <PostFlow>
          <Request>
                <Step>
                    
          <Response>
                <Step>
                    
          <Description>
    <PostClientFlow> (<ProxyEndpoint> only)
          <Response>
                
          <Description>

      // Additional configuration elements

</ProxyEndpoint | TargetEndpoint>

Синтаксис

В следующем примере показан синтаксис элементов конфигурации потока. Каждый из этих элементов подробно описан в следующих разделах:

<!-- ProxyEndpoint flow configuration file -->
<ProxyEndpoint ... >
  ...
  <PreFlow name="flow_name">
    <Description>flow_description</Description>
    <Request>
      <Step>
        <Condition>property operator "value"</Condition>
        <Name>policy_name</Name>
      </Step>
      ...
    </Request>
    <Response>
      <Step>
        <Condition>property operator "value"</Condition>
        <Name>policy_name</Name>
      </Step>
      ...
    </Response>
  </PreFlow>
  <Flows name="flow_name">
    <Flow name="conditional_flow_name">
      <Description>flow_description</Description>
      <Condition>property operator "value"</Condition>
      <Request>
        <Step>
          <Condition>property operator "value"</Condition>
          <Name>policy_name</Name>
        </Step>
        ...
      </Request>
      <Response>
        <Step>
          <Condition>property operator "value"</Condition>
          <Name>policy_name</Name>
        </Step>
        ...
      </Response>
    </Flow>
  </Flows>
  <PostFlow name="flow_name">
    <Description>flow_description</Description>
    <Request>
      <Step>
        <Condition>property operator "value"</Condition>
        <Name>policy_name</Name>
      </Step>
      ...
    </Request>
    <Response>
      <Step>
        <Condition>property operator "value"</Condition>
        <Name>policy_name</Name>
      </Step>
      ...
    </Response>
  </PostFlow>
  <PostClientFlow name="flow_name">
    <Description>flow_description</Description>
    <Response>
      <Step>
        <Condition>property operator "value"</Condition>
        <Name>policy_name</Name>
      </Step>
      ...
    </Response>
  </PostClientFlow>
  ...
</ProxyEndpoint>

<!-- TargetEndpoint flow configuration file -->
<TargetEndpoint ... >
  ...
  <PreFlow name="flow_name">
    <Description>flow_description</Description>
    <Request>
      <Step>
        <Condition>property operator "value"</Condition>
        <Name>policy_name</Name>
      </Step>
      ...
    </Request>
    <Response>
      <Step>
        <Condition>property operator "value"</Condition>
        <Name>policy_name</Name>
      </Step>
      ...
    </Response>
  </PreFlow>
  <Flows name="flow_name">
    <Flow name="conditional_flow_name">
      <Description>flow_description</Description>
      <Condition>property operator "value"</Condition>
      <Request>
        <Step>
          <Condition>property operator "value"</Condition>
          <Name>policy_name</Name>
        </Step>
        ...
      </Request>
      <Response>
        <Step>
          <Condition>property operator "value"</Condition>
          <Name>policy_name</Name>
        </Step>
        ...
      </Response>
    </Flow>
    ...
  </Flows>
  <PostFlow name="flow_name">
    <Description>flow_description</Description>
    <Request>
      <Step>
        <Condition>property operator "value"</Condition>
        <Name>policy_name</Name>
      </Step>
      ...
    </Request>
    <Response>
      <Step>
        <Condition>property operator "value"</Condition>
        <Name>policy_name</Name>
      </Step>
      ...
    </Response>
  </PostFlow>
  ...
</TargetEndpoint>

Эти элементы используются для определения этапов выполнения PreFlow, Conditional Flow, PostFlow и PostClientFlow.

<Condition>

Определяет оператор, который обрабатывается во время выполнения. Если оператор оценивается как истинный, то выполняется шаг или поток, связанный с условием. Если оператор оценивается как ложный, то шаг или поток игнорируется.

Тип Нить
Родительский элемент(ы) <Flow>
<Step>
Дочерний(е) элемент(ы) Никто

В зависимости от того, поместите ли вы элемент в элемент <Flow> или <Step> , вы можете применить условие к конкретному шагу или ко всему процессу целиком:

// Condition can apply to just one step:        // Or to the flow:
<Flows>                                         <Flows>
  <Flow>                                          <Flow>
    <Step>                                          <Condition>
      <Condition>                                   <Step>
      <Name>                                          <Name>
      ...                                             ...
    ...                                             ...
  ...                                             ...
</Flows>                                        </Flows>

Если условие в рамках шага <Step> истинно, Edge выполняет этот шаг. Если условие ложно, Edge пропускает шаг.

Если условие в потоке <Flow> истинно, Edge обрабатывает все шаги потока. Если условие ложно, Edge пропускает весь поток.

Синтаксис

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

<Condition>property operator "value"</Condition>

Где:

property
Свойство переменной потока, которое вы хотите использовать в своем условии. Например, переменная потока request имеет свойства с именами path и content . Чтобы использовать их в условии, укажите свойство flow_variable [точка] property_name :
request.path
request.content

Полный список переменных потока и их свойств см. в справочнике по переменным потока .

operator
Конструкция, определяющая способ оценки вашего условия. К распространённым операторам относятся:
>     greater than           <=    less than or equal to
<     less than              >=    greater than or equal to
=     equals                 &&    and
!=    not equals             ||    or

~~    JavaRegex
~     Matches
/~    MatchesPath

Полный список см. в разделе «Операторы» в справочнике «Условия».

" value "
Значение, относительно которого оценивается свойство переменной потока. Обычно это базовый тип, например, целое число или строка. Например, 200 или "/cat". Значение может включать подстановочные знаки, такие как звездочки и другие символы для сопоставления с шаблоном, как описано в разделе "Сопоставление с шаблоном с помощью условных операторов" .

Пример 1

В следующем примере проверяется, имеет ли свойство verb переменной потока request значение "GET":

<!-- api-platform/reference/examples/flow-segments/condition-1.xml -->
<ProxyEndpoint name="default">
  <PreFlow name="my-preFlows">
    <Description>My first PreFlow</Description>
    <Request>
      <Step>
        <Condition>request.verb = "GET"</Condition>
        <Name>Log-Request-OK</Name>
      </Step>
    </Request>
  </PreFlow>
  ...
</ProxyEndpoint>

Если запрос имеет тип "GET", то в этом примере выполняется политика "Log-Request-OK".

Пример 2

В следующем примере проверяется код ответа:

<!-- api-platform/reference/examples/flow-segments/condition-2.xml -->
<ProxyEndpoint name="default">
  <PreFlow name="my-preFlows">
    <Description>My first PreFlow</Description>
    <Response>
      <Step>
        <Condition>response.status.code LesserThanOrEquals 300</Condition>
        <Name>Log-Response-OK</Name>
      </Step>
      <Step>
        <Condition>response.status.code GreaterThan 300</Condition>
        <Name>Log-Response-NOT-OK</Name>
      </Step>
    </Response>
  </PreFlow>
  ...
</ProxyEndpoint>

В зависимости от значения кода выполняется разная политика.

Атрибуты

Элемент <Condition> не имеет атрибутов.

Дочерние элементы

Элемент <Condition> не имеет дочерних элементов.

<Description>

Описывает процесс в удобочитаемом виде. Используйте этот элемент для предоставления информации о процессе себе или другим разработчикам. Описание не отображается для внешнего просмотра.

Тип Нить
Родительский элемент(ы) <Flow>
<PreFlow>
<PostFlow>
Дочерний(е) элемент(ы) Никто

Синтаксис

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

<Description>flow_description</Description>

Пример

В следующем примере показан элемент <Description> , который определяет назначение потока: 

<!-- api-platform/reference/examples/flow-segments/description-1.xml -->
<ProxyEndpoint name="default">
  <Flows name="my-conditional-flows">
    <Flow name="reports">
      <Request>
        <Description>Based on the path suffix, determine which flow to use</Description>
        <Step>
          <Condition>proxy.pathsuffix MatchesPath "/reports"</Condition>
          <Name>XML-to-JSON-1</Name>
        </Step>
        <Step>
          <Condition>proxy.pathsuffix MatchesPath "/forecasts"</Condition>
          <Name>XML-to-JSON-1</Name>
        </Step>
      </Request>
    </Flow>
  </Flows>
  ...
</ProxyEndpoint>

Атрибуты

Элемент <Description> не имеет атрибутов.

Дочерние элементы

Элемент <Description> не имеет дочерних элементов.

<Flow>

Определяет пользовательский набор шагов, которые выполняет Edge.

Тип Сложный объект
Родительский элемент(ы) <Flows>
Дочерний(е) элемент(ы) <Condition>
<Description>
<Request>
<Response>

При желании можно указать <Condition> для <Flow> . В этом случае Edge будет выполнять шаги потока только в том случае, если условие истинно. В противном случае Edge пропустит весь поток.

Элемент <Flows> может содержать несколько элементов <Flow> , каждый со своим условием и шагами. При наличии нескольких элементов <Flow> Edge выполняет только первый из них, в котором нет условия или условие оценивается как истинное.

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

Синтаксис

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

<Flow name="conditional_flow_name">
  <Description>flow_description</Description>
  <Condition>property operator "value"</Condition>
  <Request>
    <Step>
      <Condition>property operator "value"</Condition>
      <Name>policy_name</Name>
    </Step>
    ...
  </Request>
  <Response>
    <Step>
      <Condition>property operator "value"</Condition>
      <Name>policy_name</Name>
    </Step>
    ...
  </Response>
</Flow>

Все дочерние элементы <Flow> являются необязательными.

Пример 1

В следующем примере показан простой <Flow> , который всегда выполняет политику "Log-Message-OK": 

<!-- api-platform/reference/examples/flow-segments/flow-1.xml -->
<ProxyEndpoint name="default">
  <Flows name="my-flow">
    <Flow>
      <Request>
        <Step>
          <Name>Log-Message-OK</Name>
        </Step>
      </Request>
    </Flow>
  </Flows>
  ...
</ProxyEndpoint>

Пример 2

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

<!-- api-platform/reference/examples/flow-segments/flow-2.xml -->
<ProxyEndpoint name="default">
  <Flows name="my-conditional-flows">
    <Flow name="reports">
      <Request>
        <Description>Based on the path suffix, determine which flow to use</Description>
        <Step>
          <Condition>proxy.pathsuffix MatchesPath "/reports"</Condition>
          <Name>XML-to-JSON-1</Name>
        </Step>
        <Step>
          <Condition>proxy.pathsuffix MatchesPath "/forecasts"</Condition>
          <Name>Verify-Auth-1</Name>
        </Step>
      </Request>
    </Flow>
  </Flows>
  ...
</ProxyEndpoint>

Пример 3

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

<!-- api-platform/reference/examples/flow-segments/flows-2.xml -->
<ProxyEndpoint name="default">
  <Flows>
    <Flow name="my-flow-1">
      <Response>
        <Step>
          <Condition>response.status.code = 200</Condition>
          <Name>Assign-Message-1</Name>
        </Step>
      </Response>
    </Flow>
    <Flow name="my-flow-2">
      <Response>
        <Step>
          <Condition>response.status.code >= 400</Condition>
          <Name>Assign-Message-2</Name>
        </Step>
      </Response>
    </Flow>
    <Flow name="my-flow-3">
      <Response>
        <Step>
          <Condition>response.status.code >= 300</Condition>
          <Name>Assign-Message-3</Name>
        </Step>
      </Response>
    </Flow>
  </Flows>
  ...
</ProxyEndpoint>

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

Атрибуты

В следующей таблице описаны атрибуты элемента <Flow> :

Атрибут Тип Описание
name Нить (Обязательно) Уникальный идентификатор для потока. Например, "My-Conditional-Flow-1". Имя не может содержать пробелов или других специальных символов.

Дочерние элементы

В следующей таблице описаны дочерние элементы <Flow> :

Дочерний элемент Тип Описание
<Condition> Нить Определяет условное выражение, которое обрабатывается во время выполнения. Если выражение истинно, то выполняется поток (и все его шаги). Если выражение ложно, то поток (и все его шаги) игнорируются.
<Description> Нить Предоставляет краткое описание процесса. Это описание не отображается внешне.
<Request> Сложный объект Определяет шаги и условия для сегмента запроса.
<Response> Сложный объект Определяет шаги и условия для сегмента ответа.

<Flows>

Содержит ноль или более элементов <Flow> .

Тип Сложный объект
Родительский элемент(ы) <ProxyEndpoint>
<TargetEndpoint>
Дочерний(е) элемент(ы) <Flow>

Если в элементах <Flows> присутствует несколько элементов <Flow> , будет выполнен только один элемент <Flow> . Это будет первый поток, который либо не имеет <Condition> , либо условие которого истинно.

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

Синтаксис

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

<Flows name="flow_name">
  <Flow name="conditional_flow_name">
    <Description>flow_description</Description>
    <Condition>property operator "value"</Condition>
    <Request>
      <Step>
        <Condition>property operator "value"</Condition>
        <Name>policy_name</Name>
      </Step>
      ...
    </Request>
    <Response>
      <Step>
        <Condition>property operator "value"</Condition>
        <Name>policy_name</Name>
      </Step>
      ...
    </Response>
  </Flow>
</Flows>

Все дочерние элементы <Flows> являются необязательными.

Пример 1

В следующем примере показан простой элемент <Flows> с одним элементом <Flow> : 

<!-- api-platform/reference/examples/flow-segments/flows-1.xml -->
<ProxyEndpoint name="default">
  <Flows name="my-conditional-flows">
    <Flow name="reports">
      <Request>
        <Description>Based on the path suffix, determine which flow to use</Description>
        <Step>
          <Condition>proxy.pathsuffix MatchesPath "/reports"</Condition>
          <Name>XML-to-JSON-1</Name>
        </Step>
        <Step>
          <Condition>proxy.pathsuffix MatchesPath "/forecasts"</Condition>
          <Name>Verify-Auth-1</Name>
        </Step>
      </Request>
    </Flow>
  </Flows>
  ...
</ProxyEndpoint>

Edge выполняет одну из этих политик на основе суффикса пути, который он получает из переменной потока proxy . Если суффикс пути не соответствует ни одному из условий, Edge не выполняет этот поток.

Пример 2

В следующем примере показано несколько элементов <Flow> внутри <Flows> , каждый со своим собственным <Condition> : 

<!-- api-platform/reference/examples/flow-segments/flows-2.xml -->
<ProxyEndpoint name="default">
  <Flows>
    <Flow name="my-flow-1">
      <Response>
        <Step>
          <Condition>response.status.code = 200</Condition>
          <Name>Assign-Message-1</Name>
        </Step>
      </Response>
    </Flow>
    <Flow name="my-flow-2">
      <Response>
        <Step>
          <Condition>response.status.code >= 400</Condition>
          <Name>Assign-Message-2</Name>
        </Step>
      </Response>
    </Flow>
    <Flow name="my-flow-3">
      <Response>
        <Step>
          <Condition>response.status.code >= 300</Condition>
          <Name>Assign-Message-3</Name>
        </Step>
      </Response>
    </Flow>
  </Flows>
  ...
</ProxyEndpoint>

Edge выполняет только первый поток в сегменте, условие которого истинно. После этого Edge пропускает остальные потоки в сегменте.

Пример 3

В следующем примере показан " <Flow> по умолчанию": 

<!-- api-platform/reference/examples/flow-segments/flows-3.xml -->
<ProxyEndpoint name="default">
  <Flows>
    <Flow name="my-conditional-flow-1">
      <Response>
        <Step>
          <Condition>response.status.code = 200</Condition>
          <Name>Assign-Message-1</Name>
        </Step>
      </Response>
    </Flow>
    <Flow name="my-conditional-flow-2">
      <Response>
        <Step>
          <Condition>response.header.someheader = "42"</Condition>
          <Name>Assign-Message-2</Name>
        </Step>
      </Response>
    </Flow>
    <Flow name="my-default-flow">
      <Response>
        <Step>
          <Name>Assign-Message-3</Name>
        </Step>
      </Response>
    </Flow>
  </Flows>
  ...
</ProxyEndpoint>

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

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

Атрибуты

Элемент <Flows> не имеет атрибутов.

Дочерние элементы

Элемент <Flows> имеет следующие дочерние элементы:

Дочерний элемент Тип Описание
<Flow> Сложный объект Схема, определяющая один из возможных наборов шагов в рамках условного потока.

<Name>

Указывает идентификатор политики, которая должна быть выполнена в рамках <Flow> .

Тип Нить
Родительский элемент(ы) <Step>
Дочерний(е) элемент(ы) Никто

Синтаксис

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

<Name>policy_name</Name>

Пример

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

<!-- api-platform/reference/examples/flow-segments/name-1.xml -->
<ProxyEndpoint name="default">
  <Flows name="my-conditional-flows">
    <Flow name="reports">
      <Request>
        <Description>Based on the path suffix, determine which flow to use</Description>
        <Step>
          <Condition>proxy.pathsuffix MatchesPath "/reports"</Condition>
          <Name>XML-to-JSON-1</Name>
        </Step>
        <Step>
          <Condition>proxy.pathsuffix MatchesPath "/forecasts"</Condition>
          <Name>Verify-Auth-1</Name>
        </Step>
      </Request>
    </Flow>
  </Flows>
  ...
</ProxyEndpoint>

Атрибуты

Элемент <Name> не имеет атрибутов.

Дочерние элементы

Элемент <Name> не имеет дочерних элементов.

<PostFlow>

Определяет шаги, которые необходимо предпринять в постфактуме запроса и ответа.

Тип Сложный объект
Родительский элемент(ы) <ProxyEndpoint>
<TargetEndpoint>
Дочерний(е) элемент(ы) <Description>
<Request>
<Response>

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

Синтаксис 

<PostFlow name="flow_name">
  <Description>flow_description</Description>
  <Request>
    <Step>
      <Condition>property operator "value"</Condition>
      <Name>policy_name</Name>
    </Step>
    ...
  </Request>
  <Response>
    <Step>
      <Condition>property operator "value"</Condition>
      <Name>policy_name</Name>
    </Step>
    ...
  </Response>
</PostFlow>

Пример

В следующем примере показана процедура PostFlow с определенными шагами как для запроса, так и для ответа: 

<!-- api-platform/reference/examples/flow-segments/postflow-1.xml -->
<ProxyEndpoint name="default">
  <PostFlow name="my-postflows">
    <Description>My first PostFlow</Description>
    <Request>
      <Step>
        <Condition>request.verb = "GET"</Condition>
        <Name>Log-Request-OK</Name>
      </Step>
    </Request>
    <Response>
      <Step>
        <Name>Set-Response-Headers</Name>
      </Step>
    </Response>
  </PostFlow>
  ...
</ProxyEndpoint>

Атрибуты

В следующей таблице описаны атрибуты элемента <PostFlow> :

Атрибут Тип Описание
name Нить Уникальный идентификатор для потока (уникальный в пределах конечной точки). Например, "My-PostFlow-1". Значение не может содержать пробелы или другие специальные символы.

Дочерние элементы

В следующей таблице описаны дочерние элементы <PostFlow> :

Дочерний элемент Тип Описание
<Description> Нить Дает краткое описание процесса.
<Request> Сложный объект Определяет политики, которые должны быть выполнены во время обработки запроса после его завершения.
<Response> Сложный объект Определяет политики, которые должны быть выполнены в процессе обработки ответа (PostFlow).

<PostClientFlow>

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

Тип Сложный объект
Родительский элемент(ы) <ProxyEndpoint>
Дочерний(е) элемент(ы) <Description>
<Response>

Синтаксис

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

<PostClientFlow name="flow_name">
  <Description>flow_description</Description>
  <Response>
    <Step>
      <Condition>property operator "value"</Condition>
      <Name>policy_name</Name>
    </Step>
    ...
  </Response>
</PostClientFlow>

Все дочерние элементы <PostClientFlow> являются необязательными.

Пример

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

<!-- api-platform/reference/examples/flow-segments/postclientflow-1.xml -->
<ProxyEndpoint name="default">
  <PostClientFlow name="my-postclientflows">
    <Description>My first PostClientFlow. Processed after the response is sent back to the client.</Description>
    <Response>
      <Step>
        <Name>Message-Logging-OK</Name>
      </Step>
    </Response>
  </PostClientFlow>
  ...
</ProxyEndpoint>

Атрибуты

В следующей таблице описаны атрибуты элемента <PostClientFlow> :

Атрибут Тип Описание
name Нить Уникальный идентификатор для потока. Имя не может содержать пробелов или других специальных символов. Например, "My-PostClientFlow-1".

Дочерние элементы

В следующей таблице описаны дочерние элементы <PostClientFlow> :

Дочерний элемент Тип Описание
<Description> Нить Дает краткое описание процесса.
<Response> Сложный объект Определяет политики, которые должны быть выполнены в процессе обработки ответа (PostFlow).

<PreFlow>

Определяет политики, которые должны быть выполнены на этапе предварительного выполнения запроса и ответа.

Тип Сложный объект
Родительский элемент(ы) <ProxyEndpoint>
<TargetEndpoint>
Дочерний(е) элемент(ы) <Description>
<Request>
<Response>

Синтаксис

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

<PreFlow name="flow_name">
  <Description>flow_description</Description>
  <Request>
    <Step>
      <Condition>property operator "value"</Condition>
      <Name>policy_name</Name>
    </Step>
    ...
  </Request>
  <Response>
    <Step>
      <Condition>property operator "value"</Condition>
      <Name>policy_name</Name>
    </Step>
    ...
  </Response>
</PreFlow>

Все дочерние элементы <PreFlow> являются необязательными.

Пример

В следующем примере показана предварительная обработка запроса (PreFlow) с определенными потоками запроса и ответа: 

<!-- api-platform/reference/examples/flow-segments/preflow-1.xml -->
<ProxyEndpoint name="default">
  <PreFlow name="my-preFlows">
    <Description>My first PreFlow</Description>
    <Request>
      <Step>
        <Condition>request.verb = "GET"</Condition>
        <Name>Log-Request-OK</Name>
      </Step>
    </Request>
    <Response>
      <Step>
        <Condition>response.status.code LesserThanOrEquals 300</Condition>
        <Name>Log-Response-OK</Name>
      </Step>
      <Step>
        <Condition>response.status.code GreaterThan 300</Condition>
        <Name>Log-Response-NOT-OK</Name>
      </Step>
    </Response>
  </PreFlow>
  ...
</ProxyEndpoint>

Атрибуты

В следующей таблице описаны атрибуты элемента <PreFlow> :

Атрибут Тип Описание
name Нить Уникальный идентификатор для потока. Имя не может содержать пробелов или других специальных символов. Например, "My-PreFlow-1".

Дочерние элементы

В следующей таблице описаны дочерние элементы <PreFlow> :

Дочерний элемент Тип Описание
<Description> Нить Дает краткое описание процесса.
<Request> Сложный объект Определяет политики, которые должны быть выполнены на этапе предварительной обработки запроса.
<Response> Сложный объект Определяет политики, которые должны быть выполнены в ходе предварительной обработки ответа.

<Request>

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

Тип Сложный объект
Родительский элемент(ы) <Flow>
<PreFlow>
<PostFlow>
Дочерний(е) элемент(ы) <Condition>
<Step>

Синтаксис

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

<Request>
  <Step>
    <Condition>property operator "value"</Condition>
    <Name>policy_name</Name>
  </Step>
  ...
</Request>

Все дочерние элементы <Request> являются необязательными.

Пример

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

<!-- api-platform/reference/examples/flow-segments/request-1.xml -->
<ProxyEndpoint name="default">
  <PreFlow name="my-preFlows">
    <Description>My first PreFlow</Description>
    <Request>
      <Step>
        <Condition>request.verb = "GET"</Condition>
        <Name>Log-Request-OK</Name>
      </Step>
    </Request>
  </PreFlow>
  <PostFlow name="my-postflows">
    <Description>My first PostFlow</Description>
    <Request>
      <Step>
        <Condition>request.verb = "GET"</Condition>
        <Name>Log-Request-OK</Name>
      </Step>
    </Request>
  </PostFlow>
  ...
</ProxyEndpoint>

Атрибуты

Элемент <Request> не имеет атрибутов.

Дочерние элементы

В следующей таблице описаны дочерние элементы <Request> :

Дочерний элемент Тип Описание
<Condition> Сложный объект Определяет, будут ли выполнены шаги в рамках сегмента запроса.
<Step> Нить Указывает политику, которая должна быть выполнена в рамках сегмента запроса.

<Response>

Определяет политики, которые должны быть выполнены на этапе ответа в рамках потока.

Тип Сложный объект
Родительский элемент(ы) <Flow>
<PreFlow>
<PostClientFlow>
<PostFlow>
Дочерний(е) элемент(ы) <Condition>
<Step>

Синтаксис

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

<Response>
  <Step>
    <Condition>property operator "value"</Condition>
    <Name>policy_name</Name>
  </Step>
  ...
</Response>

Все дочерние элементы <Response> являются необязательными.

Пример

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

<!-- api-platform/reference/examples/flow-segments/response-1.xml -->
<ProxyEndpoint name="default">
    <PreFlow name="my-preFlows">
        <Description>My first PreFlow</Description>
        <Response>
            <Step>
                <Condition>response.status.code LesserThanOrEquals 300</Condition>
                <Name>Log-Response-OK</Name>
            </Step>
            <Step>
                <Condition>response.status.code GreaterThan 300</Condition>
                <Name>Log-Response-NOT-OK</Name>
            </Step>
        </Response>
    </PreFlow>
    <PostFlow name="my-postflows">
        <Description>My first PostFlow</Description>
        <Response>
            <Step>
                <Name>Set-Response-Headers</Name>
            </Step>
        </Response>
    </PostFlow>
  ...
</ProxyEndpoint>

Атрибуты

Элемент <Response> не имеет атрибутов.

Дочерние элементы

В следующей таблице описаны дочерние элементы элемента <Response> :

Дочерний элемент Тип Описание
<Condition> Нить Определяет, будут ли выполнены шаги в рамках сегмента ответа.
<Step> Нить Указывает политику, которая должна быть выполнена в сегменте ответа.

<Step>

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

Тип Сложный объект
Родительский элемент(ы) <Request>
<Response>
Дочерний(е) элемент(ы) <Condition>
<Name>

В <Flow> может быть определено более одного шага, и эти шаги выполняются в том порядке, в котором они определены в XML-файле потока.

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

Синтаксис

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

<Step>
  <Condition>property operator "value"</Condition>
  <Name>policy_name</Name>
</Step>

На каждом <Step> может быть только одно <Condition> и одно <Name> , но в <Flow> может быть несколько этапов.

Все дочерние элементы <Step> являются необязательными.

Пример 1

В следующем примере показан один шаг с условием и один шаг без условия: 

<!-- api-platform/reference/examples/flow-segments/step-1.xml -->
<ProxyEndpoint name="default">
  <PostFlow name="my-postflows">
      <Description>My first PostFlow</Description>
      <Request>
          <Step>
              <Condition>request.verb = "GET"</Condition>
              <Name>Log-Request-OK</Name>
          </Step>
      </Request>
      <Response>
          <Step>
              <Name>Set-Response-Headers</Name>
          </Step>
      </Response>
  </PostFlow>
  ...
</ProxyEndpoint>

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

Пример 2

Следующий пример демонстрирует несколько шагов в одном сегменте: 

<!-- api-platform/reference/examples/flow-segments/step-2.xml -->
<ProxyEndpoint name="default">
    <PostFlow name="PostFlow">
        <Response>
            <Step>
                <Name>Assign-Message-1</Name>
            </Step>
            <Step>
                <Name>Assign-Message-2</Name>
            </Step>
        </Response>
    </PostFlow>
  ...
</ProxyEndpoint>

Шаги без условия всегда выполняются.

Атрибуты

Элемент <Step> не имеет атрибутов.

Дочерние элементы

В следующей таблице описаны дочерние элементы элемента <Step> :

Дочерний элемент Тип Описание
<Condition> Нить Определяет условное выражение для шага, обрабатываемого во время выполнения. Если выражение истинно, Edge выполняет этот шаг. Если выражение ложно, Edge пропускает этот шаг.
<Name> Нить Указывает идентификатор политики, которая должна быть выполнена в текущем потоке.