If an API is not removed according to the instructions in the API Portal User Guide, there can be problems / mismatches between APIs which show in the API Portal versus those that exist on the API Gateway.
The API Gateway, when publishing an API as a new service in the API Portal, will associate an API ID with the published service. That unique ID will identify the service to the API Portal and allow the matching of services through the API Portal. If this API ID is changed in any way, it can cause inconsistencies with the API between the API Gateway and the API Portal.
The most common cause is deleting the service from the API Gateway before its corresponding API is removed properly from the API Portal.
The second most common cause is removing the "Set as Portal Managed Service" assertion from a published service, and then in some cases re-adding it. Any time that assertion is added to any service, it creates a unique API ID, even if the assertion is simply re-added to the same service. If that API ID is changed at any point while the API is in enabled on the API Portal, it will sever the relationship of the API between the API Portal and the API Gateway. It could cause all APIs from being view-able from the Portal GUI.
Another common cause is removing the API from the API Portal, but missing a required step or two before completely removing it. To remove an API from the API Portal without issues, please review the detailed instructions in the API Portal User Guide for the version of API Portal being used.
When orphaned APIs are found, the following steps should be followed:
- Log in to the API Portal CMS system (http://<hostname>/admin) as the admin user.
- Find the list of published API's by navigating to /sitebuilder/content/groups/APIs
- The list of XML files are associated with APIs present on the API Portal. The filename of the XML files will correspond to the API ID.
- Identify and remove any APIs that are no longer valid or which do not match any API IDs on the API Gateway services. The red "X" can be used on each line in the directory listing to remove the file.
- Restart the Catalina service:
- # service apiportal stop
- # service apiportal start
After following the steps above, the orphaned APIs should now be removed from the API Portal.
If you have difficulty identifying which API IDs exist in the Gateway database, you can use the following mysql query on the ssg database:
select name from generic_entity where classname ='com.l7tech.external.assertions.apiportalintegration.server.PortalManagedService';
Compare the API IDs from the SQL output above to the XML file names in the API CMS GUI. The references in CMS that don't appear in the SQL output would need to be removed from CMS.
How to avoid this problem
Always consult the API Portal User Guide for complete instructions on removing an API from production, as the steps differ slightly between versions. As long as all steps are properly followed, this problem should no longer occur. If the detailed instructions were correctly followed but this problem still occurs in an environment, please open a Support case for further assistance.