Initial Structure of Index Pool for Error-Tolerant Search (SAP Library

Initial Structure of Index Pool for Error-Tolerant Search

The report /PARTNER/RSADRINI has to be provided for the initial structure of the index pool. This report calls the standard function module ADDR_EXTRACT_FOR_DUPL_INDEX in a queue.

Note

Instead of "/PARTNER/", the actual namespace prefix is used. The ending "RSADRINI" is predefined. In the following, the report is always called /PARTNER/RSADRINI.

If IBUs or international subsidiaries implement a solution, a suitable similar name will be used in the appropriate namespace.

The following functions are implemented in the function module ADDR_EXTRACT_FOR_DUPL_INDEX:

By means of package processing (open cursor with hold, fetch next cursor), the function module imports all addresses in internal tables and passes the resultant tables ADDRESS_FIELD_LIST and ADDRESS_OBJECT_LIST to the calling program.

To determine the index-relevant fields, the method READ_INDEX_FIELD_LIST is called for the specified index pool. If this method does not return a result, the default is read from table TSAD10.

The address where-used list is used to determine which addresses from the dataset enter the index pool.

All the object types for the index pool are read using table TSADRVGRPE. Addresses that, according to the where-used list, belong to these object types are written into the index pool.

The corresponding field values for each address are passed to the structured table ADDRESS_FIELD_LIST. The field list has a generic structure because, in a later release, it may also contain fields of other software layers that are to be determined dynamically.

The list of corresponding owner object types is also passed to table ADDRESS_OBJECT_LIST for each address. The field FLT_VALUE is not filled with the application object key (customer number, vendor number, business partner number) since this information should not be stored in the search index. Instead, this information is to be determined after the search using the where-used list. Usually, only one object is the owner object (for example, Customer: KNA1 ADRNR), but in special cases there can be several objects (Plant master: Customer + plant + possible vendor, Returns vendor: Customer + vendor).