Ablaufkonfigurationsreferenz

Diese Seite gilt für Apigee und Apigee Hybrid.

Apigee Edge-Dokumentation aufrufen

Dieser Abschnitt enthält Referenzinformationen zu den XML-Elementen, die Sie zum Definieren Ihrer API-Proxy-Ablaufs verwenden.

Hierarchie & Syntax

Die folgenden Beispiele zeigen die Elementhierarchie und die Syntax der Ablaufkonfigurationselemente:

Elementhierarchie

Das folgende Beispiel zeigt die Hierarchie der Ablaufkonfigurationselemente innerhalb des <ProxyEndpoint> und <TargetEndpoint> Elemente:

<ProxyEndpoint | TargetEndpoint>
    <PreFlow>
          <Request>
                <Step>
                    <Condition>
                    <Name>
          <Response>
                <Step>
                    <Condition>
                    <Name>
          <Description>
    <Flows>
          <Flow>
                <Description>
                <Condition>
                <Request>
                      <Step>
                          
                <Response>
                      <Step>
                          
          <Description>
    <PostFlow>
          <Request>
                <Step>
                    
          <Response>
                <Step>
                    
          <Description>
    <PostClientFlow> (<ProxyEndpoint> only)
          <Response>
                
          <Description>

      // Additional configuration elements

</ProxyEndpoint | TargetEndpoint>

Syntax

Das folgende Beispiel zeigt die Syntax für die Ablaufkonfigurationselemente. Jedes dieser Elemente wird in den folgenden Abschnitten ausführlich beschrieben:

<!-- ProxyEndpoint flow configuration file -->
<ProxyEndpoint ... >
  ...
  <PreFlow name="flow_name">
    <Description>flow_description</Description>
    <Request>
      <Step>
        <Condition>property operator "value"</Condition>
        <Name>policy_name</Name>
      </Step>
      ...
    </Request>
    <Response>
      <Step>
        <Condition>property operator "value"</Condition>
        <Name>policy_name</Name>
      </Step>
      ...
    </Response>
  </PreFlow>
  <Flows name="flow_name">
    <Flow name="conditional_flow_name">
      <Description>flow_description</Description>
      <Condition>property operator "value"</Condition>
      <Request>
        <Step>
          <Condition>property operator "value"</Condition>
          <Name>policy_name</Name>
        </Step>
        ...
      </Request>
      <Response>
        <Step>
          <Condition>property operator "value"</Condition>
          <Name>policy_name</Name>
        </Step>
        ...
      </Response>
    </Flow>
  </Flows>
  <PostFlow name="flow_name">
    <Description>flow_description</Description>
    <Request>
      <Step>
        <Condition>property operator "value"</Condition>
        <Name>policy_name</Name>
      </Step>
      ...
    </Request>
    <Response>
      <Step>
        <Condition>property operator "value"</Condition>
        <Name>policy_name</Name>
      </Step>
      ...
    </Response>
  </PostFlow>
  <PostClientFlow name="flow_name">
    <Description>flow_description</Description>
    <Response>
      <Step>
        <Condition>property operator "value"</Condition>
        <Name>policy_name</Name>
      </Step>
      ...
    </Response>
  </PostClientFlow>
  ...
</ProxyEndpoint>

<!-- TargetEndpoint flow configuration file -->
<TargetEndpoint ... >
  ...
  <PreFlow name="flow_name">
    <Description>flow_description</Description>
    <Request>
      <Step>
        <Condition>property operator "value"</Condition>
        <Name>policy_name</Name>
      </Step>
      ...
    </Request>
    <Response>
      <Step>
        <Condition>property operator "value"</Condition>
        <Name>policy_name</Name>
      </Step>
      ...
    </Response>
  </PreFlow>
  <Flows name="flow_name">
    <Flow name="conditional_flow_name">
      <Description>flow_description</Description>
      <Condition>property operator "value"</Condition>
      <Request>
        <Step>
          <Condition>property operator "value"</Condition>
          <Name>policy_name</Name>
        </Step>
        ...
      </Request>
      <Response>
        <Step>
          <Condition>property operator "value"</Condition>
          <Name>policy_name</Name>
        </Step>
        ...
      </Response>
    </Flow>
    ...
  </Flows>
  <PostFlow name="flow_name">
    <Description>flow_description</Description>
    <Request>
      <Step>
        <Condition>property operator "value"</Condition>
        <Name>policy_name</Name>
      </Step>
      ...
    </Request>
    <Response>
      <Step>
        <Condition>property operator "value"</Condition>
        <Name>policy_name</Name>
      </Step>
      ...
    </Response>
  </PostFlow>
  ...
</TargetEndpoint>

Mit diesen Elementen definieren Sie die Ausführung von PreFlow, Conditional Flow, PostFlow und PostClientFlow.

<Condition>

Definiert eine Anweisung, die zur Laufzeit verarbeitet wird. Wenn die Anweisung den Wert „true“ ergibt, wird der Schritt oder Ablauf ausgeführt, welcher der Bedingung zugeordnet ist. Wenn die Anweisung den Wert „false“ ergibt, wird der Schritt oder Ablauf ignoriert.

Typ String
Übergeordnete Elemente <Flow>
<Step>
Untergeordnete Elemente

Sie können eine Bedingung auf einen bestimmten Schritt oder einen gesamten Ablauf anwenden, je nachdem, ob Sie das Element in <Flow> oder <Step> einfügen.

// Condition can apply to just one step:        // Or to the flow:
<Flows>                                         <Flows>
  <Flow>                                          <Flow>
    <Step>                                          <Condition>
      <Condition>                                   <Step>
      <Name>                                          <Name>
      ...                                             ...
    ...                                             ...
  ...                                             ...
</Flows>                                        </Flows>

Wenn eine Bedingung in einem <Step> „true“ ergibt, führt Apigee diesen Schritt aus. Wenn die Bedingung „false“ ergibt, überspringt Apigee den Schritt.

Wenn eine Bedingung in einem <Flow> „true“ ergibt, verarbeitet Apigee alle Schritte im Ablauf. Wenn die Bedingung „false“ ergibt, überspringt Apigee den gesamten Ablauf.

Syntax

Das Element <Condition> verwendet die folgende Syntax:

<Condition>property operator "value"</Condition>

Wobei:

property
Das Attribut der Ablaufvariable, das Sie in Ihrer Bedingung verwenden möchten. Die Ablaufvariable request hat beispielsweise Attribute mit den Namen path und content. Wenn Sie diese in einer Bedingung verwenden möchten, geben Sie den flow_variable[dot]property_name an:
request.path
request.content

Eine vollständige Liste der Ablaufvariablen und ihrer Eigenschaften finden Sie unter Referenz für Ablaufvariablen.

operator
Ein Konstrukt, das definiert, wie Ihre Bedingung bewertet wird. Häufige Operatoren sind:
>     greater than           <=    less than or equal to
<     less than              >=    greater than or equal to
=     equals                 &&    and
!=    not equals             ||    or

~~    JavaRegex
~     Matches
/~    MatchesPath

Eine vollständige Liste finden Sie unter Operatoren in der Bedingungsreferenz.

"value"
Der Wert, mit dem das Attribut der Ablaufvariable ausgewertet wird. Dies ist im Allgemeinen ein einfacher Typ, z. B. eine Ganzzahl oder ein String. Beispiel: 200oder /cat Der Wert kann Platzhalterzeichen wie Sternchen und andere Zeichen für den Musterabgleich enthalten, wie unter Musterabgleich mit Bedingungen beschrieben.

Beispiel 1

Im folgenden Beispiel wird geprüft, ob das Attribut verb der Ablaufvariable request GET ist:

<!-- api-platform/reference/examples/flow-segments/condition-1.xml -->
<ProxyEndpoint name="default">
  <PreFlow name="my-preFlows">
    <Description>My first PreFlow</Description>
    <Request>
      <Step>
        <Condition>request.verb = "GET"</Condition>
        <Name>Log-Request-OK</Name>
      </Step>
    </Request>
  </PreFlow>
  ...
</ProxyEndpoint>

Wenn die Anfrage ein GET ist, wird in diesem Beispiel die Richtlinie Log-Request-OK ausgeführt.

Beispiel 2

Im folgenden Beispiel wird der Antwortcode überprüft:

<!-- api-platform/reference/examples/flow-segments/condition-2.xml -->
<ProxyEndpoint name="default">
  <PreFlow name="my-preFlows">
    <Description>My first PreFlow</Description>
    <Response>
      <Step>
        <Condition>response.status.code LesserThanOrEquals 300</Condition>
        <Name>Log-Response-OK</Name>
      </Step>
      <Step>
        <Condition>response.status.code GreaterThan 300</Condition>
        <Name>Log-Response-NOT-OK</Name>
      </Step>
    </Response>
  </PreFlow>
  ...
</ProxyEndpoint>

Je nach Wert des Codes wird eine andere Richtlinie ausgeführt.

Attribute

Das <Condition>-Element hat keine Attribute.

Untergeordnete Elemente

Das <Condition>-Element hat keine untergeordneten Elemente.

<Description>

Beschreibt den Ablauf durch Begriffe in einem für Menschen lesbaren Format. Verwenden Sie dieses Element, damit Sie sich selbst oder anderen Entwicklern Informationen zum Ablauf bereitstellen können. Die Beschreibung ist nicht extern sichtbar.

Typ String
Übergeordnete Elemente <Flow>
<PreFlow>
<PostFlow>
Untergeordnete Elemente

Syntax

Das <Description>-Element verwendet die folgende Syntax:

<Description>flow_description</Description>

Beispiel

Das folgende Beispiel zeigt ein <Description>-Element, das den Zweck eines Ablaufs angibt:

<!-- api-platform/reference/examples/flow-segments/description-1.xml -->
<ProxyEndpoint name="default">
  <Flows name="my-conditional-flows">
    <Flow name="reports">
      <Request>
        <Description>Based on the path suffix, determine which flow to use</Description>
        <Step>
          <Condition>proxy.pathsuffix MatchesPath "/reports"</Condition>
          <Name>XML-to-JSON-1</Name>
        </Step>
        <Step>
          <Condition>proxy.pathsuffix MatchesPath "/forecasts"</Condition>
          <Name>XML-to-JSON-1</Name>
        </Step>
      </Request>
    </Flow>
  </Flows>
  ...
</ProxyEndpoint>

Attribute

Das <Description>-Element hat keine Attribute.

Untergeordnete Elemente

Das <Description>-Element hat keine untergeordneten Elemente.

<Flow>

Definiert einen benutzerdefinierten Satz von Schritten, die Apigee ausführt.

Typ Objekt des Komplexes
Übergeordnete Elemente <Flows>
Untergeordnete Elemente <Condition>
<Description>
<Request>
<Response>

Sie können optional ein <Condition> für einen <Flow> angeben. In diesem Fall führt Edge die Schritte im Ablauf nur dann aus, wenn die Bedingung als „true“ ausgewertet wird. Andernfalls überspringt Apigee den gesamten Ablauf.

Ein <Flows>-Element kann mehrere <Flow>-Elemente mit jeweils eigener Bedingung und Schritten enthalten. Wenn mehrere <Flow>-Elemente vorhanden sind, führt Apigee nur das erste Element aus, bei dem keine Bedingung vorliegt oder die Bedingung „true“ ergibt.

Sie können einen Standardablauf definieren, der immer ausgeführt wird, sofern keiner der anderen bedingten Abläufe ausgeführt wird. Je nachdem, wie Ihr API-Proxy konfiguriert ist, kann dies ein nützliches Werkzeug zum Schutz vor böswilligen Angriffen sein.

Syntax

Das <Flow>-Element verwendet die folgende Syntax:

<Flow name="conditional_flow_name">
  <Description>flow_description</Description>
  <Condition>property operator "value"</Condition>
  <Request>
    <Step>
      <Condition>property operator "value"</Condition>
      <Name>policy_name</Name>
    </Step>
    ...
  </Request>
  <Response>
    <Step>
      <Condition>property operator "value"</Condition>
      <Name>policy_name</Name>
    </Step>
    ...
  </Response>
</Flow>

Alle untergeordneten Elemente von <Flow> sind optional.

Beispiel 1

Das folgende Beispiel zeigt einen einfachen <Flow>, der immer die Richtlinie "Log-Message-OK" ausführt:

<!-- api-platform/reference/examples/flow-segments/flow-1.xml -->
<ProxyEndpoint name="default">
  <Flows name="my-flow">
    <Flow>
      <Request>
        <Step>
          <Name>Log-Message-OK</Name>
        </Step>
      </Request>
    </Flow>
  </Flows>
  ...
</ProxyEndpoint>

Beispiel 2

Das folgende Beispiel zeigt ein <Flow> mit mehreren Schritten, von dem jeder eine eigene Bedingung hat:

<!-- api-platform/reference/examples/flow-segments/flow-2.xml -->
<ProxyEndpoint name="default">
  <Flows name="my-conditional-flows">
    <Flow name="reports">
      <Request>
        <Description>Based on the path suffix, determine which flow to use</Description>
        <Step>
          <Condition>proxy.pathsuffix MatchesPath "/reports"</Condition>
          <Name>XML-to-JSON-1</Name>
        </Step>
        <Step>
          <Condition>proxy.pathsuffix MatchesPath "/forecasts"</Condition>
          <Name>Verify-Auth-1</Name>
        </Step>
      </Request>
    </Flow>
  </Flows>
  ...
</ProxyEndpoint>

Beispiel 3

Das folgende Beispiel zeigt mehrere Abläufe in einem bedingten Ablauf:

<!-- api-platform/reference/examples/flow-segments/flows-2.xml -->
<ProxyEndpoint name="default">
  <Flows>
    <Flow name="my-flow-1">
      <Response>
        <Step>
          <Condition>response.status.code = 200</Condition>
          <Name>Assign-Message-1</Name>
        </Step>
      </Response>
    </Flow>
    <Flow name="my-flow-2">
      <Response>
        <Step>
          <Condition>response.status.code >= 400</Condition>
          <Name>Assign-Message-2</Name>
        </Step>
      </Response>
    </Flow>
    <Flow name="my-flow-3">
      <Response>
        <Step>
          <Condition>response.status.code >= 300</Condition>
          <Name>Assign-Message-3</Name>
        </Step>
      </Response>
    </Flow>
  </Flows>
  ...
</ProxyEndpoint>

Apigee führt nur einen Ablauf in einem Segment aus; es wird der erste Ablauf ausgeführt, der keine Bedingung hat oder dessen Bedingung „true“ ergibt.

Attribute

In der folgenden Tabelle werden die Attribute des <Flow> -Elements beschrieben:

Attribut Typ Beschreibung
name String (Erforderlich) Eine eindeutige ID für den Ablauf. Beispiel: My-Conditional-Flow-1. Der Name darf keine Leerzeichen oder andere Sonderzeichen enthalten.

Untergeordnete Elemente

In der folgenden Tabelle werden die untergeordneten Elemente von <Flow> beschrieben:

Untergeordnetes Element Typ Beschreibung
<Condition> String Definiert eine bedingte Anweisung, die zur Laufzeit verarbeitet wird. Wenn die Anweisung den Wert „true“ ergibt, werden der Ablauf und alle seine Schritte ausgeführt. Wenn die Anweisung den Wert „false“ ergibt, werden der Ablauf und alle seine Schritte ignoriert.
<Description> String Bietet eine kurze Beschreibung des Ablaufs. Diese Beschreibung ist nicht extern sichtbar.
<Request> Objekt des Komplexes Gibt die Schritte und Bedingungen für das Anfragesegment an.
<Response> Komplexes Objekt Gibt die Schritte und Bedingungen für das Antwortsegment an.

<Flows>

Enthält null oder mehr <Flow>-Elemente.

Typ Objekt des Komplexes
Übergeordnete Elemente <ProxyEndpoint>
<TargetEndpoint>
Untergeordnete Elemente <Flow>

Wenn mehrere <Flow> -Elemente in <Flows> enthalten sind, wird nur ein <Flow> ausgeführt. Dies ist der erste Ablauf, der entweder kein <Condition> enthält oder dessen Bedingung in wahr aufgelöst wird.

Sie können einen Standardablauf definieren, der immer ausgeführt wird, sofern keiner der anderen Abläufe ausgeführt wird. Je nachdem, wie Ihr API-Proxy konfiguriert ist, kann dies ein nützliches Werkzeug zum Schutz vor böswilligen Angriffen sein.

Syntax

Das <Flows>-Element verwendet die folgende Syntax:

<Flows name="flow_name">
  <Flow name="conditional_flow_name">
    <Description>flow_description</Description>
    <Condition>property operator "value"</Condition>
    <Request>
      <Step>
        <Condition>property operator "value"</Condition>
        <Name>policy_name</Name>
      </Step>
      ...
    </Request>
    <Response>
      <Step>
        <Condition>property operator "value"</Condition>
        <Name>policy_name</Name>
      </Step>
      ...
    </Response>
  </Flow>
</Flows>

Alle untergeordneten Elemente von <Flows> sind optional.

Beispiel 1

Das folgende Beispiel zeigt ein einfaches <Flows> -Element mit einem einzelnen <Flow>:

<!-- api-platform/reference/examples/flow-segments/flows-1.xml -->
<ProxyEndpoint name="default">
  <Flows name="my-conditional-flows">
    <Flow name="reports">
      <Request>
        <Description>Based on the path suffix, determine which flow to use</Description>
        <Step>
          <Condition>proxy.pathsuffix MatchesPath "/reports"</Condition>
          <Name>XML-to-JSON-1</Name>
        </Step>
        <Step>
          <Condition>proxy.pathsuffix MatchesPath "/forecasts"</Condition>
          <Name>Verify-Auth-1</Name>
        </Step>
      </Request>
    </Flow>
  </Flows>
  ...
</ProxyEndpoint>

Apigee führt eine dieser Richtlinien auf der Grundlage des Pfadsuffixes aus, das über die Ablaufvariable proxy erfasst wird. Wenn das Pfadsuffix mit keiner der Bedingungen übereinstimmt, führt Apigee diesen Ablauf nicht aus.

Beispiel 2

Das folgende Beispiel zeigt mehrere <Flow>-Elemente innerhalb von <Flows> mit jeweils einer eigenen <Condition>:

<!-- api-platform/reference/examples/flow-segments/flows-2.xml -->
<ProxyEndpoint name="default">
  <Flows>
    <Flow name="my-flow-1">
      <Response>
        <Step>
          <Condition>response.status.code = 200</Condition>
          <Name>Assign-Message-1</Name>
        </Step>
      </Response>
    </Flow>
    <Flow name="my-flow-2">
      <Response>
        <Step>
          <Condition>response.status.code >= 400</Condition>
          <Name>Assign-Message-2</Name>
        </Step>
      </Response>
    </Flow>
    <Flow name="my-flow-3">
      <Response>
        <Step>
          <Condition>response.status.code >= 300</Condition>
          <Name>Assign-Message-3</Name>
        </Step>
      </Response>
    </Flow>
  </Flows>
  ...
</ProxyEndpoint>

Apigee führt nur den ersten Ablauf in einem Segment aus, dessen Bedingung „true“ ergibt. Danach überspringt Apigee die verbleibenden Abläufe im Segment.

Beispiel 3

Das folgende Beispiel zeigt einen „Standard-<Flow>“:

<!-- api-platform/reference/examples/flow-segments/flows-3.xml -->
<ProxyEndpoint name="default">
  <Flows>
    <Flow name="my-conditional-flow-1">
      <Response>
        <Step>
          <Condition>response.status.code = 200</Condition>
          <Name>Assign-Message-1</Name>
        </Step>
      </Response>
    </Flow>
    <Flow name="my-conditional-flow-2">
      <Response>
        <Step>
          <Condition>response.header.someheader = "42"</Condition>
          <Name>Assign-Message-2</Name>
        </Step>
      </Response>
    </Flow>
    <Flow name="my-default-flow">
      <Response>
        <Step>
          <Name>Assign-Message-3</Name>
        </Step>
      </Response>
    </Flow>
  </Flows>
  ...
</ProxyEndpoint>

Apigee führt nur den ersten Ablauf in einem Segment aus, dessen Bedingung „true“ ergibt. Wenn keine bedingten Flüsse ausgeführt werden, wird der dritte Ablauf in diesem Beispiel (ohne Bedingung) ausgeführt.

Ein Standardablauf kann ein nützliches Tool zum Schutz vor böswilligen Angriffen sein.

Attribute

Das <Flows>-Element hat keine Attribute.

Untergeordnete Elemente

Das <Flows>-Element hat die folgenden untergeordneten Elemente:

Untergeordnetes Element Typ Beschreibung
<Flow> Komplexes Objekt Ein Ablauf, der einen möglichen Satz von Schritten innerhalb des bedingten Ablaufs definiert.

<Name>

Gibt die ID der Richtlinie an, die innerhalb von <Flow> ausgeführt werden soll.

Typ String
Übergeordnete Elemente <Step>
Untergeordnete Elemente

Syntax

Das <Name>-Element verwendet die folgende Syntax:

<Name>policy_name</Name>

Beispiel

Das folgende Beispiel zeigt zwei Richtlinien, die Abläufe anhand ihres Namens hinzugefügt werden:

<!-- api-platform/reference/examples/flow-segments/name-1.xml -->
<ProxyEndpoint name="default">
  <Flows name="my-conditional-flows">
    <Flow name="reports">
      <Request>
        <Description>Based on the path suffix, determine which flow to use</Description>
        <Step>
          <Condition>proxy.pathsuffix MatchesPath "/reports"</Condition>
          <Name>XML-to-JSON-1</Name>
        </Step>
        <Step>
          <Condition>proxy.pathsuffix MatchesPath "/forecasts"</Condition>
          <Name>Verify-Auth-1</Name>
        </Step>
      </Request>
    </Flow>
  </Flows>
  ...
</ProxyEndpoint>

Attribute

Das <Name>-Element hat keine Attribute.

Untergeordnete Elemente

Das <Name>-Element hat keine untergeordneten Elemente.

<PostFlow>

Definiert die Schritte, die im PostFlow der Anfrage und Antwort ausgeführt werden sollen.

Typ Objekt des Komplexes
Übergeordnete Elemente <ProxyEndpoint>
<TargetEndpoint>
Untergeordnete Elemente <Description>
<Request>
<Response>

Das <PostFlow>-Element verwendet die folgende Syntax:

Syntax

<PostFlow name="flow_name">
  <Description>flow_description</Description>
  <Request>
    <Step>
      <Condition>property operator "value"</Condition>
      <Name>policy_name</Name>
    </Step>
    ...
  </Request>
  <Response>
    <Step>
      <Condition>property operator "value"</Condition>
      <Name>policy_name</Name>
    </Step>
    ...
  </Response>
</PostFlow>

Beispiel

Das folgende Beispiel zeigt einen PostFlow mit Schritten für die definierte Anfrage und Antwort:

<!-- api-platform/reference/examples/flow-segments/postflow-1.xml -->
<ProxyEndpoint name="default">
  <PostFlow name="my-postflows">
    <Description>My first PostFlow</Description>
    <Request>
      <Step>
        <Condition>request.verb = "GET"</Condition>
        <Name>Log-Request-OK</Name>
      </Step>
    </Request>
    <Response>
      <Step>
        <Name>Set-Response-Headers</Name>
      </Step>
    </Response>
  </PostFlow>
  ...
</ProxyEndpoint>

Attribute

In der folgenden Tabelle werden die Attribute des <PostFlow> -Elements beschrieben:

Attribut Typ Beschreibung
name String Eine eindeutige ID für den Ablauf (innerhalb des Endpunkts eindeutig). Beispiel: My-PostFlow-1. Der Wert darf keine Leerzeichen oder andere Sonderzeichen enthalten.

Untergeordnete Elemente

In der folgenden Tabelle werden die untergeordneten Elemente von <PostFlow> beschrieben:

Untergeordnetes Element Typ Beschreibung
<Description> String Bietet eine kurze Beschreibung des Ablaufs.
<Request> Objekt des Komplexes Definiert die Richtlinien, die während des PostFlow der Anfrage ausgeführt werden sollen.
<Response> Komplexes Objekt Definiert die Richtlinien, die während des PostFlow der Antwort ausgeführt werden sollen.

<PostClientFlow>

Definiert Richtlinien im ProxyEndpoint, die erst ausgeführt werden, nachdem eine Antwort an den Client zurückgegeben wurde. Diese Richtlinien protokollieren normalerweise Nachrichten, die sich auf die Antwort beziehen.

Typ Objekt des Komplexes
Übergeordnete Elemente <ProxyEndpoint>
Untergeordnete Elemente <Description>
<Response>

Syntax

Das <PostClientFlow>-Element verwendet die folgende Syntax:

<PostClientFlow name="flow_name">
  <Description>flow_description</Description>
  <Response>
    <Step>
      <Condition>property operator "value"</Condition>
      <Name>policy_name</Name>
    </Step>
    ...
  </Response>
</PostClientFlow>

Alle untergeordneten Elemente von <PostClientFlow> sind optional.

Beispiel

Das folgende Beispiel zeigt einen einfachen PostClientFlow, der eine einzelne Richtlinie ausführt:

<!-- api-platform/reference/examples/flow-segments/postclientflow-1.xml -->
<ProxyEndpoint name="default">
  <PostClientFlow name="my-postclientflows">
    <Description>My first PostClientFlow. Processed after the response is sent back to the client.</Description>
    <Response>
      <Step>
        <Name>Message-Logging-OK</Name>
      </Step>
    </Response>
  </PostClientFlow>
  ...
</ProxyEndpoint>

Attribute

In der folgenden Tabelle werden die Attribute des <PostClientFlow> -Elements beschrieben:

Attribut Typ Beschreibung
name String Eine eindeutige ID für den Ablauf. Der Name darf keine Leerzeichen oder andere Sonderzeichen enthalten. z. B. My-PostClientFlow-1

Untergeordnete Elemente

In der folgenden Tabelle werden die untergeordneten Elemente von <PostClientFlow> beschrieben:

Untergeordnetes Element Typ Beschreibung
<Description> String Bietet eine kurze Beschreibung des Ablaufs.
<Response> Komplexes Objekt Definiert die Richtlinien, die während des PostFlow der Antwort ausgeführt werden sollen.

<PreFlow>

Definiert die Richtlinien, die im PreFlow der Anfrage und Antwort ausgeführt werden sollen.

Typ Objekt des Komplexes
Übergeordnete Elemente <ProxyEndpoint>
<TargetEndpoint>
Untergeordnete Elemente <Description>
<Request>
<Response>

Syntax

Das <PreFlow>-Element verwendet die folgende Syntax:

<PreFlow name="flow_name">
  <Description>flow_description</Description>
  <Request>
    <Step>
      <Condition>property operator "value"</Condition>
      <Name>policy_name</Name>
    </Step>
    ...
  </Request>
  <Response>
    <Step>
      <Condition>property operator "value"</Condition>
      <Name>policy_name</Name>
    </Step>
    ...
  </Response>
</PreFlow>

Alle untergeordneten Elemente von <PreFlow> sind optional.

Beispiel

Das folgende Beispiel zeigt einen PreFlow mit einer Anfrage und einem definierten Antwortablauf:

<!-- api-platform/reference/examples/flow-segments/preflow-1.xml -->
<ProxyEndpoint name="default">
  <PreFlow name="my-preFlows">
    <Description>My first PreFlow</Description>
    <Request>
      <Step>
        <Condition>request.verb = "GET"</Condition>
        <Name>Log-Request-OK</Name>
      </Step>
    </Request>
    <Response>
      <Step>
        <Condition>response.status.code LesserThanOrEquals 300</Condition>
        <Name>Log-Response-OK</Name>
      </Step>
      <Step>
        <Condition>response.status.code GreaterThan 300</Condition>
        <Name>Log-Response-NOT-OK</Name>
      </Step>
    </Response>
  </PreFlow>
  ...
</ProxyEndpoint>

Attribute

In der folgenden Tabelle werden die Attribute des <PreFlow> -Elements beschrieben:

Attribut Typ Beschreibung
name String Eine eindeutige ID für den Ablauf. Der Name darf keine Leerzeichen oder andere Sonderzeichen enthalten. z. B. My-PreFlow-1

Untergeordnete Elemente

In der folgenden Tabelle werden die untergeordneten Elemente von <PreFlow> beschrieben:

Untergeordnetes Element Typ Beschreibung
<Description> String Bietet eine kurze Beschreibung des Ablaufs.
<Request> Objekt des Komplexes Definiert die Richtlinien, die während des PreFlow der Anfrage ausgeführt werden sollen.
<Response> Komplexes Objekt Definiert die Richtlinien, die während des PreFlow der Antwort ausgeführt werden sollen.

<Request>

Definiert die Richtlinien, die während des Anforderungssegments des Ablaufs ausgeführt werden sollen.

Typ Objekt des Komplexes
Übergeordnete Elemente <Flow>
<PreFlow>
<PostFlow>
Untergeordnete Elemente <Condition>
<Step>

Syntax

Das <Request>-Element verwendet die folgende Syntax:

<Request>
  <Step>
    <Condition>property operator "value"</Condition>
    <Name>policy_name</Name>
  </Step>
  ...
</Request>

Alle untergeordneten Elemente von <Request> sind optional.

Beispiel

Das folgende Beispiel zeigt für die Anfrage definierte Abläufe im PreFlow und PostFlow:

<!-- api-platform/reference/examples/flow-segments/request-1.xml -->
<ProxyEndpoint name="default">
  <PreFlow name="my-preFlows">
    <Description>My first PreFlow</Description>
    <Request>
      <Step>
        <Condition>request.verb = "GET"</Condition>
        <Name>Log-Request-OK</Name>
      </Step>
    </Request>
  </PreFlow>
  <PostFlow name="my-postflows">
    <Description>My first PostFlow</Description>
    <Request>
      <Step>
        <Condition>request.verb = "GET"</Condition>
        <Name>Log-Request-OK</Name>
      </Step>
    </Request>
  </PostFlow>
  ...
</ProxyEndpoint>

Attribute

Das <Request>-Element hat keine Attribute.

Untergeordnete Elemente

In der folgenden Tabelle werden die untergeordneten Elemente von <Request> beschrieben:

Untergeordnetes Element Typ Beschreibung
<Condition> Objekt des Komplexes Legt fest, ob die Schritte im Anfragesegment ausgeführt werden.
<Step> String Gibt eine Richtlinie an, die im Anfragesegment ausgeführt werden soll.

<Response>

Definiert die Richtlinien, die während des Anfragesegments des Ablaufs ausgeführt werden sollen.

Typ Objekt des Komplexes
Übergeordnete Elemente <Flow>
<PreFlow>
<PostClientFlow>
<PostFlow>
Untergeordnete Elemente <Condition>
<Step>

Syntax

Das <Response>-Element verwendet die folgende Syntax:

<Response>
  <Step>
    <Condition>property operator "value"</Condition>
    <Name>policy_name</Name>
  </Step>
  ...
</Response>

Alle untergeordneten Elemente von <Response> sind optional.

Beispiel

Das folgende Beispiel zeigt für die Antwort definierte Abläufe im PreFlow und PostFlow:

<!-- api-platform/reference/examples/flow-segments/response-1.xml -->
<ProxyEndpoint name="default">
    <PreFlow name="my-preFlows">
        <Description>My first PreFlow</Description>
        <Response>
            <Step>
                <Condition>response.status.code LesserThanOrEquals 300</Condition>
                <Name>Log-Response-OK</Name>
            </Step>
            <Step>
                <Condition>response.status.code GreaterThan 300</Condition>
                <Name>Log-Response-NOT-OK</Name>
            </Step>
        </Response>
    </PreFlow>
    <PostFlow name="my-postflows">
        <Description>My first PostFlow</Description>
        <Response>
            <Step>
                <Name>Set-Response-Headers</Name>
            </Step>
        </Response>
    </PostFlow>
  ...
</ProxyEndpoint>

Attribute

Das <Response>-Element hat keine Attribute.

Untergeordnete Elemente

In der folgenden Tabelle werden die untergeordneten Elemente von <Response> beschrieben:

Untergeordnetes Element Typ Beschreibung
<Condition> String Legt fest, ob die Schritte im Antwortsegment ausgeführt werden.
<Step> String Gibt eine Richtlinie an, die im Antwortsegment ausgeführt werden soll.

<Step>

Gibt eine auszuführende Richtlinie und optional eine Bedingung an, die bestimmt, ob diese Richtlinie ausgeführt werden soll.

Typ Objekt des Komplexes
Übergeordnete Elemente <Request>
<Response>
Untergeordnete Elemente <Condition>
<Name>

In einem <Flow> können mehrere Schritte definiert werden. Die Schritte werden in der Reihenfolge ausgeführt, in der sie in der XML des Ablaufs definiert sind.

Schritte ohne Bedingung werden immer ausgeführt. Schritte mit einer Bedingung werden nur ausgeführt, wenn die Bedingung „true“ ergibt. Wenn die Bedingung „false“ ergibt, überspringt Apigee den Schritt.

Syntax

Das Element <Step> verwendet die folgende Syntax:

<Step>
  <Condition>property operator "value"</Condition>
  <Name>policy_name</Name>
</Step>

Es kann nur ein <Condition> und ein <Name> pro <Step> vorhanden sein, aber mehrere <Flow> können mehrere Schritte enthalten.

Alle untergeordneten Elemente von <Step> sind optional.

Beispiel 1

Das folgende Beispiel zeigt einen Schritt mit einer Bedingung und einen Schritt ohne Bedingung:

<!-- api-platform/reference/examples/flow-segments/step-1.xml -->
<ProxyEndpoint name="default">
  <PostFlow name="my-postflows">
      <Description>My first PostFlow</Description>
      <Request>
          <Step>
              <Condition>request.verb = "GET"</Condition>
              <Name>Log-Request-OK</Name>
          </Step>
      </Request>
      <Response>
          <Step>
              <Name>Set-Response-Headers</Name>
          </Step>
      </Response>
  </PostFlow>
  ...
</ProxyEndpoint>

Der Schritt ohne Bedingung wird jedes Mal während des Anfragesegments ausgeführt. Der Schritt mit einer Bedingung wird nur ausgeführt, wenn die Anfrage während des Antwortsegments ein „GET“ ist.

Beispiel 2

Das folgende Beispiel zeigt mehrere Schritte in einem einzelnen Segment:

<!-- api-platform/reference/examples/flow-segments/step-2.xml -->
<ProxyEndpoint name="default">
    <PostFlow name="PostFlow">
        <Response>
            <Step>
                <Name>Assign-Message-1</Name>
            </Step>
            <Step>
                <Name>Assign-Message-2</Name>
            </Step>
        </Response>
    </PostFlow>
  ...
</ProxyEndpoint>

Schritte ohne Bedingung werden immer ausgeführt.

Attribute

Das <Step>-Element hat keine Attribute.

Untergeordnete Elemente

In der folgenden Tabelle werden die untergeordneten Elemente von <Step> beschrieben:

Untergeordnetes Element Typ Beschreibung
<Condition> String Definiert eine bedingte Anweisung für den Schritt, der zur Laufzeit verarbeitet wird. Wenn die Anweisung den Wert „true“ ergibt, führt Apigee den Schritt aus. Wenn die Anweisung den Wert „false“ ergibt, überspringt Apigee den Schritt.
<Name> String Gibt die ID der Richtlinie an, die im aktuellen Ablauf ausgeführt werden soll.