Esta página aplica-se ao Apigee e ao Apigee Hybrid.
Veja a documentação do
Apigee Edge.
Os fluxos são a base dos proxies de API. Os fluxos permitem-lhe programar o comportamento de uma API, permitindo-lhe configurar a sequência em que as políticas e o código são executados por um proxy de API.
Os fluxos são fases sequenciais ao longo do caminho de processamento de pedidos da API. Quando adiciona lógica de proxy, por exemplo, para validar uma chave de API, adiciona a lógica como um passo na sequência especificada por um fluxo. Quando define uma condição para especificar se e quando a lógica é executada, adiciona a condição a um fluxo.
O exemplo de configuração do fluxo seguinte define um fluxo no qual a política VerifyAPIKey
é executada se o caminho do pedido recebido terminar com / e o verbo HTTP do pedido
for 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>O valor Verify-API-Key no elemento <Name> do fluxo serve
para incluir uma política configurada noutro local no proxy com XML, como o seguinte:
<?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>Conceber a sequência de execução do fluxo
Estrutura os fluxos para que a lógica possa ser executada na sequência certa ao longo do caminho de processamento.
Ao decidir onde adicionar lógica, primeiro, escolhe se a quer adicionar a um ponto final de proxy ou a um ponto final de destino. Um proxy de API divide o respetivo código entre o código que interage com o cliente do proxy (ponto final do proxy) e o código opcional que interage com o destino de back-end do proxy, se existir (ponto final de destino).
Ambos os pontos finais contêm fluxos, conforme descrito aqui:
| Tipo de ponto final | Descrição | Fluxos suportados |
|---|---|---|
| ProxyEndpoint | Contém os fluxos de proxy da API mais próximos do cliente. Oferece locais para a lógica agir primeiro no pedido do cliente e, em seguida, por último na resposta ao cliente. | PreFlow, fluxos condicionais, PostFlow e PostClientFlow |
| TargetEndpoint | Contém os fluxos de proxy da API mais próximos do recurso de back-end. Fornece locais para a lógica se preparar para um pedido e, em seguida, processar a resposta de um recurso de back-end. | PreFlow, fluxos condicionais e PostFlow |
Configura o fluxo com XML que especifica o que deve acontecer e em que ordem. A ilustração seguinte mostra como os fluxos são ordenados sequencialmente num ponto final de proxy e num ponto final de destino:
O ponto final do proxy e o ponto final de destino contêm fluxos que pode organizar na seguinte sequência:
| Posição | Tipo de fluxo | Descrição |
|---|---|---|
| 1 | PreFlow |
Útil quando precisa de garantir que determinado código é executado antes de qualquer outra ação. Se o PreFlow estiver num ponto final de destino, é executado após o PostFlow do ponto final do proxy. |
| 2 | Fluxo condicional |
O local para a lógica condicional. Executa-se após o PreFlow e antes do PostFlow. Apenas um fluxo condicional é executado por segmento, o primeiro fluxo cuja condição é avaliada como verdadeira. Isto significa que pode ter um fluxo condicional executado como parte de cada um dos seguintes elementos:
|
| 3 | PostFlow |
Um bom local para registar dados, enviar uma notificação de que algo aconteceu durante o processamento do pedido, etc. É executado após os fluxos condicionais e o PreFlow. Se o PostFlow estiver num ponto final de proxy e existir um ponto final de destino, o PostFlow do ponto final de proxy é executado antes do PreFlow do ponto final de destino. |
| 4 | PostClientFlow (apenas fluxo de proxy) | Um fluxo para registar mensagens depois de uma resposta ser devolvida ao cliente. |
Executar código primeiro com um PreFlow
Um PreFlow é útil quando precisa de se certificar de que determinado código é executado antes de qualquer outra ação.
Num ponto final de proxy, um PreFlow é um excelente local para código que autentica um cliente e limita o tráfego de clientes. Num ponto final de destino, onde começa a preparar-se para enviar um pedido para um destino de back-end, um PreFlow é adequado para os primeiros passos na preparação do envio do pedido.
Por exemplo, normalmente, não quer prestar serviços a um cliente que tenha excedido a respetiva quota. Para suportar estes requisitos, coloca políticas de segurança e de quotas no segmento PreFlow. Desta forma, não tem de se preocupar com a falha de avaliação de uma condição num fluxo condicional posterior. As políticas neste fluxo são sempre executadas antes de qualquer outro processamento.
No exemplo seguinte, as políticas SpikeArrest e Quota são executadas antes de o processamento ser transmitido para fluxos condicionais.
<PreFlow name="MyPreFlow">
<Request>
<Step>
<Name>Spike-Arrest</Name>
</Step>
<Step>
<Name>Quota</Name>
</Step>
</Request>
<Response/>
</PreFlow>Fazer com que o código seja executado condicionalmente com um fluxo condicional
Entre um PreFlow e um PostFlow, pode ter fluxos que são executados condicionalmente. Isto dá-lhe a oportunidade de configurar várias sequências de lógica, mas apenas uma é executada com base no estado do seu proxy. Um fluxo condicional é opcional se puder executar toda a lógica em PreFlow ou PostFlow e não forem necessárias condições (por outras palavras, apenas um caminho através do ponto final é suportado).
Cada fluxo especifica uma condição que testa diferentes valores de estado. Isto ramifica efetivamente a execução com base nas condições. Por exemplo, pode querer converter XML em JSON apenas quando a app que envia o pedido estiver a ser executada num dispositivo móvel.
Aqui, as restrições de quota só são aplicadas se o pedido for um pedido GET com um padrão de URI de /issue/** (/issue/ com qualquer elemento no URI após a última barra
invertida).
<Flow name="MyFlow">
<Description/>
<Request>
<Step>
<Name>Quota</Name>
</Step>
</Request>
<Response/>
<Condition>(proxy.pathsuffix MatchesPath "/issue/**") and (request.verb = "GET")</Condition>
</Flow>As variáveis de fluxo são usadas para especificar condições. Para saber mais sobre a utilização de variáveis em condições, consulte o artigo Condições com variáveis de fluxo.
Para ver exemplos de utilização da correspondência de padrões em condições, consulte o artigo Correspondência de padrões.
Executar código após a lógica principal com um PostFlow
Um PostFlow é um ótimo local para realizar ações após a lógica essencial do seu ponto final e antes de o processamento do ponto final terminar. Um PostFlow é executado após os fluxos condicionais e o PreFlow.
Um PostFlow é um bom local para registar alguns dados, enviar uma notificação de que algo aconteceu, transformar o formato da mensagem de resposta, etc.
No exemplo seguinte, uma política AssignMessage denominada SetResponseHeaders define os cabeçalhos da mensagem de resposta antes de o Apigee enviar a resposta de volta para o cliente.
<PostFlow>
<Response>
<Step>
<Name>SetResponseHeaders</Name>
</Step>
</Response>
</PostFlow>Executar código depois de o cliente receber a resposta do seu proxy com um PostClientFlow
Um PostClientFlow só pode incluir as seguintes políticas. Não é possível usar outras políticas num PostClientFlow:
- Política de texto de chamada dinâmico*
- Política de MessageLogging
- Política de textos destacados de serviços
* A política FlowCallout só pode chamar fluxos partilhados que, por sua vez, cumpram os critérios para estarem no PostClientFlow (ou seja, que contenham apenas políticas compatíveis).
Se incluir um, um PostClientFlow é o último fluxo a ser executado, sendo executado depois de uma resposta ser enviada para o cliente.
Um PostClientFlow é adequado para o registo final. Além disso, pode registar as indicações de data/hora de início e fim da mensagem de resposta.
Segue-se um exemplo de um PostClientFlow com uma política MessageLogging anexada.
<ProxyEndpoint name="endpoint1">
...
<PostFlow name="PostFlow">
<Request/>
<Response/>
</PostFlow>
<PostClientFlow>
<Response>
<Step>
<Name>Message-Logging-1</Name>
</Step>
</Response>
</PostClientFlow>
...
</ProxyEndpoint>
Para mais informações, consulte a referência de configuração do proxy da API.
Adicionar lógica aos fluxos
Quando adiciona lógica ao proxy, fá-lo adicionando políticas aos fluxos do proxy. Tal como os fluxos são executados numa sequência (PreFlow, Flow e PostFlow, conforme descrito neste tópico), os conteúdos de um fluxo são executados numa sequência.
A configuração do fluxo de exemplo seguinte faz referência a três políticas (configuradas noutro local nos respetivos ficheiros XML). A política referenciada por Verify-API-Key é executada antes da política referenciada por Assign-Message. Ambas são seguidas pela 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>Depurar fluxos
A ferramenta de depuração oferece uma forma gráfica de ver como a lógica no seu proxy de API é executada após um pedido. A ferramenta ilustra o processamento entre o pedido e a resposta. Não ilustra especificamente a separação entre PreFlow, fluxos condicionais e PostFlow.
Para mais informações sobre a depuração de proxies, consulte o artigo Usar a ferramenta de depuração.
Processamento de erros em fluxos
Pode gerar falhas a partir de vários locais num proxy de API, incluindo a partir de fluxos.
O exemplo seguinte é a secção de resposta de um PreFlow num ponto final de destino. Por outras palavras, é o código que é executado imediatamente após receber a resposta de um destino de back-end.
No exemplo, é gerada uma falha se a resposta do destino não for 200 (êxito).
<PreFlow name="PreFlow">
<Response>
<Step>
<Name>RaiseFault</Name>
<Condition>(response.status.code GreaterThan "200")</Condition>
</Step>
</Response>
</PreFlow>Para mais informações sobre o processamento de erros, consulte o artigo Processamento de falhas.