This page applies to Apigee and Apigee hybrid.
View
Apigee Edge documentation.
This section provides reference information about the XML elements you use to define your API proxy flows.
Hierarchy & syntax
The following examples show the element hierarchy and syntax of the flow configuration elements:
Element Hierarchy
The following example shows the hierarchy of the flow configuration elements within the
<ProxyEndpoint>
and <TargetEndpoint>
elements:
<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>
Syntax
The following example shows the syntax for the flow configuration elements. Each of these elements is described in detail in the sections that follow:
<!-- ProxyEndpoint flow configuration file --> <ProxyEndpoint ... > ... <PreFlow name="flow_>name&<quot; D>escriptionflow_d<escription/D>escri<ption > Requ<est > Ste<p > Conditionproperty operat<or "v>alue"<;/Co>ndition < >Namepol<icy_n>ame/Name </Step > .<.. />Request< > Response< St>ep Conditionprope<rty operat>or "<valu>e"/Con<ditio>n < Na>mepolicy_name/N<ame > /S<tep > .<.. /Response /Pr>eFlow< Flows name="flow_name&quo>t; <Flow name=&>quot;conditional<_flow_name&q>uot; < Descr>iptionflow_description/De<scription > C<onditio>nproperty< ope>rator "<;value&qu>ot;/Condition Reque<st > Step < > Conditionp<roper>ty operat<or &q>uot;value"/Con<dition > < Namepo>licy_name</Nam>e /<Step > ... /Request < Respon>se <Step> <Condi>tionprope<rty o>perator "value<"/Co>nditi<on > < N>ame<policy_name/Name >/Step< ..>. /Respons<e /Flow > /Fl<ows P>ostFlow< nam>e="f<low_name&>quot; Descriptionflow<_descripti>on/Descri<ptio>n Reque<st > Ste<p > Conditionp<roperty >opera<tor &quo>t;value<&quo>t;/Condit<ion > Namepolicy_name/Name < /Step> ..<. > /Request < R>esponse< > Step <Condition>pro<perty ope>rat<or "value"/Condition > < Namepoli>cy_name/Name < /Step > ..<. /R>esponse< />PostFlow < PostCli>entFlow name="flow_n<ame" > Descr<ipti>onflow_desc<ripti>on/Desc<ripti>on Response< St>ep < Conditi>onprope<rty operator &>qu<ot;value"/Condition Namepolicy_n>a<me/Name /Step> ..<. /Response /PostC>lient<Flow ... >/ProxyEndpoint <!-- TargetEn>dpoin<t flow >configu<rati>on file -<- TargetE>ndpoint ... ... PreF<low name=&>quot;flow<_nam>e" < Desc>ription<flow_>description/Des<cription> <Request > S<tep > C<onditionp>roperty operator "va<lue"/>Condition< > Namepo<licy_>name/Na<me > /Step < ... >/Re<quest > R<esponse Step > <Conditionproperty operator ">value&q<uot;/Condit>ion Name<policy_name/>Name < /Step> ... /Response < /PreFlow> Flow<s name=>"flo<w_na>me" < Flow na>me="conditional_flow<_name">; Des<crip>tionflow_de<scrip>tion/Desc<ripti>on Conditionp<roperty >operato<r ">value&quo<t;/C>ondition < Reque>st Step < Condition>property op<erat>or "va<lue&q>uot;/Cond<ition> Namepoli<cy_name/N>ame < > /Step < .>.. < /Request Resp>onse < Ste>p Cond<itionpropert>y ope<rator &>quot;va<lue&>quot;/Con<dition > Namepolicy_name/N<ame > /Step < > ... < /Re>sponse < />Flow ... </Flows > Post<Flow nam>e="<;flo>w_name&qu<ot; D>escriptionflow_descriptio<n/Descript>ion R<eque>st St<ep > C<ondit>ionproperty ope<rator &qu>ot;<value&quo>t;/Cond<ition N>amepolicy_name/Name /Step ... /Request Response Step Conditionproperty operator "value"/Condition Namepolicy_name/Name /Step ... /Response /PostFlow ... /TargetEndpoint
You use these elements to define your PreFlow, Conditional Flow, PostFlow, EventFlow, and PostClientFlow execution.
<Condition>
Defines a statement that is processed at runtime. If the statement evaluates to true, then the step or flow associated with the condition is executed. If the statement evaluates to false, then the step or flow is ignored.
Type | String |
Parent Element(s) |
<Flow> <Step> |
Child Element(s) | None |
You can apply a condition to a specific step or to an entire flow, depending on whether you put
the element in the <Flow>
or <Step>
element:
// Condition can apply to just one step: // Or to the flow:<Flows>
<Flows>
<Flow>
<Flow>
<Step>
<Condition>
<Condition>
<Step>
<Name>
<Name>
... ... ... ... ... ... </Flows> </Flows>
If a condition within a <Step>
evaluates to true, Apigee executes that step. If the condition
evaluates to false, Apigee skips the step.
If a condition within a <Flow>
evaluates to true, Apigee processes all the steps in the flow. If
the condition evaluates to false, Apigee skips the entire flow.
Syntax
The <Condition>
element uses the following syntax:
<Condition>property operator "v<alue">/Condition
Where:
- property
- The flow variable property that you want to use in your
condition. For example, the
request
flow variable has properties namedpath
andcontent
. To use them in a condition, you specify the flow_variable[dot]property_name:request.path request.content
For a complete list of flow variables and their properties, see Flow variables reference.
- operator
- A construct that defines how your condition is evaluated. Common
operators include:
> greater than <= less than or equal to < less than >= greater than or equal to = equals && and != not equals || or ~~ JavaRegex ~ Matches /~ MatchesPath
For a complete list, see Operators in the Conditions reference.
- "value"
- The value against which the flow variable property is evaluated. This is commonly a
basic type such as an integer or string. For example,
200
or/cat
. The value can include wildcards, such as asterisks and other characters for pattern matching, as described in Pattern matching with conditionals.
Example 1
The following example checks if the request
flow variable's verb
property is GET
:
<!-- api-platform/reference/examples/flow-segments/condition-1.xml --> <ProxyEndpoint name="def>aul<t" PreFlow name=&qu>ot;my<-preFlows&q>uot; Descrip<tionMy first> PreF<low/Des>criptio<n > Request< St>ep Condition<request.ve>rb = &quo<t;GE>T"/Condit<ion > <NameL>og-Re<quest-OK>/Na<me > /Step < /Request > /PreFlow ... /ProxyEndpoint
If the request is a GET
, then this example executes the Log-Request-OK
policy.
Example 2
The following example checks for the response code:
<!-- api-platform/reference/examples/flow-segments/condition-2.xml --> <ProxyEndpoint name="def>aul<t" PreFlow name=&qu>ot;my<-preFlows&q>uot; Descrip<tionMy first> PreF<low/Desc>ription< > Response< St>ep Conditionresponse.status.code Le<sserThanOr>Equals 30<0/Co>ndition < Name>Log-Res<ponse>-OK/Nam<e > /Step< St>ep Conditionresponse.status.<code Great>erThan 30<0/Co>ndition Nam<eLog->Respons<e-NOT>-OK/N<ame > /S<tep >/Respon<se /PreFlow > ... /ProxyEndpoint
Depending on the value of the code, a different policy is executed.
Attributes
The <Condition>
element has no attributes.
Child Elements
The <Condition>
element has no child elements.
<Description>
Describes the flow in human-readable terms. Use this element to provide information about the flow to yourself or other developers. The description is not externally visible.
Type | String |
Parent Element(s) |
<Flow> <PreFlow> <PostFlow> |
Child Element(s) | None |
Syntax
The <Description>
element uses the following syntax:
<Description>flow_description</Description>
Example
The following example shows a <Description>
element that specifies the purpose of a
flow:
<!-- api-platform/reference/examples/flow-segments/description-1.xml --> <ProxyEndpoint name="def>aul<t" Flows name="my-con>ditio<nal-flows" > Flow n<ame=&qu>ot;report<s" > Request DescriptionBased on the path suffi<x, determine> which fl<ow t>o use/Descr<iption > Step Conditionproxy.pat<hsuffix Ma>tchesPath &<quot>;/reports&quo<t;/Co>ndition < > NameX<ML-t>o-JSON-1/Na<me > /Step Step Conditionp<roxy.paths>uffix Match<esPa>th "/for<ecast>s"/C<ondit>ion < N>ameXM<L-to->JSO<N-1/Na>me < /Step > /Request /Flow /Flows ... /ProxyEndpoint
Attributes
The <Description>
element has no attributes.
Child Elements
The <Description>
element has no child elements.
<Flow>
Defines a custom set of steps that Apigee executes.
Type | Complex object |
Parent Element(s) |
<Flows> |
Child Element(s) |
<Condition> <Description> <Request> <Response> |
You can optionally specify a <Condition>
on a <Flow>
. In that case, Apigee only executes
the steps in the flow if the condition evaluates to true. Otherwise, Apigee skips the entire
flow.
A <Flows>
element can contain multiple <Flow>
elements, each with its own condition
and steps. When there are multiple <Flow>
elements, Apigee executes only the first one in which
there is no condition or the condition evaluates to true.
You can define a default flow that always executes (if none of the other conditional flows do). Depending on how your API proxy is configured, this can be a useful tool in protecting against malicious attacks.
Syntax
The <Flow>
element uses the following syntax:
<Flow name="conditional_flow_>nam<e" D>escriptionflow_d<escription/D>esc<ription > Conditionproperty operat<or "v>alu<e">/Cond<itio>n Req<uest >Step Conditionprope<rty operat>or &quo<t;va>lue"/C<ondit>ion < >Namepolicy_<name/Nam>e < /Step> <... > /Requ<est Res>ponse Step Cond<itionprope>rty ope<rato>r "val<ue&qu>ot;/C<ondit>ion N<amepolicy>_<name/>Name /Step ... /Response /Flow
All child elements of <Flow>
are optional.
Example 1
The following example shows a simple <Flow>
that always executes the "Log-Message-OK"
policy:
<!-- api-platform/reference/examples/flow-segments/flow-1.xml --> <ProxyEndpoint name="def>aul<t" Flows name>=&quo<t;my>-flow&q<uot; > Flow < >Request < > Step < Nam>eLog-Mess<age-O>K/Name < >/Step< > /<Reques>t /<Flow /Flows > ... /ProxyEndpoint
Example 2
The following example shows a <Flow>
with multiple steps, each with its own
condition:
<!-- api-platform/reference/examples/flow-segments/flow-2.xml --> <ProxyEndpoint name="def>aul<t" Flows name="my-con>ditio<nal-flows" > Flow n<ame=&qu>ot;report<s" > Request DescriptionBased on the path suffi<x, determine> which fl<ow t>o use/Descr<iption > Step Conditionproxy.pat<hsuffix Ma>tchesPath &<quot>;/reports&quo<t;/Co>ndition < > NameX<ML-t>o-JSON-1/Na<me > /Step Step Conditionp<roxy.paths>uffix Match<esPa>th "/for<ecast>s"/C<ondit>ion < N>ameVe<rify->Aut<h-1/Na>me < /Step > /Request /Flow /Flows ... /ProxyEndpoint
Example 3
The following example shows multiple flows in a Conditional Flow:
<!-- api-platform/reference/examples/flow-segments/flows-2.xml --> <ProxyEndpoint name="def>aul<t&quo>t; <Flows Flow name=&>quot;my<-flow-1&>quot; < R>esponse < Step> Conditionrespon<se.status.>code = 200/<Cond>ition <NameA>ssign-Mes<sage->1/Name < />Step < > /Res<ponse /Flow F>low nam<e=">my-flow-2<&quo>t; Re<sponse > Step >Condi<tionrespon>se.status.c<ode >= 400/Condition < > Name<Assig>n-Messa<ge-2/Name> < />Step < /Response />Flow < Flow n>ame="<;my->flow-3"<; R>esponse Step > < Condi>tionrespons<e.st>atus.code = 300/<Condi>tion < > NameAs<sign-Mess>age-3</Name> < >/Step < /Response> /Flow /Flows ... /ProxyEndpoint
Apigee executes only one flow in a segment; it executes the first flow which does not have a condition, or whose condition resolves to true.
Attributes
The following table describes the attributes of the <Flow>
element:
Attribute | Type | Description |
---|---|---|
name |
String | (Required) A unique ID for the flow. For example,
My-Conditional-Flow-1 . The name cannot contain spaces or other special
characters. |
Child Elements
The following table describes the child elements of <Flow>
:
Child Element | Type | Description |
---|---|---|
<Condition> |
String | Defines a conditional statement that is processed at runtime. If the statement evaluates to true, then the flow (and all its steps) are executed. If the statement evaluates to false, then the flow (and all its steps) are ignored. |
<Description> |
String | Provides a brief description of the flow. This description is not externally visible. |
<Request> |
Complex object | Specifies steps and conditions for the request segment. |
<Response> |
Complex object | Specifies steps and conditions for the response segment. |
<Flows>
Contains zero or more <Flow>
elements.
Type | Complex object |
Parent Element(s) |
<ProxyEndpoint> <TargetEndpoint> |
Child Element(s) |
<Flow> |
If there are multiple <Flow>
elements within <Flows>
, only one <Flow>
will execute. This
will be the first flow that either doesn't have a <Condition>
, or whose condition resolves
to true.
You can define a default flow that always executes (if none of the other flows do). Depending on how your API proxy is configured, this can be a useful tool in protecting against malicious attacks.
Syntax
The <Flows>
element uses the following syntax:
<Flows name="flow_>nam<e" Flow name="conditi>onal_<flow_name&q>uot; Descrip<tionflow_des>cript<ion/Descr>iption Conditionprope<rty operat>or &q<uot;val>ue"<;/Co>ndition < Reques>t Step Cond<itionprope>rty opera<tor >"value<">;/Condi<tion > Namepol<icy_name>/Name< />Step < >... /<Request > Response Step < Cond>itionprop<erty> operator &<quot;>value&q<uot;/>Condition < Namepo>lic<y_nam>e</Name > /Step ... /Response /Flow /Flows
All child elements of <Flows>
are optional.
Example 1
The following example shows a simple <Flows>
element with a single <Flow>
:
<!-- api-platform/reference/examples/flow-segments/flows-1.xml --> <ProxyEndpoint name="def>aul<t" Flows name="my-con>ditio<nal-flows" > Flow n<ame=&qu>ot;report<s" > Request DescriptionBased on the path suffi<x, determine> which fl<ow t>o use/Descr<iption > Step Conditionproxy.pat<hsuffix Ma>tchesPath &<quot>;/reports&quo<t;/Co>ndition < > NameX<ML-t>o-JSON-1/Na<me > /Step Step Conditionp<roxy.paths>uffix Match<esPa>th "/for<ecast>s"/C<ondit>ion < N>ameVe<rify->Aut<h-1/Na>me < /Step > /Request /Flow /Flows ... /ProxyEndpoint
Apigee executes one of these policies based on the path suffix that it gathers from the
proxy
flow variable. If the path suffix matches neither of the conditions, then
Apigee does not execute this flow.
Example 2
The following example shows multiple <Flow>
elements within <Flows>
, each with its own
<Condition>
:
<!-- api-platform/reference/examples/flow-segments/flows-2.xml --> <ProxyEndpoint name="def>aul<t&quo>t; <Flows Flow name=&>quot;my<-flow-1&>quot; < R>esponse < Step> Conditionrespon<se.status.>code = 200/<Cond>ition <NameA>ssign-Mes<sage->1/Name < />Step < > /Res<ponse /Flow F>low nam<e=">my-flow-2<&quo>t; Re<sponse > Step >Condi<tionrespon>se.status.c<ode >= 400/Condition < > Name<Assig>n-Messa<ge-2/Name> < />Step < /Response />Flow < Flow n>ame="<;my->flow-3"<; R>esponse Step > < Condi>tionrespons<e.st>atus.code = 300/<Condi>tion < > NameAs<sign-Mess>age-3</Name> < >/Step < /Response> /Flow /Flows ... /ProxyEndpoint
Apigee executes only the first flow in a segment whose condition evaluates to true. After that, Apigee skips the remaining flows in the segment.
Example 3
The following example shows a "default" <Flow>
:
<!-- api-platform/reference/examples/flow-segments/flows-3.xml --> <ProxyEndpoint name="def>aul<t&quo>t; <Flows Flow name="my-cond>itional<-flow-1&>quot; < R>esponse < Step> Conditionrespon<se.status.>code = 200/<Cond>ition <NameA>ssign-Mes<sage->1/Name < />Step < > /Res<ponse /Flow Flow name=&qu>ot;my-c<ondition>al-flow-2<&quo>t; Re<sponse > Step Conditionres<ponse.head>er.somehead<er => "42"/<Condi>tion < > NameAs<sign-Mess>age-2</Name> < /Step /Response > /Flo<w Fl>ow name=&<quot>;my-default<-flo>w" Re<spons>e < Step> < NameA>ssign<-Mess>age<-3/Nam>e < /Step > /Response /Flow /Flows ... /ProxyEndpoint
Apigee executes only the first flow in a segment whose condition evaluates to true. If no conditional flows execute, then the third flow in this example (with no condition) executes.
A default flow can be a useful tool in protecting against malicious attacks.
Attributes
The <Flows>
element has no attributes.
Child Elements
The <Flows>
element has the following child elements:
Child Element | Type | Description |
---|---|---|
<Flow> |
Complex object | A flow that defines one possible set of steps within the Conditional Flow. |
<Name>
Specifies the ID of the policy to execute within a <Flow>
.
Type | String |
Parent Element(s) |
<Step> |
Child Element(s) | None |
Syntax
The <Name>
element uses the following syntax:
<Name>policy_name</Name>
Example
The following example shows two policies that are added to flows by their name:
<!-- api-platform/reference/examples/flow-segments/name-1.xml --> <ProxyEndpoint name="def>aul<t" Flows name="my-con>ditio<nal-flows" > Flow n<ame=&qu>ot;report<s" > Request DescriptionBased on the path suffi<x, determine> which fl<ow t>o use/Descr<iption > Step Conditionproxy.pat<hsuffix Ma>tchesPath &<quot>;/reports&quo<t;/Co>ndition < > NameX<ML-t>o-JSON-1/Na<me > /Step Step Conditionp<roxy.paths>uffix Match<esPa>th "/for<ecast>s"/C<ondit>ion < N>ameVe<rify->Aut<h-1/Na>me < /Step > /Request /Flow /Flows ... /ProxyEndpoint
Attributes
The <Name>
element has no attributes.
Child Elements
The <Name>
element has no child elements.
<PostFlow>
Defines the steps to take in the PostFlow of the request and response.
Type | Complex object |
Parent Element(s) |
<ProxyEndpoint> <TargetEndpoint> |
Child Element(s) |
<Description> <Request> <Response> |
The <PostFlow>
element uses the following syntax:
Syntax
<PostFlow name="flow_>nam<e" D>escriptionflow_d<escription/D>esc<ription> Re<ques>t S<tep > Conditionproperty operat<or "v>alue&qu<ot;/>Condition < >Namep<olicy>_name/Name < /Ste>p < ... > /Req<uest> Resp<onse >Step Conditionprope<rty operat>or &quo<t;va>lue"/C<ondit>ion < >Namepolicy_<name/Name> < /Step> ... /Response /PostFlow
Example
The following example shows a PostFlow with steps for both the request and response defined:
<!-- api-platform/reference/examples/flow-segments/postflow-1.xml --> <ProxyEndpoint name="def>aul<t" PostFlow name=&quo>t;my-<postflows&q>uot; Descript<ionMy first >PostF<low/Des>criptio<n > Request< St>ep Condition<request.ve>rb = &quo<t;GE>T"/Condit<ion > <NameL>og-Re<quest-OK>/Name< />Step < /R>equest < Re>sponse Step < > NameSe<t-Res>ponse<-Headers/>Nam<e />Step < /Response >/PostFlow ... /ProxyEndpoint
Attributes
The following table describes the attributes of the <PostFlow>
element:
Attribute | Type | Description |
---|---|---|
name |
String | A unique ID for the flow (unique within the endpoint). For example,
My-PostFlow-1 . The
value cannot include spaces or other special characters. |
Child Elements
The following table describes the child elements of <PostFlow>
:
Child Element | Type | Description |
---|---|---|
<Description> |
String | Provides a brief description of the flow. |
<Request> |
Complex object | Defines the policies to execute during the request's PostFlow. |
<Response> |
Complex object | Defines the policies to execute during the response's PostFlow. |
<EventFlow>
Defines the steps to take in the EventFlow
. EventFlow
is used to support streaming server-sent events. For
more information, see Streaming server-sent events.
Type | Complex object |
Parent Element(s) |
<TargetEndpoint> |
Child Element(s) |
<Description> <Response> |
The EventFlow
element uses the following syntax:
Syntax
<EventFlow name="flow_name" content-type="tex>>t/eve<nt-stream&q>uot; Descrip<tionflow_des>cript<ion/Desc>ription< > Response< > Step < >Namepol<icy_n>ame/N<ame > /S<tep /R>esponse /EventFlow
Example
The following example shows a EventFlow:
<TargetEndpoint name="def>aul<t" EventFlow name="EF-1" content-type>=&quo<t;text/e>vent-st<ream>" < Re>sponse Step < Nam>eRaise-Fa<ult-Cred->Invalid/Name Conditionfault.name< equals &q>uot;inv<alid_>acces<s_token&q>uot<;/Conditio>n < /Step /Resp>o<nse /EventFlo><w >HTTPTargetConnection /TargetEndpoint/pre
Attributes
The following table describes the attributes of the EventFlow element:
Attribute | Type | Description |
---|---|---|
name |
String | A unique ID for the flow (unique within the endpoint). For example,
My-EventFlow-1 . The
value cannot include spaces or other special characters. |
content-type |
String | (Required) Must be set to: content-type="text/event-stream" |
Child Elements
The following table describes the child elements of EventFlow:
Child Element | Type | Description |
---|---|---|
<Description> |
String | Provides a brief description of the flow. |
<Response> |
Complex object | Defines the policies to execute during the response's EventFlow. |
<PostClientFlow>
Defines policies in the ProxyEndpoint that execute only after a response has been returned to the client. These policies typically log messages related to the response.
Type | Complex object |
Parent Element(s) |
<ProxyEndpoint> |
Child Element(s) |
<Description> <Response> |
Syntax
The <PostClientFlow>
element uses the following syntax:
<PostClientFlow name="flow_>nam<e" D>escriptionflow_d<escription/D>esc<ription > Res<pons>e S<tep > Conditionproperty operat<or "v>alue&qu<ot;/>Condition < >Namep<olicy>_name/Name < /Step> < ... /Resp>onse /PostClientFlow
All child elements of <PostClientFlow>
are optional.
Example
The following example shows a simple PostClientFlow that executes a single policy:
<!-- api-platform/reference/examples/flow-segments/postclientflow-1.xml --> <ProxyEndpoint name="def>aul<t" PostClientFlow name="my-p>ostcl<ientflows&q>uot; DescriptionMy first PostClientFlow. Processed after the response is sent< back to the> clie<nt./Desc>ription< > Response< > Step Na<meMes>sage-Lo<gging>-OK/N<ame > /S<tep /Respon>se /P<ostClientFlow<>/span> ... /ProxyEndpoint
Attributes
The following table describes the attributes of the <PostClientFlow>
element:
Attribute | Type | Description |
---|---|---|
name |
String | A unique ID for the flow. The name cannot include spaces or other special
characters. For example, My-PostClientFlow-1 . |
Child Elements
The following table describes the child elements of <PostClientFlow>
:
Child Element | Type | Description |
---|---|---|
<Description> |
String | Provides a brief description of the flow. |
<Response> |
Complex object | Defines the policies to execute during the response's PostFlow. |
<PreFlow>
Defines the policies to execute in the PreFlow of the request and response.
Type | Complex object |
Parent Element(s) |
<ProxyEndpoint> <TargetEndpoint> |
Child Element(s) |
<Description> <Request> <Response> |
Syntax
The <PreFlow>
element uses the following syntax:
<PreFlow name="flow_>nam<e" D>escriptionflow_d<escription/D>esc<ription> Re<ques>t S<tep > Conditionproperty operat<or "v>alue&qu<ot;/>Condition < >Namep<olicy>_name/Name < /Ste>p < ... > /Req<uest> Resp<onse >Step Conditionprope<rty operat>or &quo<t;va>lue"/C<ondit>ion < >Namepolicy_<name/Name> < /Ste>p ... /Response /PreFlow
All child elements of <PreFlow>
are optional.
Example
The following example shows a PreFlow with a request and a response flow defined:
<!-- api-platform/reference/examples/flow-segments/preflow-1.xml --> <ProxyEndpoint name="def>aul<t" PreFlow name=&qu>ot;my<-preFlows&q>uot; Descrip<tionMy first> PreF<low/Des>criptio<n > Request< St>ep Condition<request.ve>rb = &quo<t;GE>T"/Condit<ion > <NameL>og-Re<quest-OK>/Name< />Step < /R>equest < Respons>e Step Conditionresponse.stat<us.code Le>sserThanO<rEqu>als 300/Conditi<on > N<ameLo>g-Respo<nse->OK/Name < /Ste>p Step Conditionrespon<se.status.>code Grea<terT>han 300/Condition < > NameL<og-Re>spons<e-NOT-OK/>Nam<e >/Step < /Response > /PreFlow ... /ProxyEndpoint
Attributes
The following table describes the attributes of the <PreFlow>
element:
Attribute | Type | Description |
---|---|---|
name |
String | A unique ID for the flow. The name cannot include spaces or other special
characters. For example, My-PreFlow-1 . |
Child Elements
The following table describes the child elements of <PreFlow>
:
Child Element | Type | Description |
---|---|---|
<Description> |
String | Provides a brief description of the flow. |
<Request> |
Complex object | Defines the policies to execute during the request's PreFlow. |
<Response> |
Complex object | Defines the policies to execute during the response's PreFlow. |
<Request>
Defines the policies to execute during the request segment of the flow.
Type | Complex object |
Parent Element(s) |
<Flow> <PreFlow> <PostFlow> |
Child Element(s) |
<Step> |
Syntax
The <Request>
element uses the following syntax:
<Request> <Step> <Condition>property operator "v<alue">/Cond<itio>n Namep<olicy>_na<me/Na>me /S<tep ..>. /Request
All child elements of <Request>
are optional.
Example
The following example shows flows defined for the request in both the PreFlow and PostFlow:
<!-- api-platform/reference/examples/flow-segments/request-1.xml --> <ProxyEndpoint name="def>aul<t" PreFlow name=&qu>ot;my<-preFlows&q>uot; Descrip<tionMy first> PreF<low/Des>criptio<n > Request< St>ep Condition<request.ve>rb = &quo<t;GE>T"/Condit<ion > <NameL>og-Re<quest-OK>/Na<me > /S<tep /Request /PreFlow > Pos<tFlow name=>"my-postflow<s" >Descr<iptionM>y first< Pos>tFlow/Des<cription<>/span> Request St<ep > Conditio<nreq>uest.verb = &q<uot;G>ET"<;/Con>ditio<n > N<ameLog-Re>quest-O<K/Name />Step /Request /PostFlow ... /ProxyEndpoint
Attributes
The <Request>
element has no attributes.
Child Elements
The following table describes the child elements of <Request>
:
Child Element | Type | Description |
---|---|---|
<Step> |
String | Specifies a policy to execute within the request segment. This type of child can appear multiple times. |
<Response>
Defines the policies to execute during the response segment of the flow.
Type | Complex object |
Parent Element(s) |
<Flow> <PreFlow> <PostClientFlow> <PostFlow> |
Child Element(s) |
<Step> |
Syntax
The <Response>
element uses the following syntax:
<Response> <Step> <Condition>property operator "v<alue">/Cond<itio>n Namep<olicy>_na<me/Na>me /S<tep ...> /Response
All child elements of <Response>
are optional.
Example
The following example shows flows defined for the response, in both the PreFlow and PostFlow:
<!-- api-platform/reference/examples/flow-segments/response-1.xml --> <ProxyEndpoint name="def>ault&<quot; PreFlow name=&qu>ot;my-pre<Flows"> Descrip<tionMy first> PreFlow/<Descript>ion R<espo>nse S<tep > Conditionresponse.status.code Le<sserThanOr>Equals 300/Condit<ion<>/span> < Name>Log-Response-<OK/Na>me < /S>tep S<tep > Conditionresponse.status.<code Great>erThan 300/Condit<ion<>/span> Nam<eLog->Response-NOT-<OK/Na>me < /St>ep < /R>espon<se /PreFlow PostFlow> name=&qu<ot;my-postf>lows" < Descriptio>nMy first< PostFlo>w/Description< > Response < > Step < > NameSet-Resp<onse->Headers/N<ame > < /Step > </Response >/PostFlow ... /ProxyEndpoint
Attributes
The <Response>
element has no attributes.
Child Elements
The following table describes the child elements of <Response>
:
Child Element | Type | Description |
---|---|---|
<Step> |
String | Specifies a policy to execute within the response segment. This type of child can appear multiple times. |
<Step>
Specifies a policy to execute and (optionally) a condition that determines whether to execute that policy.
Type | Complex object |
Parent Element(s) |
<Request> <Response> |
Child Element(s) |
<Condition> <Name> |
There can be more than one step defined in a <Flow>
, and the steps are executed in the
order in which they are defined in the flow's XML.
Steps without a condition always execute. Steps with a condition execute only if the condition evaluates to true. If the condition evaluates to false, then Apigee skips the step.
Syntax
The <Step>
element uses the following syntax:
<Step> <Condition>property operator "v<alue">/Co<ndit>ion Namep<olicy>_<name/>Name /Step
There can be only one <Condition>
and one <Name>
per <Step>
, but there can be
multiple steps in a <Flow>
.
All child elements of <Step>
are optional.
Example 1
The following example shows one step with a condition and one step without a condition:
<!-- api-platform/reference/examples/flow-segments/step-1.xml --> <ProxyEndpoint name="def>aul<t" PostFlow name=&quo>t;my-po<stflows&quo>t; Descript<ionMy first >PostFlo<w/Descr>iption < Re>quest < Step > Condition<request.ve>rb = "GET&<quot>;/Condition < > Name<Log-R>equest-<OK/Name<>/span> < /Step> /Req<uest> Response< > Step < > NameSet-Re<spons>e-Heade<rs/Name > < /St>ep < /Response >/PostFlow ... /ProxyEndpoint
The step without the condition will execute every time during the request segment. The step with a condition will execute only when the request is a "GET" during the response segment.
Example 2
The following example shows multiple steps in a single segment:
<!-- api-platform/reference/examples/flow-segments/step-2.xml --> <ProxyEndpoint name="def>ault&<quot; PostFlow name=>"Pos<tFlow&qu>ot; R<espo>nse S<tep<>/span> <NameA>ssign-Message<-1/Na>me < /S>tep S<tep<>/span> <NameA>ssign-Message<-2/Na>me < /St>ep < /Re>sponse < /PostFlow > ... /ProxyEndpoint
Steps without a condition always execute.
Attributes
The <Step>
element has no attributes.
Child Elements
The following table describes the child elements of <Step>
:
Child Element | Type | Description |
---|---|---|
<Condition> |
String | Defines a conditional statement for the step that is processed at runtime. If the statement evaluates to true, then Apigee executes the step. If the statement evaluates to false, then Apigee skips the step. |
<Name> |
String | Specifies the ID of the policy to execute in the current flow. |