Dokumentacja konfiguracji serwera proxy interfejsu API

Wyświetlasz dokumentację Apigee Edge.
Zapoznaj się z dokumentacją Apigee X. info

Gdy pracujesz jako deweloper z Apigee Edge, Twoje główne działania związane z programowaniem obejmują konfigurowanie proxy interfejsu API, które działają jako proxy interfejsów API lub usług backendu. Ten dokument zawiera informacje o wszystkich elementach konfiguracji dostępnych podczas tworzenia proxy interfejsów API.

Jeśli uczysz się tworzenia serwerów proxy interfejsu API, zacznij od tematu Tworzenie prostego serwera proxy interfejsu API.

Najczęstsze sposoby edytowania konfiguracji serwera proxy to:

• Korzystanie z edytora XML w interfejsie Edge
• Pobierz konfigurację i edytuj ją lokalnie zgodnie z opisem w sekcji Lokalne tworzenie konfiguracji serwera proxy.

Lokalne programowanie konfiguracji serwera proxy

Możesz pobrać konfiguracje serwera proxy, aby edytować je na komputerze lokalnym. Gdy skończysz, prześlij wyniki do Edge. Dzięki temu możesz zintegrować konfiguracje serwera proxy z kontrolą źródła, wersjonowaniem i innymi udostępnionymi przepływami pracy. Dodatkowo, pracując nad konfiguracją serwera proxy lokalnie, możesz używać własnego edytora XML i narzędzi do weryfikacji.

W tej sekcji opisujemy, jak za pomocą interfejsu pobrać istniejącą konfigurację serwera proxy, edytować ją, a następnie przesłać z powrotem do Edge w celu wdrożenia. Możesz też użyć narzędzia apigeetool, aby pobrać i wdrożyć nową konfigurację serwera proxy (używając odpowiednio poleceń fetchproxy i deployproxy).

Aby edytować konfigurację serwera proxy lokalnie za pomocą interfejsu:

1. Pobierz bieżącą konfigurację serwera proxy w interfejsie Edge. (W widoku Proxy interfejsu API wybierz Projekt > Pobierz wersję).
2. Na komputerze lokalnym utwórz nowy katalog i rozpakuj do niego pobrany plik ZIP.

   Aby rozpakować plik ZIP, możesz użyć narzędzia takiego jak unzip, jak pokazano w tym przykładzie:

   mkdir myappdir
   unzip ./my-app_app_rev3_2019_04_20.zip -d myappdir

   Rozpakowana zawartość pliku ZIP powinna być podobna do struktury opisanej w sekcji Struktura proxy interfejsu API.

3. W razie potrzeby zmodyfikuj pliki źródłowe. Opis plików źródłowych w konfiguracji serwera proxy znajdziesz w artykule Pliki konfiguracyjne i struktura katalogów serwera proxy interfejsu API.

   Aby na przykład włączyć monitorowanie stanu w proxy interfejsu API, edytuj plik konfiguracyjny TargetEndpoint w katalogu /apiproxy/targets/. Domyślny plik w tym katalogu to default.xml, ale jeśli używasz warunkowych elementów docelowych, mogą się w nim znajdować pliki o innych nazwach.

   W tym przypadku, jeśli plik konfiguracji TargetEndpoint i jego katalog nie istnieją, utwórz je.

4. Po zakończeniu edycji plików konfiguracyjnych serwera proxy zapisz zmiany.
5. Przejdź do nowego katalogu utworzonego podczas rozpakowywania plików ZIP (katalogu głównego rozpakowanych plików konfiguracyjnych).

   Jeśli na przykład rozpakowano pliki do katalogu /myappdir, przejdź do tego katalogu, jak pokazano w tym przykładzie:

   cd myappdir

   Przed ponownym zarchiwizowaniem plików konfiguracyjnych serwera proxy przejdź do tego katalogu, ponieważ nie chcesz, aby katalog /myappdir był uwzględniony w pliku ZIP. Katalog najwyższego poziomu w pliku ZIP musi mieć nazwę /apiproxy.

6. Ponownie zarchiwizuj pliki konfiguracyjne serwera proxy, w tym nowe lub zmienione pliki. Możesz użyć narzędzia takiego jak zip, jak pokazano w tym przykładzie:

   zip my-new-proxy.zip -r .

   Katalog najwyższego poziomu w pliku ZIP musi mieć nazwę /apiproxy.

   Nazwa pliku ZIP nie musi spełniać żadnych specjalnych wymagań. Nie musisz na przykład zwiększać numeru wersji ani podawać daty w nazwie pliku, ale może to być przydatne podczas debugowania lub kontroli źródła.

   Edge zwiększa numer wersji nowej konfiguracji serwera proxy, gdy ją przesyłasz.

7. Prześlij nową konfigurację serwera proxy za pomocą interfejsu Edge. (W widoku Proxy interfejsu API wybierz Projekt > Prześlij nową wersję).

   Jeśli pojawi się błąd, np. Bundle is invalid. Empty bundle., sprawdź, czy katalog najwyższego poziomu w pliku ZIP to /apiproxy. Jeśli tak nie jest, ponownie spakuj pliki konfiguracji serwera proxy z katalogu głównego rozwiniętego katalogu.

   Po przesłaniu nowej konfiguracji serwera proxy Edge zwiększa numer wersji i wyświetla go w widoku Podsumowanie wersji.

   Po przesłaniu nowej wersji za pomocą interfejsu Edge nie wdraża jej automatycznie.

8. Wdróż nową wersję.

Więcej informacji znajdziesz w artykule Tutorial: How to download a proxy using the UI and the management API (Samouczek: jak pobrać serwer proxy za pomocą interfejsu i interfejsu API zarządzania) w społeczności Apigee.

Struktura proxy interfejsu API

Proxy interfejsu API składa się z tej konfiguracji:

Struktura katalogu proxy interfejsu API i jego zawartość

Komponenty w tabeli powyżej są zdefiniowane przez pliki konfiguracyjne w tej strukturze katalogów:

Pliki konfiguracji i struktura katalogów proxy interfejsu API

W tej sekcji wyjaśniamy, czym są pliki konfiguracyjne i struktura katalogów serwera proxy interfejsu API.

• Konfiguracja podstawowa
• ProxyEndpoint
• TargetEndpoint
  • Konfiguracja TLS/SSL TargetEndpoint
• Zasady
• Flows
• Materiały

Konfiguracja podstawowa

/apiproxy/weatherapi.xml

Podstawowa konfiguracja proxy interfejsu API, która określa jego nazwę. Nazwa musi być unikalna w obrębie organizacji.

Przykładowa konfiguracja:

<APIProxy name="weatherapi">
</APIProxy>

Elementy konfiguracji podstawowej

ProxyEndpoint

Na ilustracji poniżej przedstawiono przepływ żądania i odpowiedzi:

/apiproxy/proxies/default.xml

Konfiguracja ProxyEndpoint określa interfejs przychodzący (dostępny dla klienta) dla proxy interfejsu API. Konfigurując ProxyEndpoint, ustawiasz konfigurację sieci, która określa, w jaki sposób aplikacje klienckie („aplikacje”) powinny wywoływać interfejs API proxy.

Przykładowa konfiguracja ProxyEndpoint będzie przechowywana w tym miejscu:/apiproxy/proxies

<ProxyEndpoint name="default">
  <PreFlow/>
  <Flows/>
  <PostFlow/>
  <HTTPProxyConnection>
    <BasePath>/weather</BasePath>
    <VirtualHost>default</VirtualHost>
  </HTTPProxyConnection>
  <FaultRules/>
  <DefaultFaultRule/>
  <RouteRule name="default">
    <TargetEndpoint>default</TargetEndpoint>
  </RouteRule>
</ProxyEndpoint>

Wymagane elementy konfiguracji w podstawowym elemencie ProxyEndpoint to:

Konfiguracja ProxyEndpoint Elementy

Konfigurowanie reguł routingu

Nazwany TargetEndpoint odnosi się do pliku konfiguracyjnego w /apiproxy/targets, do którego RouteRule przekazuje żądanie po przetworzeniu przez ProxyEndpoint.

Na przykład ta reguła RouteRule odnosi się do konfiguracji /apiproxy/targets/myTarget.xml:

<RouteRule name="default">
  <TargetEndpoint>myTarget</TargetEndpoint>
</RouteRule>

Bezpośrednie wywoływanie adresu URL

ProxyEndpoint może też bezpośrednio wywoływać usługę backendu. Bezpośrednie wywołanie adresu URL pomija każdą konfigurację o nazwie TargetEndpoints w /apiproxy/targets. Z tego powodu TargetEndpoint jest opcjonalną konfiguracją proxy interfejsu API, chociaż w praktyce bezpośrednie wywołanie z ProxyEndpoint nie jest zalecane.

Na przykład ta reguła RouteRule wykonuje wywołanie HTTP do strony http://api.mycompany.com/v2.

<RouteRule name="default">
  <URL>http://api.mycompany.com/v2</URL>
</RouteRule>

Trasy warunkowe

Reguły RouteRules można łączyć w łańcuchy, aby obsługiwać dynamiczne routing w czasie działania. Żądania przychodzące mogą być kierowane do nazwanych konfiguracji TargetEndpoint, bezpośrednio do adresów URL lub do kombinacji tych dwóch elementów na podstawie nagłówków HTTP, treści wiadomości, parametrów zapytania lub informacji kontekstowych, takich jak pora dnia, ustawienia regionalne itp.

Warunkowe reguły RouteRule działają podobnie jak inne instrukcje warunkowe w Apigee Edge. Zobacz Dokumentację warunków i Dokumentację zmiennych.

Na przykład poniższa kombinacja RouteRule najpierw ocenia żądanie przychodzące, aby sprawdzić wartość nagłówka HTTP. Jeśli nagłówek HTTP routeTo ma wartość TargetEndpoint1, żądanie jest przekazywane do punktu końcowego TargetEndpoint o nazwie TargetEndpoint1. W przeciwnym razie żądanie przychodzące jest przekazywane do http://api.mycompany.com/v2.

<RouteRule name="MyRoute">
  <Condition>request.header.routeTo = "TargetEndpoint1"</Condition>
  <TargetEndpoint>TargetEndpoint1</TargetEndpoint>
</RouteRule>
<RouteRule name="default">
  <URL>http://api.mycompany.com/v2</URL>
</RouteRule>

Trasy zerowe

Można zdefiniować regułę RouteRule o wartości null, aby obsługiwać scenariusze, w których wiadomość z żądaniem nie musi być przekazywana do TargetEndpoint. Jest to przydatne, gdy ProxyEndpoint wykonuje wszystkie niezbędne operacje, np. za pomocą JavaScriptu wywołuje usługę zewnętrzną lub pobiera dane z wyszukiwania w pamięci klucz/wartość usług API.

Na przykład poniższy kod definiuje pustą trasę:

<RouteRule name="GoNowhere"/>

Warunkowe trasy zerowe mogą być przydatne. W tym przykładzie skonfigurowano trasę o wartości null, która ma być wykonywana, gdy nagłówek HTTP request.header.X-DoNothing ma wartość inną niż null.

<RouteRule name="DoNothingOnDemand">
  <Condition>request.header.X-DoNothing != null</Condition>
</RouteRule>

Pamiętaj, że reguły RouteRules można łączyć w łańcuchy, więc warunkowa trasa null Route będzie zwykle jednym z elementów zestawu reguł RouteRules zaprojektowanego do obsługi routingu warunkowego.

Praktycznym zastosowaniem warunkowej trasy null jest obsługa buforowania. Używając wartości zmiennej ustawionej przez zasadę Cache, możesz skonfigurować serwer proxy interfejsu API tak, aby wykonywał trasę null, gdy wpis jest obsługiwany z pamięci podręcznej.

<RouteRule name="DoNothingUnlessTheCacheIsStale">
  <Condition>lookupcache.LookupCache-1.cachehit is true</Condition>
</RouteRule>

TargetEndpoint

Element TargetEndpoint jest odpowiednikiem wychodzącym elementu ProxyEndpoint. TargetEndpoint działa jako klient usługi backendu lub interfejsu API – wysyła żądania i otrzymuje odpowiedzi.

Proxy interfejsu API nie musi mieć żadnych docelowych punktów końcowych. ProxyEndpointy można skonfigurować tak, aby wywoływały adresy URL bezpośrednio. Proxy interfejsu API bez TargetEndpoints zwykle zawiera ProxyEndpoint, który bezpośrednio wywołuje usługę backendu lub jest skonfigurowany do wywoływania usługi za pomocą języka Java lub JavaScript.

Konfiguracja TargetEndpoint

/targets/default.xml

Element TargetEndpoint definiuje połączenie wychodzące z Apigee Edge do innej usługi lub zasobu.

Oto przykładowa konfiguracja TargetEndpoint:

<TargetEndpoint name="default">
  <PreFlow/>
  <Flows/>
  <PostFlow/>
  <HTTPTargetConnection>
    <URL>http://mocktarget.apigee.net</URL>
    <SSLInfo/>
  </HTTPTargetConnection>
  <FaultRules/>
  <DefaultFaultRule/>
  <ScriptTarget/>
  <LocalTargetConnection/>
</TargetEndpoint>

Konfiguracja TargetEndpoint Elementy

Punkt końcowy docelowy może wywoływać cel na jeden z tych sposobów:

• HTTPTargetConnection na potrzeby wywołań HTTP(S)
• LocalTargetConnection do łączenia lokalnych serwerów proxy
• ScriptTarget w przypadku wywołań skryptu Node.js hostowanego na serwerze brzegowym

W obiekcie TargetEndpoint skonfiguruj tylko jedną z tych opcji.

Konfiguracja TLS/SSL TargetEndpoint

Punkty końcowe docelowe często muszą zarządzać połączeniami HTTPS z różnorodną infrastrukturą backendu. Z tego powodu obsługiwanych jest wiele ustawień konfiguracji TLS/SSL.

TLS/SSL Elementy konfiguracji TargetEndpoint

<Ciphers>
 <Cipher>TLS_RSA_WITH_3DES_EDE_CBC_SHA</Cipher>
 <Cipher>TLS_RSA_WITH_DES_CBC_SHA</Cipher>
</Ciphers>

<Protocols>
 <Protocol>TLSv1.1</Protocol>
 <Protocol>TLSv1.2</Protocol>
</Protocols>

<CommonName wildcardMatch="true">*.myhost.com</CommonName>

Przykładowy TargetEndpoint z włączonym uwierzytelnianiem klienta wychodzącego

<TargetEndpoint name="default">
  <HttpTargetConnection>
        <URL>https://myservice.com</URL>
    <SSLInfo>
      <Enabled>true</Enabled>
      <ClientAuthEnabled>true</ClientAuthEnabled>
      <KeyStore>myKeystore</KeyStore>
      <KeyAlias>myKey</KeyAlias>
      <TrustStore>myTruststore</TrustStore>
    </SSLInfo>
  </HttpTargetConnection>
</TargetEndpoint>

Szczegółowe instrukcje znajdziesz w artykule Konfigurowanie protokołu TLS od brzegu sieci do backendu (chmura i chmura prywatna).

Używanie zmiennych przepływu do dynamicznego ustawiania wartości TLS/SSL

Możesz też dynamicznie ustawiać szczegóły TLS/SSL, aby obsługiwać elastyczne wymagania środowiska wykonawczego. Jeśli na przykład Twój serwer proxy łączy się z 2 potencjalnie różnymi celami (testowym i produkcyjnym), możesz skonfigurować serwer proxy interfejsu API tak, aby programowo wykrywał, które środowisko wywołuje, i dynamicznie ustawiał odwołania do odpowiedniego magazynu kluczy i magazynu zaufanych certyfikatów. Więcej informacji o tym scenariuszu i przykłady wdrożonych serwerów proxy interfejsu API znajdziesz w tym artykule w społeczności Apigee: Dynamic SSLInfo for TargetEndpoint using variable reference (Dynamiczne informacje SSL dla TargetEndpoint przy użyciu odwołania do zmiennej).

W tym przykładzie pokazującym, jak tag <SSLInfo> jest ustawiany w konfiguracji TargetEndpoint, wartości mogą być podawane w czasie działania, np. przez wywołanie Java Callout, zasadę JavaScript lub zasadę Assign Message. Użyj zmiennych wiadomości, które zawierają wartości, jakie chcesz ustawić.

Zmienne są dozwolone tylko w tych elementach:

<SSLInfo>
    <Enabled>{myvars.ssl.enabled}</Enabled>
    <ClientAuthEnabled>{myvars.ssl.client.auth.enabled}</ClientAuthEnabled>
    <KeyStore>{myvars.ssl.keystore}</KeyStore>
    <KeyAlias>{myvars.ssl.keyAlias}</KeyAlias>
    <TrustStore>{myvars.ssl.trustStore}</TrustStore>
</SSLInfo>

Używanie odwołań do dynamicznego ustawiania wartości TLS/SSL

Podczas konfigurowania TargetEndpoint, który używa protokołu HTTPS, musisz wziąć pod uwagę sytuację, w której wygasa certyfikat TLS/SSL lub zmiana konfiguracji systemu wymaga zaktualizowania certyfikatu. W przypadku instalacji Edge for Private Cloud podczas konfigurowania protokołu TLS/SSL za pomocą wartości statycznych lub zmiennych przepływu może być konieczne ponowne uruchomienie procesorów wiadomości.

Więcej informacji znajdziesz w artykule Aktualizowanie certyfikatu TLS.

Możesz jednak opcjonalnie skonfigurować TargetEndpoint tak, aby zamiast tego używał odwołania do magazynu kluczy lub magazynu zaufanych certyfikatów. Zaletą korzystania z odwołania jest to, że możesz je zaktualizować, aby wskazywało inny magazyn kluczy lub magazyn zaufanych certyfikatów. Dzięki temu zaktualizujesz certyfikat TLS/SSL bez konieczności ponownego uruchamiania procesorów wiadomości.

Poniżej znajdziesz przykład TargetEndpoint, który korzysta z odwołania do magazynu kluczy:

<SSLInfo>
    <Enabled>true</Enabled>
    <ClientAuthEnabled>false</ClientAuthEnabled>
    <KeyStore>ref://keystoreref</KeyStore>
    <KeyAlias>myKeyAlias</KeyAlias>
</SSLInfo>

Aby utworzyć odwołanie o nazwie keystoreref, użyj tego wywołania interfejsu API POST:

curl -X POST  -H "Content-Type:application/xml" https://api.enterprise.apigee.com/v1/o/{org_name}/e/{env_name}/references \
-d '<ResourceReference name="keystoreref">
    <Refers>myTestKeystore</Refers>
    <ResourceType>KeyStore</ResourceType>
</ResourceReference>' -u email:password

Odwołanie określa nazwę magazynu kluczy i jego typ.

Aby wyświetlić odwołanie, użyj tego wywołania interfejsu API GET:

curl -X GET https://api.enterprise.apigee.com/v1/o/[org_name}/e/{env_name}/references/keystoreref -u uname:password

Aby później zmienić odwołanie tak, aby wskazywało inny magazyn kluczy, upewnij się, że alias ma taką samą nazwę, i użyj tego wywołania PUT:

curl -X PUT -H "Content-Type:application/xml" https://api.enterprise.apigee.com/v1/o/{org_name}/e/{env_name}/references/keystoreref \
-d '<ResourceReference name="keystoreref">
    <Refers>myNewKeystore</Refers>
    <ResourceType>KeyStore</ResourceType>
</ResourceReference>' -u email:password

TargetEndpoint z docelowym równoważeniem obciążenia

Obiekty TargetEndpoint obsługują równoważenie obciążenia na wielu nazwanych serwerach docelowych przy użyciu 3 algorytmów równoważenia obciążenia.

Szczegółowe instrukcje znajdziesz w artykule Równoważenie obciążenia na serwerach backendu.

Zasady

Katalog /policies w proxy interfejsu API zawiera wszystkie zasady, które można dołączyć do przepływów w proxy interfejsu API.

Elementy konfiguracji zasad

Załącznik do zasad

Na tym obrazie widać sekwencję wykonywania przepływów serwera proxy interfejsu API:

Jak widać powyżej:

Zasady są dołączane jako etapy przetwarzania do przepływów. Nazwa zasady służy do odwoływania się do zasady, która ma być egzekwowana jako krok przetwarzania. Załącznik do zasad ma następujący format:

<Step><Name>MyPolicy</Name></Step>

Zasady są egzekwowane w kolejności, w jakiej zostały dołączone do przepływu. Na przykład:

<Step><Name>FirstPolicy</Name></Step>
<Step><Name>SecondPolicy</Name></Step>

Konfiguracja załącznika zasad Elementy

Przepływy

Elementy ProxyEndpoint i TargetEndpoint definiują potok przetwarzania wiadomości żądań i odpowiedzi. Potok przetwarzania składa się z przepływu żądania i przepływu odpowiedzi. Każdy przepływ żądania i przepływ odpowiedzi jest podzielony na PreFlow, co najmniej 1 opcjonalny przepływ „warunkowy” lub „nazwany” oraz PostFlow.

• PreFlow: zawsze się wykonuje. Wykonuje się przed wszystkimi przepływami warunkowymi.
• PostFlow: zawsze się wykonuje. Jest wykonywany po wszystkich przepływach warunkowych.

Możesz też dodać do ProxyEndpoint element PostClientFlow, który jest wykonywany po zwróceniu odpowiedzi do aplikacji klienta wysyłającej żądanie. Do tego przepływu można dołączyć tylko zasady MessageLogging i rozszerzenie Google Stackdriver Logging. PostClientFlow zmniejsza opóźnienie serwera proxy interfejsu API i udostępnia informacje do rejestrowania, które nie są obliczane, dopóki odpowiedź nie zostanie zwrócona do klienta, np. client.sent.start.timestamp i client.sent.end.timestamp. Ten przepływ jest używany głównie do pomiaru przedziału czasu między sygnaturami czasowymi początku i końca wiadomości z odpowiedzią.

Obejrzyj krótki film z instrukcjami

Oto przykład PostClientFlow z dołączoną zasadą rejestrowania wiadomości.

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

Potok przetwarzania serwera proxy interfejsu API wykonuje przepływy w tej kolejności:

Potok żądań:

1. Wstępny przepływ żądania serwera proxy
2. Przepływy warunkowe żądań proxy (opcjonalnie)
3. Proxy Request PostFlow
4. Target Request PreFlow
5. Kierowanie żądań na przepływy warunkowe (opcjonalnie)
6. Target Request PostFlow

Potok odpowiedzi:

1. Docelowy przepływ wstępny odpowiedzi
2. Docelowe przepływy warunkowe odpowiedzi (opcjonalnie)
3. Target Response PostFlow
4. Proxy Response PreFlow
5. Warunkowe przepływy odpowiedzi serwera proxy (opcjonalnie)
6. Proxy Response PostFlow
7. Odpowiedź PostClientFlow (opcjonalnie)

W konfiguracjach ProxyEndpoint lub TargetEndpoint należy skonfigurować tylko te przepływy, które mają załączone zasady. Elementy PreFlow i PostFlow muszą być określone w konfiguracji ProxyEndpoint lub TargetEndpoint tylko wtedy, gdy zasady muszą być egzekwowane podczas przetwarzania PreFlow lub PostFlow.

W przeciwieństwie do przepływów warunkowych kolejność elementów PreFlow i PostFlow nie ma znaczenia – serwer proxy interfejsu API zawsze wykonuje każdy z nich w odpowiednim momencie potoku, niezależnie od tego, gdzie pojawiają się w konfiguracji punktu końcowego.

Przepływy warunkowe

ProxyEndpoints i TargetEndpoints obsługują nieograniczoną liczbę przepływów warunkowych (zwanych też „nazwanymi przepływami”).

Serwer proxy interfejsu API sprawdza warunek określony w przepływie warunkowym, a jeśli warunek jest spełniony, wykonuje kroki przetwarzania w przepływie warunkowym. Jeśli warunek nie zostanie spełniony, kroki przetwarzania w przepływie warunkowym zostaną pominięte. Przepływy warunkowe są oceniane w kolejności zdefiniowanej w proxy interfejsu API. Wykonywany jest pierwszy przepływ, którego warunek jest spełniony.

Definiując przepływy warunkowe, możesz stosować kroki przetwarzania w proxy interfejsu API na podstawie:

• Identyfikator URI żądania
• Czasownik HTTP (GET/PUT/POST/DELETE)
• Wartość parametru zapytania, nagłówka i parametru formularza
• wiele innych rodzajów warunków.

Na przykład ten warunkowy przepływ określa, że jest wykonywany tylko wtedy, gdy ścieżka zasobu żądania to /accesstoken. Każde żądanie przychodzące ze ścieżką /accesstoken powoduje wykonanie tego przepływu wraz z zasadami do niego dołączonymi. Jeśli ścieżka żądania nie zawiera sufiksu /accesstoken, przepływ nie zostanie wykonany (chociaż może zostać wykonany inny przepływ warunkowy).

<Flows>
  <Flow name="TokenEndpoint">
    <Condition>proxy.pathsuffix MatchesPath "/accesstoken"</Condition>
    <Request>
      <Step>
        <Name>GenerateAccessToken</Name>
      </Step>
    </Request>
  </Flow>
</Flows>

Elementy konfiguracji przepływu

Przetwarzanie krokowe

Kolejność warunkowych przepływów jest wymuszana przez Apigee Edge. Przepływy warunkowe są wykonywane od góry do dołu. Pierwszy przepływ warunkowy, którego warunek przyjmuje wartość true, jest wykonywany tylko raz.

Na przykład w tej konfiguracji przepływu każde żądanie przychodzące, które nie zawiera sufiksu ścieżki /first ani /second, spowoduje wykonanie ThirdFlow, co wymusi zastosowanie zasad o nazwie Return404.

<Flows>
  <Flow name="FirstFlow">
    <Condition>proxy.pathsuffix MatchesPath "/first"</Condition>
    <Request>
      <Step><Name>FirstPolicy</Name></Step>
    </Request>
  </Flow>
  <Flow name="SecondFlow">
    <Condition>proxy.pathsuffix MatchesPath "/second"</Condition>
    <Request>
      <Step><Name>FirstPolicy</Name></Step>
      <Step><Name>SecondPolicy</Name></Step>
    </Request>
  </Flow>
  <Flow name="ThirdFlow">
    <Request>
      <Step><Name>Return404</Name></Step>
    </Request>
  </Flow>
</Flows>

Zasoby

„Zasoby” (pliki zasobów do użycia w proxy interfejsu API) to skrypty, kod i transformacje XSL, które można dołączać do przepływów za pomocą zasad. Pojawiają się one w sekcji „Skrypty” edytora proxy interfejsu API w interfejsie zarządzania.

Obsługiwane typy zasobów znajdziesz w sekcji Pliki zasobów.

Zasoby mogą być przechowywane w proxy interfejsu API, środowisku lub organizacji. W każdym przypadku zasób jest przywoływany w zasadach za pomocą nazwy. Usługi API rozwiązują nazwę, przechodząc od proxy interfejsu API do środowiska i poziomu organizacji.

Do zasobu przechowywanego na poziomie organizacji można się odwoływać w zasadach w dowolnym środowisku. Do zasobu przechowywanego na poziomie środowiska mogą odwoływać się zasady w tym środowisku. Zasób przechowywany na poziomie proxy interfejsu API może być używany tylko przez zasady w tym proxy interfejsu API.