cancel
Showing results for 
Search instead for 
Did you mean: 

FF log review dependency on action usage log

Former Member
0 Kudos

Hello experts,

In our SP16 GRC10 install, few cases of FF log instances not initiating workflows (GRACFFLOG) are brought to our notice as the corresponding FF id checkouts are not reviewed by controllers. Also, firefighter checkouts that had a corresponding workflow with approvals show up in the FF Log summary report with empty session details

As we are looking into it, we find that the behavior is reported in several GRC support packs on 10.0, potential reason could be that the FF table GRACFFREPMAPP is not updated accordingly.

Apart from granting additional authority to plug-in system communication user on s_tools_ex object, how do you verify the Action Usage Log job along with the other jobs (FF Log sync and FF workflow update) in GRC are able to update all the necessary FF log tables?

please share your thoughts.

the plug-in system is running SAPK-10507INGRCPINW on NW 731.

Thanks,

Pawan.

Accepted Solutions (0)

Answers (1)

Answers (1)

Former Member
0 Kudos

Hi Pawan,

I have observed that FF log instances not initiating workflows is due to the reason that no activity/transaction was executed by the FF. STAD collects log from CDHDR and CDPOS, and if it does not find any entry(as there were no changes performed), nothing will be updated in GRACFFCHANGELOG. So, no workflow will be created in this case. Controllers can only review, when workflow has sent a request to them.

Regards

plaban

Former Member
0 Kudos

Thanks for your reply Plaban.

the FF log instances in my case had run some activity in the plugin systems.

and more recent FF checkout instances have triggered corresponding FF log review workflows.

so we are waiting for the next instance that does not trigger a workflow.

in the mean time, we are trying to understand what caused the previous checkout instances from not starting workflow. For all those instances, the GRACREPMAPP table does not show any entries that correspond to actions executed, so we are trying to understand what stopped the table population for only few FF checkout instances.

Also, to determine if we should open a message to SAP.

Pawan.

Former Member
0 Kudos

Looks like this issue is a candidate for an SAP message, as I find that the time based EAM log synchronization program is making a call to plug-in system to invoke function 'RSAU_READ_FILE' for Security audit log reads. Audit log reads are only happening on random application server, instead of iterating the call through  all available app servers in the plug-in system.

And when sec audit log is not retrieved and when no other logs (os log, change log, stad log) are found, EAM application does not start the MSMP workflow.

I find similar behavior reported in SAP Note 1723094 - Firefighter's log details missing for multiple app. servers. But it doesn't give a correction note that applies to our plug-in system.

Please share if you experienced the same, or have other thoughts..

Thanks,

Pawan.