Layer7 API Management

Hi,

I am using GMU to migrateIn a service to the target gateway for an already deployed service. However, do not see the change in Cluster-Wide Properties. But if I delete the Cluster-Wide Properties and the service, then run the GMU -migrateIn command, i can see the Cluster-Wide Properties with new value and the service deployed to gateway.

Following are the steps:

1.  migrateOut the service to generate bundle.xml

   GatewayMigrationUtility.bat migrateOut --argFile gatewayprop.properties --dest "sampleServiceAPI.xml" 

   --serviceName /test/sampleServiceAPI

2. templating the sampleServiceAPI.xml and create a template.properties file

   GatewayMigrationUtility.bat template --bundle sampleServiceAPI.xml --template template.properties

3. Manually updated the template.properties file with new value to a Cluster-Wide Properties

4. migrateIn with --template option to deploy it.

GatewayMigrationUtility.bat migrateIn --argFile gatewayprop.properties --bundle sampleServiceAPI.xml --template template.properties --destFolder /test/sampleServiceAPI

need your support here to understand if --migrateIn command will update the existing service. Do i have pass any other parameter in --migrateIn command to overwrite the existing service.

Thanks.

Hey rdas4,

you'll need to consider the mapping action of the entities as well. By default, when you migrateOut, the mappingAction is "NewOrExisting", meaning the entity will be created on the destination if it doesn't exist, and if it does exist, map to said entity, but don't update it.

there are a few ways to get that guy updated, 

first, we can use the manageMappings command to target the cluster wide property, using something like the following,

./gmu.sh manageMappings -b Bundles/mybundle.xml -t CLUSTER_PROPERTY -a "NewOrUpdate"

//this will target all cluster wide properties in the bundle and modify the action to "NewOrUpdate" and they will be ready to overwrite the destination values upon import.

the other method that comes to mind is on the 'migrateOut' operation, we have an option to change the default action of all the entities,

--defaultAction <action> Default mapping action: [NewOrExisting,NewOrUpdate,Ignore]default=NewOrExisting

so something like the following

./gmu.sh migrateOut -z args/Gateway1.args --serviceName /blah --dest ./Bundles/blah.xml --defaultAction "NewOrUpdate" 

(something like this )

all entities in the bundle will now be ready to overwrite upon the destination import.

hope this helps,

Doyle

Hi Doyle,

Thanks for your quick response and solution.

I have opted for the second option to change the defaultAction while migrateOut the API to .xml. It is working now.

Thanks again.

Regards,

Rashmi

Thanks, I will be testing this method but in slightly different way. We need to be able to update the policy on the target gateway without having to worry or changing the cluster wide property between environments for existing policies. 

I am assuming the following will work - 

1. Export the bundle with defaultaction set to "NewOrUpdate"

2. Then change the bundles CWP action to "ignore"

3. Import the policy to target gateway.

Any advice would be great.

Kind Regards

Dinesh

Be careful with ignore, but i think specifically for the CWP use-case you'll be fine, as CWP's are just referenced as strings, but if there was an object relationship ( i.e.  JDBC Connection, JMS, SSO, etc.. ), the mapping may not be updated on the target, causing u to login and select the dropdown to select the target object.... 

I believe the general recommendation would be to use 'NewOrExisting' in this case, so that it will map to the existing entity, but not necessarily modify it.

hope this helps,

D