A reasonably new change is this:
Migrate Solution Kits - CA API Gateway - 9.2 - CA Technologies Documentation
What exactly is the point of this ? I've read the docs from top to bottom and it is completely unclear.
What does this add ?
If I have a working configured dev GW for example, with an installed OTK, all configured for dev, integrated with the customers systems - all customised, etc as required what I WANT to be able to do is treat this absolutely no differently from any other policies/config I am migrating to a higher environment (e.g. TEST).
Now I know this works, as I've done exactly that before, migrating the OTK, selected APIs, etc that I want to be moved to TEST and GMU does what I expect it to do.
I can then template it, make whatever changes I need in there, or occasionally after migration (JDBC connection, etc).
The result works fine.
I can't see what you are trying to achieve with this separate contrived model of migration ? Is it because some solution kits, like the MAG include custom assertions and would otherwise not work through GMU ?
Even i that IS the case, I fail to see what problem you are trying to solve here ?
I realise you want to constrain changes to user configurable sections of policy - but there still seems no benefit to your method -
1. they HAVE constrained there DEV changes to user configurable sections, and therefore they end up with DEV and TEST syned after the migration (as they would in the old model of pulling it out with GMU)
2. they had to make some change NOT in the configurable sections, in which case it is FUNDAMENTAL to the successful migration that this change IS migrated to TEST, and your solution will in fact not work at all.
I really don't think this has been thought through very well.
The main thing that the workflow detailed in the Migrate Solution Kits - CA API Gateway - 9.2 - CA Technologies Documentation adds is that the solution kit entities themselves get migrated. If you follow those steps and then go into manager solution kits dialog you will see the same solution kits on both the source and target gateways. This will also migrate the 'readonly-ness' of entities.
If neither of these is important in your scenario then the migration workflow that you mention above is another approach you can follow for migrating solutions from one gateway to another.
So I've had a chance to try this out - and I can confirm, that it really does appear to add nothing as far as I can see.
I did a gmu export from my source GW of all and solution kits.
I did a gmu import to my target GW.
It worked fine, all the policies are there. Under Solution Kits, the two solution kits show fine (OTK and MAG), AND the 'readonly-ness' of the entities has been maintained.
So as far as I can see there is no scenario where the documented workflow adds any value whatsoever ?
I know that one of the benefits of migrating Solution Kits between environments is that the unique IDs of the entities stored on the gateways will be the same between each environment. This makes migration using the GMU easier, as by default the GMU will map by these unique IDs.
Were you able to export with the output format specified as 'directory' (instead of the default single file)? I keep getting an error.
Here is how I export:
java -jar gmu/GatewayMigrationUtility.jar migrateOut \
-format directory \
-defaultAction NewOrUpdate \
-z ~/Documents/api-gateway-config/connection-dev.properties \
It runs successfully for a long time, but I think the error comes when it tries to make the mapping.xml or dependencies.xml files. I get this error:
Execution failed. Reason: No bean named 'SCHEDULED_TASKBeanTypeEntityResource' is defined.
If I remove '-format directory' as an argument, it works. But I'm controlling my config in git and would prefer separate files/folders so it's easier to see what's changed before I perform a git commit.
Looks like there might be a version mismatch issue. What version of GMU and Gateway are you trying this with?
I can confirm this was resolved by upgrading to the newest version of the gmu tool. I think i was on version 1.2 or 1.3, but upgrading to 1.5 fixed my errors.