This assumes you are familiar with the basic usage of the Gateway Migration Utility and that you are using an arguments file with an encoded password to connect to your API Gateway. This also assumes you have migrated out an entity (service, policy, folder) into an XML file named foo.xml.
When you export an entity using migrateOut, the defaultAction can be NewOrExisting, NewOrUpdate, or Ignore, like this.
/path/to/GatewayMigrationUtility.sh migrateOut -defaultAction NewOrExisting|NewOrUpdate|Ignore . . .
The action you use will be in the XML file that is migrated out, like this.
If one of these three actions does not quite fit into your needs, then you can utilize manageMappings. With manageMappings, the following actions can be used.
|New||Create new entity. Fail if entity exists.|
|Update||Update existing entity. Fail if entity does not exist.|
|Existing||Use existing entity. Fail if entity does not exist.|
|ForceNew||Create new entity, using a new ID if necessary.|
|Delete||Delete an entity. Fail if entity does not exist.|
|Ignore||Ignore an entity regardless if entity exists or not. The entity will not be created or updated in the target environment as part of the migrate in.|
|NewOrUpdate||Update an existing entity. Create one if entity does not exist.|
|NewOrExisting||Use an existing entity. Create one if entity does not exist.|
|DeleteOrIgnore||Delete an entity. Ignore if it does not exist.|
For example, you could use ForceNew to create a new entity in the target.
/path/to/GatewayMigrationUtility.sh manageMappings –bundle foo.xml -type "SERVICE" -action "ForceNew"
In this example, foo.xml is updated with the new mapping action.
Or Delete the entity in the target.
/path/to/GatewayMigrationUtility.sh manageMappings –bundle foo.xml -type "SERVICE" -action "Delete" -outputFile bar.xml
In this example, foo.xml is not changed. Instead, a new file (bar.xml) is created, and bar.xml contains the new mapping action.
After updating the mapping action, you are ready to migrate in.