Best practice to stop using SA38

[Former Member]

Hi people,

We have a system where we´ve found that many users are using SA38 in order to execute programs. Until now when we face this kind of situations what we´ve done is to identify the programs executed, create a Z transaction of each one and then assign these tcodes to the proper users.It works pretty well but is time consuming.

I wonder wheter this approach is the best one or if there is something else (faster) that can be done. We asked to SAP and the reply confirmed our procedure but I´d like to know you point of view. So, do you have something cool and magic?

Thanks,

Félix

[JonathanM]

Hi Felix,

There is no magic trick...

You should avoid to give SA38 transaction to users in Production (also SE38, SE80, SE37 etc).

Like mentionned, you should give transaction instead.

To gain some time, you should get info from the log. There are some custom reports to get a better view of the workload statistic of the system.

In place of directly creating a Z transcation (for standard programs), you could check in transaction SE93 if there is already one existing. You could also go directly (via TC SE16) to table TSTC and also TSTCP because some programs are started like a parameter (ex: S_AHR_...).

Best regards,

Jonathan

[Frank_Buchholz]

Use the Workload Statistics ST03N to list the reports used in the past and create custom transactions for them in advance. Than you just need to add them to roles.

Hint: ST03N uses one column to show either the transaction name or the report name. If a user starts a report transaction, than you will find the report name only.

This Code Exchange project shows a custom report for reading the ST03N data:

https://cw.sdn.sap.com/cw/groups/how-to-use-workload-statistic-to-optimize-authorizations-for-sap-ab...

Kind regards

Frank

[Former Member]

Thanks for your help. I´ll keep your advises in mind.

Best regards,

Félix

[Former Member]

The approach is correct, but you need a "migration path" to the role menus.

There are some usefull hints in the FAQ -> http://scn.sap.com/thread/791548

Cheers,

Julius

[Former Member]

Dear Felix,

Best solution is create one tcode ZSA38 for SA38 access and ZSA38_TABL table for maintaining the user id, report name and validity ( start date and end date)

The ZSA38 first check the entry in the table for program / report allowed to the user and validity, then it will execute SA38 with that report name.

This is very flexible solution and better to avoid the new role creation for each report.

Regards,

Jayendra

[Former Member]

There are a couple of OK-CODE cases which you might want to comment out if you use the ZSA38 approach...

For example, try TABL or SQ01.

Cheers,

Julius

[Former Member]

Hummm, Javendra your approach looks interesting. If I understand properly, the way that it works is that I just need to maintain a table ZSA38_TABL where I insert one line for every pair user-report. Is roughly correct?

Julius: Could you explain a little bit more your observation?

Thanks,

Félix

[Former Member]

Yes, Felix, one unique record for user id and report. This is very useful for giving access to auditor, they can ask access to any report at anytime, and we cant create transaction code for each report and put them in role and assign it to them.

The above logic delivered the solution which can be only possible by having one role having only one transaction which assoscited to one report. And also we haven't provided SA38 tcode also.

Regards,

Jayendra.

[Former Member]

If you copy SA38 then it still leaves relics behind via OK code commands.

For example it calls itself -> enter 'SA38' as command in the OK-code and hit enter. It calls SQ01 -> 'AQ01' command. It calls SM30 via 'TABL' command. Via 'BTCH' it runs the program entered in the user's parameter ID 'RID' in the background. Etc...

Just as long as you are aware that copying a potentially dangerous SAP transaction and then expecting it to be harmless is still flawed, is what I meant. So one must be careful.

The intended option is to use parameter transactions for START_REPORT, but migrating the users there via a "launchpad" which looks like SA38 (because they insist on it...) can sometimes be useful. I do agree with that.

Cheers,

Julius

[OttoGold]

Hello Jayendra.

Are you aware of the fact that you're suggesting the use of "check-tables" (user-ID based access) instead of authority-checks in a public security forum?

cheers Otto

[Former Member]

Your original question is asking for a best practice approach to stop using SA38 and whilst Jayendra's solution is certainly pragmatic, I don't believe it to be best practice as it is essentially working around the roles/authorisations concept.  It's kind of ironic that you say you provision access to Auditors using this method as it would mean no audit trail of the auditors (unless you have also set up logging).

The following would be my personal recommendations...

In the first instance you should be confirming that there isn't a standard transaction associated with the report.  This can be done either through SE93 as suggested or (ironically) via SE38.  To find transactions associated with a report in SE38 you need to enter the program name and then select the where used option.  From there remove all options except for 'Transactions'.  If nothing is returned then there are no standard transactions for the program.  Something else to note is that if it is a true 'report' then they will not be able to execute it directly via SE38, but will need to call it via START_REPORT as suggested by Julius.

If no transaction exists then the second thing you should be doing is investigating why the program/report doesn't have a transaction associated with it?  Is it an obsolete program, a program that should not be used in a production environment etc.

Then if you do decide that it is required then a Z tcode would certainly be my preferred option.  This also allows you to attach any necessary authorisation objects/values to the tcode.

I think Franc provides some good advice in using system traces in a pro-active manner to determine what programs are required.

[Former Member]

Dear Patrick,

Please read the Felix question properly, he is requesting for how to eliminate SA38 usage for those reports which doesn't have TCODEs, rather than getting lecture from you about how to find TCODE of perticular program / report, even I will suggest you to find the tcode and associated program check in the TSTC table entries, instead se38 n all long story.

Before passing the judgement on others solution and saying its ironic, I suggest you to do some homework about audit log. I hope atleast you have that much common sence.

For your information, my solution also provides information about the name of report / program user executed in the audit log report. Here is the proof.

Regards,

Jayendra.

[ganesh_s7]

Hi Felix,

If this is the scenario in Production, then you may need to understand why the users are doing this.  Is it an Knowledge Gap  OR  are users trying to have more access than they ought to.

SAP best practice and recommnedation is to user Tcodes for access, rather than via programs directly.

Your approach of creating Z t-codes is correct, but this has to be done only after checking that there is no SAP standard Tcode for that Program (SE93).  Sometimes the required program is mapped to a Master Program or known with an alternate name or with prefix. You can check with Developers (ABAP'ers) for the program association.

In my experience, this happens mostly due FC's wanting to subvent standard process (like requesting Firefighter D) & do something directly via reprorts to save time/effort  or  due to knowledge gap.

Hope this helps.

Rgds

Ganesh.S