Esta página aplica-se ao Apigee e ao Apigee Hybrid.
  
    Veja a documentação do 
    Apigee Edge.
  
  
      
 
  
Esta secção fornece informações de referência sobre os elementos XML que usa para definir os fluxos do proxy de API.
Hierarquia e sintaxe
Os exemplos seguintes mostram a hierarquia de elementos e a sintaxe dos elementos de configuração do fluxo:
Hierarquia de elementos
O exemplo seguinte mostra a hierarquia dos elementos de configuração do fluxo nos elementos
      <ProxyEndpoint> e <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>
    EventFlow
          <Response>
                <Step>
                    
          <Description>
    <PostClientFlow> (<ProxyEndpoint> only)
          <Response>
                
          <Description>
      // Additional configuration elements
</ProxyEndpoint | TargetEndpoint>Sintaxe
O exemplo seguinte mostra a sintaxe dos elementos de configuração do fluxo. Cada um destes elementos é descrito detalhadamente nas secções seguintes:
<!-- 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>Use estes elementos para definir a execução de PreFlow, Conditional Flow, PostFlow, EventFlow e PostClientFlow.
<Condition>
  Define uma declaração que é processada no tempo de execução. Se a declaração for avaliada como verdadeira, o passo ou o fluxo associado à condição é executado. Se a declaração for avaliada como falsa, o passo ou o fluxo são ignorados.
| Tipo | String | 
| Elementos principais | 
        
          
            <Flow><Step> | 
    
| Elementos secundários | Nenhum | 
Pode aplicar uma condição a um passo específico ou a um fluxo completo, consoante coloque o elemento no elemento <Flow> ou <Step>:
// Condition can apply to just one step: // Or to the flow:<Flows><Flows><Flow><Flow><Step><Condition><Condition><Step><Name><Name>... ... ... ... ... ... </Flows> </Flows>
Se uma condição num <Step> for avaliada como verdadeira, o Apigee executa esse passo. Se a condição for avaliada como falsa, o Apigee ignora o passo.
Se uma condição num <Flow> for avaliada como verdadeira, o Apigee processa todos os passos no fluxo. Se
  a condição for avaliada como falsa, o Apigee ignora todo o fluxo.
Sintaxe
O elemento <Condition> usa a seguinte sintaxe:
<Condition>property operator "value"</Condition>
Onde:
- property
 - A propriedade da variável de fluxo que quer usar na sua condição. Por exemplo, a variável de fluxo 
requesttem propriedades denominadaspathecontent. Para as usar numa condição, especifique o flow_variable[ponto]property_name:request.path request.content
Para ver uma lista completa das variáveis de fluxo e das respetivas propriedades, consulte a Referência de variáveis de fluxo.
 - operator
 - Uma construção que define como a sua condição é avaliada. Os operadores
          comuns incluem:
          
> greater than <= less than or equal to < less than >= greater than or equal to = equals && and != not equals || or ~~ JavaRegex ~ Matches /~ MatchesPath
Para ver uma lista completa, consulte os Operadores na referência de condições.
 - "value"
 - O valor com base no qual a propriedade da variável de fluxo é avaliada. Normalmente, trata-se de um tipo básico, como um número inteiro ou uma string. Por exemplo, 
200ou/cat. O valor pode incluir carateres universais, como asteriscos e outros carateres para correspondência de padrões, conforme descrito em Correspondência de padrões com condicionais. 
Exemplo 1
O exemplo seguinte verifica se a propriedade verb da variável de fluxo request é 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>
Se o pedido for um GET, este exemplo executa a política Log-Request-OK.
Exemplo 2
O exemplo seguinte verifica o código de resposta:
<!-- 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>
Consoante o valor do código, é executada uma política diferente.
Atributos
O elemento <Condition> não tem atributos.
Elementos secundários
O elemento <Condition> não tem elementos subordinados.
<Description>
  Descreve o fluxo em termos legíveis. Use este elemento para fornecer informações sobre o fluxo a si ou a outros programadores. A descrição não é visível externamente.
| Tipo | String | 
| Elementos principais | 
        
          
            <Flow><PreFlow><PostFlow> | 
    
| Elementos secundários | Nenhum | 
Sintaxe
O elemento <Description> usa a seguinte sintaxe:
<Description>flow_description</Description>
Exemplo
O exemplo seguinte mostra um elemento <Description> que especifica a finalidade de um fluxo:
<!-- 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>
Atributos
O elemento <Description> não tem atributos.
Elementos secundários
O elemento <Description> não tem elementos subordinados.
<Flow>
  Define um conjunto personalizado de passos que o Apigee executa.
| Tipo | Objeto complexo | 
| Elementos principais | 
        
          
            <Flows> | 
    
| Elementos secundários | 
        
          
            <Condition><Description><Request><Response> | 
    
Opcionalmente, pode especificar um <Condition> num <Flow>. Nesse caso, o Apigee só executa os passos no fluxo se a condição for avaliada como verdadeira. Caso contrário, o Apigee ignora todo o fluxo.
Um elemento <Flows> pode conter vários elementos <Flow>, cada um com a sua própria condição
  e passos. Quando existem vários elementos <Flow>, o Apigee executa apenas o primeiro em que não existe uma condição ou a condição é avaliada como verdadeira.
Pode definir um fluxo predefinido que é sempre executado (se nenhum dos outros fluxos condicionais o fizer). Consoante a forma como o proxy de API está configurado, pode ser uma ferramenta útil para proteger contra ataques maliciosos.
Sintaxe
O elemento <Flow> usa a seguinte sintaxe:
<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>Todos os elementos secundários de <Flow> são opcionais.
Exemplo 1
O exemplo seguinte mostra um <Flow> que executa sempre a política "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>
Exemplo 2
O exemplo seguinte mostra um <Flow> com vários passos, cada um com a sua própria condição:
<!-- 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>
Exemplo 3
O exemplo seguinte mostra vários fluxos num fluxo condicional:
<!-- 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>
O Apigee executa apenas um fluxo num segmento; executa o primeiro fluxo que não tem uma condição ou cuja condição é resolvida como verdadeira.
Atributos
A tabela seguinte descreve os atributos do elemento <Flow>:
| Atributo | Tipo | Descrição | 
|---|---|---|
name | 
        String | (Obrigatório) Um ID exclusivo para o fluxo. Por exemplo,
          My-Conditional-Flow-1. O nome não pode conter espaços nem outros carateres especiais. | 
      
Elementos secundários
A tabela seguinte descreve os elementos subordinados de <Flow>:
| Elemento secundário | Tipo | Descrição | 
|---|---|---|
<Condition> | 
        String | Define uma declaração condicional que é processada no tempo de execução. Se a declaração for avaliada como verdadeira, o fluxo (e todos os respetivos passos) é executado. Se a declaração for avaliada como falsa, o fluxo (e todos os respetivos passos) é ignorado. | 
<Description> | 
        String | Fornece uma breve descrição do fluxo. Esta descrição não é visível externamente. | 
<Request> | 
        Objeto complexo | Especifica os passos e as condições para o segmento de pedidos. | 
<Response> | 
        Objeto complexo | Especifica os passos e as condições para o segmento de resposta. | 
<Flows>
  Contém zero ou mais elementos <Flow>.
| Tipo | Objeto complexo | 
| Elementos principais | 
        
          
            <ProxyEndpoint><TargetEndpoint> | 
    
| Elementos secundários | 
        
          
            <Flow> | 
    
Se existirem vários elementos <Flow> em <Flows>, apenas um <Flow> é executado. Este será o primeiro fluxo que não tem um <Condition> ou cuja condição é resolvida como verdadeira.
Pode definir um fluxo predefinido que é sempre executado (se nenhum dos outros fluxos o for). Consoante a forma como o proxy de API está configurado, pode ser uma ferramenta útil para proteger contra ataques maliciosos.
Sintaxe
O elemento <Flows> usa a seguinte sintaxe:
<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>Todos os elementos secundários de <Flows> são opcionais.
Exemplo 1
O exemplo seguinte mostra um elemento <Flows> simples com um único <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>
O Apigee executa uma destas políticas com base no sufixo do caminho que recolhe da variável de fluxo proxy. Se o sufixo do caminho não corresponder a nenhuma das condições, o Apigee não executa este fluxo.
Exemplo 2
O exemplo seguinte mostra vários elementos <Flow> dentro de <Flows>, cada um com o seu próprio
      <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>
O Apigee executa apenas o primeiro fluxo num segmento cuja condição é avaliada como verdadeira. Depois disso, o Apigee ignora os fluxos restantes no segmento.
Exemplo 3
O exemplo seguinte mostra um <Flow> "predefinição":
<!-- 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>
O Apigee executa apenas o primeiro fluxo num segmento cuja condição é avaliada como verdadeira. Se não forem executados fluxos condicionais, o terceiro fluxo neste exemplo (sem condição) é executado.
Um fluxo predefinido pode ser uma ferramenta útil para proteção contra ataques maliciosos.
Atributos
O elemento <Flows> não tem atributos.
Elementos secundários
O elemento <Flows> tem os seguintes elementos subordinados:
| Elemento secundário | Tipo | Descrição | 
|---|---|---|
<Flow> | 
        Objeto complexo | Um fluxo que define um conjunto possível de passos no fluxo condicional. | 
<Name>
  Especifica o ID da política a executar num <Flow>.
| Tipo | String | 
| Elementos principais | 
        
          
            <Step> | 
    
| Elementos secundários | Nenhum | 
Sintaxe
O elemento <Name> usa a seguinte sintaxe:
<Name>policy_name</Name>
Exemplo
O exemplo seguinte mostra duas políticas que são adicionadas aos fluxos pelo respetivo nome:
<!-- 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>
Atributos
O elemento <Name> não tem atributos.
Elementos secundários
O elemento <Name> não tem elementos subordinados.
<PostFlow>
  Define os passos a seguir no PostFlow do pedido e da resposta.
| Tipo | Objeto complexo | 
| Elementos principais | 
        
          
            <ProxyEndpoint><TargetEndpoint> | 
    
| Elementos secundários | 
        
          
            <Description><Request><Response> | 
    
O elemento <PostFlow> usa a seguinte sintaxe:
Sintaxe
<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>Exemplo
O exemplo seguinte mostra um PostFlow com passos definidos para o pedido e a resposta:
<!-- 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>
Atributos
A tabela seguinte descreve os atributos do elemento <PostFlow>:
| Atributo | Tipo | Descrição | 
|---|---|---|
name | 
        String | Um ID exclusivo do fluxo (exclusivo no ponto final). Por exemplo,
          My-PostFlow-1. O valor
          não pode incluir espaços nem outros carateres especiais. | 
      
Elementos secundários
A tabela seguinte descreve os elementos subordinados de <PostFlow>:
| Elemento secundário | Tipo | Descrição | 
|---|---|---|
<Description> | 
        String | Fornece uma breve descrição do fluxo. | 
<Request> | 
        Objeto complexo | Define as políticas a executar durante o PostFlow do pedido. | 
<Response> | 
        Objeto complexo | Define as políticas a executar durante o PostFlow da resposta. | 
<EventFlow>
Define os passos a dar no EventFlow. EventFlow é usado para suportar o streaming de eventos enviados pelo servidor. Para
    mais informações, consulte o artigo Streaming de eventos enviados pelo servidor.
  
| Tipo | Objeto complexo | 
| Elementos principais | 
        
          
            <TargetEndpoint> | 
    
| Elementos secundários | 
        
          
            <Description><Response> | 
    
O elemento EventFlow usa a seguinte sintaxe:
Sintaxe
<EventFlow name="flow_name" content-type="text/event-stream">> <Description>flow_description</Description> <Response> <Step> <Name>policy_name</Name> </Step> </Response> </EventFlow>
Exemplo
O exemplo seguinte mostra um EventFlow:
<TargetEndpoint name="default"> <EventFlow name="EF-1" content-type="text/event-stream"> <Response> <Step> <Name>Raise-Fault-Cred-Invalid</Name> <Condition>fault.name equals "invalid_access_token"</Condition> </Step> </Response> </EventFlow> <HTTPTargetConnection> </TargetEndpoint></pre>
Atributos
A tabela seguinte descreve os atributos do elemento EventFlow:
| Atributo | Tipo | Descrição | 
|---|---|---|
name | 
        String | Um ID exclusivo do fluxo (exclusivo no ponto final). Por exemplo,
          My-EventFlow-1. O valor
          não pode incluir espaços nem outros carateres especiais. | 
      
content-type | 
        String | (Obrigatório) Tem de ser definido como: content-type="text/event-stream" | 
      
Elementos secundários
A tabela seguinte descreve os elementos subordinados de EventFlow:
| Elemento secundário | Tipo | Descrição | 
|---|---|---|
<Description> | 
        String | Fornece uma breve descrição do fluxo. | 
<Response> | 
        Objeto complexo | Define as políticas a executar durante o EventFlow da resposta. | 
<PostClientFlow>
  Define políticas no ProxyEndpoint que são executadas apenas depois de uma resposta ter sido devolvida ao cliente. Normalmente, estas políticas registam mensagens relacionadas com a resposta.
| Tipo | Objeto complexo | 
| Elementos principais | 
        
          
            <ProxyEndpoint> | 
    
| Elementos secundários | 
        
          
            <Description><Response> | 
    
Sintaxe
O elemento <PostClientFlow> usa a seguinte sintaxe:
<PostClientFlow name="flow_name">
  <Description>flow_description</Description>
  <Response>
    <Step>
      <Condition>property operator "value"</Condition>
      <Name>policy_name</Name>
    </Step>
    ...
  </Response>
</PostClientFlow>Todos os elementos secundários de <PostClientFlow> são opcionais.
Exemplo
O exemplo seguinte mostra um PostClientFlow simples que executa uma única política:
<!-- 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>
Atributos
A tabela seguinte descreve os atributos do elemento <PostClientFlow>:
| Atributo | Tipo | Descrição | 
|---|---|---|
name | 
        String | Um ID exclusivo do fluxo. O nome não pode incluir espaços nem outros carateres
        especiais. Por exemplo, My-PostClientFlow-1. | 
      
Elementos secundários
A tabela seguinte descreve os elementos subordinados de <PostClientFlow>:
| Elemento secundário | Tipo | Descrição | 
|---|---|---|
<Description> | 
        String | Fornece uma breve descrição do fluxo. | 
<Response> | 
        Objeto complexo | Define as políticas a executar durante o PostFlow da resposta. | 
<PreFlow>
  Define as políticas a executar no PreFlow do pedido e da resposta.
| Tipo | Objeto complexo | 
| Elementos principais | 
        
          
            <ProxyEndpoint><TargetEndpoint> | 
    
| Elementos secundários | 
        
          
            <Description><Request><Response> | 
    
Sintaxe
O elemento <PreFlow> usa a seguinte sintaxe:
<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>Todos os elementos secundários de <PreFlow> são opcionais.
Exemplo
O exemplo seguinte mostra um PreFlow com um pedido e um fluxo de resposta definidos:
<!-- 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>
Atributos
A tabela seguinte descreve os atributos do elemento <PreFlow>:
| Atributo | Tipo | Descrição | 
|---|---|---|
name | 
        String | Um ID exclusivo do fluxo. O nome não pode incluir espaços nem outros carateres
        especiais. Por exemplo, My-PreFlow-1. | 
      
Elementos secundários
A tabela seguinte descreve os elementos subordinados de <PreFlow>:
| Elemento secundário | Tipo | Descrição | 
|---|---|---|
<Description> | 
        String | Fornece uma breve descrição do fluxo. | 
<Request> | 
        Objeto complexo | Define as políticas a executar durante o PreFlow do pedido. | 
<Response> | 
        Objeto complexo | Define as políticas a executar durante o PreFlow da resposta. | 
<Request>
  Define as políticas a executar durante o segmento de pedido do fluxo.
| Tipo | Objeto complexo | 
| Elementos principais | 
        
          
            <Flow><PreFlow><PostFlow> | 
    
| Elementos secundários | 
        
          
            <Step> | 
    
Sintaxe
O elemento <Request> usa a seguinte sintaxe:
<Request>
  <Step>
    <Condition>property operator "value"</Condition>
    <Name>policy_name</Name>
  </Step>
  ...
</Request>Todos os elementos secundários de <Request> são opcionais.
Exemplo
O exemplo seguinte mostra os fluxos definidos para o pedido no PreFlow e no 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>
Atributos
O elemento <Request> não tem atributos.
Elementos secundários
A tabela seguinte descreve os elementos subordinados de <Request>:
| Elemento secundário | Tipo | Descrição | 
|---|---|---|
<Step> | 
        String | Especifica uma política a executar no segmento de pedido. Este tipo de elemento filho pode aparecer várias vezes. | 
<Response>
  Define as políticas a executar durante o segmento de resposta do fluxo.
| Tipo | Objeto complexo | 
| Elementos principais | 
        
          
            <Flow><PreFlow><PostClientFlow><PostFlow> | 
    
| Elementos secundários | 
        
          
            <Step> | 
    
Sintaxe
O elemento <Response> usa a seguinte sintaxe:
<Response>
  <Step>
    <Condition>property operator "value"</Condition>
    <Name>policy_name</Name>
  </Step>
  ...
</Response>Todos os elementos secundários de <Response> são opcionais.
Exemplo
O exemplo seguinte mostra os fluxos definidos para a resposta, tanto no PreFlow como no 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>
Atributos
O elemento <Response> não tem atributos.
Elementos secundários
A tabela seguinte descreve os elementos subordinados de <Response>:
| Elemento secundário | Tipo | Descrição | 
|---|---|---|
<Step> | 
        String | Especifica uma política a executar no segmento de resposta. Este tipo de elemento filho pode aparecer várias vezes. | 
<Step>
  Especifica uma política a executar e (opcionalmente) uma condição que determina se deve executar essa política.
| Tipo | Objeto complexo | 
| Elementos principais | 
        
          
            <Request><Response> | 
    
| Elementos secundários | 
        
          
            <Condition><Name> | 
    
Pode haver mais do que um passo definido num <Flow>, e os passos são executados pela ordem em que são definidos no XML do fluxo.
Os passos sem uma condição são sempre executados. Os passos com uma condição só são executados se a condição for avaliada como verdadeira. Se a condição for avaliada como falsa, o Apigee ignora o passo.
Sintaxe
O elemento <Step> usa a seguinte sintaxe:
<Step> <Condition>property operator "value"</Condition> <Name>policy_name</Name> </Step>
Só pode haver um <Condition> e um <Name> por <Step>, mas pode haver vários passos num <Flow>.
Todos os elementos secundários de <Step> são opcionais.
Exemplo 1
O exemplo seguinte mostra um passo com uma condição e um passo sem uma condição:
<!-- 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>
O passo sem a condição é executado sempre durante o segmento de pedido. O passo com uma condição só é executado quando o pedido é "GET" durante o segmento de resposta.
Exemplo 2
O exemplo seguinte mostra vários passos num único segmento:
<!-- 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>
Os passos sem uma condição são sempre executados.
Atributos
O elemento <Step> não tem atributos.
Elementos secundários
A tabela seguinte descreve os elementos subordinados de <Step>:
| Elemento secundário | Tipo | Descrição | 
|---|---|---|
<Condition> | 
        String | Define uma declaração condicional para o passo que é processado no tempo de execução. Se a declaração for avaliada como verdadeira, o Apigee executa o passo. Se a declaração for avaliada como falsa, o Apigee ignora o passo. | 
<Name> | 
        String | Especifica o ID da política a executar no fluxo atual. |