Controla cómo se ejecuta un proxy con flujos

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

Cualquier modelo de programación de aplicaciones incluye una forma de controlar el flujo de procesamiento. En un proxy de API, esto se hace con flujos. A los flujos debes agregar lógica, declaraciones de condiciones, manejo de errores, etcétera. Los flujos se usan para controlar qué sucede y cuándo.

Los flujos son etapas secuenciales en la ruta de procesamiento de la solicitud a la API. Cuando agregas una lógica de proxy, por ejemplo, para verificar una clave de API, agregas la lógica como un paso de la secuencia especificada por un flujo. Cuando defines una condición para especificar si se ejecuta la lógica y cuándo, agregas la condición a un flujo.

En el siguiente ejemplo de configuración de flujo, se define un flujo en el que la política VerifyAPIKey se ejecuta if la ruta de la solicitud entrante termina con / y el verbo HTTP de la solicitud es GET.

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

El valor Verify-API-Key en el elemento <Name> del flujo sirve para incluir una política configurada en otra parte del proxy con XML, como la que se muestra a continuación:

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

Diseña una secuencia de ejecución de flujo

Debes estructurar los flujos para que la lógica se ejecute en la secuencia correcta a lo largo de la ruta de procesamiento.

Cuando decidas dónde agregar lógica, primero deberás elegir si deseas agregarla al extremo del proxy o al extremo de destino. Un proxy de API divide su código entre el código que interactúa con el cliente del proxy (extremo de proxy) y el código opcional que interactúa con el destino del backend del proxy, si existe alguno (extremo de destino).

Ambos extremos contienen flujos, como se describe a continuación:

Tipo de extremo Descripción Flujos compatibles
ProxyEndpoint Contiene los flujos del proxy de API más cercanos al cliente. Proporciona lugares para que la lógica actúe primero en la solicitud del cliente y, al último, en la respuesta al cliente. PreFlow, flujos condicionales, PostFlow, PostClientFlow
TargetEndpoint Contiene los flujos del proxy de API más cercanos al recurso de backend. Proporciona lugares para que la lógica prepare una solicitud y, luego, maneje la respuesta desde un recurso de backend. PreFlow, flujos condicionales, PostFlow

Configuras el flujo con XML que especifica qué debe suceder y en qué orden. En la siguiente ilustración, se muestra cómo se ordenan los flujos de forma secuencial dentro de un extremo de proxy y un extremo de destino:

Solicitud del cliente HTTP que pasa por el extremo del proxy al extremo objetivo en el backend a fin de alcanzar el servicio HTTP Cada panel de solicitud y respuesta muestra el flujo previo, los flujos condicionales y el flujo posterior. Además, se proporcionan ejemplos de los extremos del proxy y de destino.

El extremo del proxy y el extremo de destino contienen flujos que puedes organizar en la siguiente secuencia:

Cargo Tipo de flujo Descripción
1 PreFlow

Es útil cuando necesitas asegurarte de que un código determinado se ejecute antes de que suceda cualquier otra cosa.

Si el PreFlow está en un extremo de destino, se ejecuta después del PostFlow del extremo del proxy.

2 Flujo condicional

El lugar para la lógica condicional. Se ejecuta después del PreFlow y antes del PostFlow.

Solo se ejecuta un flujo condicional por segmento: el primer flujo cuya condición se evalúa como verdadera. Eso significa que puedes ejecutar un flujo condicional como parte de cada una de las siguientes opciones:
  • Canalización de solicitudes de ProxyEndpoint
  • Canalización de solicitudes de TargetEndpoint
  • Canalización de respuestas de ProxyEndpoint
  • Canalización de respuestas de TargetEndpoint
3 PostFlow

Un buen lugar para registrar datos, enviar una notificación que indique que algo sucedió mientras se procesaba la solicitud, etcétera. Se ejecuta después de los flujos condicionales y el PreFlow.

Si PostFlow está en un extremo proxy, y hay un extremo objetivo, el PostFlow del extremo del proxy se ejecuta antes del PreFlow del extremo de destino.

4 PostClientFlow (solo flujo de proxy) Un flujo para registrar mensajes después de que se muestra una respuesta al cliente.

Haz que el código se ejecute primero con un Flujo previo

Un PreFlow es útil cuando necesitas asegurarte de que cierto código se ejecute antes de que suceda algo.

En un extremo de proxy, un PreFlow es un excelente lugar para el código que autentica a un cliente y limita el tráfico de los clientes. En un extremo de destino, en el que comienza a prepararse para enviar una solicitud a un destino de backend, un PreFlow es ideal para los primeros pasos de la preparación del envío de la solicitud.

Por ejemplo, en general, no es recomendable entregar el servicio a un cliente que haya excedido su cuota. Para admitir estos requisitos, debes establecer políticas de seguridad y cuotas en el segmento de PreFlow. De esa manera, no necesitas preocuparte por que una condición no se evalúe en un flujo condicional posterior. Las políticas en este flujo siempre se ejecutarán antes de que se realice cualquier otro procesamiento.

En el siguiente ejemplo, las políticas SpikeArrest y Quota se ejecutan antes de que el procesamiento pase a los flujos condicionales.

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

Ejecuta código de manera condicional con un flujo condicional

Entre un PreFlow y un PostFlow, puedes tener flujos que se ejecuten de forma condicional. Esto te da la oportunidad de configurar varias secuencias lógicas, pero que solo una se ejecute en función del estado de tu proxy. Un flujo condicional es opcional si puedes ejecutar toda la lógica en PreFlow o PostFlow y no necesitas condiciones (en otras palabras, solo se admite una ruta a través del extremo).

Cada flujo especifica una condición que prueba diferentes valores de estado. Esto ramifica de manera efectiva la ejecución en función de las condiciones. Por ejemplo, es posible que desees convertir XML a JSON solo cuando la app que realiza la solicitud se ejecuta en un dispositivo móvil.

Aquí, las restricciones de cuota se aplican solo si la solicitud es GET con un patrón de URI de /issue/** (/issue/ con cualquier elemento en el URI después de la última barra diagonal).

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

Usa variables de flujo para especificar condiciones. Si deseas obtener más información sobre el uso de variables en condiciones, consulta Condiciones con variables de flujo.

Para ver ejemplos del uso de la coincidencia de patrones en las condiciones, consulta Coincidencia de patrones.

Ejecuta el código después de la lógica central con un PostFlow

Un PostFlow es un excelente lugar para realizar acciones después de la lógica central de tu extremo y antes de que finalice el procesamiento de extremo. Un PostFlow se ejecuta después de los flujos condicionales y el PreFlow.

Un PostFlow es un buen lugar para registrar algunos datos, enviar una notificación de que ocurrió algo, transformar el formato de los mensajes de respuesta, etcétera.

En el siguiente ejemplo, una política deAssignMessage llamada SetResponseHeaders establece los encabezados del mensaje de respuesta antes de que Apigee Edge envíe la respuesta al cliente.

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

Hacer que el código se ejecute después de que el cliente recibe la respuesta del proxy con un PostClientFlow

Un PostClientFlow puede incluir las siguientes políticas:

* La política FlowCallout solo puede llamar a flujos compartidos que cumplen con los criterios para estar en PostClientFlow (es decir, solo contienen políticas compatibles).

Si incluyes uno, un PostClientFlow sería el último flujo en ejecutarse, que se ejecutará después de que se envíe una respuesta al cliente.

Un PostClientFlow es bueno para el registro final. Además, puedes registrar las marcas de tiempo de inicio y de finalización del mensaje de respuesta.

Este es un ejemplo de un PostClientFlow con una política de MessageLogging adjunta.

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

Video: Mira este breve video que muestra cómo crear un PostClientFlow con la política MessageLogging de la serie Video de cuatro minutos para desarrolladores (4MV4D).

Para obtener más información, consulta:

Añade lógica a los flujos

Cuando agregas lógica a tu proxy, lo haces con políticas en los flujos de tu proxy. Así como los flujos se ejecutan en una secuencia (PreFlow, flujo y PostFlow, como se describe en este tema), el contenido de un flujo se ejecuta en una secuencia.

El siguiente ejemplo de configuración de flujo hace referencia a tres políticas (configuradas en otra parte en sus propios archivos en formato XML). La política a la que hace referencia Verify-API-Key se ejecuta antes que la política a la que hace referencia Remove-API-Key. Después de ellas, se ejecuta la política representada por Quota.

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

La consola de Apigee Edge presenta esta secuencia de políticas en una fila de íconos en la que cada uno representa la política.

La consola de Apigee Edge presenta esta secuencia de políticas en una fila de íconos en la que cada uno representa la política. Los íconos que se muestran en la ruta de la solicitud incluyen los siguientes: Verificar clave de API, Quitar clave de API y Cuota

Flujos de depuración

La herramienta Apigee Edge Trace proporciona una forma gráfica de ver cómo se ejecuta la lógica en el proxy de la API después de una solicitud. La herramienta ilustra el procesamiento entre la solicitud y la respuesta. No ilustra específicamente la separación entre PreFlow, flujos condicionales y PostFlow.

Para obtener más información sobre los proxies de seguimiento, consulta Usa la herramienta de seguimiento.

Controla errores en los flujos

Puedes generar fallas en varios lugares de un proxy de API, incluso en los flujos.

El siguiente ejemplo es la estrofa de respuesta de un PreFlow en un extremo de destino; en otras palabras, es el código que se ejecuta inmediatamente después de recibir la respuesta de un destino de backend. En el ejemplo, se genera una falla si la respuesta del objetivo no es 200 (correcto).

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

Para obtener más información sobre cómo manejar las fallas, consulta Soluciona errores.