Type of JOBs

Types of JOBs

DMSContainer can handle 2 kinds of JOB: class and shell. Each JOB must have a name which defines the name of the log file, the name of the configuration file and, generally, the name of this job in all the DMSContainer related information. A job can be enabled or disabled according to its enabled property value. In order to be executed a job must be scheduled using a cron-like syntax. All the job information (but the job specific configuration) is stored in the jobsmanager.json file which maintains the jobs configuration in a JSON array of JSON objects. While this is a JSON file, there is an extensions to the JSON format which allows to put comment lines using the # (sharp) character as the very first character of the line.

Every job configuration requires at least the following keys:

  • enabled (boolean) defines if the job is enabled or not
  • jobname (string) defines the name of the job - this name will be used to search the config file and to generate the log files related to this job executions
  • schedule (cron-like scheduling string) defines the scheduling of this job using the cron syntax
  • jobtype (string) can be shell or class and defines the type of the job - if the jobtype is class then other property must be defined (see the paragraphs below)

Jobs of type shell

A job of type shell represents a command line executed at configured time, just like a cron service does. The command can be arbitrary complex and the STD_OUT of the execution is logged in the specific log file. A shell job is defined in the jobsmanager.json file. For instance, the following jobsmanager.json defines a shell job named pinglocalhost.

#SCHEDULE FORMAT:

#<Minute> <Hour> <Day_of_the_Month> <Month_of_the_Year> <Day_of_the_Week> <Year> 

#

#

# The character # (sharp) if encountered at the first col is considered comment. 

# The other lines must be in JSON format.

{
  "jobs":[
      {
        "enabled": true,
        "jobname": "pinglocalhost",
        "jobtype":"shell",
        "schedule": "* * * * * *"
      }
  ]
}

As you can see in the jobsmanager.json file there aren’t information about the actual action/s that the job will do. These information, especially for the shell jobs, are stored in the related configuration file. Reading the previous jobsmanager.json configuration, the DMSContainer engine looks for a file named job.pinglocalhost.config.json in the DMS_HOME conf folder. All the shell jobs must have a specific config file which contains the actual command line to execute. Here’s the config file of the pinglocalhost job.

    {
        "cmd":"ping 127.0.0.1"
    }

As you can see, the only property of a shell job config file is cmd which contains the actual command line to execute.

When a DMSContainer instance runs, it generate a specific log file for this job containing all the STD_OUT and the executions log.

Considering the previous configuration files you can expect to have in the folder DMS_HOME\logs the file dms_00.pinglocalhost.log which contains something similar to the following:

2017-10-28 18:44:00:197  [TID       4952][INFO    ] >> [pinglocalhost] Execute [pinglocalhost]
2017-10-28 18:44:00:198  [TID       4952][DEBUG   ] [ExecuteCMDCommand] [Executing: cmd.exe /C "ping 127.0.0.1"] [pinglocalhost]
2017-10-28 18:44:03:288  [TID       4952][DEBUG   ] [ExecuteCMDCommand] (ExitCode 0):
Esecuzione di Ping 127.0.0.1 con 32 byte di dati:
Risposta da 127.0.0.1: byte=32 durata<1ms TTL=128
Risposta da 127.0.0.1: byte=32 durata<1ms TTL=128
Risposta da 127.0.0.1: byte=32 durata<1ms TTL=128
Risposta da 127.0.0.1: byte=32 durata<1ms TTL=128

Statistiche Ping per 127.0.0.1:
    Pacchetti: Trasmessi = 4, Ricevuti = 4, 
    Persi = 0 (0 [pinglocalhost]
2017-10-28 18:44:03:288  [TID       4952][INFO    ] << [pinglocalhost] Execute [pinglocalhost]
2017-10-28 18:45:00:269  [TID      21180][INFO    ] >> [pinglocalhost] Execute [pinglocalhost]
2017-10-28 18:45:00:280  [TID      21180][DEBUG   ] [ExecuteCMDCommand] [Executing: cmd.exe /C "ping 127.0.0.1"] [pinglocalhost]
2017-10-28 18:45:03:339  [TID      21180][DEBUG   ] [ExecuteCMDCommand] (ExitCode 0):
Esecuzione di Ping 127.0.0.1 con 32 byte di dati:
Risposta da 127.0.0.1: byte=32 durata<1ms TTL=128
Risposta da 127.0.0.1: byte=32 durata<1ms TTL=128
Risposta da 127.0.0.1: byte=32 durata<1ms TTL=128
Risposta da 127.0.0.1: byte=32 durata<1ms TTL=128

Statistiche Ping per 127.0.0.1:
    Pacchetti: Trasmessi = 4, Ricevuti = 4, 
    Persi = 0 (0 [pinglocalhost]
2017-10-28 18:45:03:339  [TID      21180][INFO    ] << [pinglocalhost] Execute [pinglocalhost]

Each line which starts with >> [pinglocalhost] Execute [pinglocalhost] defines the start of the job named pinglocalhost. Each line which starts with << [pinglocalhost] Execute [pinglocalhost] represents the end of the job execution. The standard >> (double closed square brackets) to represent the “start” of something the << (double opened square brackets) to represent the end of something is used very often into the log files.

Jobs of type class

This kind of jobs are the most powerful. While the shell job are, more or less, a glorified cron scheduled command, the class jobs allows to implement complete microservices and deploy them in the DMSContainer environment. A class job is composed by 2 parts: the class job itself and the JSON-RPC API class which can manage and handle all the information related to the job itself. The job class and the RPC class must be implemented in Delphi and packaged as BPLs. Let’s talk about the class job seeing an actual configuration related to the very powerful email job extracted from the jobsmanager.json file.

#

# DMS CONTAINER JOBSMANAGER CONFIG FILE

#

# SCHEDULE FORMAT: 

# <Minute> <Hour> <Day_of_the_Month> <Month_of_the_Year> <Day_of_the_Week> <Year> 

#

#

# The character # (sharp) if encountered at the first col is considered comment. 

# The other lines must be in JSON format.

{
  "jobs":[
#

# This is ready-to-use class-job able to send emails which provides a powerful rpc manager class

#

    {
        "enabled": true,
        "jobname": "email",
        "schedule": "* * * * * *", 
        "jobtype":"class", 
        "jobclass":"Jobs.Email.Job.TJobEmail",
        "rpcclass":"Jobs.Email.RPC.TEmailRPC",
        "rpcuri":"/emailrpc"
    }
  ]
}

With this configuration the job email will be executed every minute (as schedule property defines). The actual job is represented by the class Jobs.Email.Job.TJobEmail which inherits from TCustomJob and overrides the method named DoExecute. The actual job is done by the DoExecute method.

If the job provides an RPC API, the class that implements this API must be configured in the rpcclass property. In this case the JSON-RPC class is Jobs.Email.RPC.TEmailRPC which inherits from TCustomRPC base class.