LinkedIn
Twitter
Note - The below features of Shared Flows and Flow Hooks are part of Edge 17.01 private cloud release and will be soon (very soon!) available on our public cloud for consumption.
Shared Flows
What is a shared flow and how can I create one?
A shared flow is simply a sequence of policies, ideally covering a specific functionality that can be referenced and re-used by API proxies. Think about it as reusable, common logic that is shared across your API proxies. It is important to note that the shared flow and policies can change independent of the API proxy that is using it.
Demonstration Video -
Don't quiet like watching demo videos? No worries!
Follow the documentation and screen shots below 🙂
As you can see a shared flow is very similar to an API Proxy. In terms of its development and deployment life cycle, schema, structure etc. it is exactly like an API proxy. However unlike an API Proxy, a Shared Flow does not have proxy or target endpoints, as it can not be directly called like an API Proxy. It also does not have other facets like virtual host’s, pre, post (req/res) and conditional flows, route rules etc.. like an API Proxy.
OK, I get it. So a Shared Flow is similar an API Proxy, but not exactly an API Proxy. It needs to be used, re-used and referenced from an API Proxy. But how can I do that?
Shared Flow’s can be referenced from an API Proxy using a NEW policy called “FlowCallout”. Which simply calls out and executes everything that is developed under the shared flow which is called.
Like any other policy you can put the FlowCallout policy in any flow where you want it to execute.
The policy schema is simple most of the things gets populated based on selections from the UI.
Once the proxy is deployed, the FlowCallout policy will execute the policies/code in that shared flow. Below is how the trace session looks, very much as if those policies were directly developed on that particular API Proxy.
Yes, the variables set in the policies of the shared flow will be available in the API Proxy and vice versa.
Who should use this feature?
This feature is an awesome way to share common and best practices within and across different development teams. It will simplify the use of tools like our open sourced ‘Maven dependency plugin’ which is commonly used to achieve code re-use during the build cycle. Shared flows enable this type of reuse directly in the product.
When should one consider using this feature?
One should use Shared Flows for everything that can be represented as reusable policie's grouped as a sequence of stepsflow fragments and referenced as common best practices. Some common examples are security, traffic management, logging, common orchestration and mashup flows, custom a/x , monetization flows etc
Flow Hooks
What are Flow Hooks and how can I create one?
Above we saw how we can create templates in shared flows and how we can reference those from an API Proxy using the FlowCallout policy. Think of Flow Hooks as a way to ENFORCE one or more of the Shared Flows to ALL the API Proxies running in a particular environment. This gives you a separately implemented and deployed sequence of logic that is are part of a proxy's implementation code (either directly or referenced through a flowCallout policy).
Flow Hooks are available under the environment configurations, same place where we manage caches, KVM etc. Under a particular environment all the deployed Shared Flows will appear in the drop down.
So put simply, Flow Hooks are merely a way to “hook” existing Shared Flows to a particular “flow” across all proxies in an environment.
Demonstration Video -
Follow the below documentation and screen shots if you are not into watching videos.
Enforcement Points -
Pre-proxy Flow Hook - for logic that needs to be enforced BEFORE a proxy endpoint executes for ALL API Proxies deployed to that environment.
For example, you could have logic for enforcing security across all the APIs in an environment.
Pre-target Flow Hook for logic that needs to be enforced right BEFORE reaching out to a target backend for ALL API Proxies deployed to that environment.
For example, you could implement logging before the request reaches the backend. You could also enforce mediation by removing certain fields from the request.
Post-target Flow Hook for logic that needs to be enforced BEFORE the API Proxy response executes for ALL API Proxies deployed to that environment.This will be enforced right after the response comes back from the backend. You can use it to log the backend response or perform some mediation by removing sensitive fields from the backend response.
Post-proxy Flow Hook for logic that needs to be enforced AFTER the proxy endpoint and right before the response is sent out to the client for ALL API Proxies deployed to that environment.
This could include some enforcement logic for CORS, logging the response, or performing some mashup or formatting.
How would the enforcements under Flow Hooks impact the runtime APIs for that environment?
Well in most simplistic terms- they are executed on calls to ALL APIs deployed in that environment. Below is how a trace session will look like -
Imagine that you have one team managing a single set of security requirements for multiple teams that represent different lines of businesses (LOBs). Each LOB team can develop APIs according to their own requirements, and without needing to account for the broader security requirements. The security team can implement those security requirements in a shared flow, then attach the flow to the Apigee Edge environment using a flow hook. Because the shared flow isn't part of proxy code, the security team can revise it as needed without interfering with LOB code.
