With the initial version of API Insights, released in September of 2024, we created experiences for a CMDB administrator and an architect (software/enterprise). Let's review the activities each can perform in the API Insights workspace.
CMDB Administrator:
- Configure API Service Graph Connectors
- Search the inventory of APIs in the CMDB
- See details of an API and its related resources
- Enable clustering of orphaned API resources and then relate to an API
- Address missing attributes and/or relationships on APIs
Architect (software/enterprise):
- Search the inventory of APIs in the CMDB
- See details of an API and its related resources
- Address missing attributes and/or relationships on APIs
- Request access to an API (customizable workflow)
- Approve or reject access requests to APIs their team owns
- Configure the behavior of the different flows in the workspace
What's New in v2.0
ServiceNow API Imports
Prior to the 2.0 release, the API Insights workspace was typically populated with APIs proxied on a gateway (AWS API gateway, Azure API Management service, Apigee X, Kong Enterprise). With 2.0 we have added an option for the CMDB administrator to be able to import ServiceNow APIs as well. As we continue to expand the capabilities in this area, the current types of APIs which may be imported are Scripted REST APIs (including platform APIs like the Table API), Scripted SOAP, Outbound REST Messages, and Outbound SOAP Messages. The import will also attempt to collect usage statistics for the Scripted REST and SOAP APIs. However, statistics are only collected when the Collect API Stats flag is set to true on the sys_api_stats_whitelist table.
Filters on List Views
You may be thinking that this isn't a big deal as lists always have filters. While this is true, the difference in this case is that the API list on the workspace is made up of multiple tables and relationships which makes simple filtering more difficult across related tables. In 2.0 we have added the ability to filter by the management platform (e.g. Kong gateway) and even a specific instance of the platform (like the production instance versus test or dev instances).
Filters for the API Inventory
Connect to Application Services
Giving business context to CIs, including APIs, is important for many reasons including, deriving ownership, assessing impact, viewing dependencies, and more. In v1.0 API Insights could link an API to an application service if there was no existing relationship to at least one application service that also was related to a business application. This flow still exists and it meant to facilitate conformance with the CSDM guidance for CIs having a business context. In v2.0 we have added an additional way to relate APIs to an application service as well as remove existing relationships.
Connect to Application Services
Usage Data
The introduction of usage data for APIs is a combination of updates to both the workspace and the API Service Graph Connectors (ASGCs). The ASGCs have options for importing a daily average of requests made to an API (some configuration to the API may be required to enable this tracking on the various platforms) and the workspace has two visualizations for showing this usage.
Consumer Access
Another combined update between the workspace and the ASGCs is the population of the api_consumer_access table and subsequent presentation of that data. Each platform we currently integrate with has multiple methods for providing access to the APIs defined. The primary mechanism we focused on in this release of the connectors was to capture the access path when consumers / developers register and app on a portal or platform and that app subscribes to one or more API products. The terminology changes a bit for each platform, but the basic constructs are the same.
In ServiceNow we have normalized these into API Consumers (api_consumer), API Product Bundles (cmdb_ci_api_product_bundle), and API Consumer Subscription (cmdb_ci_api_consumer_subscription). The API product bundles have one or more relationships to APIs, which is how we eventually populate the API Consumer Access table to reflect which consumers have access to which API (effectively flattening and de-normalizing the four tables involved in capturing these relationships).
API Specifications
A table was added to the API Insights application to provide a place to store API specifications (sn_api_insights_ws_api_specification). In addition, a data source and transform map have been created to provide an endpoint which may be used to send one or more specification files using the Import Set API. The specific endpoint would be "https://[instance]/api/now/import/sn_api_insights_ws_push_api_spec/insertMultiple".
The 2.0 release of the API Insights workspace also came with a new layout of the API details page to better organize the data being presented. We hope you find value in analyzing your API landscape from within API Insights, and we look forward to hearing your feedback (or reading it at least).
