Layer7 API Management

Expand all | Collapse all

What do you do for policy migration?

  • 1.  What do you do for policy migration?

    Posted 05-25-2018 12:01 PM

    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?

  • 2.  Re: What do you do for policy migration?

    Posted 01-02-2019 02:22 PM

    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

  • 3.  Re: What do you do for policy migration?

    Posted 01-04-2019 10:54 AM

    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/ -s " Client DB GET Extension" --policy -d --exportonly --mappings -b /APPS/PROMISE-CRQ/PhB/toto.xml


    Then modify each item accordingly and remove some:


    and then import:

    # /usr/local/bin/ -s " Client DB GET Extension" --policy -d --importonly --noninteractive -b /APPS/PROMISE-CRQ/PhB/toto.xml

  • 4.  Re: What do you do for policy migration?

    Posted 01-11-2019 09:30 AM

    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.

  • 5.  Re: What do you do for policy migration?

    Posted 01-10-2019 02:26 PM

    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.