Layer7 API Management

Dear CA APIM users,

As a new GMU user, I want to export some services from a dev to test env.

I do prefer directory format for my exports, it is easier to browse between files and I get the same folder tree than the existing one in source gateway.

For exporting I used the command : GatewayMigrationUtility.sh migrateOut --argFile sourceSSGcommon.properties --folderName "someService" --dest Export_bundle

Problems appeared when I tried migrateIn command. I wanted to test the bundle before importing and thus use --test parameter : GatewayMigrationUtility.sh migrateIn –-argFile targetSSGcommon.properties --bundle Export_bundle --test –-results results.xml.

But I was surprised to notice that after running this command the "someService" was exposed on my target Gateway ! I was able to use the service like in my dev env, without "committing" the import (migrateIn without --test param).

The big issue I faced is when the migrateIn --test returned a conflict state for another service export... Because export was commited (and it was not supposed to!), my target gateway became unstable : I was able to connect to it via Policy Manager but impossible to do any actions. Then I try to reboot gateway and .. it was impossible, an error message telling me it was impossible to get an entity !

Two questions :

- Could you confirm me that migrateIn with --test arg is not supposed to act like I described ? I wonder if this bug is not related to the fact i used a bundle in directory format (all examples in doc used .xml simple file format) ...

- I am also wonderinf if the NewOrUpdate mapping action I set in my common property file is not responsible for the target broken Gateway. Some high-level dependecies of a service mapped with such action could provoke such a mess in a target gateway ?

Thank you for helping me

They gateway should have NOT reacted the way it did. This is definitely strange and uncommon. The --test option should do as you intended and NOT commit the policy. The manage mappings command shouldn't have an effect on this either. If this is reproducible, please open a support ticket, so that this can be tracked.

Hi Doyle_Reece,

Thank you for your confirmation.

I just noticied that I use GMU 1.1 version, but my soft Gateways are in 8.3.

Maybe someone from support team know if there is incompatibility issues ?

I downloaded GMU 1.0 version and behavior is the same.

Here is my use-case : create a folder test in source Gateway, migrateOut it in simplefile format.

Then migrateIn this xml bundle with --test arg and .... test folder is created into target Gateway, without explicit commit.

So I'am puzzled about GMU. May I forgot something obvious or I face a really annoying bug in my env (Restman bugging ?)

Silly question... What happens when you move the --test flag immediately after the migrateIn command?

Thanks,

Alejandro

Hi acalbazana,

Nice try, but no it does not change the result.

Moreover I am sure that test mode is well interpreted by GMU because its response message ends with "Test migrate in successful".

This is a very strange behavior, could someone test this "test" flag ?

My conf : GMU 1.0 / GTW 8.3 patch 2

i should of read further before commenting above. Please open a support case, this seems like a bug to me.

Thank you Doyle_Reece,

I opened a support case. Very annoying bug

SSG 8.3 uses GMU 1.0

SSG 8.4 uses GMU 1.1

Please try 1.0 and let us know how it works. No need to troubleshoot, if its a compatibility issue