Introduction
In some implementations it might be helpful to change some environment conditions in which ARA Actions are executed. This article describes how change the JAVA_HOME environment variable and to switch the Java binary from the users default to specific ARA settings. This will be done without changing ARA Actions nor any settings on the target machines by using Job Header Includes.
Job Headers in the Automation Engine
Automic supplies platform-specific Includes in client 0000. Within Header and Trailer Includes, user Includes are called using the parameter "NOFOUND=IGNORE" in order to avoid errors if these Includes do not exist.
In doing so, individual Includes can be created which are responsible for special tasks during the various stages of job execution. These tasks are then included in Automic processing.
You can take a look at the default Header Includes in client 0 by simply searching for "HEADER" in the Quick Search.
<Please see attached file for image>
align="bottom" class="documentation" title="Search for header includes in client 0" border="0" alt=".png" src="http://ecmstage.ca.com/KB%20Asset%20Library/000008583_Embeded/.png">Examining the HEADER.UNIX Include for example shows the reference to another include which can be created in the different clients to change the behavior of jobs. In this case UNIX jobs. These Includes will be used for every execution of corresponding jobs.
<Please see attached file for image>
align="bottom" class="documentation" title="Unix Include sample showcasing further includes" border="0" alt=".png" src="http://ecmstage.ca.com/KB%20Asset%20Library/000008583_Embeded/.png">The same is true for the other HEADER Includes in their corresponding platforms.
Setting Environment Variables
The Header Includes can be used to do anything right before the execution of a script on the agent/host. In this example it is used to change the environment variables JAVA_HOME and PATH. These changes are not permanent to the user but are only valid for the current run and will therefore not affect any other processes on the target machines.
Hint: Different shells might require different commands to set an environment variable.
First off, a sample job is created which will output the values of JAVA_HOME and will show the java binary as well as it's version:
<Please see attached file for image>
align="bottom" class="documentation" title="Sample job showcasing the changed environment variables" border="0" alt=".png" src="http://ecmstage.ca.com/KB%20Asset%20Library/000008583_Embeded/.png">
Upon execution, one can see the default values of the user in the jobs report. Java 1.6.0.22 is used and JAVA_HOME is set to the correct directory:
<Please see attached file for image>
align="bottom" class="documentation" title="Report of the sample job showing default settings" border="0" alt=".png" src="http://ecmstage.ca.com/KB%20Asset%20Library/000008583_Embeded/.png">
Now a Header Include for Unix Jobs (HEADER.UNIX.USER.START) is created to change the values of JAVA_HOME as well as PATH to switch out the Java binary:
<Please see attached file for image>
align="bottom" class="documentation" title="Custom unix header include to change JAVA_HOM and java binary" border="0" alt=".png" src="http://ecmstage.ca.com/KB%20Asset%20Library/000008583_Embeded/.png">
This Include will automatically be used by all Unix jobs in the client. Therefore no further action is required. After executing the sample job from before again, the report has slightly changed. The java binary is now a version 1.4.2 and the JAVA_HOME was also changed to match the binary:
<Please see attached file for image>
align="bottom" class="documentation" title="Report of the sample job after adding a custom header include" border="0" alt=".png" src="http://ecmstage.ca.com/KB%20Asset%20Library/000008583_Embeded/.png">Adding or changing Header Includes will affect ALL jobs in a client immediately so do this with caution
Adding complexity
Header Includes can not only contain shell or batch scripts, also Automic script can be used. In the above scenario it might make sense to create a Static Variable Object to store different environment variables and settings for different Agents or Host Groups. This will make it rather easy to have different settings for different machines and maybe also different users without changing anything on the target machines nor the jobs which will be executed on those.
In order to adapt the above example, first a Static Variable Object is created for storing the JAVA_HOME settings per Agent. The Agent is used as Key and the JAVA_HOME directory is stored as Value 1:
<Please see attached file for image>
align="bottom" class="documentation" title="Static Variable Object Storing Custom JAVA_HOME Values Per Agent" border="0" alt=".png" src="http://ecmstage.ca.com/KB%20Asset%20Library/000008583_Embeded/.png">
Now the Header Include is adapted to get the value from the Variable Objects instead of a static setting. This will cause the same effect as before but allows for different settings for different Agents:
<Please see attached file for image>
align="bottom" class="documentation" title="Sample Header Include Using Variable Object" border="0" alt=".png" src="http://ecmstage.ca.com/KB%20Asset%20Library/000008583_Embeded/.png">The Static Variable Object can also be exchanged with an SQL Variable Object to get settings from a different system or perhaps with a Backend Variable Object to make it dependent on some files on the target machine.