Referenz für Bedingungen

Sie sehen die Dokumentation zu Apigee Edge.
Zur Apigee X-Dokumentation weitere Informationen

Mit Bedingungen können sich API-Proxys zur Laufzeit dynamisch verhalten. Bedingungen definieren Vorgänge für Variablen, die von der Apigee Edge-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 Anweisungen mit Edge verwendet werden. 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 UND kombinieren, um mehrere Bedingungen gleichzeitig zu erzwingen. Die folgenden Bedingungen werden beispielsweise nur als true ausgewertet, wenn der URI der Anfrage mit /statuses übereinstimmt und das HTTP-Verb der Anfrage GET ist:

<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 Aussagen 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 (Anfrage/Antwort) auf ProxyEndpoints und TargetEndpoints werden für jede Transaktion ausgeführt und bieten daher unbedingte "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 den Abgleich von URI-Pfaden verwendet, wobei „*“ für ein einzelnes Pfadelement und „**“ für mehrere URI-Ebenen verwendet wird.

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. Beispiel: 'request.header.help!me'.
  • Arithmetische Operatoren (+ * - / %) werden nicht unterstützt.
  • Für Operatoren gilt die Java-Priorität.
  • Apigee Edge 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 Wortmarke 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 > beim Definieren der Bedingung in der Edge-Benutzeroberfläche verwenden, wird es in &gt; konvertiert.
>= oder &gt;= GreaterThanOrEquals Größer als oder gleich. Wenn Sie >= beim Definieren der Bedingung in der Edge-Benutzeroberfläche verwenden, wird es in &gt;= konvertiert.
&lt; LesserThan Kleiner als. Die Edge-Benutzeroberfläche unterstützt nicht das Literal <.
&lt;= LesserThanOrEquals Kleiner als oder gleich. Die Edge-Benutzeroberfläche unterstützt nicht das Literal <=.
&& 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 in bedingten Anweisungen.
~ Matches, Like Gleicht ein glob-ähnliches Muster unter Verwendung des Platzhalterzeichens „*“ ab. Bei dem Abgleich wird die Groß-/Kleinschreibung beachtet. Beispiele finden Sie unter Musterabgleich mit Bedingungen.
~/ MatchesPath, LikePath Entspricht einem Pfadausdruck. Bei dem Abgleich wird die Groß-/Kleinschreibung beachtet. Beispiele finden Sie unter Musterabgleich mit Bedingungen.
=| StartsWith Gleicht die ersten Zeichen eines Strings ab. Bei dem Abgleich wird die Groß-/Kleinschreibung beachtet.

Operanden

Apigee Edge passt Operanden vor dem Vergleich an einen gemeinsamen Datentyp an. 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 Boolean Ganzzahl Long Float Double String Vergleichbar Objekt
Boolean Boolesch Ganzzahl Long Float Double String -
Ganzzahl Ganzzahl Ganzzahl Long Float Double String Vergleichbar -
Lang Lang Lang 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:

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