Introducing Critical Events

Sat, 12/08/2018 - 11:40 By Dave Brooks

Not long ago, we were discussing a customer's technical issue here in the office. It seems that three of their Windows printers had gotten out of date, perhaps behind on driver updates or related problems. Anyway, when they scheduled a job in RPM Remote Print Manager® (RPM) to print to one of these devices, RPM suffered a failure.

However, the only symptom in RPM evident to the customer was that jobs weren’t printing. Further, they didn’t even know they had a problem with their Windows print drivers.

In our defense, the printer definitions were in such bad shape that if you selected one of them in a regular Windows application, Windows put up an error message that they were “driverless". We literally had never heard of this before, and I regret we don’t have a screenshot to share.

Nonetheless, it became instantly clear that we needed a better way of notifying the user regarding a category of more severe errors.

How to view critical events

In the user interface, go to the View menu. 

View menu

A sample critical event

Here is a sample critical event dialog from a recent post:

Critical events, device errors

Critical events, device errors

The category shown is a descriptive term from RPM. The date and time in the second column are when this event was encountered. The message is an attempt to describe what happened. None of this information suggests that RPM itself had an error. Rather, something happened that RPM needs to report.

To remove entries from this list, select one or more and click "Delete". Until you do that, the messages will remain.

The premise for a critical event

In our view, what makes an event significant is that it affects the outcome of your job processing, and you should know about it.

A critical event may require intervention from the administrator. Typical measures would include a configuration change, such as updating the login credentials for a user account in RPM after it they updated it in the “real” world of the Windows domain.

Another critical event may warn you that job processing failed, but RPM will attempt it again, and maybe it will work the next time. For instance, if RPM warns you that disk space is low, but in the interim, someone manages the disk space, then a future retry may succeed.

Another critical event may warn of an exception. It may be our code failure or an unexpected error return from Windows (which happens).

Yet another critical event may warn you that you need to stop the service and perform database maintenance

How do we notify about critical events?

We used the event handling system in RPM that we use for nearly everything already. With it, we can generate an event, then create handlers in the code to do something meaningful in the context of that handler.

We set up a database handler that will write the critical event to a new database table we created, called “alerts.” If your database does not have this table for any reason, the handler will generate an event log message, so you’ll still get the critical event by opening the Event pane in the user interface.

We created an email handler that will use the alert settings to send an email. To configure the alert settings (“from” and “to” plus others) go to the user interface, go to Configure / Notification Settings.

Please note that we take every effort not to duplicate critical events, so if a device is offline, you should not get 10,000 messages about it in your inbox.

Finally, if the RPM user interface is running, it will pop up the Critical Events dialog. You can also use the View menu as described above.

What are the current critical events?

  1. If RPM attempts to execute a user login to prepare for a device or action configured to use login credentials, and that login fails
  2. When someone sends a print job referencing a queue that you have not already created in RPM, you'll see the critical event and whether or not RPM allowed it
  3. If you send a job to the AppSocket port and there is no setup for that port, including printer emulation data
  4. If the device tester fails a device for any reason
  5. For any number of specific printer related issues
  6. If a database operation results in an error message returned from the database, or if there is an exception processing the request; this includes updates, inserts, deletes, and queries
  7. For the following license-related errors:
    1. The product code in the license does not match the product currently running
    2. If any of the licenses return an error on open
    3. If a license trial expires
  8. If the network code detects that the MAC address has changed from the last time RPM ran
  9. Any error reported by the PCL to PDF transform process
  10. Once every 10,000 new print jobs, RPM will remind you to perform database maintenance
  11. The LPD protocol module will report wrong input if it receives an LPD request that is out of bounds; this may happen when someone sends a print job directly to the LPD printer port or uses a security scanner that sends web requests
  12. If a transform takes an exception during job processing