In nearly a decade supporting enterprise software, I’ve learned there is a three-word phrase that customers rarely like to hear. The phrase is: “working as designed,” which is what many software vendors say when they don’t want to deal with a customer’s unique challenges. But it doesn’t have to be so cringe-worthy. “Working as designed” can be either a negative or a positive thing, depending on who designed the software.
At LRS, we know that large enterprises have complex IT environments, and no two are exactly alike. We design our products with this understanding in mind, so we can address unique application and operational requirements through varying levels of customization. This capability provides significant business value for our customers, and it demonstrates the flexibility of our product architecture. Let me give you an example of what I mean.
I have spoken with customers who want the ability to receive notifications whenever a printer contains more than a specified number of jobs in the VPSX Output Queue. Why? Because when a printer has a large number of jobs in the Output Queue, it often signals a growing problem with the print queue or that printer. Instead of waiting for the issue to be reported by a user, some proactive administrators would like to start resolving the backlog before users begin to notice the problem in the first place.
In the standard Dashboard view of our VPSX product, you can set a Queue Minimum mask on the Printer List to display this type of information. That would be useful info for any administrator who was logged in and actively monitoring the system. But what happens when they aren’t logged in and watching the network? While VPSX software has the ability to send printer-based email notifications, the customer was looking for something a little more specific to their needs. A simple print queue management tool that could warn if print queues were becoming overloaded. Less of a full-blown print queue manager than the proverbial canary in a coalmine.
To address this situation, I wrote a Perl script that uses our LRS SOAP API and a VBScript that uses the VPSX API to scan the list of defined printers and look for ones that meet or exceed a specified number of jobs in the Output Queue. When these conditions are met, the system sends an email to the VPSX administrator. Information about the printer, including SNMP information, is included in the email to help you determine what might be causing jobs to back up. You can use the Task Scheduler in Windows or a cron job for UNIX/LINUX platforms to run this script as frequently as you would like.
To prevent notifications from being sent for specific printers (PERSONALQ printers for example), you can either specify an excluded printer list in the script or add NOTIFY=N to the Contact field of a VPSX printer. You can also add SNMP=N to the Contact field of a VPSX printer to disable SNMP gathering for a specific printer. You will likely want to do this for printers that do not support SNMP or that have SNMP disabled to prevent error messages being written to the VPSX log.
When using SOAP scripts, you can specify a VPSX ID mask to limit which printers will generate notifications. Better yet, you can set up a new ServerX User specifically to use with this script and control which printers to monitor with ServerX Printer Security. For the VPSX API script, you can only point it to one VPSX instance at a time with the VPSX URI.
There is more information about the structure and some tips in the comments sections of the script. There are two versions of each; one that can accept command line options (QueueMonitor.pl; QueueMonitor.vbs) to override the values set in the script and a second one that does not accept command line options (QueueMonitor_noargs.pl, QueueMonitor_noargs.vbs). I created this with Perl to limit the number of dependencies and just mirrored that concept with the VBScripts.
I have shared this script with my other technical colleagues at LRS in case they run into customers with a similar need. Likewise, these co-workers frequently share their own custom scripts and modifications with me and other LRS staff. In fact, we maintain a library of such special-purpose scripts that enable us to take full advantage of the flexible VPSX architecture.
Through the use of the Windows API, Java API, and SOAP API, the ways you can interact with the VPSX application are endless. The ability of this architecture to address unique customer requirements is a positive example of “Working as designed.” If you are interested in this or other special-purpose scripts, please contact LRS and let us know how we can help you provide better, more reliable service to your end users.