Message Monitoring via the web

There are a number of message monitoring products out there for the IBM i which have been around for a long time. While were were looking at the remote monitoring possibilities using the Nagios/NEMS for Linux solutions we investigated how we could add some kind of immediate message signalling to the solution. Using one of the existing products was an obvious option but that would require additional investment on the clients part plus we would have to somehow integrate with a product we knew nothing about.

We wanted something that would be easy to use and just fulfill the needs of the monitoring solution plus not have too many options which make it difficult to implement. The aim is to provide a remote monitoring solution for our customers specifically for HA4i but also add some limited systems management capabilities. Another requirement was to be able to send a configured response to the messages or request a response to messages via the web using your phone or web browser on a PC.

After discussing some of the basic principles with a couple of partners they also suggested some kind of exit program capabilities so they could add some kind of resolution process of their own for specific messages, as we were going to rely on that for our own design it would be a simple addition. The web server is something that worried us at first because setting up a web server for every client would be a problem, it would be possible to build the server using each clients infrastructure, but we decided that if we could provide a central server and allow segregation of the message handling by customer, it would reduce complexity for the clients plus allow us to manage updates to the server configurations and database without trying to figure out each client environment on their systems.

The notification process needed to support but SMS text and Email based notifications. We have built and tested both solutions in various product trials but none had the ability to do either option together. We would therefore need to build something that would join both options, this would rely on an address book where the users contact information would be stored. There are previous posts on this blog that show the basic principles of each solution and we have posted Open Source code on GitHub that shows how we did it, just search the blog for more information if you need it.

The main interface will be UIM based 5250 screens as we see this more as a tool than an application. The HTTP interfaces for message handling are built using PHP, Javascript and CSS so they can be altered to meet peoples visual needs. The back end Database is MySQL with NGINX as the server. We called the product EM4i (uses the same convention as our other product) but that may change as we move forward because at the moment we are just in the proof of concept stage.

Operations menu

Once we get the product design settled we will create a manual explaining each of the steps but in short the product needs the following steps to be carried out prior to starting the servers which monitor the message queues ( we also allow monitoring of joblogs and hope to add LIC monitoring as well at some time).

  • Install LPP
  • Configure the web server and database information
  • Add the SMS provider details (by country)
  • Configure the user connection information
  • Add message queues and messages to be monitored
  • Add any job monitoring information
  • Start the servers.

To test the process we have built a couple of programs that will send messages to the message queues and either wait for the response (via the web interface) or send an automated response to the message if required. They also send notification messages that do not need responses. The jobs that send the messages need to be submitted to ensure the messages are seen via the QSYSOPR message queue (not much point in monitoring a user message queue as the inquiry messages are sent to the users screen).

Submitting an inquiry message

The message is immediately sent to the QSYSOPR message queue wanting a response as can be seen in the following screen.

QSYSOPR Message Queue

The server will also automatically send the message out to the person configured to receive the message, in the case it is via SMS to a cell phone. Here is a capture of the phone when the message is received.

Message received on iPhone

When you click the link on the phone it will open your browser and display the message that was sent plus list the valid responses to the message.

Message information and valid responses
Response has been sent

Now when you check the QSYSOPR message queue you should se the following.

reply received

The same process is followed for email notifications in that a link to a web page is sent to the configured email address, the web browser on your PC is a lot bigger so the screen shots would reflect that, but in principle its the same information that is presented.

We are still working on the complete product design and toying with the best way to add the capabilities into the solution we are building for the Nagios/NEMS for Linux products so we are not ready to make it available at this time. If you want to be part of the beta testing let us know we will be happy to discuss what we are doing and look at any additional features that come up during our discussions.


Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.