searchindex Command

[start|update|status|modify|clear|validate|print] searchindex {CLAUSE};

• CLAUSEs provide additional information about the search index.

start searchindex mode FULL|PARTIAL [vault PATTERN] [limit N];

• mode specifies whether a baseline (FULL) or incremental (PARTIAL) indexing process is to be performed. This clause is mandatory.
• vault specifies the vaults to be indexed. The PATTERN argument allows you to specify a pattern of vault names, including a wildcard '*' character. For example, if there were two vaults named v1 and v2, instead of issuing the command twice, once for each vault, you could simply issue it once using vault v*. This clause is optional. For more information, see Status Searchindex.
• limit specifies the maximum number (N) of objects to be indexed. This clause is optional.

update searchindex [vault PATTERN] type TYPE{,TYPE}[ type TYPE{,TYPE}] [!|not][file];

• vault specifies the vault(s) to be indexed. The PATTERN argument allows you to specify a pattern of vault names, including a wildcard '*' character. For example, if there were two vaults named v1 and v2, instead of issuing the command twice, once for each vault, you could simply issue it once using vault v*. This clause is optional. For more information, see Status Searchindex.
• type specifies the object type to be updated.
• For3DSpace Index, the command update searchindex type Part, for example, is the only option to update the index with that new field.

The status for the Searchindex commands had previously been stored in the vault property SearchIndexStats. It is stored in the index as a checkpoint. A checkpoint is much like a property in that it can store an arbitrary string, but it is also associated with the data that has been committed in the index, so it ties the vault status to what has been processed in the index.

status searchindex [vault PATTERN];

• vault specifies the vault(s) to be indexed. The PATTERN argument allows you to specify a pattern of vault names, including a wildcard '*' character. For example, if there were two vaults named v1 and v2, instead of issuing the command twice, once for each vault, you could simply issue it once using vault v*. This clause is optional.

The output of this command includes the start time and duration of the indexing process, for example:

            MQL<4>status searchindex; 
test: Complete  last indexed: 08/23/2011 20:48:06
number of objects: 1    start: 9/9/2011 5:33:10 PM
duration: 7 seconds

modify searchindex modified DATE [vault VAULT];

• DATE specifies the last_modified timestamp of an incremental indexing operation. This clause is required. The format is MM/dd/yyyy HH:mm:ss. You will be informed with an error message if the format of the entered data is incorrect.
• vault specifies the vaults)to be indexed. This clause is optional.

clear searchindex;

The following command clears only the status of the indexing process.

clear searchindex statsonly [vault PATTERN];

• vault specifies the vault(s) to be indexed. The PATTERN argument allows you to specify a pattern of vault names, including a wildcard '*' character. For example, if there were two vaults named v1 and v2, instead of issuing the command twice, once for each vault, you could simply issue it once using vault v*. This clause is optional. For more information, see Status Searchindex.

validate searchindex [vault PATTERN] [type|relationship] [interval START_TIME END_TIME];

• vault PATTERN specifies the vault(s) to validate. The PATTERN argument allows you to specify a pattern of vault names, including a wildcard '*' character. For example, if there were two vaults named v1 and v2, instead of issuing the command twice, once for each vault, you could simply issue it once using vault v*. This clause is optional.
• type|relationship specifies whether to validate business objects only or connections only.
  Note: You cannot use both arguments in the same command.
• interval START_TIME END_TIME specifies a time interval so that only objects or connections modified in that interval can be validated. START_TIME and END_TIME must be in MX_NORMAL_DATETIME_FORMAT.

The validate searchindex command takes the 3DSpace Index High Availability configuration into account and produces separate validation reports for the primary and the secondary indexes.

This command generates a tcl script that can be used to repair the index. This tcl script contains the physicalids of all business objects and/or connections that are missing in the index. Once the script is launched, these business objects and/or connections are logged as custom events in the event monitor. The event monitor mechanism then triggers the incremental indexing of these custom events.

All logs and repair scripts are stored in the logs/sxi/validate/<tenantname>/validate_<timestamp>.zip. The generated logs are: validate_searchindex_counts*.log, validate_searchindex_objects*.log and validate_searchindex_repair*.log (which contains the oids of business objects or connections that need to repaired). Executing the validate searchindex command multiple times will therefore generate multiple zip files under logs/sxi/validate/<tenantname>. Each zip filename will have the timestamp at which it was generated. For High Availability cases, the zip will include the primary validate logs, the secondary validate logs, the primary index repair script, and the secondary index repair script.

The following system environment variables allow you to control the default behavior of the validate searchindex command. They must be added into the mxEnv.sh file (for Linux) or the enovia.ini file (for MS Windows).