Kontrolowanie działania serwera proxy za pomocą przepływów

Przeglądasz dokumentację Apigee Edge.
Przejdź do Dokumentacja Apigee X. informacje.

Każdy model programowania aplikacji obejmuje sposób kontrolowania przepływu przetwarzania. W interfejsie API przez serwery proxy. Aby to zrobić, dodaj reguły logiczne, instrukcje warunku, obsługę błędów i tak dalej. Za pomocą przepływów możesz kontrolować, co i kiedy się dzieje.

Przepływy to sekwencyjne etapy na ścieżce przetwarzania żądań do interfejsu API. Gdy dodasz logikę proxy, np. w celu weryfikacji klucza interfejsu API, należy dodać tę funkcję jako krok w sekwencji określonej przez przepływ. Gdy definiujesz warunek określający, czy i kiedy logika ma być wykonywana, dodajesz go do przepływ.

Poniższy przykład konfiguracji przepływu definiuje przepływ, w którym zasada VerifyAPIKey wykonuje polecenie, jeśli ścieżka żądania przychodzącego kończy się znakiem /, a kod HTTP żądania czasownik to 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>

Wartość Verify-API-Key w elemencie <Name> przepływu wyświetla się , aby uwzględnić zasadę skonfigurowaną w innym miejscu na serwerze proxy za pomocą kodu XML, na przykład:

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

Projektowanie sekwencji wykonywania przepływu

Przepływy są uporządkowane w taki sposób, aby logika była wykonywana w odpowiedniej kolejności ścieżki przetwarzania danych.

Podczas podejmowania decyzji o tym, gdzie dodać logikę, najpierw zdecyduj, czy chcesz dodać ją do punktu końcowego serwera proxy docelowego punktu końcowego. Serwer proxy interfejsu API dzieli swój kod między kod współpracujący z serwerem proxy klient (punkt końcowy serwera proxy) oraz opcjonalny kod, który wchodzi w interakcję z miejscem docelowym backendu (jeśli istnieje) (docelowy punkt końcowy).

Oba punkty końcowe zawierają przepływy, które opisano tutaj:

Konfigurujesz przepływ za pomocą kodu XML, który określa, co i w jakiej kolejności powinno się wydarzyć. Poniżej ilustracja przedstawiająca sekwencyjną kolejność przepływów w punkcie końcowym serwera proxy i w miejscu docelowym punkt końcowy:

Punkt końcowy serwera proxy i docelowy punkt końcowy zawierają przepływy, które możesz umieścić w w następującej kolejności:

Po wykonaniu kodu z PreFlow

PreFlow jest przydatny, gdy chcesz mieć pewność, że określony kod będzie uruchamiany przed innymi co się dzieje.

W punkcie końcowym serwera proxy można zastosować PreFlow do kodowania kodu uwierzytelniającego klienta i ogranicza ruch generowany przez klientów. w docelowym punkcie końcowym, gdzie zaczyna się przygotowywać żądanie do wysłania jako cel backendu, funkcja PreFlow jest przydatna podczas pierwszych kroków w przygotowaniu do wysłania żądania.

Na przykład zwykle nie chcesz obsługiwać klienta, który przekroczył limit. Do uwzględniasz te wymagania, umieszczasz zasady zabezpieczeń i limitów w segmencie PreFlow. Dzięki temu nie musisz się martwić, że warunek nie zostanie oceniony w późniejszym procesie warunkowym. zasady w tym przepływie są zawsze stosowane przed jakimkolwiek innym przetwarzaniem.

W poniższym przykładzie zasady SpikeArrest i Limitu są wykonywane przed przetworzeniem przebiegów do przepływy warunkowe.

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

Mając kod jest wykonywany warunkowo z użyciem przepływu warunkowego

Pomiędzy PreFlow a PostFlow możesz mieć przepływy, które są wykonywane warunkowo. Dzięki temu można skonfigurować wiele sekwencji logiki, ale tylko jedno wykonać na podstawie stan serwera proxy. Przepływ warunkowy jest opcjonalny, jeśli możesz wykonać całą logikę w PreFlow lub PostFlow i nie są wymagane żadne warunki (inaczej mówiąc, tylko jedna ścieżka prowadząca przez punkt końcowy jest obsługiwane).

Każdy przepływ określa warunek, który testuje różne wartości stanu. Dzięki temu wykonywanie gałęzi na podstawie warunków. Możesz na przykład przekonwertować tylko format XML na JSON gdy na urządzeniu mobilnym działa żądająca aplikacja.

Tutaj ograniczenia limitów są egzekwowane tylko wtedy, gdy żądanie jest żądaniem GET z atrybutem Wzorzec identyfikatora URI /issue/** (/issue/ z dowolnym elementem w identyfikatorze URI po ostatnim przekazaniu dalej ukośnik).

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

Do określania warunków używasz zmiennych przepływu. Aby dowiedzieć się więcej o używaniu zmiennych w warunkach, patrz Warunki ze zmiennymi przepływu.

Przykłady wykorzystania dopasowania do wzorca w warunkach znajdziesz w sekcji Dopasowywanie do wzorca.

Potrzebny jest kod wykonaj po głównej logice za pomocą PostFlow

PostFlow to świetne miejsce do wykonywania działań po głównej logice punktu końcowego, a przed gdy zakończy się przetwarzanie punktu końcowego. Proces PostFlow jest wykonywany po przepływach warunkowych i PreFlow.

Zapisanie danych, wysłanie powiadomienia o tym, że coś się stało, przekształcą format wiadomości z odpowiedzią i tak dalej.

W poniższym przykładzie zasada AssignMessage o nazwie SetResponseHeaders ustawia nagłówki komunikat z odpowiedzią, zanim Apigee Edge wyśle odpowiedź do klienta.

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

wykonywanie kodu po otrzymaniu odpowiedzi serwera proxy za pomocą PostClientFlow;

Interfejs PostClientFlow może obejmować następujące zasady:

• ExtensionCallout (Zasady dotyczące rozszerzenia objaśnień)
• Zasady rozszerzenia FlowCallout^*
• Zasady MessageLogging
• Zasady dotyczące wywołań usługi

^* Zasada FlowCallout może wywoływać tylko udostępnione przepływy, które spełniają wymagania kryteria udziału w PostClientFlow (tzn. muszą zawierać tylko zgodne zasady).

Jeśli je dodasz, ostatnim przepływem do wykonania będzie PostClientFlow, wykonywany po odpowiedź jest wysyłana do klienta.

Przepływ PostClientFlow jest dobrym rozwiązaniem do ostatecznego rejestrowania danych. Możesz też zapisać sygnaturę czasową rozpoczęcia i zakończenia wiadomości z odpowiedzią.

Oto przykład interfejsu PostClientFlow z dołączoną zasadą MessageLogging.

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

Aby dowiedzieć się więcej, zobacz:

• Dokumentacja konfiguracji serwera proxy interfejsu API
• Samouczek : artykuł na karcie Społeczność Apigee Edge – post przepływu klienta

Dodawanie logiki do przepływów

Gdy dodajesz reguły do serwera proxy, musisz dodać zasady do przepływów serwera proxy. Tak samo przepływy są wykonywane w sekwencji (PreFlow, Flow, a następnie PostFlow, jak opisano w tym temacie), zawartość przepływu jest wykonywana w sekwencji.

Poniższa przykładowa konfiguracja przepływu odwołuje się do 3 zasad (skonfigurowanych w innym miejscu własne pliki XML). Zasada, do której odwołuje się Verify-API-Key, jest wykonywana przed zasada, do której odwołuje się Remove-API-Key; po obu następuje zasada reprezentowana przez 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>

Konsola Apigee Edge przedstawia tę sekwencję zasad w postaci wiersza ikon, przy czym każda ikona jest reprezentowana przez zasadę.

Debugowanie przepływów

Narzędzie Apigee Edge Trace pozwala w graficzny sposób zapoznać się z działaniem logiki serwera proxy interfejsu API po wykonaniu żądania. Narzędzie to ilustruje przetwarzanie żądania i odpowiedzi. it nie ilustruje wyraźnie rozdzielenia między przepływami PreFlow, przepływami warunkowymi i PostFlow.

Więcej informacji na temat śledzenia serwerów proxy znajdziesz w artykule na temat używania narzędzia Trace.

Obsługa błędów w przepływach

Błędy możesz zgłaszać z różnych miejsc serwera proxy interfejsu API, w tym z przepływów.

Poniższy przykład to zdanie odpowiedzi z PreFlow w docelowym punkcie końcowym – w innym jest to kod, który wykonuje się natychmiast po otrzymaniu odpowiedzi z celu backendu. W tym przykładzie błąd jest zgłaszany, jeśli odpowiedź z elementu docelowego nie wynosi 200 (powodzenie).

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

Więcej informacji o obsłudze błędów znajdziesz w sekcji Obsługa błędów.