Skip to content

General Information

Jörg Neumann edited this page Jan 14, 2022 · 2 revisions

Most tables of the API support initial values for at least some of their fields. For such fields, initial values will match any given value, which allows the creation of [partly] "generic" customizing entries.

At runtime the customizing will be filtered and the most specific entry will become effective.

In order to keep the subordinate pages short and crisp, the unified documentation format for database tables is described here.

Structure of table descriptions

Column Description
Fieldname The technical fieldname
Fieldtype Possible values: Filter, Key, Data
Filter-Priority Only filled, if Fieldtype is Filter
Description Describing text for the column

Possible Fieldtypes

Fieldtype Is key field? Description
Filter Yes Initial values are considered "generic", meaning that they will match any value at runtime.
Key Yes Initial values are NOT considered "generic". They must match the runtime values.
Data No Data fields contain the actuall settings.

If multiple fields of type Filter exist, the field Filter-Priority becomes important. If multiple matching customizing entries exist, the Filter-Priority decides, which entry "wins". The entry with lowest number has the highest priority.

Example

The example explains how the filter logic works in detail.

Table structure

Imagine that the structure description of our table looks like this:

Fieldname Fieldtype Filter-Priority Description
KEY_1 Key Example key #1
FILTER_1 Filter 2 Example filter #1
FILTER_2 Filter 1 Example filter #2
SETTING Data Example setting

NOTE: Field FILTER_2 has the highest priority in this example!

Table content

If you look at the table e.g. in SE16, it contains the following data:

KEY_1 FILTER_1 FILTER_2 SETTING
42 HELLO FOO 1
42 WORLD BAR 2
42 HELLO 3
42 WORLD 4
42 FOO 5
42 BAR 6
42 7
8

The initial Filter-fields will match any given value at runtime, which could lead to multiple matching customizing entries.

As we need EXACTLY ONE customizing entry, such collisions will be resolved using the Filter-Priority to find the most specific entry.

Example Inputs

The following table shows which input values would produce which results.

Input for KEY_1 Input for FILTER_1 Input for FILTER_2 Potential Matches Result Comment
42 HELLO FOO 1, 3, 5 1 A perfect match always "wins".
42 HELLO BAR 3, 6 6 6 wins over 3 because FILTER_2 has the higher priority.
42 UNKNOWN INPUT 7 7 1 - 6 do not match because of the non-initial fields.
12 UNKNOWN INPUT N/A N/A 8 would match, if the input KEY_1 was initial (Key-Fields are NOT generic)
Clone this wiki locally