Page tree
Skip to end of metadata
Go to start of metadata

Purpose

Clarify where the action usage data is captured from when running the Action Usage Synchronization job, and how this report is executed in technical details.

Overview

The Action Usage Synchronization job brings all the actions executed by the users in the plugin systems, and stores the information in the GRAC tables to be further processed.

The action usage data also incorporates the execution count information and the alerts data. This job is important and is a pre-requisite for the User Access Review (UAR) workflow feature.


 
 


 

  

 

This report has a particular mechanism wherein it can be executed from two places which will establish distinct logic to handle Users.

  • EAM Log Sync
  • Action Usage Sync


The report has a couple of criteria fields which can be set, and specifically the User criteria will determine what logic/scenario to follow:


User

  • If the Action Usage Sync is called from within the EAM Log Sync job, it restricts the log collection to FFID users only, to fasten the processing times. The mechanism in this scenario will occur in run-time, where the code logic will filter out on FFIDs users that match the remaining report criteria such as Connector, Time Period (in reference to FFID session Logon Time). 
  • If the Action Usage Sync is executed in standalone (documented in Note 2168571), the User criteria must be blank (* symbol is not blank so make sure the field is blank/empty).
  • If the User criteria is filled (not blank), the code will establish the logic for EAM Log Sync scenario. Table GRACMGMTACTUSAGE will not be involved, hence in Risk Analysis and some other reports you will not see Execution Count and Last Executed Date for those users outside the user criteria filled. Only in very specific cases SAP Support engineer may request this report to be run for specific user or set of users, but this is very rare, and should not be done otherwise.
  • Also this way we not utilize packaging, hence it is tryng to retrieve the data in a single pack which will cause dumps in plugin system (so this could be a reason why you are facing dumps also)

Time Period: this parameter is telling the Action Usage Sync, what amount of data shold it retrieve in a single RFC connection. It has nothing to do with the frequency of the job, it just means that how many seconds of data should be retrieved in a single RFC. If the delta between the current timestamp and the last execution time is greater then this value, it will retrieve the data in more RFC calls. For e.g.: we set the time period to 300 sec, and the last execution time was 1 hour 3 minutes 2 seconds ago (=63 minutes 2 second = 3782 seconds). This means we will start 13 RFC calls sequently to the plugin system, and in both RFC calls we will retrieve 300 seconds of data (in the last one it will 178 seconds). In this way we can decrease the required memory and time to process in the plugin system, but we have more RFC calls which will lengthen the overal execution of the job.

Retention period: time how long we store data in GRACACTTRANS table, every data which is older then the actual timestamp minus this amount of seconds will be deteleted from this table. This should be set according to the retention period of STAD. GRACACTTRANS table is a self maintaining table wich stores the Transaction ID’s of the dialog steps. Due to STAD is storing the data for two days, ideally the Transaction ID’s will not be repeated after 3 or 4 days . This is why we set it in default 5 days of interval. We use GRACACTTRANS table to crosscheck with those action that are alredy stored (by storing the transaction ID which is the unique ID of a single transaction for longer time).




This WIKI will describe each scenario as follows.


Scenario 1 - When User field is NOT populated

Below is the technical overview of what the report does, when the User field is initial (left blank).

The report:

1) Gets current date time stamp

2) Selects all users for the specified connector(s) from table GRACMGMTACTUSAGE to get the action execution counts.

3) Gets the last execution date time from table GRACTASKEXECSTMP for the specified connector(s), where Task name is equal to
ACTION_USAGE_SYNC. If first time the job is running, the last execution will be assigned to initial date and time of 1970-01-01 00:00:00.

4) Calculates the number of hours to read back the action usage information. This is calculated by taking current system date and time minus last execution date time captured in step 3).

5) Reads the action log via RFC call:

For each specified connector, the report loops through the list of application servers available for that connector (system), and reads the action usage available in STAD that falls within the calculated time frame (according to the number of hours calculated initially to be read back in time).

6) Inserts the new action usage into table GRACACTUSAGE.

7) Updates the Alert action data into table GRACALACTLOG.

8) Updates the action execution counts into table GRACMGMTACTUSAGE, for the unique combination of conector + user + action.

Scenario 2 - When Action Usage Sync is executed from EAM Log Sync

Whenever the report is called from within the EAM Log Sync job, the User field will be transparently populated (during runtime) with all firefighter IDs from table GRACFFLOG that satisfy the report criteria for connector and Time Period (based on "logon time" which is the time frame explained in step 3 of Scenario 2). This is to restrict the log collection to these users and to fasten the Action Usage Sync overall processing time.

Below is a technical overview of what the report does, when the User field is specified.

The report:

1) Gets current date time stamp

2) Does not select users for the specified connector(s) from table GRACMGMTACTUSAGE to get the action execution counts. This step is bypassed.

3) Gets the last execution date time from table GRACTASKEXECSTMP for the specified connector(s), where Task name is equal to
SPM_ACTION_USAGE. If first time the job is running, the last execution will be assigned to initial date and time of 1970-01-01 00:00:00.

4) Syncs the Firefighter session logs, for the specified connector(s), in other words, updates the Firefighter session log from the plug-in systems in the GRC Repository. This is done by assigning current system date and time to column "Logoff_Time", and assigning 'X' to column "Data_sync", in table /GRCPI/GRIAFFLOG.

5) Does not calculate the number of hours to read back the action usage information. This step is bypassed.

6) Inserts an entry in table GRACTASKEXECSTMP for each specified connector, with Task name equals to SPM_ACT_USAGE_NEW. This is only done in this scenario.

7) Selects all entries from table GRACACTUSAGE for the specified connector(s), for the specified user(s), where action usage execution date and time is between current system date and time and last execution date time captured in step 3). This is only done in this scenario.

This initial select is used to improve performance later in step 9), when only new action usage data will be inserted, comparing to existing action usage data, for the specified user(s).

8) Reads the action log via RFC call:

For each specified connector, the report loops through the list of application servers available for that connector (system), and reads the action usage available in STAD that falls within the calculated time frame (according to the number of hours calculated initially to be read back in time), for the specified user(s).

9) Inserts the new action usage into table GRACACTUSAGE. This step is bypassed.

10) Updates the Alert action data into table GRACALACTLOG.

11) Does not update the action execution counts into table GRACMGMTACTUSAGE.

Related Content

Related Documents

Related Notes

SAP Note 1704699: GRAC_ACTION_USAGE_SYNC job is taking long time to complete
SAP Note 1716500: GRC Action Usage Synch job is not indicating completion
SAP Note 1702180: Action Usage report is generating duplicate entries
SAP Note 1715597: Performance issue with action usage report
SAP Note 1697692: Action usage sync results in TSV_TNEW_PAGE_ALLOC_FAILED
SAP Note 1700811: Scheduling the action usage full sync job
SAP Note 1773446: Action usage is showing wrong execution count

  • No labels

8 Comments

  1. Former Member

    Very well explained thanks for sharing this information

  2. Former Member

    Hello,

    Has anyone experienced an issue where teh system did NOT bring in historic data beyond the day the usage job was run.

    I see lots of notes on long run times, but when we scheduled our jobs for the first time, they only broght back the data for 'today'

    I have raised an OSS note, but any thouhgts / similiar experiences would be appreciated.

    Thanks

    Peter

    1. Former Member

      Hello Peter,

       

      Did you hear from SAP?I have similar issue.

       

      We are getting the Action usage data only from certain period.Data before specific date is not shown.

       

      Regards,

      Lakshmi.

       

       

      1. Former Member

        Hi Lakshmi,

        The answer to this was that the action usage only uses the STAT data not the STAD data. STAT data is by default only kept for 48 hours (if I recall) STAD data while it is kept for default of 3 months in summarised form cannot be imported into GRC.

        In the call we had with SAP they said it would not be possible to bring the STAD data into GRC due the complexity of such a change. As such switch on your jobs as soon as possible and let the data build up so that it becomes meaningful.

         

        Peter

        1. Former Member

          Hello Peter,

          Thanks for the quick reply.

          In my case, we had the ACTION Usage sync job running once for every 24 hours.

          Also when we have executed the report sometime in June 2014 back we have got the date before June 2014.But now the data is coming only from June 2014.

          Should I suspect , my DB team has deleted some data in the table : GRACACTUSAGE??I am afriad.

          Regards,

          Lakshmi

           

           

          1. Hi Lakshmi,

            Could you please advise if you got something on this? Please advise what is the impact onTransaction log and session details report if data has been deleted from GRACACTUSAGE table.

             We are not able to find some data in Transaction log and session details report (which was available earlier) in GRC and we know that DB team has deleted logs from GRACACTUSAGE table so I believe this could be the issue.

            Could you please advise if you got any information on that. 

  3. Former Member

    Hi guys quick question, we have currently an issue that GRAC action usage is not reporting correctly once we run user risk analysis. Looked at note 1773446 but this is for 10 we are currently on 10.1 SP6.

    Any advise?

    thx

    pedro