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:

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

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:

Muster Beispiel für übereinstimmende URI-Pfade
/*/a/ /x/a/ oder /y/a/
/*/a/* /x/a/b oder /y/a/foo
/*/a/** /x/a/b/c/d
/*/a/*/feed/ /x/a/b/feed/ oder /y/a/foo/feed/
/a/**/feed/** /a/b/feed/rss/1234

% 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

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:

Symbol Word Beschreibung
! Not, not Einstelliger Operator (eine einzelne Eingabe möglich)
= Equals, Is Ist gleich (Groß-/Kleinschreibung wird beachtet)
!= NotEquals, IsNot Ist ungleich (Groß-/Kleinschreibung wird beachtet)
:= EqualsCaseInsensitive Ist gleich (aber die Groß-/Kleinschreibung wird nicht berücksichtigt)
> oder &gt; GreaterThan Größer als. Wenn Sie bei der Definition der Bedingung in der Apigee-Benutzeroberfläche ">" verwenden, wird das Zeichen in "& gt;" konvertiert.
>= oder &gt;= GreaterThanOrEquals Größer als oder gleich. Wenn Sie beim Definieren der Bedingung in der Apigee-UI ">=" verwenden, wird das Zeichen in "&gt;=" konvertiert.
&lt; LesserThan Kleiner als. Die Apigee-UI unterstützt das Literal "<" nicht.
&lt;= LesserThanOrEquals Kleiner als oder gleich. Die Apigee-UI unterstützt kein direktes "<=".
&& And, and Und
|| Or Beim Operator "Or" wird nicht zwischen Groß- und Kleinschreibung unterschieden. Zum Beispiel sind OR, Or und or alle gültig.
() Gruppiert einen Ausdruck. ( öffnet den Ausdruck und ) schließt ihn.
~~ JavaRegex

Entspricht einem javax.util.regex-kompatiblen regulären Ausdruck. Bei dem Abgleich wird die Groß-/Kleinschreibung beachtet. Beispiele finden Sie unter Musterabgleich.
~ Matches, Like Übereinstimmung mit einem Glob-Stil-muster mithilfe des Platzhalterzeichen *. Bei dem Abgleich wird die Groß-/Kleinschreibung beachtet. Beispiele finden Sie unter Musterabgleich.
~/ MatchesPath, LikePath Entspricht einem Pfadausdruck. Bei dem Abgleich wird die Groß-/Kleinschreibung beachtet. Beispiele finden Sie unter Musterabgleich.
=| StartsWith Gleicht die ersten Zeichen eines Strings ab. Bei dem Abgleich wird die Groß-/Kleinschreibung beachtet.

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:

RHS LHS Boolesch Ganzzahl Long Float Double String Vergleichbar Objekt
Boolesch Boolesch Ganzzahl Long Float Double String -
Ganzzahl Ganzzahl Ganzzahl Long Float Double String Vergleichbar -
Long Long Long Long Float Double String Vergleichbar -
Float Float Float Float Float Double String Vergleichbar -
Double Double Double Double Double Double String Vergleichbar -
String String String String String String String Vergleichbar -
Vergleichbar Vergleichbar Vergleichbar Vergleichbar Vergleichbar Vergleichbar Vergleichbar Vergleichbar -
Objekt - - - - - - - -

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:

Operator LHS-Null RHS-Null LHS- und RHS-Null
=, ==, := false false true
=| false false false
!= true true false
> oder &gt; true false false
>= oder &gt;= false true true
&lt; true false false
&lt;= true false true
~ false – false
~~ false – false
!~ true false false
~/ false – false

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>