Automatic Workflow Creation

We are working with TeamSite 6.1 on a Windows 2003 server and yesterday I was asked if it is possible to write a script that will automatically generate a workflow based upon fields in a web rsponse form. I am open to suggestions but I see quite a few impediments to this. I see a problem knowing which branch/workarea to start the workflow in. I see the business not knowing all the optional steps that may or may not be required and I also see the business not knowing who the proper players for all the different content.

To that end, they have requested that the workflow be first routed to a "functional manager" who would then assign the content creator and choose the optional steps, such as legal review, needed for that content.

This makes a couple of assumptions:
1. A workflow can be automatically generated from an online form
2. Optional steps can be added after a workflow has been created.

Quite frankly, I don't see this in the workflow developer documentation and am not sure it is possible.

Thoughts? Ideas? Jeers?

Paul

Find more posts tagged with

Comments

Migrateduser

This makes a couple of assumptions:
1. A workflow can be automatically generated from an online form
2. Optional steps can be added after a workflow has been created.

Quite frankly, I don't see this in the workflow developer documentation and am not sure it is possible.

Thoughts? Ideas? Jeers?

Paul

Responses:
1. YES You can invoke the workflow automatially using the CLT tool iwjobc this takes a job specification file (xml).
2. NO You can't add or remove workflow tasks once instantiated. You can use sub-workflows to achive some flexiblity in adding the tasks.

ISCBorisB

You absolutely can create workflows dynamically.

As pointed, you can use iwjobc or if you need fine control
TeamSite::WFtemplate / TeamSite::WFsystem to create workflows.

It may be benefitial to split your WF's, the first one targeting "Functional Manager".
After he supplied extra details (via CGI task for example) you may spawn totally different
WF from the external task of the original one or use nested WF.

Although it's true that you can not add /remove steps to existing WF you can make quite
elaborate transitions where depending on WF Tags
(set before WF instantiation) and / or dynmically changing WF variables
one or another flow gets executed.

kaalraa

Paul,

The best possible option to overcome the problems in your situation is to use wfconstructor.pm.

For example:
Use a launcher workflow which have the bare minimum number of tasks. Say the input screen and the workflow instantiator perl script.

Just pass on the CGI input screen to your functional manager and then depending upon the inputs provided by him.. just shoot your dynamic job specification file creation and instantiation.

As far as your query about dropping and linking of tasks on different conditions. Whil eusing wfconstructor.pm you have to link the tasks according to your needs. It means that you declare all the tasks which can be needed in all situations but link only those which are to be used as per the inputs,

I hope you better fly with dynamism that a dynamic workflow can give you.

jbonifaci

Actually, I think the easiest solution would be to use a single workflow. I am adamantly against using nested workflows as I believe they over complicate things when there is rarely the need.

Let's say you want the functional manager to be able to choose whether 4 different approval types are needed. Your first task would be a cgitask for the functional manager to select which approvals are needed. You'll have 4 job variables "ApprovalOneNeeded", "ApprovalTwoNeeded", "ApprovalThreeNeeded" and "ApprovalFourNeeded". If the functional manager says the approval is needed, you set the corresponding job variable to 1, if it is not needed, you set it to 0. Then, before each approval task in your workflow, you have an external task that simply takes in the name of a job variable and transitions to the successorset in the job variable.

So the workflow would flow something like this:

Functional Manager CGI Task
  - FM selects necessary approvals and transitions to "Approval One Task Picker External Task"
Approval One Task Picker External Task
  - Evaluate "ApprovalOneNeeded" job variable
    - 0 go to "Approval Two Task Picker External Task"
    - 1 go to "Approval One User Task"
Approval One User Task
  - Approval one happens and transitions to "Approval Two Task Picker External Task"
Approval Two Task Picker External Task
  - Evaluate "ApprovalTwoNeeded" job variable
    - 0 go to "Approval Three Task Picker External Task"
    - 1 go to "Approval Two User Task"
Approval Two User Task
  - Approval two happens and transitions to "Approval Three Task Picker External Task"
Approval Three Task Picker External Task
  - Evaluate "ApprovalThreeNeeded" job variable
  - 0 go to "Approval Four Task Picker External Task"
  - 1 go to "Approval Three User Task"
Approval Three User Task
  - Approval three happens and transitions to "Approval Four Task Picker External Task"
Approval Four Task Picker External Task
  - Evaluate "ApprovalFourNeeded" job variable
  - 0 go to "Submit Task"
  - 1 go to "Approval Four User Task"
Approval Four User Task
  - Approval four happens and transitions to "Submit Task"
Submit Task
  - Submit content

It's fairly simple and straight forward and much easier to develop and maintain, IMO. For the task picker external task, all you really need is something like this:

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

my ($JobVariable, $JobId, $TaskId, $Workarea) = @ARGV;

my $TaskObject = TeamSite::WFtask->new($TaskId);
my $JobObject = TeamSite::WFworkflow->new($JobId);

my $Successorset = $JobObject->GetVariable($JobVariable);
chomp($Successorset);

if ( (defined $Successorset) && ($Successorset) )
{
 if ($Successorset =~ m|\D|)
 {
  $Successorset = 1;
 }
}
else
{
 $Successorset = 0;
}

$TaskObject->CallBack($Successorset, '');

~Jeff

kaalraa

Jeff,

As far as my advice is concerned, is not of the nested workflow. Its only about a launcher workflow having a CGITASK picking up the values by functional manager, an EXTERNALTASK creating on the fly a job specifcation file based on the values and last the ENDTASK which activated as and when the external task comes to an end.

Also as of now, Paul has just provided one of his pre-requisites. Might be there are some more, so keeping them in mind i have suggested to use wfconstructor.pm

Anyways I am surprised to see such a long reply for a solution.

jbonifaci

As far as my advice is concerned, is not of the nested workflow. Its only about a launcher workflow having a CGITASK picking up the values by functional manager, an EXTERNALTASK creating on the fly a job specifcation file based on the values and last the ENDTASK which activated as and when the external task comes to an end.

Yes, but I would still be against this, as it is multiple wfts. Why overcomplicate things when there is are simpler solutions. Workflow is not rocket science, yet some people seem to try to make it be.

Also as of now, Paul has just provided one of his pre-requisites. Might be there are some more, so keeping them in mind i have suggested to use wfconstructor.pm

Using WFconstructor.pm really has nothing to do with the design of the workflow, only with how the code is written. It is just a simple perl module that outputs your wft xml for you instead of you outputting it yourself. It could probably be better, but it has become a standard among TeamSite developers. But, as I said before, it really has no bearing on the design of the workflow.

Anyways I am surprised to see such a long reply for a solution.

I was giving a useful answer and trying to make it easy for the original poster to understand.

~Jeff

Paul

Thank you all for your replies. I appreciate the different ideas.

Jeff - You know how they say you can't see the forest for the trees? I have actually implemented a solution like the one you suggest. I suppose I could set the content creator, reviewer (for the optional steps) and whatnot as variables in that CGI task as well.

Thanks
PAUL

brokenDiagram.zip

jbonifaci

Paul,

If you're going to have the user in the cgi task also select the user for each of the approvals, you can simply set the task owner using TeamSite::WFworkflow->GetTaskByName() and TeamSite::WFtask->SetOwner() right in the cgi task.

~Jeff

Adam Stoller

This has already been hashed out a bit - but I noticed a lack of mentioning of iwwft_compile.ipl as a means of kicking off the inital (and potentially sub-) workflow(s).

As for using one workflow with lots of optional parts or using a top-level workflow and sub-workflows - I think it depends on the amount of similarity and differences between the processed to be run based on the information entered in the initial input form and/or by the functional manager.

If there are a lot of similarities - then I would try to go with the consolidated approach.

If there are a lot of differences - then I would lean towards having distinct workflows for the different processes (each of which may still have variable components but not as complex as trying to do everything in one workflow)

If you go with the sub-workflow concept - then it's a question of whether the functional manager needs to "oversee" the workflows or whether they're essentially a dispatcher.

In the first case - wfttask's make sense.
In the second case - instantiating workflows via iwwft_compile.ipl or iwjobc -i probably make more sense.