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

WFworkflow.pm Methods

iw_store

We are migrating from teamsite 650 to teamsite 570 on windows XP professional.

We are successful in migration and all our code base was working fine. Suddenly yesterday our workflows have stopped working.

When I debug my external task, I made an interesting investigation.

Code of IPL.

use TeamSite::WFtask;
use TeamSite::WFworkflow;
use TeamSite::Config;
use POSIX qw(strftime);

my $VERSION = "4.5.1 Build 2065 SYM Interwoven 20001027";
my $iwhome = TeamSite::Config::iwgethome();
my $scriptname = $ARGV[0];
my $deploymenttype = $ARGV[1];

my $out="E:\/teamsite\/iw-logs\/tsapplogs\/deployment.txt";
open OUT, ">>$out";

my $wfid = $ARGV[3];
my $taskid = $ARGV[4];
my $task = new TeamSite::WFtask($taskid);
my $job = new TeamSite::WFworkflow($wfid);
my $branch = $job->GetVariable('branch');
my $wfdescription = $job->GetDescription();
my $wfname = $job->GetName();
my $wfowner = $job->GetOwner();
my $area = $task->GetArea();
$taskid = $task->GetId();

print OUT " branch :: $branch \n";
print OUT " $area :: $area \n";
print OUT " $wfname :: $wfname \n";
print OUT " wfowner :: $wfowner \n";

close OUT;

In above code the variables which I am printing to file are coming blank. Methods of WFworkflow.pm are not working as expected.

To get branch name in ipl the code in wft is ::

I am getting value of array @ARGV inside ipl.

Any help/idea will be appreciated.

Thanks,

Find more posts tagged with

Comments

ISCBorisB

We are migrating from teamsite 650 to teamsite 570 on windows XP professional.
We are successful in migration and all our code base was working fine. Suddenly yesterday our workflows have stopped working.

When I debug my external task, I made an interesting investigation.

Code of IPL.
use TeamSite::WFtask;
use TeamSite::WFworkflow;
use TeamSite::Config;
use POSIX qw(strftime);

my $VERSION = "4.5.1 Build 2065 SYM Interwoven 20001027";
my $iwhome = TeamSite::Config::iwgethome();
my $scriptname = $ARGV[0];
my $deploymenttype = $ARGV[1];

my $out="E:\/teamsite\/iw-logs\/tsapplogs\/deployment.txt";
open OUT, ">>$out";

my $wfid = $ARGV[3];
my $taskid = $ARGV[4];
my $task = new TeamSite::WFtask($taskid);
my $job = new TeamSite::WFworkflow($wfid);
my $branch = $job->GetVariable('branch');
my $wfdescription = $job->GetDescription();
my $wfname = $job->GetName();
my $wfowner = $job->GetOwner();
my $area = $task->GetArea();
$taskid = $task->GetId();

print OUT " branch :: $branch \n";
print OUT " $area :: $area \n";
print OUT " $wfname :: $wfname \n";
print OUT " wfowner :: $wfowner \n";

close OUT;

In above code the variables which I am printing to file are coming blank. Methods of WFworkflow.pm are not working as expected.

To get branch name in ipl the code in wft is ::

I am getting value of array @ARGV inside ipl.

Any help/idea will be appreciated.

Thanks,

What is the exact 'command' Syntax you execute this Task with? Has it been modified recently?

iw_store

What is the exact 'command' Syntax you execute this Task with? Has it been modified recently?

Hi,

Nothing has changed, everything was working on last thursday, friday all our workflows have stopped.

This problem is not specific to single external command, all workflows/all ipls in all wfts have same problem. Same stuff works works in development migrated box without any problem.

WFT Code is:

I have given snippet of code for experts reference, I don't think any problem with our code as its working from 10 years and when I copare our working code in starteam is exactly same as production box for all ipls, CGIs and wft files.

When I debug I found problem in above snippet of code across system.

ISCBorisB

Please note that the 'command' syntax you've used is somewhat error-prone. You do not seem to use parameters'
quoting. Hence you *may* experience a parameter shift.

For example, imagine that as a result of some code changes, configuration changes, environment changes and whatnot
$deployment_machine or $workflowtype evaluates to an empty string. With your syntax the shell will not *know* that the parameter
was ever there and therefore jobID and taskID parameters will get @ARGV ordinals of 2 and 3, not 3 and 4 that you unconditionally
use in the code sample. If both parameters may evaluate to nothing you'll get jobID/taskID as 1, 2, etc

Adam Stoller

Please learn how to format and Preview your posts to make sure that the information you are trying to provide is, in fact, presented.
Also - I assume you mean you upgraded to 6.7.0 since you wouldn't upgrade from 6.5 to 5.7 (which I don't believe ever existed)

Since you're on Windows - if the name of the script is longer than 8 characters and you have several such scripts with long names like that - you might be running into the ugly 8.3 short-name-convention garbage of Windows - where you have N scripts in which the actual long name of the script and the short name of the script don't line up the same way as they used to - and as a result you end up actually executing the wrong script (this tends to happen a lot more with CGI scripts that use the binary wrapper program instead of an actual *.ipl script).

Of course - that's really a shot in the dark - and quite likely to have nothing to do with your situation - you should enable workflow debugging and verify the actual command that the workflow engine sees in the job specification file - and verify if that script works correctly.

For another shot in the dark - on Windows you have to preface external command scripts with the full path to iwperl. On several occasions, people seem to have created a file called "iwperl" in the IWHOME/iw-perl/bin/ directory - which then causes commands to fail. Generally you can fix this by removing that file, and/or replacing your reference to iwperl with iwperl.exe (personally, I prefer to get rid of the bogus iwperl file)

iw_store

[size=2][color=#0000ff]Thanks Ghtoi. I will make sure, in future I post correct information with proper formatting.

Finally we were able to get this resolved.

Response from our Infra Team is.

One of the utility daemon log file had grown very big (5 GB) because of which things were not working.

I will try to get the name of log file and paste here.
[/color][/size]