Kong-Erweiterungsklassen
Die Store-App „CMDB CI Class Models“ (CMDB-CI-Klassenmodelle) fügt Klassen für Kong-Gateways hinzu oder aktualisiert sie.
Die App fügt Klassenmodelle hinzu, die die Klassenhierarchie CMDB erweitern, einschließlich Klassenbeschreibungen, Identifizierungsregeln, Bezeichnereinträge und abhängige Beziehungen (falls zutreffend). Sie können die hinzugefügten Klassen wie 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 Host-Datenverkehr besser verwalten können.
Klassen
In diesem Abschnitt werden die Klassen aufgelistet, die von der Store-App CMDB CI-Klassenmodelle hinzugefügt oder aktualisiert werden.
CMDB CI-Klassenmodelle: Version 1.49.0 fügt die folgenden Klassen für Kong hinzu. Die Liste der CMDB -Klassen in einem Basissystem, einschließlich der Klassen, die durch diese Store-App möglicherweise erweitert werden, finden Sie unter Beschreibungen der CMDB-Tabellen.
| 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 standardmäßige Lastenausgleichsmodul in der Kong-Gateway-Anwendung, 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] |
Das Back-End mit Lastenausgleich des Gateways, das API-Anforderungen erfüllt. Beispiel: httpbin-target1. |
Klassenattribute
CMDB CI-Klassenmodelle: Release 1.49.0 fügt den jeweiligen Klassen die folgenden Attribute hinzu.
| Attribut | Datentyp | Beschreibung |
|---|---|---|
| Administrator-URL | Zeichenfolge (255) | URL zum Stellen 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 Lastenausgleich verwendeten Algorithmus. Beispiel: Round-Robin. |
| ID | Zeichenfolge (255) | Eindeutiger Bezeichner aus dem Quellsystem. |
| Attribut | Datentyp | Beschreibung |
|---|---|---|
| Zielvorgabe | Zeichenfolge (255) | URL der Zielintegration. |
Schlüsselbeziehungsstrukturen
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 Folgendes bereit::Bereitgestellt von | Kong-Lastenausgleichsmodul | Abhängig |
Zugehörige Nicht-CMDB-Tabellen
Die Kong-Gateway-Klasse verwendet die Nicht-CMDB-Tabelle des Kong-Arbeitsbereichs 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 ein Kong-Gateway
Hier ist ein Beispiel für eine Abhängigkeitsansicht für die Kong-Gatewayklasse, die zeigt, wie ein Gateway die abhängige Klasse der verwalteten API mit zugehörigen APIs und Komponenten füllt. Die Klasse der verwalteten APIs 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.