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

WF Variables and WFM

nipper

OK, I am playing with WFM. My questions are around how WFM and external tasks behave.

I have an external task that does a check for review needed. First, how can I get the value of IW_REVIEWER(ID12345) in my perl ? I can easily set a second task variable (and hard code it), but since I have it already, I should be able to use what is there.

I have tried using $IW_REVIEWER as well as creating a task variable reviewer and assign it $IW_REVIEWER. No luck.

Also, trying to return from the external task, I have 3 transitions defined. ReviewNeeded (Conditional on True), ReviewNotNeeded (Conditional on False), and Error (which is a timeout). I tried CallBack ("false", "Review Needed") but that is going to my timeout.

So do I need to set a task variable in the script and then write JS to interrogate that value ?

I am certainly liking the old way better.

Tips/Pointers/RTFMs appreciated.

Andy

Find more posts tagged with

Comments

Adam Stoller

OK, I am playing with WFM. My questions are around how WFM and external tasks behave.

I have an external task that does a check for review needed. First, how can I get the value of IW_REVIEWER(ID12345) in my perl ? I can easily set a second task variable (and hard code it), but since I have it already, I should be able to use what is there.

I have tried using $IW_REVIEWER as well as creating a task variable reviewer and assign it $IW_REVIEWER. No luck.

Also, trying to return from the external task, I have 3 transitions defined. ReviewNeeded (Conditional on True), ReviewNotNeeded (Conditional on False), and Error (which is a timeout). I tried CallBack ("false", "Review Needed") but that is going to my timeout.

So do I need to set a task variable in the script and then write JS to interrogate that value ?

I am certainly liking the old way better.

Tips/Pointers/RTFMs appreciated.

Andy

Not having a system to play with all I can suggest are strategies that I might take in such a situation.

In this case - I'd have the externaltask script generate a debugging log file that contains a list of all the environment variables and their values, all the job variables and their values, and all the task variables and their values -- hopefully somewhere in there is what you're looking for.

nipper

Not having a system to play with all I can suggest are strategies that I might take in such a situation.

In this case - I'd have the externaltask script generate a debugging log file that contains a list of all the environment variables and their values, all the job variables and their values, and all the task variables and their values -- hopefully somewhere in there is what you're looking for.

Nothing of help with this:


foreach my $key (sort keys %ENV)
{
 debug($debugFile, "$key -> $ENV{$key}");
}

A bunch of information, nothing that has the info I need, or any of the TS workflow parameters (IW_USER, IW_HOME, etc)

ChartPreview.jpg

ChartActual.jpg

Adam Stoller

Nothing of help with this:
foreach my $key (sort keys %ENV)
{
 debug($debugFile, "$key -> $ENV{$key}");
}
A bunch of information, nothing that has the info I need, or any of the TS workflow parameters (IW_USER, IW_HOME, etc)

And what about job variables and task variables - that I also suggested you log?

nipper

And what about job variables and task variables - that I also suggested you log?

I agree, any idea how ?

Migrateduser

Squeal guinea pig. SQUEAL!!

nipper

No kidding.

This new tool is taking a great deal of time. To make matters worse, the examples (including the training) all use the old way of getting information, i.e. WA, Job, and Task from teh Perl command line.

One thing I have seen is that I can send a known global variable via command line:

iwperl fool.ipl $IW_HOME

and that is accessible. Still not overly helpful since I cannot find my reviewer group variable anywhere (I think it is a local variable).

Adam Stoller

I agree, any idea how ?

Are you saying the TeamSite::WFworkflow and TeamSite::WFtask cannot create job and task objects (respectively) from the command line arguments passed to the externaltask script when the externaltask script is launched from a WFM-generated job??

nipper

Are you saying the TeamSite::WFworkflow and TeamSite::WFtask cannot create job and task objects (respectively) from the command line arguments passed to the externaltask script when the externaltask script is launched from a WFM-generated job??

Yes they can. Those still work. I still am not seeing any data in those that will help.

Adam Stoller

Yes they can. Those still work. I still am not seeing any data in those that will help.

Either I lost the thread of what the problem is, or I just cannot understand it because I don't have access to WFM right now - so unless you think you can explain the problem in more detail - you'll have to wait for someone else to chip in - sorry.

ReportDesigner.jpg

nipper

Sure, I understand that.

MY WF, built with WFM, sets a variable (it appears to be IW_REVIEWERS) to signify the group that is to review the content.

I am writing an external task that want to check to see if the user is a member of that group. If so, it should take a different path than if not.

My problem is two fold.

First I cannot seem to figure out how to determine what this group is. I can certainly hard code it, but I would lke to read the data provided instead. I have read the ENV variables as well as the job and task variables.

The second question is in an external task, how do you control the returns ? I have 3 possible outcomes, review needed, review not needed and timeout (some error occurred). Playing with the callBack(#), I have not been able to figure out exactly how it should work

Andy

Adam Stoller

Sure, I understand that.

MY WF, built with WFM, sets a variable (it appears to be IW_REVIEWERS) to signify the group that is to review the content.

I am writing an external task that want to check to see if the user is a member of that group. If so, it should take a different path than if not.

My problem is two fold.

First I cannot seem to figure out how to determine what this group is. I can certainly hard code it, but I would lke to read the data provided instead. I have read the ENV variables as well as the job and task variables.

The second question is in an external task, how do you control the returns ? I have 3 possible outcomes, review needed, review not needed and timeout (some error occurred). Playing with the callBack(#), I have not been able to figure out exactly how it should work

Andy

Is there someway in WFM to have a WFM/Javascript variable transformed into a job or task variable? (I don't know - something like the iw_setwfarg_ stuff from WFTs - but it would seem the logical process to follow, and then you would be able to access the information in your externaltask script)

As has, I believe, been pointed out - the ordering of transitions in WFM is determined by the order in which the transitions are made in the WFM GUI (this probably seemed like a reasonable thing to do when they developed it, but I think in practice it is rather problematic and somewhat questionable).

IWOV probably needs to provide another method for WFtask.pm that will allow you to access a callback transition by the WFM transition name/id -- I'd suggest filing a FR for this.

ccprofessional

Andy,

The second question is in an external task, how do you control the returns ? I have 3 possible outcomes, review needed, review not needed and timeout (some error occurred). Playing with the callBack(#), I have not been able to figure out exactly how it should work

Maybe you can you have an external task that forks into -
review and timeout.

and review forks into 'review needed' and 'review not needed'

Since WFM allows for javascript in the instantiation form, maybe this logic can be decided at instantiation time as opposed to when you actually design the wf model.

Adam Stoller

Andy,

Maybe you can you have an external task that forks into -
review and timeout.

and review forks into 'review needed' and 'review not needed'

Since WFM allows for javascript in the instantiation form, maybe this logic can be decided at instantiation time as opposed to when you actually design the wf model.

If there's an option chosen during instantiation that controls the process flow - then this might work.
If there's programmatic determination done after the workflow has been instantiated (such as whether a deployment succeeded or failed when run from an externaltask script) - the choice of which transition to take has to be made from within that externaltask script - and that seems to be the problem - figuring out how to control/determine the proper transition callback value to use to get the desired results.

ccprofessional

Ghoti,

If there's an option chosen during instantiation that controls the process flow - then this might work.

I know for a fact that such an option exists.
ie., the Job instantiator can pretty much decide what the flow will be based on javascript in the instantiation Form.

nipper

Andy,

Maybe you can you have an external task that forks into -
review and timeout.

and review forks into 'review needed' and 'review not needed'

Since WFM allows for javascript in the instantiation form, maybe this logic can be decided at instantiation time as opposed to when you actually design the wf model.

The timeout is always needed. I have a timeout on every external task to catch errors. It could be Perl issues, system issues, etc, but I will not have dangling jobs with an external task that has been "running" for months.

It would also make zero sense for an external task to not be able to fork in any direction it chooses. I cannot believe IW would make that kind of design.

ccprofessional

I am looking at the callback documentation, and it looks like you can use the comment string variable to achieve the result of multiple (more than 2) return values.

I quote -


Consider the following as only a rough example of how you might be able to use this
functionality:
...
my($COMMENT) = "=" x 70 . "\n" . scalar(localtime) . "\n";
...
if (something){
$COMMENT .= "Something happened\n";
else {
$comment .= "Something else happened\n";
}
...
$task->CallBack(0, "$COMMENT");

nipper

No, my point is that in WFT, I can put CallBack(0,"Some Comment") to go to the first link and CallBack (1,"Another Comment") to go to a second link. The timeout is yet a third link (which is used if there is an internal script error detected or if the script never completes)

I cannot figure out how to do this in the WFM.

Adam Stoller

No, my point is that in WFT, I can put CallBack(0,"Some Comment") to go to the first link and CallBack (1,"Another Comment") to go to a second link. The timeout is yet a third link (which is used if there is an internal script error detected or if the script never completes)

I cannot figure out how to do this in the WFM.

Is the timeout a timeout-transition (only) or a selectable-transition - e.g.: part of the susccessorsets?

If the former - I don't believe there's ever been a way to transition explicitly to a timeout transition programmatically (except maybe changing the timeout duration programmatically?)

If the latter - then it should be one of the transitions - callback 0, 1, 2, ...

nipper

You see Adam, you are thinking in the WFT mindset. WFM is different (and as fast as I can tell not as flexible)

My best practice for external tasks is having a timeout and an error transition to an Admin task, in addition to the normal transition(s) coming out of a task. That is normally controlled with successorset and callback(somenumber). How that is to be accompished with WFM is the $64K question.

Adam Stoller

You see Adam, you are thinking in the WFT mindset. WFM is different (and as fast as I can tell not as flexible)

My best practice for external tasks is having a timeout and an error transition to an Admin task, in addition to the normal transition(s) coming out of a task. That is normally controlled with successorset and callback(somenumber). How that is to be accompished with WFM is the $64K question.

Can't you draw N transitions from your externaltask?
If you draw a "normal" transition (I forget the exact terminology) for your timeout transition as well as an actual timeout transition for it - then you should be able to access the "normal" transition via one of the callback values.

Clearly, I need to get myself setup with a 671 server sometime soon so I can start to play with this a bit more ...

pdasarat

OK, I am playing with WFM. My questions are around how WFM and external tasks behave.

I have an external task that does a check for review needed. First, how can I get the value of IW_REVIEWER(ID12345) in my perl ? I can easily set a second task variable (and hard code it), but since I have it already, I should be able to use what is there.

I have tried using $IW_REVIEWER as well as creating a task variable reviewer and assign it $IW_REVIEWER. No luck.

Also, trying to return from the external task, I have 3 transitions defined. ReviewNeeded (Conditional on True), ReviewNotNeeded (Conditional on False), and Error (which is a timeout). I tried CallBack ("false", "Review Needed") but that is going to my timeout.

So do I need to set a task variable in the script and then write JS to interrogate that value ?

I am certainly liking the old way better.

Tips/Pointers/RTFMs appreciated.

Andy

All your WFM variables are accessed via $IW_CV(ID12345). Just as a pointer, you might want to look at default_config.xml located at iwadmin\main\workflowModels\WORKAREA\iw-wa\Config\yourmodename\default_config.xml

Can you post your WFM and external script to understand your stance.

Pradeep

JMcNeil

http://devnet.interwoven.com/forums_vb/showthread.php?t=20085&page=2

Check my final post in that thread for how to transition from an external task to the next task of your choice based on the description of that task (ie. 'Error' or 'Success').

Make both of the conditional links coming out of your task default links, and name those links accordingly (they become the successor descriptions of your task).

I'm not sure on the timeout link, I haven't played with them yet, but I presume it should kick in if the task takes too long to complete without having to Callback programmatically.

As for the $IW_CV, I'm not entirely sure, but I think that if you make a task variable on this task, which is a configurable variable (gets filled out at instantiation) you should be able to reference its value as the value of the task variable. in modeler your task variable would look like: variable=$IW_CV(ID12345). When you pick that CV at instantiation the value of the task variable (or make it a WF variable if you like) will be set to whatever was chosen.