Referenz für Bedingungen

Diese Seite gilt für Apigee und Apigee Hybrid.

Apigee Edge-Dokumentation aufrufen

Mit Bedingungen können sich API-Proxys zur Laufzeit dynamisch verhalten. Bedingungen definieren Vorgänge für Variablen, die von der Apigee-Verarbeitungspipeline ausgewertet werden. Bedingte Anweisungen sind boolesch und werden immer als true oder false ausgewertet.

Übersicht über die Conditions

In diesem Abschnitt wird beschrieben, wie und wo bedingte Aussagen mit Apigee verwendet werden können. Außerdem wird in folgenden Abschnitten die Syntax beschrieben:

• Operatoren
• Operanden
• Literale

Struktur bedingter Aussagen

Die grundlegende Struktur einer bedingten Aussage ist:

<Condition>variable.name operator "value"</Condition>

Beispiel:

<Condition>request.verb = "GET"</Condition>

Sie können Bedingungen mit AND kombinieren, um mehrere gleichzeitig zu erzwingen. Beispielsweise werden die folgenden Bedingungen nur als true ausgewertet, wenn der URI der Anfrage übereinstimmt mit /statuses und Das HTTP-Verb der Anfrage ist GET:

<Condition>(proxy.pathsuffix MatchesPath "/statuses") and (request.verb = "GET")</Condition>

Wann können bedingte Anweisungen verwendet werden?

Sie können Bedingungen verwenden, um Verhalten in folgenden Fällen zu steuern:

• Richtlinienausführung
• Ablaufausführung
• Auswahl der Zielendpunkt-Route

Richtlinienausführung

Mit bedingten Aussagen können Sie die Durchsetzung von Richtlinien steuern. Ein häufiger Anwendungsfall ist die bedingte Transformation von Antwortnachrichten basierend auf HTTP-Header oder Nachrichteninhalt.

Im folgenden Beispiel wird XML basierend auf dem Header Accept bedingt in JSON umgewandelt:

<Step>
  <Condition>request.header.accept = "application/json"</Condition>
  <Name>XMLToJSON</Name>
</Step>

Ablaufausführung

Mit bedingten Anweisungen können Sie die Ausführung benannter Abläufe in ProxyEndpoints und TargetEndpoints steuern. Beachten Sie, dass nur benannte Abläufe bedingt ausgeführt werden können. Preflows und Postflows (jeweils Anfrage und Antwort) für ProxyEndpoints und TargetEndpoints werden für jede Transaktion ausgeführt und bieten daher bedingungslose failsafe-Funktionen.

Beispiele sind ein bedingter Anfrageablauf basierend auf dem HTTP-Verb der Anfragenachricht und ein bedingter Antwortablauf auf Basis eines (potenziellen) HTTP-Statuscodes, der einen Fehler darstellt:

<Flow name="GetRequests">
  <Condition>request.verb = "GET"</Condition>
  <Request>
    <Step>
      <Condition>request.path MatchesPath "/statuses/**"</Condition>
      <Name>StatusesRequestPolicy</Name>
    </Step>
  </Request>
  <Response>
    <Step>
      <Condition>(response.status.code = 503) or (response.status.code = 400)</Condition>
      <Name>MaintenancePolicy</Name>
    </Step>
  </Response>
</Flow>

Auswahl der Zielendpunkt-Route

Mit bedingten Anweisungen können Sie den Zielendpunkt steuern, der durch die Proxyendpunktkonfiguration aufgerufen wird. Eine Routingregel leitet eine Anfrage an einen bestimmten Zielendpunkt weiter. Wenn mehr als ein Zielendpunkt verfügbar ist, wird die Bedingung der Routingregel ausgewertet. Wenn der Wert „true“ ist, wird die Anfrage an den benannten Zielendpunkt weitergeleitet.

So können Sie Nachrichten beispielsweise bedingt durch Content-Type an einen bestimmten Zielpunkt weiterleiten:

<RouteRule name="default">
 <!--this routing executes if the header indicates that this is an XML call. If true, the call is routed to the endpoint XMLTargetEndpoint-->
  <Condition>request.header.Content-Type = "text/xml"</Condition>
  <TargetEndpoint>XmlTargetEndpoint</TargetEndpoint>
</RouteRule>

Weitere Informationen finden Sie unter Ablaufvariablen und Bedingungen.

Pfadausdrücke

Pfadausdrücke werden für übereinstimmende URI-Pfade verwendet, wobei * ein einzelnes Pfadelement und ** mehrere URI-Ebenen darstellt.

Beispiel:

% wird als Escape-Zeichen behandelt. Das Muster %{user%} stimmt mit {user} überein, aber nicht mit user.

Variablen

Sie können in bedingten Aussagen sowohl integrierte Ablaufvariablen als auch benutzerdefinierte Variablen verwenden. Weitere Informationen

• Referenz für Ablaufvariablen: Eine vollständige Liste der integrierten Variablen
• ExtractVariables-Richtlinie: Anleitung zum Bestimmen von benutzerdefinierten Variablen

Operatoren

Beachten Sie bei der Verwendung von Operatoren folgende Einschränkungen:

• Operatoren können nicht als Variablennamen verwendet werden.
• Vor und nach einem Operator ist ein Leerzeichen erforderlich.
• Um einen Operator in eine Variable aufzunehmen, muss ein Variablenname in einfache Anführungszeichen gesetzt werden. z. B. 'request.header.help!me'
• Arithmetische Operatoren (+ * - / %) werden nicht unterstützt.
• Für Operatoren gilt die Java-Priorität.
• Apigee stützt sich auf reguläre Ausdrücke, wie in java.util.regex implementiert.

In der folgenden Tabelle sind die unterstützten Operatoren aufgeführt. Sie können das Symbol oder das Wort in Ihren Ausdrücken verwenden:

Operanden

Apigee passt Operanden an einen gemeinsamen Datentyp an, bevor sie verglichen werden. Beispiel: Lautet der Statuscode der Antwort 404, so sind der Ausdruck response.status.code = "400" und der response.status.code = 400 äquivalent.

Bei numerischen Operanden wird der Datentyp als Ganzzahl interpretiert, sofern der Wert nicht wie hier beschrieben terminiert wird:

• f oder F (float, z. B. 3.142f, 91.1F)
• d oder D (double, z. B. 3.142d, 100.123D)
• l oder L (long, z. B. 12321421312L)

In diesen Fällen führt das System Anpassungen in der folgenden Tabelle durch, wobei sich RHS auf die rechte Seite der Gleichung und LHS auf die linke Seite bezieht:

Null-Operanden

Die folgende Tabelle zeigt, ob Bedingungen als true oder false ausgewertet werden, wenn die Werte auf der linken (LHS) und/oder rechten (RHS) Seite des angezeigten Operanden Null sind:

Literale

Zusätzlich zu String- und numerischen Literalen können Sie folgende Literale in bedingten Aussagen verwenden:

• null
• true
• false

Beispiel:

• request.header.host is null
• flow.cachehit is true

Beispiele

<RouteRule name="default">
     <Condition>request.header.content-type = "text/xml"</Condition>
     <TargetEndpoint>XmlTargetEndpoint</TargetEndpoint>
</RouteRule>

<Step>
    <Condition>response.status.code = 503</Condition>
    <Name>MaintenancePolicy</Name>
</Step>

<Flow name="GetRequests">
    <Condition>response.verb="GET"</Condition>
    <Request>
        <Step>
            <Condition>request.path ~ "/statuses/**"</Condition>
            <Name>StatusesRequestPolicy</Name>
        </Step>
    </Request>
    <Response>
        <Step>
            <Condition>(response.status.code = 503) or (response.status.code = 400)</Condition>
            <Name>MaintenancePolicy</Name>
        </Step>
    </Response>
</Flow>