Layer7 API Management

Expand all | Collapse all

Emulating ESM mapping in GMU

Jump to Best Answer
  • 1.  Emulating ESM mapping in GMU

    Posted 03-29-2018 03:42 PM

    I am experimenting with GMU as a potential replacement for ESM.  ESM identifies and notifies you of potential dependencies/mappings prior to migration.  So far, I've not come up with a way to do this in GMU.  In fact GMU's idea of "dependencies" don't seem to align with ESM's function.  I'm rudimentarily familiar with the manageMappings option of GMU, but not finding it very useful so far.  This is best illustrated by example.

     

    The most common thing we have to map when migrating up our SDLC chain is service policy routing URL's.  For example, a routing in a development level service might be https://devsystem.blah.com, while the QA level is https://qasystem.blah.com.  ESM identifies this as a dependency and notifies you of it, allowing you to modify it for migration.  How do I do this with GMU.  When I did a simple test migration it didn't even look like GMU recognizes the routing in its "dependencies".  All I got was the default private key associated with the routing, which I don't need and can't see why I'd ever want it since the destination gateway will have its own default ssl key for routings.  So...

     

    1.  How do I identify routings in a migration?

    2.  How do I change the value of the routing URL so migrateIn will set it accordingly?

     

    If we can't do these things then GMU is pretty much useless as a procedural administrative tool.  We can't give it to our publisher staff and expect them to use it effectively.  Having to log in to the destination gateway after migration and changing values is not a good option at all.  It risks things running in the interim with incorrect settings.



  • 2.  Re: Emulating ESM mapping in GMU
    Best Answer

    Posted 03-07-2019 01:53 PM

    Good afternoon,

     

    The template functionality of the GMU will provide the functionality that matches what the ESM did for mapping properties. Within the template properties file you can modify it to have the variance used for each environment. template command - CA API Gateway - 9.3 - CA Technologies Documentation 

     

    Another option that we recommend is using cluster wide properties (CWP) in the HTTP Routing assertion which can then we modified easier in the migration. An example could be to have the host in a variable called ${gateway.http.hr} and set the value to https://hr.example.com with the rest of the URL either as another CWP or just typed out in the HTTP Routing assertion. We discuss this and other topic to help with how policies are developed in Thinking in Policy - CA API Gateway - 9.3 - CA Technologies Documentation 

     

    Sincerely,

     

    Stephen Hughes

    Broadcom Support