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

listing all job variables

System

I just had a need to list all of the job variables in a CGI task (there's an incredibly long story behind this that no one really wants to know about), and discovered much to my surpise and chagrin that WFworkflow.pm does not have a method for getting the list of variables. No problem, I thought, I'll just call iwjobvariables directly. My surpise was greatly increased when I discovered that it also lacks any ability to do this.

Has anyone else out there ever had this need, and if so, how did you solve it?

Find more posts tagged with

Comments

james1

If you run "iwgetwfobj <jobid>", you can inspect the returned XML for all job variables.

I expect TS5.5.2 SP3 to have a TeamSite::WFworkflow::GetVariables() method.

-- James

--
James H Koh
Interwoven Engineering

Migrateduser

Don't know why I didn't think of that. Rather a pain since I'll have to parse the result with TeamSite::XMLparser, but it would be a way around the problem.

james1

If you can parse the result with *ANY* XML parser, not just TeamSite::XMLparser, in case that makes it any less of a pain for you...

-- James

--
James H Koh
Interwoven Engineering

Bowker

You could also get the output back and instead of the XMLParser option you could use a simple regex to get the keys and the values. I believe it would be quicker. XMLParser tends to be slow (1/2 second to actually find the first element searched for)

Adam Stoller

For what it's worth, I've filed a feature request (35581) asking to provide a GetVariables() method for the TeamSite::WFworkflow module to correspond to the method that exists in the TeamSite::WFtask module. Contact support to register your interest in this feature.

Until then, parsing the output from iwgetwfobj is the officially supported work-around.

--fish
(Interwoven Senior Technical Consultant)

Error1.png

Adam Stoller

I'm slipping now - Ignore my previous post that ID should not be used - because I had already filed this feature request before (ID = 29549) but for some reason failed to find it when I looked last night.

Sorry for the confusion.

--fish
(Interwoven Senior Technical Consultant)

Migrateduser

I was going back through my old posts, trying to find a specific one where Smitty had pm'ed me for being too hard on a guy (yeah, I had some unread PMs that were two years old), and I came across this. It's funny because I think the same question that prompted this was an earlier attempt at the thing I just posted about in the perl forum.

I am glad to report that somewhere along the way GetVariables() did get added to WFworkflow.pm. There is one weirdness about the way it was implemented, though. Who on earth thought it was a good idea to have it return a ref to an anonymous hash instead of just a flat list that I could assign into an existing hash? I don't really mind having to do this -

my $taskVars = $task->GetVariables();
foreach my $key (keys %{$taskVars}) {
$varHash->{$key} = $taskVars->{$key};
}

but I can imagine that folks who never wanted to be perl coders would find the above to be a bit ugly.

Anyway, I'm just happy that I can do what I wanted to do, and it only too two little years.

Dwayne

Performance, I would assume. Returning an array would result in the data being copied around a few times that might not be needed.

BTW - I think this line of code does the same as what you meant your loop to do:

my %varHash = %{$task->GetVariables()};

--

Current project: TS 5.5.2/6.1 W2K

Migrateduser

Yeah, performance is probably a good guess, but I can't imagine that there is anyone out there who has more than a few variables on a job or a task. Then again, I've seen enough stuff now that I know that people will push any feature of TeamSite to the limit and beyond.

Your code example is not quite the same as what I'm doing, bc in my case $varHash is a hash reference. I pass a ref to a hash in at the beginning of the function, under the theory that I might later move it to a module, and the hash might already have some elements. That will probably never happen, but keep in mind that my goal here is maximum reusability.

I tried this:
%{$varHash} = %{$task->GetVariables()};

but that still stomps any previous contents of whatever was referenced by $varHash. Not a big deal, anyway.

Adam Stoller

I think at one point I suggested that it would be better to pass in a reference to a hash and have it filled by the method - i.e. something like this:

my %hash;
$task->GetVariables(\%hash);

but for whatever reason, that wasn't used - and, as has been pointed out, it is better to pass or return scalars (e.g. references to hashes or arrays) rather than to pass or return the full data-structure - so the two choices were either passing in a reference or returning a reference and the powers-that-be at the time decided to return a reference, and so that's how it stayed.

Believe it or not - every little bit of performance improvement you can get makes a difference because it all adds up (I once got a customer a 60% performance boost just by cleaning up their Perl code)

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