Workflow: Modeler vs. Constructor

Hey all,

We've got a number of large workflows headed our way for a new project. I will have a learning curve to use the WFconstructor module, but I've got some great examples and I'm fairly confident I can make it work.

We are going to be using 6.7.1 on a windows server, and a colleague mentioned that I might want to take advantage of the new workflow modeler.

Since I'll have a learning curve in either case, I was wondering if anyone could provide some insight into which might be the best in terms of maintainability, customization, and future support (I'd hate to make a perl workflow only to have it become deprecated in some future release).

Any thoughts? Pros/Cons?

Thanks

Find more posts tagged with

Comments

Migrateduser

I would prefer WFconstructor as there are many examples provided by interwoven. I have not yet tried the 6.7.1 workflow modeler so not sure how easy it will be.

Bill Klish

The new modeler is easy to use, but has a decent learning curve to get working correctly. There are some problems with the models themselves as well, which I am told will not be fixed until SP1 for TeamSite 6.7.1 expected in the second half of 2007.

The most annoying limitation that I found is not being able to have 2 tasks with the same successorset description. For example, if you have a common error pathway within your workflow and all tasks have an "error occurred" transition, this is not supported currently. You would have to uniquely identify each successorset with a unique name.

I haven't tried to work with the data source or DCT setup yet, but hope to soon.

JMcNeil

Anyone else who has used both systems have any feedback?

Also, about the common error task, how have others tackled that in the past?

I'm thinking of having an available transition at the end of every external task which points to a "Retry" type usertask. But I'm not sure how to specify the successor of that task if it depends on which task is was that called it. (I'd prefer not to have to have a unique error task for each external task).

Any thoughts?

Sample.Zip

yanSi

If the Retry task is a usertask, then interaction is required from the user. This means that the user would be responsible for clicking a button to determine which externaltask to retry. Your Retry task should then contain a list of successorset elements each with a different description which will be used for the button label and once the particular button is clicked, the task specified in the succ element will be activated.

Bill Klish

The common transition name issue appears to be fixed in 6.7.1 patch 2.

JMcNeil

I'm looking at this patches details (without necessarily wanting to download the full patch), and I don't notice any reference to this problem in the Modeler, is it just in the release notes? Do we have to update the TS server, or just the Modeler client in order for this problem to go away?

Frederik

@JMcNeil :

taken from IWOV-win-WorkflowModeler-1.0.0-p69620_README.txt, part of "6.7.1 Patch 2"

* Bug ID 69838: Unable to provide same names for links, even though they are in two different tasks. Platform(s): Generic

I guess updating the WFM client is a minimum. Not sure if you need to apply the patch for teamsite that is also in this "Patch 2".

JMcNeil

I upgraded the client, and not the server, and it works great now