Discussions
Categories
Groups
Community Home
Categories
INTERNAL ENABLEMENT
POPULAR
PUBLIC CLOUD
PRIVATE CLOUD
Quick Links
MY LINKS
HELPFUL TIPS
Back to website
Home
Web CMS (TeamSite)
DummyTask Timeout question
Hazzie
Whilst looking at the TimeOut transition option on a dummy task within workflow builder (5.5.2) on TS 5.5.2 i notice that it has 3 options.
1) In a specified amount of time from now
2) At a specified date and time
3) From a variable.
Its the 3rd one that has me a little puzzled as i dont see any documentation on it. How do i set the variable, how do i call it. Is it looking for a Job level varaible and all i have to do is specify the variable name in the input box and it will get the relevant info.
any ideas,
Hazzie
TS 5.5.2 on NT.
Find more posts tagged with
Comments
Migrateduser
Are you reading this from the manual? If so, what page is it on? If not, where are you reading the stuff about the "variable"? I'm guessing the variable is simply a perl variable or a TAG variable that gets its value from user input in your wft and you use that for your timeout value.
Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com
akshathp
If you are using dummytask I believe you must be using the following sysntax:
<dummytask name="Delay" owner="__TAG__('iw_user');" description="Queue for deployment">
<timeout v="__INSERT__($timeout);">
<succ v="Deploy"/>
</timeout>
<activation>
<pred v="Submit"/>
</activation>
</dummytask>
I do not know what is the workflow design you have for your custom workflow so wouldn't know why and where you would need the varibale tag. Variable tag allows you to associate a varibale with task which can be used in the external scripts for worklfows. So if you can be more specific about the workflow desing, probably there can be ways to resolve it.
Hope this helps!
Akshat Pramod Sharma
Interwoven Inc.
Migrateduser
I believe the 3rd option is unique to WFB. I assume it allows you to use a wfb variable for the timeout value, instead of a hard-coded value. It would still need to be a delta or a fixed date/time, though.
bw
Bob Walden [bob.walden@interwoven.com]
Interwoven Education Group
IM: Yahoo, MSN bob_walden
Adam Stoller
Look in the manual for information about setting variables - I believe if you want to prompt for the value during instantiation it would be a User Variable, and if you want to programmatically set it within your own custom Perl code it would be a Custom Variable - in either case, it would end up being referenced as previously posted by Akshat - using either:
__INSERT__('$variable_name') - if it was a custom variable, or
__TAG__('variable_name') - if it was a user variable.
In both cases - the value of that variable would have to evaluate into one of the other two mentioned formats ("MMDDYYYYHHMM" or "+HHHHMM")
--fish
(Interwoven Senior Technical Consultant)
Hazzie
Thanks for the comments. Yes it is a something i was looking at within WFB I just couldnt see any documentation on it within the WFB manual.
I do want to be able to set it programtiaclly from a user input at on a CGI page so i will try your suggestions.
With the release of the visio templates for workflow are Interwoven thinking about dropping the WFB product?
Thanks,
Hazzie
TS 5.5.2 on NT.
Adam Stoller
With the release of the visio templates for workflow are Interwoven thinking about dropping the WFB product?
The Visio templates pre-date the existance of WorkflowBuilder.
My understanding is that there were discussions at GearUp this year regarding possible enhancements and/or replacements for the current WorkflowBuilder - but to date I do not believe there have been any formal plans made with regard to its future development.
Until such time as there is a formal announcement, I would expect that the current WorkflowBuilder product will continue to be maintained and supported.
(I'm sure Smitty will have something to add here :-)
--fish
(Interwoven Senior Technical Consultant)
Migrateduser
Indeed, I was licking my chops as I was reading Adam's reply. At the Workflow Focus Group prior to GearUp, one of the product VPs really tried to get people's input on how to make Workflow Builder better. It seemed like this was a major deal for Interwoven. After most of the Focus Group was taken up by this, and I was sitting there frustrated because we were only talking about Workflow Builder, a tool I never use, I raised my hand and asked the VP to please not forget about the advanced users, among other things. At that point he took a poll of the people in the room (there were probably about 30 developers there) on who wanted Interwoven to concentrate on making Workflow Builder a better product, on a scale of 1 to 5, with 5 meaning they really really wanted a better Workflow Builder. He slowly called off numbers from 5 down to 1. Only one person ever raised their hand. He was quite shocked at the response. No one who concentrates on workflow appears to want Interwoven to focus on Workflow Builder. What developers appear to want is a better ToDo UI, more customization, and other things pertaining to more advanced development. Hardly anyone is interested in allowing their business users to develop workflows themselves, which is pretty much what Workflow Builder is for.
That said, it wasn't clear how much Interwoven will take that feedback to heart. I assume they will do something with Workflow Builder, but hopefully they will not spend 80% of future workflow development on that and only 20% on the stuff people really appear to want. One thing that looks interesting is that the wft development is going to change pretty dramatically. Rather than a strictly perl wft, they are planning to open wft to be more template based, which means people will be able to use other programming languages to develop workflow templates. Unfortunately they didn't have much time to talk about that because of all the WFB nonsense, but I am anxious to hear more about this new wft approach as it develops into something deliverable.
I do think that a lot of people would like some kind of iconized view of their jobs after instantiation - a way for users to view the whole job in a pretty (pleasing to the eye), easily understandable flow, with their current task highlighted. If the ToDo page could become more user friendly, that would be a huge win for workflow developers and users of workflow. Workflow Builder was a good try, but it still doesn't remove workflow developers from having to understand the guts of workflow if they try to do anything remotely complex.
Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com
Migrateduser
Dave, we hear input from the Focus Group loud and clear. I'll guarantee you that our future effort is not 80% WFB and 20% Task UI. We are currently working on a couple of proposals to bring back to the Focus Group attendees for further feedback. I hope to be back in touch no later than January.
Regards,
Patrick Fu
Migrateduser
That is good to hear, Patrick. I was so disappointed that there wasn't more time for the Focus Groups - there were so many people and just not enough time to really dig in and have a good discussion - especially after all that time was taken up talking about WFB. I am very glad to hear you guys heard loud and clear what we wanted. Getting the focus group back together would be awesome - I found that to be so valuable to get in a room with the engineers and just hash out ideas. I'll be looking forward to that.
Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com
Hazzie
I have a CGI Task that is bascially an Approval screen, it has 3 successors.
1) Reject
2) Launch ASAP
3) Launch Preset
The reject steps just basicaly takes the job back to the start.
The Launch ASAP step goes directly to a Submit step
The launch Preset step goes to a dummy task. This dummy task is linked to the submit task via a timeout. The aim of this is to allow the approver to say ok this can go live but allow them to put in a new date and time (in the correct format) via the cgi task. I was hoping that the variable option i was enquiring about could pick up this new date and time and wait until said moment before transitioning to submit.
However, as i understand the replys so far the variable can either be a user variable or a custom variable. As i see custom varibales, they offer some flexibility but only at job instantiation. Can i modify a the contents of the custom variable at my Approval step so the Dummy task picks it up or is it something that has to be set at the time the Job is started. Is there a better way to do this?
Hazzie
TS 5.5.2 on NT.
Adam Stoller
(I didn't read back through the who thread on this - I'm just responding to your latest post)
If a task already has a timeout value associated with it - you can programmatically (via an externaltask, or your already existing cgitask) alter the timeout value of that task (see TeamSite::WFtask for more details).
It doesn't matter what kind of variable was used to set the original timeout value during instantiation - just that there *was* a timeout value set during instantiation.
--fish
(Interwoven Senior Technical Consultant)
Hazzie
So i could set the dummy task timeout transition with a dummy value and then change it at my cgi task using SetTimeout($timeout).
Excellent thanks.
Hazzie
TS 5.5.2 on NT.
Hazzie
Can i ask for some coding help please.
I have a CGI task that calls a dummy task. The dummy task has a timout transition to a submit task. (the CGI also has 2 other transitions out to other tasks).
when the CGI form is updated it calls this final sub.
sub FinishIpr
{
open (OUT, ">>$iwhome\\timout.log");
my ($TaskID, $IprRejectApproveLaunch, $IprTargetLiveDate, $IprTargetLiveTime) =
@_
;
$IprTargetLiveDate =~ /(.*)-(.*)-(.*)/;
my $timeout = "" . $2 . $3 . $1 . "";
$timeout .= "" . $IprTargetLiveTime . "";
$timeout =~ s/://g;
print OUT "timeout $timeout\n";
DBDisConnect();
# Next two lines comented out for testing.
if ($IprRejectApproveLaunch eq "LaunchLater")
{
($success, $NextTask) = $Job->GetTaskByName("WaitForLaunch");
if ($success == 1) {
print OUT "Success\n";
$NextTask->SetTimeout("$timeout");
}
$Task->CallBack(0, "IPR ok for Launch Time altered");
}
elsif ($IprRejectApproveLaunch eq "LaunchASAP")
{
$Task->CallBack(1, "IPR ok for Launch ASAP");
}
else
{
$Task->CallBack(2, "IPR Rejected");
}
print qq|<script language="javascript">if (opener.top.Ctl) {
opener.top.Ctl.pw_refresh();
}
else {
opener.location.reload();
}
self.close();
</script>|;
print "</BODY></HTML>";
close OUT;
exit;
}
values passed in
$taskid = 8379
$IprRejectApproveLaunch = "LaunchLater"
$IprTargetLiveDate = "2002-11-25"
$IprTargetLiveTime = "13:26"
example output from timout.log
timeout 112520021326
Success
When i take a look at the Dummy Task "WaitForLaunch " I see that the timeout has been set to
<timeout v="0">
....
</timeout>
When the Job is first run i have made sure that the timout is initially set to +60.
Any ideas why the timeout is not being set to the value requested?
Hazzie
TS 5.5.2 on NT.
Migrateduser
Sorry, but I can't spot the problem just glancing at your code. You might try the following:
1. Check the return value from SetTimeout (it should be zero).
2. Call GetTimeout immediately afterwards.
3. Print out the current time (according to the server) and compare. Perhaps the specified time has already passed.
Brinko Kobrin
Interwoven Staff Engineer
Hazzie
Brinko,
Thanks for the reply,
comments
1)
Strange the WFworkflow.pm says it should return 1 if successful
($success, $task) = GetTaskByName($taskname)
Returns task in the workflow with name $taskname. $task is a
possibly invalid TeamSite::WFtask object. $success is 1 if
successful.
2)
I look at the workflow from iwgetwfobj anyways to see whats going on and i see its set to 0 there.
3)
I am using a date 2 days in advance and the server date and time is correct.
Hazzie
TS 5.5.2 on NT.
