Informacje o warunkach

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

Warunki umożliwiają dynamiczne działanie serwerów proxy interfejsu API w czasie wykonywania. Warunki określają operacje na zmiennych, które są oceniane przez potok przetwarzania Apigee Edge. Instrukcje warunkowe są logiczne i zawsze zwracają wartość true lub false.

Omówienie warunków

W tej sekcji opisujemy, jak i gdzie używać instrukcji warunkowych w Edge. W sekcjach poniżej znajdziesz opis składni:

• Operatory
• Operandy
• Literały

Struktura instrukcji warunkowych

Podstawowa struktura instrukcji warunkowej jest następująca:

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

Na przykład:

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

Możesz połączyć warunki za pomocą operatora AND, aby wymusić więcej niż 1 warunek naraz. Na przykład te warunki przyjmują wartość true tylko wtedy, gdy identyfikator URI żądania pasuje do /statuses i czasownik HTTP żądania to GET:

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

Gdzie można używać instrukcji warunkowych

Warunków możesz używać do kontrolowania działania w tych obszarach:

• Egzekwowanie zasad
• Wykonanie przepływu
• Wybór trasy docelowego punktu końcowego

Wykonywanie zasad

Za pomocą instrukcji warunkowych możesz kontrolować egzekwowanie zasad. Typowym przypadkiem użycia jest warunkowe przekształcanie wiadomości z odpowiedzią na podstawie nagłówka HTTP lub treści wiadomości.

Poniższy przykład warunkowo przekształca XML na JSON na podstawie nagłówka Accept:

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

Wykonanie przepływu

Za pomocą instrukcji warunkowych możesz kontrolować wykonywanie nazwanych przepływów w elementach ProxyEndpoint i TargetEndpoint. Pamiętaj, że warunkowo można wykonywać tylko przepływy „nazwane”. Preflows i postflows (zarówno żądania, jak i odpowiedzi) w przypadku ProxyEndpoints i TargetEndpoints są wykonywane w przypadku każdej transakcji, a tym samym zapewniają bezwarunkowe możliwości „awaryjne”.

Na przykład aby wykonać przepływ żądania warunkowego na podstawie czasownika HTTP w wiadomości żądania i przepływ odpowiedzi warunkowej na podstawie (potencjalnego) kodu stanu HTTP reprezentującego błąd:

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

Wybór trasy docelowego punktu końcowego

Za pomocą instrukcji warunkowych możesz kontrolować docelowy punkt końcowy wywoływany przez konfigurację punktu końcowego proxy. Reguła trasy przekazuje żądanie do określonego docelowego punktu końcowego. Gdy dostępnych jest więcej niż 1 docelowy punkt końcowy, reguła trasy jest oceniana pod kątem warunku, a jeśli warunek jest spełniony, żądanie jest przekazywane do nazwanego docelowego punktu końcowego.

Aby na przykład warunkowo kierować wiadomości do wyznaczonych docelowych punktów końcowych na podstawie Content-Type:

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

Więcej informacji znajdziesz w sekcji Zmienne przepływu i warunki.

Wyrażenia ścieżki

Wyrażenia ścieżki służą do dopasowywania ścieżek URI. Symbol „*” oznacza pojedynczy element ścieżki, a „**” – wiele poziomów URI.

Na przykład:

Znak % jest traktowany jako znak modyfikacji. Wzorzec %{user%} pasuje do adresu {user}, ale nie do adresu user.

Zmienne

W instrukcjach warunkowych możesz używać zarówno wbudowanych zmiennych przepływu, jak i zmiennych niestandardowych. Aby dowiedzieć się więcej, zobacz:

• Dokumentacja zmiennych przepływu: pełna lista wbudowanych zmiennych
• Zasady ExtractVariables: instrukcje dotyczące ustawiania zmiennych niestandardowych

Operatory

Podczas korzystania z operatorów pamiętaj o tych ograniczeniach:

• Operatorów nie można używać jako nazw zmiennych.
• Przed operatorem i po nim musi znajdować się spacja.
• Aby uwzględnić operatora w zmiennej, nazwę zmiennej należy ująć w apostrofy. Na przykład: 'request.header.help!me'.
• Operatory arytmetyczne (+ * - / %) nie są obsługiwane.
• W przypadku operatorów obowiązuje kolejność działań w języku Java.
• Apigee Edge korzysta z wyrażeń regularnych zaimplementowanych w java.util.regex.

W tabeli poniżej znajdziesz listę obsługiwanych operatorów. W wyrażeniach możesz używać symbolu lub słowa:

Operandy

Apigee Edge dostosowuje operandy do wspólnego typu danych przed ich porównaniem. Jeśli na przykład kod stanu odpowiedzi to 404, wyrażenia response.status.code = "400" i response.status.code = 400 są równoważne.

W przypadku operandów liczbowych typ danych jest interpretowany jako liczba całkowita, chyba że wartość jest zakończona w następujący sposób:

• „f” lub „F” (liczba zmiennoprzecinkowa, np. 3.142f, 91.1F)
• „d” lub „D” (liczba podwójnej precyzji, np. 3,142d, 100,123D)
• „l” lub „L” (liczba długa, np. 12321421312L)

W takich przypadkach system wprowadza zmiany przedstawione w tabeli poniżej (gdzie RHS oznacza prawą stronę równania, a LHS – lewą):

Operandy o wartości null

W poniższej tabeli pokazano, czy warunki przyjmują wartość true czy false, gdy wartości po lewej stronie (LHS) lub po prawej stronie (RHS) operandu są wartościami null:

Literały

Oprócz literałów tekstowych i numerycznych w instrukcjach warunkowych możesz używać tych literałów:

• null
• true
• false

Na przykład:

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

Przykłady

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