search CLT to index a file.

Is there an equivalent CLT to index a file in the same manner that a file is indexed once it has been submitted?

Would it be recommended to use iwndxrefreshbr -i, I would assume this would need to run off peak.

I'm looking for an adhoc file approach.

John Cuiuli

Find more posts tagged with

Comments

Migrateduser

Just wondering if you checked here:
http://devnet.interwoven.com/site.fcgi/webcasts/data/005/15-TeamSite65-Search/TS-SearchDevNetWebcast040605.pdf

regards,

lissa

Johnny

Yep already did - seems like indexing is at the branch level for CLT.
Unless I've missed something.
Thanks

John Cuiuli

Johnny

Does anyone have an answer?

We cannot use the eventsubsystem to index on submitting as we cannot secure a database for our environment. The default file database is not fit for production use, so we're left in the dark.

We currently run a nightly job to index the branch.

How can I index a file on submitting in this situation?.. Will running the branch index CLT after a submit have minimal impact?.. Roughly how long before indexing will that file become available for search?

I think a good use for search is not just for the end user, but with in content apps themselves.
I would like to use search to retrieve content based off metadata, rather than walking the filesystem.

Would my assumptions in efficiency be correct?

1st Search
2nd Content Services recursive vpath walking
3rd Recursive file system walking

Of course Search is currently not available in workareas - which will limit certain use cases.

John Cuiuli

Migrateduser

If for whatever reason you do not have the event subsystem configured so as to automatically index submitted files, you can get by, by issuing the iwndxrefreshbr CLT periodically. The iwndxrefreshbr CLT essentially tells the index manager to get the indexes for the specified branch up-to-date. The index server on getting this request checks to see how far along has the specified branch been indexed till and then goes on to index any subsequent files that have been submitted since that time - essentially bring the indexes for the branch up-to-date.

Note that if the event subsystem is configured appropriately, then the branch indexes will be brought up-to-date automatically on (almost) every submit as the index server listens to these events. Hence, in the absence of the the event subsystem being configured, the iwndxrefreshbr CLT needs to be run at a PROPER frequency to make sure that the branch indexes are up-to-date.

As far as the other question goes, we have "Content Services API" that enable one to obtain files ranked based on relevancy for queries that satisfy searches across metadata.

Regards
--Anirudha

Johnny

While I appreciate the fact that you took the time to provide an answer, we still haven't addressed any of the questions put forward in my post.

Thanks

John Cuiuli

Migrateduser

I am sorry if I was not clear. Here goes:

Q: How can I index a file on submitting in this situation?
A: By using the iwndxrefreshbr CLT, one could achieve the same effect as would have happened if the index server was configured to properly get submit events from the event subsystem.

Q: Will running the branch index CLT after a submit have minimal impact?
A: The iwndxrefreshbr CLT is smart to only do the indexing of files that have been submitted to the branch since the last edition that the branch has been indexed till. Stated another way, the impact would be similar to the case where the index server was configured to properly get submit events from the event subsystem.

Q: Roughly how long before indexing will that file become available for search?
A: Again, if the iwndxrefreshbr CLT is issued immediately after a submit of a set of files for a branch, then the time it takes to index these submitted files in either case would be similar. As far as how long it may take in either case, that depends on the size of the submitted files and whether or not the index server is busy indexing files from other branches in addition to the CPU/memory of the machine where the index server is running.

Q: I think a good use for search is not just for the end user, but with in content apps themselves.
I would like to use search to retrieve content based off metadata, rather than walking the filesystem.
Would my assumptions in efficiency be correct?
1st Search
2nd Content Services recursive vpath walking
3rd Recursive file system walking
A: I am not sure I understand this question. There are Content Services APIs whereby you can issue queries that search across metadata and these result in a set of files based on the relevance rank of the search. This API is applicable for a specified branch and it applies the search query across all files in that branch. We currently do not support searches across multiple branches but expect to do so in a subsequent release.

Q: Of course Search is currently not available in workareas - which will limit certain use cases.
A: Correct. We expect to support this in a subsequent release.

Please let me know if I missed answering any specific question.

Regards
--Anirudha

Johnny

Anirudha - thanks for the detailed post - I really appreciate it!

In reply to:

Q: I think a good use for search is not just for the end user, but with in content apps themselves.
I would like to use search to retrieve content based off metadata, rather than walking the filesystem.
Would my assumptions in efficiency be correct?
1st Search
2nd Content Services recursive vpath walking
3rd Recursive file system walking
A: I am not sure I understand this question. There are Content Services APIs whereby you can issue queries that search across metadata and these result in a set of files based on the relevance rank of the search. This API is applicable for a specified branch and it applies the search query across all files in that branch. We currently do not support searches across multiple branches but expect to do so in a subsequent release.

Here's an example, say I had to build an index file based off a number of DCR's. There would be an index file per some kind of category field in the DCR.

EG
CatA -> Aindex
CatB -> Bindex

Traditionally in TeamSite, you would have to walk the data directory tree (EG in PERL File::Find, TeamSite: Smiley Very Happy

irwalk) and parse each DCR and group by category. This can be quite time consuming as the number of files grow.

The thought I have is to query the search service as I would a database to retrieve this information much faster.

EG
Query for CatA="SomeCategory"

I'm assuming that a result set with 100% relevance are exact matches.

I expect performance would be much better, though it would currently only be available to content in the STAGING area.

Thanks again
John

John Cuiuli