"Job Groups" Concept?

trueter (21 posts)
April 8, 2013 07:38 AM
Accepted Answer

Hello,

I'm wondering if there is any way to keep track of a group of jobs as a single unit.

 

I have a job that in turn kicks off two independent, parallel jobs.  I have a fourth job that waits on the completion of these two parallel jobs, and when they complete, the fourth job starts.

 

I would like to log any errors that occur during these jobs to a database.  However I would like to be able to group the jobs together as a single unit.  In other words, I would like my error logging table to have a column (i.e. group ID or some such) that lets me determine which errors occurred during the same "group execution" so to speak.

 

Is there any concept of this in AdTempus?  One solution I was considering was to create a new GUID at the start of the first job, and somehow pass that GUID on to the subsequent jobs when they start, and log in my database table against that GUID.  However, I'm not sure if it is possible to pass Job variable values from one job to another.

 

Any help would be great.

Thanks!

 

This topic has an accepted answer. Jump to it.
Bill Staff (601 posts)
April 8, 2013 09:01 AM
Accepted Answer

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.

trueter (21 posts)
April 8, 2013 09:12 AM
Accepted Answer

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

Bill Staff (601 posts)
April 8, 2013 11:03 AM
Accepted Answer
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.
Bill Staff (601 posts)
April 9, 2013 10:29 AM
Accepted Answer

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.

Bill Staff (601 posts)
August 2, 2013 01:58 PM
Accepted Answer

This is now available in adTempus 4. All instances that are linked together through a Response chain will carry the same ChainID, which is a Guid.

If you are reporting from the database you can find this as the ChainID in the ExecutionHistoryItem table.

If you are querying through the API, you can get the ChainID for an instance from the ExecutionHistoryItem. To get all other instances in the chain, use the Job.GetExecutionHistory method. The InstanceQueryParameters object lets you specify one or more ChainIDs to search for.

Replies are disabled for this topic.