GRC 10.1 - Some workflow are not sent to controller for firefighter usage

[Former Member]

Hi All - We are using GRC 10.1 (SP 6) and implemented workflow for firefighter activity (EAM module) but we are facing one issue with workflow.

We are observing for some firefighter usage workflow is not sent to controller (around 5-10 % of total FF usage).

(In GRCFFLOG table , WORKFLOW_SENT column is blank for some case).

What could be the possible reason and solution ?

I welcome your any comment or thought 

[alessandr0 · Accepted solution]

Dear Rajesh,

usually this happens due to empty firefighter logs. SAP has therefore implemented a new parameter 4020 (with SP7). I recommend to implement the following SAP note:

http://service.sap.com/sap/support/notes/2017105

Hope this helps.

Regards,

Alessandro

[Former Member · Accepted solution]

Thanks Alessandro for your help !!!

Could you please also advice on the below

1. We have some case where firefighter log is not empty (we checked the activity manually via CDHDR table & FF consolidated log) but still FF log is not sent. (screenshot is attached)

2. Do we need to upgrade to SP7 to implement this note  Or can we apply it on SP6 as well ?

[kevin_tucholke1 · Accepted solution]

Rajesh:

1.  You can use the EAM Timebased abap to help recreate any unsent workflows.  Did you also look in the GRRACACTUSAGE table for transactions executed for the logs you see?

2.  No, you can apply SAP Notes on lower SP levels, you may have some dependent notes to implement as well, but SNOTE will determine that for you.

Thanks.

Kevin Tucholke

[alessandr0 · Accepted solution]

as a further advice I also recommend to check the authorization of the RFC user in the backend system. I have had similar issues at a client where the RFC user missed authorization and couldn't retrieve the logs properly (it worked sometimes, but not always.. was a strange issue). Anyway, you need to check S_ADMIN_FCD and S_TOOLS_EX. Best to run an authorization trace via SAUTHTRACE.

As Kevin has mentioned you can try to regenerate the workflows with program GRAC_EAM_LOG_SYNC_TIMEBASED.

Hope this helps.

Regards,

Alessandro

[Former Member · Accepted solution]

Hi Kevin - Thanks for your advice .

Yes . the table GRRACACTUSAGE shows the logs for FFID session for which log was not sent.

1. Thanks to let me know the program  GRAC_EAM_LOG_SYNC_TIMEBASED  but its not updating the workflow status in GRACFFLOG table.  (Doest it update the the table as well ?)

2. Also in GRACFFLOG table I see the  time stamp for "updated at" is later than the log off date . Screenshot attached. Any advice please ?

3. Also can we change the time stamp in better format . currently time stamp is coming up in format 20.160.105.113.421

[alessandr0 · Accepted solution]

Rajesh,

just copy & paste from GRACFFLOG. Use the Logon time and Logoff time and just copy and paste the timestamps. The program will update the GRACFFLOG table as well. If the update at is given, you can rerun the program to retrieve missing logs and update them. It is also possible to regenerate the workflow once again.

Regards,

Alessandro

[premb · Accepted solution]

please make sure all the timestamps ( Datebase, Kernel, ABAP-Processor, Localtime ) are in sync.Yo ucan check by using the report program "RSDBTIME" to see the current times.

Thanks

Prem

[Former Member · Accepted solution]

Hi Alessandro - Thanks for your comment.

1. We are using trusted RFC in our landscape , that's mean the FFID access is getting checked while connection with ECC system ( We are using centralized FFID ) . I also traced FFID but didn't found any issue yet.

2. Could you please also advice on the time stamp issue :

-  In GRACFFLOG table we see the timestamp at "Updated at" column is later than "Log off time" . Screenshot attached . How updated at is later than log off date .

-  Is there any way to change the format of time stamp . currently time stamp is showing as 20.160.105.113.421 . We want to change this in better format e.g DD MM YYYY  HH:MM:SS

[Former Member · Accepted solution]

Thanks for your comment . But all time are already in sync.   Any other clue  ?

[Former Member · Accepted solution]

Hi,

GRAC_EAM_LOG_SYNC_TIMEBASED can be a bit tricky until you get the hang of using it.

Have you implemented the note for it? 1934127 if not, have the note implemented fully to make using the program easier (the field names are "human readable".) there is also a Word document attached to this note to help with using GRAC_EAM_LOG_SYNC_TIMEBASED

When you run it do you have the check box for send workflow active?

If not, no workflow will be sent it will just give you an informational message:

If so, rerun with the generate workflow mode checked (if one shows as being affected) and you should get a workflow to generate with your user ID as the creator in the log on the date you ran GRAC_EAM_LOG_SYNC_TIMEBASED update not the date of the FFID usage.

Also these notes are helpful if time frame of FFID usage is an issue:

2143380 - AC10.1 EAM consolidated report failed to show session details

2187377 - AC 10.X - De-Centralized SPM causing discrepancies in the log report and workflow notifications

2077307 – Transaction log execution time incorrect

2112934 – EAM Audit Log workflow becomes invalid after providing additional information and EAM logs are missing from Log reports

As for the date format as with all things SAP I have no idea why they chose this particular format (other than to make things difficult). So I wrote an Excel formula to convert it so, I can read it faster. 

You may have to learn how much your target systems differ from the GRC +/- GMT and account for this in your calculations when running GRAC_EAM_LOG_SYNC_TIMEBASED (not sure if Prem Balraj’s response about time sync program RSDBTIME would overcome this issue if it does I would love to know about it.)

“=CONCATENATE(LEFT(RIGHT(C4,10),2),"/",LEFT(RIGHT(C4,8),2),"/",LEFT(C4,4), " ",LEFT(RIGHT(C4,6),2),":",LEFT(RIGHT(C4,4),2),":",RIGHT(C4,2))”

Drew