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

POLL: "iwat trigger" versus "file watcher daemon"

LeggMan

Requirement: Kick off a workflow whenever a file is created/replaced in a specific workarea. This workarea will be updated once or twice a day.

Correct me if I'm wrong regarding use of the iwat trigger: Every file system event in every branch/workarea will have to be evaluated to determine if it pertains a file in the workarea of interest. This would result in potentially thousands of events/calls per day. There is no way to "localize events" to a particular workarea to limit firing of the trigger only when there is an FSE in that workarea.

Contrasted to use of a file watcher that checks for new/changed files in the specified workarea every 10-15 minutes: A script would get exec'd 96 to 120 times per day... even less if restricted to polling only during normal working hours.

What method would you opt for?

Thanks in advance for your input.

Find more posts tagged with

Comments

Sbardeo

Advantages of IWAT trigger:
1. WF will get executed only when new file is created.
2. IWAT trigger script can be configured only to respond to new file creation event.

Disadvantages:
1. No WA specific triggering.
2. iwevent log size issue as it will have new entry for newly created files which is disabled by default.
3. In triggering script you will have to read iwevent log using iwevents CLT which seems somewhat complex to get exact path of newly created file with WA location as you will have to deal with OBJ ids for WA and branch.

ISCBorisB

Requirement: Kick off a workflow whenever a file is created/replaced in a specific workarea

>>Every file system event [...] will have to be evaluated...
Wrong. Catch CreateFSE Event, it fires when an FSE (file/directory/symlink) has been created. You may have to check
created asset type, that's it.

>>Every [...] branch/workarea will have to be evaluated...
Wrong. createfse_filter=regex entry in the [iwserver] Section allows you to control event logging per Branch
(or may be even WA, I never tried). Please note that AFAIK this feature has not been documented!

Oh, by the way... Your Event handler does not have to read/parse Event Log to obtain any Event information.
Upon invocation iwat (use it!) will call your Event handler with timestamp, user, role, area, path Parameters.
iwatcreate (do not use it) will set corresponding Env Variables, etc...

How to generate events on file create/rename/modify

nipper

Advantages of IWAT trigger:
1. WF will get executed only when new file is created.
2. IWAT trigger script can be configured only to respond to new file creation event.

You can create a trigger to fire off of a ModifyFSE event. So that when an element is modified (for the 1st time after a submit) it will fire. If you modify an object 5 times before submit, it will however only fire off of the 1st one.

ISCBorisB

This post has been removed

LeggMan

>>Every file system event [...] will have to be evaluated...
Wrong. Catch CreateFSE Event, it fires when an FSE (file/directory/symlink) has been created. You may have to check
created asset type, that's it.

>>Every [...] branch/workarea will have to be evaluated...
Wrong. createfse_filter=regex entry in the [iwserver] Section allows you to control event logging per Branch
(or may be even WA, I never tried). Please note that AFAIK this feature has not been documented!

Oh, by the way... Your Event handler does not have to read/parse Event Log to obtain any Event information.
Upon invocation iwat (use it!) will call your Event handler with timestamp, user, role, area, path Parameters.
iwatcreate (do not use it) will set corresponding Env Variables, etc...

How to generate events on file create/rename/modify

I had a feeling you'd chime in about where I was wrong... ;->

I've shaken the trees at Interwoven Tech Support to see if I can get more docs regarding the technique you say would allow me to control event logging per branch. Parsing the event log is not a big deal for me. Responding to thousands of create/modify FSEs when I only care about 25 a month is how I would like to optimze the process.

nipper

. Responding to thousands of create/modify FSEs when I only care about 25 a month is how I would like to optimze the process.

I still think this is a good way to do it. You may be looking at this script running 100 times a day. It may regex the path (depending on what the requirements are) and stop without doing anything, that will take almost no resources.

ISCBorisB

Sorry Man, could not resist. Please note the excerpt from your original post

...Correct me if I'm wrong regarding use of the iwat trigger: Every file system event...

My apologies

Btw, correct (read "unambiguous") parsing of the event log is not as easy as you may think

LeggMan

Sorry Man, could not resist. Please note the excerpt from your original post My apologies

Btw, correct (read "unambiguous") parsing of the event log is not as easy as you may think

I put that phrase ("correct me if I'm wrong") in there just for you, ghoti, and other well-versed developers precisely because I haven't used or explored iwat triggers since '01 and wasn't at all confident in my grasp of techniques required to exploit it.

Parsing can indeed be an adventure sometimes but, given a set of log entries that represent the "problem domain" it's just a matter of time to come up with the regex(es) to do the parsing job (as opposed to poking around in the dark to ferret out under- or un-documented functionality).

Thanks!

LeggMan

I still think this is a good way to do it. You may be looking at this script running 100 times a day. It may regex the path (depending on what the requirements are) and stop without doing anything, that will take almost no resources.

"100 times a day" ... During the course of a day I can get many more create & modify events than a hundred. Sometimes I can get five create events occurring within a second when multiple files are generated from a single DCR. This would probably result in five different FSEs, none of which would be germane trigger-wise. After a series of these I'd be over a hundred by mid-morning.

Since I (and Donald Knuth) believe that "premature optimization is the root of all evil" you can be sure that I'm not worried so much about "wasting" processor cycles and disk reads as I am about the impact on the system if/when it has to contend with bursts of create/modify FSEs and responding correctly if/when such activity occurs in a target workarea and must be processed. As it stands now, periods of only moderately intense activity on my TeamSite server result in noticeable slowdowns so overall server performance level is a consideration.