Ablaufkonfigurationsreferenz

<ph type="x-smartling-placeholder"></ph> Sie sehen die Dokumentation zu Apigee Edge.
Gehen Sie zur Apigee X-Dokumentation. Weitere Informationen

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 Keine

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> als wahr ausgewertet wird, führt Edge diesen Schritt aus. Wenn die Bedingung als falsch ausgewertet wird, überspringt Edge den Schritt.

Wenn eine Bedingung in einem <Flow> als wahr ausgewertet wird, verarbeitet Edge alle Schritte im Fluss. Wenn wird die Bedingung als falsch ausgewertet, überspringt Edge den gesamten Fluss.

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. Zur Verwendung in einer Bedingung geben Sie das Attribut flow_variable[Punkt]property_name: 
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äufig 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: 200 oder „/cat“. Der Wert kann Platzhalter wie Sternchen und andere Zeichen für den Musterabgleich verwenden, wie beschrieben in Musterabgleich mit Bedingungen:

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 Anforderung ein "GET" ist, führt dieses Beispiel die Anweisung "Log-Request-OK" .

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 Keine

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 Edge 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 wahr ausgewertet wird. Andernfalls überspringt Edge 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 Edge nur das erste Element aus, bei dem keine Bedingung vorliegt oder die Bedingung als wahr ausgewertet wird.

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>

Edge führt nur einen Ablauf in einem Segment aus; wird der erste Ablauf ausgeführt, der keine Bedingung hat oder dessen Bedingung in wahr aufgelöst wird.

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: &quot;My-Conditional-Flow-1&quot;. 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>

Edge führt eine dieser Richtlinien basierend auf dem Pfad-Suffix aus, das die Ablaufvariable proxy erfasst. Wenn das Pfadsuffix mit keiner der Bedingungen übereinstimmt, führt Edge 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>

Edge führt nur den ersten Ablauf in einem Segment aus, dessen Bedingung als wahr ausgewertet wird. Danach überspringt Edge 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>

Edge führt nur den ersten Ablauf in einem Segment aus, dessen Bedingung als wahr ausgewertet wird. 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 Keine

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). Zum 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. Zum Beispiel "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. Zum Beispiel "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 als falsch ausgewertet wird, überspringt Edge 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 als true ausgewertet, führt Edge den Schritt aus. Wird die Anweisung als auf „false“ setzen, dann überspringt Edge den Schritt.
<Name> String Gibt die ID der Richtlinie an, die im aktuellen Ablauf ausgeführt werden soll.