Referencia de configuración de flujo

Estás viendo la documentación de Apigee X.
Consulta la documentación de Apigee Edge.

En esta sección, se proporciona información de referencia sobre los elementos XML que usas para definir tus flujos de proxy de API.

Jerarquía y sintaxis

En los siguientes ejemplos, se muestra la jerarquía de elementos y la sintaxis de los elementos de configuración de flujo:

Jerarquía de los elementos

En el siguiente ejemplo, se muestra la jerarquía de los elementos de configuración de flujo dentro de los elementos <ProxyEndpoint> y <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>

Sintaxis

En el ejemplo siguiente, se muestra la sintaxis para los elementos de configuración del flujo. Cada uno de estos elementos se describe en detalle en las secciones siguientes:

<!-- 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>

Usa estos elementos para definir tu ejecución de flujo previo, flujos condicionales, flujo posterior y flujo de cliente posterior.

<Condition>

Define una declaración que se procesa en el entorno de ejecución. Si la declaración se evalúa como verdadera, entonces el paso o flujo asociado con la condición se ejecuta. Si la declaración se evalúa como falsa, se ignora el paso o flujo.

Tipo String
Elementos superiores <Flow>
<Step>
Elementos secundarios Ninguno

Puedes aplicar una condición a un paso específico o a un flujo completo, según si colocas el elemento en el elemento <Flow> o <Step>:

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

Si una condición dentro de un <Step> se evalúa como verdadera, Apigee ejecuta ese paso. Si la condición se evalúa como falsa, Apigee omite el paso.

Si una condición dentro de <Flow> se evalúa como verdadera, Apigee procesa todos los pasos del flujo. Si la condición se evalúa como falsa, Apigee omite todo el flujo.

Sintaxis

El elemento <Condition> usa la siguiente sintaxis:

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

Aquí:

property
La propiedad de variable de flujo que quieres usar en tu condición. Por ejemplo, la variable de flujo request tiene propiedades llamadas path y content. Para usarlos en una condición, especifica el flow_variable[dot]property_name:
request.path
request.content

Para obtener una lista completa de las variables de flujo y sus propiedades, consulta Referencia de variables de flujo.

operator
Una construcción que define cómo se evalúa tu condición. En los operadores comunes, se incluyen los siguientes:
>     greater than           <=    less than or equal to
<     less than              >=    greater than or equal to
=     equals                 &&    and
!=    not equals             ||    or

~~    JavaRegex
~     Matches
/~    MatchesPath

Para obtener una lista completa, consulta Operadores en la referencia de condiciones.

"value"
El valor con el que se evalúa la propiedad de la variable de flujo. Por lo general, este es un tipo básico, como un número entero o una string. Por ejemplo, 200 o /cat. El valor puede incluir comodines, como asteriscos y otros caracteres para coincidencia de patrones, como se describe en Coincidencia de patrones con condicionales.

Ejemplo 1

En el siguiente ejemplo, se verifica si la propiedad verb de la variable de flujo request es 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>

Si la solicitud es una GET, entonces este ejemplo ejecuta la política Log-Request-OK.

Ejemplo 2

En el ejemplo siguiente se verifica el código de respuesta:

<!-- 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>

Según el valor del código, se ejecuta una política diferente.

Atributos

El elemento <Condition> no tiene atributos.

Elementos secundarios

El elemento <Condition> no tiene elementos secundarios.

<Description>

Describe el flujo en términos legibles. Usa este elemento para proporcionar información sobre el flujo a ti mismo o a otros desarrolladores. La descripción no es visible de forma externa.

Tipo String
Elementos superiores <Flow>
<PreFlow>
<PostFlow>
Elementos secundarios None

Sintaxis

El elemento <Description> usa la siguiente sintaxis:

<Description>flow_description</Description>

Ejemplo

En el siguiente ejemplo, se muestra un elemento <Description> que especifica el propósito de un flujo:

<!-- 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>

Atributos

El elemento <Description> no tiene atributos.

Elementos secundarios

El elemento <Description> no tiene elementos secundarios.

<Flow>

Define un conjunto personalizado de pasos que ejecuta Edge.

Tipo Objeto complejo
Elementos superiores <Flows>
Elementos secundarios <Condition>
<Description>
<Request>
<Response>

De manera opcional, puedes especificar un <Condition> en un objeto <Flow>. En ese caso, Apigee solo ejecuta los pasos del flujo si la condición se evalúa como verdadera. De lo contrario, Apigee omite todo el flujo.

Un elemento <Flows> puede contener varios elementos <Flow>, cada uno con su propia condición y pasos. Cuando hay varios elementos <Flow>, Apigee solo ejecuta el primero en el que no hay condición o la condición se evalúa como verdadera.

Puedes definir un flujo predeterminado que siempre se ejecute (si ninguno de los otros flujos condicionales funciona). Según cómo esté configurado el proxy de API, esta puede ser una herramienta útil para protegerse de ataques maliciosos.

Sintaxis

El elemento <Flow> usa la siguiente sintaxis:

<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>

Todos los elementos secundarios de <Flow> son opcionales.

Ejemplo 1

En el siguiente ejemplo, se muestra un <Flow> simple que siempre ejecuta la política “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>

Ejemplo 2

En el siguiente ejemplo, se muestra un <Flow> con varios pasos, cada uno con su propia condición:

<!-- 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>

Ejemplo 3

En el siguiente ejemplo, se muestran varios flujos en un flujo condicional:

<!-- 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>

Apigee ejecuta solo un flujo en un segmento. Ejecuta el primer flujo que no tiene una condición o cuya condición se resuelve como verdadera.

Atributos

En la siguiente tabla, se describen los atributos del elemento <Flow>:

Atributo Tipo Descripción
name String (Obligatorio) Un ID único para el flujo. Por ejemplo: My-Conditional-Flow-1. El nombre no puede contener espacios ni otros caracteres especiales.

Elementos secundarios

En la siguiente tabla, se describen los elementos secundarios de <Flow>:

Elemento secundario Tipo Descripción
<Condition> String Define una declaración condicional que se procesa en el tiempo de ejecución. Si la declaración se evalúa como verdadera, entonces el flujo (y todos sus pasos) se ejecutan. Si la declaración se evalúa como falsa, se ignora el flujo (y todos sus pasos).
<Description> String Proporciona una descripción breve del flujo. Esta descripción no es visible de forma externa.
<Request> Objeto complejo Especifica los pasos y las condiciones del segmento de solicitud.
<Response> Objeto complejo Especifica los pasos y las condiciones para el segmento de respuesta.

<Flows>

Contiene cero o más elementos <Flow>.

Tipo Objeto complejo
Elementos superiores <ProxyEndpoint>
<TargetEndpoint>
Elementos secundarios <Flow>

Si hay varios elementos <Flow> en <Flows>, solo se ejecutará un <Flow>. Este será el primer flujo que no tiene un <Condition> o cuya condición se resuelve como verdadera.

Puedes definir un flujo predeterminado que siempre se ejecute (si ninguno de los otros flujos funciona). Según cómo esté configurado el proxy de API, esta puede ser una herramienta útil para protegerse de ataques maliciosos.

Sintaxis

El elemento <Flows> usa la siguiente sintaxis:

<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>

Todos los elementos secundarios de <Flows> son opcionales.

Ejemplo 1

En el siguiente ejemplo, se muestra un elemento <Flows> simple con una sola <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>

Apigee ejecuta una de estas políticas según el sufijo de ruta que recopila de la variable de flujo proxy. Si el sufijo de la ruta de acceso no coincide con ninguna de las condiciones, Apigee no ejecuta este flujo.

Ejemplo 2

En el siguiente ejemplo, se muestran varios elementos <Flow> dentro de <Flows>, cada uno con su propio <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>

Apigee solo ejecuta el primer flujo en un segmento cuya condición se evalúe como verdadera. Después de eso, Apigee omite los flujos restantes en el segmento.

Ejemplo 3

En el siguiente ejemplo, se muestra un <Flow> "predeterminado":

<!-- 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>

Apigee solo ejecuta el primer flujo en un segmento cuya condición se evalúe como verdadera. Si no se ejecutan flujos condicionales, se ejecuta el tercer flujo en este ejemplo (sin condición).

Un flujo predeterminado puede ser una herramienta útil para protegerse contra ataques maliciosos.

Atributos

El elemento <Flows> no tiene atributos.

Elementos secundarios

El elemento <Flows> tiene los siguientes elementos secundarios:

Elemento secundario Tipo Descripción
<Flow> Objeto complejo Un flujo que define un conjunto de pasos posible dentro del flujo condicional.

<Name>

Especifica el ID de la política que se ejecutará en un <Flow>.

Tipo String
Elementos superiores <Step>
Elementos secundarios None

Sintaxis

El elemento <Name> usa la siguiente sintaxis:

<Name>policy_name</Name>

Ejemplo

En el siguiente ejemplo, se muestran dos políticas que se agregan a los flujos por su nombre:

<!-- 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>

Atributos

El elemento <Name> no tiene atributos.

Elementos secundarios

El elemento <Name> no tiene elementos secundarios.

<PostFlow>

Define los pasos que debe seguir en PostFlow para la solicitud y la respuesta.

Tipo Objeto complejo
Elementos superiores <ProxyEndpoint>
<TargetEndpoint>
Elementos secundarios <Description>
<Request>
<Response>

El elemento <PostFlow> usa la siguiente sintaxis:

Sintaxis

<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>

Ejemplo

El siguiente ejemplo muestra un PostFlow con pasos para la solicitud y la respuesta definidas:

<!-- 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>

Atributos

En la siguiente tabla, se describen los atributos del elemento <PostFlow>:

Atributo Tipo Descripción
name String Un ID único para el flujo (único dentro del extremo). Por ejemplo: My-PostFlow-1 El valor no puede incluir espacios ni otros caracteres especiales.

Elementos secundarios

En la siguiente tabla, se describen los elementos secundarios de <PostFlow>:

Elemento secundario Tipo Descripción
<Description> String Proporciona una descripción breve del flujo.
<Request> Objeto complejo Define las políticas que se ejecutarán durante PostFlow de la solicitud.
<Response> Objeto complejo Define las políticas que se ejecutarán durante el PostFlow de la respuesta.

<PostClientFlow>

Define políticas en el ProxyEndpoint que se ejecutan solo después de que se muestra una respuesta al cliente. Por lo general, estas políticas registran los mensajes relacionados con la respuesta.

Tipo Objeto complejo
Elementos superiores <ProxyEndpoint>
Elementos secundarios <Description>
<Response>

Sintaxis

El elemento <PostClientFlow> usa la siguiente sintaxis:

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

Todos los elementos secundarios de <PostClientFlow> son opcionales.

Ejemplo

En el siguiente ejemplo, se muestra un PostClientFlow simple que ejecuta una sola política:

<!-- 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>

Atributos

En la siguiente tabla, se describen los atributos del elemento <PostClientFlow>:

Atributo Tipo Descripción
name String Un ID único para el flujo. El nombre no puede incluir espacios ni otros caracteres especiales. Por ejemplo, My-PostClientFlow-1.

Elementos secundarios

En la siguiente tabla, se describen los elementos secundarios de <PostClientFlow>:

Elemento secundario Tipo Descripción
<Description> String Proporciona una descripción breve del flujo.
<Response> Objeto complejo Define las políticas que se ejecutarán durante el PostFlow de la respuesta.

<PreFlow>

Define las políticas que se ejecutarán en el PreFlow de la solicitud y la respuesta.

Tipo Objeto complejo
Elementos superiores <ProxyEndpoint>
<TargetEndpoint>
Elementos secundarios <Description>
<Request>
<Response>

Sintaxis

El elemento <PreFlow> usa la siguiente sintaxis:

<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>

Todos los elementos secundarios de <PreFlow> son opcionales.

Ejemplo

En el siguiente ejemplo, se muestra un PreFlow con un flujo de respuesta y uno de solicitud definido:

<!-- 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>

Atributos

En la siguiente tabla, se describen los atributos del elemento <PreFlow>:

Atributo Tipo Descripción
name String Un ID único para el flujo. El nombre no puede incluir espacios ni otros caracteres especiales. Por ejemplo, My-PreFlow-1.

Elementos secundarios

En la siguiente tabla, se describen los elementos secundarios de <PreFlow>:

Elemento secundario Tipo Descripción
<Description> String Proporciona una descripción breve del flujo.
<Request> Objeto complejo Define las políticas que se deben ejecutar durante el PreFlow de la solicitud.
<Response> Objeto complejo Define las políticas que se ejecutarán durante el flujo previo de respuesta.

<Request>

Define las políticas que se ejecutarán durante el segmento de solicitudes del flujo.

Tipo Objeto complejo
Elementos superiores <Flow>
<PreFlow>
<PostFlow>
Elementos secundarios <Condition>
<Step>

Sintaxis

El elemento <Request> usa la siguiente sintaxis:

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

Todos los elementos secundarios de <Request> son opcionales.

Ejemplo

En el ejemplo siguiente, se muestran flujos definidos para la solicitud tanto en PreFlow como en PostFlow:

<!-- 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>

Atributos

El elemento <Request> no tiene atributos.

Elementos secundarios

En la siguiente tabla, se describen los elementos secundarios de <Request>:

Elemento secundario Tipo Descripción
<Condition> Objeto complejo Determina si se ejecutan los pasos dentro del segmento de la solicitud.
<Step> String Especifica una política para ejecutar dentro del segmento de la solicitud.

<Response>

Define las políticas que se ejecutarán durante el segmento de respuesta del flujo.

Tipo Objeto complejo
Elementos superiores <Flow>
<PreFlow>
<PostClientFlow>
<PostFlow>
Elementos secundarios <Condition>
<Step>

Sintaxis

El elemento <Response> usa la siguiente sintaxis:

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

Todos los elementos secundarios de <Response> son opcionales.

Ejemplo

En el siguiente ejemplo, se muestran los flujos definidos para la respuesta, tanto en el flujo de flujo previo como del flujo posterior:

<!-- 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>

Atributos

El elemento <Response> no tiene atributos.

Elementos secundarios

En la siguiente tabla, se describen los elementos secundarios de <Response>:

Elemento secundario Tipo Descripción
<Condition> String Determina si se ejecutan los pasos dentro del segmento de respuesta.
<Step> String Especifica una política que se ejecutará dentro del segmento de respuesta.

<Step>

Especifica una política que se ejecutará y (opcionalmente) una condición que determina si se debe ejecutar esa política.

Tipo Objeto complejo
Elementos superiores <Request>
<Response>
Elementos secundarios <Condition>
<Name>

Puede haber más de un paso definido en un <Flow> y los pasos se ejecutan en el orden en que se definen en el XML del flujo.

Los pasos sin una condición siempre se ejecutan. Los pasos con una condición se ejecutan solo si la condición se evalúa como verdadera. Si la condición se evalúa como falsa, entonces se omite el paso.

Sintaxis

En el elemento <Step>, se usa la siguiente sintaxis:

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

Solo puede haber un <Condition> y un <Name> por <Step>, pero puede haber varios pasos en un <Flow>.

Todos los elementos secundarios de <Step> son opcionales.

Ejemplo 1

En el siguiente ejemplo, se muestra un paso con una condición y un paso sin una condición:

<!-- 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>

El paso sin la condición se ejecutará cada vez durante el segmento de solicitud. El paso con una condición se ejecutará solo cuando la solicitud sea "GET" durante el segmento de respuesta.

Ejemplo 2

En el siguiente ejemplo, se muestran varios pasos en un solo segmento:

<!-- 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>

Los pasos sin una condición siempre se ejecutan.

Atributos

El elemento <Step> no tiene atributos.

Elementos secundarios

En la siguiente tabla, se describen los elementos secundarios de <Step>:

Elemento secundario Tipo Descripción
<Condition> String Define una declaración condicional para el paso que se procesa en el entorno de ejecución. Si la declaración se evalúa como verdadera, entonces Apigee ejecuta el paso. Si la declaración se evalúa como falsa, entonces Apigee omite el paso.
<Name> String Especifica el ID de la política que se ejecutará en el flujo actual.