古老的search help技术-Matchcode object

What are matchcodes?

Matchcodes are an SAP technique to help users find information, normally in
connection with the F4 key on an input field. Information from one or more
tables can be combined and queried on using various search criteria: for
example, all companies whose name starts with "LEVI" and whose location is
"San Francisco."

How are matchcodes implemented?

Traditionally, matchcodes were implemented as redundant collections of data
in pool tables, as illustrated in the following:

Company header table Company detail table   Matchcode pool table
(TAB1) (TAB2) (M_POOL)

The advantage of the old pool matchcodes was a quick and easy search, as
long as the significant fields were entered by the end user (in this case,
company name and location). The disadvantage was that for every change in
the master tables, the system had to make redundant updates in the matchcode
tables. In addition, it was impossible to search in a pool matchcode for any
but the significant fields, i.e., it would have been very CPU intensive to
search for all companies in San Francisco.

This limitation led to the creation of matchcodes (more precisely, in SAP
terms, "matchcode IDs") for every possible query you could expect from end
users (one with company name as the significant field, one with location,
yet another with customer number, and so on). Customers with a very high
number of debitors, for example, soon found that their pool matchcode tables 
grew to unmanageable sizes.

As of release 2.1, it is now possible to define so-called transparent or
view matchcodes. Transparent matchcodes are implemented by defining a
database view for the information that should be queried. Database views are
not redundant containers of data, but are merely definitions of paths to
obtaining that data. In the example:

Company header table Company detail table      Database view:
(TAB1) (TAB2) (M_VIEW)

The advantage of this new technique is that it is no longer necessary to
maintain redundant matchcode data: a view takes only a small amount of
database dictionary space. Using this technique, the query is converted by
the database to a query against the original tables, so it becomes very
important that access be supported by the proper indexes.

Matchcode Customizing

When a transparent matchcode ID is activated, the system checks if an
appropriate index exists for the ID. Normally, such an index is necessary to
support the matchcode query. If such an index does not exist, there can be
major performance problems during matchcode selection. The system assumes
that the first field in the matchcode definition (for client-dependent match
codes the first field after the client field) is the relevant search field,
i.e., that the user will narrow down the search by entering a selection
criterion in this field.

An index is considered appropriate for the matchcode if it contains this
relevant matchcode field (or the client field followed by this field).
If no such index exists, a warning is given during the activation of the
matchcode ID. At this point, there are two possible courses of action:
1) If the matchcode view in the database covers less than 1,000 data
records, it is not necessary to create an index.
2) If the matchcode view will search more than 1,000 records, you should
create an index.

The first fields of an index to support matchcode selection should be
those that will be searched with equality (client, language or general
fields for which the get/set indicator has been set, i.e., the flag GP is
set for the field in the screen Update Matchcode ID Fields).

The index should have the following structure:
Client field - Fields for which the Get Parameter flag is set

Search fields - This index structure does not guarantee that the index will
be used by the underlying database system. Which index is used depends on
the database system's optimizer. You must verify that the index you have
created actually is used by the database.

Use the following method to determine whether the proper index is being used
to support the matchcode query:
Open a second session and choose System / Utilities / SQL Trace.
Select Trace on.
In your first session, do a search on your matchcode ID.
In your second session, choose Trace off and then List trace.
Search in your list for the first statement in which the matchcode view
occurs. Use the function Explain SQL to obtain information about how the
optimizer services the query. In particular, you can see which index is used.


Surplus matchcodes:

Before Release 3.0, surplus matchcode IDs should be deleted.
As of Release 3.0, surplus matchcodes IDs should be deactivated.

Deleting matchcode IDs (before Release 3.0)

Before you can delete a matchcode ID, you must check if it is a "system
matchcode." You can tell this by looking at the field System matchcode on
the screen Update Matchcode ID (Attributes). If this field is set, SAP uses
this matchcode ID. You should never delete a system matchcode ID!
Unfortunately, the dictionary transactions will allow you to delete system
matchcodes, so you should be extremely careful to check this flag and don't
delete a matchcode ID for which the flag is set.

If the flag System matchcode is not set, you must check which programs
use the matchcode. Use the general table display function (se16) and enter
the matchcode object and matchcode ID as the table name.

Deactivating matchcode IDs (as of Release 3.0)

The function Deactivate in the menu MC-Id of the screen Update Matchcode ID
(Attributes) allows you to reduce the load of unnecessary matchcode IDs.
Rather than deleting the ID, the dictionary definition remains available in
the ABAP/4 dictionary. If at some point the ID is needed again, it can
simply be reactivated.
The function Deactivate can only be used for active matchcode IDs. Before a
matchcode ID can be deactivated, the corresponding objects in the database
must be deleted (e.g., the view and possibly the index for IDs of update
type I).
Note that when you deactivate a matchcode ID of update type S, the matchcode
records will no longer be updated to keep up with application data. If you
reactivate a matchcode ID, you must re-create the matchcode records with the
matchcode utilities.
Note also that the deactivated matchcode IDs will not appear in F4 help.
Warning: Deactivation is a pure customizing function, i.e., not a
transportable characteristic.
If a deactivated matchcode ID is delivered again by SAP, it will be active
again after the upgrade.

Conversion to transparent matchcodes

Prerequisites for conversion

To convert a "physically stored" (pool) matchcode ID to transparent (view),
the following condition must be met:
All underlying tables of the ID must be transparent; no partial fields can
be used.
Note that when converting a program-controlled ID, you may need to adapt
the application programs.

Conversion procedure

To convert a physically stored matchcode ID (update type A, S or P) to
transparent (update type I), proceed as follows: Copy the ID you wish to
convert to the customer name range (IDs 0 to 9). Change the update type to
I and activate the ID.

If the original ID has the update type S, change the original to update type
A. This prevents unnecessary updates of the old ID. In Release 3.0, you
should simply deactivate the original ID.

Changes after the conversion

Searches are case sensitive

Queries on transparent matchcode IDs are case sensitive, i.e., when entering
a search argument in the text field, there is a distinction between upper
and lower case. The search string "hugo" would not match with the value
"Hugo" in the database. In some applications, there have been text fields
added to the original tables in which information is held redundantly in
upper case. If you use these fields in the matchcode ID, you can avoid this
problem of case sensitivity.

Sort order in output changes

For releases 2.1G to 2.1J, the output list is sorted by the index that the
optimizer chose for accessing the ID. As of 2.2E, the sort order depends on
the field order in the ID, i.e., the sort order will correspond to that of
the physical matchcode IDs. Transparent IDs that were not delivered with
2.2E must be activated again to have this new sort order.

Result set of a query can be smaller

The result set of a query on a transparent ID can be a real subset of the
results of an equivalent query on a physical matchcode ID. This is because
of the fact that transparent IDs are implemented with an inner join, whereas
the physical matchcodes are realized with an implicit outer join.
When searching with a transparent ID, records of a primary table that have
no corresponding entries in the foreign key fields of a secondary table will
not be found.
Example: An ID provides the search for an employee's personnel number using
name and department. The primary table contains the personnel number and
name. The secondary table contains departments and their employees.
Employees who have not been assigned to a department have no entry in the
secondary table. THose employees will not be found in a search with a
transparent matchcode with fields number, name and department. In a physical
matchcode ID with the same fields, those employees will be found.

Adapting partial fields

Partial fields in matchcodes are fields that you have defined so only a
portion of the original field is displayed and maintained in the matchcode.
You might want to show, for example, only the last six positions of SAP's
standard 16-character material number. If you defined partial fields for
the matchcode ID, their definitions must be removed to convert to a
transparent matchcode.

Further information

Issues especially for programmed matchcodes (update type P)

Programmed matchcodes are implemented physically, i.e., the matchcode data
is held redundantly in a separate table. The data is updated directly by
application programs, so that these application programs and other programs
always have access to the latest matchcode data. A function module is
generated during activation of the matchcode. The matchcode data is updated
when this function module is called. Conversion of programmed matchcodes to
transparent requires changes to the application programs that use the
function module. It is possible to just comment out the call to the function
module.

Adding tables to a matchcode object that contains a programmed matchcode ID
can lead to difficulties. Only one function module exists for all programmed
IDs in the object. This function module gets its information directly from
the matchcode object. For this reason, the function module interface should
be modified whenever the basis table of the object is changed, even if this
modification does not directly concern the programmed matchcode IDs.

Common problems with matchcode tables

Excessively large matchcode pool tables

At some point, it becomes difficult to manage large matchcode tables. There
are, for example, jobs that delete and re-create matchcodes; these run fine
if the master tables have only 50,000 records, but become quite cumbersome
if the master tables grow to have many millions of records. You may also see
a high number of extents on matchcode tables (i.e., table names beginning
with M_).
If you are having trouble managing pool matchcodes, you should seriously
consider converting to the new view matchcode technique.