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

Wyświetlasz dokumentację Apigee Edge.
Przejdź do dokumentacji Apigee X. info

Każdy model programowania aplikacji obejmuje sposób kontrolowania przepływu przetwarzania. W serwerze proxy interfejsu API odbywa się to za pomocą przepływów. Do przepływów dodajesz logikę, instrukcje warunkowe, 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 żądania do interfejsu API. Gdy dodajesz logikę serwera proxy, np. aby zweryfikować klucz interfejsu API, dodajesz ją jako krok w sekwencji określonej przez przepływ. Gdy definiujesz warunek określający, czy i kiedy ma być wykonywana logika, dodajesz go do przepływu.

Ten przykład konfiguracji przepływu definiuje przepływ, w którym zasada VerifyAPIKey jest wykonywana tylko wtedy, gdy ścieżka żądania przychodzącego kończy się znakiem /, a czasownik HTTP żądania 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 służy do uwzględniania zasady skonfigurowanej w innym miejscu serwera proxy za pomocą kodu XML, takiego jak ten:

<?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ą tak skonstruowane, aby logika mogła być wykonywana w odpowiedniej kolejności na ścieżce przetwarzania.

Decydując, gdzie dodać logikę, najpierw wybierasz, czy chcesz ją dodać do punktu końcowego serwera proxy czy punktu końcowego docelowego. Serwer proxy interfejsu API dzieli swój kod na kod, który wchodzi w interakcję z klientem serwera proxy (punkt końcowy serwera proxy), oraz opcjonalny kod, który wchodzi w interakcję z docelowym backendem serwera proxy (punkt końcowy docelowy).

Oba punkty końcowe zawierają przepływy, jak opisano poniżej:

Przepływ konfigurujesz za pomocą kodu XML, który określa, co i w jakiej kolejności ma się dziać. Ilustracja poniżej pokazuje, jak przepływy są uporządkowane sekwencyjnie w punkcie końcowym serwera proxy i punkcie końcowym docelowym:

Punkt końcowy serwera proxy i punkt końcowy docelowy zawierają przepływy, które możesz ułożyć w tej kolejności:

Wykonywanie kodu w pierwszej kolejności za pomocą PreFlow

PreFlow jest przydatny, gdy musisz mieć pewność, że określony kod zostanie wykonany przed innymi działaniami.

W punkcie końcowym serwera proxy PreFlow to dobre miejsce na kod, który uwierzytelnia klienta i ogranicza ruch od klientów. W punkcie końcowym docelowym, w którym rozpoczyna się przygotowywanie do wysłania żądania do docelowego backendu, PreFlow jest dobrym miejscem na pierwsze kroki w przygotowaniu do wysłania żądania.

Zwykle nie chcesz obsługiwać klienta, który przekroczył limit. Aby spełnić te wymagania, umieść zasady dotyczące bezpieczeństwa i limitów w segmencie PreFlow. Dzięki temu, nie musisz się martwić, że warunek nie zostanie spełniony w późniejszym przepływie warunkowym. Zasady w tym przepływie będą zawsze wykonywane przed rozpoczęciem przetwarzania.

W tym przykładzie zasady SpikeArrest i Quota są wykonywane przed przekazaniem przetwarzania do przepływów warunkowych.

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

Wykonywanie kodu warunkowo za pomocą przepływu warunkowego

Między PreFlow a PostFlow możesz mieć przepływy, które są wykonywane warunkowo. Dzięki temu możesz skonfigurować wiele sekwencji logiki, ale tylko 1 z nich będzie wykonywana na podstawie stanu serwera proxy. Przepływ warunkowy jest opcjonalny, jeśli możesz wykonać całą logikę w PreFlow lub PostFlow i nie są wymagane żadne warunki (czyli obsługiwana jest tylko 1 ścieżka przez punkt końcowy ).

Każdy przepływ określa warunek, który sprawdza różne wartości stanu. Powoduje to rozgałęzienie wykonania na podstawie warunków. Możesz na przykład chcieć przekonwertować XML na JSON tylko wtedy, gdy aplikacja wysyłająca żądanie jest uruchomiona na urządzeniu mobilnym.

W tym przypadku ograniczenia limitu są egzekwowane tylko wtedy, gdy żądanie jest żądaniem GET z wzorcem URI /issue/** (/issue/ z dowolną treścią w URI po ostatnim ukośniku).

<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. Więcej informacji o używaniu zmiennych w warunkach, zobacz Warunki ze zmiennymi przepływu.

Przykłady użycia dopasowywania wzorców w warunkach znajdziesz w artykule Dopasowywanie wzorców.

Wykonywanie kodu po logice podstawowej za pomocą PostFlow

PostFlow to dobre miejsce na wykonywanie działań po logice podstawowej punktu końcowego i przed zakończeniem przetwarzania punktu końcowego. PostFlow jest wykonywany po przepływach warunkowych i PreFlow.

PostFlow to dobre miejsce na logowanie danych, wysyłanie powiadomień o zdarzeniach, przekształcanie formatu wiadomości odpowiedzi itp.

W tym przykładzie zasada AssignMessage o nazwie SetResponseHeaders ustawia nagłówki wiadomości odpowiedzi, zanim Apigee Edge wyśle odpowiedź z powrotem do klienta.

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

Wykonywanie kodu po otrzymaniu przez klienta odpowiedzi serwera proxy za pomocą PostClientFlow

PostClientFlow może obejmować te zasady:

• ExtensionCallout
• FlowCallout^*
• MessageLogging
• ServiceCallout

^* Zasada FlowCallout może wywoływać tylko przepływy współdzielone, które same spełniają kryteria umieszczenia w PostClientFlow (czyli zawierają tylko zgodne zasady).

Jeśli uwzględnisz PostClientFlow, będzie to ostatni przepływ, który zostanie wykonany po wysłaniu odpowiedzi do klienta.

PostClientFlow jest przydatny do logowania końcowego. Możesz też rejestrować sygnatury czasowe rozpoczęcia i zakończenia wiadomości odpowiedzi.

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

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

Więcej informacji znajdziesz w tych artykułach:

• Dokumentacja konfiguracji serwera proxy interfejsu API
• Samouczek : Apigee Edge – artykuł społecznościowy o przepływie po stronie klienta

Dodawanie logiki do przepływów

Gdy dodajesz logikę do serwera proxy, robisz to, dodając zasady do przepływów serwera proxy. Tak jak przepływy są wykonywane w sekwencji (PreFlow, potem Flow, a następnie PostFlow, jak opisano w tym artykule), tak samo zawartość przepływu jest wykonywana w sekwencji.

Ten przykład konfiguracji przepływu odwołuje się do 3 zasad (skonfigurowanych w innych plikach XML). Zasada, do której odwołuje się Verify-API-Key, jest wykonywana przed zasadą, do której odwołuje się Remove-API-Key. Po obu tych zasadach jest wykonywana 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 jako wiersz ikon, z których każda ikona reprezentuje zasadę.

Debugowanie przepływów

Narzędzie śledzenia Apigee Edge umożliwia graficzne sprawdzenie, jak logika w serwerze proxy interfejsu API jest wykonywana po otrzymaniu żądania. Narzędzie ilustruje przetwarzanie między żądaniem a odpowiedzią. Nie ilustruje ono konkretnie podziału na PreFlow, przepływy warunkowe i PostFlow.

Więcej informacji o śledzeniu serwerów proxy znajdziesz w artykule Korzystanie z narzędzia śledzenia.

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

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

Ten przykład to sekcja odpowiedzi z PreFlow w punkcie końcowym docelowym – innymi słowy, jest to kod, który jest wykonywany natychmiast po otrzymaniu odpowiedzi z docelowego backendu. W tym przykładzie błąd jest zgłaszany, jeśli odpowiedź z celu nie jest odpowiedzią 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 artykule Obsługa błędów.