We are just starting out with the shared flows at our organization.
Just wanted to understand from the experts within the community about the shared flow behavior and its lifecycle w.r.t. to an api proxy.
Shouldn’t API proxy fail at deploy time if a referenced shared flow(s) is NOT available/deployed in the target environment rather than failing at run time ?
Should we not treat a shared flow(s), just like any other environment level configuration (Target Server. KVM, Cache). What would be use case where we should treat it any differently ?
Should we even version the shared flow bundles to manage its lifecycle ?
My questions are more specific from an enterprise customer perspective, as we have plethora of Apigee Edge orgs./envs.
#1 You can undeploy a shared flow even if it’s referenced in APIproxies. #2 You can deploy the APIproxy when there is no shared flow deployed even with validate=true op which is not same for environment/org-entities. #3 It is always good to maintain versions for shared flows like we do for APIproxies as we keep updating them.
I think for now we will have to write something custom to validate sharedflows during the deploy time.
What was the reasoning/logic behind not having the validations for the sharedflows during deployment ?
Will sharedflow validations during deploy time be part of future product enahancement ? If not, we would be more than happy to put in a feature request
@Maruti Chand I am in the same situation as the OP of this post. Has there been any development in this case where i can check if the referenced shared flows are deployed or not while deploying an apiproxy?
I tried to figure out if i can use maven to overcome this situation but unable to find any solution either.