auto-updating author's workareas

We have some workareas in which only authors work. But of course, there are shared files that get updated and need to land in author's workareas.

Since they can't get latest, we'd like to automate this process. I can think of handling this via workflows or an atsub trigger.

I'm leaning towards the trigger, but I just want to know how others are handling this type of scenario... any thoughts/caveats on either approach?

TS 5.5.2, Solaris

Thanks,
maureen

Find more posts tagged with

Comments

Migrateduser

Personally I prefer to have an explicit externaltask at the end of the workflows to update all workareas on the branch from staging - that makes it clear what is doing what, when, and you can build in error control. Triggers are associated with a minor performance impact and you might not know it if for some reason the trigger stops kicking off the command.

Migrateduser

In case of workflows, isn't there any performance impact if the a workflow is started for each file submit?
If users submit 100 files in a day, the update WA task will be called 100 times. Is that ok?

Migrateduser

If they submit them as a batch there would be only one workflow. In either case iwupdate is going to be called 100 times (multiplied by the number of workareas minus one). Generally you want a workflow around the submit operation, right? This approach does not handle submit direct - that could be an advantage or a disadvantage - you might want exceptions to the rule that all other workareas would be updated - you could use submit direct for this exception (using a trigger would require that you put logic in the trigger to detect submit direct or disable the trigger if you don't want the other workareas updated).

I am curios why you would have multiple workareas if they are always kept in sync. I think many times this is implemented for the wrong reasons (political motiviations, misunderstandings of what workareas are for, misunderstandings about how permissions are implemented, etc.) when a single workarea would suffice with much less complication, conflict, customization, application server/proxy configuration, etc. I would never use the suggested/standard/default logic that the workarea owner must approve content from that workarea - approval should always be done by a group (in case someone is out of the office or leaves the company) so that is really not a limitation I would choose. I realize that multiple workareas must be considered for the overall architecture but they don't always have to be implemented right away.

rwinterpacht

Our organization handles this kind of in the middle. We have a cron job that loops through each workarea daily in the middle of the night and executes a Get Latest. This works very well for folks who go into TeamSite once in a while. Those who work in it everyday have to manually run a Get Latest, and with enough people in the branch, often come across conflicts. Because an author can't do a Get Latest, we really don't use any...we have mostly editors and admins. Not like we have a lot of money to throw around for TeamSite licences, but that was our need, as the author (license) was useless to us.

Thanks,
Raf Winterpacht

Adam Stoller

If they submit them as a batch there would be only one workflow. In either case iwupdate is going to be called 100 times (multiplied by the number of workareas minus one).
Not necessarily.

if you use an updatetask, you avoid the overhead of running the iwupdate CLT and it only gets called once per workarea - but you'd have to code N-updatetask's, one for each workarea.
If you use an externaltask and programmatically determine the list of workareas to update, you can still avoid calling the CLT 100 times per workarea by creating a filelist and doing iwupdate -f filelist target-workarea
As a variant of the previous option, you could run iwupdate -f - target-workarea within a pipe and print the list of source vpaths through the pipe:
```
if (open(PIPE, "|$iwhome/bin/iwupdate -f - $targetArea")){
    print PIPE $_ foreach(@sourceVpaths);
    close(PIPE);
}
```

--fish
(Interwoven Senior Technical Consultant)

Migrateduser

I think N update tasks is not an option - what if a workarea is created after the job has started.

You are right about reducing the calls to iwupdate though - but I don't think that can be applied for the trigger method (unless the trigger appends to a file list and some scheduled co-process handles the file list or something, but I think I would avoid that).

I am curious with this way of invoking a command - how would you get STDERR, STDOUT and OS return code?

Thanks,

-John

Adam Stoller

I agree - I don't think N-update tasks is a very viable option, but an option none-the-less.

I also don't think a trigger is a very good idea for the reasons mentioned (though I did once work on an implemention of such, it involved a portal widget and what they did is shipped a specifically named file that contained the list of other files, at the very end of the transaction, and the trigger script ignored everything except that specially named file)

Which way of invoking the command were you curious about? I presume the last, using the pipe. You can check the $? variable for the status after the close pipe to get the CLT status return - if you want to get STDERR / STDOUT output its a bit trickier (you have to set up a 3-way pipe I believe, I haven't much experience with doing this)

--fish
(Interwoven Senior Technical Consultant)

Migrateduser

I think using the pipe would be convenient but I always need to trap STDERR/STDOUT - knowing that an error occurred is one thing, putting a semi-useful error message in an email is better.

james1

Just a word of caution here: In my experience, 3-way pipes in Perl are broken on Windows and tricky in Solaris (easy to get into a race condition). An alternative might be to redirect stdout and stderr to files and then to read the contents of those files.

-- James

--
James H Koh
Interwoven Engineering

mogoo

Thank you everybody for the great input. Looks like workflow would be a more flexible solution.

The workareas are not kept TOTALLY in sync. What I was originally talking about was global items, like images or include files. So there are predictible dirs I would want to attach the update all workareas workflow to. HOWEVER, I've noticed that sometimes when you submit via the "List Modified" screen, a wf that is supposed to be an option for the file in "/global/images/" dir doesn't show up, even though the file you're submitting lives in /global/images/. Is this just a bug (ts 5.5 SP2, Solaris)? Has it been fixed?

... and one more thought -- it wasn't clear to me in the documentation -- can you set up an iwatsub trigger for the /global/images/ directory at the command line, when you invoke iwatsub? Or does an iwatsub run on every submit, the path needing to be checked in the ensuing script?

maureen

james1

> HOWEVER, I've noticed that sometimes when you submit via
> the "List Modified" screen, a wf that is supposed to be an
> option for the file in "/global/images/" dir doesn't show up,
> even though the file you're submitting lives in /global/images/.
> Is this just a bug (ts 5.5 SP2, Solaris)? Has it been fixed?

Um, I believe that available_templates.cfg only allows you to configure workflows per branch, not per directories within branches.

> ... and one more thought -- it wasn't clear to me in
> the documentation -- can you set up an iwatsub trigger for
> the /global/images/ directory at the command line, when
> you invoke iwatsub? Or does an iwatsub run on every
> submit, the path needing to be checked in the ensuing
> script?

Your iwatsub script will trigger for every single submit.

-- James

--
James H Koh
Interwoven Engineering

mogoo

Thanks for the answers James... and actually, I've found that this entry in available_templates.cfg works...
<branch value ='branchname/WORKAREA/.+/templatedata/global/nav' include='yes' />

...except from the List Modified screen, SOMEtimes the workflow doesn't show up as an option. (haven't troublehot it enough to recognize a pattern)
maureen

Adam Stoller

Templating workflows (tt_data) only process the branch - not the workarea nor the directrories within.
Basic workflows (new_job, submit) will process the branch, workarea, and directories within - however when you do a List Modified - you are no longer in the context of the directory where the files was found - and therefore a restrictive branch regex will not work.
I.e. - if list modified shows a file [area]/foo/bar/baz/mumble.html - the branch-path for that file is probably (haven't verified) just "[area]" and nothing beyond that.

--fish
(Interwoven Certified, Senior Technical Consultant)