Do you know that on average 60% of your custom code is in reality not executed in your productive landscape? Especially in SAP Business Suite migration projects like to SAP HANA or SAP S/4HANA such amounts of unused code result in huge adaptation efforts. Therefore SAP’s recommendation is to clean up your unused custom code before migration. But how can you identify the code that is not used?

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. Therefore as a result of the monitoring, you get a list of business transactions (callers) along with all ABAP objects that have been called within these business transactions including the number of calls.

In the example below you can see, that the function module HTTP_GET_HOST was called altogether 50 times and 19 times of it within the transaction SICF, 17 times as remote function call from the FB_AUINT_CLASSTEST_EXTERNAL and so on.

ABAP Call Monitor does not provide any performance data.

You can use the collected data for example, to find all business processes that call  a specific ABAP object (e.g.to identify the business processes affected by code change or deprecation) or to find out which ABAP objects are called by a specific business process.

SAP’s recommendation is to keep the monitor switched on for a certain period of time to get reliable data.

Prerequisites

ABAP Call Monitor is available with AS ABAP 7.50 and for the lower releases (>=7.00) per ST-PI Add-on.

The authorization profile for object S_ADMI_FCD with value SCMD for read access to ABAP Call Monitor data.

The authorization profile for object S_ADMI_FCD with value SCMA for administration activities in the ABAP Call Monitor.

Integration into SAP Solution Manager 7.20

SCMON can be activated in different systems from one single place: SAP Solution Manager 7.20, if these systems are connected to SAP Solution Manager (Solman_Setup -> Custom Code Management).

Generally the Solution Manager 7.20 collects either UPL or SCMON data depending whether the connected system is capable of SCMON or UPL. It is also possible to extract the SCMON data into Solution Manager BW. The data will be stored in day slices and if needed as well in weekly, monthly and yearly aggregation. This will help to keep SCMON data during a long time period in one single place, but still keep the time slices and the respective data small in the original system itself. The existing already collected UPL data get also imported into Solution Manager BW and simply mixed with the new SCMON data.

The SCMON data can then be evaluated for decommissioning of unused objects in the connected systems, using Custom Code Lifecycle Management (CCLM) Decommissioning Cockpit in the Solution Manager. (Sm_Workcenter -> Custom Code Management -> Custom Code Management or CCLM Decomissioning Cockpit). Please consider that usage data are collected from different systems and if an object is not used on one system, but used on the other system, you should not decommission it.

Administrator: Configuring ABAP Call Monitor

System administrator configures SCMON and changes the data collection.

CAUTION:

  • You should never run Usage Procedure Logging (UPL) und SCMON in parallel. This can happen coincidentally for example if you activate UPL via Solution Manager and then SCMON locally in ABAP system.
  • Avoid using SCMON (or UPL) for the systems which already run under maximum load

It is the task of a system administrator to activate or deactivate monitoring with SCMON for the entire ABAP system (all server instances) by using the button Activate and then specifying the configuration settings:

Here you specify the point of time when the monitoring will be deactivated automatically (Scheduled Deactivation) and limit the maximum number of records that are created during monitoring (Record Limit).

The time slices in the ABAP Call Monitor make possible to analyze the progress of monitoring results over time. You then have the option to focus on monitoring data for a specific time interval. For example, you might be interested in those ABAP procedures that call development objects that have been declared as deprecated since a specific point of time (ABAP Call Monitor > Configure Time Slices).

Here you can limit the data records created during monitoring to a specific period of time. The ABAP Call Monitor automatically deletes the monitoring data that has been created before Maximum Number of days.

Usually, the data collection takes automatically place once an hour if the ABAP Call Monitor is active in the system. But you can trigger the data collection explicitly at any point of time (button Collect Data).

If you have finished your monitoring activities and no longer need the corresponding data, you have the option to explicitly delete the collected monitor data (menu ABAP Call Monitor > Delete Data).

Developer: Using ABAP Call Monitor for data analysis

Display and analyze the collected data

The Data Browser of the ABAP Call Monitor allows you to analyze the use/dependency relationship between called objects and calling business processes (button Display Data).

You can also specify the data for selective analysis. For example if you want to get all URLs calling the method TRACE of the class CL_HTTP_SERVER during a specific period of time, you need to specify the following options:

And here is the result example:

If you want to display all ABAP objects that were used (called) by the SE38 transaction within one day you need to specify the following options:

Based on the selection criteria, the ABAP Call Monitor generates a result list of request entry points along with all ABAP objects that have been executed within the selected time interval:

Each entry in the list represents a monitoring data record, which you can drill down for viewing further details. For example Show Time Evolution displays the daily time slices of monitoring data for the selected entry, Show Calling Requests displays the calling requests and Show Called Requests displays the called requests for the selected entry.

Display and analyze the Call Graph

The call graph option allows you to focus on the usage/dependency relationship between requests (button Display Call Graph). For example, if you want to know which objects call the transaction SE38 within a certain period of time, you will need to specify the following options:

And here is the result example:

Display Log

Occasionally, you will need an overview of all monitor activities within a certain period of time (button Display Log).

In the Log Browser screen that appears, you get a list of actions or events – such as activation or deactivation of the call monitor, deletion of records, and collection of data.

 

To report this post you need to login first.

11 Comments

You must be Logged on to comment or reply to a post.

  1. Florian Henninger

    Hi Olga,

     

    thank you for this blog. Did not had a try yet to use it, but is it also possible to have a run, which I say to the settings a maximum for collecting the same object. So the example looks like that:

    I want to know every customer-object, but when a object is called more than 100 times a day I’m sure I need to have a look at it, and I want to have the rest of the trace not filled with the same information over and over again. Got the question?

    ~Florian

     

    (0) 
    1. Olga Dolinskaja Post author

      Hi Florian,

      it is not possible but also not necessary, since only the counter is counted up (per call request), that is, there are not more trace entries created.

      Regards, Olga.

      (1) 
  2. Joachim Rees

    Hi Olga,

    thanks for sharing!

    I recently learned about UPL and that it can be also used without SolMan, via Report /SDF/UPL_CONTROL .

    Now you say that SCMON is better than UPL, so it’s probably a good idea not to dig to deep into UPL, but more into SCMON, right?!

     

    Your initial statement (only 60 % of custom code is actual executed) points towards “we can get rid of a lot of dead code, if we can Identify it.”

    But how do I identify that code? You describe a way vie “Custom Code Lifecycle Management (CCLM) ” in SolMan, but is there also a standalone option (without SolMan) available?

    -> IF SCMON logs everything that is called, it should be easy to also show me parts that have never been called. Is there an option for that, or would I have to try to compile that list manual, somehow?

     

    best

    Joachim

     

    (0) 
    1. Thomas Fiedler

      Hi Joachim,

      if you would like to run an Usage Analysis without SolMan we recommend to use SCMON as this is definetly the better approach because of the entry point information. If you would like to identify code which is not used at all you have to use the SolMan CCLM Tooling. But you are right it looks not so complicated to detect this delta when you have SCMON data in the system. So we think about it to provide this feature in the NW stack as well.

       

      Regards,

      Thomas.

       

      (1) 
      1. Stephan Heinberg

        Hi Thomas,

        yes, please integrate that in NW stack!

        CCLM is a lame duck, destroyed by SAP Sales people, who did not know how to sell Enterprise Support.

        We decided to build our own decommissioning tool based on TADIR minus UPL 365 days.

        Thanks,

        Stephan

         

        (0) 
        1. Thomas Fischer

          Hi Stephan,

          I don’t agree that CCLM is a lame duck. It provides a lot of usefull information which helps to make the wright decision for decommissioning. It was developed in several co-innovation projects with our customers. For example it enriches the usage information from UPL with usage information for includes and transactions. As for example usage of includes is not collected by UPL or SCMON. CCLM calculates automatically usage information for includes based on the references and the usage of the main object(s). This is just one example. CCLM is now used by more than 1000 customers with the main use case to decommission unused objects based as well on information coming from TADIR, PROGDIR, UPL/SCMON, workload statistics and many other sources.

          You might even have a look at the new quality cockpit of CCLM provided with SAP Solution Manager 7.20 which support for example the conversion to S/4HANA.

          But yes, CCLM is not part of standard support.

          Best regards,

          Thomas

           

          (0) 
  3. Stephan Heinberg

    Hi Olga,

     

    why another tool? Could SAP not enhance UPL? What about all the UPL ideas in 2014 (DDIC …)

    Now I have two tools, that have both disadvantaged and should not even run this in parallel.

    Do you have a list of objects that are support in UPL, but are not in SCMON (SmartForms, Adobe Forms, WebDynpro?)

     

    Thanks,

    Stephan

     

    (1) 
      1. Thomas Fiedler

        Hi: Jelena, Stephan.

        you don’t need both tools. SCMON is the replacement for UPL. It comes with new features (entry point) and can be used on the ABAP stack without SolMan. So you can analyse the SCMON results within the ABAP stack.

        Technically it was not possible to enhance the UPL infrastructure with new features. Therefore we decided to replace the UPL with a complete new infrastructure.

        Regards,

        Thomas.

         

        (1) 
  4. Julian Kruetten

    Hi Olga,

    you say that SCMON is available for Systems < 7.50 per ST-PI Add-on.

    I have a System with 7.40 and the latetest ST-PI, but I cannot find the Transaction. Is there a Report maybe?

    Thanks,

    Julian

    (0) 

Leave a Reply