Guys, I searched internet over and over but could not find anything on this new trace tcode released by SAP. Hence writing this post.
STUSOBTARCE is a new tracing TCODE which is used internally in SAP during the development to determine the authorization default values used for transactions, RFCs and services used. Usually, this trace is switched “ON” for a longer period than ST01 or STAUTHTRACE. It captures authorization checks once per application and code location independent of user and client. SAP advises permanent activation of this trace. This is how the trace evaluation looks like:
Activation of this trace requires a parameter to be set in RZ10 in DEFAULT.PFL profile, which obviously need a system restart. Luckily, this parameter is a dynamic parameter hence can be set in RZ11 as well. But once the system is restarted the parameter will again be set to the one maintained in RZ10 DEFAULT.PFL profile. The parameter is auth/authorization_trace and below are the possible values:
Y: This value will set the parameter to ACTIVE and all the actions (Unique auth checks) will be recorded for Transactions, RFCs, external/internal services etc.
N: Inactive.
F: This value will activate the trace with filters. But we need to maintain at least one filter. We can maintain Auth objects or users in filter criteria.
Few examples to understand how STUSOBTRACE works:
Use Case: We have a stable prod environment, and nobody uses S_DEVELOP DEBUG 02, not even with FFID. But still it was in the broader access roles which were assigned to Batch User IDs and pointed out in SOS report. Everybody was convinced to remove but the management did not want to take any risk of failing jobs if any. So, we concluded to activate USOBTRACE for S_DEVELOP in system for 3-6 months, and act accordingly. We could have activated ST01 trace for those IDs, but the amount of data that will be captured and stored will pose a performance/storage issue, hence we opted for this option.
In Conclusion, so be it ACTIVE with filters or without filters, it will capture only unique authorization checks. This trace can be used to conclude all the checks by TCODES or RFCs being used in the system while the system is still in design phase. Whereas cannot be used for troubleshooting access issues. SAP recommends keeping this trace active permanently.
References: SAP Notes 1854561, 543164
STUSOBTARCE is a new tracing TCODE which is used internally in SAP during the development to determine the authorization default values used for transactions, RFCs and services used. Usually, this trace is switched “ON” for a longer period than ST01 or STAUTHTRACE. It captures authorization checks once per application and code location independent of user and client. SAP advises permanent activation of this trace. This is how the trace evaluation looks like:
Activation of this trace requires a parameter to be set in RZ10 in DEFAULT.PFL profile, which obviously need a system restart. Luckily, this parameter is a dynamic parameter hence can be set in RZ11 as well. But once the system is restarted the parameter will again be set to the one maintained in RZ10 DEFAULT.PFL profile. The parameter is auth/authorization_trace and below are the possible values:
Y: This value will set the parameter to ACTIVE and all the actions (Unique auth checks) will be recorded for Transactions, RFCs, external/internal services etc.
N: Inactive.
F: This value will activate the trace with filters. But we need to maintain at least one filter. We can maintain Auth objects or users in filter criteria.
Few examples to understand how STUSOBTRACE works:
- The trace is ACTIVE with no filters. User1 executes TCODE SE16N and access table AGR_1251. The activity is recorded as highlighted record in yellow. Immediately after that User2 executes the same TCODE and accesses the same table. But it won’t capture the one from User2. And the record will still be under User1 in table.
- The trace is ACTIVE with Filters. The trace was activated for User1, User2 and for S_TABU_DIS and S_TABU_NAM objects. User1 ran SE16N and viewed table USR02 and then after that User2 accesses the same table. The trace was captured only once for User1 and was not overwritten.
Use Case: We have a stable prod environment, and nobody uses S_DEVELOP DEBUG 02, not even with FFID. But still it was in the broader access roles which were assigned to Batch User IDs and pointed out in SOS report. Everybody was convinced to remove but the management did not want to take any risk of failing jobs if any. So, we concluded to activate USOBTRACE for S_DEVELOP in system for 3-6 months, and act accordingly. We could have activated ST01 trace for those IDs, but the amount of data that will be captured and stored will pose a performance/storage issue, hence we opted for this option.
In Conclusion, so be it ACTIVE with filters or without filters, it will capture only unique authorization checks. This trace can be used to conclude all the checks by TCODES or RFCs being used in the system while the system is still in design phase. Whereas cannot be used for troubleshooting access issues. SAP recommends keeping this trace active permanently.
References: SAP Notes 1854561, 543164
- SAP Managed Tags:
3 Comments
| User | Count |
|---|---|
| 5 | |
| 4 | |
| 3 | |
| 2 | |
| 2 | |
| 2 | |
| 2 | |
| 2 | |
| 1 | |
| 1 |
