API Developer Portal (ADP): Orphaned APIs and how to remove them from an environment
search cancel

API Developer Portal (ADP): Orphaned APIs and how to remove them from an environment


Article ID: 42842


Updated On:


CA API Developer Portal CA API Gateway



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.


When orphaned APIs are found, the following steps should be followed:

  1. Log in to the API Portal CMS system (http://<hostname>/admin) as the admin user.
  2. 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.
  3. 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.
  4. 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.


Release: L7APIP99000-3.1-API Developer Portal-Perpetual


Please Update This Required Field

Additional Information

Additional Information - Identifying the rogue service uuid, and how to delete it.


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 

mysql -u root -p -e "select name from ssg.generic_entity where classname ='com.l7tech.external.assertions.apiportalintegration.server.PortalManagedService';" > /tmp/gw_apilist.txt

1.2 On API Portal 3.5 Get list of API's that are published 

cd DATA/PUBLISHED/sitebuilder/content/groups/APIs/
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) 

cd /tmp
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. .

cat api_gw_to_portal.diff 
--- 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 @@
@@ -30,41 +21,29 @@

1.5 But we are only intestested in the "+" entries - the uuid's that are on portal but NOT on the API gateway. 

So : 
   cat api_gw_to_portal.diff | grep "^+"

Which gives us : 
+++ portal_apilist.txt    2018-10-12 12:03:00.362228768 +1100

Identifying 99e6ce41-52c5-417d-bfc0-d63748784dfa.xml as the entry on API Portal but not on the API Gateway - the entry we have to delete 

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>

User-added image

(note: not the same api as the one we deleted) 



1558693812832000042842_sktwi1f5rjvs16hj7.png get_app