Individual Objects of the Configuration

Object dependencies

Characteristics

Variant Tables

Buffering Master Data Tables

1 Object Dependencies

1.1 Description
Global or Local Object Dependencies
Object dependencies can be defined locally or globally. In general, global dependencies lead to
better performance than local dependencies.

1.2 Analysis
List all object dependencies, you will recognize all local dependencies by viewing the dependency
name. A local object dependency has no name, only an internal number. A global object
dependency cannot have a number as a name.

1.3 Recommendation
Global or Local Object Dependencies
We recommend the use of global dependencies as opposed to local dependencies.

If you use a dependency more than once, global dependencies lead to better performance than
local dependencies. This also applies to global dependencies that are used in more than one
configuration model.

You should only use object-specific (Local) dependencies if you are certain that the dependency
will not be needed elsewhere.

1.4 Influences on the business process and maintenance of the model

Global or Local Object Dependencies

‘+’ If global dependencies are used, you can use the central maintenance functions on these
dependencies and allocate them to other objects.

1.5 Performance improvement

If a global dependency is allocated more than once, the database buffer or the R/3 buffer is used
more often than for a local dependency.
Improving Performance of Variant Configuration

>> Go to top of document

2 Characteristics

2.1 Description
Restrictable Characteristics
In order to help the sales order taker during the configuration process, you can use restrictable
characteristics. With a constraint and a variant table, restrictable characteristics dynamically
reduce the number of possible characteristic values (PF4). Please be aware, however, that the use
of restrictable characteristics with constraints and variant tables add a considerable load on the
system.

2.2 Analysis
You can see quite clearly from the configuration trace that variant tables have to be interpreted
much more frequently when used in this way (please also see the section on constraints).

For a specific characteristic you can check via transaction CT03 (and then press return) if the value
assignment is “single-value”, “multiple value”, or “restrictable”.

2.3 Recommendation
Restrictable Characteristics
Instead of modelling with restrictable characteristics you can always use preconditions. Often this
results in a huge number of preconditions. In those cases we recommend you to program a
function module to check and set the allowed set of value for each characteristic. To be able to
display the allowed value set, a customer specific F4-function must be written. You can combine
this with a transparent table containing all valid combinations of the characteristics.

To do a complete check of the assigned values, we realize it may be necessary to use constraints.

For detailed information please see the R/3 online documentation:

Cross Application → Characteristics Guide → Maintaining Characteristics → Values → Function
Modules for Checking Values'.
This documentation is also available when you are processing the values screen of a
characteristic. Choose 'Other value check', select 'Function module' and confirm, then choose the
F1 help on the 'Function' field (ATPRF).

Preconditions are re-evaluated frequently. Constraints are evaluated only once, as long as the
input values don’t change. In general, it is important to ensure that these input values for the
constraint are not set by actions or procedures, as these will also cause frequent re-evaluated, by
the constraint!!

The performance of constraints for restricting the value range is expected to improve when the
table look-ups improve. The technique of restricting value ranges dynamically with constraints is a
powerful one that should not be ignored. However, please be aware that very large value ranges
will be particularly resource intensive and adversely affect performance.

If you continue to model with restrictable characteristics you should not allocate an additional
precondition to a value of one of these characteristics.

2.4 Influences on the business process and maintenance of the model

Printed on 12/5/2010 Page 2

Improving Performance of Variant Configuration

Restrictable Characteristics

'- -' Additional efforts in programming a function module and creating a transparent table for
possible characteristic values combinations.

'- -' Inheritance of characteristic values and processing of object dependency allocated to the
characteristic values is not carried out.

'-' The setting of one characteristic value, if only one is possible or allowed, must be
programmed in the function module.

2.5 Performance improvement

Restrictable Characteristics

'+ +' Constraints don’t need to be loaded.

The performance of loading and processing constraint nets is currently being improved in
31I. The results are not available yet. In 40x (x > 40C) and the SCE constraint loading and
processing will be significantly improved.

'+ +' Variant tables do not need to be loaded in order to find, check, limit the value range, or set
characteristic values.
The table selection will be improved significantly in 3.1I using enhanced run time objects for
variant tables. It is a goal to significantly improve table selections in the SCE.

>> Go to top of document

3 Variant Tables

Tables are used to store complex inter-relationships between several characteristics and their
values in a format that is easy to read and maintain. You can use tables to either check
consistency or to set characteristic values. In release 3.0A up to 4.0B all entries of a variant table
are stored in the AUSP and KSSK tables.
Every row in the variant table is stored as an entry in KSSK. Every entry (selected value) is stored
as an entry in AUSP. A selected interval value will only cause one entry in AUSP.

Example 1:

Note: In this example characteristic CH3 is an multi-valued characteristic

CH1 CH2 CH3 CH4
Type1 200 mm A 10 – 20
B

 AUSP entries: 5; KSSK entries: 1

Example 2:
CH1 CH2 CH3 CH4
Type1 200 mm A 10 – 20
Type1 200 mm B 10 – 20

Printed on 12/5/2010 Page 3

Improving Performance of Variant Configuration

 AUSP entries: 8; KSSK entries: 2

3.1 Description

Runtime objects
A runtime object is a compressed, locked version of the table, with its lines and entries. You can
create runtime objects for a variant table by using the path: Extras → Runtime object →
Activate. If you activate a runtime object, you see a special icon column on the right of the list of
the table structure (see Table Lists). If you activate runtime objects for variant tables the system will
keep them up to date if the variant table is changed.
CLBUF Key if RELID = TA, SRTFD contains CLINT (internal table name = class name)

If RELID = TB, SRTFD contains CLINT + ECM No (blank if not used)+ R/3 Release

The content of a variant table is stored in the field CLUSTD of the table CLBUF, eventually in more
than one line entry. (Function group for these operations is CUD3).

Splitting of large variant tables

A large variant table may be divided into some, smaller tables. In order to do this you must check if
it is logically possible.

Transparent tables
The structure of a variant table is replicated as a transparent table. In the object dependencies
where the variant table is called you must refer to the transparent table via a variant function.

Unfortunately, this is not useful for dynamically restricting the set of values (domains) with
constraints, because functions cannot be used for restricting domains in constraints.

3.2 Analysis
General
A list of all variant tables is shown by the logistics monitor (transaction ST14 ). For each table the
number of rows and columns (i.e. characteristics) are described. For this, use the following path:
“Sales and Distribution” → “Functions” → Variant Configuration → Variant Tables.

From the configuration trace you see which variant tables are used during the execution of the
configuration.

Also, you can use transaction “CU64”. After pressing the “execution” button, you will get a list of all
variant tables with their descriptions, statuses, group names, and a flag (so called radioactive flag)
indicating the existence of a run time object.

Runtime objects
A list of all variant tables is shown by the logistics monitor (transaction ST14 ). For each table a flag
describes if there is a run time object for this table. For this, use the following path: “Sales and
Distribution” → “Functions” → Variant Configuration → Variant Tables with Run Time Objects.

Splitting of large variant tables

The size of a variant table can be estimated by the logistics monitor (transaction ST14 ). For each
table the number of rows and columns (i.e. characteristics) are described. For this, use the
following path: “Sales and Distribution” → “Functions” → Variant Configuration → Variant
Tables.

Transparent tables
The configuration trace does not describe if a transparent table is read. But it lists the functions,
which are executed.

Printed on 12/5/2010 Page 4

Improving Performance of Variant Configuration

With an SQL-Trace you can detect if customer defined tables are used. These tables can used
during the configuration.

To compare these three ways of using a variant table we did some run-time measurements that are
available in a separate document.

3.3 Recommendation
Runtime objects

’!’ You should always activate runtime objects for variant tables by choosing 'Tools ⇒ Table
structure ⇒ Create/Change/Display' from the variant configuration menu. These runtime
objects are automatically regenerated by the system, (unlike the runtime objects for the
configuration model).

Splitting of large variant tables

'+' As a rule, it is better for performance if you use several small tables with a smaller number of
characteristics and value entries, than one large table. When you have more than 500 lines
in one table you should check if it is possible to split this large variant table into a several
smaller ones.

Transparent tables

'++' In the case of large tables (for example, 2000 lines and 15 columns), we advise you to use a
transparent table (DDIC tables) instead of a variant table. You must then use variant
functions to process these transparent tables individually. You should also consider table
buffering for the transparent tables.
Do only take this step if the variant table causes performance problems!

3.4 Influences on the business process and maintenance of the model

Runtime objects

‘-‘ If you change the table structure, the runtime objects for variant tables must be regenerated.

Splitting of large variant tables

‘-‘ Maintenance effort increases with the number of variant tables

Transparent tables

‘- -‘ More effort in programming of function modules and creating of transparent tables in the
DDIC.

‘-‘ Less flexibility in changing the table structure.

‘-‘ For transporting the table with “ALE” functions must to be programmed. The easier way is by
using the transport system.

3.5 Performance improvement

Runtime objects
If you import a runtime object, the object is stored in the global data area of program SAPLCUD4.
The next time you access the same table, the system only needs to expand the data in table
CLBUF, and not re-read it. (However, there is a small disadvantage of activating runtime objects,

Printed on 12/5/2010 Page 5

Improving Performance of Variant Configuration

as table maintenance involves constant regeneration of a new run time object.)

Printed on 12/5/2010 Page 6

Improving Performance of Variant Configuration

Transparent tables
Large variant tables adversely affect performance, because they are internally stored as classes
and classifications records. Using transparent tables avoids the selection in the AUSP and KSSK
tables of the classification system.

If you activate table buffering for the transparent tables you would further improve performance.
The buffer are tables which are stored in the memory of the application server and if you access a
buffered tables this request goes only to the buffer and not to the database. This can lead to a
significant decrease of database load and can improve system wide performance.

Using transparent tables instead of variant tables always results in less runtime.

In order to compare the runtime of the three alternatives and to provide customers with “best
practice” implementation rules, a series of tests were executed (vt_sum.DOC - Measurements)

3.6 Example Transparent tables

Typically scenario :

Deriving a characteristic value with a procedure or an action referring to a variant table.

Variant table: MAXLOAD

CABIN_WIDTH CABIN_DEPTH MLOAD
(maximum load)
1000 mm 2000 mm 850 kg
1200 mm 2200 mm 1250 kg

An action (or a procedure) sets the value for characteristic MLOAD during the configuration
process. This procedure refers to variant table MAXLOAD.

TABLE MAXLOAD ( CABIN_WIDTH = $ROOT.WIDTH,

CABIN_DEPTH = $ROOT.DEPTH,
MLOAD = $SELF.LOAD )

Scenario with transparent table:

Deriving a characteristic value using a (procedure or) an action with a function referring to a
transparent table.

1. Create a transparent table in the DDIC that has the same structure as your variant table.

2. Create table entries in one of the following ways:

• Manually in transaction SM31 (in this case, the length of the name is limited to 5 characters)

• By making entries in your variant table (your variant table is the user interface)
You need to write an ABAP report program that updates the transparent table. As of Release
3.1I and 4.0, there is a userexit in variant tables for executing this update program.

3. Create a function. The name of your function must be the same as the name of the
function module that you want to call. When you create a function, the system automatically
looks for a function module with the same name (see processing method 2).

Printed on 12/5/2010 Page 7

Improving Performance of Variant Configuration

4. Create an action (or a procedure) that refers to the variant table. Replace the keyword
TABLE with the keyword FUNCTION, and enter the name of the function. You do not need to
change the assignment of characteristic names in configuration (right-hand side) to
characteristic names in the table (left-hand side), provided that the function uses the same
characteristics as the table.

Transparent table: ZMLD

ZWIDTH ZDEPTH ZMLOAD
(cabin width) (cabin depth) (maximum load)
1000 mm 2000 mm 850 kg
1200 mm 2200 mm 1250 kg

A procedure sets the value for characteristic ZMLOAD during the configuration process. This
procedure uses a function (with function name ZMAX_LOAD) to refer to transparent table ZMLD.

FUNCTION ZMAX_LOAD ( CABIN_WIDTH = $ROOT.ZWIDTH, CABIN_DEPTH =

$ROOT.ZDEPTH, MLOAD =
$SELF.ZMLOAD )

Function ZMAX_LOAD

Interface import/export parameters:

GLOBALS CUOV_00

Interface table parameters

QUERY CUOV_01
MATCH CUOV_01

Exceptions FAIL
INTERNAL ERROR

*Source code:

tables: ZMLD.
data: xmload like cuov_01-atwrt,
xwidth like cuov_01-atflv,
xdepth like cuov_01-atflv.

*Read cabin depth from configuration:

call function 'CUOV_GET_FUNCTION_ARGUMENT'
exporting
argument = 'CABIN_DEPTH'
importing
num_val = xdepth
tables
query = query
exceptions
arg_not_found = 01.
if sy-subrc <> 0.
raise internal_error.
endif.

Printed on 12/5/2010 Page 8

Improving Performance of Variant Configuration

*As for cabin depth, use function module

CUOV_GET_FUNCTION_ARGUMENT.

*Read transparent table ZMLD:

select * from zmld where zwidth eq xwidth
and zdepth eq xdepth.
move zmld-zmload to xmload.
endselect.

*Set value for characteristic MLOAD in function ZMAX_LOAD:

Call function 'CUOV_SET_FUNCTION_ARGUMENT'
exporting
argument = 'MLOAD'
vtype = 'NUM'
sym_val = xmload
tables
match = match
exceptions
existing_value_replaced = 01.

If you call the variant function in a procedure, you are supposed to use a "PFUNCTION", her you
can call functions allocated to function module CUPR. For more information have a look in the on-
line documentation.

>> Go to top of document

4 Buffering of Master Data Tables

4.1 Description

As with other forms of data buffering, any changes made to your data are not made in the buffer.
Roughly speaking, the buffer contains the actual data after following the load of this data or after a
synchronization of the buffer. Therefore, the frequency with which a table is changed in your
situation determines whether or not you can buffer a table. Moreover, the table must fit into the
buffer. Of course, the size of a table which you can buffer is limited by (a fraction) of the size of the
table buffer.

4.2 Analysis

Frequency of Change
To determine the frequency of updates before Release 3.0D, call Transaction ST03. In Table
statistics, choose All servers. Choose Tables of all servers.
To determine the frequency of updates with 3.0D, call Transaction ST10. Choose All tables → All
servers → This week. The Changes column shows the frequency of changes in each table.
CAUTION: In most cases, for several days after the start of production, certain post-customizing
actions are required which distort the statistics. If in doubt, contact the customer to check the
frequency of changes since the start of production.

If the table is frequently updated, find out why, and whether the situation is only temporary.

Size of the Buffer

Estimate whether the table buffer is large enough, or whether tables are displaced from the buffer

Printed on 12/5/2010 Page 9

Improving Performance of Variant Configuration

(that is, whether the table has status pending). If necessary, advise the customer to increase the
size of the table buffer. To determine whether this is necessary, call Transaction ST02 and look for
the entry (N1) in field swaps of the table buffer. This alternative is only available as of Release
3.1H.
NOTE: This entry is not the number of tables which were displaced, but rather the number of
reorganizations. During such a reorganization, more than one table is displaced.
If this parameter is not available, call Transaction ST02. Choose In Tables → Call Statistics (from
the Detail analysis menu). Count the number of tables (N2) with status pending.

Table Size
The table size can be determined by:

1. Call Transaction ST02.

2. Select Detail Analysis Menu.

3. Select Call Statistics.

4. Locate the cursor in the selected table.

5. Select Analyze Table. (Note: In addition to the table size you get the selectivity of each
individual attribute.)

4.3 Recommendation

The main database tables of the variant configuration are listed below, most of them can be
buffered.

— You can influence the time it takes to load object dependencies by defining how table
CUEX is buffered. Unfortunately, table CUEX can become huge. Therefore, you need to know
how much memory is required for table CUEX. You can choose to buffer only part of the table,
instead of 100%. If you do this, only the object dependencies that are used most frequently are
held in the buffer.
Table CUEX should be buffered, if the customer does not change the object dependencies (of
configuration model for the configurable products) in his productive system.
Use a generic buffer with two keys (CLIENT, KNNUM).

— Tables for the configuration model and the classification system can also be buffered, if
the customer does not change the classification system and the configuration model for the
configurable products in his productive system.

Printed on 12/5/2010 Page 10

Improving Performance of Variant Configuration

PRELIMINARY LIST OF TABLES USED BY VARIANT CONFIGURATOR

table name desciption buffering relevant

Class
KLAH Class data *1
SWOR Description/Catchwords *1
KSML Characteristic allocations to class x
Characteristic
CABN Characteristic – Header Data x
CABNT Descriptions x
CAWN Values x
CAWNT Value Descriptions x
Classification/Configuration Result*
KSSK Allocations of Objects to class no
INOB Object key (e.g. material no) --> CUOBJ no
AUSP Char value for a CUOBJ no
Config profile
CUCO Conf.profile data *1, 2
Variant table
CUVT
KRIF value assignment alternative x
KLAH Variant table header data x
KSML Allocation of characteristic to variant table x
AUSP Content of variant table no
Dep. knowledge
CUEX Compiled dependency Knowledge x
CUKN Dependency knowledge *1
CUKB Administrative data x
CUKBT Description *1
CUOB Links between object and multiple dependencies *1
CUXREF Object dependency cross reference – where-used list *1
Constraint specific
CURSVAR Constraint Internal variables x, 3
CUCVRNT Constraint Variants *1
CURSADD Dep.net additional data *1
CURSCOD Storage of Code to be Evaluated x, 3
CURSOBJ x
CURSDNN x
CURSSPN x

x: relevant for buffering

n: in the case of generic buffering: n denotes the number of key fields
*1: not performance relevant

Type of Buffering

If the table is large and it should be buffered, the buffered table size can be reduced by using a
generic buffering type. For determining the number of key fields use the selectivity of the attributes
(see section analysis). Generally, it is not necessary to buffer all data of a table belonging to
different clients at once.

Printed on 12/5/2010 Page 11

Improving Performance of Variant Configuration

General remark

Tables AUSP and KSSK are normally changed frequently and they become huge in most customer
systems. Therefore, buffering them is not recommended.

>> Go to top of document

Printed on 12/5/2010 Page 12