Searching and finding

Objects you can include when using the full-text search.

The EUREKA search indexes specific fields of a DTO. Fields added through customizing can be indexed addi­tionally.  For these, the Additional fields sublist can be found in the object list (Administraion/Tools/Search and find/EUREKA search: Objects). Here, you can add the additional fields to be indexed for every DTO. If a specified field in the DTO exists and is visible, then the field content will be captured as a new line in the index text. CLOB fields are first converted to plain text.

All string and CLOB fields of an object are indexed as ell. The fields with GID or IDN in their name, as well as system fields, are excluded.

Indexing also includes component fields (i.e. certain data of linked objects) such as:

• For contacts in general: addresses, properties
• For persons, in addition: company name
• For companies, in addition: industry, region
• For projects: customer name, address, properties, products
• For service objects: customer name, operating company name
• For products: supplier name

1. In the administration of the Eureka search: For objects, also component fields can be specified in the list of fields to be indexed additionally.
2. In the individual reader implementations, the relations to the indicated components or lists can be defined using code. Then these will reindex the actual object when the index is updated. The definitions of 1. don’t need to be specified once again in the list. If an indexed n:m record is deleted (e.g., address or property), the actual object (e.g., contact or project) cannot be reindexed because the data required to find the relevant record does not exist anymore. In this case, the index is incorrect until the object modifies itself.
   The index reader needs to be overloaded if a field (string field) should really be excluded.

• The index used by the EUREKA search is refreshed immediately after data has been created or modified.
• The behavior can be controlled in detail via several PSA_FUL_IDX_... variables (Classification general / EUREKA search).

For the full text search in emails or their metadata, a method is used that reduces the load on the data­base, accelerates the groupware synchronization significantly and does not require a job for indexing.

The search in email fields is avoided where possible, and instead each cluster instance holds a map with all email addresses and contact GIDs. Modifying or deleting a contact have an effect on the map and are distributed in the cluster compound. The phone numbers are also stored in a map. This allows dropping the Lucene-based phone index. The advantage is that changes are found immedi­ately.

Recommendation: Switch off the job for the telephone index!

A tool for the EUREKA index administration is available, particularly for administration in cluster mode: Administration/Tools/Search and find/EUREKA search: Administration

The dialog offers several functions:

Output of the document number, index size and date of the most recent index update.

Closes all references to the index.

Deletes the entire content of the index.

Enables or disables the automatic index update (background update).

Copies the variables for the last update time to other clusters.

Opens the index updating job for editing or customizing.

Shows the filter definition data for the DTO of the current dialog. The data can be viewed and edited in the filter management. The filter management is limited to the DTO. It is not possible to use the filter for other data classes.

The full search condition of the filter can be checked in Where condition. It is automatically built from the individual field search entries defined in the filter form. You can correct or extend the total search condi­tion here in the list.

Using View, you can restrict the display.

The difference to the filter management for dialog objects (e.g. the company mask) lies in the information the filter has available.

The filter dialog of the company mask is aware of the data object on which the company mask, and therefore also the corresponding components and associations (blue and red folders), is based. The filter administration only refers to the data object of the filter, in the example PSA_CON_STR, the absolute base table of the contacts. For this reason, only the fields of this table are visible here.

This ultimately restricts editing a filter in the filter administration, since only the data object of a filter is known. If you want to add fields from components of the "Company DTO", this is only possi­ble via the filter dialog of the mask. There, the filter automatically receives the PSA_ORG_EXT_XTD DTO in the example, and thus also the proper associa­tions and components in the filter management of the mask.

The reason for this is that the same filters should not be available in too many places at the same time (filters for service cases also at marketing masks etc.). This way, filters are visi­ble only in the mask in which they were created, or in masks that have exactly the same data object as their basis.

In the filter administration, this data object should not be changed then to prevent fil­ters from "disappearing". This means that a filter that is visible in the company mask should also remain visi­ble there after changing it.

As an administrator, you can use the global filter administration to make a filter accessible to other users if, for example, it was created by an employee who meanwhile left the company.

For this, open and focus a dialog for whose driving data class you want to manage the filters, and then call Admi­nistration/Tools/Search and Find/Filter Management. Then, the filter administration opens, showing (unlike the filter list in the PiSA cubes - resources) only the filters for the specific DTO. Here you can call the access wizard via the context menu, where you can change the access to the selected filter as needed.