We are working on the migration of some services that rely on generic policies using the GMU. Those generic policies are available on both environments, having the same contents, having the same name and having the same path. The only difference is their ID.
This causes me some headache with the GMU. Mapping these entities using the option --targetName does not work as the GMU reports that it cannot find the targets. Explicitly describing their names (either including and excluding the path) makes no difference.
The only thing I can find that makes the GMU successfully migrate them to the target Gateway is by mapping to their targetId. (And besides, I have to explicitly ignore the parent folders of the generic policies, otherwise the GMU reports that it can't find those entities in the bundle.)
We - and our customer - are not satisfied with this solution, as we will have to repeat this migration from the acceptance to the production environment and we feel that we should not be entering the id's of the generic policies on the production environment in the migration script again.
Am I missing an option of the GMU that does allow me to properly (and automatically) map the generic policies? Preferably also without having to explicitly ignore their parent folders?
Or should we use calls to the restman service on the target gateway in our migration script to automate the search for the target id's?
Try this to see if it helps,
./gmu.sh manageMappings -b myBundle.xml -t GENERIC -N
The '-N' will map 'ALL' GENERIC entities by Name in the bundle if no other arguments are provided.
thanks for your reply. However, I don't get this to work. If I give this command (using the Windows batch file instead of the shell script) the GMU responds with "Execution failed. Reason: Mapping not found with type=GENERIC and srcName=null". Adding an action parameter does not change a thing...
Ah, was I wrong expecting that type GENERIC simply referred to all types of entities?
Can you give me a simple bundle and an example of the commands you have to do to get it to work?
I want to make sure i understand your question/frustration.
Well, I can send you a bundle if you give me your email address. But perhaps that is not necessary.
The bundle I am talking about has been created with the following command:
gmu.bat migrateOut --argFile herkomstOTKexport.properties --folderName sap-accountmanagement --dest bundle/bhrOTK-RP.xml
The service contained in that folder uses three policy fragments which have a general purpose, are located outside the folder that has been designated for migration, and already exist on test, acceptance and production environments. I am not sure how these general purpose policies have been migrated (it was at least before the upgrade from version 7 to 8.4, I believe they used the ESM), they have identical names and paths but different policy ID's on the different environments.
Unfortunately I am not able to replicate the logs now (they are overwritten by the next migration intent).
If I do not map on name (using --targetName) I get - of course - a unique key conflict, as the name of the policy already exists. Mapping on name, however, results in the GMU not being able to find the corresponding policy on the target gateway (tried with both --action Existing and --action NewOrExisting (unique key conflict as well)). I also tried writing the targetName explicitly, both including and excluding the path, but this makes no difference.
What is more. The errors I get do not only refer to the general purpose policies, but also to their parent folders. The bundle does not contain the parent folder as an item, but does contain it as a attribute (or child, don't pin me down on this one) of the policy and the parent folder has its own mapping instruction in the bundle. I need to map the parent folders with --action Ignore to avoid the error that the 'entity cannot be found in the bundle'... (Intuitively I would want to try to map the parent folder to its counterpart on the target gateway, but I cannot find its ID on the target gateway.)
One thing I haven't tried is mapping --type FOLDER --srcId 30bae345f6646ab10000000001160029 --targetName nameFolder ...
I will see if I can try that one here on our own environment...
I found the solution and it is not that complicated... This is the way it must be done:
manageMappings --type POLICY --targetName
manageMappings --type FOLDER --srcId <folder ID of parent folder> --action Ignore
the last line has to be repeated for each parent folder.