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

Perl running twice in WF

nipper

Someone please try this, in your Perl in a WFT:
(where the custom code belongs)

open (LOG, "/tmp/workflow_$$.log");
print LOG "Smitty is a ...\n";
close (LOG)

Then run your WF.

Tell me if you get 1 file or 2 ? I am getting 2, one before the CGI popup for comments and one after.

Andy

Find more posts tagged with

Comments

james1

I believe that the WFT instantiator executes all of your <template_script> code once, to see if the provided inputs satisfy all of the tags' requirements. If they do not, then it executes all of your <template_script> again, to render the HTML form. Otherwise, it takes those inputs and generates the job spec.

-- James

--
James H Koh
Interwoven Engineering

Migrateduser

I would certainly be interested in seeing the list of input values you received for that query...

Smiley Happy

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

nipper

Depends, if you ran my test then it was Smitty is a great guy. :-)

fiquebem

Sorry, I'm not sure I understand.

We have a workflow template which doesn't prompt the user for anything. Nonetheless, the Perl code in it is executed twice anyway.

Unfortunately, the said code impacts the performance, so we can't afford to have it execute twice. What can we do to insure that it runs only once?

Thanks much,

S.

Adam Stoller

Try wrapping that code within the following conditional:

if (!defined(__VALUE__(iw_first_time))) {
   ...
}

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

fiquebem

Thanks for that tip, Fish. With that directive, we're able to eliminate 1 redundant iteration (which was occurring after hitting Run Job). But there still remains 1 other redundant iteration. As Monsieur James was suggesting, under some (mysterious to me) circumstances the job instantiator does a 2nd pass before getting to the point where it would present the HTML form (even if there's no HTML form to be presented after all).

Incidentally, the job instantiatiator seems to execute routines invoked via the __INSERT__ directive (e.g., __INSERT__(get_cmd_email("iw_send_email")) Smiley Wink

twice for each time it executes those routines when they're invoked from elsewhere. So such routines can end up being executed 6 times!

Anyway, as I mentioned, we're able to eliminate the 3rd redundant execution of a subroutine via the "iw_first_time" symbol; wonder if there's a "iw_primordial_time" tag or some other trick to eliminate the 2nd superfluous execution?

Thanks,

S.

Migrateduser

fiquebem wrote:
> the Perl code [...] impacts the performance, so we can't afford to
> have it execute twice.

It would help to have some idea of what this code is doing. What are its inputs? Can it change between successive submits by the same user within a session?

Perhaps the result of this expensive computation can be cached in a hidden variable or in a file. But to prevent redundant execution and still ensure correctness would require an understanding of the conditions under which cached results can become invalidated.

Brinko Kobrin
Interwoven Staff Engineer

fiquebem

>Incidentally, the job instantiatiator seems to execute routines invoked via the __INSERT__ directive ... twice

Sorry, I just realized that that's not true.

> So such routines can end up being executed 6 times!

That's not true. Code gets executed only 3 times : ).

>It would help to have some idea of what this code is doing. What are its inputs? Can it change between successive submits by the same user within a session?

For example, the files the user submits can be inputs.

>Perhaps the result of this expensive computation can be cached in a hidden variable or in a file.

Yes sir. But I don't know how I would cache something in a hidden variable to be accessed later from a workflow template.

> But to prevent redundant execution and still ensure correctness would require an understanding of the conditions under which cached results can become invalidated.

Well said. It's beyond me : ).

Thanks much,

S.

fiquebem

>With that directive [iw_first_time], we're able to eliminate 1 redundant iteration (which was occurring after hitting Run Job).

iw_first_time is only set after one hits Run Job. If there's no job instantiation form, there's no Run Job button and iw_first_time is never defined.

> But there still remains 1 other redundant iteration ... the job instantiator does a 2nd pass before getting to the point where it would present the HTML form (even if there's no HTML form to be presented after all).

Actually, the part in parentheses -- "even if there's no HTML form to be presented after all" -- is incorrect.

Summary: The workflow engine seems to execute the Perl code in a .wft file (a) once to begin with; (b) once more if the user must be prompted for input; and (c) once more before finally creating/invoking the job. Case (c) can be avoided, but only if "iw_first_time" is defined -- that is, only if case (b) holds true.

Perhaps Interwoven should provide a mechanism to avoid the remaining redundant execution of custom Perl code in a .wft file.

S.

SandeepMadan

I am also facing the same issue..... can you please look into this.
the code is in template script tag and needs to be executed once only on initiation. but this code get executed twice within the initiation.....even before hitting run job.

if (!defined(__VALUE__(iw_first_time))) {
#debug("sandeep");
my $dcrPath=$iw_workarea."/".__VALUE__('iw_file');

my $Content_Relevance=Bharti::Attach::getDCR($dcrPath,$iw_workarea);
my $Content_Relevance=Bharti::Attach::getContentType($dcrPath);

#my @reviewerdata=Bharti::Attach::getReviewer($iw_workarea);
#my $Content_Primary_Approver=$reviewerdata[1];
#my $Content_Primary_Approver_Email=$reviewerdata[2];
#my $Content_Secondary_Approver=$reviewerdata[3];
#my $Content_Secondary_Approver_Email=$reviewerdata[4];

#=====================================================================
# simple debugging routine
#=====================================================================
sub debug {
if ($debug_mode eq "1") {
if ($debug_output) {
print STDERR @_;
if (-e ($debug_output)) {
# Just return if it fails to open debug file
open(OUT, ">>$debug_output") || return;
print OUT @_, "\n";
close(OUT);
} else {
# Just return if it fails to open debug file
open(OUT, ">>$debug_output") || return;
print OUT "File Created and Permission Set to 777\n";
print OUT @_, "\n";
close(OUT);
`/usr/bin/chmod 777 $debug_output`;
}
}
}
}
}
######################################################################
# End of Initialisation
######################################################################

Regards,
Sandeep Madan

Adam Stoller

I just responded in one of the *other* threads you posted this question.

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