Indexing Super type(dm_document) but filtering its sub types(dmc_jar etc) from Fast indexing

Hi All,

We have a requirement that we need index documents in our system.

Many of these documents are of dm_document types and some are of our custom type documents.

The requirement is to index all these documents excluding the other sub types of dm_docuemnt like dm_xfm_instance, dm_xfm_resource, dm_xfm_schema, dm_xml_config, dmc_jar etc.

Is there any way to include dm_document for indexing and unregister some of its sub types that we dont want?

It will be of great help if you reply as soon as possible.

Thanks!

Regards,

Jitender

Find more posts tagged with

Comments

dnvhariprasad

You can do it from DA and uncheck register for indexing

bacham2

You can do that with the new xPlore filters. Register dm_document and then exclude the subtypes that you don't want (dm_ftfilter_config.types_to_exclude).

XdctmX

Go through the support note - (I dont have link to the below support note)

Symptoms

By default, all dm_sysobject types and its subtypes generate fulltext events in a repository.
This would make all dm_sysobject types and their subtypes eligible for fulltext index processing. Henceforth there would be demand for more work on Index Agent and Index Server components resulting in a bigger index repository. Searching bigger index repositories would also require more resources and time.

Sometimes your business may require searching only the custom object types which are specific to your application. In that case you can programmatically queue fulltext events or register only the specific object types your application will search by. For example, you could decide to only register your custom dm_document subtype.

Registering specific object types would result in better utilization of available resources which will result in optimized performance of Index Agent and Index Server components.

Cause

By default, all dm_sysobject types and their subtypes generate fulltext events in a repository. This would make all dm_sysobject types and their subtypes eligible for fulltext index processing.

Resolution

Registering specific object types would result in better utilization of available resources which will result in optimized performance of Index Agent and Index Server components. The following are the steps to un-register all dm_sysobject type and its subtypes, and to re-register custom dm_sysobject subtype for fulltext events.

unregister,c,<r_object_id_of_dm_sysobject_type>,dm_save,dm_fulltext_index_user unregister,c,<r_object_id_of_dm_sysobject_type>,dm_destroy,dm_fulltext_index_user unregister,c,<r_object_id_of_dm_sysobject_type>,dm_checkin,dm_fulltext_index_user unregister,c,<r_object_id_of_dm_sysobject_type>,dm_readnlysave,dm_fulltext_index_user unregister,c,<r_object_id_of_dm_sysobject_type>,dm_move_content,dm_fulltext_index_user

To re-register a dm_sysobject subtype you must modify install script create_fulltext_objects.ebs in $DM_HOME/install/admin directory. Copy this over to create_fulltext_objects2.ebs, and modify the line (buff = "retrieve," & SessionID & ",dm_type where name = 'dm_sysobject'") to replace this occurrence of dm_sysobject with your custom object type (buff = "retrieve," & SessionID & ",dm_type where name = '<custom_type>'" ).

Caution: Do not change any other occurrences of the string dm_sysobject.

Run create_fulltext_objects2.ebs script as the installation owner by executing following command.

Syntax:

$DM_HOME/bin/dmbasic -f$DM_HOME/install/admin/create_fulltext_objects2.ebs -einstall -- <Docbase Name> <installowner> <password>

Example: Docbase - testdoc, install owner- dmadmin, password abcd1234

$DM_HOME/bin/dmbasic -f$DM_HOME/install/admin/create_fulltext_objects2.ebs -einstall -- testdoc dmadmin abcd1234

Note: Index agent run in migration mode will still index all object types.

If you intend to index ONLY those objects that you choose to index then you must resubmit these objects for indexing based on a custom object type (s).

Objects may be resubmitted when the index agent is running in either migration mode or normal mode. The file of object IDs is designated in the file_name parameter of the indexagent.xml configuration file for a particular index agent. By default, the file_name parameter is set to the file name ids.txt.

The indexagent.xml file is in

X:\Program

Files\Documentum\IndexAgents\IndexAgentN\webapps\IndexAgentN\WEBINF\

classes (Windows)

or

indexagentinstalldirectory/IndexAgents/IndexAgentN/webapps/IndexAgentN/WEB-INF/

classes (UNIX)

where N is the number of the particular index agent.

The index agent periodically checks for the existence of ids.txt. If the file is found, the

objects are resubmitted for indexing.

To index your custom object types, you would run a SELECT query (refer to esg92725) and return a list of only your custom objects. These object ID's can then be placed into the ids.txt file (as above) - and they will be indexed accordingly.