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

Tagging event

g_sal

Hi peeps,

I was wondering if there was a TeamSite event for when a resource is tagged with new metadata? This resource would reside in a workarea, and would not necessarily be in Staging.

Looking at the iwevents.log, I don't see any events being declared.

Does anyone have any input? Ultimately I would like to catch the event and force the TSSearch to do an incremental index on that resource.

TS 6.7 - Windows 2003

Find more posts tagged with

Comments

dkuntze

Hi peeps,

I was wondering if there was a TeamSite event for when a resource is tagged with new metadata? This resource would reside in a workarea, and would not necessarily be in Staging.

Looking at the iwevents.log, I don't see any events being declared.

Does anyone have any input? Ultimately I would like to catch the event and force the TSSearch to do an incremental index on that resource.

TS 6.7 - Windows 2003

Make sure you have the event subsystem running and check the database that chose to run it under for the event. If you have the event subsystem running and search properly config'ed to listen to it, it should incrementally index your content.

g_sal

Thanks for you reply dkuntze,

I believe that workarea modifications are not incrementally indexed on modification events. It's reindexed every two minutes based on the iw.index.wamodifications.frequency property in the search.properties file. I set that value to 0 but it didn't guarantee me that the resources were indexed immediately and it was processor intensive.

If I understood you correctly I can monitor the event subsystem? What's the name of the event I'm looking for? SetEA? Or are you saying that I can configure the search engine to listen to particular events?

Thanks

Migrateduser

Hi ,

Following are the answers to your queries

>>If there was a TeamSite event for when a resource is tagged with new metadata?
Yes, Only if the content is submitted to STAGING. The search server listens to the submit event.

>>His resource would reside in a workarea, and would not necessarily be in Staging.
True, This is the case when there is the tag modification is in the workArea. No event is generated for this.

>>I can monitor the event subsystem? What's the name of the event I'm looking for? SetEA? Or are you saying that I can configure the search engine to listen to particular events?
You need not monitor the events and also cannot configure the search engine to listen to the particular event. All desired functionality can be acheived using the search config file.

>>Ultimately I would like to catch the event and force the TSSearch to do an incremental index on that resource.

1.) If you have enabled the event based updates in your system your search server automatically will be informed about the submit events to the STAGING (including the tagging events)
The relevent config peoperties are
# Event-based updates are enabled
iw.index.events.enable=true
# Optimal wait time before received events are processed (in minutes)
iw.index.optimalWaitMins=1
The indexserver will update the indexes and hence the new files will be searchable but there might be some delay (time lag) which primarily depends upon
a.) iw.index.optimalWaitMins value
b.) CPU availabilty (as other bulk indexing threads may cuncurrently be running)

2.) WorkArea indexing: This functionality can be enabled and derived by the the following config params
# Indexing workarea modifications
# Control whether indexing of and searching across modifications in workareas
# of indexed branches is turned on or not.
iw.index.wamodifications.enable=true
# Control whether indexing the modifications of ALL the workareas of a branch
# at the time the branch is first indexed should be turned on or off (permissible
# values are none and all).
iw.index.wamodifications.branchcreation.default=all
# Control how often (in minutes) an attempt is made to index the modified files in the
# relevant workareas of all the relevant indexed branches.
iw.index.wamodifications.frequency=1
# Control after how much time (in hours) the collections of workarea modifications for a
# branch are considered too old and hence deleted and then re-indexed. Checked during
# index server startup only.
iw.index.wamodifications.deleteindexes=1

WorkArea searcing essentially means looking for the modified files in the workArea (not submitted) in addition to the files which are in sync with the STAGING. This process does not listen to the events and only keeps monitoring the changed files. Your judgement is correct "that workarea modifications are not incrementally indexed on modification events." If the file is modified in the workarea (whether for the content or the Tag) the modified file is picked by the indexserver and WORKAREA indexes are accordingly modified. As in 1 the timelag here also depends on the iw.index.wamodifications.frequency and the current state of CPU.

Thanks,
Hemant

g_sal

Thanks Hemant,

Therefore it appears I can't index a file in a workarea immediately after a an EA is changed. That's pretty disappointing.

Ah well, back to the drawing board. Thanks everyone for your help!

g_sal

Well, back to the idea of capturing SetEA events. I've done a command to register a SetEA event but I don't see any events fired. I read in the documentation that for some events you need to enable their logging in iw.cfg, but they only have one example and it's not intuitive. What do I need to enable in order to capture the SetEA event?

What I've tried so far:
iwat SetEA setea-handler.ipl

I also added the following line to the iw.cfg file under the iwserver section:
log_setea=yes

No success. Can anyone provide suggestions or help please?

TS 6.7 - Windows 2003

Adam Stoller

Well, back to the idea of capturing SetEA events. I've done a command to register a SetEA event but I don't see any events fired. I read in the documentation that for some events you need to enable their logging in iw.cfg, but they only have one example and it's not intuitive. What do I need to enable in order to capture the SetEA event?

What I've tried so far:
iwat SetEA setea-handler.ipl

I also added the following line to the iw.cfg file under the iwserver section:
log_setea=yes

No success. Can anyone provide suggestions or help please?

TS 6.7 - Windows 2003

I don't believe any such event exists (feel free to check with support and correct me, or file a FR for it) - I believe the only way to do what you want is to put a wrapper around the tagger GUI and have the wrapper invoke the indexer for you after the tagger GUI exits.

In 6.7.1SP1 it should be a bit easier - because we should hopefully, finally, have formapi available for MDC - and then you'll be able put an event handler inside the DCT for when the save/close is done and do a callserver script to run your indexer - but until then ....

Migrateduser

Hi Sal,

one thing I notice in u r config is

>>It's reindexed every two minutes based on the iw.index.wamodifications.frequency property in the search.properties file. I set that value to 0 but it didn't guarantee me that the resources were indexed immediately and it was processor intensive.

This might be the reason for your longer time to see the new indexes. The value 0 for the iw.index.wamodifications.frequency is not permitted and if you analyze your log file u'll see that the indexer has put the warning and defaulted to 2 min.

WARN com.interwoven.hunter.index.WorkareaIndexer (WrapperSimpleAppMain) - iw.index.wamodifications.frequency=0 is invalid, returning default (2)

The minimum value permittable here is one (1) min (only +ve integers permitted). I guess that will certainly reduce u r workarea index updation time to half. Smiley Happy

Cheers,
Hemant

g_sal

I don't believe any such event exists (feel free to check with support and correct me, or file a FR for it) - I believe the only way to do what you want is to put a wrapper around the tagger GUI and have the wrapper invoke the indexer for you after the tagger GUI exits.

In the CLT manual for 6.7, page 210, there is an event SetEA which states "An EA has been added to/modified on a file." Since the manual tells me so, it must be true, right? A KB article (49618) also lists the event. Surely they can't both be wrong?

As for the wrapper suggestion, it's a good idea, I'll look into it.

I also noticed that as the setting in the iw.cfg file was incorrect. The Admin guide uses the example "log_modifyfse=yes", but I've also seen it as "log_modifyfse=on" in two other locations. Eitherway I think your right, the SetEA event only exists in the minds of Interwoven. Pretty darn sad.

g_sal

This might be the reason for your longer time to see the new indexes. The value 0 for the iw.index.wamodifications.frequency is not permitted and if you analyze your log file u'll see that the indexer has put the warning and defaulted to 2 min.

This is useful to know, thank you. Unfortunately, I realy would have liked a modified file to be indexed immediately, since a delay of 1 minute is still problematic for me.

I noticed that I can't make the indexer reindex just a single file either way. Soooo... no dice for me.

Adam Stoller

In the CLT manual for 6.7, page 210, there is an event SetEA which states "An EA has been added to/modified on a file." Since the manual tells me so, it must be true, right? A KB article (49618) also lists the event. Surely they can't both be wrong?

As for the wrapper suggestion, it's a good idea, I'll look into it.

I also noticed that as the setting in the iw.cfg file was incorrect. The Admin guide uses the example "log_modifyfse=yes", but I've also seen it as "log_modifyfse=on" in two other locations. Eitherway I think your right, the SetEA event only exists in the minds of Interwoven. Pretty darn sad.

Hmm - my bad - I just searched and the setEA event was documented as far back as 4.5 - according to that you should be able to monitor the event with something like:

iwat setEA "c:/iw-home/iw-perl/bin/iwperl c:/iw-home/local/bin/setea_trigger.ipl"

(paths and name of script are just an example, on Unix you would not need to preface the script with the perl engine).

I don't believe I've ever tried to set such an event trigger (for setEA) - but it might be interesting to find out if it works and what information is passed to the script when it's triggered...

I also don't know what you could use to ensure that such events were logged, as the only settings I've ever seen documented (in the 4.2.1 release notes - although documented in Support KB 1458 as being added in 3.0) were:

As for being able to get the indexer to do what you want - sorry, can't help you there at all.Both of these issues are probably worth of (separate) feature request filings...

sample_report.rptdesign

ISCBorisB

I don't believe I've ever tried to set such an event trigger (for setEA) - but it might be interesting to find out if it works and what information is passed to the script when it's triggered...

Just tried it on my Dev 6.5. Event subsystem is running, log_setea is NOT set. Nothing has been triggered on extended attribute changes, either from GUI or CLT.
I then set iwat ".*" and made Submit - EA Change - Submit. Got my submits all right(actually, dozens of various WF - related hits each) and nothing in between.

As indicated before:

What I've tried so far: iwat SetEA setea-handler.ipl
I also added the following line to the iw.cfg file under the iwserver section:
log_setea=yes
No success...

g_sal

I've opened a case with Interwoven. I'll share once I get a response.

Thanks,
g_sal

g_sal

Apparently it was working.

In iw.cfg under [iwserver]:
log_setea=on

Command:
iwreset -a

Not sure how I missed it, but this does work. Either something on the box changed or I was staring at my screen far too long!

This fires off many setea events. Especially when you use the Tagging UI, since all the EAs will be rewritten. Even by saving a DCR, some EAs are reset.

Adam Stoller

Apparently it was working.

In iw.cfg under [iwserver]:
log_setea=on

Command:
iwreset -a

Not sure how I missed it, but this does work. Either something on the box changed or I was staring at my screen far too long!

This fires off many setea events. Especially when you use the Tagging UI, since all the EAs will be rewritten. Even by saving a DCR, some EAs are reset.

Did you ask Support to file a bug on the documentation (which apparently doesn't list this anywhere)?

g_sal

Yes, there's a doc fix request, but I don't have the number.

Hyde

This could come in handy. Thanks for doing the legwork G-sal!

cliff1

At the risk of being flamed, I'm pretty sure there is a SetEA event that can be enabled. This event is picked up by DataDeploy when it is configured in the "DAS" (database auto synchronization) mode. I don't have the time to look right now, but I suspect the OpenDeploy/DataDeploy docs that talk about DAS will give you the correct incantation to enable this event. I beleive the event is posted the event subystem where DAS (and other subscribers) can process the event.

Sorry for the vaque answer -- it's been a while since I've worked with this part of the system.

-Cliff

Migrateduser

I'm not convinced that SetEA is picked up by DAS. We've discussed this before, and I currently have a case open with support to verify the behaviour I am seeing. I have it logging, so I see the event being fired, but DAS only appears to pick up on it when the EA was changed via tagging. I the EA is changed via an eastartop in workflow or by the iwextattr CLT, the event appears in the log, but DAS doesn't do anything with it.

actuateNestedTables.rptdesign

cliff1

Your reply jogged my memory a bit and I agree that DAS only cares about EAs that are set via the tagging UI. In retrospect, I do recall that the UI posts a message when it updates metadata so that DAS can be triggered immediately. This is not a general solution that will solve your indexing issue -- sorry for the red-herring.

-Cliff