Best fit recommended CMDB class for PingGateway

[gerhardmari]

Hi Everyone,

We are currently looking for the best suited CMDB CI class to document our PingGateway CI's. The recommended on the web is the cmdb_ci_api_gateway class. However this does not seem to fit 100% as the PingGateway is a local application and configuration install per service instance (hosting Linux or Windows OS).

PingGateway seems to have more the characteristics of a reverse proxy, and sits in front of API's, Web Apps and micro services. So API gateway does not seem to fit for us.

Would a custom class be better suited, or is there a class that would suite best for tracking each PingGateway install with its host configuration per service instance in our ServiceNow CMDB?

Any recommendations would be appreciated. 

[sachinvic · Accepted solution]

Hi @gerhardmari 

Based on the description, cmdb_ci_api_gateway may not be the best fit if the PingGateway installation is primarily being managed as a software component running on a Linux/Windows host rather than as an API gateway platform.

Before creating a custom CMDB class, consider modeling the PingGateway installation as a Software Instance (cmdb_software_instance) associated with the host. ServiceNow uses Software Instance to represent an installed instance of software and maintain the relationship to the server/computer.

If you need PingGateway itself to participate as a CI in service topology/impact analysis, another option is the Application (cmdb_ci_appl) class, particularly if Discovery can identify the running PingGateway process. ServiceNow describes this class as representing a discoverable application instance running on a host, and Discovery can automatically relate it to the host.

So, the choice would depend on what you need to represent:

1. Software inventory / installation >> cmdb_software_instance

2. Discoverable running application / service component >>  cmdb_ci_appl

3. API gateway infrastructure >> cmdb_ci_api_gateway

A custom class would be the last option, only if the existing classes cannot represent the attributes, relationships, and lifecycle you need. Before creating one, check the available classes in CI Class Manager and validate the identification/reconciliation and relationship requirements.

For PingGateway specifically, if each installation needs to be tracked against its host and service instance, you should start with Software Instance or Application, rather than introducing a new custom class.

[sachinvic · Accepted solution]

Hi @gerhardmari 

Based on the description, cmdb_ci_api_gateway may not be the best fit if the PingGateway installation is primarily being managed as a software component running on a Linux/Windows host rather than as an API gateway platform.

Before creating a custom CMDB class, consider modeling the PingGateway installation as a Software Instance (cmdb_software_instance) associated with the host. ServiceNow uses Software Instance to represent an installed instance of software and maintain the relationship to the server/computer.

If you need PingGateway itself to participate as a CI in service topology/impact analysis, another option is the Application (cmdb_ci_appl) class, particularly if Discovery can identify the running PingGateway process. ServiceNow describes this class as representing a discoverable application instance running on a host, and Discovery can automatically relate it to the host.

So, the choice would depend on what you need to represent:

1. Software inventory / installation >> cmdb_software_instance

2. Discoverable running application / service component >>  cmdb_ci_appl

3. API gateway infrastructure >> cmdb_ci_api_gateway

A custom class would be the last option, only if the existing classes cannot represent the attributes, relationships, and lifecycle you need. Before creating one, check the available classes in CI Class Manager and validate the identification/reconciliation and relationship requirements.

For PingGateway specifically, if each installation needs to be tracked against its host and service instance, you should start with Software Instance or Application, rather than introducing a new custom class.

[Shahjay · Accepted solution]

Hi @gerhardmari ,

Agreed with @sachinvic  — cmdb_ci_api_gateway isn't the right fit here. Worth adding: PingGateway (ForgeRock/Ping Identity's product) is specifically an Identity Gateway — a reverse proxy for authN/authZ enforcement in front of APIs, web apps, and microservices — not an API-management platform. That's a category mismatch on top of the install-vs-platform issue, which is why cmdb_ci_api_gateway (built for products like Kong/Apigee) doesn't apply even loosely.

Recommended approach, in priority order:

1. cmdb_ci_appl (Application) — preferred if PingGateway needs to appear in topology, impact analysis, or Service Mapping. Discovery can identify the running process and auto-relate it to the host via Runs on::Runs.
2. cmdb_software_instance (Software Instance) — use this if you only need install/inventory tracking per host, without topology participation.
3. cmdb_ci_api_gateway— only if you're modeling PingGateway as an enterprise gateway platform rather than per-host installs (not your case, based on the description).
4. Custom class — last resort. Only if the classes above can't hold the attributes/relationships you need. Check identification and reconciliation rules in CI Class Manager first.

Practical modeling:

• Host = existing Computer/Linux/Windows Server CI
• PingGateway install = cmdb_ci_appl or cmdb_software_instance, related Runs on::Runs to the host
• Optionally relate the technical CI to an Application Service for CSDM-aligned business context

No custom class needed for a straightforward per-host install like this.

If I answered your question, please mark it as Helpful / Accept as Solution.

Thanks