Google używa technologii AI do tłumaczenia treści na Twój preferowany język. Tłumaczenia wygenerowane przez AI mogą zawierać błędy.

Dokumentacja konfiguracji przepływu

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

W tej sekcji znajdziesz informacje o elementach XML, których używasz do definiowania przepływów serwera proxy interfejsu API.

Więcej informacji

Hierarchia i składnia

Poniższe przykłady pokazują hierarchię elementów i składnię elementów konfiguracji przepływu:

Hierarchia elementów

Poniższy przykład pokazuje hierarchię elementów konfiguracji przepływu w elementach <ProxyEndpoint> i <TargetEndpoint>:

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

    more_horiz  // Additional configuration elements

</ProxyEndpoint | TargetEndpoint>

Składnia

W przykładzie poniżej pokazujemy składnię elementów konfiguracji przepływu. Każdy z tych elementów jest szczegółowo opisany w dalszej części tego artykułu:

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

Za pomocą tych elementów możesz zdefiniować wykonanie PreFlow, Conditional Flow, PostFlow i PostClientFlow.

Inne elementy konfiguracji

Ta sekcja nie obejmuje tych elementów używanych w konfiguracji serwera proxy:

<APIProxy>
<DefaultFaultRule>
<FaultRules>
<HTTPProxyConnection>
<ProxyEndpoint>
<RouteRule>
<TargetEndpoint>

Te elementy, które definiują konfigurację serwera proxy, a nie przepływy, zostały omówione w dokumentacji konfiguracji serwera proxy interfejsu API.

`<Condition>`

Definiuje instrukcję przetwarzaną w czasie wykonywania. Jeśli instrukcja przyjmuje wartość „true”, wykonywany jest krok lub przepływ powiązany z warunkiem. Jeśli instrukcja zwraca wartość „fałsz”, krok lub przepływ jest ignorowany.

Typ	Ciąg znaków
Elementy nadrzędne	`<Flow>` `<Step>`
Elementy podrzędne	Brak

Warunek możesz zastosować do konkretnego kroku lub do całego przepływu, w zależności od tego, czy umieścisz element w elemencie <Flow> czy <Step>:

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

Jeśli warunek w bloku <Step> zwraca wartość „prawda”, Edge wykonuje ten krok. Jeśli warunek przyjmuje wartość „false”, Edge pomija ten krok.

Jeśli warunek w <Flow> przyjmuje wartość „prawda”, Edge przetwarza wszystkie kroki w przepływie. Jeśli warunek przyjmie wartość false, Edge pominie cały przepływ.

Składnia

Element <Condition> ma tę składnię:

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

Gdzie:

property

Właściwość zmiennej przepływu, której chcesz użyć w warunku. Na przykład zmienna przepływu request ma właściwości o nazwach path i content. Aby użyć ich w warunku, określ flow_variable[kropka]property_name:

request.path
request.content

Pełną listę zmiennych przepływu i ich właściwości znajdziesz w dokumentacji zmiennych przepływu.

operator

Konstrukcja określająca sposób oceny warunku. Typowe operatory to:

>     greater than           <=    less than or equal to
<     less than              >=    greater than or equal to
=     equals                 &&    and
!=    not equals             ||    or

~~    JavaRegex
~     Matches
/~    MatchesPath

Pełną listę znajdziesz w sekcji Operatory w dokumentacji warunków.

„value”

Wartość, na podstawie której jest oceniana właściwość zmiennej przepływu. Zwykle jest to typ podstawowy, np. liczba całkowita lub ciąg znaków. Na przykład 200 lub „/cat”. Wartość może zawierać symbole wieloznaczne, takie jak gwiazdki i inne znaki do dopasowywania wzorców, zgodnie z opisem w artykule Dopasowywanie wzorców z użyciem warunków.

Przykład 1

W tym przykładzie sprawdzamy, czy właściwość verb zmiennej przepływu request ma wartość „GET”:

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

Jeśli żądanie to „GET”, ten przykład wykonuje zasadę „Log-Request-OK”.

Przykład 2

W tym przykładzie sprawdzany jest kod odpowiedzi:

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

W zależności od wartości kodu wykonywana jest inna zasada.

Atrybuty

Element <Condition> nie ma atrybutów.

Elementy podrzędne

Element <Condition> nie ma elementów podrzędnych.

`<Description>`

Opisuje przepływ w sposób zrozumiały dla człowieka. Użyj tego elementu, aby przekazać informacje o procesie sobie lub innym programistom. Opis nie jest widoczny na zewnątrz.

Typ	Ciąg znaków
Elementy nadrzędne	`<Flow>` `<PreFlow>` `<PostFlow>`
Elementy podrzędne	Brak

Składnia

Element <Description> ma tę składnię:

<Description>flow_description</Description>

Przykład

Poniższy przykład przedstawia element <Description>, który określa cel przepływu:

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

Atrybuty

Element <Description> nie ma atrybutów.

Elementy podrzędne

Element <Description> nie ma elementów podrzędnych.

`<Flow>`

Definiuje niestandardowy zestaw kroków wykonywanych przez Edge.

Typ	Obiekt złożony
Elementy nadrzędne	`<Flows>`
Elementy podrzędne	`<Condition>` `<Description>` `<Request>` `<Response>`

Opcjonalnie możesz określić <Condition> w <Flow>. W takim przypadku Edge wykonuje kroki w przepływie tylko wtedy, gdy warunek przyjmuje wartość true. W przeciwnym razie Edge pominie cały proces.

Element <Flows> może zawierać wiele elementów <Flow>, z których każdy ma własny warunek i kroki. Jeśli występuje wiele elementów <Flow>, Edge wykonuje tylko pierwszy z nich, w którym nie ma warunku lub warunek ma wartość „prawda”.

Możesz zdefiniować domyślny przepływ, który będzie zawsze wykonywany (jeśli żaden z pozostałych przepływów warunkowych nie zostanie uruchomiony). W zależności od konfiguracji serwera proxy interfejsu API może to być przydatne narzędzie do ochrony przed złośliwymi atakami.

Składnia

Element <Flow> ma tę składnię:

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

Wszystkie elementy podrzędne elementu <Flow> są opcjonalne.

Przykład 1

Ten przykład pokazuje prosty warunek <Flow>, który zawsze wykonuje zasadę „Log-Message-OK”:

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

Przykład 2

Poniższy przykład przedstawia <Flow> z wieloma krokami, z których każdy ma własny warunek:

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

Przykład 3

Poniższy przykład pokazuje wiele przepływów w przepływie warunkowym:

<!-- 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 wykonuje tylko jeden przepływ w segmencie. Wykonuje pierwszy przepływ, który nie ma warunku lub którego warunek ma wartość true.

Atrybuty

W tabeli poniżej opisano atrybuty elementu <Flow>:

Atrybut	Typ	Opis
`name`	Ciąg znaków	(Wymagany) Unikalny identyfikator procesu. np. „My-Conditional-Flow-1”. Nazwa nie może zawierać spacji ani innych znaków specjalnych.

Elementy podrzędne

W tabeli poniżej opisano elementy podrzędne elementu <Flow>:

Element podrzędny	Typ	Opis
`<Condition>`	Ciąg znaków	Definiuje instrukcję warunkową, która jest przetwarzana w czasie wykonywania. Jeśli instrukcja przyjmuje wartość „true”, przepływ (i wszystkie jego kroki) jest wykonywany. Jeśli instrukcja ma wartość fałszywą, przepływ (i wszystkie jego kroki) jest ignorowany.
`<Description>`	Ciąg znaków	Zawiera krótki opis przepływu. Ten opis nie jest widoczny na zewnątrz.
`<Request>`	Obiekt złożony	Określa kroki i warunki segmentu żądania.
`<Response>`	Obiekt złożony	Określa kroki i warunki segmentu odpowiedzi.

`<Flows>`

Zawiera zero lub więcej elementów <Flow>.

Typ	Obiekt złożony
Elementy nadrzędne	`<ProxyEndpoint>` `<TargetEndpoint>`
Elementy podrzędne	`<Flow>`

Jeśli w elemencie <Flows> znajduje się kilka elementów <Flow>, wykona się tylko jeden <Flow> z nich. Będzie to pierwszy przepływ, który nie ma <Condition> lub którego warunek przyjmuje wartość Prawda.

Możesz zdefiniować domyślny przepływ, który będzie zawsze wykonywany (jeśli żaden z pozostałych przepływów nie zostanie uruchomiony). W zależności od konfiguracji serwera proxy interfejsu API może to być przydatne narzędzie do ochrony przed złośliwymi atakami.

Składnia

Element <Flows> ma tę składnię:

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

Wszystkie elementy podrzędne elementu <Flows> są opcjonalne.

Przykład 1

Ten przykład pokazuje prosty element <Flows> z pojedynczym elementem <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 wykonuje jedną z tych zasad na podstawie sufiksu ścieżki, który pobiera ze zmiennej przepływu proxy. Jeśli sufiks ścieżki nie spełnia żadnego z tych warunków, Edge nie wykonuje tego przepływu.

Przykład 2

Poniższy przykład pokazuje kilka elementów <Flow> w elemencie <Flows>, z których każdy ma własny element <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 wykonuje tylko pierwszy przepływ w segmencie, którego warunek przyjmuje wartość „prawda”. Następnie Edge pomija pozostałe przepływy w segmencie.

Przykład 3

Poniższy przykład przedstawia domyślny <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 wykonuje tylko pierwszy przepływ w segmencie, którego warunek przyjmuje wartość „prawda”. Jeśli nie zostaną wykonane żadne przepływy warunkowe, zostanie wykonany trzeci przepływ w tym przykładzie (bez warunku).

Domyślny przepływ może być przydatnym narzędziem w ochronie przed złośliwymi atakami.

Atrybuty

Element <Flows> nie ma atrybutów.

Elementy podrzędne

Element <Flows> ma te elementy podrzędne:

Element podrzędny	Typ	Opis
`<Flow>`	Obiekt złożony	Automatyzacja, która określa jeden z możliwych zestawów kroków w automatyzacji warunkowej.

`<Name>`

Określa identyfikator zasady, która ma być wykonana w ramach <Flow>.

Typ	Ciąg znaków
Elementy nadrzędne	`<Step>`
Elementy podrzędne	Brak

Składnia

Element <Name> ma tę składnię:

<Name>policy_name</Name>

Przykład

W tym przykładzie pokazujemy 2 zasady, które są dodawane do przepływów według nazwy:

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

Atrybuty

Element <Name> nie ma atrybutów.

Elementy podrzędne

Element <Name> nie ma elementów podrzędnych.

`<PostFlow>`

Określa kroki, które należy wykonać w ramach PostFlow żądania i odpowiedzi.

Typ	Obiekt złożony
Elementy nadrzędne	`<ProxyEndpoint>` `<TargetEndpoint>`
Elementy podrzędne	`<Description>` `<Request>` `<Response>`

Element <PostFlow> ma tę składnię:

Składnia

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

Przykład

Poniższy przykład pokazuje przepływ po przepływie z określonymi krokami dotyczącymi żądania i odpowiedzi:

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

Atrybuty

W tabeli poniżej opisano atrybuty elementu <PostFlow>:

Atrybut	Typ	Opis
`name`	Ciąg znaków	Unikalny identyfikator przepływu (unikalny w ramach punktu końcowego). Na przykład „My-PostFlow-1”. Wartość nie może zawierać spacji ani innych znaków specjalnych.

Elementy podrzędne

W tabeli poniżej opisano elementy podrzędne elementu <PostFlow>:

Element podrzędny	Typ	Opis
`<Description>`	Ciąg znaków	Zawiera krótki opis przepływu.
`<Request>`	Obiekt złożony	Określa zasady, które mają być wykonywane podczas etapu PostFlow żądania.
`<Response>`	Obiekt złożony	Określa zasady, które mają być wykonywane podczas PostFlow odpowiedzi.

`<PostClientFlow>`

Określa zasady w punkcie końcowym proxy, które są wykonywane dopiero po zwróceniu odpowiedzi do klienta. Te zasady zwykle rejestrują wiadomości związane z odpowiedzią.

Typ	Obiekt złożony
Elementy nadrzędne	`<ProxyEndpoint>`
Elementy podrzędne	`<Description>` `<Response>`

Składnia

Element <PostClientFlow> ma tę składnię:

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

Wszystkie elementy podrzędne elementu <PostClientFlow> są opcjonalne.

Przykład

Poniższy przykład przedstawia prosty przepływ PostClientFlow, który wykonuje jedną zasadę:

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

Atrybuty

W tabeli poniżej opisano atrybuty elementu <PostClientFlow>:

Atrybut	Typ	Opis
`name`	Ciąg znaków	Unikalny identyfikator procesu. Nazwa nie może zawierać spacji ani innych znaków specjalnych. Na przykład „My-PostClientFlow-1”.

Elementy podrzędne

W tabeli poniżej opisano elementy podrzędne elementu <PostClientFlow>:

Element podrzędny	Typ	Opis
`<Description>`	Ciąg znaków	Zawiera krótki opis przepływu.
`<Response>`	Obiekt złożony	Określa zasady, które mają być wykonywane podczas PostFlow odpowiedzi.

`<PreFlow>`

Określa zasady, które mają być wykonywane w ramach PreFlow żądania i odpowiedzi.

Typ	Obiekt złożony
Elementy nadrzędne	`<ProxyEndpoint>` `<TargetEndpoint>`
Elementy podrzędne	`<Description>` `<Request>` `<Response>`

Składnia

Element <PreFlow> ma tę składnię:

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

Wszystkie elementy podrzędne elementu <PreFlow> są opcjonalne.

Przykład

Poniższy przykład pokazuje PreFlow z określonym przepływem żądania i odpowiedzi:

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

Atrybuty

W tabeli poniżej opisano atrybuty elementu <PreFlow>:

Atrybut	Typ	Opis
`name`	Ciąg znaków	Unikalny identyfikator procesu. Nazwa nie może zawierać spacji ani innych znaków specjalnych. Na przykład „My-PreFlow-1”.

Elementy podrzędne

W tabeli poniżej opisano elementy podrzędne elementu <PreFlow>:

Element podrzędny	Typ	Opis
`<Description>`	Ciąg znaków	Zawiera krótki opis przepływu.
`<Request>`	Obiekt złożony	Określa zasady, które mają być wykonywane podczas wstępnego przetwarzania żądania.
`<Response>`	Obiekt złożony	Określa zasady, które mają być wykonywane podczas PreFlow odpowiedzi.

`<Request>`

Określa zasady, które mają być wykonywane w segmencie żądania przepływu.

Typ	Obiekt złożony
Elementy nadrzędne	`<Flow>` `<PreFlow>` `<PostFlow>`
Elementy podrzędne	`<Condition>` `<Step>`

Składnia

Element <Request> ma tę składnię:

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

Wszystkie elementy podrzędne elementu <Request> są opcjonalne.

Przykład

W przykładzie poniżej pokazujemy przepływy zdefiniowane dla żądania w przepływie PreFlow i 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>

Atrybuty

Element <Request> nie ma atrybutów.

Elementy podrzędne

W tabeli poniżej opisano elementy podrzędne elementu <Request>:

Element podrzędny	Typ	Opis
`<Condition>`	Obiekt złożony	Określa, czy kroki w segmencie żądania są wykonywane.
`<Step>`	Ciąg znaków	Określa zasadę, która ma być wykonywana w segmencie żądania.

`<Response>`

Określa zasady, które mają być wykonywane w segmencie odpowiedzi przepływu.

Typ	Obiekt złożony
Elementy nadrzędne	`<Flow>` `<PreFlow>` `<PostClientFlow>` `<PostFlow>`
Elementy podrzędne	`<Condition>` `<Step>`

Składnia

Element <Response> ma tę składnię:

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

Wszystkie elementy podrzędne elementu <Response> są opcjonalne.

Przykład

W przykładzie poniżej pokazujemy przepływy zdefiniowane dla odpowiedzi w przepływie PreFlow i 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>

Atrybuty

Element <Response> nie ma atrybutów.

Elementy podrzędne

W tabeli poniżej opisano elementy podrzędne elementu <Response>:

Element podrzędny	Typ	Opis
`<Condition>`	Ciąg znaków	Określa, czy kroki w segmencie odpowiedzi są wykonywane.
`<Step>`	Ciąg znaków	Określa zasady, które mają być wykonywane w segmencie odpowiedzi.

`<Step>`

Określa zasadę do wykonania i (opcjonalnie) warunek, który decyduje o tym, czy ją wykonać.

Typ	Obiekt złożony
Elementy nadrzędne	`<Request>` `<Response>`
Elementy podrzędne	`<Condition>` `<Name>`

W elemencie <Flow> można zdefiniować więcej niż 1 krok. Kroki są wykonywane w kolejności, w jakiej są zdefiniowane w pliku XML przepływu.

Kroki bez warunku są zawsze wykonywane. Kroki z warunkiem są wykonywane tylko wtedy, gdy warunek zwraca wartość „prawda”. Jeśli warunek przyjmuje wartość „false”, Edge pomija krok.

Składnia

Element <Step> ma tę składnię:

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

Każdy <Step> może zawierać tylko jeden element <Condition> i jeden element <Name>, ale <Flow> może zawierać wiele kroków.

Wszystkie elementy podrzędne elementu <Step> są opcjonalne.

Przykład 1

Poniższy przykład pokazuje jeden krok z warunkiem i jeden krok bez warunku:

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

Krok bez warunku będzie wykonywany za każdym razem w segmencie żądania. Krok z warunkiem zostanie wykonany tylko wtedy, gdy żądanie będzie typu „GET” w segmencie odpowiedzi.

Przykład 2

Poniższy przykład pokazuje wiele kroków w jednym segmencie:

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

Kroki bez warunku są zawsze wykonywane.

Atrybuty

Element <Step> nie ma atrybutów.

Elementy podrzędne

W tabeli poniżej opisano elementy podrzędne elementu <Step>:

Element podrzędny	Typ	Opis
`<Condition>`	Ciąg znaków	Definiuje instrukcję warunkową dla kroku, który jest przetwarzany w czasie działania. Jeśli instrukcja przyjmuje wartość „true”, Edge wykonuje krok. Jeśli instrukcja ma wartość fałsz, Edge pomija ten krok.
`<Name>`	Ciąg znaków	Określa identyfikator zasady, która ma być wykonana w bieżącym procesie.