Migrate services from and to same gateway in different folder

[DIVEK TOLIA]

I have 3 folders in my gateway

 

1) dev

2) qa

3) uat

 

I would like to migrate the same service from one folder to another. If the service  is not existing in the target folder, then create it otherwise update it. 

 

Assume, I have a policy on dev folder with name "divek_test_try_gmu_v1". When I use manageMappings, I am able to migrate it to qa folder with the same name as "divek_test_try_gmu_v1" and it works fine as I use manageMappings with --action ForceNew  and then I user - -destFolder qa while executing the migrateIn command.  But when I try to migrate to the uat folder, it fails with below error.

 

How do I get around this ? My end goal is to have the same service name as “divek_test_try_gmu_v1” under the dev, qa and uat folder and also able to update these services using GMU.

 

    <l7:Properties>

                    <l7:Property key="ErrorMessage">

                        <l7:StringValue>Incorrect mapping instructions: Found multiple possible target entities found with name: divek_test_try_gmu_v1. Mapping for: EntityHeader. Name=divek_test_try_gmu_v1, id=cda89459e6929840a6232a2c5650f876, description=divek_test_try_gmu_v1, type = SERVICE</l7:StringValue>

                    </l7:Property>

                    <l7:Property key="MapBy">

                        <l7:StringValue>name</l7:StringValue>

                    </l7:Property>

                    <l7:Property key="MapTo">

                        <l7:StringValue>divek_test_try_gmu_v1</l7:StringValue>

                    </l7:Property>

                </l7:Properties>

[Ruchi Bhadani]

Hi,

 

From the use case you said it seems you want same service in 3 different folder?

since you have already migrated the service once and you are mapping by name the error suggests that the service already exists in target with same name. 

1. You can try removing the map by name option from mapping by not specifying the --targetName option and then migrate by --destFolder option

[DIVEK TOLIA]

Hi,

 

The problem is i am not able to migrate from dev to uat. It only works when I migrate from dev folder to qa. But when I try to migrate from dev folder to uat, It fails with the error described in the post.

[Legacy User]

You could look at using Restman to export the service, do a find and replace of the relevant details (folder id, service url, etc...) and then use Restman to inject the service into the new folder.

[Doyle_Reece]

Multi-Tenency can get complicated using GMU as there are multiple factors that have to be considered, but here is how i was able to accomplish this via the simple use-case for a very simple service.

 

**Make sure the default folder structure exists on all environments involved, as of this writing, GMU doesn't support 'automatically' creating a folder structure that doesn't already exist.. ( a folder that you want to migrate into the the bundle doesn't already have or know about ).

 

Here is My folder structure

 

 

• Let's 'migrateOut' /Environments/Dev/Doyles_Awesome_Service now

./gmu.sh migrateOut -z args/ssg90.args --serviceName /Environments/Dev/Doyles_Awesome_Service -d Exports/DAS.xml

 

This creates us a bundle (DAS.xml) for the service, and places it in an existing directory 'Exports'

 

• Modify the bundle to 'ForceNew' the creation of the service

We need to do this, as the gateway keeps track of services via ServiceID's, so if we didnt do this, the gateway will notice that we already have a service with the same ID, and will ignore the --destFolder argument, but by modifying the action to 'ForceNew', GMU now understands that we know what we are doing, and that we don't want map to the existing service, but intend on a new one.

 

./gmu.sh manageMappings -b Exports/DAS.xml -t SERVICE --action ForceNew

 

• Templatize Our Bundle

Templatizing is an important concept with GMU and your SDLC process. It allows us to Externalize Environmentally different variables from the Bundle itself. ( i.e. Backend URL will be different, etc.. )

 

./gmu.sh template -b Exports/DAS.xml -t TemplateProperties/DEV.properties

 

** Make sure you templatize your bundle after all your manageMappings commands or you could face some interesting behaviour ( i.e. your service could be imported in the 'disabled' state ).

 

• Set up our Templatization Properties for all our environments

Our template command created a file called DEV.properties, which holds all our possible environmentally different values for various settings in the bundle.

ls -ltr TemplateProperties/
-rw-r--r-- 1 reedo03 staff 1465 Oct 10 12:23 DEV.properties

 

so lets go ahead and make a few copies for the rest of our environments at this point.

 

Now i have these identical files in the same directory

 

ls -ltr TemplateProperties/
-rw-r--r-- 1 reedo03 staff 1465 Oct 10 12:23 DEV.properties
-rw-r--r-- 1 reedo03 staff 1465 Oct 10 12:26 QA.properties
-rw-r--r-- 1 reedo03 staff 1465 Oct 10 12:26 UAT.properties
-rw-r--r-- 1 reedo03 staff 1465 Oct 10 12:26 PROD.properties

 

Now lets modify the values that will be different... ( In our case, the URI of the service MUST be unique )

 

Here's an example of what i did for UAT.properties, repeat this step(Modification of the URI) for each future environment that will live on the same host/cluster. 

 

The end result is one file per environment that contains environmental specific properties.

 

• Import the Bundles

All the hard work is now done, next is for the import. 

It's considered a best practice to use the --test argument on 'migrateIn' statements, as this is a non-persistent action, that can validate the import will import okay or show you the errors that will occur during the process.

 

Test Import

 

./gmu.sh migrateIn -z args/ssg90.args --destFolder /Environments/QA --template TemplateProperties/QA.properties -b Exports/DAS.xml --test

Warning: TLS hostname verification has been disabled
Warning: TLS server certificate check has been disabled
Running.............
MigrateIn results saved in: results.xml
Test migrate in successful

 

Actual Import

 

./gmu.sh migrateIn -z args/ssg90.args --destFolder /Environments/QA --template TemplateProperties/QA.properties -b Exports/DAS.xml

Warning: TLS hostname verification has been disabled
Warning: TLS server certificate check has been disabled
Running...........
MigrateIn results saved in: results.xml
Migrate in successful

 

You will need to repeat the above steps for each local environment, making sure to specify the corresponding template.properties file and the corresponding destination Folder.

 

i.e. UAT Environment 

 

./gmu.sh migrateIn -z args/ssg90.args --destFolder /Environments/UAT --template TemplateProperties/UAT.properties -b Exports/DAS.xml

Warning: TLS hostname verification has been disabled
Warning: TLS server certificate check has been disabled
Running...........
MigrateIn results saved in: results.xml
Migrate in successful

 

Here's what you should see in the end

 

 

 

You will want to watch out for items such as Fragments, Encapsulated Assertions, various configs ( ID Providers, SSO Settings, JMS Queues, etc. ) as careful thought and strategy should be put in place to handle these.(sharing or creating new)

 

hopes this helps to at least get you started.