DEX-Architektur

  • Freigeben Version: Yokohama
  • Aktualisiert 8. Januar 2026
  • 3 Minuten Lesedauer
  • Die Architektur von Digitale Endanwender-Experience (DEX) bietet Endanwendern eine nahtlose und integrierte digitale Experience. Das Thema bietet einen umfassenden Überblick über die Funktionsweise von DEX, einschließlich des Designs.

    DEX nutzt eine Reihe neuer mehrinstanzenfähiger Cloud-nativer Services, den sogenannten ServiceNow Cloud Services. In dieser Architektur können Agents auf DEX-Endpunkten ( Agent Client Collector ) ohne MID-Server mit der ServiceNow-Cloud kommunizieren. ServiceNow Cloud Services authentifizieren DEX-Agents und ermöglichen die Nachrichtenpufferung und die Verarbeitung von Daten aus zustandsbehafteten Streams, die schließlich an den kundenspezifischen Glide- und Zeitreihen-Datenspeicher (MetricBase) gesendet werden. Zudem bieten ServiceNow Cloud Services eine sichere Möglichkeit, Richtlinienaktualisierungen zu senden und bei Bedarf von Glide aus Prüfungen auf den DEX-Agents durchzuführen. Somit ermöglichen ServiceNow Cloud Services eine sichere bidirektionale Kommunikation zwischen Glide und den Agents auf DEX-Endpunkten.

    Abbildung : 1. Diagramm der DEX-Architektur
    Übersichtsdiagramm der Architektur von Digitale Endanwender-Experience.

    Flow für die Agent-Registrierung

    Bevor die Endpunkt-Discovery beginnen kann, muss der Agent Client Collector (Agent) auf einem Endpunkt die Registrierung über den Agent-Registrierungs-Flow abschließen und von der Glide-Instanz des Kunden ein TLS-Client-Zertifikat erhalten.

    Flow-Diagramm für Agent-Registrierung.

    Der Registrierungsprozess für Agents besteht aus folgenden Schritten.
    1. In der Kundeninstanz wird automatisch ein Registrierungsschlüssel für den Agent Client Collector (Agent) generiert.
    2. Der Agent wird mithilfe des Registrierungsschlüssels, der Instanz-URL und des öffentlichen Endpunkts in der Kundeninstanz installiert.

      Die Instanz-URL entspricht der Variablen INSTANCE_URL im einzeiligen Installationsbefehl. Der öffentliche Endpunkt verweist auf den DNS-Namen des nächstgelegenen Endpunkts der ServiceNow Cloud Services, der durch den Wert der Variablen ACC_CNC im einzeiligen Installationsbefehl dargestellt wird. Weitere Informationen zu dem Befehl und den Parametern finden Sie unter und .

    3. Der Agent sendet eine Registrierungsanforderung an die Kundeninstanz.
    4. Der Agent ist in der Kundeninstanz registriert, und ihm wird ein Zertifikat ausgestellt.
    5. Der Agent speichert sowohl das ausgegebene Zertifikat als auch den öffentlichen Schlüssel, der zur Überprüfung von Codesignaturen verwendet wird.
    6. Der Agent kommuniziert mit der Kundeninstanz über die ServiceNow Cloud Services durch Senden von Nachrichten.
    7. ServiceNow Cloud Services ermitteln, an welche Kundeninstanz die Agent-Nachrichten gesendet werden müssen.

    Endpunkterkennung

    Der DEX-Endpunkt muss zuerst erkannt und der CMDB hinzugefügt werden, bevor DEX-Metriken erfasst und verarbeitet werden können. Nach seiner Registrierung stellt der DEX-Agent eine Verbindung zu den ServiceNow Cloud Services her und meldet sich über die Keepalive-API bei Glide an. Dadurch wird der Agent-Status im Dashboard für die Integrität von Agent Client Collector aktualisiert. Glide leitet dann Checks and policies über die ServiceNow Cloud Services an den Agent weiter. Einige der Richtlinien lösen die Erkennung und Eintragung in der CMDB aus. Weitere Informationen dazu, wie ACC für die Erkennung und Eintragung in der CMDB verwendet wird, finden Sie unter Agent Client Collector for Visibility - Content.

    DEX-spezifische Richtlinien, die an den Agent gesendet werden, informieren ihn, welche Metriken für SaaS-Apps, installierte Apps und den Endpunkt erfasst werden. Diese Richtlinien lösen zuerst das Herunterladen von Agent Client Collector plugins (mit für die Erkennung und Erfassung der Metriken erforderlichen Skripts und Code) über ServiceNow Cloud Services auf den Agent-Endpunkt aus, indem in Glide eine direkte REST-API aufgerufen wird.

    Verarbeitung von DEX-Metriken

    • Die DEX-Chrome-Erweiterung führt einen internen API-Aufruf an den Agent durch, um eine Liste der URLs von SaaS-Apps abzurufen, für die Metriken erfasst werden müssen. Die DEX-Erweiterung für Chrome konzentriert sich hauptsächlich auf die Erfassung von Leistungsmetriken wie Seitenladezeit und Antwortzeit. Es werden keine detaillierten Informationen über Benutzerverhalten und Interaktionen erfasst.
    • ACC führt eine Datenvorverarbeitung oder -filterung durch und sendet die erfassten Daten an die ServiceNow Cloud Services.
    • ServiceNow Cloud Services puffern die Daten in Rohmetrikthemen zur weiteren Verarbeitung.
    • Die Daten im Rohmetrikthema werden dann von einem Verarbeitungsauftrag für Daten aus zustandsbehafteten Streams aufgenommen, der eine DEX-spezifische Datenanreicherung, Transformation, Filterung, Zusammenfassung, Analyse oder Ereigniserstellung durchführt.
    • Die für den Auftrag zur Verarbeitung des DEX-Streams erforderlichen Metrikmetadaten werden aus Glide abgerufen.
    • Die angereicherten und zusammengefassten Daten werden in ServiceNow Cloud Services in die entsprechenden Themen geschrieben.
    • Die Daten in diesen Themen werden von MetricBase direkt aufgenommen und zur weiteren Analyse in den DEX-MetricBase-Tabellen gespeichert.
    • Einige verarbeitete, nicht metrische Daten werden vom Auftrag zur Verarbeitung des Streams direkt in den Glide-Tabellen gespeichert.
    • Die Metrikdaten werden aus MetricBase gelesen und im DEX Dashboard visualisiert.