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

Basic Workflow Questions...

kris1

I've read through Interwoven's documentation for workflows, and must say that a lot of fundamentals appear to be missing. I had a couple of very basic questions, I was hoping anyone could answer:

1. What does a successorset element match against when determining which script goes next. If I were writing a cgi-script as a cgi-task, how do I pass back to the workflow the exiting state of the script? For example, the iwwfsubmit.cgi file appears to return values like "onSubmitConflicts", "onSubmitErrorsNoConflicts", etc. (As an aside, is there any way to specify the description attribute of the successorset element in Workflow Builder?)

2. If I was making a Submit and Deploy workflow, how do files get carried thru the workflow if the <files> tags can only be used for start tasks. I've taken the default_submit.wft file that comes with Teamsite v5.0, and have added another cgitask for deployment. But, I haven't been able to figure out how to tell the deployment script what files were first selected, and then submitted. I've tried Teamsite::WFTask->GetFiles() after keying on the taskID, but that returns an empty array.

Any help you can provide would be much appreciated!

Find more posts tagged with

Comments

Migrateduser

I'll respond to your questions by number:

1) I think what you're asking here is when you have more than one successorset in your successors, how do you control which successor is selected? There are 2 ways of calling back from a cgitask or externaltask and control which successorset is executed. You can use the description attribute of the successorset tag to point to the successorset that will be chosen, or you can use a return code. Return codes start with 0 and increment for each successorset. Say you have 3 successorsets within a task. To point to the first one you'd use a return code of 0, to point to the second one, use a return code of 1, etc. The values you're seeing in iwwfsubmit.cgi are shown in one of the standard workflows delivered with TeamSite called default_submit.wft (this workflow should be in your iw-home/local/config/wft/default path or something equivalent for your installation). You can, in fact, use any of these descriptions for successorsets in a submittask in any workflow you develop and depending on what happens during your submit, it will callback appropriately. I cannot view iwwfsubmit.cgi because it has been protected by Interwoven and is not viewable, so I can't see the syntax they use to callback using descriptions. If you send me the callback code used in iwwfsubmit.cgi, I can see how they're using it. As far as Workflow Builder goes, I don't use it at all. I have always written my workflows in perl and find Workflow Builder cumbersome, so I will most likely never use it. I would think there would have to be a way to specify a description for a successorset using Workflow Builder, but I really have no clue how it's done.

2) Even though the Files tag is only used in start tasks, the files are attached to every task in the workflow, and you can manipulate the files (adding or deleting files to the job) at any task in the workflow. You can do this through the TeamSite GUI or in extarnaltask or cgitask scripts programmatically. Whenever you execute an externaltask, 4 parameters are automatically passed to the script (Job ID, Task ID, Areavpath, Files). No parameters are passed to a cgitask script. I always use an externaltask for deployment, so the array of files is conveniently passed automatically. I'm curious why you are using a cgitask to do your deployment? Regardless, you should be able to get the files using the GetFiles method. Perhaps there's something wrong with the way the files are initially being attached to the job. Are you certain you're taskid value is correct? How are you determining the taskid in your CGI script? I always use a debug file to print out the values in my variables so I can be sure everything is set the way I think it should be when problems like this arise. I'm sure you already know this, but here's how I've used GetFiles in my scripts:

use TeamSite::WFtask;
use TeamSite::WFworkflow;

my ($jobID) = @ARGV;

my $workflow = new TeamSite::WFworkflow($ARGV[0]);
my $task = new TeamSite::WFtask($taskID);
my @files = $task->GetFiles();
if (@files) {
# Add filenames to manifest
foreach my $file (@files) {
# Do something
}
}

Hope this helps.

Dave Smith
davidh.smith@nike.com

<font color='red'>Dave Smith</font>
DavidH.Smith@nike.com

brent1

I know this post is old, but, I was wondering if you ever found an answer to your second question. I am currently trying to do something similar with default_submit.wft and have found that the files are detached from the workflow after the SubmitIt task.

Brent Seddelmeyer
Beckman Coulter Inc.

Migrateduser

I'm not sure I understand your question. Dave's response was concise yet pretty thorough. The only other thing I think he should have mentioned is that if you need to add files further along in the workflow, you can use

$task->AddFile();

in an external or CGI task. Perhaps if you could be a bit more specific about what your specific issue is we could be more helpful to you.

Cheers
Rob Huffstedtler
rob@bagpipe.com

brent1

My question is specifically regarding the Submit Workflow (default/default_submit.wft) that comes with v. 5.0.1 of the product.

It appears that the first CGI task in this workflow (iwwfsubmit.cgi) removes the files from the workflow. If you query the task while the task is active you will find your files attached to it. If you query the task after the task inactivates you will find no files attached to it. Subsequent tasks also have no files associated with them.

I would like to add an external task to default_submit.wft to perform a deploy, but, I am not sure if I can maintain the file list through this entire workflow.

Any help from anyone that has modified default_submit.wft would be appreciated.

Brent Seddelmeyer
Beckman Coulter Inc.

Migrateduser

I don't see why the cgi would remove files from the job - that makes no sense at all. What method are you using to determine whether the files exist in the job after the submit task? Try using a submittask instead of an externaltask to submit your files.

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com

brent1

Agreed, removing the files from the job makes no sense. Remember, this is Interwoven's cgi that comes with TeamSite (iwwfsubmit.cgi) and unfortunately that is what it seems to do. I was hoping to be able to modify the default_submit.wft workflow that the users have been using to include the deploy to production so that it looks no different to the users after the change.
I was able to do this, but, I had to add some code and an additional external task to the workflow to add the files back in after Interwoven's cgi task.
I'll try to attach my code in case anyone is interested.

Brent Seddelmeyer
Beckman Coulter Inc.

Migrateduser

While it's nice that Interwoven supplies the sample workflows, they are extremely limited in what they can do for you. You don't have to make a significant change to the workflow to keep it similar enough to the default_submit workflow. Besides, you're changing it anyway to add the deployment, so it's a good time to lose the externaltask for submitting and replace it with a submittask. In my opinion, it's an oversight on Interwoven's part to even provide a sample workflow that uses an externaltask rather than a submittask to submit files to STAGING.

Now an even bigger issue - the fact that Interwoven supplies scripts that are encrypted so that you can't look at the code or modify them. iwwfsubmit.cgi is an example of this. What the **** good does a script do for me if it is undocumented and I can't read it? I sort of understand why you'd want to use the sample workflow, but I would also say shame on you if you are using code that you can't read, so you really don't know what it's doing. I still can't believe that this script actually removes files from your workflow, but since I can't read the code, I can't prove it. The correct solution to your problem is not to add files back into the workflow - use the submittask and the files won't disappear at all. And don't rely on code when you don't know what it's doing.

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com

Adam Stoller

Smitty77's response is reasonably accurate but let me see if I can clarify a few points.

With respect to the first question:

What does a successorset element match against when determining which script goes next...

The Perl module, TeamSite::WFtask contains a CallBack method which takes two arguments: idx and comment

The first parameter is the index of the successorset within the current task's definition, to activate (it's like but not a "return code" as it assumes no relevance to the success or failure of the script that was run - it is simply an indication of which successors to activate).
As pointed out, the index is zero-based.

If you are using the TeamSite::CGI_lite Perl module, there is an iwcallback method which similary takes two parameters: transition and comment

In this case, the first argument is a string, and must match exactly the string used in the description of the successorset you wish to activate.

If you have:


   &lt;successors>

     &lt;successorset description="Choice1">

       &lt;succ v="first_choice_task"/>

     &lt;/successorset>

     &lt;successorset description="Choice2">

       &lt;succ v="second_choice_task"/>

     &lt;/successorset>

   &lt;/successors>

With TeamSite::WFtask::CallBack() you would use a first argument of either 0 or 1.

With TeamSite::CGI_lite::iwcallback() you would use a first argument of either Choice1 or Choice2.

For externaltask scripts - you cannot use the CGI_lite module, so you are always using an index value as part of the callback.

For cgitask scripts - you have a choice.

With resepct to the default_submit workflow using a binary CGI script - I believe that was more for performance than to hide anything - and you'll find that the default_submit.wft and author_submit.wft in the 5.5.2 release do use the submittask rather than the previously described cgitask with the binary cgi program.

However, it might be worth pointing out that there is a distinction between the two strategies since the submittask allows for only a single successorset it relies on internal mechanisms to handle conflicts - whereas the cgitask allows for multiple successorsets and can thus cause a workflow to transition in different directions based upon the results of attempting to perform the submission.

I will confess that I haven't played around with it sufficiently to be able to state what will happen when a conflict occurs within the confines of a submittask, but for lack of any proof the other way I will assume it does "the right thing"

With regard to the second question:

... how do files get carried thru the workflow ... I haven't been able to figure out how to tell the deployment script what files were first selected, and then submitted. I've tried Teamsite::WFTask->GetFiles() after keying on the taskID, but that returns an empty array.

When you say "after keying on the taskID" what do you mean? You want to create a task object and call the GetFiles method from that object, not from the class itself. I.e. something like (assuming a cgitask script):


    ...

    use TeamSite::WFtask;

    use TeamSite::CGI_lite;

    ...

    my $taskid = $cgi->{form}{iw_taskid} || $cgi->{form}{task_id};

    if (ref($taskid) eq "ARRAY"){

        $taskid = $taskid[0];

    }

my $task = TeamSite::WFtask->new($taskid);

    ...

my @files = $task->GetFiles();

    ...

    $cgi->iwcallback("ss_description", "my comment");

    exit(0);

As Smitty mentioned, for externaltasks, the taskid is passed on the command line as one of the parameters to the script. Do not assume the file list is also passed on the command line. It has been in the past, but there are configuration options to prevent that and it might get changed completely in the future (consider that passing a larget number of area-relative paths to files on the command line could overrun the OS/shell-imposed limit on command line length fairly easily). For that reason you should same code as highlighted above - except that in this case the taskid will be passed in on the command line and you don't have to worry about if it is an array reference or not. Also you would use the $task->CallBack() method as discussed in the answer to the first question.

Adding and deleting files from the task list is a simple matter of using the methods available from the TeamSite::WFtask module (AddFile(), RemoveFile(), and commming in 5.5.2 AddMultipleFiles())

I hope this clarified (and not increased the confusion)

--fish

(Adam Stoller)

Curriculum Development

Interwoven, Inc.

Migrateduser

This is just a response to the part about iwwfsubmit.cgi.

Performance? You can't be serious. I think that delivering a sample workflow that uses a script that is not readable is pretty bad. Even if the executable is binary for "performance" reasons, they could at least have delivered a readable version as well so people could try and figure out what it was doing. After all, this was supposed to be an example that people could build from. If the one that's delivered in newer versions is not binary, that's a good thing. Evidently performance is taking a back seat to common sense. Smiley Happy

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com