API Developer Portal (ADP): Orphaned APIs and how to remove them from an environment
Article ID: 42842
Updated On:
Products
Issue/Introduction
Introduction
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.
Common causes
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.
Resolution
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.
Environment
Component:
Resolution
Additional Information
1. How to identify the the rogue service uuid that API Poaral 3.5 has, but that API Gateway does not.
Below are the steps we followed to identify the rogue id :
1.1 Get list of API's in the API Gateway
1.2 On API Portal 3.5 Get list of API's that are published
ls -1 | cut -d'.' -f1 > /tmp/portal_apilist.txt
1.3. Find the differences (note you may need to copy those files onto the same machine to run the compare)
diff -u gw_apilist.txt portal_apilist.txt > api_gw_to_portal.diff
1.4 The full list of differences is in the .diff file, but only the "added" "+" entries are relevant. .
--- gw_apilist.txt 2018-10-12 12:01:38.108637474 +1100
+++ portal_apilist.txt 2018-10-12 12:03:00.362228768 +1100
@@ -1,23 +1,14 @@
14971f98-b3a8-478e-a976-d25cd039809e
-1a603849-a4e9-47a8-a5ce-539345adb224
1f980d1f-3a67-4f47-92cb-aa3d8c7bdbf3
2079c413-61c8-4589-8263-4ed7df3e5924
-286a2715-faa4-4d1f-a770-182d4c1af80d
-305b2d93-3583-4dd7-b980-2ec8f89e76f1
3479ad5c-4bc2-482d-a19d-a85940ba3a1c
@@ -30,41 +21,29 @@
8f29fce7-29c8-4b99-83df-c7cde04688af
-92316586-e87a-4cfc-8426-e34adecd2a03
94f89f9c-73e8-490d-894c-6854335a3a60
+99e6ce41-52c5-417d-bfc0-d63748784dfa
99f0023c-7adc-4099-8c26-a1ba84358794
9b9ecf1d-7d49-420d-b5d3-b1c0c8bdd516
9d9995d8-66d7-40c8-976c-4ddf926bdb82
a30dfd19-39cd-4a3a-84ce-4daed812e10d
a3348a50-ea62-4bde-b24d-df8d98bdd4f7
a35a8184-47f0-4875-b8d5-493c64023ac2
-a378737b-9767-4b4f-8c42-d4d76d0abedc
-a971a1c1-42fa-47a8-a5d7-da1455fc6f2a
afde3726-669a-4010-a2be-e59485b72da5
1.5 But we are only intestested in the "+" entries - the uuid's that are on portal but NOT on the API gateway.
cat api_gw_to_portal.diff | grep "^+"
+99e6ce41-52c5-417d-bfc0-d63748784dfa
2. To delete via the API Portal Admin interface. :
From the admin : http://<portal>/admin
select "sitebuilder" and navigate to directory : /sitebuilder/content/groups/APIs/
Or direct link : http://<portal>/admin?action=list&path=/sitebuilder/content/groups/APIs
From screen find the errant uuid xml file and delete.
<Please see attached file for image>
(note: not the same api as the one we deleted)
Attachments
Feedback
