Kong-Erweiterungsklassen
Die Store-App CMDB CI Class Models fügt Klassen für Kong-Gateways hinzu oder aktualisiert sie.
Die App fügt Klassenmodelle hinzu, die die CMDB-Klassenhierarchie erweitern, einschließlich Klassenbeschreibungen, Identifizierungsregeln, Bezeichnereinträgen und abhängigen Beziehungen (falls zutreffend). Sie können die hinzugefügten Klassen als jede andere CMDB-Klasse verwenden. Anwendungen wie Muster für Discovery und Service-Mapping können diese Klassenerweiterungen verwenden, um CIs auszufüllen und verschiedene Technologien und Software zu erkennen.
Apps im Store anfordern
Besuchen Sie die ServiceNow Store-Website, um alle verfügbaren Apps anzuzeigen und Informationen zum Senden von Anforderungen an den Store zu erhalten. Kumulative Informationen zum Release für alle veröffentlichten Apps finden Sie in den Release-Hinweisen zum ServiceNow Store-Versionsverlauf.
Kong
Kong ist eine API-Verwaltungsplattform, mit der Unternehmen den Client- und Hostverkehr besser verwalten können.
Klassen
In diesem Abschnitt werden die Klassen aufgelistet, die die Store-App CMDB CI Class Models hinzufügt oder aktualisiert.
CMDB CI Class Models: Release 1.49.0 fügt die folgenden Klassen für Kong hinzu. Eine Liste der CMDB-Klassen in einem Basissystem, einschließlich der Klassen, die diese Store-App möglicherweise erweitert, finden Sie unter CMDB-Tabellenbeschreibungen.
| Klasse | Erweitert | Beschreibung |
|---|---|---|
| Kong-Gateway [cmdb_ci_kong_gateway] |
API-Gateway [cmdb_ci_api_gateway] |
Die Kong-Gateway-Anwendung, die einzelne APIs hostet und verwaltet. Beispiel: Kong Gateway instanceName. |
| Kong-Lastenausgleichsmodul [cmdb_ci_kong_lb] |
Lastenausgleichsmodul-Anwendung [cmdb_ci_lb_appl] |
Das Standardlastenausgleichsmodul in der Gateway-Anwendung „Kong“, das bei der Erfüllung von API-Anforderungen auf Back-End-Serviceinstanzen verweist. Beispiel: httpbin-upstream. |
| Kong-Ziel [cmdb_ci_kong_target] |
API-Komponente [cmdb_ci_api_component] |
Back-End mit Lastenausgleich des Gateways, das API-Anforderungen erfüllt. Beispiel: httpbin-target1. |
Klassenattribute
CMDB CI Class Models: Release 1.49.0 fügt den jeweiligen Klassen die folgenden Attribute hinzu.
| Attribut | Datentyp | Beschreibung |
|---|---|---|
| Administrator-URL | Zeichenfolge (255) | URL zum Senden von Admin-API-Anforderungen. |
| Datenbank | Zeichenfolge | Typ der vom Kong-Gateway verwendeten Datenbank. Beispiel: Postgres oder Cassandra. |
| Attribut | Datentyp | Beschreibung |
|---|---|---|
| Algorithmus | Zeichenfolge | Typ des für den Lastausgleich verwendeten Algorithmus. Beispiel: Round-Robin. |
| ID | Zeichenfolge (255) | Eindeutiger Bezeichner aus dem Quellsystem. |
| Attribut | Datentyp | Beschreibung |
|---|---|---|
| Ziel | Zeichenfolge (255) | URL der Zielintegration. |
Wichtige Beziehungsstrukturen
Es gibt eine Reihe von Schlüsselbeziehungen, die für API- und Kong-Klassen definiert werden müssen.
| Übergeordnete Klasse | Beziehung | Untergeordnete Klasse | Beziehungstyp |
|---|---|---|---|
| API-Back-End [cmdb_ci_api_backend] | Verwendet::Verwendet von | Kong-Lastenausgleichsmodul | Vorgeschlagen |
| Kong-Lastenausgleichsmodul [cmdb_ci_lb_appl] | Enthält::Enthalten in | Kong-Ziel | Abhängig |
| Kong-Gateway [cmdb_ci_kong_gateway] | Stellt bereit::Bereitgestellt von | Kong-Lastenausgleichsmodul | Abhängig |
Zugehörige Nicht-CMDB-Tabellen
Die Klasse „Kong Gateway“ verwendet die Nicht-CMDB-Tabelle „Kong Workspace“ als zugehörige Liste:
| Attribut | Datentyp | Beschreibung |
|---|---|---|
| Name | Zeichenfolge (100) | Name des Kong-Arbeitsbereichs. |
| ID | Zeichenfolge (255) | Eindeutiger Bezeichner aus dem Quellsystem. |
| API-Gateway | Referenz | Verweis auf das Kong-API-Gateway. |
Beispiel für das Kong-Gateway
Hier ist ein Beispiel für eine Abhängigkeitsansicht für die Gateway-Klasse „Kong“, die zeigt, wie ein Gateway die abhängige verwaltete API-abhängige Klasse mit zugehörigen APIs und Komponenten ausfüllt. Die verwaltete API-Klasse wird in Bezug auf das Gateway als Beziehung der ersten Ebene betrachtet, während die Front-End- und Back-End-Komponenten als Beziehungen der zweiten Ebene betrachtet werden. Von hier aus können Sie dann Warnungen an diese CIs binden, dynamische CIs für Serviceansichten und Incidents konfigurieren oder zusätzliche Workflows einrichten, die CIs verwenden.