Skip to Content

An old dog tries new tricks – CCMS II / ADM107 – Addendum 2: CPH 02-Jun-2008

Previously, I shared what I learned in the ADM107 class and how we we applying these lessons
to our enterprise systems. As the teams face other challenges on the way, the completion of
our initial goal of a set of business transaction metrics remains elusive.


An old dog learning new tricks – SAP education course ADM107 – Day 1 (of 2)

An old dog learning new tricks – SAP education course ADM107 – Day 2 (of 2)

An old dog tries new tricks – CCMS II / ADM107 – Addendum 1

    As mentioned in prior blogs, Dieter Krieger has tried to help us, since before SAP TechEd 2007.  After we got stuck with our latest challenge, monitoring transaction specific response times, he agreed to have a web meeting.  Due to scheduling conflicts on both sides of the Atlantic, it was several weeks before we could all meet virtually.

    On June 2nd, we got time on Dieter’s calendar for knowledge transfer, debugging, and road map planning.  Next time I think I’ll ask if we can record him, perhaps for some E-learning.

    Below is the chronology of our progress, with events both before and after our chat: 

    h4. 08:33

    Before getting started, there were remnants of prior attempts to set up monitoring.
    Values are visible in the RZ20 monitoring tree hierarchy, but no data were being collected.



    The database table ALTRAMONI had 1 row.



    At 09:27, we added 1 row to ALTRAMONI as follows:

    Transaction RZ23N, then
    Extended, then
    Extended CPH Settings


    h4. Online Help

    Dieter said to search
    for ALTRAMONI,
    which produced 2 pages:

    Transaction-Specific Dialog Monitor




    As we couldn’t wait for the next data cycle, we forced a run with:
    on the central system.

    h4. 09:39


    We also triggered:
    on the satellite system,
    which moves data? (Dieter, little help here again please?)


    After verifying data is now being collected on the source/satellite system, we looked at the target/central system.

    SM37 (Job Overview) on the central system shows the PFDB (performance database) job only ran when we forced it:

    SAP_CCMS_PFDB_COUP_DEV JSPATH Finished 06/02/2008 09:51:27 8 0
    SAP_CCMS_PFDB_COUP_DEV JSPATH Finished 06/02/2008 09:52:54 1 0
    SAP_CCMS_PFDB_COUP_DEV JSPATH Finished 06/02/2008 09:53:11 2 0
    SAP_CCMS_PFDB_COUP_DEV JSPATH Finished 06/02/2008 09:53:28 2 0
    SAP_CCMS_PFDB_COUP_DEV JSPATH Finished 06/02/2008 09:54:03 1 0
    SAP_CCMS_PFDB_COUP_DEV JSPATH Finished 06/02/2008 09:54:21 1 0

    There was a tangential discussion on how to set up the central system so we don’t need to configure each satellite system.
    We didn’t totally understand what Dieter said, so we need to follow up as to whether this is practical, desirable, necessary, or even possible.

    h4. 09:55


    Houston, we have data!




    The times are off (seem to be showing GMT, not local time), and as of yet, no records have appeared beyond the 10:00 time, but there is data in the CPH system!



    Later, I added a transaction I’m more familiar with (ST10 – table buffer performance).  This will help in determining the match between when transactions occur, when they are moved to the CPH, and when the CPH shows they happened.

    h4. 13:30

    I also decreased the time between collections.


    Here’s what ALTRAMONI has now.

    </p>h4. 13:36


    The MTE Focus Groups

    We had difficulty identifying the monitoring tree element that would initiate transaction specific monitoring, so we picked several that had the term “Focus” in them.  Dieters tip was to use the search function, as scrolling through the list was not showing us what we needed.  I don’t think assigning extra mappings will have any negative effect.

    !/weblogs/images/251822835/ContextR3DialogFocus.png|alt=|src=/weblogs/images/251822835/ContextR3DialogFocus.png! !/weblogs/images/251822835/R3DialogFocusClient.png|alt=|src=/weblogs/images/251822835/R3DialogFocusClient.png! !/weblogs/images/251822835/R3DialogFocusClientTransaction.png|alt=|src=/weblogs/images/251822835/R3DialogFocusClientTransaction.png!
    !/weblogs/images/251822835/R3DialogFocusDbRequestTime.png|alt=|src=/weblogs/images/251822835/R3DialogFocusDbRequestTime.png! !/weblogs/images/251822835/R3FocusDialogResponseTime.png|alt=|src=/weblogs/images/251822835/R3FocusDialogResponseTime.png!

    To help search engines later, here are the focus tokens:

      1. ContextR3DialogFocus
      2. R3DialogFocusClient
      3. R3DialogFocusClientTransaction
      4. R3DialogFocusDbRequestTime
      5. R3FocusDialogResponseTime

    h2. Next steps

    We’ve added the currently-defined critical business transactions to another development system to see if all will be collected after insertion into the ALTRAMONI table.

    We’re planning to add more than 10 transactions into another system to see what happens to number 11.

    We will research the collection and transfer jobs, with the goal of putting these in our enterprise job scheduling system, so that we can better control and monitor the collection time, run frequency, and measurement duration.


    1 Comment
    You must be Logged on to comment or reply to a post.
    • Hi Jim,
      thanks for you blog.
      Basically, you enter critical transaction codes in ALTRAMONI on each of your monitored system, wherever appropriate.
      Response times are read centrally by a method called CCMS_UpdateDialogFocusMonitoring (see method definitions in RZ21), which is centrally triggered by SAPMSSY8 once in 5 minutes. You can trigger this manually by executing SAPMSSY8 (which calls all short-running methods) in SE38 or by calling the relevant function module individually. The method call updates your self-defined central transaction-specific monitor with data from the monitored systems. For details on how you define your own monitor in your central system, see the section “Creating a monitor with the response times of the monitored transactions/clients” in the documentation mentioned above.
      The collected transaction response times will appear in your monitor.
      You can then make appropriate assignments for the CPH to make the transaction response times persistent in the central database for reporting purposes. Note that time zone conversion can be defined in the collection and reorg schema of CPH.
      The data to be stored in the CPH is collected by background jobs with standard intervals, which you can change as you described in the blog.
      I hope this makes it clearer.