Dokumentacja konfiguracji przepływu

Przeglądasz dokumentację Apigee Edge.
Przejdź do Dokumentacja Apigee X. informacje.

Ta sekcja zawiera informacje referencyjne na temat elementów XML, które służą do definiowania Przepływy serwerów proxy interfejsu API.

Hierarchia składnia

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

Hierarchia elementów

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

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

Składnia

Poniższy przykład pokazuje składnię elementów konfiguracji przepływu. Każda z tych opcji są szczegółowo opisane w tych sekcjach:

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

Tych elementów możesz używać do zdefiniowania przepływu warunkowego, przepływu warunkowego, PostFlow i PostClientFlow

<Condition>

Definiuje instrukcję przetwarzany w czasie działania. Jeśli instrukcja zwraca wartość true (prawda), krok lub przepływ powiązany z warunkiem zostanie wykonany. Jeśli zwraca wartość false (fałsz), a dany 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 całego procesu, w zależności od tego, element w elemencie <Flow> lub <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 elemencie <Step> ma wartość Prawda, Edge wykonuje ten krok. Jeśli warunek zwraca wartość fałsz, a Edge pomija krok.

Jeśli warunek w obrębie <Flow> ma wartość Prawda, Edge przetwarza wszystkie kroki przepływu. Jeśli gdy warunek zostanie zwrócony jako fałsz, Edge pomija cały przepływ.

Składnia

Element <Condition> ma taką składnię:

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

Gdzie:

property
Właściwość zmiennej przepływu, której chcesz użyć w swoim tagu . Na przykład zmienna przepływu request ma właściwości o nazwie path i content. Aby ich użyć w warunkach, musisz wskazać flow_variable[kropka]property_name: 
request.path
request.content

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

operator
Obiekt, który określa sposób oceny warunku. Powszechny operatory obejmują: 
>     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 tutaj Operatory w Informacje o warunkach.

„value”
Wartość, względem której oceniana jest właściwość zmiennej przepływu. Jest to zwykle podstawowy typ, taki jak liczba całkowita lub ciąg znaków. Przykład: 200 lub „/cat”. Wartość może mogą zawierać symbole wieloznaczne, takie jak gwiazdki i inne znaki służące do dopasowywania wzorców, jak opisane w Dopasowywanie do wzorca z warunkami.

Przykład 1

Ten przykład pozwala sprawdzić, czy verb zmiennej przepływu request jest „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 żądanie „Log-Request-OK”. .

Przykład 2

Ten przykład pozwala sprawdzić 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 proces w zrozumiały dla człowieka sposób. Użyj tego elementu, aby podać informacje o do Ciebie lub do innych programistów. Opis nie jest widoczny z zewnątrz.

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

Składnia

Element <Description> ma taką składnię:

<Description>flow_description</Description>

Przykład

W przykładzie poniżej widać element <Description>, który określa przeznaczenie przepływ:

<!-- 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, które wykonuje Edge.

Typ Złożony obiekt
Elementy nadrzędne <Flows>
Elementy podrzędne <Condition>
<Description>
<Request>
<Response>

Opcjonalnie możesz określić <Condition> w <Flow>. W takim przypadku Edge będzie wykonywać tylko kroków ścieżki, jeśli warunek ma wartość prawda. W przeciwnym razie Edge pomija cały przepływu danych.

Element <Flows> może zawierać wiele elementów <Flow>, z których każdy może mieć własny warunek i krokach. W przypadku wielu elementów <Flow> Edge wykonuje tylko pierwszy z nich, w którym nie ma warunku lub warunek przyjmuje wartość prawda.

Możesz zdefiniować przepływ domyślny, który zawsze jest wykonywany (jeśli nie robią tego żadne inne przepływy warunkowe). W zależności od konfiguracji serwera proxy interfejsu API może to być przydatne narzędzie w ochrony przed złośliwym oprogramowaniem .

Składnia

Element <Flow> ma taką 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

Poniższy przykład pokazuje prosty interfejs <Flow>, który zawsze wykonuje polecenie „Log-Message-OK”. zasady:

<!-- 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 pokazuje pole <Flow> z wieloma krokami, z których każdy zawiera własne. 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

Przykład poniżej pokazuje kilka 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 zawiera warunek lub gdy warunek ma wartość prawda.

Atrybuty

W tej tabeli opisano atrybuty elementu <Flow>:

Atrybut Typ Opis
name Ciąg znaków (Wymagane) Unikalny identyfikator przepływu. Przykład: &quot;My-Conditional-Flow-1&quot;. Nazwa nie może zawierać spacji ani innych znaków specjalnych.

Elementy podrzędne

W tej tabeli 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 działania. Jeśli instrukcja ocenia na true, wówczas proces (i wszystkie jego kroki) jest realizowany. Jeśli instrukcja zwraca wartość false (fałsz), wówczas proces (i wszystkie jego kroki) będzie ignorowany.
<Description> Ciąg znaków Krótki opis przepływu zadań. Ten opis nie jest dostępny zewnętrznie widoczne.
<Request> Złożony obiekt Określa kroki i warunki związane z segmentem żądań.
<Response> Złożony obiekt Określa kroki i warunki związane z segmentem odpowiedzi.

<Flows>

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

Typ Złożony obiekt
Elementy nadrzędne <ProxyEndpoint>
<TargetEndpoint>
Elementy podrzędne <Flow>

Jeśli w obrębie <Flows> jest wiele elementów <Flow>, zostanie wykonany tylko 1 z nich <Flow>. Ten będzie pierwszym procesem, który nie ma <Condition> lub którego warunek zostanie rozwiązany na wartość true (prawda).

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

Składnia

Element <Flows> ma taką 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 przedstawia 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 zebranego z proxy zmienną przepływu. Jeśli sufiks ścieżki nie spełnia żadnego z warunków, Edge nie wykonuje tego przepływu.

Przykład 2

Poniższy przykład pokazuje wiele elementów <Flow> w obrębie <Flows>, z których każdy ma własne. <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. Po że Edge pomija pozostałe przepływy w segmencie.

Przykład 3

Następujący przykład przedstawia wartość domyślną <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 są wykonywane żadne przepływy warunkowe, potem trzeci przepływ w tym przykładzie (bez warunku) .

Domyślny przepływ może być przydatnym narzędziem ochrony przed złośliwym oprogramowaniem .

Atrybuty

Element <Flows> nie ma atrybutów.

Elementy podrzędne

Element <Flows> ma te elementy podrzędne:

Element podrzędny Typ Opis
<Flow> Złożony obiekt Przepływ, który określa jeden możliwy zestaw kroków w przepływie warunkowym.

<Name>

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

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

Składnia

Element <Name> ma taką składnię:

<Name>policy_name</Name>

Przykład

Poniższy przykład przedstawia 2 zasady dodane 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>

Definiuje działania, które należy wykonać w procesie PostFlow żądania i odpowiedzi.

Typ Złożony obiekt
Elementy nadrzędne <ProxyEndpoint>
<TargetEndpoint>
Elementy podrzędne <Description>
<Request>
<Response>

Element <PostFlow> ma taką 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 schemat PostFlow z krokami dla żądania i odpowiedzi. zdefiniowano:

<!-- 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 tej tabeli opisano atrybuty elementu <PostFlow>:

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

Elementy podrzędne

W tej tabeli opisano elementy podrzędne elementu <PostFlow>:

Element podrzędny Typ Opis
<Description> Ciąg znaków Krótki opis przepływu zadań.
<Request> Złożony obiekt Definiuje zasady, które mają być wykonywane w trakcie żądania PostFlow.
<Response> Złożony obiekt Definiuje zasady do wykonania w trakcie procesu PostFlow odpowiedzi.

<PostClientFlow>

Definiuje zasady w punkcie końcowym Proxy, które są wykonywane dopiero po zwróceniu odpowiedzi do do klienta. Te zasady zwykle rejestrują komunikaty związane z odpowiedzią.

Typ Złożony obiekt
Elementy nadrzędne <ProxyEndpoint>
Elementy podrzędne <Description>
<Response>

Składnia

Element <PostClientFlow> ma taką 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 pokazuje prostą zasadę PostClientFlow, która uruchamia 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 tej tabeli opisano atrybuty elementu <PostClientFlow>:

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

Elementy podrzędne

W tej tabeli opisano elementy podrzędne elementu <PostClientFlow>:

Element podrzędny Typ Opis
<Description> Ciąg znaków Krótki opis przepływu zadań.
<Response> Złożony obiekt Definiuje zasady do wykonania w trakcie procesu PostFlow odpowiedzi.

<PreFlow>

Określa zasady do wykonania w PreFlow żądania i odpowiedzi.

Typ Złożony obiekt
Elementy nadrzędne <ProxyEndpoint>
<TargetEndpoint>
Elementy podrzędne <Description>
<Request>
<Response>

Składnia

Element <PreFlow> ma taką 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 przepływ wstępnego przepływu ze zdefiniowanym żądaniem 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 tej tabeli opisano atrybuty elementu <PreFlow>:

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

Elementy podrzędne

W tej tabeli opisano elementy podrzędne elementu <PreFlow>:

Element podrzędny Typ Opis
<Description> Ciąg znaków Krótki opis przepływu zadań.
<Request> Złożony obiekt Określa zasady do wykonania podczas PreFlow żądania.
<Response> Złożony obiekt Definiuje zasady, które mają być wykonywane podczas procesu PreFlow odpowiedzi.

<Request>

Definiuje zasady, które mają być wykonywane w trakcie segmentu żądania w przepływie.

Typ Złożony obiekt
Elementy nadrzędne <Flow>
<PreFlow>
<PostFlow>
Elementy podrzędne <Condition>
<Step>

Składnia

Element <Request> ma taką 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

Poniższy przykład pokazuje przepływy zdefiniowane dla żądania zarówno w PreFlow, jak i PreFlow 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 tej tabeli opisano elementy podrzędne elementu <Request>:

Element podrzędny Typ Opis
<Condition> Złożony obiekt Określa, czy kroki w segmencie żądania zostały wykonane.
<Step> Ciąg znaków Określa zasadę do wykonania w segmencie żądania.

<Response>

Definiuje zasady wykonywane w trakcie segmentu odpowiedzi przepływu.

Typ Złożony obiekt
Elementy nadrzędne <Flow>
<PreFlow>
<PostClientFlow>
<PostFlow>
Elementy podrzędne <Condition>
<Step>

Składnia

Element <Response> ma taką 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

Poniższy przykład pokazuje przepływy zdefiniowane dla odpowiedzi zarówno w PreFlow, jak i PreFlow 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 tej tabeli opisano elementy podrzędne elementu <Response>:

Element podrzędny Typ Opis
<Condition> Ciąg znaków Określa, czy kroki w segmencie odpowiedzi zostały wykonane.
<Step> Ciąg znaków Określa zasadę do wykonania w segmencie odpowiedzi.

<Step>

Określa zasadę do wykonania i (opcjonalnie) warunek określający, czy ma zostać wykonana tej zasady.

Typ Złożony obiekt
Elementy nadrzędne <Request>
<Response>
Elementy podrzędne <Condition>
<Name>

W <Flow> może być zdefiniowanych więcej kroków. Są one wykonywane w interfejsie 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 ma wartość Fałsz, Edge pomija krok.

Składnia

Element <Step> ma taką składnię:

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

W każdym elemencie <Step> może przypadać tylko 1 <Condition> i 1 <Name>, ale nie może ich być wiele kroków w ciągu <Flow>.

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

Przykład 1

Na przykładzie poniżej widać jeden krok z warunkem, a drugi 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 podczas segmentu żądania. Krok z warunkiem zostanie wykonane tylko wtedy, gdy żądanie będzie typu „GET” w trakcie udzielania odpowiedzi segmentację.

Przykład 2

Przykład poniżej 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 tej tabeli 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 zwraca wartość prawda, a następnie Edge wykonuje krok. Jeśli instrukcja zwraca wartość false, a przeglądarka Edge pominie ten krok.
<Name> Ciąg znaków Określa identyfikator zasady do wykonania w bieżącym przepływie.