Referenz zur API-Proxy-Konfiguration

<ph type="x-smartling-placeholder"></ph> Sie sehen die Dokumentation zu Apigee Edge.
Gehen Sie zur Apigee X-Dokumentation. Weitere Informationen

Als Entwickler, der mit Apigee Edge arbeitet, umfassen Ihre primären Entwicklungsaktivitäten folgende Aufgaben: Konfigurieren von API-Proxys, die als Proxys für APIs oder Back-End-Dienste fungieren. Dieses Dokument enthält eine Referenz aller Konfigurationselemente, die Ihnen beim Erstellen von API-Proxys zur Verfügung stehen.

Wenn Sie lernen, API-Proxys zu erstellen, sollten Sie mit dem Thema Einfachen API-Proxy erstellen beginnen.

Die häufigsten Methoden zum Bearbeiten von Proxykonfigurationen sind:

• Mit im XML-Editor in der Edge-Benutzeroberfläche
• Laden Sie die Konfiguration herunter und bearbeiten Sie sie lokal, wie unter Lokale Entwicklung von Proxykonfigurationen beschrieben.

Lokale Entwicklung von Proxy-Konfigurationen

Sie können Ihre Proxykonfigurationen herunterladen, um sie auf einem lokalen Computer bearbeiten zu können. Wann? Sobald Sie fertig sind, laden Sie die Ergebnisse in Edge hoch. Auf diese Weise können Sie die Proxykonfigurationen in Ihre Versionsverwaltung, Versionsverwaltung und andere freigegebene Workflows integrieren. Wenn Sie lokal an einer Proxykonfiguration arbeiten, können Sie außerdem Ihren eigenen XML-Editor und Validierungstools verwenden.

In diesem Abschnitt wird beschrieben, wie Sie über die Benutzeroberfläche eine vorhandene Proxy-Konfiguration herunterladen, bearbeiten, und es dann zur Bereitstellung wieder in Edge hochladen. Außerdem können Sie mit apigeetool eine neue Proxykonfiguration herunterladen und bereitstellen (mithilfe der Befehle fetchproxy bzw. deployproxy).

So bearbeiten Sie eine Proxykonfiguration lokal über die Benutzeroberfläche:

1. Laden Sie die aktuelle Proxy-Konfiguration in der Edge-Benutzeroberfläche herunter. (In den API-Proxys wählen Sie Projekt > Überarbeitung herunterladen.
2. Erstellen Sie auf Ihrem lokalen Computer ein neues Verzeichnis und erweitern Sie die heruntergeladene ZIP-Datei.

   Zum Erweitern der ZIP-Datei können Sie ein Dienstprogramm wie unzip verwenden, wie im folgenden Beispiel gezeigt:

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

   Der maximierte Inhalt der ZIP-Datei sollte der unter API-Proxy-Struktur beschriebenen Struktur ähneln.

3. Bearbeiten Sie die Quelldateien nach Bedarf. Eine Beschreibung der Quelldateien in einer Proxykonfiguration finden Sie unter Konfigurationsdateien und die Verzeichnisstruktur eines API-Proxys.

   Wenn Sie beispielsweise das Statusmonitoring in Ihrem API-Proxy aktivieren möchten, bearbeiten Sie die Konfigurationsdatei "TargetEndpoint" im Verzeichnis /apiproxy/targets/. Die Standarddatei in diesem Verzeichnis ist default.xml. Wenn Sie jedoch bedingte Ziele verwenden, können Dateien mit anderen Namen vorhanden sein.

   Erstellen Sie in diesem Fall die neue TargetEndpoint-Konfigurationsdatei und das zugehörige Verzeichnis.

4. Nachdem Sie die Proxykonfigurationsdateien bearbeitet haben, speichern Sie Ihre Änderungen.
5. Wechseln Sie in das neue Verzeichnis, das Sie beim Erweitern der ZIP-Dateien erstellt haben (das Stammverzeichnis der erweiterten Konfigurationsdateien).

   Wenn Sie die Dateien beispielsweise in das Verzeichnis /myappdir erweitert haben, wechseln Sie in dieses Verzeichnis, wie im folgenden Beispiel gezeigt:

   cd myappdir

   Wechseln Sie in dieses Verzeichnis, bevor Sie Ihre Proxykonfigurationsdateien neu archivieren, da das Verzeichnis /myappdir nicht in der ZIP-Datei enthalten sein soll. Das Verzeichnis der obersten Ebene in der ZIP-Datei muss /apiproxy sein.

6. Archivieren Sie die Proxykonfigurationsdateien neu, einschließlich der neuen oder geänderten Dateien. Sie können ein Dienstprogramm wie zip verwenden, wie im folgenden Beispiel gezeigt:

   zip my-new-proxy.zip -r .

   Das Verzeichnis der obersten Ebene in der ZIP-Datei muss /apiproxy sein.

   Für den Namen der ZIP-Datei gibt es keine besonderen Anforderungen. Es ist beispielsweise nicht erforderlich, die Überarbeitungsnummer zu erhöhen oder das Datum im Dateinamen anzugeben. Dies kann jedoch für die Fehlerbehebung oder die Versionsverwaltung nützlich sein.

   Edge erhöht die Überarbeitungsnummer der neuen Proxy-Konfiguration beim Hochladen für Sie .

7. Laden Sie die neue Proxy-Konfiguration über die Edge-Benutzeroberfläche hoch. (In den API-Proxys wählen Sie Projekt > Laden Sie eine neue Version hoch.

   Wenn ein Fehler wie Bundle is invalid. Empty bundle. angezeigt wird, prüfen Sie, ob das oberste Verzeichnis Ihrer ZIP-Datei /apiproxy ist. Ist dies nicht der Fall, archivieren Sie Ihre Proxykonfigurationsdateien erneut aus dem Stammverzeichnis des erweiterten Verzeichnisses.

   Nach dem Hochladen Ihrer neuen Proxy-Konfiguration erhöht Edge die Überarbeitungsnummer und wird es in der Ansicht Revisionszusammenfassung angezeigt.

   Edge stellt die neue Version nicht für Sie bereit, nachdem Sie sie über die Benutzeroberfläche hochgeladen haben.

8. Stellen Sie Ihre neue Überarbeitung bereit.

Weitere Informationen finden Sie unter Anleitung: Herunterladen eines Proxys mithilfe der UI und der Verwaltungs-API in der Apigee-Community

API-Proxystruktur

Ein API-Proxy besteht aus der folgenden Konfiguration:

API-Proxy-Verzeichnisstruktur und -Inhalte

Die Komponenten in der obigen Tabelle werden durch Konfigurationsdateien in der folgenden Verzeichnisstruktur definiert:

Konfigurationsdateien und Verzeichnisstruktur eines API-Proxys

In diesem Abschnitt werden die Konfigurationsdateien und die Verzeichnisstruktur eines API-Proxys erläutert.

• Basiskonfiguration
• ProxyEndpoint
• TargetEndpoint
  • TLS/SSL-TargetEndpoint-Konfiguration
• Richtlinien
• Abläufe
• Ressourcen

Basiskonfiguration

/apiproxy/weatherapi.xml

Die Basiskonfiguration für einen API-Proxy, der den Namen des API-Proxys definiert. Der Name muss innerhalb einer Organisation eindeutig sein.

Beispielkonfiguration:

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

Basiskonfigurationselemente

ProxyEndpoint

Die folgende Abbildung zeigt den Ablauf von Anfrage/Antwort:

/apiproxy/proxies/default.xml

Die ProxyEndpoint-Konfiguration definiert die eingehende (Client-bezogene) Schnittstelle für einen API-Proxy. Wenn Sie einen ProxyEndpoint konfigurieren, richten Sie eine Netzwerkkonfiguration ein, die definiert, wie Clientanwendungen ('Apps') die Proxy-API aufrufen.

Die folgende ProxyEndpoint-Konfiguration würde unter /apiproxy/proxies gespeichert werden:

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

Folgende Konfigurationselemente sind in einem einfachen ProxyEndpoint erforderlich:

ProxyEndpoint-Konfigurationselemente

So konfigurieren Sie RouteRules

Ein benannter TargetEndpoint bezieht sich auf eine Konfigurationsdatei unter /apiproxy/targets, an die RouteRule eine Anfrage nach der Verarbeitung durch den ProxyEndpoint weiterleitet.

Die folgende RouteRule bezieht sich beispielsweise auf die Konfiguration /apiproxy/targets/myTarget.xml:

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

Direkter URL-Aufruf

Ein ProxyEndpoint kann auch direkt einen Back-End-Dienst aufrufen. Bei dem direkten URL-Aufruf werden alle benannten TargetEndpoints-Konfigurationen unter /apiproxy/targets umgangen. Aus diesem Grund ist TargetEndpoint eine optionale API-Proxykonfiguration, obwohl in der Praxis kein direkter Aufruf vom ProxyEndpoint empfohlen wird.

Die folgende RouteRule führt beispielsweise einen HTTP-Aufruf an http://api.mycompany.com/v2 aus.

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

Bedingte Routen

RouteRules können für die Unterstützung von dynamischem Routing zur Laufzeit verkettet werden. Eingehende Anfragen können an benannte TargetEndpoint-Konfigurationen, direkt an URLs oder eine Kombination aus beidem weitergeleitet werden, basierend auf HTTP-Headern, Nachrichteninhalten, Suchparametern oder Kontextinformationen wie Tageszeit, Gebietsschema usw.

Bedingte RouteRules funktionieren wie andere bedingte Anweisungen in Apigee Edge. Weitere Informationen finden Sie unter Referenz für Bedingungen und Referenz für Variablen.

Die folgende RouteRule-Kombination wertet beispielsweise zuerst die eingehende Anfrage aus, um den Wert eines HTTP-Headers zu prüfen. Wenn der HTTP-Header routeTo den Wert TargetEndpoint1 hat, wird die Anfrage an den TargetEndpoint mit dem Namen TargetEndpoint1 weitergeleitet. Ist dies nicht der Fall, wird die eingehende Anfrage an http://api.mycompany.com/v2 weitergeleitet.

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

Nullrouten

Eine Null-RouteRule kann so definiert werden, dass sie Supportszenarien unterstützt, in denen die Anfragenachricht nicht an den TargetEndpoint weitergeleitet werden muss. Dies ist nützlich, wenn der ProxyEndpoint die gesamte Verarbeitung übernimmt, z. B. indem JavaScript verwendet wird, um einen externen Dienst aufzurufen, oder Daten aus einer Suche in den Schlüssel/Wert-Speicher der API-Dienste abzurufen.

Im Folgenden wird beispielsweise eine Nullroute definiert:

<RouteRule name="GoNowhere"/>

Bedingte Nullrouten können nützlich sein. Im folgenden Beispiel wird eine Nullroute konfiguriert, die ausgeführt wird, wenn ein HTTP-Header request.header.X-DoNothing einen anderen Wert als null hat.

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

Denken Sie daran, dass die Routingregeln verkettet werden können. Eine bedingte Nullroute wäre also normalerweise eine Komponente eines Satzes von Routingregeln, die für ein bedingtes Routing geeignet sind.

Eine praktische Verwendung einer bedingten Nullroute würde das Caching unterstützen. Mithilfe des Werts der Variablen, der durch die Cache-Richtlinie festgelegt wird, können Sie einen API-Proxy so konfigurieren, dass die Nullroute ausgeführt wird, wenn ein Eintrag aus dem Cache bereitgestellt wird.

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

TargetEndpoint

Ein TargetEndpoint ist die ausgehende Entsprechung eines ProxyEndpoints. Ein TargetEndpoint funktioniert wie -Client an einen Back-End-Dienst oder eine API - er sendet Anfragen und empfängt Antworten.

Ein API-Proxy benötigt keine TargetEndpoints. ProxyEndpoints können so konfiguriert werden, dass URLs direkt aufgerufen werden. Ein API-Proxy ohne TargetEndpoints enthält in der Regel einen ProxyEndpoint, der entweder einen Back-End-Dienst direkt aufruft oder einen Dienst konfiguriert, der Java oder JavaScript verwendet.

TargetEndpoint-Konfiguration

/targets/default.xml

Der TargetEndpoint definiert die ausgehende Verbindung von Apigee Edge zu einem anderen Dienst oder .

Hier ein Beispiel für eine TargetEndpoint-Konfiguration:

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

TargetEndpoint-Konfigurationselemente

Ein TargetEndpoint kann ein Ziel auf eine der folgenden Arten aufrufen:

• HTTPTargetConnection für HTTP(S)-Aufrufe
• LocalTargetConnection für die lokale Proxy-zu-Proxy-Verkettung
• ScriptTarget für Aufrufe eines von Edge-gehosteten Node.js-Script

Konfigurieren Sie nur eines davon in einem TargetEndpoint.

TLS/SSL-TargetEndpoint-Konfiguration

TargetEndpoints müssen häufig HTTPS-Verbindungen mit heterogenen Back-End-Infrastruktur verwalten. Aus diesem Grund werden verschiedene TLS/SSL-Konfigurationseinstellungen unterstützt.

TLS/SSL-Konfigurationselemente für 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>

Beispiel für TargetEndpoint mit aktivierter ausgehender Client-Authentifizierung

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

Eine ausführliche Anleitung finden Sie unter TLS konfigurieren vom Edge zum Back-End (Cloud und Private Cloud).

Ablaufvariablen zum dynamischen Festlegen von TLS/SSL-Werten verwenden

Sie können auch TLS/SSL-Details dynamisch festlegen, um flexible Laufzeitanforderungen zu unterstützen. Wenn Ihr Proxy zum Beispiel mit zwei möglichen Zielen verbunden ist (ein Testziel und ein Produktionsziel), können Sie dafür sorgen, dass Ihr API-Proxy programmatisch ermittelt, welche Umgebung aufgerufen wird, und Verweise dynamisch auf den entsprechenden Schlüsselspeicher und Truststore festlegen. Im folgenden Artikel der Apigee-Community wird dieses Szenario ausführlich erläutert und es werden Beispiele für ausführbare API-Proxys bereitgestellt: https://community.apigee.com/articles/21424/dynamic-sslinfo-for-targetendpoint-using-variable.html.

Im folgenden Beispiel wird gezeigt, wie das Tag <SSLInfo> in einer TargetEndpoint-Konfiguration festgelegt werden. Die Werte können zur Laufzeit bereitgestellt werden, beispielsweise über die Richtlinien "Java-Callout", "JavaScript" oder "Assign Message". Verwenden Sie die Nachrichtenvariablen, die die Werte enthalten, die Sie festlegen möchten.

Variablen sind nur in folgenden Elementen zulässig.

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

Referenzen verwenden, um TLS/SSL-Werte dynamisch festzulegen

Wenn Sie einen TargetEndpoint konfigurieren, der HTTPS verwendet, müssen Sie berücksichtigen, Das TLS/SSL-Zertifikat läuft ab oder eine Änderung der Systemkonfiguration erfordert, dass Sie das Zertifikat aktualisieren. In wenn Sie TLS/SSL mithilfe statischer Werte oder durch mit Ablaufvariablen beginnen, müssen Sie die Message Processors möglicherweise neu starten.

Weitere Informationen finden Sie unter TLS-Zertifikat aktualisieren.

Sie können den TargetEndpoint jedoch optional so konfigurieren, dass er einen Verweis auf den Keystore oder Truststore verwendet. Der Vorteil einer Referenz besteht darin, dass Sie die Referenz aktualisieren können, um auf einen anderen Keystore oder Truststore zu verweisen, um das TLS/SSL-Zertifikat zu aktualisieren, ohne die Nachrichtenprozessoren neu starten zu müssen.

Im Folgenden sehen Sie ein Beispiel für einen TargetEndpoint, der einen Verweis auf den Schlüsselspeicher verwendet:

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

Verwenden Sie den folgenden POST-API-Aufruf, um die Referenz mit dem Namen keystoreref zu erstellen:

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

Die Referenz gibt den Namen des Schlüsselspeichers und seinen Typ an.

Verwenden Sie den folgenden GET API-Aufruf, um die Referenz aufzurufen:

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

Verwenden Sie den folgenden PUT-Aufruf, um später die Referenz so zu ändern, dass sie auf einen anderen Schlüsselspeicher verweist, damit der Alias denselben Namen hat:

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 mit Ziel-Load-Balancing

TargetEndpoints unterstützt Load-Balancing über mehrere benannte TargetServer mit drei Load-Balancing-Algorithmen.

Eine ausführliche Anleitung finden Sie unter Load-Balancing für Backends Server.

Richtlinien

Das Verzeichnis /policies in einem API-Proxy enthält alle Richtlinien, die an Abläufe im API-Proxy angehängt werden können.

Richtlinienkonfigurationselemente

Richtlinienbindung

Die folgende Abbildung zeigt die Ausführungssequenz der API-Proxys:

Wie oben gezeigt:

Richtlinien werden als Verarbeitungsschritte an Abläufe angehängt. Mit dem Namen der Richtlinie wird auf die Richtlinie verwiesen, die als Verarbeitungsschritt erzwungen werden soll. Richtlinienanhänge haben folgendes Format:

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

Richtlinien werden in der Reihenfolge erzwungen, in der sie einem Ablauf zugeordnet sind. Beispiel:

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

Konfigurationselemente der Richtlinienanhänge

Abläufe

ProxyEndpoint und TargetEndpoint definieren eine Pipeline für die Verarbeitung von Anfragen und Antworten. Eine Verarbeitungspipeline besteht aus einem Anfrageablauf und einem Antwortablauf. Jeder Anfrageablauf und Antwortablauf ist in einen PreFlow, einen oder mehrere optionale "Conditional"- oder "named"-Abläufe sowie in einen PostFlow unterteilt.

• PreFlow: Wird immer ausgeführt. Wird vor allen bedingten Abläufen ausgeführt.
• PostFlow: Wird immer ausgeführt. Wird nach allen bedingten Abläufen ausgeführt.

Sie können dem ProxyEndpoint auch einen PostClientFlow hinzufügen, der ausgeführt wird, nachdem die Antwort an die anfragende Clientanwendung zurückgegeben wird. An diesen Ablauf können nur die MessageLogging-Richtlinie und die Google Stackdriver Logging-Erweiterung angehängt werden. PostClientFlow reduziert die Latenz des API-Proxys und stellt Informationen für Logging zur Verfügung, die erst berechnet werden, wenn die Antwort an den Client zurückgegeben wurde, z. B. client.sent.start.timestamp und client.sent.end.timestamp. Der Ablauf wird hauptsächlich für die Messung des Zeitintervalls zwischen dem Start- und Endzeitstempel der Antwortnachricht verwendet.

Kurzes Video mit Anleitung ansehen

Hier ein Beispiel für einen PostClientFlow mit angehängter Nachrichten-Logging-Richtlinie:

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

Die API-Proxy-Verarbeitungspipeline führt Flows in der folgenden Sequenz aus:

Anfrage-Pipeline:

1. Proxyanfrage-PreFlow
2. Proxyanfrage für bedingte Abläufe (optional)
3. Proxyanfrage PostFlow
4. Zielanfrage PreFlow
5. Zielanfrage für bedingte Abläufe (optional)
6. Zielanfrage PostFlow

Antwort-Pipeline:

1. Zielantwort PreFlow
2. Zielantwort für bedingte Abläufe (optional)
3. Zielantwort PostFlow
4. Proxyantwort PreFlow
5. Proxyantwort für bedingte Abläufe (optional)
6. Proxyantwort PostFlow
7. PostClientFlow-Antwort (optional)

Nur Abläufe mit Richtlinienanhängen müssen in ProxyEndpoint- oder TargetEndpoint-Konfigurationen konfiguriert werden. PreFlow und PostFlow müssen nur in einer ProxyEndpoint- oder TargetEndpoint-Konfiguration angegeben werden, wenn eine Richtlinie während der PreFlow- oder PostFlow-Verarbeitung erzwungen werden muss.

Im Gegensatz zu bedingten Abläufen ist die Reihenfolge von PreFlow- und PostFlow-Elementen nicht wichtig. Der API-Proxy wird immer an der entsprechenden Stelle in der Pipeline ausgeführt, unabhängig davon, wo sie in der Endpunktkonfiguration angezeigt werden.

Bedingte Abläufe

ProxyEndpoints und TargetEndpoints unterstützen eine unbegrenzte Anzahl bedingter Abläufe (auch als "benannte Abläufe" bezeichnet).

Der API-Proxy testet die im bedingten Ablauf angegebene Bedingung. Wenn die Bedingung erfüllt wird, werden die Verarbeitungsschritte im bedingten Ablauf vom API-Proxy ausgeführt. Wird die Bedingung nicht erfüllt, werden die Verarbeitungsschritte im bedingten Ablauf umgangen. Bedingte Abläufe werden in der im API-Proxy definierten Reihenfolge ausgewertet und der erste, dessen Bedingung erfüllt ist, wird ausgeführt.

Durch die Definition bedingter Abläufe können Sie die Verarbeitungsschritte in einem API-Proxy basierend auf Folgendem anwenden:

• Anfrage-URI
• HTTP-Verb (GET/PUT/POST/DELETE)
• Wert eines Abfrageparameters, Headers und Formularparameters
• Viele andere Arten von Bedingungen

Der folgende bedingte Ablauf gibt beispielsweise an, dass er nur ausgeführt wird, wenn der Anfrageressourcenpfad /accesstoken ist. Jede eingehende Anfrage mit dem Pfad /accesstoken führt dazu, dass dieser Ablauf zusammen mit allen Richtlinien ausgeführt wird, die an den Ablauf angehängt sind. Wenn der Anfragepfad nicht das Suffix /accesstoken enthält, wird der Ablauf nicht ausgeführt (obwohl ein anderer bedingter Ablauf möglich ist).

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

Elemente der Ablaufkonfiguration

Schrittverarbeitung

Die sequenzielle Reihenfolge von bedingten Abläufen wird von Apigee Edge erzwungen. Bedingte Abläufe werden von oben nach unten ausgeführt. Der erste bedingte Ablauf, dessen Bedingung true erfüllt, wird ausgeführt und nur ein bedingter Ablauf wird ausgeführt.

Beispiel: In der folgenden Ablaufkonfiguration führt jede eingehende Anfrage, die nicht das Pfadsuffix /first oder /second enthält, ThirdFlow aus. Dabei wird die Richtlinie Return404 ausgeführt.

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

Ressourcen

"Ressourcen" (Ressourcendateien zur Verwendung in API-Proxys) sind Skripts, Code und XSL-Transformationen, die Abläufen mithilfe von Richtlinien hinzugefügt werden können. Diese erscheinen in den Skripten der API Proxy-Editor auf der Verwaltungsbenutzeroberfläche.

Die unterstützten Ressourcentypen finden Sie unter Ressourcendateien.

Ressourcen können in einem API-Proxy, in einer Umgebung oder in einer Organisation gespeichert werden. In jedem Fall wird in einer Richtlinie mit dem Namen auf eine Ressource verwiesen. API-Dienste auflösen den Namen, indem sie vom API-Proxy in die Umgebung oder Organisationsebene wechseln.

Eine auf Organisationsebene gespeicherte Ressource kann über Richtlinien in jeder Umgebung referenziert werden. Eine auf der Umgebungsebene gespeicherte Ressource kann von den Richtlinien in dieser Umgebung referenziert werden. Eine auf API-Proxyebene gespeicherte Ressource kann nur von Richtlinien in diesem API-Proxy referenziert werden.