Customer has API Gateway and Developer Portal both in all their environments, DEV, TEST, UAT etc.,
Now, considering they have published the APIs on to the Portal in DEV, if we migrate them to TEST using GMU, the APIs doesn't show up in TEST API Portal, even though they have a valid "set as portal managed service" assertion with a unique App ID.
I presume, we should migrate the contents of the API Portal as well between the environments, so that the all the API (appid.xml etc) and related content will move to TEST env as it is in DEV, and there wouldn't be a need to publish the apis again.
Is there a procedure that we follow as a standard to this kind of migration? If so, please share it with me.
I have seen this issue in the past simply due to how the Portal "listens" for changes on the Gateway.
In the past we have simply removed the Set as Portal Managed Assertion, Save and Activate the Policy, and then a minute or so later, add a new Set as Portal Managed Service to the policy and Save and Activate Again.
You should now see the service come into the Portal for onboarding.
Let me know if this helps.
Thanks for that. But, the customers would not want to have different versions in different environments. Modifying the assertion would increase the revision, and make the policy different from the one migrated using GMU.
I'm not 100% sure, but on portal cms -> plugin administration -> Layer 7 gateway -> "Sync ssg data" section, there are few buttons to sync the ssg data. Could you try manually sync ssg data after migration?
Exactly, there should be a timer on portal to sync the data, the default interval should be 5 minutes if my memory is right.
ie. any change on gateway will not be seen on portal immediately, you may need to wait few minutes or try to sync the data manually.