Layer7 API Management

Hi there,

Am just trying to understand. Let say,if I've added just an input variable in the below highlighted in blue,and want to migrateIn this encapsulated assertion in to higher environments through GMU command line(essentially its an update).Would it possible to perform this change through GMU or do i need to do it manually because we have 6 clusters? I tried with the below commands which didn't reflect the specific variable which I've created i,e test.

GMU.bat migrateOut --argFile E:\GMU\dev99.properties --dest E:\GMU\test\refresh-token.xml --policy e001cfd0c1c1ffaa18e187b5e7

GMU.bat manageMappings -b E:\GMU\test\refresh-token.xml -t CLUSTER_PROPERTY -a ignore
GMU.bat manageMappings -b E:\GMU\test\refresh-token.xml -t SECURE_PASSWORD -a ignore
GMU.bat manageMappings -b E:\GMU\test\refresh-token.xml-t POLICY -a ignore
GMU.bat manageMappings -b E:\GMU\test\refresh-token.xml -t JDBC_CONNECTION -a ignore
GMU.bat manageMappings -b E:\GMU\test\refresh-token.xml-t FOLDER -a ignore
GMU.bat manageMappings -b E:\GMU\test\refresh-token.xml  -t POLICY --srcId e001cfd0c1c1ffaa18e187b5e7 -a NewOrUpdate

GMU.bat migrateIn --test -z E:\GMU\Properties\stagging.properties --bundle E:\GMU\test\refresh-token.xml.xml --results E:\GMU\test\refresh-token.xml-log.xml

As this is for migrating encapsulated assertion, you should include --encassAsPolicyDependency in your migrateOut command, otherwise, only the policy will be migrateOut, the encapsulated assertion will not be migrateOut.

encapsulated assertion and its associated policy are 2 entities.

The change is on encapsulated assertion, so NewOrUpdate on policy will not impact the encapsulated assertion, you may ensure the same action on  the encapsulated assertion entity.

The change is just in encapsulated assertion, just a small variable need to add in to it as per my earlier screen shot.No changes to policy.

Hi CA team,

Any update pls on the above ask?

Dear SHARATH YERAMALLA ,

Sorry for the late response.

We may need to check the bundle file, to see if the encapsulated assertion entity is in the bundle file, and what mapping action for this entity.

Again, policy of the encapsulated assertion is different with encapsulated assertion itself. As you change the property of encapsulated assertion, we need to migrate the encapsulated assertion itself. It has nothing to do with the policy of the encapsulated assertion.

You can search by the name of the encapsulated assertion in the bundle file, you should find 2 entities with different type,

one is <l7:Type>POLICY</l7:Type>,

another is <l7:Type>ENCAPSULATED_ASSERTION</l7:Type>

The last one is what we care about, find the <l7:Id> of the ENCAPSULATED_ASSERTION, and search with the ID, you should be able to find its mapping action,

the problem is, the default mapping action for ENCAPSULATED_ASSERTION should be <l7:Mapping action="NewOrExisting" ...

That means if you have the same encapsulated assertion on target server, it will not be migrated, you need to change the mapping action for encapsulated assertion which I don't see it in your manage mapping commands.

for example,

./GatewayMigrationUtility.sh manageMappings --bundle <bundle>.xml --type ENCAPSULATED_ASSERTION --action NewOrUpdate

Regards,

Mark