Show TOC

Object documentationTechnical Bill of Materials (TBOM) Locate this document in the navigation structure

 

A TBOM contains a list of all objects that are involved in a certain transaction. These objects are, for example, elements of the user interface, module pools, function modules or tables.

TBOM contents can be generated dynamically or statically. A TBOM can also contain a mixture of both content types.

  • Dynamic:

    In the dynamic generation of a TBOM, the corresponding transaction is called using the corresponding RFC user in the managed system. All objects involved in the transaction are entered in the background and copied to the TBOM once the transaction is complete.

    The generation of the dynamic TBOM only covers operations in the managed system that are processed within a context there. Branches to other systems (e.g. by RFC) are not recorded. This also applied to branched GUI procedures, which occur, for example, if a Web Dynpro is called within an SAP transaction. The operations within the Web Dynpro application are not recorded.

  • Static:

    In the static generation of a TBOM, the transaction is not called. The system uses an environment analysis to determine which objects are involved in the transaction. Dynamic calls or generated objects are not found and therefore do not enter the TBOM either.

 

Business Process Change Analyzer can use a TBOM to determine whether a transaction is affected by a change (e.g. Support Package, customer development, add-on installation, …).

Structure

The TBOM contains the following reference values about the managed system in which the corresponding transaction was executed:

  • Names and version numbers of Support Packages

  • Names and version numbers of add-ons

  • Names and version numbers of main components

In the actuality check, this information is compared to the current status of the managed system.

The TBOM also contains the following information about the objects involved in the transaction:

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

    Predefined classification types are:

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

    • A = Application table (master and transaction data)

    • C = Customizing table (customer maintenance only, no SAP Import)

    • L = Table for storing temporary data (supplied blank)

    • G = Customizing table (protected against SAP UPD, only INS allowed)

    • E = Control table (SAP and customer have own key areas)

    • S = System table (maintained only 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, e.g. SAP_BASIS.

  • Object type: Designation from the version database. Since reference objects are used there, the designation can, in rare cases, deviate further from the object type mentioned earlier.

  • Object name: Designation from the version database. Since reference objects are used there, the designation can, in rare cases, deviate further from the object name mentioned earlier.

  • Version number: Current version number of the object

  • Order number: Number of the transport order used to transport the object in its current version into the system.

Integration

The TBOM is an attribute of a transaction in the Business Process Hierarchy (SOLAR01).

The generation of dynamic TBOMs is not available in managed systems with kernel 620/640 but it is available in systems with kernel 46C and above 640.

The generation of static TBOMs is available for all managed systems with ST-PI 2008_01.