Kong Erweiterungsklassen
Die CMDB CI-Klassenmodelle App fügt Klassen für hinzu oder aktualisiert sie Kong Gateways.
CMDB CI-Klassenmodelle Ist ein ServiceNow Store App, die Klassenmodelle hinzufügt, die erweitern CMDB Klassenhierarchie. Die neuen oder aktualisierten Klassen umfassen Klassenbeschreibungen, Identifizierungsregeln, Bezeichnereinträge und, falls zutreffend, abhängige Beziehungen. Sie können die hinzugefügten Klassen wie jede andere verwenden CMDB Klasse. Anwendungen wie Muster für Discovery und Service-Mapping Kann die Klassenerweiterungen verwenden, um CIs auszufüllen und Technologien und Software zu erkennen.
Siehe Vollständige Release-Hinweise für alle CMDB CI-Klassenmodelle.
Apps im Store anfordern
Besuchen Sie ServiceNow StoreUm 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 Enterprise-Unternehmen den Client- und Host-Datenverkehr besser verwalten können.
Klassen
In diesem Abschnitt werden die Klassen aufgeführt, die CMDB CI-Klassenmodelle App fügt hinzu oder aktualisiert sie. Für die Liste der Klassen in Basissystem, Einschließlich Klassen, die diese App erweitern könnte, siehe CMDB-Tabellenbeschreibungen.
CMDB CI-Klassenmodelle: Release 1.49.0 fügt die folgenden Klassen für hinzu Kong.
| 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-Instanzname. |
| Kong Lastenausgleichsmodul [cmdb_ci_kong_lb] |
Lastenausgleichsmodul-Anwendung [cmdb_ci_lb_appl] |
Der standardmäßige Lastenausgleichsmodul auf Kong Gateway-Anwendung, die 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 lastausgleichende Back-End 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 für Administrator-API-Anforderungen. |
| Datenbank | Zeichenfolge | Typ der von verwendeten Datenbank Kong Gateway. Beispiel: Postgres oder Cassandra. |
| Attribut | Datentyp | Beschreibung |
|---|---|---|
| Algorithmus | Zeichenfolge | Typ des Algorithmus, der für den Lastenausgleich verwendet wird. Beispiel: Round-robin. |
| ID | Zeichenfolge (255) | Eindeutiger Bezeichner aus dem Quellsystem. |
| Attribut | Datentyp | Beschreibung |
|---|---|---|
| Zielvorgabe | Zeichenfolge (255) | URL der Zielintegration. |
Wichtige Beziehungsstrukturen
Es gibt eine Reihe von Schlüsselbeziehungen, die für API und definiert werden müssen Kong Klassen.
| Ü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 Kong Gateway-Klasse verwendet Kong Arbeitsbereich Nicht- CMDB Tabelle als zugehörige Liste:
| Attribut | Datentyp | Beschreibung |
|---|---|---|
| Name | Zeichenfolge (100) | Name von Kong Arbeitsbereich. |
| ID | Zeichenfolge (255) | Eindeutiger Bezeichner aus dem Quellsystem. |
| API-Gateway | Referenz | Verweis auf Kong API-Gateway. |
Kong Gateway-Beispiel
Hier ist ein Beispiel für eine Abhängigkeitsansicht für Kong Gateway-Klasse, die angibt, wie ein Gateway die abhängige verwaltete API-abhängige Klasse mit zugehörigen APIs und Komponenten ausfüllt. Die Klasse der verwalteten API 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 Warnungen an diese CIs binden, dynamische CIs für Serviceansichten und Incidents konfigurieren oder zusätzliche Workflows einrichten, die CIs verwenden.