Architecture and Discovery
About 13% of the CIS-EM exam — see all 5 domains.
This domain is about the moving parts that make Event Management work and how it depends on a well-discovered CMDB.
MID Server
The MID Server (Management, Instrumentation, and Discovery) is a Java application that runs inside the customer network and brokers communication between the ServiceNow instance and on-premise resources. It is the workhorse for both Discovery and Event Management collection. The instance never connects directly into the customer's data center; the MID Server does, and it initiates outbound communication to the instance.
For Event Management, a MID Server runs connectors that collect events. MID Servers have capabilities and applications that scope what work they can do; for Operational Intelligence/metrics you assign the Metrics capability and run the Operational Intelligence (Metric Intelligence) extension. MID Servers can be clustered for load balancing and high availability.
Discovery and the CMDB dependency
Event Management is only as service-aware as the CMDB beneath it. Discovery populates the CMDB with CIs and their attributes; Service Mapping builds the service topology (application services: which CIs support which service). Zurich impact calculation runs for Service Instance [cmdb_ci_service_auto] classes such as application services, not for Business Service or Technology Management Service records. Without accurate CI records and relationships, CI binding fails, topology-based correlation cannot work, and service impact cannot be computed. This is why CMDB health, CSDM structure, and Discovery quality are explicitly part of Event Management architecture.
How events reach the instance
- Push: an external monitor (or script) sends events to the instance or to a MID Server via the web service / REST API. The sender initiates.
- Pull: a MID Server connector periodically queries the external monitoring system and brings events back. The MID Server initiates on a schedule.
Both paths land events in em_event for the same processing pipeline.
Components installed
Activating Event Management installs the event/alert tables, processing jobs, base event rules and subflows, dashboards, and the operator workspace artifacts. Operational Intelligence and Health Log Analytics are separately installed/licensed capabilities layered on top.
Sample questions from this domain
Three of the 39 in this domain, with the reasoning. The full set is in the question bank.
What is the primary role of a MID Server in an Event Management deployment?
- A. To run the Identification and Reconciliation Engine that decides which CIs each incoming event updates
- B. To securely collect events from on-premises monitoring tools and relay them to the ServiceNow instance ✓
- C. To store and correlate alerts locally so the instance receives just the grouped primary alerts
- D. To host the Service Operations Workspace so operators can triage alerts on the local network
Why: The MID Server acts as a secure bridge that collects events from on-premises sources and relays them to the ServiceNow instance, especially for pull connectors. The Identification and Reconciliation Engine runs on the instance, alerts are stored and correlated in em_alert on the instance, and Service Operations Workspace is an instance UI, so none of those are MID Server roles.
In a pull-based monitoring connector, which component initiates the collection of events?
- A. The instance scheduler calls the monitoring tool API directly from the cloud
- B. The MID Server periodically queries the monitoring tool for new events ✓
- C. The monitoring tool pushes events to the MID Web Server extension endpoint
- D. An event rule on the em_event table triggers a fetch of pending events
Why: With a pull connector, the MID Server periodically queries (pulls) the monitoring tool on the connector instance schedule to collect new events. The instance does not call on-premises tools directly, the MID Web Server extension is a push path where the tool sends events, and event rules process events that already exist rather than fetching them.
Which method do push-based event sources typically use to deliver events to ServiceNow?
- A. They send events to the Event Management REST/web service endpoint (inbound API) ✓
- B. They wait for a MID Server connector to query their API on a set schedule
- C. They are imported by a Discovery schedule that runs against the source host
- D. They insert records directly into em_alert so that the event processing stage is skipped
Why: Push sources deliver events by sending them to the Event Management inbound REST/web service endpoint (for example /api/global/em/jsonv2), which inserts records into em_event. Waiting for a MID Server connector to query on a schedule is the pull model, Discovery schedules populate CIs rather than events, and pushed events land in em_event and go through event processing before any alert exists.