Start using the Job Runner today

How do you handle big, time consuming, scripted jobs in the HyperPoint Scripting Service? When an operation consumes the single-threaded HSS process for longer than desired, other scripts may not execute in a timely fashion.

Do you want to utilize custom .NET assemblies from within CygNet’s VBScript environment?

What if you could do both, right now, from the HSS, with a few simple lines of script?

Good news. You can!

Let’s discuss how easy it is to get stared with the Job Runner.

In case you are not yet familiar with the Job Runner, check out Walter’s announcement of its release here.

So what can Job Runner do? The better question is what can’t it do?

All you need to know about Job Runner is covered in the fantastic Job Runner Help file (included with the install) but here are some snippets for easy reference.

Use the Job Runner to improve the efficiency of an HSS by taking long-running scripts and having them run on multiple concurrent threads. Yay!

Studio screens not being as responsive as you would like during script execution? Improve responsiveness of a Studio Screen by executing script activities on a thread separate from the UI thread.

Want to execute methods on a .NET assembly in the HSS and/or Studio? Feel free!

How does Job Runner work?You’ll have to ask Walter and/or Blake if you want the down and dirty specifics, but for our purposes, let’s go with, the Job Runner executes a VBScript or a .NET assembly method on a separate thread and stores status so you know if the work was completed successfully or not.

Keep in mind that because the Job Runner uses a separate script engine it will not have access to shared objects in the HSS or Studio (like the Facilities or Points object) unless you make sure to include them.

For this example, we’ll use Job Runner to run a VBScript stored in a .vbs file on our local machine.

In total we will need three points for Job Runner to execute a .vbs file on the local machine.

An HSS point with the VBScript to be run

A trigger point (to be used for automation)

A status point in the UIS to display the status of the job

This is a fairly common usage for Job Runner and is probably the one most likely to have immediate applicability in your system, this example will cover just one possible configuration method; we could use Job Runner to execute a script stored in an inactive HSS point, a .vbs file stored in the BLOB, or we could be calling a .NET assembly method. We don’t need the trigger point if we are using Job Runner outside of CygNet (we could simply add the job to Windows Scheduler as part of a batch file, for example), and the status point is optional as well. Really we could do with just two HSS point, the script, and the trigger, though being able to check on the status of each running job is helpful so we’ll leave it here.

CygNet Job Runner offers a lot of flexibility and can be adapted to your specific use cases.

For our scenario, we have created a CygNet Designer blueprint, and want to run blueprint validation on a schedule to ensure our system remains within our blueprints defined parameters.

In the above two lines the source of the script is set (0 = local file system, 1 = the HSS, 2 = BSS file) and it’s location.

g_objJobRunner.ExecuteJob(objScriptJob)

Finally we tell Job Runner to execute the job.

SetPointEx “JAKKU.HSS::JOBRUNNER.TRIGGER”, 0, Now, 0, 1000

After the job is executed we set the value of the trigger point back to 0.

In this example, we wrapped the script inside of an IF statement that resets our trigger point after the job is executed.

The full script inside this event can be seen below.

OnPointChange event

In this example, the default value of the trigger point is 0, and when we want our script to run we edit the value of the trigger point (which is being monitored by the Job Runner points OnInitializeEx event) to 1. Once the job is started, we edit the value of our trigger point back to 0.

We can use this trigger point in combination with the MSS Set Point Task to automate when we want our script to be run.

Job Runner trigger point

You could also edit the trigger value manually, or set the value through a button in Studio.

We’ll want to create a Point that we can use for Job Runner to report its status to.

Here the idea is to have our UIS display the value of the job status. The Job Runner simply creates a job that you can ask it for the status of. The Job Runner can start up multiple jobs and is responsible for tracking the status of any jobs it’s started. In this case we are only creating one job, but we want to be able to track the status of the job, creating a status point allows for Job Runner to have a place to report to.

Job Runner UIS Status point

That’s it! We can edit the value of our trigger point and the Job Runner will be called to spin up a job for our CygNet Designer validation to be processed in a separate thread. We will get feedback about the status of the job in our status point in the UIS.

This is really just the tip of the iceberg and we haven’t even touched on .NET assembly methods, Job IDs, executing a script stored in an inactive HyperPoint, logging, troubleshooting, and more. This post should hopefully be enough to get you started and feel free to ask questions.If you don’t yet have the CygNet Job Runner feel free to get it from the Download site at support.cygnet.com.