What are the advantages of using shared flows?

Google Cloud Apigee
1

Hello,

I came across the documentation for shared flows and would like to hear from anyone that has used or is using shared flows.

Currently, we achieve a similar result with a Common API that has flow fragments injected into the proxy at build time.

However, it does mean that each new proxy requires us to go through the same steps each time to add in these common/shared flows and we enforce this through reviews of pull requests.

Shared flows (with flow hooks) look as though they may save us some time in both proxy configuration and enforcement of some features that we’d like on all proxies.

If you have used shared flows, what advantages or disadvantages have you found over other methods? What other methods do you use?

It’s not clear from the docs but I’m guessing that faults are handled by the proxy calling the shared flow callout?

1 Like
2

Neil - Thanks for asking some very good Q’s!

Shared Flows gives you an ability to share and reuse best practices across different API proxies and even across different teams. You may be currently achieving some kind of code reusability through flow fragments at deploy time injecting code at appropriate places. With shared flows this will happen at runtime(through flow callouts) and you would have all your best practices avail under env config–> shared flows rather than hidden in some common proxy which could not even be deployed. Above everything this feature comes straight out of product so it has its own advantages. Other advantages for some enhanced use cases is that it can be nested, meaning you can call one shared flow from another by including a flow callout within a shared flow.

Shared Flows when applied to flow hooks at hook points gives you enforcement. This is specifically advantageous to LOB’s like security who might not be directly responsible for developing and managing API proxies. Lets say that some proxies are deployed in production and later a security expert wants to enforce certain things like threat protection policy to ALL and ANY proxy running in production. This can be achieved through flow hooks by attaching security shared flows to a point in production environment. This could be achieved by just one configuration without even touching a single proxy code running in production and it would still enforce every prod call to check for threat protection.

You are correct faults could be handled by the proxy calling the flow callout. However you could also raise a fault using the raise fault policy within a shared flow and raise an exception there.

I hope this helps. I will soon be posting a video which might help understand the use cases and scenarios better.

Thanks!

Vinit

2 Likes
3

@Vinit Mehta

Thanks for your reply - looking forward to the video.

What approach would you recommend for building and testing? Should the shared flow be treated as a standalone “API” for deployment and testing?

4

Hi @Neil Munro,

If you are using Maven (which I believe you are!), there is currently a ticket to add support for shared flows. You can find this here: https://github.com/apigee/apigee-deploy-maven-plugin/issues/67

Once this has been implemented, I believe we will review our build/test approach. We will want a ‘Common API’ where developers can implement their shared flows. Additionally we will want to separate our integration tests, so that when a change is pushed for a shared flow, we run the tests for all APIs using these flows.

Keep an eye out for new versions of the Maven plugin, and we can investigate then!

Many thanks,

Sean

5

@Neil Munro Check out all the details and the videos in the article here - https://community.apigee.com/articles/36809/shared-flows-and-flow-hooks-concepts-technical-det.html

6

@Vinit Mehta

Hi vinit,

I did a scenario on this shared flow.

Created a shared flow which is deployed in test environment and using this shared flow in my proxy which is deployed in prod environment.

while tracing what i observed is the url is getting hitted 5-6times with a difference of 4-5ms and an error is populated in a dialoque box above stating “you are hitting the wrong url”.

how should i populate the error stating that your shared flow is deployed in test environment and ur proxy is deployed in prod environment,Hence policy fails

OR

“Different environment deployement”