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

dummytask problem

plazm

Greetings!

I am having a weird workflow problem. I don't know, maybe I am crazy or smth. The setup is the following.

User task A has dummy task B as a successor. Task B has some timeout value set. When you choose "success" for the user task, the control goes to task B, and hangs there in the task list for the timeout specified.

Now ... we want task A to start automatically without user's intervention. The following is done...

Task A is now externaltask (changed from usertask) executing some dummy script. The script call a callback and allows the control to go along to the dummy task. Now the weird thing: the timeout doesn't work. The whole process dies right there and never goes beyond the dummytask.

Any ideas? You help is much appreciated.
A.

Find more posts tagged with

Comments

mgal

Can you let me know which version of teamsite and operating system you are having issue with?

Migrateduser

What do you mean by "The whole process dies right there and never goes beyond the dummytask"? What exactly happens? Does the externaltask never execute the callback? Does the workflow end? Does an error occur? Might help if you attached a copy of your wft file as well.

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

plazm

w2k
TeamSite 5.5.1

plazm

Hi!
It never goes beyond the dummytask. The whole workflow just disappears from the task list. The callback is invoked properly. If the callback is not called then the whole process hangs in the external task. This is not the case, so I think the callback is not an issue.

This is the whole problem. Nothing happens. The task after the dummy task is never started, but the task before executes successfully.

A.

Edited by plazm on 07/17/02 08:51 AM (server time).

Bowker

Is it possible that the callback is returning a status higher than you have defined as successors.

For example:

if your workflow has:
<successors>
<successorset description = "Request Content Approver Approval">
<succ v = "EmailContentApprover"/>
</successorset>
<successorset description = "Request Deployment">
<succ v = "EmailWPT"/>
</successorset>
<successorset description = "Reject to Author">
<succ v = "EmailReject"/>
</successorset>
</successors>

a call back of:
`$IWHOME/bin/iwcallback $taskID 0`;
will request content approval

a callback of:
`$IWHOME/bin/iwcallback $taskID 1`;
will request a deployment

a callback of
`$IWHOME/bin/iwcallback $taskID 2`;
will reject back to author

a callback of
`$IWHOME/bin/iwcallback $taskID 3`;
probably will result in the workflow either terminating or hanging.

plazm

The callback returns 0, and there only one successor. When a timeout for the dummy task is set in the past, everything works. But whenever you set in in the future, the dummy task dies for some reason.

plazm

BTW, it should not result in hanging or terminating. The manual says if the callback parameter is greater than the number of successors, then the last successor is invoked.

Migrateduser

Can you post or attach your job spec and the extarnaltask script?

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

plazm

Here we go ...

<externaltask name="publish_content"
start="t"
owner="iwdev\developer"
description="Publish Content"
lock="f"
immediate="t">

<areavpath v="\default\main\media\publishing\demo_com\dev\WORKAREA\developer"/>
<successors>
<successorset description="Success">
<succ v="wait_for_TTL"/>
</successorset>
</successors>

<command v="c:\iw-home\iw-perl\bin\iwperl c:\iw-home\httpd\iw-bin\dummy.ipl"/>

<files>
<file path='\templatedata\content\article\data\2002\07\20020704_112004_moo' comment='Publication Zone: ZONE2,TTL: 2003/01/01:0000'/>
</files>

</externaltask>

<dummytask
name="wait_for_TTL"
description="Wait for TTL"
start="f">

<timeout v = "010120030000">
<succ v = "generate_content"/>
</timeout>
</dummytask>

The script (dummy.ipl) is the following:
use strict;

use TeamSite::WFtask;

my ($jobid, $taskid, $area) = (@ARGV[0..2]);
my $task = TeamSite::WFtask->new($taskid);
$task->CallBack(0, 'Success');

Migrateduser

I'm thinking that because your dummytask does not have an owner, that task is being assigned to "no_user" in TeamSite. If you do a View All in your ToDo list, I'll bet you see all those jobs . Set the owner of the dummytask to "iwdev\developer" and I think you'll see that it's working properly.

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

Migrateduser

Just a nit, but there is no "immediate" attribute for an externaltask. The immediate attribute is specific to cgitasks.

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

plazm

But dummytasks do not have owners as far as I know. A dummy task never appears in the tasklist. Control just stays in the previous task for the timeout specified.

Migrateduser

You are correct, dummytasks don't have an owner attribute - my mistake. However, when I recreate your job spec, I can see the dummytask in the ToDo list if I View All Jobs. Did you try to View All Jobs?

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

plazm

Ooops! You are right! Looks like it's there. Is there any way to show this on my own ToDo list?

Actually if you do "view my jobs", it is there ... So, it is not a problem.

thanks a lot!
A.

Edited by plazm on 07/19/02 06:55 AM (server time).