A TBOM contains a list of all objects in an executable entity. These objects are, for example, elements of the user interface, module pools, function modules or tables.
These objects are assigned to a TBOM Enhancement. When a TBOM is created, the system creates a first TBOM enhancement which contains all objects in this initial recording. You can add any number of enhancements to a TBOM, increasing the list of relevant objects.
TBOM extensions can be generated dynamically or statically. For more information about the creation types, see Recording a TBOM.
The Business Process Change Analyzer can use a TBOM to determine whether an executable entity is affected by a change (for example, by changed objects in a transport request).
The following information is saved with every TBOM enhancement (you can view this information on the TBOM tab page in the Enhancements dialog):
Enhancement name
Enhancement type (dynamic, static, or automatic test case)
Logical component
Managed system name
Managed system client
TBOM enhancement status
Number of objects in the enhancement
Managed system product version
Managed system role
Created by and on/at
Name of the automatic test case by means of which the enhancement was created
The system also saves the following dates for each TBOM enhancement:
Creation date
Last change date
Date of last obsolescence check
These dates are used during the obsolescence check. Based on these dates, the system defines the scope of transport requests for which objects must be checked.
The TBOM also contains the following information about the individual objects involved in the executable entity (you can view this information in the TBOM content display):
Program ID: ID of the object, for example, R3TR for complex objects such as programs and all related elements or LIMU for subobjects
Object type: Precise assignment of the object to a type, for example, REPS for Report Source, FUNC for functions, TABL for tables
There are several hundred different object types.
Object name: Technical name of the object
Program ID, object type, and object name together uniquely identify the object.
Origin: Origin of the object
D for dynamically generated objects
S for statically generated objects
Classification type: Different object types are summarized to a classification type. The default assignment of classification types to object types is stored in the system.
The following classification types have been predefined:
TABC = Table Class
UI = User Interface
TRAN = Business Transaction
FUNC = Business Function
DOKU = Technical Documentation Object
DDIC = Data Dictionary
AUTH = Authorization Object
CUSX = Customer Extension Points (EnhSpots)
MISC = other classification types
Classification values: Objects of classification type TABC (tables) are subdivided further using the classification value as follows:
A = Application table (master and transaction data)
C = Customizing table (entries and changes can only be performed by the customer, no SAP Import)
L = Table for storing temporary data (supplied blank)
G = Customizing table (new entries only from SAP, existing entries in the customer system are protected)
E = Control table (SAP and customer have own key areas)
S = System table (entry and changes can only be made by SAP, change = modification)
W = System table (content can be transported using own TR objects)
Package: Development class
Software component: Name of the application from which the object originates, for example SAP_BASIS.
Object type: Designation from the version database. Since reference objects are used there, the designation can deviate further from the object type mentioned earlier in some rare cases.
Object name: Designation from the version database. Since reference objects are used there, the designation can deviate further from the object name mentioned earlier in some rare cases.
Table key: When database tables are accessed, the values of the key fields used to access the tables are also entered in addition to the database tables. This enables the system the reduce the number of hits in the change impact analysis.
Note
Only the following table types can be accessed:
C = Customizing table
G = Customizing table
E = Control table
S = System table
W = System table
Whether the system can record a key value for table access also depends on the type of access. The following access types are supported:
Any access covered by the SAP table buffer
Access for which at least one key field is specified
The following access types are currently not supported:
Access with SQL statement SELECT FOR ALL ENTRIES
Access with range tables
Access with join expressions
If the system cannot record a key value when accessing a table, the TBOM contains the table name only. In the change impact analysis, each changed entry in such tables leads to hits in all executable entities that access these tables.
The TBOM is an attribute of an executable entity in the Business Process Hierarchy (SOLAR01).
Dynamic TBOMs: In systems with kernel 620/640, the creation of dynamic TBOMs is only possible after status ST-PI 2008_01 SP03. In all other systems (kernel 46C or after 640), the creation of dynamic TBOMs is available.
Cross-system TBOMs: If an executable entity addresses other systems (e.g. by RFC), the objects in the other systems are also recorded. A separate TBOM enhancement is created for these objects per system. This function is available if all managed systems involved have a kernel status of at least 700.
Web applications: To record TBOMs for web applications, the managed systems must have a kernel status of at least 700.
Static TBOMs: The generation of a static TBOMs is available for managed systems from ST-PI 2008_01.