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; } } }

How to start tow CGI-tasks in a row

meikel

Hi,
I have two CGI-tasks. when the first is finished the second has to be started.
But i don't start automatically. I have to start it by hand with the "task options" menu.
Is there a way to start the second CGI-task automatically?
Both tasks belong to the same user.

regards
meikel

Find more posts tagged with

Comments

JonathonG

I believe the key to this is to use the CallBack method of the TeamSite::CGI_lite module. If you use the one in WFtask or just use a system call to run the clt, you will not get the second cgi task to execute immediately. Also, make sure you haven't set the immediate attribute to false on the second task in your WFT.

Jonathon
Independent Interwoven Contractor

Migrateduser

I thought a cgitask will only kick off automatically if the previous task was owned by the same user and it is a user interaction task (like a usertask).

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com

JonathonG

Well, it actually depends on the version/patch level you are on. With the latest TeamSite versions, what I said above is true. There were problems with subsequent CGI tasks in earlier versions of TeamSite, I believe the problem existed in 5.5.2 with no SP, but don't quote me on that. I don't remember exactly when the fix was introduced into the CGI_lite.pm module, but I do know that it did get fixed there. Without that fix, what you say is correct.

Jonathon
Independent Interwoven Contractor

Migrateduser

After checking the 6.0 docs it looks like you are correct. What a bizarre "hack" to solve a problem. I would hope that Interwoven makes it so all callback options would make this scenario work. It's just another example of sticking a finger in one of the holes in the dam instead of fixing the whole dam.

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com

JonathonG

While I would agree with you that IW often "sticks a finger in the dam", I don't think this is a case of that.
I'm not sure that its technically feasible to make all the callbacks behave like this. It has something to do with knowing what window to render the CGI into. From a technology perspective, a CGI is dependent on a user request to run. That's how it knows what client machine and window to put its response into. So, when you have a CGI task go active, it must have a window to target or else it can't run. When the preceding task is a user interaction task of some sort, there is a window defined. If that task is a user/group task or the job instantiation window, the underlying code can check to see if the subsequent task is a CGI task and initiate the request on behalf of the user. This is the same thing that the code in CGI_lite is doing. The iwcallback CLT and the WFtask::CallBack method are designed to work generically, no matter where they're called from (CGI task, external task, command line). Thus, they cannot assume that they have a user context to display the CGI in. CGI_lite can make that assumption because it should only be used by CGI tasks.

Perhaps I'm mistaken, but I believe this is simply a technology limitation.

Jonathon
Independent Interwoven Contractor

message.jpg

scriptbefore.jpg

Migrateduser

Most of that was over my head. But I have a problem when there is more than one way to perform the same act (a callback from an externaltas or cgitask) and you call them the same thing but they act differently. Keeping track of the 3 or 4 ways to do a callback is not something I need to worry about on top of everything else. I would much rather have one master callback function somewhere that handles your callback, whatever the scenario. Maybe that's asking for too much, but if it is, then callbacks are more complicated than they need to be.

I'm not ranting at you, I'm just ranting...

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com

Bill Klish

What you are asking for can be accomplished using the CGI_lite::iwcallback method. Interestingly, you need to use the name of the task transition instead of the number of the transition, as is used in the regular Task::CallBack. So if you have your successors defined in a cgitask element in your .wft file, something like this:

<successors>
<successorset description="Next">
<succ v="Next CGI"/>
</successorset>
<successorset description="Previous">
<succ v="Previous CGI"/>
</successorset>
</successors>

you would use code similar to the following snippet:

my $cgi = TeamSite::CGI_lite->new();
$cgi->parse_data();

$cgi->iwcallback("Next", "Going to the next cgi task");

This will invoke the Next CGI element as defined in your workflow. If the next task is not a CGI task, you do not want to use this method. Use this only when going between cgis.

As noted in the other posts, this assumes that the same user owns the next CGI as well.

Hope that helps.

JonathonG

Now thats an option. Make a generic callback (maybe change the functionality of WFtask::CallBack?) that determines the task type and does the right thing. There'd be some overhead, but it shouldn't be too bad.

In the meantime, I think its pretty easy to keep straight:

use TeamSite::CGI_lite::callback from cgi tasks
use TeamSite::WFtask::callback from external tasks
only use iwcallback clt if you need to administratively "force" a task callback.

Now, for the next rant...every one of these takes different parameters Smiley Sad

Jonathon
Independent Interwoven Contractor

Bill Klish

One additional note. There was a problem with 3 different ways to pull all of the workflow and user information using the task id (taskId, iw_taskid, and task_id). This issue has been corrected in TeamSite 5.5.2 SP3, and you should reference task_id only.

See this technote in devnet for more information:

http://devnet.interwoven.com/site.fcgi/techlib/049747