Dokumentacja konfiguracji serwera proxy interfejsu API

Wyświetlasz dokumentację Apigee Edge.
Otwórz dokumentację Apigee X. informacje.

Jako programista pracujący dla Apigee Edge Twoje główne działania związane z programowaniem obejmują konfigurowanie serwerów proxy interfejsów API, które działają jako serwery proxy interfejsów API lub usług backendu. Ten dokument zawiera informacje o wszystkich elementach konfiguracji dostępnych podczas tworzenia serwerów proxy API.

Jeśli chcesz się dowiedzieć, jak tworzyć serwery proxy API, zacznij od tematu Tworzenie prostego serwera proxy interfejsu API.

Oto najczęstsze sposoby edytowania konfiguracji serwera proxy:

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

Lokalne tworzenie konfiguracji serwerów proxy

Konfiguracje serwera proxy możesz pobrać i edytować na komputerze lokalnym. Po zakończeniu przesyłasz wyniki do Edge. Ta metoda umożliwia zintegrowanie konfiguracji serwera proxy z kontrolą źródła, obsługą wersji i innymi współdzielonymi przepływami pracy. Pracując nad konfiguracją serwera proxy lokalnie, możesz też użyć własnego edytora XML i narzędzi do weryfikacji.

W tej sekcji opisano, jak za pomocą interfejsu użytkownika pobrać istniejącą konfigurację serwera proxy, zmodyfikować 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ę proxy (korzystając odpowiednio z poleceń fetchproxy i deployproxy).

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

1. Pobierz bieżącą konfigurację serwera proxy z interfejsu użytkownika Edge. (W widoku serwerów proxy interfejsu API wybierz Projekt > Pobierz wersję).
2. Na komputerze lokalnym utwórz nowy katalog i rozwiń w nim pobrany plik ZIP.

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

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

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

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

   Aby na przykład włączyć monitorowanie stanu na serwerze proxy interfejsu API, edytuj plik konfiguracji TargetEndpoint w katalogu /apiproxy/targets/. Domyślnym plikiem w tym katalogu jest default.xml, ale jeśli używasz celów warunkowych, mogą istnieć pliki o innych nazwach.

   W tym przypadku, jeśli plik konfiguracji TargetEndpoint ani jego katalog nie istnieje, utwórz go.

4. Po zakończeniu edytowania plików konfiguracji serwera proxy zapisz zmiany.
5. Przejdź do nowego katalogu utworzonego podczas rozpakowywania plików ZIP (katalogu głównego rozwiniętych plików konfiguracji).

   Jeśli na przykład pliki zostały rozwinięte do katalogu /myappdir, przejdź do tego katalogu, jak pokazano w poniższym przykładzie:

   cd myappdir

   Wybierz ten katalog, zanim ponownie zarchiwizujesz pliki konfiguracji serwera proxy, ponieważ nie chcesz, aby katalog /myappdir był zawarty w pliku ZIP. Katalog najwyższego poziomu w pliku ZIP to /apiproxy.

6. Ponownie archiwizuj pliki konfiguracji serwera proxy, w tym nowe i 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 to /apiproxy.

   Nie ma specjalnych wymagań dotyczących nazwy pliku ZIP. Nie musisz na przykład zwiększać numeru wersji ani określać daty w nazwie pliku, ale może to być przydatne podczas debugowania lub kontroli źródła.

   Po przesłaniu nowego serwera proxy Edge zwiększa numer wersji nowej konfiguracji serwera proxy.

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

   Jeśli pojawi się błąd, taki jak Bundle is invalid. Empty bundle., sprawdź, czy katalog najwyższego poziomu pliku ZIP to /apiproxy. Jeśli nie, zarchiwizuj 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 ją w widoku Podsumowanie wersji.

   Edge nie wdroży nowej wersji, gdy prześlesz ją za pomocą interfejsu użytkownika.

8. Wdróż nową wersję.

Więcej informacji znajdziesz w samouczku: jak pobrać serwer proxy za pomocą interfejsu użytkownika i interfejsu API zarządzania w społeczności Apigee.

Struktura proxy interfejsu API

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

Struktura i zawartość katalogów serwera proxy interfejsu API

Komponenty wymienione w powyższej tabeli są zdefiniowane w plikach konfiguracji w tej strukturze katalogów:

Pliki konfiguracji i struktura katalogów serwera proxy interfejsu API

W tej sekcji opisano pliki konfiguracji i strukturę katalogów na serwerze proxy interfejsu API.

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

Konfiguracja podstawowa

/apiproxy/weatherapi.xml

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

Przykładowa konfiguracja:

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

Podstawowe elementy konfiguracji

ProxyEndpoint

Ilustracja przedstawia przepływ żądania/odpowiedzi:

/apiproxy/proxies/default.xml

Konfiguracja ProxyEndpoint definiuje interfejs przychodzący (postrzegany przez klienta) dla serwera proxy interfejsu API. Konfigurując punkt końcowy serwera proxy, konfigurujesz konfigurację sieci określającą sposób, w jaki aplikacje klienckie („aplikacje”) powinny wywoływać interfejs API przez serwer proxy.

Poniższa przykładowa konfiguracja ProxyEndpoint byłaby przechowywana w regionie /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:

Elementy konfiguracji punktu końcowego serwera proxy

Jak skonfigurować reguły trasy

Nazwany punkt końcowy odnosi się do pliku konfiguracji w domenie /apiproxy/targets, do którego reguła trasy przekierowuje żądanie po przetworzeniu przez punkt końcowy.

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

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

Wywoływanie bezpośredniego adresu URL

Punkt końcowy ProxyEndpoint może też wywoływać bezpośrednio usługę backendu. Wywołanie bezpośredniego adresu URL pomija każdą konfigurację o nazwie TargetEndpoints w /apiproxy/targets. Z tego powodu TargetEndpoint jest opcjonalną konfiguracją proxy interfejsu API, ale w praktyce nie jest zalecane bezpośrednie wywoływanie z tego punktu końcowego.

Na przykład poniższa reguła RouteRule wykonuje wywołanie HTTP http://api.mycompany.com/v2.

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

Trasy warunkowe

Reguły tras można łączyć w łańcuchy, aby umożliwić obsługę routingu dynamicznego w czasie działania. Żądania przychodzące mogą być kierowane do nazwanych konfiguracji docelowych punktów końcowych, bezpośrednio do adresów URL lub do kombinacji tych parametrów na podstawie nagłówków HTTP, treści wiadomości, parametrów zapytania lub informacji kontekstowych, takich jak pora dnia, język itp.

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

Na przykład ta kombinacja reguły trasy najpierw ocenia żądanie przychodzące w celu zweryfikowania wartości nagłówka HTTP. Jeśli nagłówek HTTP routeTo zawiera wartość TargetEndpoint1, żądanie jest przekazywane do docelowego punktu końcowego o nazwie TargetEndpoint1. Jeśli nie, żą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 o wartości null

Można zdefiniować pustą regułę trasy, aby obsługiwać scenariusze, w których wiadomość żądania nie musi być przekazywana do docelowego punktu końcowego. Jest to przydatne, gdy ProxyEndpoint wykonuje wszystkie niezbędne operacje przetwarzania, na przykład używając JavaScriptu do wywołania usługi zewnętrznej lub pobierania danych z wyszukiwania do magazynu par klucz/wartość usług interfejsu API.

Na przykład tak wygląda trasa 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 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 tras można wiązać łańcuchami, więc warunkowa trasa o wartości null jest zwykle jednym z komponentów zestawu reguł tras zaprojektowanych do obsługi routingu warunkowego.

Praktyczne użycie warunkowej trasy o wartości null ułatwiłoby buforowanie. Korzystając z wartości zmiennej ustawionej przez zasadę pamięci podręcznej, możesz skonfigurować serwer proxy interfejsu API, aby wykonywał trasę o wartości null, gdy wpis jest udostępniany 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 końcowego serwera proxy. Docelowy punkt końcowy działa jako klient usługi backendu lub interfejsu API backendu – wysyła żądania i odbiera odpowiedzi.

Serwer proxy interfejsu API nie musi mieć żadnych punktów docelowych. Punkty końcowe serwera proxy można skonfigurować tak, aby bezpośrednio wywoływały adresy URL. Serwer proxy interfejsu API bez docelowych punktów końcowych zwykle zawiera punkt końcowy, który bezpośrednio wywołuje usługę backendu, albo skonfigurowany do wywoływania usług przy użyciu Javy lub JavaScriptu.

Konfiguracja docelowego punktu końcowego

/targets/default.xml

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

Oto przykładowa konfiguracja punktu końcowego docelowego:

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

Elementy konfiguracji docelowego punktu końcowego

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

• HTTPTargetConnection na potrzeby wywołań HTTP(S)
• LocalTargetConnection w przypadku łańcucha lokalnych serwerów proxy-proxy
• ScriptTarget dla wywołań skryptu Node.js hostowanego w Edge

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

Konfiguracja punktu końcowego TLS/SSL

Punkty końcowe docelowe często muszą zarządzać połączeniami HTTPS za pomocą heterogennej infrastruktury backendu. Z tego powodu jest obsługiwanych kilka ustawień konfiguracji TLS/SSL.

Elementy konfiguracji punktu końcowego protokołu TLS/SSL

<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 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 artykule Konfigurowanie protokołu TLS z brzegu do backendu (Cloud i Private Cloud).

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

Możesz też dynamicznie ustawiać szczegóły protokołu TLS/SSL, aby zapewnić obsługę elastycznych wymagań dotyczących środowiska wykonawczego. Jeśli na przykład serwer proxy łączy się z 2 potencjalnie różnymi celami (testowymi i produkcyjnymi), możesz skonfigurować serwer proxy interfejsu API tak, aby automatycznie wykrywał, które środowisko wywołuje, i dynamicznie ustawiał odwołania do odpowiedniego magazynu kluczy i magazynu zaufanych certyfikatów. Ten artykuł na stronie Apigee zawiera więcej informacji na ten temat oraz zawiera przykłady wdrożenia serwera proxy interfejsu API: https://community.apigee.com/articles/21424/dynamic-sslinfo-for-targetendpoint-using-variable.html.

W poniższym przykładzie ustawienia tagu <SSLInfo> w konfiguracji docelowego punktu końcowego można podać wartości w czasie działania, np. za pomocą objaśnienia w Javie, zasady JavaScript lub zasady Przypisz wiadomość. Użyj zmiennych wiadomości, które zawierają wartości, które chcesz ustawić.

Zmienne są dozwolone tylko w następujących 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

Konfigurując punkt końcowy, który korzysta z protokołu HTTPS, musisz wziąć pod uwagę okoliczności związane z wygaśnięciem certyfikatu TLS/SSL lub zmianami w konfiguracji systemu, które będą wymagały zaktualizowania certyfikatu. W przypadku instalacji Edge dla Private Cloud, w przypadku konfigurowania protokołu TLS/SSL przy użyciu wartości statycznych lub zmiennych przepływu, istnieje ryzyko, że będzie trzeba ponownie uruchomić procesory wiadomości.

Więcej informacji znajdziesz w artykule Aktualizowanie certyfikatu TLS.

Możesz jednak opcjonalnie skonfigurować obiekt TargetEndpoint w taki sposób, aby używał odwołania do magazynu kluczy lub magazynu zaufanych certyfikatów. Zaletą korzystania z referencji jest to, że możesz zaktualizować odwołanie, tak aby wskazywały inny magazyn kluczy lub magazyn zaufania, co pozwoli zaktualizować certyfikat TLS/SSL bez konieczności ponownego uruchamiania procesorów wiadomości.

Poniżej znajduje się przykład punktu końcowego docelowego, 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ć referencję o nazwie keystoreref, użyj tego wywołania interfejsu POST API:

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 tego 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ły inny magazyn kluczy, i upewnić się, że alias ma taką samą nazwę, 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

Punkt końcowy z docelowym równoważeniem obciążenia

TargetEndpoints obsługują równoważenie obciążenia na wielu nazwanych serwerach docelowych z użyciem 3 algorytmów równoważenia obciążenia.

Szczegółowe instrukcje znajdziesz w artykule Równoważenie obciążenia między serwerami backendu.

Zasady

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

Elementy konfiguracji zasad

Załącznik do zasad

Poniższy obraz przedstawia sekwencję wykonywania przepływów przez serwer proxy interfejsu API:

Jak pokazano powyżej:

Zasady są dołączone do przepływów jako kroki przetwarzania. Nazwa zasady służy do odwoływania się do zasady, która ma być egzekwowana jako etap przetwarzania. Załącznik 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>

Elementy konfiguracji załączników do zasad

Przepływy

ProxyEndpoint i TargetEndpoint określają potok do przetwarzania żądań i odpowiedzi. Potok przetwarzania składa się z przepływu żądań i przepływu odpowiedzi. Każdy przepływ żądań i odpowiedzi jest podzielony na przepływ wstępny, jeden lub więcej opcjonalnych przepływów „warunkowych” lub „nazwanych” oraz PostFlow.

• PreFlow: zawsze jest wykonywany. Wykonywane przed innymi przepływami warunkowymi.
• PostFlow: zawsze wykonywany. Wykonywane po wszystkich przepływach warunkowych.

Możesz też dodać obiekt PostClientFlow do obiektu ProxyEndpoint, który jest wykonywany po zwróceniu odpowiedzi do żądającej aplikacji klienckiej. Do tego procesu można dołączyć tylko zasadę MessageLogging i rozszerzenie Google Stackdriver Logging. PostClientFlow skraca czas oczekiwania na serwer proxy API i udostępnia do logowania informacje, które są obliczane dopiero po zwróceniu odpowiedzi do klienta, takie jak client.sent.start.timestamp i client.sent.end.timestamp.Przepływ ten służy przede wszystkim do pomiaru odstępu czasu między sygnaturami czasowymi rozpoczęcia i zakończenia wiadomości z odpowiedzią.

Obejrzyj krótki film instruktażowy

Oto przykład obiektu PostClientFlow z dołączoną zasadą 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 tej kolejności:

Potok żądań:

1. Wstępny przepływ żądania serwera proxy
2. Przepływy warunkowe żądań serwera proxy (opcjonalnie)
3. PostFlow żądania serwera proxy
4. Wstępny przepływ żądania docelowego
5. Kierowanie na przepływy warunkowe żądań (opcjonalnie)
6. Żądanie docelowe po przepływie

Potok odpowiedzi:

1. Docelowy proces wstępny
2. Przepływy warunkowe reakcji docelowej (opcjonalnie)
3. Docelowa odpowiedź po przepływie
4. Przepływ wstępny odpowiedzi serwera proxy
5. Przepływy warunkowe odpowiedzi serwera proxy (opcjonalnie)
6. Proxy Response PostFlow
7. Odpowiedź PostClientFlow (opcjonalnie)

W konfiguracjach punktu końcowego lub docelowego punktu końcowego należy skonfigurować tylko przepływy z przyłączonymi zasadami. Funkcje PreFlow i PostFlow trzeba określić w konfiguracji ProxyEndpoint lub TargetEndpoint tylko wtedy, gdy zasada musi być egzekwowana podczas przetwarzania PreFlow lub PostFlow.

W przeciwieństwie do przepływów warunkowych kolejność elementów PreFlow i PostFlow nie jest ważna – serwer proxy interfejsu API zawsze wykonuje je w odpowiednim punkcie potoku, niezależnie od tego, gdzie pojawiają się w konfiguracji punktu końcowego.

Przepływy warunkowe

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

Serwer proxy interfejsu API testuje warunek określony w procesie warunkowym. Jeśli warunek zostanie spełniony, kroki przetwarzania w procesie warunkowym są wykonywane przez serwer proxy interfejsu API. Jeśli warunek nie będzie spełniony, kroki przetwarzania w przepływie warunkowym będą pomijane. Przepływy warunkowe są oceniane w kolejności określonej na serwerze proxy interfejsu API. Przepływy warunkowe są oceniane w kolejności określonej na serwerze proxy interfejsu API. Przepływy warunkowe są oceniane w kolejności, w której zostanie spełniony pierwszy warunek.

Po zdefiniowaniu przepływów warunkowych możesz stosować kroki przetwarzania na serwerze proxy interfejsu API na podstawie:

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

Na przykład ten przepływ warunkowy 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 ze wszystkimi zasadami powiązanymi z przepływem. Jeśli ścieżka żądania nie zawiera sufiksu /accesstoken, przepływ nie zostanie wykonany (choć może 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

Przetwarzam krok

Apigee Edge egzekwuje sekwencyjną kolejność przepływów warunkowych. Przepływy warunkowe są wykonywane od góry do dołu. Pierwszy przepływ warunkowy, którego warunek przyjmuje wartość true, jest wykonywany i tylko jeden przepływ warunkowy jest wykonywany.

Na przykład w tej konfiguracji przepływu każde żądanie przychodzące, które nie zawiera sufiksu ścieżki /first ani /second, powoduje wykonanie polecenia ThirdFlow, wymuszając na nim zasadę 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 serwerach proxy interfejsu 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” w edytorze proxy interfejsu API w interfejsie zarządzania.

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

Zasoby mogą być przechowywane na serwerze proxy interfejsu API, środowisku lub organizacji. W każdym przypadku zasób ma w zasadzie przywołaną nazwę. Usługi interfejsu API interpretują nazwę, przechodząc z serwera proxy interfejsu API na środowisko na poziom organizacji.

Do zasobu zapisanego na poziomie organizacji mogą się odwoływać zasady w dowolnym środowisku. Do zasobu zapisanego na poziomie środowiska mogą się odwoływać zasady w tym środowisku. Do zasobu zapisanego na poziomie serwera proxy interfejsu API mogą się odwoływać tylko zasady na tym serwerze proxy interfejsu API.