DEX Architecture

Digital End-User Experience (DEX) architecture provides a seamless and integrated digital experience for end users. The topic provides a comprehensive overview of how DEX works, including its design.

DEX uses a set of new multi-tenant, cloud-native services called ServiceNow Cloud Services. In this architecture, DEX endpoint Agents ( Agent Client Collector ) are able to communicate to the ServiceNow cloud without a MID server. ServiceNow Cloud Services provide authentication to DEX Agents and enable message buffering and stateful stream processing of data that is eventually sent to customer-specific Glide and time series datastore (MetricBase). ServiceNow Cloud Services also enable a secure way to send policy updates and on-demand execution of checks on the DEX Agents from Glide. Thus, ServiceNow Cloud Services enable secure bi-directional communication between Glide and the DEX endpoint Agents.

Figure 1. DEX architectural diagram

Agent Registration Flow

Before Endpoint Discovery can begin, the Agent Client Collector (Agent) on an endpoint must complete registration through the Agent registration flow and be issued TLS client certificate by the customer Glide instance.

The Agent registration process involves the following steps.

1. On the customer instance, a registration key is automatically generated for the Agent Client Collector (Agent).
2. The Agent is installed in the customer instance using the registration key, instance URL, and public endpoint.

   The instance URL corresponds to the INSTANCE_URL variable in the one-line installer command. The public endpoint refers to the DNS name of the nearest ServiceNow Cloud Services endpoint, which is represented by the value of the ACC_CNC variable in the one-line installer command. For information on the command and the parameters, see Install Agent Client Collector on Windows using ITOM Cloud Services and Perform a single-line Agent Client Collector installation on macOS by using ITOM Cloud Services.

3. The Agent sends registration request to the customer instance.
4. The Agent is registered in the customer instance and issued a certificate.
5. The Agent saves both the issued certificate and the public key used for verifying code signing signatures.
6. The Agent communicates with the customer instance through the ServiceNow Cloud Services by sending messages.
7. ServiceNow Cloud Services determine the correct customer instance to which agent messages must be sent.

Endpoint Discovery

The DEX endpoint has to be first discovered and added to CMDB before DEX metrics can be collected and processed. After the DEX agent is registered, it connects to the ServiceNow Cloud Services and uses the keep alive API to check in with glide. This updates the agent status on the Agent Client Collector Health Dashboard. Glide then pushes Checks and policies to the agent via ServiceNow Cloud Services. Some of the policies trigger discovery and populating the CMDB. For more information on how ACC is used for discovery and to populate the CMDB, see Agent Client Collector for Visibility.

DEX specific policies pushed to the agent inform the agent about the metrics to be collected for SaaS apps, installed apps and the endpoint. These policies first trigger download of Agent Client Collector plugins (that contain scripts and code needed to perform discovery and to collect the metrics) to the agent endpoint via ServiceNow Cloud Services by calling a direct REST API on glide.

DEX Metrics Processing

• The DEX Chrome Extension makes an internal API call to the agent to get a list of SaaS app URLs for which it needs to collect metrics. The DEX Chrome Extension for Chrome primarily focuses on capturing performance metrics such as page load time and response time. It does not capture detailed information about user behavior, interactions, and engagement.
• ACC performs data preprocessing or filtering and sends the collected data to ServiceNow Cloud Services.
• ServiceNow Cloud Services buffers the data in raw metrics topics for further processing.
• The data in the raw metrics topic is then consumed by a stateful stream processing job that performs DEX specific data enrichment, transformation, filtering, aggregation, analysis, or event creation.
• Metric metadata required by the DEX stream processing job is retrieved from Glide.
• The enriched and aggregated data is written to the corresponding topics in ServiceNow Cloud Services.
• The data in these topics is consumed directly by MetricBase which stores it in the DEX MetricBase tables for further analysis.
• Some processed, non-metric data is stored directly in the Glide tables by the stream processing job.
• The metrics data is read from MetricBase to visualize in the DEX dashboard.