We should have the first beta version of adTempus 4 out in the next couple of weeks, and this version has a "Cycle ID" concept, which is exactly what you describe--the first job in a chain generates a unique ID that then gets passed through to any jobs that get started down the line. So if you can wait for version 4, you'll be all set.

It's possible to do it in the meantime as you describe, but as I looked into this I found that there's apparently a problem with variables getting passed between jobs when the variables have been set by a script, so I need to look at that further. It may require a software fix.

Assuming that were working, your first job would run a script to generate a Guid and put it in a variable (say, "ChainID"). This variable won't get stored in the adTempus database anywhere, though, so you will have to store it in your own cross-reference table in the database. Your table would want to map the ChainID to the value of the "ADJobInstance" variable. ADJobInstance gives you the "OID" value that identifies the instance's record in the ExecutionHistoryItem table in the adTempus database.

When your job starts another job using the Job Control Action, the ChainID variable value will get passed through to the second job. That job will also need to add itself to your mapping table.

Probably what you want is two Shared Scripts: one that just generates the ChainID and puts it in a variable, and another that creates the mapping record using the ChainID and ADJobInstance. So your first job would call both scripts; subsequent jobs would only call the second.

You would then have a list of all the job instances that were involved in that chain.

Thanks Bill!  All seems to make sense.

I have a question about this step:

"When your job starts another job using the Job Control Action, the ChainID variable value will get passed through to the second job. That job will also need to add itself to your mapping table."

I'm assuming this is the part that is currently broken?  Which means I'll need to wait until either this bit is fixed, or the beta version of adTempus 4 comes out?  Assuming a SW fix for this is made, do you have any kind of time-table for that?

 

Tim

That's the part that won't work right now--getting the variable value passed between the jobs. If you submit a support request on this we can probably get a fix for you within a day or two.

There are two limitations that were affecting the ability to pass a variable value between jobs.

First, adTempus does not automatically pass variables between jobs when one job runs another with a Response. This was a deliberate design decision but is something we may need to reconsider in the future.

This means that variables can only be passed to the second job by explicitly setting them on the Variables tab of the Job Control Action that's running the second job.

For example, in JobA you run a script and set the ChainID variable to a new Guid: "412EB72B-C03A-4206-8B5C-C17CF98D352F". Now you want to pass the same value to JobB when you run it using a Job Control Action.

In the Job Control Action go to the Variables tab, which defines the variables that will be passed to JobB. Add a new variable named "ChainID" and set its value to "%ChainID%" (without the quotes). The percent signs tell adTempus to replace that token with the current value of the ChainID variable.

Unfortunately in the current release of the software (3.0.8) that variable expansion isn't being done, so JobB gets the literal value of "%ChainID%" rather than the expanded value of "412EB72B-C03A-4206-8B5C-C17CF98D352F".

We've made a fix for this and sent Tim the patch to try.