Estás viendo la documentación de Apigee Edge.
Ve a la documentación de Apigee X. Más 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 se ejecuta la política VerifyAPIKey si la ruta de la solicitud entrante termina en / 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 | Anterior al flujo |
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. Esto significa que puedes ejecutar un flujo condicional como parte de cada uno de los siguientes elementos:
|
| 3 | Posterior al flujo |
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 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 de AssignMessage 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>
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:
* 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 que se ejecutaría después de que se enviara 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 mediante la política MessageLogging de la serie Video de cuatro minutos para desarrolladores (4MV4D).
Para obtener más información, consulta:
- Referencia de la configuración del proxy de API
- Artículo de la comunidad Instructivo: Apigee Edge: Publica un flujo de cliente
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 como una fila de íconos en la que cada ícono representa la política.
Flujos de depuración
La herramienta de seguimiento de Apigee Edge 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 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.