Skip to main content
SaltStack Support

SaltStack ServiceNow Reactor 1.1

Changelog

The ServiceNow reactor version 1.1 is a bugfix release.  

The following issues have been fixed:

  1. Under very high load the reactor would sometimes never be able to process all the incoming events.
  2. Extensive performance metrics are now logged when the loglevel is set to DEBUG.

Known Issues

The reactor currently sends every event generated on the event bus into ServiceNow.  This was an early requirement for being able to create some ServiceNow workflows, but it is not a workable solution for ServiceNow installations connected to very large or extremely active Salt infrastructures.  This issue will be corrected in a future release.  Please contact Salt support if you feel that your Salt infrastructure is overwhelming your ServiceNow installation and we can provide a workaround.

Support Policy for the Salt-S/N-Reactor

The servicenow-reactor_1.1-1 reactor has been tested and is Support by Salt-Support using the following versions on ServiceNow & Salt:

  • ServiceNow - "Helsinki"
  • SaltStack - 2016.3 Branch
Note: Although the servicenow-reactor_1.1-1 may work on newer version of SaltStack, it is not supported by Salt-Support.

Configuration

  1. Your ServiceNow instance must have the integration update set loaded into it before the Salt ServiceNow reactor can communicate with it.  Follow standard ServiceNow instructions for loading an update set to import the update set .XML file attached to this document before starting the salt-servicenow daemon.

    If desired, the admin ServiceNow user can be used with the ServiceNow Reactor. However, this will grant the SaltStack Reactor admin access to the entire ServiceNow instance and is not recommended.

    Beginning with Update Set 2015.7.16, a user with more limited permissions can be employed by the SaltStack ServiceNow Reactor.
    1. Create a user via the ServiceNow interface.
    2. Give this new user the u_saltstack_user role.

Enter the new user's username and password in the /etc/salt/master config file, as described in the code-block example above.
Any users given the u_saltstack_user role have access to the tables within ServiceNow that are used by the SaltStack application and nothing more.
​​​​

  1. Install the appropriate package (.deb or .rpm) with your distribution's package tool on your Salt Master.  If you have multiple Salt Masters, the daemon should only be running on one at a time.
  2. Next, to configure the Salt Master to use the Salt ServiceNow reactor, the following configuration must be added to the Salt Master's config file:
service_now:
  instance: <instance>
  username: <username>
  password: <password
fileserver_backend:
  - servicenow

For the instance setting, do not include the https:// in front of the instance name.

  1. Start the salt-servicenow daemon via your system's init facility (upstart/systemd/etc.).  You may also want to configure the daemon to start on system boot.
  2. To perform a basic verification that the two systems are communicating, login to your ServiceNow instance and navigate to the SaltStack section in the left menu pane.  Click on 'Salt Minions'

    Screen Shot 2015-08-13 at 9.35.41 AM.png

    Over the next few minutes you should see this view populate with your Salt Minions.  
  3. Keeping salt-servicenow Alive

Beta testing revealed that the ServiceNow endpoints sometimes return strange results--sometimes they allow the reactor to open a TCP connection, but then reset it on the first read ("Connection reset by peer"), sometimes a read produces nothing, and sometimes the ServiceNow side appears to not be listening ("Connection refused"). These exceptions have all been accounted for in the reactor code, and the daemon will retry several times, but all contingencies cannot possibly be forseen.

This is why the systemd and upstart control files shipped with this code restart salt-servicenow if it dies. The Debian-style initscript cannot restart the daemon--pre-systemd and upstart init systems don't have that capability built in.

SaltStack does not want to prescribe a specific background process management system outside of what your distribution may already use. There are a number of choices (daemontools, supervisor, runit, etc) and you should select the one that fits your environment best.

System Requirements

As of version 0.3.0, the daemon has changed its name from snreact to salt-servicenow.

Overview

The Service Now Reactor implements a simple state machine for jobs invoked in Salt via Service Now.

+---------+   +---------+  +---------+
| PENDING |-->|EXECUTED |->| ACTIVE  |--+
+---------+   +---------+  +---------+  |   +---------+
                   |              +-----+-->|RETURNING|--+
                   v              |     |   +---------+  |
              +---------+         |     |   +---------+  |
              |INACTIVE |---------+     +-->| FAILED  |  |
              +---------+                   +---------+  |
                   |                        +---------+  |
                   v                        |INSERTED |<-+
              +---------+                   +---------+
              | UNKNOWN |
              +---------+

Here are what the states mean:

PENDING: Command has been inserted into the u_salt_commands table in Service Now but has not been sent to Salt yet
EXECUTED: Command has been sent to the Salt-master.
FAILED: Job did not run (no targets matched or some other reason)
ACTIVE: Job generated by the command is running
INACTIVE: Job is not running
RETURNING: Results from the job are starting to come back
UNKNOWN: Service Now has a job id for the job, but the Salt-master did not find a result for the job.
INSERTED: Job has completed and the job results have been inserted into Service Now.

  • SaltStack.2015.7.16.xml
    700 KB Download
  • servicenow-reactor_1.1-1_amd64.deb
    20 KB Download
  • servicenow-reactor-el6-1.1-1.x86_64.rpm
    20 KB Download
  • servicenow-reactor-el7-1.1-1.x86_64.rpm
    20 KB Download
  • Was this article helpful?