DBI_Dependencies

Overview

This service provides a verification of event(s), whether a specific object has been loaded into the database, or that a process has completed. This process can check for 1 or multiple dependencies, returning the result immediately, or it can be configured to wait until the dependencies have completed before returning. This ensures subsequent processing will not start until all dependencies have completed allowing for comprehensive SQL or audit reporting. Another specific use case allows for status related to SLA reporting. This means processing will continue when a dependency does not exist which is a subtle option, but allows for the process continuation on failure. Subsequent reporting can easily be configured to handle escalation conditions to different user groups, providing custom reporting details.

This process uses the dbi_system_log table in order to determine if the required event has completed. An event is based on the current day (after midnight) in order to determine if it has been completed. If not all of the dependencies are found, the program returns the value 1 which means unsuccessful. If all of the dependencies are found, this program returns the value of 0 which means success. If the ‘Wait For Hours’ option is set to a number > 0, this program runs in a loop every 5 minutes checking for all of the dependencies based on the number of hours specified. Once all of the dependencies are found, this program returns a successful return code. If the amount of time to check for the dependencies is exhausted, then this program returns a failure return code.

Usage

Usage: DBI_Dependencies.sh -f <configuration file name> -n <dependency name> -t <source trigger name> -g <grouping name> -c <cluster_name>

The ‘-t’ option on the command line is used to create another trigger if the trigger you find is found. We typically use this after a set of dependencies are found and we create a trigger on a share used as trigger for BO reports.

This process provides a verification of an event, either that a specific object has been loaded into the database, or if a job process has completed.  This process can check for 1 or multiple dependencies, returning the result immediately, or it can be configured to wait until the dependency has completed.  This ensures that subsequent processing will not start until all of the dependencies defined have completed. Another use case allows for SLA reporting. This means that processing will continue when a dependency does not exist.  Thus, subsequent steps can easily be configured to handle escalation conditions to different user groups, providing custom reporting details. This service is driven by rules in a rules file, no coding is required.

• Allows for the evaluation of events from the table dbi_system_log in order to determine if either a DBI_RS_Loader or DBI_Activate job(s) have completed.
• Executes and returns immediately the requested results; or the process can be configured to wait for the all of the dependencies to be found (a time limit consideration should be included in this case).
• Allows for events that occurred today, or back in time for a specific number of days.
• Allows for a specific number of occurrences to be evaluated.
• Allows for SLA reporting (when used in conjunction with the RS_Activate process)
• Creates a trigger file is required for other downstream processes.

2 execution options

• Command Line (-t option)
  • Minimal or No setup required
  • Only checks for 1 Dependency
• Rules File (-n option)
  • Add rule(s) to rs_dependencies table
  • Allows for multiple events to be checked simultaneously
  • Reusable by other calling processes

ie.  RS_Dependencies.sh -f /rs/admin/sh_scripts/RS_Dependencies_KYC.ini -t public.test_file

• • RS_Dependencies.sh -f /rs/admin/sh_scripts/RS_Dependencies_KYC.ini -n TEST_FILE

When checking dependencies, there are 2 primary scenarios.

• Current status – Checks for dependency of jobs based on current day.  For jobs with multiple runs (Run 1, 2, or 3), this will provide the dependency check based on the current run. 
• History status –  Checks for dependency of jobs over time.

The trigger that determines if the dbi_system_log_history table is included is the options for ‘Check back # of days’ and Chec back # of hours’.  If either are > 0, then the dbi_system_log_history table data is used.