Changing policy code of all proxies in one go

[Aravind]

• Hi Team,

We need to change the code inside the message logging policy in all the proxies to add a new flow variable..Is there any way/method to update the code in all proxies which contains message logging policy in one go.

Lets say i have 10 proxies with message logging policy.. instead of changing in every proxy..is there any way to change in all 10 proxies in one go.

Thanks in advance!

[dchiesa1 · Accepted solution]

Yes.

A best practice for this sort of thing is using "Shared Flows" in Apigee. A Shared flow is a named sequence of policies that can be re-used in any number of proxies. 

So you can have proxy1,2,3...proxy10 .... all calling out to SharedFlow1.  Within SharedFlow1, you configure the MessageLogging policy.  Then you just need to update the SharedFlow1, modify that one policy, redeploy, and then all of the proxies that call to the sharedflow will get that update. Logging is a really common thing to embed into a SharedFlow.  It is used by every proxy and most people want all proxies to do the same kind of logging. 

There is a related feature in Apigee called "Flow hook".  This is a way to mandate that all proxies invoke a particular SharedFlow. If you attach SharedFlow1 to a flowhook, then all proxies (proxy1,2,3...proxy10) will implicitly and automatically invoke SharedFlow1. Which means if you update  any policy within SharedFlow1, all proxies will immediately get that behavior. 

You can google for documentation on Shared Flows and Flow hooks to get the full gory details.

If you do not have Sharedflows set up for your logging policies, then.... the answer is "NO" there is no way to modify 10 unrelated policies in one go. Even if each MessageLogging policy is the same, effectively you have copy/pasted the policy configuration so they are all independent as far as the Apigee management model is concerned. 

But! There may yet remain some hope!  Another related "best practice" is to use source code repos to contain your API Proxy configuration offline, and then use an automated toolchain to deploy proxies from those source code repos. If you are following this practice, then "modifying 10 policies in 10 different proxies" amounts to a find/perl task.  You can modify all the MessageLogging policies using standard shell tools, and then just kick your continuous deployment script, and everything gets updated.  It's NOT a best practice to use copypasta in your policies across different proxies; use sharedflows for that. But if you haven't yet embraced sharedflows, and you DO have your proxy config stored in your filesystem backed by source code control repositories, then this way of mechanizing the update of a policy via find piped through perl... would be a good second-best approach.      

[Aravind]

Thank you Dino your quick reply..

I started working of yours first point which is messaging logging policy inside the shared flow..Attaching that shared flow to flowhook ..in this case i observed one flow variable is not reflecting which is "client sent.end.time"..is there any way to pull this flow variable..

Can we use shared flow(which contains message logging policy) inside the post client flow?

Thanks in adavance

[dchiesa1]

At this time there is no FlowHook for post client flow. The team has a feature request in the backlog and is working on it.  We understand the value here. 

the reason you don’t see the end time variable is because that variable is not yet set during post flow. you probably already understood that!