DBI_Activate
Overview
This process allows for the scheduling of jobs, which provides many features and proven stability. But if you want to incorporate your own scheduler into this framework (ie. Apache Airflow), then this is supported likewise.
The DBI_Activate process allows for any Linux command, shell script or SQL job to be executed. Some significant benefits using this process are as follows:
- No Linux scripting knowledge is required
- All error handling, logging and email/text notification processing are integrated automatically. This is significant as both novice and expert developers can use this process and focus on the core commands required, leaving all of the standard enterprise commands to the DBI_Activate process.
The DBI_Activate service is actually a code generator producing a self-contained executable shell script on demand when a job is initiated. Because the only requirement is the core Linux commands, this service can be used to generate all of your enterprise ready scripts. These generated scripts comply with the rigor demanded by Enterprise Architecture standards, eliminating those rogue, non-compliant scripts that typically lack basic logging and error handling. Changing the core Linux commands is simple, and as this service generates a new well-formed executable shell script before every execution, the changes become dynamic in the newly generated script created.
The status of all jobs is maintained in a standard system log table for additional signaling, reporting and trending. Several predefined standard views are available in the MySQL DB.
Execution Options
Once you enter a row in to the table dbi.dbi_activate and save it to the database, this schedule (or rule) is ‘live’ and will automatically execute DBI_Activate process is configured and running using the DBI_Services_Manager. The other option for executing a job is to run it at the Linux command line.
$ DBI_Activate.sh -f /rs/admin/sh_scripts/DBI_Activate.ini -i DEMO
Once the job is executed, a trigger file is created in the folder /opt/dbi/triggers. The job will not run again in the current day, although you can remove the trigger which ultimately allow the job to execute again. Another option for restarting a job is to use the table dbi.dbi_activate_restart. More details regarding this option is available on the page DBI_Activate_Restart.
If you need to run your job repetedly throughout the day, reference the page DBI_Activate_Repeater. Note that the job still needs to be defined in the dbi.dbi_activate table first.
Table Rules
When you have a job you want to execute, the details can be applied to a row in a MySQL table dbi.dbi_activate. Once the row is saved to the database, and if the date and time for executing is met, the job will start. The below defines the detailed attributes.
- Job_Name – Job name from DBI_Activate
- Activate_Flag (Y/N) – Determines if the job should be actively evaluated for execution
- Numeric_Date – A numeric representation of a specific data to execute the job ie. 20190101
- Input_Day (1-31) – A day of month
- Sun (Y/N) – Indicates if the job should run on this day
- Mon (Y/N) – Indicates if the job should run on this day
- Tue (Y/N) – Indicates if the job should run on this day
- Wed (Y/N) – Indicates if the job should run on this day
- Thu (Y/N) – Indicates if the job should run on this day
- Fri (Y/N) – Indicates if the job should run on this day
- Sat (Y/N) – Indicates if the job should run on this day
- Start_Hour –This is the hour/min the job will start execution
- Email_Success_Notify_Job – If the job is successful, the email address in this field will receive an email
- Email_Failure_Notify_Job – If the job fails, the email address in this field will receive an email
- Business_Job_Name – This is metadata that can be used for reporting
- SLA – This is metadata that can be used for reporting
- Track1…Track5 – This is metadata that can be used for reporting
- Notes – This is metadata that can be used for reporting
- CMD1…CMD50 – Allows for Linux commands, shell scripts, or SQL jobs to be executed