Flow in Default-Proxy-Endpoint is not executed

I created an additional Flow in my default proxy endpoint. It is displayed between PreFlow and PostFlow. I actually want it to be conditional to add the CORS headers when the request verb is OPTIONS. However, it is never executed. I even tried to comment out the condition. But even then, it is not executed when I call the endpoint and trace it. I have no idea, why. Any hints are really appreciated.

Here is the XML for the default proxy endpoint:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ProxyEndpoint name="default">
    <Description/>
    <FaultRules/>
    <PreFlow name="PreFlow">
        <Request/>
        <Response/>
    </PreFlow>
    <Flows>
        <Flow name="OptionsPreFlight">
            <!-- <Condition>request.verb == "OPTIONS" AND request.header.origin != null AND request.header.Access-Control-Request-Method != null</Condition> -->
            <Request>
                <Step>
                    <Name>add-cors</Name>
                </Step>
            </Request>
            <Response/>
        </Flow>
    </Flows>
    <PostFlow name="PostFlow">
        <Request/>
        <Response/>
    </PostFlow>
    <Flows/>
    <HTTPProxyConnection>
        <BasePath>/olp</BasePath>
        <Properties/>
        <VirtualHost>default</VirtualHost>
    </HTTPProxyConnection>
    <RouteRule name="NoRoute">
        <Condition>request.verb == "OPTIONS"</Condition>
    </RouteRule>
    <RouteRule name="default">
        <TargetEndpoint>default</TargetEndpoint>
    </RouteRule>
</ProxyEndpoint>
Solved Solved
0 2 289
1 ACCEPTED SOLUTION

1. </Flows>

<PostFlowname="PostFlow"><Request/><Response/></PostFlow>

2. <Flows/>

You are closing Flows twice thats the reason your flow is not getting executed.

View solution in original post

2 REPLIES 2

1. </Flows>

<PostFlowname="PostFlow"><Request/><Response/></PostFlow>

2. <Flows/>

You are closing Flows twice thats the reason your flow is not getting executed.

Thanks a lot! You were right, it's working correctly now. I thought this kind of error would be caught by the schema validation.