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 function help - Error not usefull

MrShake

Ok guys, I'm working on a pretty complicated workflow and am running across something I haven't been able to figure out.

The workflow has 2 configurable global variables

OEYear

OELastYear

The first task is an external task that calls a perl file. This file gathers a file list to auto attach a BUNCH of files and set variables.

I'm trying to set OEYear and OELastYear in the perl script, but its not working:

 ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = localtime(time);
 $year += 1901;
 $lastyear = $year - 2;
print FILE "Last Year:$lastyear\n";
print FILE "Next Year:$year\n";

$workflow = new TeamSite::WFworkflow($jobid) or print FILE "Workflow: Can't create new Workflow Instance: $!\n";
$task = new TeamSite::WFtask($taskid); #This line is used below by the "AddFile" function.
$taskarea = $task->GetArea(); #Used for the iwextattr CLT in the filepath 
$setYear = $workflow->SetVariable("$OEYear", $year) or print FILE "Can't Set Variable OEYear: $!\n";
$setLastYear = $workflow->SetVariable("$OELastYear", $lastyear) or print FILE "Can't Set Variable OELastYear: $!\n";

The log from $setYear and $setLastYear both say:

Can't Set Variable OEYear: No such file or directory
Can't Set Variable OELastYear: No such file or directory

And, of course, the variable is not being set in the workflow. Have I made a stupid mistake? The error trap doesn't make any sense.

Find more posts tagged with

Comments

ISCBorisB

It is probably "false positive". SetVariable method actually returns an exit status of underlying "iwjobvariable"
Command. Thus, returned 0 (Zero) means that everything was Ok, non-zero indicates an error.

Since you've coded "OR" condition and first operand gets 0, Perl executes the second one and logs out
an error that did not happen. To make it even more interesting, you print $! that contains some previous
message that has nothing whatever to do to SetVariable execution.

nipper

It is probably "false positive". SetVariable method actually returns an exit status of underlying "iwjobvariable"
Command. Thus, returned 0 (Zero) means that everything was Ok, non-zero indicates an error.

Since you've coded "OR" condition and first operand gets 0, Perl executes the second one and logs out
an error that did not happen. To make it even more interesting, you print $! that contains some previous
message that has nothing whatever to do to SetVariable execution.

But he did state that the variable is not being set.

It would be worthwhile having a statement like this before the checks:

print FILE "Workflow: checking the buffer: $!\n";

And I would try $workflow->GetVariable... right after.

You know the $OELastYear and $OEYear are set correctly ?

ISCBorisB

But he did state that the variable is not being set

Sure, he said that. How does he know? Problem is, I trust code much more than whatever has been "stated".
And from code I see that he prints an Error only and only when SetValue returns "0" - which means that it has
indeed been set.

MrShake

Ok, I liked the buffer check idea, here are the results:

Workflow: checking the buffer: 
Can't Set Variable OEYear: No such file or directory
Can't Set Variable OELastYear: No such file or directory

On the question of if $OEYear and $OELastYear are set correctly... I'd guess not. I say that because I chagned the code and added the $ after leaving it off didn't work.

I believe the syntax should be closer to:

$setYear = $workflow->SetVariable("OEYear", $year) or print FILE "Can't Set Variable OEYear: $!\n";

Which also does not work.

I know the variables are not set as I setup a check in the workflow.

After the external task, there is a user task with Brief Description set to the configurable(OEYear) and Description set to configurable(OELastYear), so I can clearly see their values.

They are being set to the default (which is IW_OWNER I believe), and not to the values I'm trying to set using the Perl File

Adam Stoller

You say these are Configurable Variables - yes?
Did you also set them up as Job Variables - with the Configurable Variables associated to them?

You need to do that in order to be able to set the variables from the external task.

ISCBorisB

You say these are Configurable Variables - yes?
Did you also set them up as Job Variables - with the Configurable Variables associated to them?

You need to do that in order to be able to set the variables from the external task.

That does indeed look like a mish-mash between Model's variables (that no longer exist run-time when External Task
gets executed) and actual Job Variables that do.

Another coding issue here is the use of double qoutes around literal starting with the "$", like this:
...$workflow->SetVariable("$OEYear", $year)...

Perl will try to evaluate $OEYear Variable first, quite possibly to empty String.

Adam Stoller

Another coding issue here is the use of double qoutes around literal starting with the "$", like this:
...$workflow->SetVariable("$OEYear", $year)...

Ah yes, missed that as I didn't look at the code that closely. In case the above is not clear:

$workflow->SetVariable("$OEYear", $year);

should be just:

$workflow->SetVariable("OEYear", $year);

The first argument to SetVariable is the name of the variable.

MrShake

You say these are Configurable Variables - yes?
Did you also set them up as Job Variables - with the Configurable Variables associated to them?

You need to do that in order to be able to set the variables from the external task.

I've got 2 global variables setup

MrShake

Ah yes, missed that as I didn't look at the code that closely. In case the above is not clear:
$workflow->SetVariable("$OEYear", $year);
should be just:
$workflow->SetVariable("OEYear", $year);
The first argument to SetVariable is the name of the variable.

Yea, I did that first, I threw the $ in there hoping I had wrong syntax... neither worked

Rick Poulin

You say these are Configurable Variables - yes?
Did you also set them up as Job Variables - with the Configurable Variables associated to them?

You need to do that in order to be able to set the variables from the external task.

I've got 2 global variables setup

Configurable (global) variables != job variables. You might want to read that again. /snark

MrShake

Configurable (global) variables != job variables. You might want to read that again. /snark

LOL, I did just that, made a change:

Adam Stoller

Since we cannot see what you have / have not done in terms of code for model and the script, the only way we can try to evaluate your current state is if you post the following (preferably as attachments):

doing the above, I'd recommend trying to create a smaller, cut-down version of the WFM and script to just isolate the specific issue rather than bombarding everyone with 100% of the code of which only 10% applies to the issue you're having.

MrShake

Its not a bit script right now anyway.

I've cut out some of the extranious stuff from the log file (AutoAttachOpenEnrollment.txt), specifically where it lists file names and paths.

I had to change the .ipl to .txt (openEnrollmentSetup.txt)

Job Spec is in JobSpec.txt.. duh

ISCBorisB

I know the variables are not set as I setup a check in the workflow.

After the external task, there is a user task with Brief Description set to the configurable(OEYear) and Description set to configurable(OELastYear), so I can clearly see their values.

They are being set to the default (which is IW_OWNER I believe), and not to the values I'm trying to set using the Perl File

Please note that there are two distinctly different seqiential threads in WF Execution.

#1. WF Engine Evaluates the Model.
   That includes Instantiation Screen Data Capture, Forms processing and the like. That's when
   your "UserTask13" Brief Description and Description are set to transient Model Variables
   "OEYear" / "OELastYear", whatever values they happened to have at a time.

   The end result is generated Job Specs, that's it. It's an XML, pretty much what you've attached as jobspec.txt

#2. WF Engine evaluates Job Specs and instantiates corresponding Job and linked Task Objects.
At this point Model Variables no longer exist, only Job Specs XML matters.

   Upon success, Engine spawns start Task Thread(s). In your case that's single "openEnrollmentSetup".
   Among other things, this process successfully sets "OEYear" / "OELastYear" Job Variables.
   Your code misinterprets command's return as a Failure (I've explained why in one of my previous posts to this
   thread) and logs an error, including completely unrelated $!

   Absolutely nothing happens to subsequent UserTask Descriptions - and why should it?

Makes sense?

MrShake

Please note that there are two distinctly different seqiential threads in WF Execution.

#1. WF Engine Evaluates the Model.
   That includes Instantiation Screen Data Capture, Forms processing and the like. That's when
   your "UserTask13" Brief Description and Description are set to transient Model Variables
   "OEYear" / "OELastYear", whatever values they happened to have at a time.

   The end result is generated Job Specs, that's it. It's an XML, pretty much what you've attached as jobspec.txt

#2. WF Engine evaluates Job Specs and instantiates corresponding Job and linked Task Objects.
At this point Model Variables no longer exist, only Job Specs XML matters.

   Upon success, Engine spawns start Task Thread(s). In your case that's single "openEnrollmentSetup".
   Among other things, the process successfully sets "OEYear" / "OELastYear" Job Variables.
   Your code misinterprets command's return as a Failure (I've explained why in one of my previous posts to this
   thread) and logs an error, including completely unrelated $!.

   Absolutely nothing happens to subsequent UserTask Descriptions - and why should it?

Makes sense?

Aaahh.. I get what your saying here... the descriptions are set LONG before the .ipl file sets the variable to a new value.

So, that leads me to this question... how can I see what the variable has/is changed to?

In essence, I'm trying to set the Source Vpath and Vpath for the submit task using variables created in the .ipl file.

ISCBorisB

Aaahh...

You are welcome...

how can I see what the variable has/is changed to?

If you have required access credentials you can see Job Variables through WF GUI.
Switch to "Jobs" (rather than Tasks) Mode and get to Actions - Change Properties.

To obtain Job Variables in code you'd have to use corresponding TeamSite::WFworkflow / CSWorkflow
Class' Methods.

MrShake

DUDE!!!!!!

I had no idea you could see Job Variables in Change Properties....

I think, in one fell swoop, you've solved all of life's problems... MUCH THANKS!!!

ISCBorisB

De nada