Short Story

If you want to know more about TBOMs, keep reading this blog. We are going to provide you more details about its content, types, and how to record them to run a BPCA analysis before deploying planned changes into productive systems.

The TBOM contain a list of all technical objects that are used by a specific transaction, and may contain elements such as function modules, tables, among others. There are 3 types of TBOMs: dynamic, semi-dynamic and static.

Semi-dynamic TBOMs require the collection of usage data from the target managed system. There are 2 options to collect usage data – via UPL (Usage Procedure and Logging) or via SCMON (ABAP Call Monitor).

Different strategies can be adopted to create a Technical Bill of Material such manually, manually during UAT, via automated test cases or background jobs.

Long Story

In the previous blog article, the Business Process Change Analyzer feature was described. Now, we are going to provide you more details about the Technical Bill of Material like its content, types, and how to record them to run a BPCA analysis before deploying planned changes into productive systems.

Before running a BPCA analysis, you must create the so called TBOMs. They contain a list of all technical objects that are used by a specific transaction, and may contain elements such as function modules, tables, among others.

Although it is an independent entity, it must be assigned to an executable such as a transaction or a report. The assignment is automatically done by Solution Manager during creation-time of a TBOM.

The figure below shows the creation of a TBOM for transaction FPY1 “Payment Run / Debit Memo Run” which is assigned to process step “Payment Run” under business process “Account Payables” in Solution Documentation.

The figure below shows the statistics for this TBOM considering two factors – classification type and software component.

In the Statistics block, you can get more details about its content classified by Logical Component Group, Software Component and Package to which the technical object belongs to.

 By choosing a package, more details are shown:

 There are 3 types of TBOMs: dynamic, semi-dynamic and static.

  • Dynamic-TBOMs: this is the most complete and efficient TBOM type as it contains a list of all objects that are used during the execution of a transaction in a specific business context. The drawback is you need to run it either manually or by using an automated test case (e.g. CBTA).

  • Static-TBOMs: this option is not efficient as a dynamic or semi-dynamic TBOM as it relies only on the technical objects listed in the executable’s code and certain level (usually 4) which might not be enough to have a reliable analysis. Additionally, dynamic call cannot be captured. The advantage of using this type is the possibility to create a background job to massively create TBOMs for the entire BPH at once.

  • Semi-dynamic TBOMs: This approach is available as of SAP Solution Manager 7.1 SP10, and is much more efficient than static TBOMs. Likewise, it is possible to massively create TBOMs using a background job, however it requires in advance the collection of usage data from the target managed system. There are 2 options to collect usage data – via UPL (Usage Procedure and Logging) or via SCMON (ABAP Call Monitor). Keep in mind both UPL and SCMON belong to SAP NetWeaver component, but they are consumed by Solution Manager and stored on its Business Information Warehouse (BW) system. Another advantage of using this type compared to static-TBOMs is that dynamic calls may be captured as well (SCMON), and it is possible to go much deeper in the code (999 levels, which is more than sufficient). It is recommended to have at least 3 months of usage data to get a more reliable BPCA analysis. * I’ll write another blog to explain in more details about UPL and SCMON.

In the TBOM window, it is possible to find out its type, status, creation date and time, and much more.

 Different strategies can be adopted to create a Technical Bill of Material.

  • Manually: BPXs need to create the TBOMs manually and individually in Solution Documentation. Usually customers do not follow this approach as it may require a high effort depending the number of executables/process steps/business processes to be considered.

  • Manually during UAT: if Test Suite is in place, it is possible to take advantage of UAT to create and/or update TBOMs as transactions must be manually executed to verify if the process under test was delivered as designed by the business department.

  • Usage of automated test cases: automated tests (TAF) are reused to automatically create and/or update the TBOMs.

  • Background job: if UPL or SCMON data is available, it is possible to trigger a background job to create/update TBOMs in mass for all executables included in a Solution/Branch.

To optimize the BPCA analysis, BPCA offers two additional features: TBOM Filter and TBOM Criticality.

 We will discuss about this in another blog, so keep following us!