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

Pass Variables into Workflow?

bettineski

I have a workflow where one of the tasks calls an ipl, who in turn calls a webservice.

I've got it working just fine right now, but that's because for testing I hardcoded the variables into the webservice ipl call.

But this workflow is going to be used by many DCR's, and I need to figure out a way of passing these variables into the workflow so that it can pass them along to the ipl call.

I've read through the documentation and have searched the forums, but I'm not seeing anything that helps me. It may be that I'm asking the wrong question. There might be a better way of doing this. If so, does anyone know it?

Thanks!

Find more posts tagged with

Comments

bettineski

We are now looking into passing metadata for this. Might do the trick.

bettineski

Oops. I said Metadata when I meant Extended Attributes.

Is there a way in WFM to have the workflow read the EA's?

I'm trying to figure out how to read the EA's as variables, and then have the Workflow call an .ipl and pass the variable into it.

I've got the WFM User Guide, but it doesn't have anything about this. I'm worried it's not possible...

CRB

your description of the problem isnt very clear.

my guess is that you want to attach DCRs to a WF which invokes an ipl. then process the DCRs with their EAs in your ipl...

you dont need to pass EAs as variables, since you can read them in your ipl using the TS cmd to read EAs. so you will need to use getAttachedFiles() and run the cmd iwextattr on each file.

if that is not what you need, please explain what variables you need and your scenario.

bettineski

you can read them in your ipl using the TS cmd to read EAs. so you will need to use getAttachedFiles() and run the cmd iwextattr on each file.

Yes, essentially this what I am looking to do, only how would the .ipl know which DCR is calling it?

If the workflow calls an ipl, how can that ipl use getAttachedFiles()? Isn't an external task external from the workflow?

This is why I thought of having the Workflow read the EAs then pass that along to the ipl. So that way the workflow can be used by multiple DCRs.

So that's why I was asking about how do I, inside Workflow Modeler, have a workflow read an EA.

If there's a better way of doing this that I'm unaware of, I'm all ears. Smiley Happy

Thanks for the reply.

CRB

could you explain how you are calling your ipl from the WF?
are the DCRs attached to the invoked WF?

in general when you call an ipl from a workflow with attached files, there are a lot arguments that automatically get passed to your ipl ( jod id, task id, attached files...).

depends how you are calling your ipl, you could use task id to get the attached DCRs, or you might find your files passed as an arg and separated with ",", you will need to d something like this:
[HTML]
use TeamSite::WFworkflow;
use TeamSite::WFtask();

##print @ARGV and see what it has
my($files, $jobID, $taskID, $workarea)=@ARGV;
my $task = new TeamSite::WFtask($taskID);
my @files = $task->GetFiles();

## process your files

$Task->CallBack(0, "failed");
[/HTML]

Adam Stoller

could you explain how you are calling your ipl from the WF?
are the DCRs attached to the invoked WF?

in general when you call an ipl from a workflow with attached files, there are a lot arguments that automatically get passed to your ipl ( jod id, task id, attached files...).

depends how you are calling your ipl, you could use task id to get the attached DCRs, or you might find your files passed as an arg and separated with ",", you will need to d something like this:
[HTML]
use TeamSite::WFworkflow;
use TeamSite::WFtask();

##print @ARGV and see what it has
my($files, $jobID, $taskID, $workarea)=@ARGV;
my $task = new TeamSite::WFtask($taskID);
my @files = $task->GetFiles();

## process your files

$Task->CallBack(0, "failed");
[/HTML]

The following code is more generic and does not assume any explicit parameters being passed on the command line, only implicit ones - and is simpler to debug from the command line:

use TeamSite::WFworkflow;
use TeamSite::WFtask;
...
my ($jobid, $taskid) = @ARGV;
my $task = TeamSite::WFtask->new($taskid);
if (! $task->IsValid()) {
    # ERROR OUT
}
my $area = $task->GetArea();
my @files = $task->GetFiles();
...
foreach my $file (@files) {
   # Do something... e.g.:
   if ($file =~ m|templatedata/.*?/.*?/data/.*$|) {
      # This is most likely a DCR ...
   }
   else {
      # This is not a DCR ...
   }
}
...
$task->CallBack(0, "Done");

}

ccprofessional

Oops. I said Metadata when I meant Extended Attributes.

Is there a way in WFM to have the workflow read the EA's?

I'm trying to figure out how to read the EA's as variables, and then have the Workflow call an .ipl and pass the variable into it.

I've got the WFM User Guide, but it doesn't have anything about this. I'm worried it's not possible...

Passing variables to a WFM works differently than passing variables to a WFT. If you are planning to pass something to a WFM at instantiation time you can use the Datasource framework that can do anything a normal DCT could do. It involves creating your own custom_instantiation form, then running 'iwmodelc' etc.

If you look up on custom instantiation, creating custom variables and how to use the WFM variables.. you should find your answers. Is this what you are looking for?

bettineski

Thanks for all the help with this. I just got in this morning and was pleasantly surprised with all the replies.

CRB: To answer your question, this is how I am calling the ipl:

In WFM is I have an External Task, and the command is this:

[html]
$IW_HOME/iw-perl/bin/iwperl $IW_HOME/local/config/wft/solutions/pge_custom/jason.ipl TEST TEST2 TEST3
[/html]

ghoti: Thank you for the code. I am working with it now.

ccprofessional: Thank you for the leads on what to research.

CRB

then the code code I and Gothi gave you should work for you.

i noticed you are passing extra parameters, so print out what is in @ARGV and you will find the right order of passed parameters.

Adam Stoller

then the code code I and Gothi gave you should work for you.

i noticed you are passing extra parameters, so print out what is in @ARGV and you will find the right order of passed parameters.

Please learn to spell my "name" correctly.

You shouldn't need to print out what is in @ARGV - you should know what's in there implicitly:

...It's "bad" because depending on the length of the paths to the files and the number of files associated with the job - you could exceed OS-limitations on command-line-length and/or number-of-command-line-arguments and then your script won't run and you'll have to dig through the log files to see semi-intelligible error messages that won't mean a thing unless you understand this.

bettineski

I see why that would be bad.

Is there an alternative way to figure out the associated file?

The reason being is that an aspx page is generated, EAs attached, and then this file is the associated file.

This way the ipl gets this:

Arg3: \default\main\SITE\REGULATORYAFFAIRS\WORKAREA\root\

Arg4: \about\regulatory_affairs\filings\advice_filings\default.aspx

Then I just concatenate those and point iwextattr at that file and pull the EAs out.

I have it working right now and will post my solution later.

Unless, of course, you have an alternative to doing the "external_task_add_filelist=false" method.

Adam Stoller

I see why that would be bad.

Is there an alternative way to figure out the associated file?

The reason being is that an aspx page is generated, EAs attached, and then this file is the associated file.

This way the ipl gets this:

Arg3: \default\main\SITE\REGULATORYAFFAIRS\WORKAREA\root\

Arg4: \about\regulatory_affairs\filings\advice_filings\default.aspx

Then I just concatenate those and point iwextattr at that file and pull the EAs out.

I have it working right now and will post my solution later.

Unless, of course, you have an alternative to doing the "external_task_add_filelist=false" method.

Please clarify:

ISCBorisB

Unless, of course, you have an alternative to doing the "external_task_add_filelist=false" method.

Ghoti already illustrated the correct "alternative".

WF Task Object contains a collection of Relative path values for the Attached Files regardless of "external_task_add_filelist" Value.
"external_task_add_filelist" is just a trigger that controls whether WF Engine passes a list of attached Files as a "tail list" of the External
Task Script Parameters.

Therefore, the recommended configuration is "external_task_add_filelist=false". You'd have to use GetFiles Method to obtain
the List directly from the Task Object.