workflow ideas???

Though some folks out there might be able to help me with a workflow design...

Essentially, our users will submit a DCR and our workflow kicks off. What we want to happen is start an external task that is going to validate some DCR values, if the values aren't good, they will have a <usertask> to go fix them. If there are good I would like metatagger (mtmetaproxy.cgi to kick off right away). I have tried accomplishing this through a nested workflow but it doesn't seem to run immediately (even with start="t" and immediate="t" set on the task in the nested workflow).

First off, is what I am trying to do achievable?

For example, can you have a <cgitask> start if it is not the first task in the workflow? If so, will this work in a nested workflow? Does anyone have examples of this type of requirement?

Any ideas on this would be excellent :-)

Cheers,

Lucas Cochrane

Lucas Cochrane
lcochrane@dc.com

Find more posts tagged with

Comments

Migrateduser

Can you put the validation logic right into the .wft in addition to the ExternalTask (both could call the same package/subroutine)? Then you could have the .wft notify and start with the usertask if there are validation errors, or the CGItask if there are none. If there are a lot of DCRs per job or the validation logic takes too long, performance might be bad.

Without the validation in the wft, I don't think you can get what you want if the CGITask does not have start=t. But you could have both external and cgitask have start=t - that way the user should see the CGI even if there are validation errors, and the usertask will also be activated - but the externaltask should send them notification so they know they have that to resolve.

Migrateduser

I'll concur. Adding the validation logic to the .wft is your best solution. The validation can be moved to a perl module or other external component that is called in both instances. Then the .wft could set 'Rework File' or 'Set Metadata' to be the first task and begin the workflow.

The uglier way to do it is to create a cgi that runs as the first task. It could store all the needed variables it gets. If validation is succesful, the .cgi runs the metadata .cgi (via a perl exec or straight command-line run.) If it is not succesful, then it does a callback to the next task which is user rework. This task can then be called after user rework.
This method is much more clunky and not officially supported, but does give you an advantage of doing preprocessing for a .cgi.

akshathp

1. CGItask has to be the start task. Custom CGI that you execute with your CGItask has to run in the browser that workflow instantiator opens. Incase you have any other task prior to CGI task, this browser is lost and CGI can't run. This is clearly explained in the workflow developer tutorial.

2. As far as validation is concerned, I believe you have already received answers to that. Also, you could have first CGI task to run your custom CGI that can perform this validation and then have it callback for next CGItask that could be your mtmetaproxy.cgi call.

Hope this helps!

Akshat Pramod Sharma
Interwoven Inc.

Adam Stoller

A <cgitask> does not have to be the first (start) task in order to run immediately - it has to either:

be the start task owned by the same user who initiated the workflow, or
follow a <usertask> or <grouptask> owned by the same user, or
follow another <cgitask> owned by the same user and which uses TeamSite::CGI_lite::iwcallback() rather than TeamSite::WFtask::CallBack()

Smitty - before you rant again (:-) - this information IS being added to the documentation.

--fish
(Interwoven Senior Technical Consultant)