Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
Showing results for 
Search instead for 
Did you mean: 

This blog serves as a quick introduction to BPCA, but mainly to aims to provide the required knowledge and information about the SCMON Semi-Dynamic TBOMs for SAP Fiori Apps, its prerequisites, limitations and capabilities 

Working with BPCA & SEA enables the users to analyze and forecast the required testing effort for new changes in enhancement packages, support packages, or even customer developments that may impact business processes. 

This is done through BPCA functionalities where the objects in a transport are compared against the TBOMs in the managed system.   

The BPCA can get an object list for business functions, as well as objects in transport, and compares this object list with the objects in TBOMs. Since every TBOM is assigned to an executable entity in a scenario, business process, or process step, you can determine which parts of a solution documentation are affected by any changes. To be able to use the BPCA, make requisite preparations in your system. Record the TBOMS and apply filter and criticality settings. 

Please note the following requisite preparations: 

  • Assign executables to the solution documentation. 

  • Create a list of objects TBOM for every executable entity. 

  • Define test cases for the solution documentation. 

  • This process guides you through the required steps. 

For more information, see Business Process Change Analyzer (BPCA). 

What is a TBOM? 

A TBOM is a list that contains all objects in an executable entity. These objects could be classes, UI elements, FM and tables. 

For more information please visit the official website here. 

TBOM could be created dynamically, statically, or semi-dynamically depending on the use case.  

  • Dynamic TBOM: They are considered the most precise. They can be generated manually by recording a transaction while it is being executed. All objects that were used in this execution are captured in the background and copied to the TBOM content. 

The recorded/created dynamic TBOM will be attached to the executable position (e.g.:  process level, process step level, it depends on where the executable exists and where the recording is executed). 

you can find more details regarding Dynamic TBOMS here.   

  • Semi Dynamic TBOM: 

Semi-dynamic TBOMs are created in mass fashion using background job in BPCA. They are more accurate that the static TBOMs as they are based on usage data (SCMON/UPL) in the production system. The created Semi Dynamic TBOM will be created and attached to the executable in the executable's library, this TBOM will be referenced/inherited in all process steps/processes where this executable exists.  

Check the attached screenshot to see the data flow for Semi Dynamic TBOMs generation. 

you can find more details regarding Semi Dynamic TBOM here. 


  • Static TBOMs, which are based on ABAP trace data. They were the first developed TBOMs type. 

Static TBOMs are also mass generated like the Semi Dynamic TBOMs, however, the Static TBOMs don’t use and usage data, so no authorizations for the managed system are required. The dynamic calls or generated objects are not detected so they are not part of the static TBOM. Therefore, the result is not as good as Semi Dynamic TBOMs or Dynamic TBOMs. 

you can find more details regarding Static TBOM here. 


NOTE: Static and semi-dynamic TBOMs do not support SAP Web Link (SAP_LONG_URL) applications (the URL of a portal, for example, which are used to start an SAP application in an ABAP application server). In this case, create dynamic TBOMs.. 


What is SCMON Data?  

The purpose of the ABAP Call Monitor (transaction SCMON) is to monitor the execution (usage) of ABAP code (function modules, method calls etc.) in your productive system.  

 The advantage of the SCMON compared to the UPL (Usage Procedure Logging in SAP Solution Manager) is that using this tool, you not only collect the usage data (how often a specific ABAP object was called), but also the information about the calling business process.  

 Since SCMON comes along with an enhanced functionality scope compared with UPL, you can consider SCMON as a successor and use it instead of UPL. 

For more information, please check the blog here. 


What is SAP Fiori? 

SAP Fiori is the main concepts/guidelines  used to design SAP applications.

It does not address only the UI design but it is concerned with the whole User Experience (UX).

It aims to provide role based applications, to enable the end users best experience possible using the app. For more information related to SAP Fiori please visit the provided links 1,2,3


What is ODATA? 

OData is an Open Data Protocol used in web technologies. OData is used by SAP to make SAP data accessible to other platforms so that the non-SAP users can also access this data to develop web applications, websites, mobile apps, etc. 

For more interesting information regarding ODATA you can check the following blog here .


Problem Description  

For the Executables of type SAP Fiori application, only dynamic TBOMs through manual activities or automated test cases were allowed. 

The creation of semi-dynamic TBOMs for Executable of type SAP Fiori application was not possible for the following reasons: 

  • Firstly, there was a missing relation between the Executable of type SAP Fiori application attributes, Solution Documentation & and the used API to send data to BPCA.  

This problem is solved from SP14. Among other enhancements, a new table was introduced, and it delivers the required relation between solution documentation, BPCA, and the attributes of the SAP Fiori applications. 

For more information regarding SP14, please check the following blog.  

  • Secondly, from SP15, it also became possible to download the information of Executable type SAP Fiori Application from a managed system and upload it in the SAP Solution Manager system, for more information regarding what is new in SP15 please check the blog here. 

  • Finally, it was not possible to use the SCMON data that was being generated because it included only the ODATA service name, and we did not have a connection between the ODATA service name and to which SAP Fiori App it is referring.  no other information regarding the SAP Fiori app behind it. So, it was not possible to retrieve additional information or attributes of the executable type Fiori (Fiori ID, Action. Object) 

In the screenshot below, you can see the above-mentioned SOLDOC table, that contains the SAP Fiori apps attributes: Fiori ID, Semantic Object, Action & ODATA service, and more. 


The Change Impact Analysis app is extended to enable the SCMON semi-dynamic TBOMs for SAP Fiori apps (with ODATA service). 

The new logic extracts the semantic object and action from executable ID (as the executable defined in SOLDOC)  

Check the screenshot to see how an executable of type Fiori looks in Solution Documentation. 


Then we use this information to retrieve the OData service name from Solution Documentation Database table. 

Then we use the extracted ODATA service name to search in the SCMON roots. 

The ODATA service name is now delivered, therefore, a regular expression is built. This expression is then used to search and identify related usage data in the available SCMON data. 

The found entries are carried out to the next step in the standard pipeline of semi-dynamic TBOM creation. 

This strongly depends on the available SCMON data in the chosen date range 



 For the new functionality to work, some pre-configurations are mandatory. 


 SCMON Usage Data Activation  

To create SCMON semi–dynamic TBOMs for all executables, not only SAP Fiori apps, this step must also be followed. 

SCMON usage data generation must be activated in the managed system. 

In transaction SOLMAN_SETUP, pre-configuration is required to import SCMON data from managed system to the SAP Solution Manager system. 

For more information, please read the following blog. 


SAP Fiori Apps Reference Library Import: 

For more information, please check the following blog. 

From SAP S/4HANA 2020 onwards, you can use the launchpad content aggregator (SAP GUI transaction /n/UI2/FLPCA) to get an overview of all configured SAP Fiori apps in your managed system and client. 


Use a custom layout to show all relevant SAP Fiori app data. 


It is mandatory to provide data of the SAP Fiori apps either through importing data from the managed system or from the SAP Fiori apps reference library. 

To get the data from managed system, from SAP S/4HANA 2020, it is possible to use the launchpad content aggregator (SAP GUI transaction /UI2/FLPCA) to get an overview of all configured SAP Fiori apps in your managed system and client.  

As an alternative, the SAP Fiori apps reference library provides a list of all available SAP Fiori apps for a specific SAP Product and version (e.g. SAP S/4HANA 2020). This data is SAP-generic and does not reflect any specific configuration of SAP Fiori apps in the customer system landscape. 

The following data is required for each SAP Fiori app: Fiori ID, primary OData service, semantic object and action, the application component, and the title. 

With this function, you can import SAP Fiori app data from the managed system or SAP Fiori apps reference library into SP Solution Manager 7.2. 


Do the following: 


First, go to Solution Administration and open the Service Activities → Manage SAP Fiori application data as the screenshot below illustrates. 

Then, based on your use case/scenario, you chose the import source. 

If you have already maintained your SAP Fiori apps in your managed system landscape, you can import them from the managed system. 

If you are not sure if you have the complete list of used SAP Fiori apps, then the import source should be SAP Fiori apps reference library. 

In the first screenshot below, the chosen source is the managed system. The procedures must be followed carefully to create the relevant import file.  

In the second screenshot below, the chosen source is the SAP Fiori apps reference library. 

Different producers are described. Those steps must be followed to correctly create a relevant import file.   

After a successful upload, the SAP Fiori data is ready to be used for executable library generation and for value help. More importantly, the SOLDOC table will be filled with SAP Fiori apps and their related data. 

Library Generation  

The idea of this step is to retrieve all used executables information from the managed system to solution manger system. To enable the usage of those executables in the solution documentation application. This part is explained in details in official SAP Help Portal here. 

 Open the Library Generation Cockpit 

In Solution Administration, in the Global Functions menu, you can use the Library Generation Cockpit entry to open the library generation cockpit for the selected solution, and then follow the steps mentioned in the link above . 





During our testing and analysis phase, we observed the following limitations: 

  • In case the same ODATA service, Semantic Object & Action are used in several SAP Fiori apps, it won’t be possible to create semi-dynamic TBOMs. 

This is because the SMUD_USAGE_FIORI table hides the SAP Fiori apps that use the same OData service; hence we can’t extract the additional SAP Fiori information. 

  • If there are truncated URLs in SCMON DATA where the ODATA service name is not complete, these calls are ignored, hence the semi-dynamic TBOM quality could be affected. This limitation is due to the character length restrictions in the SCMON table (only 60 characters are allowed). Moreover, the overflow happens at the biggening of the URL, not at the end, which might cause an entry where the ODATA service name is not complete. 

This impact on quality of the created TBOM varies from critical to almost no effect at all. It depends on the quality and quantity of SCMON data generated in your production environment.  

In the screenshot below, you can see an example of an extremally truncated ODATA service name, where it is not possible to identify from which SAP Fiori App it is coming. 

The entry is highlighted. 


  • This feature is unfortunately not available for all SAP Fiori applications in the SAP reference library. The new logic only works for the SAP Fiori applications that use an ODATA service (about 2900 applications which represent around only 19% of the whole SAP Fiori library).

For the other SAP Fiori apps (mainly based on transactions) it is not possible yet to directly create a semi-dynamic TBOM for those.

However, as a workaround, the end user should find out which transaction stands behind the SAP Fiori app currently being executed, add this transaction to the SOLDOC, and then generate a semi dynamic TBOM for this executable.


Summary & Key Take aways

This feature could be considered as the first step towards the enablement of Semi Dynamic TBOMs for SAP Fiori applications. However, now the generation of Semi Dynamic TBOMs for SAP Fiori Applications is working only with limited set of the SAP Fiori Apps Reference Library (only SAP Fiori Applications that use ODATA service). This due to the limitations that we discussed through this blog.