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

Dummy Task and Timeouts

Hazzie

Would someone please be kind enough to sanity check the code below as when ever its run my timeout value for my dummy task is
<timeout v="0">
<successorset description="Timeout">
<succ v="XXXXX"/>
</successorset>
</timeout>

I expect to see a date and time in the <timeout v="0"> bit.

#debug code start
open (OUT, ">>$iwhome\\debugmsg.log") || return;

print OUT "NowDayOfMonth $mon\n";
print OUT "NowWeekDay $day\n";
print OUT "NowDayOfYear $year\n";
print OUT "NowHour $hour\n";
print OUT "NowMin $min\n";

$NowDayOfMonth = sprintf("%02d",$mon);
$NowWeekDay = sprintf("%02d",$day);
$NowDayOfYear = sprintf("%04d",$year);
$NowHour = sprintf("%02d",$hour);
$NowMin = sprintf("%02d",$min);

print OUT "NowDayOfMonth $NowDayOfMonth\n";
print OUT "NowWeekDay $NowWeekDay\n";
print OUT "NowDayOfYear $NowDayOfYear\n";
print OUT "NowHour $NowHour\n";
print OUT "NowMin $NowMin\n";

$timeout = "" . $NowDayOfMonth . "" . $NowWeekDay . "" . $NowDayOfYear . "" . $NowHour . "" . $NowMin . "";
print OUT "$timeout\n";

close OUT;
#debug code end
#actual code start

if ($IprRejectApproveLaunch eq "LaunchLtr")
{
($success, $NextTask) = $Job->GetTaskByName("WaitForLaunch");

if ($success == 1) {

$NextTask->SetTimeout("$timeout");
}
$Task->CallBack(0, "IPR ok for Launch Time altered");
}
#actual code end

the output is

NowDayOfMonth 05
NowWeekDay 05
NowDayOfYear 2003
NowHour 11
NowMin 19
NowDayOfMonth 05
NowWeekDay 05
NowDayOfYear 2003
NowHour 11
NowMin 19
050520031119

The task is transitioned with the comment IPR ok for Launch Time altered.

Thanks.

Hazzie
TS 5.5.2 on NT.

Find more posts tagged with

Comments

Adam Stoller

When is the code being run? After the timeout has occurred for that task? If so - 0 (or +0) is the correct value.

Regardless of which format you specify for the timeout for a task, GetTimeout() returns to use the number of *seconds* from "now" for that timeout to go off.

So if you specify "+000001" (HHHHMM format) - and do a GetTimeiout() - you'll get back "+60" - i.e. 60 seconds from now.

The same thing holds true with "MMDDYYHHMM" format - that's what you supply, but GetTimeout() returns the number of seconds from "now" to "MMDDYYHHMM".

Once a timeout has occurred - the value of that timeout is now the same as "now", and: "now" - "now" = 0

If you want to convert the value of GetTimeout() back into a date or HHHHMM format - take a look at the Date::Manip Perl module.

--fish
(Interwoven Senior Technical Consultant)

Hazzie

OK,

After running this again with a bit more of a sensible timeout value (one that was 10 mins ahead) instead of 10 days, i saw that the task actualy transistioned.

So it looks to work ok.

However is it a bug that the <timeout v="0"> bit still stays at 0?

let me explain a bit more.

i set a timeout for 1 hour. using the full method of specifying the time out i.e "month day year hour min"
i progress the workflow so its waiting at the time out for the said 1 hour
i do iwgetwfobj on the dummy task while its still waiting and it shows <timeout v="0">
shouldnt that be <timeout v="042920031335"> (or a epoc representation of that date string) for example

Where in the job is that value of my timeout stored?

Ta.

Hazzie
TS 5.5.2 on NT.

Edited by Hazzie on 04/29/03 04:51 AM (server time).

Hazzie

I am running an ipl that allows the user to either submit now or submit later (at a user specified time). The user specified time is then fed into a dummy task as a timeout.

So when i am running the code the timeout hasnt even started yet never mind finished as the dummy task has not been transitioned to.

Hazzie
TS 5.5.2 on NT.

Adam Stoller

My appologies - while what I posted was correct - there is apparently a known bug (30189) with regard to the information that is shown (either through iwgetwfobj or calling GetTimeout) when dealing with timeouts set with absolute dates (relative timeouts appear to work as I indicated previously).

I do not believe that this has been fixed in the soon-to-be-released SP3, so I'm not sure when it will be fixed.

While the absolute timeout *does* work as desired - the only workaround I can think of for accessing that information invloves translating the absolute time into a relative time before it actually gets set in the workflow - sorry.

--fish
(Interwoven Senior Technical Consultant)

Hazzie

Ghoti,

Thanks for the information. As a slight workaround i have renamed the Dummy task description to "waiting till XXXXXX" where XXXXXX is the date and time. This enables a user to see how long the task is to sit att he dummy task point.
I suppose i should really change the absolute to relative so i have a proper record of it in the Time out variable.

Thanks.

Hazzie
TS 5.5.2 on NT.

Migrateduser

This is a glaring reason why the bug list should be posted to everyone who has spent the many thousands of dollars it costs to buy this product. Seems like this bug should be easy to fix and shouldn't be lingering around any longer. If someone was able to push Interwoven to do a better job of fixing bugs, maybe more bugs would be fixed.

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

Jeremy

I tend to agree with Dave here - especially when it comes to trying to debug. I know I have spent many hours even days debuging certain aspects of Teamsite, only to eventually open a case and be told its already a known bug!

I'd be a big fan of seeing the Known bugs list - I know it'll save me time when I face issues!

Jeremy

Hazzie

I have to agree as i spent a couple of unproductive days trying to figure this one out.

I am going to raise this with our TeamSite Account Manager and try to get a response from him.

Hazzie
TS 5.5.2 on NT.

Migrateduser

There are 2 sub-threads here,
1. Bug Tracking - how do I let IWOV know I care about when a bug is fixed
2. Bug Visibility - I sure wish we could see the list of known problems.

For the bug tracking sub-thread, the best way to handle this is to open an IWOV support case. If you have the bug ID and an active support contract, the IWOV tech support engineer will link your support case to the engineering bug. IWOV runs regular status reports to ensure your priority for the bug is communicated to engineering. When the bug is fixed, IWOV support will notify the person listed as your tech support contact.

As far as Bug Visibility, this is something IWOV is considering. I will open a new thread in 'bit bucket' to solicit in put on this topic. I would be most interested to learn about how small (e.g. non-Microsoft) enterprise software vendors do this.

Lissa

Migrateduser

Here's the link to the bug list question (it's in the suggestion box forum)
http://devnet.interwoven.com/forums/cgi-bin/showflat.pl?Cat=&Board=suggestion_box&Number=13865&page=0&view=collapsed&sb=5&o=&part=

nipper

Lissa

One main problem is that the number of people who can call into support is very limited. We have a very large enterprise rollout with only a couple of people who can call support.

This makes it very difficult for the support engineer since they are not talking to the direct person with the bug.

That is why you see a lot of people asking about issues, I know I cannot call the suport line. Times I have tried to go through the admin filter, it has seldom worked.

That is part of the reason I (and possibly others on the list) are so vocal about the bugs in TS.

Finally I have harped on this a few times, access to the KB would be helpful. People have said the devnet articles are the same, but I have been given KBs that are not on devnet. Also the search capibilites on devnet suck. KB search is much superior.

I do not think opening up the complete bugs database is the answer. However, if a limited number of the bugs were available over the net (maybe only P1, P2, & enhancements) through a superior interface, that may help.

Andy

Hazzie

can you just tell me if my understanding is correct on call backs.

A callback (unless specifically told otherwise) will always take the route out of a task that is in position 0.

I ask this as my users have now asked for the ability to bring a dummy task (that has a timeout on it) back to a previous cgi-task if they feel there is the need to do further work on the assets before the submit stage.

i.e
The CGI Task has two routes out.
Route 1 goes directly to submit.
Route 2 goes to a Dummy Task for a set period of time before goign to submit.

Route 3 If i add another successor that points back to the previous cgi task i can specically call that using the iwcallback clt and a transition id of 1 (presuming there are only 2 transitions from the dummy task).


CGI-Task-----Route1----------------------->SUBMIT-------->etc
  ^    |----Route2--->Dummy Task--------------^
  |-----Route 3-----<--------|

Hazzie
TS 5.5.2 on NT.

pdf_layer_new[1].pdf

Migrateduser

Does a callback even work on any type of task other than externaltasks and cgitasks? I wouldn't think a callback would work on a dummytask - have you tried it?

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

Hazzie

Well after posting that i went and took a closer look at the spec for the dummy task and noticed there wasnt a succcessor element which sort of means the whole thing is a bit pointless. Teach me to think allowed and not do any immediate investigation.

Any ideas how i could recall the dummytask back to the task immeditaly previous to it before the timeout has expired?

I sort of have an idea of an external task after the dummy task and before the submit task that looks at a variable and depending on the state of that either goes onto submit or another of my choice.

Is there anything more graceful than that?

Hazzie
TS 5.5.2 on NT.

Migrateduser

How about instead of a dummytask, use an externaltask with a timeout element embedded in it. Will that work? As far as I'm concerned, any task with a timeout element is the same as a dummytask.

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

Jeremy

To be able to use a callback wouldn't you have to have a <command> attribute where you can call a script?
It seems that in the Workflow DTD the DummyTask does not include a <command> attribute. Is there any other way of being able to use the callback command?

I had always thought a Dummy task would always have only one successor. Otherwise how can you specify which successor to activate?

Hazzie

That would be better than creating an extra task. Why have 2 when 1 can do. (end of the day here in the UK brain is a little fried)

Cheers.

Hazzie
TS 5.5.2 on NT.

Migrateduser

I can relate - doesn't matter what time of day it is here - my brain is always in that state. With the externaltask, you can have your script basically do nothing but callback to index 0, which would proceed to the next logical task. But you can also have another successor that goes back to the previous task (index 1) which you can callback to manually should you decide you want to go back before your timeout runs out. A thing of beauty.

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

Migrateduser

Thanks for the info. One of the things IWOV support has heard recently is the request to allow more than one person access to the support material, while not being able to download software, or open new cases. It sounds like this would address at least part of what you are looking for.

Adam Stoller

What is the purpose of the delay before going to the submittask?

If you transition to route 1 (callback 0) the files are submitted and going back to the cgitask (presumably directed from some task after the submittask) will allow them to make further changes and submit it again.

If you transition to route 2 (callback 1) you *may* be able to access the Take Back Task functionality from the cgitask (haven't tried, don't have time right now to do so) - if this works, it would allow you to essentially cancel the dummytask do whatever you wanted and then choose either transition again from the cgitask.

You could have route 2 (callback 1) transition to both a dummytask and a usertask. The usertask would allow you to transition back to the cgitask. In this scenario, the cgitask would have to explicitly inactivate the dummytask (to keep the timer from going off) and the submittask would have to explicitly inactivate the usertask (to keep someone from going back to the cgitask when the files have already been submitted)

--fish
(Interwoven Senior Technical Consultant)

Hazzie

The purpose of the delay is that we may want to do a launch at some time in the future say at midnight. Once its waiting at the dummytask they may then realise there is something wrong (although it has passed a few levels of checking to get to this position) and need to take it back to a place where they can do something with it.

Sorry if the diagram was not clear enough (best I could do at the time) but the dummy task was either to go to the submit task OR back to the cgi task but never both.

Thanks for yours and smittys suggestions.

Hazzie
TS 5.5.2 on NT.

vp98aa

Hi there!

Did you ever get this one (about taking a "dummy task back") figured out? I am running into similar situation.

Please let me know.

Thanks,
V