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

Super Workflow

Bryan_K

We were thinking about creating a database driven generic workflow for most of our TeamSite users. Information such as a branch's name, who the reviewer(s) were, where on the web server content from that branch would deploy to, etc. would be contained in a database. We would also specify the number of reviewers for each site (anywhere from 1-5).

Upon starting a new job, 80% of users would be presented with this workflow, which would dynamically create itself based on the information contained in the database. However, we would still like to be able to make other more customized workflows available to the other 20% of the users on a one-off basis.

Our thought process was to somehow marry the iwwft_instantiator.ipl in <iw-home>\httpd\iw-bin with available_templates.

Three questions: One, has anyone else thought of doing this and had any luck? Two, is there a better approach? Three, is messing with the iwwft_instantiator a bad idea? In other words, is this rewiring the guts of TeamSite to the point where we might be affected by future patches or updates?

Thanks,
Bryan

Find more posts tagged with

Comments

Migrateduser

Messing with the iwwft_instantiator is a bad idea.

Why not put an entry for your "Super workflow" into available_templates.cfg, and have your super.wft "do the right thing"?

Brinko Kobrin
Interwoven Staff Engineer

AmyRush

Brinko,
Could you elaborate more on how we can accomplish this? (I work with Bryan_K)

The Decision factor of choosing which workflow template to instantiate based on the data recorded in the database is the quandary we are trying to address.

You sounds like you have a handle on how to do this.

ContorlCenter.jpg

Migrateduser

This almost sounds like the perfect candidate for nested workflow. You need a process to make a determination based on some data in order to kick off another process (workflow). You could have a generic workflow whose first task assesses the database data and based on that info, you'd want to instantiate another workflow, using the nested workflow process. Granted, the nested workflow process is documented very poorly, but if you could implement it properly, you get all the benefits of the workflow process, including being able to archive the entire process, without having to mess with the instantiator.

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

Adam Stoller

If the 20% users who would need to run *other* workflows are easily identifiable - you can use constraints within the available_templates.cfg to limit who can see which workflows. You can look in the manuals or just look at the iw-home/local/config/wft/available_templates.dtd if you can grok DTD's (it's a pretty simple DTD as things go).

If this wouldn't serve your needs - then something along the lines of what Smitty suggested might do the trick - but having not tried it myself I'm not sure if you can dynamically alter the name of a wftfile or jobfile to run as part of an already instantiated workflow (which I belive you would have to do with his suggestion).

The other alternative is to look through the forums here for information about starting a workflow from a custom menu item - it would be similar to what Smitty suggested, but you would be making lower-level calls to instantiate the new workflow (if the new workflow doesn't require any instantiation fields or embedded perl code - it's just iwjobc -i, otherwise it's a matter of setting a bunch of form variables and passing them along with a call to the instantiator)

--fish
(Interwoven Senior Technical Consultant)

Migrateduser

It took me a while scratching my head wondering what you meant by needing to dynamically alter the name of the wft file or job spec file after the initial job had started, but I finally understand why you might need to do that. I was originally thinking there would be a finite (and reasonably low) number of workflows that would be hardcoded as <wftask> elements and all listed as successors to the externaltask that queries the database, and then calls back with the appropriate index to the successor for the workflow they wish to execute. It's very possible that this would become a maintenance nightmare and if indeed the potential sub-workflows need to be referenced dynamically, then some interesting work lies ahead.

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

Bryan_K

What I believe we envision is creating 5 sub workflows. A 1 step, 2 step, 3 step, 4 step, and (imagine that) 5 step workflow. This allows more flexibility for departments that want to have more than 1 or 2 approvers. We would list the number of approvers or do a count on the approvers in the database and then choose which workflow to present to them based on that information. This serves a similar function to available_templates, but we dont want to have to edit available_templates to say "for this branch give them the 3 step, this branch give them the 5 step" and so on every time we create a new branch. We'd like this superworkflow to determine all that information along with who the approvers are, etc. by grabbing it from the database.

For the other 20% that need one offs, we would still control that info with available templates and restricting it to certain branches as needed.

conmgmt

Just wondering...

What if you create the workflow dynamically completely in perl? Would that not work?

You can take a look at the work_order.wft and dual_work_order.wft workflows to see what I am talking about.

We are also planning on creating a similar "super" workflow for our clients. The workflow is configured not based on a database (as in your case) but on information specified in a form that we shall pop (as a questionnaire of sorts) at the point of workflow instantiation.

Our initial thought was to create specific static workflows for all the various combinations of the answers.
We would then create a "super" workflow that would act as a router between the static nested workflows (appropriately passing all the variables).

We then looked at the 2 workflows that I mentioned and were toying with the idea that we could create the workflow dynamically in perl (as in the examples) instead.
Isn't this option better?

Any thoughts?

Bryan_K

Exactly what we are looking to do. I am glad you were able to explain it better. Our thought was that the super workflow would route other workflows based on the information from the database (or questionnaire).

We also thought about dynamically creating the workflow each time, and then were trying to decide if we would create it EVERY time or if we would just create the workflow but then have a check once a night that would see if the DB info had changed at all, which would then re-create the workflow. This would maybe cut down on time when hundreds of workflows are being run at the same time.

I was just looking at the workflows (work_order and dual_work_order) and they look really close to what we are shooting for. I agree with you that we may be able to create the job specification file dynamically, however for our purposes we may still populate the variables from a database. I believe a work_order.wft on steroids may be the ticket.

Migrateduser

This is basically the same as what I originally suggested. work_order.wft and dual_work_order.wft were the first attempt by Interwoven to provide a nested workflow solution to customers. These workflows were created back in version 4.2.1 and to my knowledge have not been updated at all since then. In 5.x (I'm not sure which was the first version to contain better nesting) there is a much easier way to nest workflows using the <wftask> task. It all boils down to what Adam said about dynamically modifying the name of your subsequent wft file you need to execute. If you can somehow solve that problem, this could work well for you.

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

Migrateduser

After thinking about this a little more, it could work to use the functionality in dual_work_order.wft/work_order.wft as long as you can do your database query inside the initial wft file. If all the information you need to query the database is what you get when you start the wft - basically the user, the area, etc. then you could probably pull it off using these templates as your base. The actual nesting part is rather complex if you choose to use these templates - if you need any help understanding them, let me know - I wrote them.

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

Bryan_K

That never hurts.

Adam Stoller

Actually, thinking about it some more - if you are willing to generate a [sub] workflow on the fly (perhaps from a template) - you could have your "super" workflow generate a name for the sub-workflow and then pass that information along to the externaltask that would do your lookups and generate the actual sub-workflow - and then the next task would be the wftask that calls the newly generated wftfile or jobfile (depending on what you decided to generate.

So - I think this gets around having to alter the parameter to the wftask on the fly - you just create workflows on the fly with dynamic names. Actually, if you have existing wfts that you want to use - all the script would need to do is know which of your existing wfts to copy into the dynamically generated named wftfile and take it from there.

I have a feeling the above may not be expressed as clearly as I (or you) would like - but I'm a tad bit short on sleep right now - so if there's something you don't understand - ask - and I'll try to clarify it when I get time.

--fish
(Interwoven Senior Technical Consultant)

AmyRush

This is so great!!! Thanks to all for the input... and keep it coming!

dennispluken

I have done a great deal of work building workflows from scratch dynamically, instantiating them and invoking them -- avoiding using wft's entirely. It is fairly straight forward, thought tedious. A solid OO approach makes it much more doable and leads to VERY reusable code.

One real benefit to this is that you can create custom cgi interfaces for workflows and you can build very complex process models which are fluid and not set in stone at the beginning of the job.

Ottawa_IWOV

How can I pass the name of a DCR that is attached to the workflow to a .ipl script that will the generate SHTML pages. I thought you could pass the value of iw_file but that does not seems to work...

Any ideas?

Lucas Cochrane
lcochrane@dc.com

dennispluken

You should be able to use the GetFiles method in the WFtask package to make the list of attached files availble with the ipl.

Ottawa_IWOV

Might you be able to elaborate a little more...How exactly would I call it in an .ipl scipt???

my $dcr_name = $wf->GetVariable(something);

Lucas Cochrane
lcochrane@dc.com

dennispluken

the job number and task number are passed to .ipl scripts as arguments...

my ($job_id,$task_id) = @_;

my $task_obj = new WFtask($task_id);
my @files = $task_obj->GetFiles();

# @files will contain a list of the files attached to the job at that point. I believe that the list elements are paths to the files relative to the workarea.