Hello,
I want to control whether a Shared Flow with multiple steps in it, to execute all the steps or none of the steps, based on a condition.
I know I can achieve this by adding the same condition in each of the steps in the Shared Flow, as below:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <SharedFlow name="Check API Key"> <Step> <Name>Get-API-Key-From-Secret-Store</Name> <Condition>(proxy.pathsuffix Not MatchesPath "/health")</Condition> </Step> <Step> <Name>Check-API-Key</Name> <Condition>(proxy.pathsuffix Not MatchesPath "/health")</Condition> </Step> <Step> <Name>Raise-Fault-incorrect-API-key</Name> <Condition>(proxy.pathsuffix Not MatchesPath "/health") and (apicheck.status.code == 403)</Condition> </Step> </SharedFlow>
However, it is possible to pull the condition that tests the proxy.pathsuffix out of each step and specify it just once? The below doesn't seem to work:
<SharedFlow name="Check API Key"> <Condition>(proxy.pathsuffix Not MatchesPath "/health")</Condition> <Step> <Name>Get-API-Key-From-Secret-Store</Name> </Step> <Step> <Name>Check-API-Key</Name> </Step> <Step> <Name>Raise-Fault-incorrect-API-key</Name> <Condition>(apicheck.status.code == 403)</Condition> </Step> </SharedFlow>
Solved! Go to Solution.
No, that won't work.
I understand exactly what you're intending, but it won't work.
The sharedflow is the unit of re-use, so one way to get what you want is to wrap the FlowCallout in a condition.
<Step> <Name>FlowCallout-Call-SharedFlow-1</Name> <Condition>(proxy.pathsuffix Not MatchesPath "/health")</Condition> </Step>
But I understand that is semantically different from including the condition inside the sharedflow. In the latter case, the sharedflow implementation gets to decide whether to execute a step. In the former case, the caller must decide.
If you're not comfortable with those options, remember you can nest sharedflow calls. So a Sharedflow might itself include a flowcallout. You could embed the three (or N) policies that all should be condiitonally executed into a separate sharedflow, and then wrap the condition around the flowcallout in the "parent" sharedflow.
That can get to be a bunch of extra overhead if you have a long series of such cases. You can have sharedflow proliferation.
I wonder if there is a need for, or room for, a super-language, like SCSS is for CSS, where we could use the syntax you suggested (which uses a toplevel condition), run it through a pre-processor, and then arrive at an Apigee-compliant syntax that includes the Condition element on each step.
I don't know if anyone has ever tried that.
No, that won't work.
I understand exactly what you're intending, but it won't work.
The sharedflow is the unit of re-use, so one way to get what you want is to wrap the FlowCallout in a condition.
<Step> <Name>FlowCallout-Call-SharedFlow-1</Name> <Condition>(proxy.pathsuffix Not MatchesPath "/health")</Condition> </Step>
But I understand that is semantically different from including the condition inside the sharedflow. In the latter case, the sharedflow implementation gets to decide whether to execute a step. In the former case, the caller must decide.
If you're not comfortable with those options, remember you can nest sharedflow calls. So a Sharedflow might itself include a flowcallout. You could embed the three (or N) policies that all should be condiitonally executed into a separate sharedflow, and then wrap the condition around the flowcallout in the "parent" sharedflow.
That can get to be a bunch of extra overhead if you have a long series of such cases. You can have sharedflow proliferation.
I wonder if there is a need for, or room for, a super-language, like SCSS is for CSS, where we could use the syntax you suggested (which uses a toplevel condition), run it through a pre-processor, and then arrive at an Apigee-compliant syntax that includes the Condition element on each step.
I don't know if anyone has ever tried that.
Yes, I did try the conditional at the point of invocation in the API proxy, however, discarded it as I end up having to code that for all the proxies, negating the benefit, somewhat, of a SharedFlow.
I think the approach of a per step is easier for this situation, and I don't need the Flow->SharedFlow->SharedFlow approach, though it sounds viable.
Thanks for the quick response and answering the question.