Controllo dell'esecuzione di un proxy con i flussi

Stai visualizzando la documentazione di Apigee Edge.
Vai alla sezione Documentazione di Apigee X. Informazioni

Qualsiasi modello di programmazione di un'applicazione include un modo per controllare il flusso di elaborazione. In un'API un proxy, questo viene fatto con i flussi. Ai flussi aggiungi logica, istruzioni di condizione, gestione degli errori e così via. Puoi usare i flussi per controllare cosa succede e quando.

I flussi sono fasi sequenziali lungo il percorso di elaborazione delle richieste API. Quando aggiungi la logica del proxy, ad esempio per verificare una chiave API, aggiungi la logica come passaggio nella sequenza specificata da un flusso. Quando definisci una condizione per specificare se e quando viene eseguita la logica, la aggiungi al un flusso.

Il seguente esempio di configurazione del flusso definisce un flusso in cui il criterio VerifyAPIKey Viene eseguito se il percorso della richiesta in entrata termina con / e l'HTTP della richiesta verbo è 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>

Viene pubblicato il valore Verify-API-Key nell'elemento <Name> del flusso per includere un criterio configurato altrove nel proxy con XML, come il seguente:

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

Progettazione della sequenza di esecuzione del flusso

Strutturare i flussi in modo da poter eseguire la logica nella sequenza corretta lungo di pre-elaborazione.

Quando decidi dove aggiungere la logica, devi prima scegliere se aggiungerla a un endpoint proxy o endpoint di destinazione. Un proxy API divide il suo codice tra codice che interagisce con il proxy (endpoint proxy) e codice facoltativo che interagisce con l'eventuale target del backend del proxy (endpoint di destinazione).

Entrambi gli endpoint contengono flussi, come descritto qui:

Configuri il flusso con un file XML che specifica cosa deve accadere e in quale ordine. Le seguenti illustrazione mostra come i flussi vengono ordinati in sequenza all'interno di un endpoint proxy e di una destinazione endpoint:

L'endpoint proxy e l'endpoint di destinazione contengono ciascuno flussi che puoi organizzare nel sequenza precedente:

Eseguire il codice con un comando PreFlow

Un PreFlow è utile quando devi assicurarti che un determinato codice venga eseguito prima di qualsiasi altra .

In un endpoint proxy, PreFlow è un ottimo posto per il codice che autentica un client limita il traffico dai client. In un endpoint di destinazione, dove inizia a prepararsi per inviare una richiesta un target di backend, un PreFlow è ideale per i primi passi nella preparazione all'invio della richiesta.

Ad esempio, in genere non è consigliabile fornire assistenza a un client che ha superato la quota disponibile. A che supportano questi requisiti, inserisci i criteri di sicurezza e quota nel segmento PreFlow. In questo modo non devi preoccuparti se una condizione non viene valutata in un flusso condizionale successivo. La i criteri in questo flusso verranno sempre eseguiti prima di qualsiasi altra elaborazione.

Nell'esempio seguente, i criteri SpikeArrest e Quota vengono eseguiti prima che l'elaborazione passi a condizionali.

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

Avere il codice viene eseguito in modo condizionale con un flusso condizionale

Tra un PreFlow e un PostFlow, puoi avere flussi che vengono eseguiti in modo condizionale. Ciò consente di puoi configurare più sequenze di logica, ma eseguirne una sola in base lo stato del proxy. Un flusso condizionale è facoltativo se puoi eseguire tutta la logica in PreFlow PostFlow e non sono richieste condizioni (in altre parole, solo un percorso attraverso l'endpoint è supportato).

Ogni flusso specifica una condizione che verifica i diversi valori di stato. In questo modo, dirama l'esecuzione in base alle condizioni. Ad esempio, potresti voler convertire solo da XML a JSON quando l'app che la richiede è in esecuzione su un dispositivo mobile.

In questo caso, i vincoli di quota vengono applicati solo se la richiesta è una richiesta GET con un Pattern URI di /issue/** (/issue/ con qualsiasi elemento nell'URI dopo l'ultimo inoltro barra).

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

Puoi usare le variabili di flusso per specificare le condizioni. Per ulteriori informazioni sull'uso delle variabili nelle condizioni, consulta Condizioni con variabili di flusso.

Per esempi di utilizzo della corrispondenza di pattern nelle condizioni, consulta Corrispondenza di pattern.

Possedere codice da eseguire dopo la logica principale con un PostFlow

Un PostFlow è un ottimo posto per eseguire azioni dopo la logica principale dell'endpoint e prima l'elaborazione dell'endpoint. Un PostFlow viene eseguito dopo i flussi condizionali e PreFlow.

PostFlow è un ottimo posto per registrare alcuni dati, inviare una notifica per informarsi trasformare il formato del messaggio di risposta e così via.

Nell'esempio seguente, un criterioAssignMessage chiamato SetResponseHeaders imposta intestazioni di il messaggio di risposta prima che Apigee Edge invii la risposta al client.

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

Fare in modo che il codice venga eseguito dopo che il client ha ricevuto la risposta del proxy con un PostClientFlow.

Un PostClientFlow può includere i seguenti criteri:

• Norme sui callout estensioni
• Norme sui callout di flusso^*
• Criterio MessageLogging
• Norme relative a ServiceCallout

^* Il criterio FlowCallout può chiamare solo i flussi condivisi che a loro volta soddisfano le criteri per la presenza in PostClientFlow (ovvero, contengono solo criteri compatibili).

Se ne includi uno, PostClientFlow è l'ultimo flusso da eseguire, che viene eseguito dopo un la risposta desiderata viene inviata al client.

Un PostClientFlow è ideale per il logging finale. Inoltre, puoi registrare i timestamp di inizio e di fine del messaggio di risposta.

Ecco un esempio di PostClientFlow con un criterio MessageLogging collegato.

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

Per ulteriori informazioni, vedi:

• Riferimento per la configurazione dei proxy API
• Tutorial : Apigee Edge - Articolo della community post-client

Aggiunta della logica ai flussi

Quando aggiungi logica al proxy, puoi farlo aggiungendo criteri ai flussi del proxy. Esattamente come vengono eseguiti in sequenza (PreFlow, Flow, PostFlow, come descritto in questo argomento), i contenuti di un flusso vengono eseguiti in sequenza.

La configurazione del flusso di esempio seguente fa riferimento a tre criteri (configurati altrove in propri file XML). Il criterio a cui fa riferimento Verify-API-Key viene eseguito prima di norma a cui si fa riferimento in Remove-API-Key; entrambi sono seguiti dal criterio rappresentato da 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 console Apigee Edge presenta questa sequenza di criteri come una fila di icone, in cui ogni icona rappresenta il criterio.

Flussi di debug

Lo strumento Apigee Edge Trace fornisce un modo grafico per vedere come la logica nel proxy API viene eseguita a seguito di una richiesta. Lo strumento illustra l'elaborazione tra richiesta e risposta. it non illustra in modo specifico la separazione tra PreFlow, i flussi condizionali e PostFlow.

Per scoprire di più sul tracciamento dei proxy, consulta Utilizzo dello strumento Trace.

Gestione degli errori nei flussi

Puoi generare gli errori da varie posizioni in un proxy API, inclusi i flussi.

L'esempio seguente è la stanza di risposta da un PreFlow in un endpoint di destinazione - in parole, è il codice che viene eseguito subito dopo aver ricevuto la risposta dalla destinazione di un backend. Nell'esempio, viene generato un errore se la risposta dal target non è 200 (esito positivo).

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

Per saperne di più sulla gestione degli errori, consulta Gestione degli errori.