Esta página se aplica a Apigee y Apigee Hybrid.
Consulta la documentación de
Apigee Edge.
Los flujos son los componentes básicos de los proxies de API. Los flujos te permiten programar el comportamiento de una API, ya que te permiten configurar la secuencia en la que un proxy de API ejecuta las políticas y el código.
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.
El siguiente ejemplo de configuración de flujo define un flujo en el que la política VerifyAPIKey se ejecuta si la ruta de acceso 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:
El extremo del proxy y el extremo de destino contienen flujos que puedes organizar en la siguiente secuencia:
| Posición | 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úe como verdadera. Esto significa que puedes ejecutar un flujo condicional como parte de cada uno de los siguientes elementos:
|
| 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 solo se aplican si la solicitud es una solicitud 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 AssignMessage llamada SetResponseHeaders establece los encabezados del mensaje de respuesta antes de que Apigee envíe la respuesta al cliente.
<PostFlow>
<Response>
<Step>
<Name>SetResponseHeaders</Name>
</Step>
</Response>
</PostFlow>Haz que el código se ejecute después de que el cliente reciba la respuesta de tu proxy con PostClientFlow
Un PostClientFlow puede incluir las siguientes políticas. No se pueden usar otras políticas en un PostClientFlow:
* 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, el PostClientFlow sería el último flujo para ejecutar, que se ejecuta después de enviar 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.
<ProxyEndpoint name="endpoint1">
...
<PostFlow name="PostFlow">
<Request/>
<Response/>
</PostFlow>
<PostClientFlow>
<Response>
<Step>
<Name>Message-Logging-1</Name>
</Step>
</Response>
</PostClientFlow>
...
</ProxyEndpoint>
Para obtener más información, consulta la Referencia de configuración de proxy de API.
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 Assign-Message. 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>Assign-Message</Name>
</Step>
<Step>
<Name>Quota</Name>
</Step>
</Request>
<Condition>(proxy.pathsuffix MatchesPath "/") and (request.verb = "GET")</Condition>
</Flow>Flujos de depuración
La herramienta de depuración proporciona una forma gráfica de ver cómo se ejecuta la lógica en el proxy de 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 depuración, consulta Usa la herramienta de depuración.
Controla errores en los flujos
Puedes generar fallas en varios lugares de un proxy de API, incluso en los flujos.
En el siguiente ejemplo, se muestra la estrofa de respuesta de un PreFlow en un extremo de destino; en otras palabras, es el código que se ejecuta de inmediato cuando se recibe la respuesta de un destino de backend.
En el ejemplo, se genera una falla si la respuesta del destino no es 200 (correcta).
<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.