Dokumentacja konfiguracji serwera proxy interfejsu API

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

Jesteś deweloperem Apigee pracującym nad Apigee Edge, więc Twoje główne działania skonfigurowanie serwerów proxy interfejsów API, które działają jako serwery proxy dla interfejsów API lub usług backendu. Ten dokument jest odniesienie do wszystkich elementów konfiguracji dostępnych podczas tworzenia serwerów proxy interfejsu API.

Jeśli dopiero uczysz się tworzyć serwery proxy interfejsów API, zalecamy zacząć od tego tematu Utwórz prosty interfejs API serwera proxy.

Najczęstsze sposoby edytowania konfiguracji serwera proxy:

• Korzystanie z za pomocą edytora XML w interfejsie Edge.
• Pobierz konfigurację i edytuj ją lokalnie, zgodnie z opisem w sekcji Lokalne tworzeniu konfiguracji proxy.

Lokalne tworzenie konfiguracji serwera proxy

Możesz pobrać konfiguracje serwera proxy, aby edytować je na komputerze lokalnym. Kiedy Gdy skończysz, prześlij wyniki do Edge. Takie podejście umożliwia integrację serwera proxy do kontroli źródła, obsługi wersji i innych współdzielonych przepływów pracy. Ponadto, według lokalnej konfiguracji serwera proxy, możesz użyć własnego edytora XML narzędzi.

Ta sekcja opisuje, jak za pomocą interfejsu pobrać istniejącą konfigurację serwera proxy, edytować ją a potem prześlij ją z powrotem do Edge w celu wdrożenia. Możesz też użyć apigeetool, aby pobrać i wdrożyć nową konfigurację serwera proxy (za pomocą narzędzi fetchproxy i deployproxy).

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

1. Pobierz bieżącą konfigurację serwera proxy w interfejsie Edge. (W przypadku serwerów proxy API w widoku danych, wybierz Projekt > Pobierz wersję).
2. Na komputerze lokalnym utwórz nowy katalog i rozwiń pobrany plik ZIP do .

   Aby rozwinąć plik ZIP, możesz użyć narzędzia takiego jak unzip, w następujący sposób: przykład pokazuje:

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

   Rozwinięta zawartość pliku ZIP powinna być podobna do struktury opisanej w Struktura serwera proxy interfejsu API.

3. W razie potrzeby zmodyfikuj pliki źródłowe. Opis plików źródłowych na serwerze proxy , patrz Pliki konfiguracji strukturę katalogu serwera proxy interfejsu API.

   Aby na przykład włączyć monitorowania zdrowia w serwera proxy interfejsu API, zmodyfikuj plik konfiguracji TargetEndpoint w Katalog /apiproxy/targets/. Domyślny plik w tym katalogu to default.xml, ale mogą też istnieć pliki o innych nazwach, jeśli używasz celów warunkowych.

   W tym przypadku, jeśli plik konfiguracji TargetEndpoint i jego katalog nie istnieją, je tworzyć.

4. Gdy skończysz edytowanie plików konfiguracji serwera proxy, zapisz zmiany.
5. Przejdź do nowego katalogu utworzonego podczas rozwijania plików ZIP (katalog główny rozwinięte pliki konfiguracji).

   Jeśli na przykład pliki zostały rozwinięte do katalogu /myappdir, zmień na zgodnie z poniższym przykładem:

   cd myappdir

   Przejdź do tego katalogu, zanim ponownie zarchiwizujesz pliki konfiguracji serwera proxy , bo nie chcesz, by katalog /myappdir był włączany do pliku ZIP. Katalog najwyższego poziomu w pliku ZIP musi obejmować /apiproxy.

6. Ponownie zarchiwizuj pliki konfiguracji serwera proxy, w tym nowe lub zmienione pliki. Za pomocą takie jak zip, jak pokazano w poniższym przykładzie:

   zip my-new-proxy.zip -r .

   Katalog najwyższego poziomu w pliku ZIP musi obejmować /apiproxy.

   Nie ma specjalnych wymagań co do nazwy pliku ZIP. Nie musisz na przykład: zwiększyć numer wersji lub określić datę w nazwie pliku, ale można to jest przydatny przy debugowaniu lub kontroli źródeł.

   Edge zwiększa numer wersji nowej konfiguracji serwera proxy podczas przesyłania .

7. Prześlij nową konfigurację serwera proxy za pomocą interfejsu Edge. (W sekcji serwery proxy interfejsów API w widoku danych, wybierz Projekt > Prześlij nową wersję).

   Jeśli pojawi się błąd taki jak Bundle is invalid. Empty bundle., sprawdź, katalog najwyższego poziomu Twojego pliku ZIP to /apiproxy. Jeśli nie, zarchiwizuj ją ponownie plików konfiguracji serwera proxy z katalogu głównego rozwiniętego katalogu.

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

   Edge nie wdroży nowej wersji po przesłaniu jej za pomocą interfejsu użytkownika.

8. Wdróż nową wersję.

Więcej informacji: Samouczek: jak pobrać serwer proxy za pomocą interfejsu użytkownika i interfejsu API do zarządzania Społeczność Apigee.

Struktura serwera proxy interfejsu API

Serwer proxy interfejsu API składa się z takiej konfiguracji:

Struktura katalogów serwera proxy interfejsu API i treści

Komponenty w tabeli powyżej są zdefiniowane przez pliki konfiguracji w tych plikach struktura katalogów:

Katalog i pliki konfiguracji struktura serwera proxy interfejsu API

W tej sekcji opisujemy pliki konfiguracji i strukturę katalogów serwera proxy interfejsu API.

• Konfiguracja podstawowa
• ProxyEndpoint
• TargetEndpoint
  • Konfiguracja docelowego punktu końcowego TLS/SSL
• Zasady
• Przepływy
• Materiały

Konfiguracja podstawowa

/apiproxy/weatherapi.xml

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

Przykładowa konfiguracja:

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

Podstawowe elementy konfiguracji

ProxyEndpoint

Poniższy obraz przedstawia przepływ żądania/odpowiedzi:

/apiproxy/proxies/default.xml

Konfiguracja ProxyEndpoint definiuje interfejs przychodzący (widoczny dla klienta) dla interfejsu API serwera proxy. Gdy konfigurujesz ProxyEndpoint, konfigurujesz konfigurację sieci, określa sposób wywoływania interfejsu API przez serwer proxy przez aplikacje klienckie („aplikacje”).

Poniższa przykładowa konfiguracja ProxyEndpoint będzie przechowywana w /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 punkcie ProxyEndpoint to:

Konfiguracja punktu końcowego serwera proxy Elements

Jak skonfigurować reguły trasy

Nazwany punkt końcowy odnosi się do pliku konfiguracji w folderze /apiproxy/targets do , w którym reguła RouteRule przekazuje żądanie po przetworzeniu przez punkt ProxyEndpoint.

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

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

Wywołanie bezpośredniego adresu URL

Punkt ProxyEndpoint może też bezpośrednio wywołać usługę backendu. Bezpośrednie wywołanie adresu URL powoduje pominięcie o nazwie konfiguracji TargetEndpoints w pliku /apiproxy/targets. Z tego powodu TargetEndpoint to opcjonalna konfiguracja serwera proxy interfejsu API, chociaż w praktyce jest to bezpośrednie wywołanie nie jest zalecane z ProxyEndpoint.

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

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

Trasy warunkowe

Reguły trasy można połączyć w łańcuch, aby obsługiwać routing dynamiczny w czasie działania. Żądania przychodzące mogą być kierowane do nazwanych konfiguracji docelowego punktu końcowego, bezpośrednio do adresów URL lub do kombinacji obu tych metod, na podstawie nagłówków HTTP, treści wiadomości, parametrów zapytania lub informacji kontekstowych, takich jak dzień, region itp.

Warunkowe reguły trasy działają tak jak inne instrukcje warunkowe w Apigee Edge. Patrz informacje o warunkach i informacje o zmiennych.

Na przykład poniższe połączenie reguły RouteRule najpierw sprawdza żądanie przychodzące, aby zweryfikować wartość nagłówka HTTP. Jeśli nagłówek HTTP routeTo zawiera wartość TargetEndpoint1, żądanie zostanie przekierowane do docelowego punktu końcowego 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 null

zerową regułę RouteRule można zdefiniować na potrzeby obsługi scenariuszy, w których wiadomość z żądaniem należy przekazać do punktu docelowego punktu końcowego. Jest to przydatne, gdy punkt końcowy proxy wykonuje wszystkie niezbędne przetwarzanie, np. przez JavaScript do wywołania usługi zewnętrznej lub pobierania danych z wyszukiwania do usług interfejsu API” klucz/wartość.

Na przykład poniższe zdefiniowanie trasy o wartości null:

<RouteRule name="GoNowhere"/>

Warunkowe trasy o wartości null mogą być przydatne. W poniższym przykładzie trasa o wartości null jest skonfigurowana tak jest wykonywane, 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 RouteRule można połączyć łańcuchami, więc warunkowa pusta trasa powinna mieć zwykle wartość 1 jest komponentem zbioru reguł trasy zaprojektowanych do obsługi routingu warunkowego.

Praktyczne wykorzystanie warunkowej trasy null wspiera buforowanie. Za pomocą wartości zmiennej określonej przez zasadę Cache możesz skonfigurować serwer proxy interfejsu API do wykonywania Trasa o wartości null w przypadku udostępniania wpisu z pamięci podręcznej.

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

TargetEndpoint

Docelowy punkt końcowy to wychodzący odpowiednik punktu ProxyEndpoint. Docelowy punkt końcowy działa jako do usługi backendu lub interfejsu API – wysyła on żądania i otrzymuje odpowiedzi.

Serwer proxy interfejsu API nie musi mieć żadnych punktów docelowych. Punkt pośredni ProxyEndpoints można skonfigurować tak, aby wywoływał adresy URL bezpośrednio. Serwer proxy interfejsu API bez punktu docelowego punktu końcowego zwykle zawiera punkt ProxyEndpoint, który bezpośrednio wywołuje usługę backendu albo skonfigurowano do wywoływania usługi za pomocą języka Java JavaScriptu.

Konfiguracja docelowego punktu końcowego

/targets/default.xml

Docelowy punkt końcowy definiuje połączenie wychodzące z Apigee Edge do innej usługi lub .

Oto przykładowa konfiguracja elementu TargetEndpoint:

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

Konfiguracja docelowego punktu końcowego Elements

Element TargetEndpoint może wywołać element docelowy na jeden z tych sposobów:

• HTTPTargetConnection w przypadku wywołań HTTP(S)
• LocalTargetConnection na potrzeby łańcucha lokalnego serwera proxy
• ScriptTarget w przypadku wywołań hostowanych przez Edge Skrypt Node.js

Skonfiguruj tylko 1 z tych elementów w docelowym punkcie końcowym.

Konfiguracja docelowego punktu końcowego TLS/SSL

Docelowy punkt końcowy często musi zarządzać połączeniami HTTPS z heterogenicznymi backendami i infrastrukturze. Z tego względu obsługiwane są różne ustawienia konfiguracji TLS/SSL.

TLS/SSL Elementy konfiguracji docelowego punktu końcowego

<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 docelowy punkt końcowy 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 sekcji Konfigurowanie TLS z Edge do backendu (Cloud i Private Cloud).

Zastosowanie zmienne przepływu do dynamicznego ustawiania wartości TLS/SSL

Możesz też dynamicznie ustawić szczegóły TLS/SSL, aby spełniały wymagania elastycznego środowiska wykonawczego. Jeśli na przykład serwer proxy łączy się z 2 potencjalnie różnymi miejscami docelowymi (docelowym testowym i środowisko docelowe, serwer proxy interfejsu API może automatycznie wykrywać środowisko. oraz dynamicznie ustawiać odwołania do odpowiedniego magazynu kluczy i magazynu zaufania. Poniżej Artykuł na karcie Społeczność Apigee wyjaśnia szczegółowo ten scenariusz i udostępnia dostępny do wdrożenia interfejs API z przykładami proxy: https://community.apigee.com/articles/21424/dynamic-sslinfo-for-targetendpoint-using-variable.html.

W tym przykładzie pokazano, jak ustawimy tag <SSLInfo> w sekcji konfigurację docelowego punktu końcowego, wartości można podać w czasie działania, np. w JavaScripcie Callout, zasady JavaScript lub zasady przypisywania wiadomości. Używaj dowolnych zmiennych wiadomości zawierają wartości, które chcesz ustawić.

Zmienne są dozwolone tylko w poniższych 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>

Zastosowanie odniesienia do dynamicznego ustawiania wartości TLS/SSL

Podczas konfigurowania punktu końcowego, który korzysta z protokołu HTTPS, należy wziąć pod uwagę sytuację, w której Certyfikat TLS/SSL wygasa lub zmiana konfiguracji systemu wymaga zaktualizowania certyfikatu. W Edge for Private Cloud, jeśli konfigurujesz TLS/SSL za pomocą wartości statycznych lub używając zmiennych przepływu, może być konieczne ponowne uruchomienie procesorów wiadomości.

Więcej informacji znajdziesz w artykule Aktualizowanie protokołu TLS certyfikat.

Możesz jednak opcjonalnie skonfigurować docelowy punkt końcowy tak, aby używał odwołania do parametru do magazynu kluczy lub zaufania. Zaletą korzystania z pliku referencyjnego jest to, że można aktualizować odniesienie do innego magazynu kluczy lub magazynu zaufania, który umożliwia aktualizację certyfikatu TLS/SSL bez na wypadek konieczności ponownego uruchamiania procesorów wiadomości.

Poniżej widać przykładowy punkt końcowy, który korzysta z odwołania do magazynu kluczy:

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

Użyj poniższego wywołania interfejsu POST API, aby utworzyć odwołanie o nazwie keystoreref:

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ć odniesienie, użyj następującego wywołania interfejsu GET API:

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ł inny magazyn kluczy, upewnij się, że alias tej samej nazwy, użyj następującego 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

TargetEndpoints obsługuje równoważenie obciążenia na wielu nazwanych serwerach docelowych z wykorzystaniem 3 obciążeń algorytmach równoważenia obciążenia.

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

Zasady

Katalog /policies w serwerze proxy interfejsu API zawiera wszystkie zasady, które mogą być dołączany do Flows na serwerze proxy API.

Elementy konfiguracji zasad

Załącznik zasad

Ten obraz przedstawia sekwencję wykonywania przepływów serwera proxy interfejsu API:

Jak pokazano powyżej:

Zasady są dołączone jako etapy przetwarzania w Przepływach. Nazwa zasady jest używana do: odnoszą się do zasady, która ma być egzekwowana jako krok przetwarzania. Format załącznika zasad to następujące:

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

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

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

Konfiguracja załącznika zasad Elements

Przepływy

ProxyEndpoint i TargetEndpoint definiują potok dla komunikatu żądania i odpowiedzi o przetwarzaniu danych. Potok przetwarzania składa się z przepływu żądań i odpowiedzi. Każda prośba przepływ i reagowanie jest podzielone na PreFlow, jeden lub więcej opcjonalnych „warunkowych”, lub z nazwą i PostFlow.

• PreFlow: zawsze jest wykonywany. Wykonywane przed jakimikolwiek przepływami warunkowymi.
• PostFlow: zawsze wykonywany. Wykonywany po dowolnych przepływach warunkowych.

Możesz też dodać interfejs PostClientFlow do punktu końcowego serwera proxy, który jest wykonywany po odpowiedź jest zwracana do aplikacji klienckiej wysyłającej żądanie. Tylko zasady MessageLogging i Można dołączyć rozszerzenie Google Stackdriver Logging w tym procesie. PostClientFlow zmniejsza czas oczekiwania na serwer proxy interfejsu API i udostępnia informacje rejestrowania, które nie jest obliczane do czasu zwrócenia odpowiedzi do klienta, np. client.sent.start.timestamp i client.sent.end.timestamp.Proces jest używany służy głównie do pomiaru przedziału czasu między sygnaturami czasowymi rozpoczęcia i zakończenia odpowiedzi .

Obejrzyj krótki film instruktażowy

Oto przykład interfejsu PostClientFlow z załączonymi zasadami logowania 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 następującej kolejności:

Potok żądań:

1. PreFlow żądania serwera proxy
2. Przepływy warunkowe żądania serwera proxy (opcjonalnie)
3. Żądanie serwera proxy po przepływie
4. Wstępne przepływy żądań docelowych
5. Przepływy warunkowe żądania docelowego (opcjonalnie)
6. Żądanie docelowe po przepływie

Potok odpowiedzi:

1. Reakcja docelowa w ramach wstępnego przepływu
2. Przepływy warunkowe odpowiedzi docelowej (opcjonalnie)
3. Docelowa odpowiedź po przepływie
4. PreFlow Proxy Response
5. Przepływy warunkowe odpowiedzi serwera proxy (opcjonalnie)
6. Odpowiedź serwera proxy w PostFlow
7. Odpowiedź PostClientFlow (opcjonalnie)

Tylko te przepływy z przyłączami zasad muszą być skonfigurowane w ProxyEndpoint lub Konfiguracje docelowego punktu końcowego. PreFlow i PostFlow trzeba określić tylko w ProxyEndpoint lub Konfiguracja docelowego punktu końcowego, gdy zasada musi być egzekwowana podczas PreFlow lub PostFlow o przetwarzaniu danych.

W przeciwieństwie do przepływów warunkowych kolejność elementów PreFlow i PostFlow nie jest taka sama jak ważne – serwer proxy interfejsu API będzie zawsze wykonywany w odpowiednim punkcie potoku, bez względu na to, gdzie się znajdują w konfiguracji punktu końcowego.

Przepływy warunkowe

ProxyEndpoints i TargetEndpoints obsługują nieograniczoną liczbę przepływów warunkowych (również nazywanych przepływami).

Serwer proxy interfejsu API testuje warunek określony w przepływie warunkowym oraz, jeśli warunek gdy zostanie osiągnięty, kroki przetwarzania w procesie warunkowym są wykonywane przez serwer proxy interfejsu API. Jeśli nie zostanie spełniony, kroki przetwarzania w przepływie warunkowym zostaną pominięte. Warunkowe przepływy są oceniane w kolejności zdefiniowanej na serwerze proxy interfejsu API i w przypadku pierwszego, którego warunek ma postać .

Definiując przepływy warunkowe, zyskujesz możliwość stosowania etapów przetwarzania na serwerze proxy API w oparciu o:

• 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 poniższy przepływ warunkowy określa, że jest on wykonywany tylko wtedy, gdy ścieżka zasobu żądania to /accesstoken. Wszystkie żądania przychodzące z parametrem ścieżka /accesstoken powoduje wykonanie tego przepływu wraz ze wszystkimi zasadami które są powiązane z procesem. Jeśli ścieżka żądania nie zawiera sufiksu /accesstoken, przepływ nie zostanie wykonany (mimo że inny przepływ warunkowy może).

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

Elementy konfiguracji przepływu

Przetwarzanie etapu

Apigee Edge wymusza sekwencyjną kolejność przepływów warunkowych. Przepływy warunkowe wykonywać od góry do dołu. Pierwszy przepływ warunkowy, którego stan przyjmuje wartość Wykonuje się zadanie true i tylko 1 przepływ warunkowy jest wykonywany.

Na przykład w tej konfiguracji przepływu wszystkie żądania przychodzące, które nie zawierają sufiks ścieżki /first lub /second będzie powodować, że ThirdFlow do wykonania, egzekwując 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żytku przez serwery proxy API) to skrypty, kod i przekształcenia XSL które można dołączyć do przepływów za pomocą zasad. Pojawią się one w sekcji „Skrypty”. Sekcja interfejsu API edytora proxy w interfejsie zarządzania.

Listę obsługiwanych plików znajdziesz w sekcji Pliki zasobów typów zasobów.

Zasoby mogą być przechowywane przez serwer proxy interfejsu API, środowisko lub organizację. W każdym przypadku zasób jest przywoływany w zasadzie za pomocą nazwy. Usługi API rozpoznają nazwę przez przeniesienie z interfejsu API z serwera proxy do środowiska, na poziomie organizacji.

Do zasobu zapisanego na poziomie organizacji mogą odwoływać się zasady w dowolnym środowisku. Zasady w tym środowisku mogą odwoływać się do zasobów przechowywanych na poziomie środowiska. O do zasobu zapisanego na poziomie serwera proxy interfejsu API mogą odwoływać się wyłącznie zasady w tym serwerze proxy.