This problem was raised some time ago in
this post on the forum but VC Support was unable to replicate the issue.
I am using Visual Cron 7.5.1.
I have created a job that we use to post messages to Slack (a team communications platform). We post using a cURL request to a URL with given parameters. I created the job so that the credentials could be consolidated in one place. The job takes several variables (Job Variables) like MessageText and Channel.
We had an issue that we were sometimes calling it before the last message had posted and this caused the job to not run (had "Do not start if job is already running" set). So, we set it to queue by selecting "Put Job in queue".
When we set it to queue it created an issue where it would revert to the job's default values when it got executed. I was eventually able to fix this issue by removing the "Do not start if job is already running" flag because it won't be an issue to run multiple cURL requests concurrently.
I believe that the specific problem comes from the fact that we have layered jobs being called:
Job A has many steps, and calls Job B to post to Slack several times. Job A creates an appropriate message by building up a string that includes job variables from Job A. Job A passes the string to Job B as a job variable, using the Job/Task control command.
An example of a MessageText string that Job A may pass to Job B is:
Preparing to copy {JOB(Active,Variable,Revision)} revision of {JOB(Active,Variable,Branch)} branch of {JOB(Active,Variable,SiteName)} to {JOB(Active,Variable,DestinationServerName)} for deployment.
If Job B gets queued then when it runs it will have default values. I believe that the state of {JOB(Active,Variable,SiteName)} is not being passed as a string but instead points to the variable value, which may not be available / becomes null when the job gets to the top of the queue. Please note that this runs fine when run synchronously. In the Job/Task control I have "Translate Variables before sending" checked.
Edited by moderator
2015-06-02T13:20:31Z
|
Reason: Not specified