Recommended best practices for creating a workflow

Hi,

I was wondering what the best practicies would be for creating a complex workflow(s) in teamsite 6.5. What would be the preference? Just write out a large xml to define the workflow, or build the workflow on the fly with a set of perl modules?

Thanks in advance,
Ankur

Find more posts tagged with

Comments

Adam Stoller

I've become a fan of the TeamSite::WFconstructor module so that aside from the begin/end template_script XML tags, the entire WFT is coded in Perl in a somewhat OO manner. Examples of its usages can be found in some of the 'solutions' workflows that come OOTB.

However - the first step is to make sure you have a good design - I highly recommend drawing it out in Visio or some other graphic program (Visio stencils exist on the DevNet site, as does my workflow tutorial supplement - just search for them - you should be able to find them).

The more design work you do up-front, the quicker and easier the actual development process will be.

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

Migrateduser

Hi,

I already have a design ready but in order to sell it to my track lead, I have to come up with pros and cons of following the perl framework.
Can you please help me out in deciding how exactly the Perl framework approach is better than pure XML tag approach apart from usual benefits of reusabilty, maintainability and easier debugging?
Are there any best practices suggested by Interwoven to implement a workflow?

Thanks in advance,
Ankur

awizardly

Like ghoti, I am a big fan of WFConstructor. I write all new workflows that I developer using the perl syntax. Hopefully this gives a basic outline of why.
The WFConstructor Syntax makes workflow creation editing and debugging alot easier

Basic Steps:
1. Define Workflow
2. Define All Tasks
3. Link Tasks
4. Do conditional logic and possiblly make certain tasks dormant/inactive
5. print out WF xml with __INSERT__

The major power of the WFConstructor syntax is in steps 3 and 4.
Basically in step 3 you define
a -> b , b -> c , c -> d with linktask functions.
Now if you wanted to rearrange things
a -> c , c -> d , d -> b
Doing so in the xml syntax requires rearranging several predecessor and successor sets to make this work.
In the WFConstructor syntax this is as simple as changing a couple link_task statements.
It's also much easier to comment out 3 link_task statements and introduce 3 new ones than it is to change the xml in tasks a,b,c,d for predecessors and successors. This makes changes to the workflow alot simpler IMO, and easier to read.

Step 4 is where the WFConstructor shows some of its true power though. The ability to make certain tasks dormant for a particular invocation of a workflow is extremely powerful and convenient
Same scenario:
a -> b , b -> c , c -> d
Let's say step b is an optional review step. If the instantiator starts a WF, and unchecks the optional review step you want to make the workflow go.
a -> c, c -> d
With the xml syntax this would probably involve some really ugly conditionals inside the xml template requiring painstaking definitions of all the combinations successor and predecessor elements you would need.
with the WFConstructor syntax you just make task b dormant and the workflow skips the optional review step.
declare_dormant ('b');

Much simpler to see what is happening, and much easier to code too. This will allow you to do alot more really complex conditionals, which would be too difficult to manage using the xml. Obviously this WF development style requires much more familiarity with perl, but its so much more powerful.
I only use the xml syntax now when looking at prebuilt workflows that I am asked to modify/edit. Even then I am tempted to sometimes rewrite them if I will need to do future modifications to them.

Lee
Organic Inc
http://www.organic.com

kaalraa

Hi there,

As you are a new user, i would also like to recommend you to start with WFconstructor. It would be of great help to you in matter of debugging, cleaning and reusability of the code. Just few days before i have written my first dynamic workflow with help of Fish and other members of Devnet.

In XML format you have to take care of all the configuration things as well as your own design logic.. working in right place or not. Whereas in auto creation of wft you just have to be concentrated on your design and logic.

The implementaion is really easy and moreover it can be called from wft or an ipl as well. If you call from a wft file.. it invokes as a nested workflow... whereas from an ipl .. it runs as a new job altogether.

All the Best... c u

- AKs.... The Shadow