We will be creating an ODI OS command with the below script that will allow us to stop the BI services:
This script will call the script wlst.sh with the variable value as stop. The content of run.sh will be:
$MW_HOME/oracle_common/common/bin/wlst.sh mydeploy.py stop
The parameters required for wlst.sh can be passed and set via other supporting (usually ".py") files as described here.
We will be creating an ODI OS command with the below script that will allow us to start the BI services:
This script will call the script wlst.sh with the variable value as start. The content of run.sh will be:
$MW_HOME/oracle_common/common/bin/wlst.sh mydeploy.py start
The values for start and stop are passed over from run.sh. Using the above variables for stop, start and Middleware home further means we have an increased flexibility and these variables can be refreshed using ODI variables in the package from a database control table. Thus this code will run fine in every environment without requiring any change, since the values are already set specific to each instance in our database control table with the appropriate values.
Another advantage of having the start and stop mechanism through ODI is utilizing the daily executing statistics to predict the completion time of the job. Usually the execution time tends to vary over a period of time and often shows a pattern, i.e. the job might take longer on specific days of the months, or might be increasing by a few minutes every week. These can be considered in a ETC (estimated time of completion) calculator procedure that can simply calculate the expected end time of the job using our custom algorithm. This information is often extremely handy in crunch situations and puts the static history data to good use for all. There goes some small AI stuff again!
How do you automate your BI service related activities and downtime maintenance?