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

chaining workflows

msrich

W2K TS 5.5.2 + SP2B; TST 5.5.2

Any best practices info available on chaining workflows -- calling a follow-on workflow at the end of a workflow?

Find more posts tagged with

Comments

Migrateduser

You might want to consider using nested wf instead of chained wf - you'll get better clean up (although smitty might disagree,see other posts on nested wf).

There is a new WF guide with 552 SP3, you could take a look at that on the support site - https://support.interwoven.com/library/manuals/teamsite/pdf/552/ts.552.wf.pdf

Regards,

lissa

Bowker

We created an external task to get components of the 'parent' workflow (variables, files, owner...) and built the 'child' .xml file filling in the blanks as necessary (owner, areavpath, task owners...).

It works well. In fact that's how we allow authors to build screens/content then request approval later. That way they don't need to know who is going to approve the work until the work is finished. This is not exactly how it works but you could (i think) create a CGI task to get info from the user at that point.

Migrateduser

lissa mentioned the new doc that is out on the support website. In addition to that I would offer the following advice about either chained or nested workflows... keep it simple.

Too many times I have seen implementations where the workflow become unusable because the process the workflow tries to implement is too complicated.

You may want to review the process before you jump into chained workflows.

self signed cert.bmp

Adam Stoller

Chained and nested workflows both have their uses (pros/cons) - consider what your overall objective is before deciding which way to go.

Chained workflows generally require "master" priveleges to invoke the job.
Nested workflows can, I believe, be done without requiring that a "master" own the wftask (I could be wrong here, I haven't used a wftask in a while and it's not something I remember off the top-of-my-head).

Nested workflows provide the hooks to allow the "child" workflow to access information from / set information in the "parent" workflow.
Chained workflows generally require that your implement those hooks yourself.

Chained workflows do not require that the initiating workflow persist after the chained workflow is instantiated.
Nested workflows do require that the "parent" workflow persist until all the "child" workflows complete.

There are probably a host of other comparisons that can be made - ultimately you have to consider your objectives / requirements.

The current implementation that I'm working on (as part of a team) uses a chained workflow for the Submit operation, that filters the files associated with the initial workflow into categories, fires off however many sub-workflows as necessary (the exact same wft that can be called from New Job) and then gracefully exits letting the sub-workflows go on their merry way. This was a reasonable choice because the initial workflow had nothing left to accomplish after spawning the other workflows.

--fish
(Interwoven Senior Technical Consultant)

laj1

You might want to consider using nested wf instead of chained wf - you'll get better clean up (although smitty might disagree,see other posts on nested wf).

Smitty is now being referenced in threads in which he has yet to participate. This is a milestone for the DevNet forums, and officially elevated Smitty to the status of DevNet Forum Personality

Len.

Len Jaffe
My Heart Is A Flower
Update your DevNet profile - let us know who you are!

Migrateduser

It sure would be nice if life was simple. Unfortunately, sometimes customers require a complicated process to get the job done. It is certainly reasonable to expect this workflow system to perform some very complicated processes. It all boils down to your competency and how much effort you want to put in to go where not too many people have gone before. You can't just tell your customers you can't do something because it's hard.

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

Migrateduser

Darn - I should have read this post first before responding to one of the other posts in this thread. I guess I burned my 15 minutes...

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