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

WFconstructor deleting subdirectory contents

Dmitry

Hi,

I've spent a couple of days on this problem and have no idea why this is happening. Hopefully one of you guys can help.

I am using the WFconstructor to design my wft in Teamsite 6.5. Everything works fine when submitting files from the root of the branch. However, when submitting files in a subdirectory, the workflow breaks. I've inserted some logging and seem to have pinpointed where the problem is occurring, but have no idea why. The wft runs 3 times, twice before the user input (TAG Info) screen and once afterwards. The first two times (before TAG Info is shown to the user), the files exist in the subdirectory as you can see from the logs below. However after the user hits 'Start Job' and the wft gets invoked for the third time, the files disappear from the subdirectory in the workarea breaking the rest of the logic.. Does anyone know why this might be happening?

FIRST TIME
\2005/08/03 16:26:25 \INFO \(eval 1)\{1\}:\38 \(eval) - \ODDS: workflow template file invoked\
\2005/08/03 16:26:25 \INFO \(eval 1)\{1\}:\158 \(eval) - \Path: '/default/main/Intranet/ODDS/WORKAREA/common/*.*'\
\2005/08/03 16:26:25 \INFO \(eval 1)\{1\}:\160 \(eval) - \File List1: /default/main/Intranet/ODDS/WORKAREA/common/Investments/NewFile.txt /default/main/Intranet/ODDS/WORKAREA/common/Investments/NewFileDynamicList.txt\

SECOND TIME
\2005/08/03 16:26:26 \INFO \(eval 178)\{1\}:\38 \(eval) - \ODDS: workflow template file invoked\
\2005/08/03 16:26:26 \INFO \(eval 178)\{1\}:\158 \(eval) - \Path: '/default/main/Intranet/ODDS/WORKAREA/common/*.*'\
\2005/08/03 16:26:26 \INFO \(eval 178)\{1\}:\160 \(eval) - \File List1: /default/main/Intranet/ODDS/WORKAREA/common/Investments/NewFile.txt /default/main/Intranet/ODDS/WORKAREA/common/Investments/NewFileDynamicList.txt\

THIRD TIME (After user fills in TAG INFO screen and hits Start job)
\2005/08/03 16:26:40 \INFO \(eval 1)\{1\}:\38 \(eval) - \ODDS: workflow template file invoked\
\2005/08/03 16:26:40 \INFO \(eval 1)\{1\}:\158 \(eval) - \Path: '/default/main/Intranet/ODDS/WORKAREA/common/*.*'\
\2005/08/03 16:26:40 \INFO \(eval 1)\{1\}:\160 \(eval) - \File List1: \

I would really appreciate if anyone is able to help.

-Dmitry

Edited by Dmitry on 08/03/05 01:35 PM (server time).

Find more posts tagged with

Comments

Adam Stoller

Can you post the actual wft code?

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

Dmitry

Sure - here is the problem area, but I'm attaching the whole file as well.

The problem is this wft runs three times, twice before user fills out the CGI and hits Start Job, and once afterwards. For some reason, when it runs for the third time after the user hits Start Job, the workarea subdirectory contents get wiped out and the code in red gets invoked.

$logger -> info("Path: '$iw_workarea/*.*'");
my @test_file_list = glob("$iw_workarea/Investments/*");
$logger -> info("File List1: @test_file_list");

my $ending_value = scalar(@submit_file);
for (my $i=0; $i<$ending_value; $i++) {
my $workarea_file;
my $staging_file;
my $new_file = TRUE;
my $deleted_file = TRUE;
my $file_label;

##check to see if the file exists in staging, if yes, then the file is NOT new
if (-e ($iw_branch . "/STAGING/" . $submit_file[$i]))
{
$new_file=FALSE;
}

##check to see if the file exists in the workarea, if yes, then the user has NOT deleted it

if (-e("$iw_workarea/$submit_file[$i]"))
{
$deleted_file=FALSE;
}

#this should never happen, but for some reason it runs after the the user hits the Start Job button
if (($new_file == TRUE) && ($deleted_file == TRUE)) {
TAG_info(
"error_$i" => [
html => "</td></tr><td colspan='2'>",
label => ("An error has occurred. Please contact the site administrator. "),
is_required => 'true',
error_msg => 'An error has occurred. Please contact the site administrator.'
]
);
}

#everything is ok - this runs the first two times the workflow is instantiated (BEFORE user provides input)
else {
$file_label="Working ok";
@file_action[$i]=DIRECT_SUBMIT;
TAG_info(
"iw_desc_$i" => [
html => ("Where and how should the link be positioned on the page?"
."<BR><textarea rows='5' cols='50'></textarea>"),
label => ("<STRONG> $submit_file[$i] </STRONG>"),
#label => "Where and how should <BR>the link be positioned on the page? ",
is_required => 'true',
error_msg => 'Please specify where the link will be positioned.'
]
);
}
}

Adam Stoller

In the order that things occurred to me while looking through your code:

The first item that jumps out at me is that you are declaring the entire code to be a package -- I'm not sure if that will cause a problem, but it seems an unnecessary thing to do that *might* cause problems.
Are you on Unix or Windows (I'm guessing Unix, but if on Windows - you may need to make sure that iw_branch is providing a file-system path rather than a vpath if you're going to depend on it for performing file existence tests)
[comment] Your isStringNull subroutine looks bad - I suggest you pick up a copy of Damian Conway's "Perl Best Practices" [O'Reilly] and give it a good read. (sorry, I call 'em as I see 'em) - and it can acutally be completely eliminated if you set up branch_list settings in your available_templates.cfg to require some value for branch path before allowing the workflow to be up for selection.
Are 'TRUE' and 'FALSE' defined constants somewhere? If not - it might be best to either define them or just use 1 and 0 respectively
Have you tried adding logging code where you attempt to test for file existance ? It would be interesting to see the output log...
Is there a reason you're using parentheses around the 'label' portion of your TAG_info() declarations? I can't imagine this would cause the problem, but I'd suggest getting rid of them just the same.
Is there a reason you must do all this testing during instantiation, rather than in, say, an immediate cgitask used as the start task for the workflow? It might be a lot easier to debug that way...
I don't see anything in the code that would explain files getting deleted by it being exexcuted (once or multiple times) - sorry

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

Dmitry

Thanks for taking the time to look at this. I am new to TS as well as Perl, so your comments are very helpful. What did you mean by "logging code where I attempt to test for file existence"? The log that I provided in my inital post is that the output of the logger.. are you saying it would be useful to log anything else? I'm not sure how I can break down the problem into any simpler chunks than I have already, perhaps you can suggest something.

Unfortunately I am still at a standstill with this problem of files being wiped out (and then reappearing) from the workarea during the third pass of workflow instantiation.

Adam Stoller

When in doubt and utterly confused - add as much logging as you possibly can (you can always remove it later).

If you don't absolutely need to determine whether the selected files are new or deleted during the actual instantiation of the job - move all of that code into a separate script which you can run via either an externaltask or cgitask as the start task of the workflow process. It's much easier to debug things in separate scripts than it is to debug stuff within the WFT code which, as you've noted, gets processed multiple times.

You may need to take a few steps back from where you are - re-examine the requirements, re-verify the design, and then go back to thinking about the implementation.

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

Johnny

Sorry I had to reply as I'm some what familar with this..

In reply to:

The first item that jumps out at me is that you are declaring the entire code to be a package -- I'm not sure if that will cause a problem, but it seems an unnecessary thing to do that *might* cause problems.

It poses no problem (for TPL's too). It is used while generating system documentation and for Log4Perl. Categorising the code lets us build a javadoc like system documentation.

In reply to:

Your isStringNull subroutine looks bad - I suggest you pick up a copy of Damian Conway's "Perl Best Practices" [O'Reilly] and give it a good read. (sorry, I call 'em as I see 'em) - and it can acutally be completely eliminated if you set up branch_list settings in your available_templates.cfg to require some value for branch path before allowing the workflow to be up for selection.

Looks bad.. perhaps you might want to provide some more detail. Merely suggesting to read a book isn't that helpful, it's more like a wild goose chase. Why don't you point out what is bad and what topic/area would be of benefit to read.
It is actually a generic function.. you are corrrect though, it's usage in this code is probably obsolete. It comes from the 5.5 days when a new job could be actioned outside of the context of a branch (I'm pretty sure you can't do that now in 6.x - don't have a machine to test right now).

John Cuiuli

Migrateduser

try pre-pending the IWMOUNT value to whatever you're passing to the glob call and the "if -e" checking...$iw_workarea and $iw_branch start with /default...been awhile since I've been on unix, but I don't think /default is a valid path off root unless have a symlink for /default to /iwmount/default?

that said, not sure why it would work fine instantiatiating (the first two runs...first the eval to make sure it won't blow up, then running it if it won't), then bomb after you submit the user input (third run)...

another thing that jumps out, is that the user input field(s) are being called "iw_desc_[$i]"...custom tags should ideally not start with "iw_" since interwoven uses this for the built-in stuff...the other issue is that you're not using that value anywhere...the .wft is pulling out the default "iw_desc" value (which is empty in your case), but doesn't retrieve any if the "iw_desc_[$i]" values...shouldn't break anything, but seems pointless to gather information you're not going to use...

cheers,
-Rori

Adam Stoller

In reply to:Your isStringNull subroutine looks bad - I suggest you pick up a copy of Damian Conway's "Perl Best Practices" [O'Reilly] and give it a good read. (sorry, I call 'em as I see 'em) - and it can acutally be completely eliminated if you set up branch_list settings in your available_templates.cfg to require some value for branch path before allowing the workflow to be up for selection.

Okay. Since asked:sub isStringNull
{
my
(
$stringValue,
) = @_;

if (defined $stringValue)
{
return (($stringValue =~ m/^\s*$/) ? TRUE : FALSE);
} else
{
return TRUE;
}
}Bad use of both horizontal and veritcal spacing. Putting a scalar variable into list context by enclosing it within parens and assigning a list to it. Instead:# Determine if a string is empty or undefined
sub isStringNull{
my $string = shift;
return TRUE if (!defined($string));
return ($string =~ m/^\s*$/) ? TRUE : FALSE;
}(one could make other changes to the code, but the above is probably most-closely associated with the original code)

It is actually a generic function.. you are corrrect though, it's usage in this code is probably obsolete. It comes from the 5.5 days when a new job could be actioned outside of the context of a branch (I'm pretty sure you can't do that now in 6.x - don't have a machine to test right now).Actually - no. Both in 5.5 and 6.x days - you can declare your workflows in the available_templates.cfg file as such (courtesy of a posting by Bob Walden): <template_file name="with_workarea_context" path="path">
<command_list>
...
</command_list>
<branch_list>
<branch value="/.*"/>
</branch_list>
</template_file>

<template_file name="without_workarea_context" path="path">
<command_list>
...
</command_list>
<branch_list>
<branch value=""/>
</branch_list>
</template_file>The first specifies that the workflow is only available if there is a branch path context available (e.g. launching a new job from the navigation interface in WebDeskPro and CCPro and, with customizations, CCStd).
The second specifies that the workflow is only available when there is no branch path context available (e.g. launching a job from the To Do List in WebDeskPro, the Workflow tab in CCPro, or the main portal interface in CCStd).

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

Dmitry

Guys - thanks for your help on this. Turned out it was a permissioning issue..

drwxrws--- 2 jc88151 staff 512 Aug 5 15:16 Investments

For some reason, the first two times the workflow was invoked, the lack of permissions didn't prevent Teamsite from executing the code. On the third run, however, it caused the problem. I'm still curious exactly why this happens - is anyone aware of in-depth info/docs covering workflow template invocation?

Thanks,
Dmitry