Dear SHARATH YERAMALLA,
From another discussion, it seems you're trying to migrate otk.
The beauty of GMU is, when you migrateOut an entity, all dependent entities will be migrateOut as well.
ie. if you have a service using stored password, when you migrate the service, stored password will be migrated, too.
To migrate OTK, you can use option --all to migrate everything, then it will include OTK, as showed in product document.
Here is an example only migrate the OTK folder,
./GatewayMigrationUtility.sh migrateOut --argFile sourcearg.txt --encassAsPolicyDependency --dest OTK.xml --folderName /OTK
./GatewayMigrationUtility.sh migrateIn --argFile targetarg.txt --bundle OTK.xml
NOTE0: you may need to map jdbc connection before migrateIn, as different env should have different database.
./GatewayMigrationUtility.sh manageMappings --bundle OTK.xml --type JDBC_CONNECTION --srcName <src jdbc name> --targetName <target jdbc name>
NOTE1: --encassAsPolicyDependency is required, otherwise the OTK encapsulated assertion cannot migrate.
NOTE2: argument file is used to connect to the gateway, here is a common sample of argument file,
host=<gateway hostname>
username=admin
plaintextPassword=7layer
encryptUsingClusterPassphrase
trustCertificate
trustHostname
results=<any name of result file>.xml
You can change the host/username/password etc. to connect to source and target server.
NOTE3: in argument file, encryptUsingClusterPassphrase will be used to encrypt stored password, that means the encryptionPassphrase needs to be the same for both migrateOut and migrateIn, otherwise the when migrateIn you will fail to migrateIn as you fail to decrypt. As we don't specify encryptionPassphrase, we are using cluster passphrase to encrypt, that means the lower and higher env need to be configured with same cluster passphrase (on gateway main menu when install gateway)
You can use plaintextEncryptionPassphrase, or encryptionPassphrase, to replace encryptUsingClusterPassphrase, refer to the product document for the details.
NOTE4:the above will not migrate solution kit settings, ie. on higher env, the Manage Solution kits task will not show the migrated OTK, as we don't need to install otk again on higher env. (and we don't need to manage solution kit on prod env, any change should be done on lower env, and then migrate to prod env)
NOTE5:
If you also have MAG install on the gateway, you cannot migrate them separately, as I found that they depend on each other. We need to migrate them altogether,
./GatewayMigrationUtility.sh migrateOut --argFile sourcearg.txt --encassAsPolicyDependency --dest OTK_MAG.xml --folderName /OTK --folderName /MAG
./GatewayMigrationUtility.sh migrateIn --argFile targetarg.txt --bundle OTK_MAG.xml
Regards,
Mark