Tracking usage of called transactions in ST03N

[jim_warrington]

We use ST03N history logs to track transactions used by users.

However, it appears that only transactions entered in dialog mode are tracked in ST03N.

Is there a way to enable tracking for the called transactions from common calling transactions such as FBL1N, FBL5N and ME23N?

Thanks,

Jim

[Former Member]

Hi Jim,

If you want to check transactions called in/by non-dialog mode, you need to change the task type as per your requirement in ST03N

[Former Member]

Hi Jim,

Alternatively, you can look at STAD for the transactions executed. STAD is also a best place from where infact SPM (Firefighter) picks up the information on the transaction usage by the Firefighter IDs.

Hope this helps!!

Rgds,

Raghu

[sdipanjan]

  Is there a way to enable tracking for the called transactions from common calling transactions such as FBL1N, FBL5N and ME23N? 

Called Transactions are executed in Dialog sessions / processed by Dialog WP and thus also Dialog Transactions and are available in this list. If you feel the list is not complete then please check the [SAP Note 1074444 ST03N/STAD: Displayed data is incomplete|https://websmp202.sap-ag.de/~form/handler?_APP=01100107900000000342&_EVENT=REDIR&_NNUM=1074444&_NLANG=E].

Regards,

Dipanjan

[jim_warrington]

Running a trace of a document update using transaction FBL5N in STAD continuously displayed a transaction of FBL5N, while the program column changed from RFITEMAR (FBL5N) to SAPMF05L (FB02).

The trace in ST03N only reflected FBL5N for the same activity.

I need the long-term history of transactions to show the patterns of users activities, but I need all of their activities.

[sdipanjan]

Hi,

Did you try checking the SM20 Audit Log for Transaction execution details? ST03N shows the Transaction lists but is mostly for Workload and not logging system activities.

Regards,

Dipanjan

[sdipanjan]

Hi,

Did you try checking the SM20 Audit Log for Transaction execution details? ST03N shows the Transaction lists but is mostly for Workload and not logging system activities.

Regards,

Dipanjan

[Former Member]

then please create your own Zprogram....... refer to RSSTAT* program..........

or refer to table CDHDR for more detail.... (if any changes are done ...... )

regards,

Surpreet

[sdipanjan]

> then please create your own Zprogram....... refer to RSSTAT* program..........

>

> or refer to table CDHDR for more detail.... (if any changes are done ...... )

>

These tables do not have transactional processing details stored. Rather they store the Header Information of changes. Thus not helpful to check such information the OP is looking for. SM20 audit log is the way to be checked and fyi.. it doesn't get stored in tables level..... rather in OS level external files.

Regards,

Dipanjan

[mvoros]

Hi,

are you sure that transition from one program to another is done via transaction call? You wrote that program name has changed but that does not mean that another transaction has been called. Sometimes programs just reuse screen to display additional data from different program. You can run ST01 to see if there is authorization check for S_TCODE. Another way to check this is to switch to debugger and put break point on each CALL TRANSACTION statement (you need new debugger to do this).

Cheers

[jim_warrington]

Martin,

Yes, I had run ST01 for a system trace to confirm. I wanted to confirm that the update did take place.

Dipanjan,

I am really looking for ALL transactions being used/required for the user whether there are actual updates or not.

My query was initiated because the user had lost ability to update a financial document after I removed a role with the transaction FB02 even though the change was done under transaction FBL5N.

I am interested in trying SM20 for this issue, but I have to wait for Basis to change the transaction audit events.

Thanks for your thoughts.

Jim

[Former Member]

Hi

Yes- we also had this problem where (say) FBL5 (or 1) calls FB02 so this is a good question.

Cheers David

[Former Member]

There is an aggregation function in the performance collector jobs. They are not intended for security really - it is more co-incidental but not reliable.

A called transaction does not evaluated the result, as the tocde context is not relevant for what ST03N was built for. The dialog steps and response times is what you see (purely co-insidence --> compare FB0*(N) tcodes for usable, or SA38, GR55, SARA, etc..

The correct tool is Sm19 config and SM20 usage to ALERT, and then use it and various other forensic tools to "drilldown" further - but you need to be fast enough (key word "alert").

Personally, I built a "cockpit" for myself and when something strange happens (you need this "heads up" triggered by various forms of alter functionalities, mostly integrated into Solution Manager diagnostics) then I execute it and it gives me a quick feedback of what's going on.

Specifically for "CALL TRANSACTION" it is release dependent even. See OSS notes on function modude AUTHORITY_CHECK_TCODE for tweaks.

Cheers,

Julius

[mvoros]

Jim,

here is the code which is called to display selected items.

* authority display or change
  perform authority_tcode using 'FB02' subrc.
  if subrc eq 0.
    x_change = 'X'.
  else.
    x_change = space.
  endif.

* leave to ALV:
  call function 'SAPGUI_PROGRESS_INDICATOR'
    exporting
      text = text-009.
  call function 'FI_ITEMS_DISPLAY'
    exporting
      caller_repid  = c_repid_ar
      acctype       = c_koart_ar
....

The routine authority_tcode uses object S_TCODE to check if user has authorization for FB02. Hence you can see this check in ST01. If user has authorization for FB02 then items are displayed in change mode. Therefore your user lost ability to change items after you removed FB02 from his role. And it's as I though it does not use CALL TRANSACTION statement to display/change FI items. It uses CALL DIALOG statement. Therefore you can't see it in stats.

Cheers

[Former Member]

I believe if you know the user ids you can use the table cdhdr and cdpos to populate the details you need, morover you if you just need the tcodes you could filter ithe table on that. Or you could use a combination.

[sdipanjan]

Please check my last post regarding these CDHDR and CDPOS tables and their entries.

regards,

Dipanjan

[Former Member]

Hi Dipanjan

Interesting - some (most) of our suim reports cycle through that cdhdr table sometime to timeout. Is there anything we can do to reduce that please? Changes for role assignment can't be run at all

Cheers

David

Edited by: David Berry on Oct 27, 2010 9:07 PM

[dieter_goedel]

Hello,

in the Security Audit Log (SM19, SM20) you can show transaction or report starts in same way as you can do it in ST03, ST03N or STAD. But in the sample case we do not have a switch of the transaction context, so we can not find such effects there.

What now?

Please try the ST01 authorization trace for your reason. Here you will get the list of all authority checks - also all S_TCODE verifications (By the way from the detail view of an entry you can navigate to the authority check in the ABAP-source).

But please take care to the tracefile - you should have always enough space on the application server file system (use the administration function in ST01 for more details).

Another by the way, I prefer the report RSAU_SELECT_EVENTS to analyze security audit logs, because you can use the compression mode for the where used reporting.

Best regards, Dieter.

[Former Member]

>

>
> Another by the way, I prefer the report RSAU_SELECT_EVENTS to analyze security audit logs, because you can use the compression mode for the where used reporting.
> 
> Best regards, Dieter.

Hi Dieter,

That is a very underused report in my opinion. It addresses a lot of annoyances with the standard log reporting

[jim_warrington]

Thanks Dieter,

I can now confirm that SM20 will only show transaction or report starts after Basis to reconfigured the Security Audit Log.

I will close this question with the question answered in the negative. To summarize:

STAD / ST03N / SM20 / RSAU_SELECT_EVENTS will report transactions started.

ST01 can be used to do a detailed trace of Authorization checks but should be used on an "as needed" basis.

Best regards,

Jim

[mvoros]

Hi,

in my opinion SM20 won't show FB02. The reason is same as for STAD. There is no transaction call. The program uses old method of calling dialog. It won't help in this case.

Cheers