group steps by conditions

Giupo · 02-23-2023 05:50 AM

Hi everyone,
I have read in this discussion that it is not possible to group several steps on a single condition (except in condition flow), do you know if there is an improvement of the product in this sense?

I have so many scenarios where we have to repeat the condition over 10 times, for example:

            <Step>
                <Condition>prelogin = true and response.status.code = 200</Condition>
                <Name>ExtractVariable_Field</Name>
            </Step>
            <Step>
                <Condition>prelogin = true and response.status.code = 200 and field = null</Condition>
                <Name>RaiseFault_MissingField</Name>
            </Step>
            <Step>
                <Condition>prelogin = true and response.status.code = 200</Condition>
                <Name>JWT_Encrypt</Name>
            </Step>
            <Step>
                <Condition>postlogin = true and response.status.code = 200</Condition>
                <Name>AM_Set-Cookie</Name>
            </Step>

I know you recommend using shared flows, but we already have about 20 shared flow, if we add more we are forced to remove proxies from the environment.

for example, if the backend returns me a status other than 200, how can I forward the response directly to the client without having to compare all these conditions?

apickelsimer

It's not clear exactly where you have configured the above Steps and policies. If the target server responds back with a non 200 response, then the proxy automatically enters a fault flow. This means that policies that are configured within the Response portion of any flow are automatically skipped. By default, Apigee treats HTTP code 4XX or 5XX as errors, and it treats HTTP code 1XX, 2XX, 3XX as success ( see docs on how to modify this behavior ). Also, you should consider using Fault Rules to catch the errors and have a uniform and consistent error handling approach, rather than passing the backends error response back directly.

Giupo

Hello,
The above conditions are configured in the ProxyEndpoint Response Preflow.
We need Apigee not to modify the backend error messages, so we set in the target endpoint:

<HTTPTargetConnection>
        <Properties>
            <Property name="success.codes">1xx,2xx,3xx,4xx,5xx</Property>
        </Properties>
</HTTPTargetConnection>

apickelsimer

Can you share exactly how Apigee is modifying the backend error messages? By default this is not the behavior. Apigee will pass through the backend error message unaltered.

Modifying the `success.codes` property will make actual errors appear as successful when viewing analytic reports and dashboards. This is likely not the behavior you want.