Using the producer framework for outbound notifications

  • Release version: Zurich
  • Updated July 31, 2025
  • 2 minutes to read
    • Summarize
    Summarized using AI
    This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.

    Summary of Using the producer framework for outbound notifications

    The producer framework in ServiceNow enables outbound notifications by capturing events within the instance and sending them to external systems. Notifications are consumed through a messaging service installed on the external system, facilitating seamless integration and communication.

    Show full answer Show less

    Key Configuration

    To utilize the producer framework effectively, specific system properties must be configured. These properties govern how outbound notifications are processed, batched, logged, and transmitted. Important properties include:

    • Logging level (snapinotifmgmt.event.log): Defines the verbosity of debug logs for notification events, ranging from critical errors to detailed debug information. Default is "err".
    • Publisher message bus configuration (snapinotifmgmt.publishermessagebusconfiguration): Specifies whether to use Hermes Messaging Service, Open Message Bus, or both for message publication. Default is "openMessageBus".
    • Inbound queue batch and record limits (snapinotifmgmt.inboundqueue.batch.limit, snapinotifmgmt.inboundqueue.maxrecords): Control how many records the scheduler processes per batch and per run, affecting throughput and processing time. Defaults are set to 200 but can be adjusted based on needs.
    • Mutex lock attempts and wait times (snapinotifmgmt.glide.mutex.script.maxspins, snapinotifmgmt.glide.mutex.script.spinwait): Define the retry behavior when acquiring locks on queue records to avoid conflicts during processing.
    • Scheduler max runtime (snapinotifmgmt.schedule.max.runtime): Sets the maximum duration the scheduler job is allowed to run before failure to ensure timely processing.

    Proper tuning of these properties is essential to balance processing efficiency and system resource usage.

    How It Works

    The framework operates by:

    • Picking up event records from a staging table at scheduled intervals.
    • Sending Glide snapshots of these events to an event processor.
    • Converting Glide snapshots into TMF 688 compliant event payloads, tailored to event types, such as trouble tickets.
    • Determining the appropriate messaging service (Hermes Kafka or Open Message Bus) for dispatching notifications based on configuration.

    This workflow ensures that outbound notifications conform to industry standards and are reliably delivered to external systems.

    Practical Implications for ServiceNow Customers

    By configuring and leveraging the producer framework, customers can:

    • Automate the delivery of event notifications to external systems, enhancing integration and real-time communication.
    • Customize notification processing parameters to suit workload and performance requirements.
    • Ensure notifications are formatted to TMF-compliant standards, supporting interoperability.
    • Choose the most suitable messaging bus technology for their environment, whether Hermes, Open Message Bus, or both.

    For detailed developer guidance and advanced configuration, customers are advised to consult the Producer Event Notification Framework developer guide and related documentation on producing outbound API notifications.

    The producer framework picks the event from the ServiceNow instance and sends the outbound notification to the external system. You can consume the details of the notification from the messaging service that is installed in your external system.

    System properties

    You must configure the system properties to use the producer framework for outbound notification. The following table explains the list of system properties that are set for the scheduled jobs.

    Table 1. Producer framework system properties
    Property Description Type
    sn_api_notif_mgmt.event.log
    Level of logging to be written to the debug logs. You can select the following logging levels:
    • emerg: Total failure.
    • alert: System corruption of a database, for example.
    • crit: Typically used for hardware errors, for example.
    • err: Any errors.
    • warning: Any warnings
    • notice: Possible action required but not essential.
    • Info: No action required.
    • debug: Generally not used except for capturing everything for fault-finding.

    Default value: err

    		 String
    sn_api_notif_mgmt.publisher_message_bus_configuration Defines whether messages are published using the Hermes Messaging Service, the Open Message Bus, or both message buses. You can use the following values:
    • openMessageBus
    • hermes
    • both

    Default value: openMessageBus

    		 String
    sn_api_notif_mgmt.inboundqueue.maxrecords Maximum number of records that the scheduler will pull from the inbound queue for one scheduler run. This value is used in conjunction with the sn_api_notif_mgmt.inboundqueue.batch.limit parameter.
    • Default value: 200
    • Other possible values: As needed

    For example, if the batch limit is set to 50 and the maxrecords is set to 200, and if the number of records that are in the inbound queue is 130, then the scheduler would pull three different batches of records in a single run; two with 50 records and one with 30 records. If the number of records in the inbound queue is 220, the scheduler would pull four batches of 50 records and the remaining 20 records would not be processed until the next time the scheduler runs.

    When setting this value, you must also consider the time that it will take for the scheduler to process multiple batches and set the sn_api_notif_mgmt.schedule.max.runtime value accordingly.

    		 Integer
    sn_api_notif_mgmt.inboundqueue.batch.limit Number of records that the scheduler pulls and processes from the inbound queue at one batch.
    • Default value: 200
    • Other possible values: As needed
    		 Integer
    sn_api_notif_mgmt.glide.mutex.script.maxspins Maximum number of attempts to acquire a mutex lock in the inbound queue records.
    • Type: Integer
    • Default value: 100
    • Other possible values: As needed
    		 Integer
    sn_api_notif_mgmt.schedule.max.runtime The maximum time, in milliseconds, that the scheduled job can run before it fails and reports an error.
    • Type: Integer
    • Default value: 90000
    • Other possible values: As needed
    		 Integer
    sn_api_notif_mgmt.glide.mutex.script.spinwait Maximum Time, in milliseconds, to wait between attempts to acquire a mutex lock on the records in the inbound queue.
    • Type: Integer
    • Default value: 100
    • Other possible values: As needed
    		 Integer

    Producer framework workflow

    When the system pushes an event to the staging table, the following steps take place as part of the producer framework mechanism:
    1. The scheduler picks a number of records at a preconfigured interval and then sends Glide snapshots to the event processor.
    2. The system converts the Glide snapshot to a TMF 688 complaint event payload based on the event type.

      To learn more about the methods used to define and generate the TMF-compliant payloads for trouble ticket events, see TopicAPIUtilsOOB - Scoped.

    3. The system checks whether the notification configuration is intended for Hermes Kafka or the open message bus.

      To learn more about configuring the producer event notification framework, see Producer Event Notification Framework developer guide.