What Is a Technical Bill of Materials (TBOM)?

Definition

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 and extend the list of relevant objects.

TBOM enhancements can be generated dynamically, statically, or semi-dynamically. For more information about the creation types, see Choosing the TBOMs Types.

Use

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).

Structure

Information About TBOM Enhancement

The following information is saved with every TBOM enhancement (you can view this information in the TBOM dialog box, on the Enhancements tab page):

  • 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.

Information About the Objects Contained

The TBOM also contains the following information about the objects 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: Assignment of the object to a type, for example, REPS for Report Source, FUNC for functions, TABL for tables

    There are several hundreds of different object types.

  • Object name: Technical name of the object

Together, the program ID, object type, and object name 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 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 occasionally differ from the object type above.

  • Object name: Designation from the version database. Since reference objects are used there, the designation can differ from the object name above.

  • 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 to reduce the number of hits in the change impact analysis.

Integration

TBOMs are assigned to executables in the Solution Documentation view.

Dynamic TBOMs: In systems with kernel 620/640, dynamic TBOMs can only be created after status ST-PI 2008_01 SP03. In all other systems (kernel 46C or after 640), dynamic TBOMs can be created.

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: Static TBOMs can be generated for managed systems from ST-PI 2008_01.