nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

CGI Task as start task

Annad

Hi,
I have a cgi task in a workflow as the start task. so when the workflow starts, a message is printed on the cgi window saying that the files have been sent to be processed. This means that the workflow continues with the rest of the tasks in the workflow.
However, if I refresh the CGI window before closing it, the workflow restarts for the same set of files. I am doing a check in the cgi script in the CGI Task to see if the task is valid. It is valid every time I refresh the window since the workflow is initiated each time.

Any ideas why refreshing the cgi window will start a new job?

Thanks
Anna Dalas.

Find more posts tagged with

Comments

Migrateduser

Are you refreshing the screen before the workflow is actually instantiated or afterwards? Is your CGItask spawning a child workflow or something?

The reason I ask is that if all your CGI task is doing is some background processing, attaching files, etc., and then transitioning, it should not be starting another workflow. So, I'm wondering what's going on in your CGI task.

Annad

This CGI task simply process the files to see if they are associated with other task. If so, it prints out a message and moves onto the end task to end the workflow, and otherwise continues to the next transition task as defined in the .wft file.

Would this be due to the fac that this is cgi task is the start task?

~Anna Dalas~

Migrateduser

Would this be due to the fac that this is cgi task is the start task?

No, not at all. It's quite common to have a CGI task as the first in your workflow. I'm not understanding something, however. You shouldn't be kicking off duplicitous workflows at all. Do you notice this behavior regardless of what CallBack you're issuing? What does your workflow spec look like?

Annad

see the attached cgi script and the wft file.

~Anna~

Migrateduser

It's not attached but what is your observation per my previous post?

Annad

It's not really kicking off duplicate workflow at the same time.
On the first round, the workflow starts by initiating a job and then the first task which is the cgi task. I kept the cgi window open and let the workflow end, so there's no tasks on my task list. However when I refresh the cgi window that I kept open, a brand new job is started.

In the cgi script, I am using the regular call back method. But I dont't think this matters since the workflow ended properly in the first place.

Just a side note. I have a log file for both the .wft file and the cgi script.
When I refresh the cgi window, a new log file for both the .wft and the script is created. This means that a new workflow is being kicked in.

Is it possible that the cgi window still has the post variables assinged to it on the first time. I mean, how is that possible.

Adam Stoller

Hi,
I have a cgi task in a workflow as the start task. so when the workflow starts, a message is printed on the cgi window saying that the files have been sent to be processed. This means that the workflow continues with the rest of the tasks in the workflow.
However, if I refresh the CGI window before closing it, the workflow restarts for the same set of files. I am doing a check in the cgi script in the CGI Task to see if the task is valid. It is valid every time I refresh the window since the workflow is initiated each time.

Any ideas why refreshing the cgi window will start a new job?

Thanks
Anna Dalas.

If the cgitask script performs the callback before rendering the message in the window - then refreshing it should only possibly cause an error with respect to trying to [re]transition an inactive task.

If the cgitask doesn't perform the callback until after the screen is rendered - or - if the callback hasn't been successfully completed at the time you do the refresh - the cgitask is still active and refreshing the window will re-run all the code in the cgitask script.

JonathonG

It's not really kicking off duplicate workflow at the same time.
On the first round, the workflow starts by initiating a job and then the first task which is the cgi task. I kept the cgi window open and let the workflow end, so there's no tasks on my task list. However when I refresh the cgi window that I kept open, a brand new job is started.

In the cgi script, I am using the regular call back method. But I dont't think this matters since the workflow ended properly in the first place.

Just a side note. I have a log file for both the .wft file and the cgi script.
When I refresh the cgi window, a new log file for both the .wft and the script is created. This means that a new workflow is being kicked in.

Is it possible that the cgi window still has the post variables assinged to it on the first time. I mean, how is that possible.

I don't recall all the details, but there was a version of TeamSite in which, if the start task was a cgitask, it was swapped into the same window as the wft instantiator without changing the location attribute on the browser. This resulted in exactly the issue you are seeing. What is your TS version/UI/OS/etc?

workorder_actuals.rptdesign

Migrateduser

Your code isn't kicking off another workflow, which it sounded like it might have been doing. I'm at a loss as to why you're seeing

jobs being duplicated. As fish said, your code will either be rerun or (more likely in this situation), you should get an error because the job and task that you're referencing are no longer valid.

So, it doesn't matter that you're dealing with a CGI task or that the task is even the first in the workflow. It doesn't do anything special with regard to workflow operation. That is, all it does is captures the job ID and task ID (and it captures it not from the workflow instantiation screen because neither of these objects exists yet) and creates Workflow and Task objects based on them. If either of these is not valid, you will receive an error.

Judging from fish's response and also from the lack of any other fingerprints on this thread (i.e. other people posting messages), we're missing something. This is not typical behavior and perhaps there is something else that is not apparent.

Dave

Migrateduser

I don't recall all the details, but there was a version of TeamSite in which, if the start task was a cgitask, it was swapped into the same window as the wft instantiator without changing the location attribute on the browser. This resulted in exactly the issue you are seeing. What is your TS version/UI/OS/etc?

I guess it might be a version thing but I frequently use the initial CGItask window as a means of debugging a workflow. I comment out the CallBack and keep refreshing it to show me workflow attributes. It's reliable and hasn't kicked off superfluous workflows for me. *shrug*

Annad

I don't recall all the details, but there was a version of TeamSite in which, if the start task was a cgitask, it was swapped into the same window as the wft instantiator without changing the location attribute on the browser. This resulted in exactly the issue you are seeing. What is your TS version/UI/OS/etc?

Hi,
You are right. since this is a cgi task and the first task in the workflow, it takes the same window. I am using TS5.5.2 on windows 2000.

I looks like the .wft file is being rerun when the window is refreshed.

Any idea how I can bypass this?

JonathonG

Hi,
You are right. since this is a cgi task and the first task in the workflow, it takes the same window. I am using TS5.5.2 on windows 2000.

I looks like the .wft file is being rerun when the window is refreshed.

Any idea how I can bypass this?

Well, based on Dave's comment...upgrade to 6.1? 5.5.2 is an EOL product, so I don't think you'll get much help on this from support.

Outside of an upgrade (which you should be planning but probably isn't of immediate help), I can think of two suggestions (neither one very good):
1. Move the CGI-task logic into your wft and do the work as part of the instantiation screen (not sure what you're doing, so not sure how feasible this is)
2. Set immediate="f" on your cgitask. Users would then have to go their task lists and click "Start Task" to get it to pop up, but then at least you would get a fresh window.

Have you tried a KB search on the support site? There might be something there.

Migrateduser

To add to what Jonathon stated, 6.1 is almost EOL also.

I'm sorry I can't help with that version... I should have asked up front but it's been years since I've used 5.5.2 but I think I recall that I had a very similar problem in that version.