In one of my last projects, I had to implement a job scheduler to the IT environment of one of our NetEye customers, whereby a central requirement was that it had to be possible to launch jobs directly from NetEye. The customer had chosen the job scheduler solution from SOS Berlin, which had to be installed on a Linux environment.
Before explaining you how I did the integration, I will shortly explain how the customer is working.
To follow the ITIL best practices, the company’s Help Desk is using NetEye for the identification of problems on the IT infrastructure and the orchestration of the detected problems. If the Help Desk in case of a problem gets an alert, the help desk employees to relaunch certain processes use the so-called ActionLaunchpad module of NetEye. Therefore, for the employees the NetEye GUI is the “single” point of contact to the IT infrastructure: not only for monitoring, but also for restarting processes.
At a certain moment, the customer had the necessity to implement a job scheduler to trigger a sequence of jobs on different systems like Unix, Windows etc. They have chosen the SOS Berlin JobScheduler, for which we, by the way, are also offering consultancy.
One of the main requirements the customer explained to me was that the NetEye GUI had to remain the only GUI, which the Help Desk employees should use. This was because the customer wished to avoid confusing his employees by implementing a new interface for restarting or monitoring scheduled jobs.
For this reason, I implemented different interfaces between the job scheduler and NetEye. This allows that each job scheduled on the job scheduler that failed will create an alert on the NetEye interface. In this way, the Help Desk is able to see the problem and to restart the failed jobs by using the NetEye ActionLaunchpad with which they are already familiar. Hence, for the Help Desk people there is no need to learn in detail the job schedulers’ GUI and configuration possibilities.