The RES Automation Manager Job Execution Tool (JET) and Job Execution Tool Command Line (JETCMD) are part of the Virtual Engine Toolkit and were developed to overcome a particular shortcoming in the RES Automation Manager product suite; unattended job scheduling. These new tools overcome the following problems:
- When scheduling a job unattended you have to specify the target agent that you wish a job to run on as there is no way to flag the “local” machine.
- When integrating RES Automation Manager jobs with RES Workspace Manager you have to supply parameter values up front. There is no way to prompt the user for parameter values from RES Workspace Manager.
- When parameter values are required at run-time, jobs have to be scheduled via the RES Automation Manager GUI.
The main JET utility is a graphical interface, dynamically built around an XML configuration file. Its initial intention was to be able to schedule RES Automation Manager jobs via managed RES Workspace Manager managed shortcuts with the ability to prompt for parameter values. Many customers have asked whether we can provide access to Run Books without granting access to the RES Automation Manager console. Unfortunately for us, there is no way to prompt for RES Automation Manager parameters when integrated with RES Workspace Manager. We can integrate parameters, but they’re a one-way operation and set in stone, i.e. they cannot be changed on the fly only configured up front.
JET overcomes this issue and permits execution of either Modules, Projects or Run Books on the local agent without having to know the local agent’s name, GUID or launch the RES Automation Manager console. If you don’t want the target job to run on the local agent, then it can all be predefined in the target Run Book.
The graphical interface is fully customisable (within reason) so you can change all the wording and even the main graphic if required. This helps end-user adoption as it can be branded with the corporate imaging etc. Here’s an example we’ve used (customer artwork removed!) at the end of the imaging process. After deployment, the relevant departmental applications can be installed by selecting the department:
The purpose of this is tool is slightly different to the GUI version. Whilst the GUI version is all about passing parameters to modules, projects or run books chosen by the end user at run time, JETCMD is all about automation!.
So how is JETCMD.EXE different from the standard WMC.EXE?! There are three big differences:
- To schedule a job via WMC.EXE you have to specify the target RES Automation Manager agent or team GUID. If you just want to schedule a job on the local agent there is no way to specify this. JETCMD allows you to simply specify the local agent without knowing its GUID or name in advance.
- There is no way to pass an encrypted password to WMC.EXE. JETCMD allows you to pass an encrypted password so it’s relatively safe to include in scripts.
- Parameters cannot be passed to a RES Automation Manager dispatcher without the use of a .CSV file. Therefore, it’s difficult to pass parameter values via the command line.
As we’re security conscious we also don’t like specifying the RES Automation Manager console username password in clear text if we can avoid it. Therefore, we allow you to obfuscate the password so users cannot manually open the RES Automation Manager console with credentials embedded in any scripts. Encoding the password is optional so the choice is entirely down to you.
If you do wish to obfuscate the password then you’ll need to use JETPWD.EXE (yet another tool!). This tool is used to generate obfuscated passwords for both JET and JETCMD.
For a brief overview and demonstration of the new features in the Virtual Engine Toolkit v1.2, check out our Youtube channel.
Free to download and NO registration required. Just run the downloaded .MSI file and install in seconds.
NOTE: It does require the Microsoft .Net Framework 4.0 to be installed.