What do you do for policy migration?

[StPaulPete]

What does the community do for policy migration?

 

I'm just wondering what other API Gateway users do for policy/service migration across clusters (like dev to QA, etc)?  Do you use GMU, manual export/import, ESM?

 

We have ESM but find it somewhat unreliable for certain things and understand it to effectively be a deprecated product.  Does anyone know what its status is?

[Victor Kazakov]

Hi StPaulPete,

I can't entirely speak for the full community but some of the more successful implementation I've seen have been done using GMU or RESTMAN directly. A newer approach would be to use the Gateway Developer Plugin.

 

The process we are promoting is to use a version control system to hold your Gateway configuration (GMU/Restman/Gateway-Developer/Plugin export). For example:

1. develop in your development environment
2. export using GMU
3. commit that export into a version control system (Git, SVN, etc...)
4. Update your other environment from the contents of the version control system.

 

Some of the benefits of this process are that you can:

• Setup automation and automated deployment when there is an update to the version control system
• There is a single source of truth for policies in the version control system
• It follows modern dev-ops practices and allows you to use some standard build/deployment tooling. (Jenkins, Ansible, etc..)

 

We currently are not investing too many resources into ESM and would recommend the above process instead of using ESM.

Take a look at this blog post for some details on Developing with the API Gateway

[Philippe Brand]

We are using our custom graphical tool, based on in-house developped framework around RESTman/WSman to migrate API from Dev/Sandbox to higher environments such as UAT/Production.

 

example to export single policy, asking for mappings interactively:

$ /usr/local/bin/migrate.sh -s "apiref-eu-int.sanofi.com:/OTK/Customizations/persistence/OTK Client DB GET Extension" --policy -d apiref-eu-ext1.sanofi.com --exportonly --mappings -b /APPS/PROMISE-CRQ/PhB/toto.xml

 

Then modify each item accordingly and remove some:

 

and then import:

# /usr/local/bin/migrate.sh -s "apiref-eu-int.sanofi.com:/OTK/Customizations/persistence/OTK Client DB GET Extension" --policy -d apiref-eu-ext1.sanofi.com --importonly --noninteractive -b /APPS/PROMISE-CRQ/PhB/toto.xml

[StPaulPete]

You should market that.  :-)  We've thought of doing something similar, but why should we develop our own graphical tool when we pay for ESM to provide that?  Having a graphical tool is useful because we can move the task into an operations area where admins can do it without having to learn complex GMU commands.

[Ben.Deutsch]

I export/import policy fragments (through their parent policy) and encapsulated assertions so that these objects maintain their GUIDs.  This allows for copy/paste of service policies, with the occasional remapping of FIPs (but those are mostly referenced via fragment or encap assertion).

All of our environment specific properties are abstracted into the fragments and encap assertions.  This makes the service policies the same in all of our environment levels and we can just copy/paste policies back and forth.  Even JDBC connections map by name and so as long as the name is the same from one environment to the other there is no re-mapping required.