MID Server to instance bridge for snmp trap event forwarding

luispeixoto
Tera Contributor

a week ago

Hello everyone!

 

I would like to know a bit more about how a Mid Server forwards events (generated from snmp traps) to the instance. This is our current setup:

External monitor tools send snmp trap messages to our Mid Server. We have uploaded some MIB files that will basically translate the data from the snmp messages into human readable data. This data is then forwarded from the MID Server to the instance under an event type of format. We want to intercept this event before it is inserted in the em_event table. I have already tested this with push connectors and it works, however push connectors execute only from a specific api endpoint (usually the /sn_em_connector/inbound_event api) and this is where my questions lies. Do mid servers perform api calls to create event records directly in the em_event table? If so, what is the out-of-the-box endpoint? Also, where in the mid-server is this configured (some config file im assuming)?

 

Thank you very much for your time in advance!

0 Helpfuls
  • 380 Views
4 REPLIES 4

Connectmustaq
Giga Guru

a week ago

Hi @luispeixoto ,

 

Mid Servers forwarding SNMP trap events to the ServiceNow instance do so by receiving traps, translating them (often using uploaded MIB files), and then sending those events to the instance. However, the Mid Server does not create event records directly via a standard REST API call that you can easily intercept, like the push connectors do.

Here are the key details relevant to your questions:

  1. The Mid Server SNMP Trap Listener extension listens for SNMP traps and translates them into event data using MIB files.

  2. The Mid Server forwards events to the ServiceNow instance by invoking internal mechanisms that insert records into the em_event table.

  3. Unlike push connectors, which explicitly use API endpoints such as /sn_em_connector/inbound_event, Mid Server event forwarding uses a lower-level, internal ServiceNow protocol and does not rely on a documented public API endpoint.

  4. The actual forwarding process is part of the MID Server's internal Java-based processes configured within its files and scripts, not through a configurable API URL like with push connectors. This means the event forwarding is automatic and not something you configure by setting an API endpoint.

  5. If you want to intercept events before insertion into em_event, the recommended way is to use event rules and transforms in ServiceNow or to develop business rules on the em_event table in the instance. Since the Mid Server forwards events internally, you cannot intercept the raw SNMP trap in-flight at the API level.

  6. The closest mention of endpoints in context is for push connectors or inbound REST integrations, but Mid Server events from SNMP traps are processed differently.

In summary, Mid Servers do not perform REST API calls to create event records in the em_event table via a known public endpoint. The forwarding is handled internally by the Mid Server’s core event processing architecture. To intercept or manipulate events, design event rules, business rules, or transformations on the instance side after the event is created.

If you want to explore more on the MID Server SNMP Trap Listener and event collection configuration, look at the MID SNMP Trap Listener and Event Management docs and community discussions about the MID Server event bridge.

please mark the answer as correct and helpful based on the impact!!

 

 

Kind Regards,

Shaik Mohammed Mustaq

 

luispeixoto
Tera Contributor
In response to Connectmustaq

a week ago

Thank you for your reply! I also though of a before business rule in the em_event table, but ServiceNow does not recommend this at all (business rules will have a significant performance impact). As an alternative, push connectors seem to be the most reliable solution. I can say that, at least in my instance, events generated from SNMP Trap messages are being created by a custom integration user account. This means that these are definitely being created via rest API, using the api/global/em/jsonv2 endpoint which is OOB. Im a bit confused on how this was achieved, but will keep looking and post my updates here. 

0 Helpfuls

Connectmustaq
Giga Guru
In response to luispeixoto

a week ago

Hi @luispeixoto ,

 

Your observation is correct — events originating from SNMP traps are created in the instance using a REST API call, and not directly inserted into the em_event table. The behavior you’re seeing (records created by a custom integration user) occurs because the MID Server sends those events to the out‑of‑box REST API endpoint /api/global/em/jsonv2 using the credentials assigned to an integration user on the instance.

How the Integration User and API Call Work

  1. Integration Account Usage

    • The MID Server uses the credentials of the integration user configured within its context or extension in the Event Management connector setup.

    • Typically, this user has the evt_mgmt_integration role and Web service access only flag enabled, limiting it to REST interactions.​

    • Every event arriving via SNMP traps therefore logs that integration account as the "Created by" user in the em_event table, which aligns with what you observed.

  2. Outbound REST Calls from MID to /api/global/em/jsonv2

    • After receiving and parsing SNMP traps, the MID Web Service Event Collector Context sends HTTP POST requests to your instance through the endpoint:

       
      text
      https://<instance>.service-now.com/api/global/em/jsonv2

    • The MID authenticates to this endpoint using the configured integration account credentials (either basic auth or API key, depending on configuration).​

  3. Configuration Location in MID and Instance

    • The user credentials and authentication settings are defined in the MID Web Server Context or Event Collector Context, not the config.xml.

    • You can review or modify these within your instance:

      • Navigate to Event Management → Integrations → MID Web Server Contexts

      • Locate the record linked to your MID

      • Check the Authentication Type and associated User Credentials

    • The MID then uses these parameters to authorize outgoing event API calls back to your instance.​

  4. Authentication Mechanisms

    • ServiceNow supports multiple authentication methods for inbound event posts:

      • Basic authentication with username/password.

      • Token-based authentication using the x‑sn‑apikey header.

      • ServiceNow’s API Access Policies feature can restrict which endpoints and users are allowed access (found under System Web Services > API Access Policies > REST API Access Policies for /api/global/em).​

In short, your MID Server forwards SNMP trap events to /api/global/em/jsonv2 as HTTP POST requests authenticated by an integration user account configured under the MID Web Server Context. That’s why these events appear as created by that user — it’s performing the REST API call that results in the record creation.

 

You may find below thread helpful:

 

please mark the answer as correct based on the impact!!

 

Kind Regards,

Shaik Mohammed Mustaq

0 Helpfuls

luispeixoto
Tera Contributor

a week ago

Thank you for your reply! I also though of a before business rule in the em_event table, but ServiceNow does not recommend this at all (business rules will have a significant performance impact). As an alternative, push connectors seem to be the most reliable solution. I can say that, at least in my instance, events generated from SNMP Trap messages are being created by a custom integration user account. This means that these are definitely being created via rest API, using the api/global/em/jsonv2 endpoint which is OOB. Im a bit confused on how this was achieved, but will keep looking and post my updates here. 

0 Helpfuls