Capital Software began development of a software product named enterprise-Q in 1998 and still continues to enhance and support it today. One of the core components of enterprise-Q is the backend queuing server call eQ Server. eQServer is a TCP/IP-based server daemon used to initiate, track, throttle, retry, and report on thousands of “transactions”. An eQ Server transaction is the execution of a program/script given a “target” for the script. A target can be anything, such as system name, IP address, agent, web server, user, etc. Companies have used eQ Server to execute literally tens of millions of transactions, automating their entire enterprise management operations around the eQ Server..

Here are a few functional examples of what a transaction script/program may do:

  • Run a task on a remote system
  • Ping a host
  • wget a web page and measure response
  • Push monitors and/or pull monitoring data to/from a remote system
  • Software distribution
  • Inventory

enterprise-Q was originally developed to integrate with IBM Tivoli software. However, eQServer has never been Tivoli-centric. That is, eQServer is independent, stand-alone software that can run on any platform that supports Perl 5 and has been deployed in production environments running on Windows, Linux, AIX, and Solaris. As such, we provide pre-built distributions of eQServer here on our Downloads page.

If you’d like to build eQServer or contribute to its development, the source code is available on GitHub.

Queuing Features: Some of the features offered include:

  • Priority – Set target and/or transaction priority
  • Throttling – Control how many transactions can run simultaneously
  • Batching – Group more than one target per transaction
  • Retry – Retry transaction x number of times or until time certain
  • Timeouts – Set the length of time a transaction can run before considering it failed
  • Scheduling – Initiate transaction immediately, on a scheduled basis, or automatically when the target becomes available (i.e. ‘wakes up’)
  • Dependency – Ensure a transaction succeeds before trying another transaction in the queue for the given target
  • Reporting – Results of all transactions are stored in the embedded SQLite RDBMS

Example: Here’s a typical example for leveraging eQServer:

Problem: You’ve got to run a script for every computer in your network.  General requirements include:

  • Track successes and failures
  • Send an email for each failure
  • Retry failures
  • Generate reports on a regular interval
  • Run no more that 25 instances of the script simultaneously as to not impair system/network performance

Solution: Install eQServer to handle all the gory details of tracking, reporting, retrying, throttling, etc.  Then write a simple script/program (for example,MyScript.pl) that:

  • Takes a computer name, and any additional command line arguments required by the script (for example, MyArg1), as input,
  • Runs various commands to accomplish goal (send files, push down monitors, SNMP I/O, ping, SOAP calls, application commands, etc.),
  • Prints the results to standard output/error
  • Exits with success (0) or failure (non-zero).

Queue and Initiate Transactions: Now,queue the script (transaction) for your targets (e.g. node1, node2, and node3), and let eQServer handle all the deployment details.  For example, run the following command that uses the EQMsg utility:

<eq>/bin/EQMsg “t_msg=add;t_dispatch=1;t_trans=MyScript;t_exec=/path/to/my/MyScript.pl;t_targets=node1,node2,node3;t_targettype=Device;MyArg1=arg1″

In this example, three (3) transactions would be queued; one for each target (node1, node2, and node3).  The transactions would initiate (start) immediately since we included t_dispatch=1.

Check the Queue: Check the queue status by running the following command:

<eq>/bin/EQMsg “t_msg=readq”

Ones that succeed will be popped off the queue, while ones that fail will stay in the queue until they are dispatched again.

Retry Failed Transactions: Let’s say node2 failed.  To retry transaction queued for this target, we need to ‘dispatch’ the target by running the following command:

<eq>/bin/EQMsg “t_msg=dispatch;t_targets=node2″

Upon receipt of the dispatch message, eQServer will check the queue for transactions queued for the given target(s).  The first transaction in the queue is initiated.  If it succeeds, the next transaction in the queue for the target is initiated.

Get More InfoFor extensive information about eQServer, download the eQ Server Technical Reference Guide