Restrict users to change value in user id field in SM36

[Former Member]

Hi,

Our users are currently given authorization objects S_BTCH_NAM, S_BTCH_ADM and S_TCH_JOB in order to be able create background jobs and execute using batch admin userid, and not under their own userid.

I like to know is there way to restrict users to execute transaction SM35, SM36, SM37 to create a job under another person's userid.

I am looking at grey off the userid field in SM35, SM36, SM37 when users execute these t-code in online mode. I want to restrict them from schedule job to run under another person userid.

However, if users perform a transaction and call a customised program to create a batch job in background to be executed under batch_admin userid, without failing the job.

How can it be achieved? Does SAP allows configuration to grey off userid field?

[Former Member]

Hi,

S_BTCH_ADM controls this. Set this option to N, which will restrict users from creating a job step with another user name.

Rgds,

Raghu

[Former Member]

Hi Raghu, thanks for your quick response.

We still want the user to be able to create job under another person userid if it is event dependent which triggered by our customized program after user perform a transaction eg a MIGO good issue.

We only want to restrict users if they are to manual key in t-code SM36 to create job under other person user id.

[Former Member]

Hi,

We still want the user to be able to create job under another person userid if it is event dependent which triggered by our customized program after user perform a transaction eg a MIGO good issue.

What is the customized program about. If you are triggering jobs from a customized program, you must be using a communication user. Create a role with S_BTCH_ADM with Y, so that it allows your program to still schedule background jobs with other names.

For the role that you assign to the user, ensure that it is set to N, so that his access will be limited to scheduling jobs under his name.

Hope this solves

Happy new year!!

Regards,

Raghu

[Former Member]

In this case, keep S_BTCH_ADM = N for your users and have the custom program code modified so that it schedules a background job automatically with authorization checked from a generic user id ( user type can be system to prevent dialog login) which can have authorization to create jobs under any person ( as decided by program logic).

I think this should be a sufficient control to avoid any audit issues.

Thanks

Sandipan

[Former Member]

Hi Raghu,

Our customized program automate certain business process after user perform a primary transaction.

The problem is that our customized program will first create a job under user "X" userid for audit trail purpose. Because user "X"does not have necessary authorization to perform full update of all other transactions or tables update, in the job, the program will indicate a non-user account with SAP_ALL authorization to perform the update.

If we are to set S_BTCH_ADM = N to user role, we are afraid that all those auto created jobs by customized program for user "X" but to be execute under admin userid, these jobs will failed.

Maybe, you can advise if SAP allows configuration to be done just to grey off the userid field in SM36?

[Former Member]

Hi,

My recommendation is to create 2 roles:

1st role with S_BTCH_ADM with Y (This role should be assigned to the communication user that is used by your custom program)

2nd role with S_BTCH_ADM with N (To assign to the end users)

This way, the option to schedule jobs under a different user ID lies with your custom program.

Regards,

Raghu

[arpan_paik]

User having access to SM36 will have access to schedule a bacth job by default. Even if user does not have any other access!! As you are keen to grey out one field so you may try creating variant transaction in SHD0

Regards,

Arpan Paik

[Former Member]

The problem is that our customized program will first create a job under user "X" userid for audit trail purpose. Because user "X"does not have necessary authorization to perform full update of all other transactions or tables update, in the job, the program will indicate a non-user account with SAP_ALL authorization to perform the update.

Since your custom program check for S_BTCH_ADM and S_BTCH_NAM from User's authorization we cannot put S_BTCH_ADM=N there and in that case, users would be able to create jobs with other user ID by executing SM36 directly.

Option 1: Discuss with your developer if it is possible to create a custom exit in the Sm36 program to perform the above authorization check in your Batch user ID's authorization instead of your dialog users. In that case your custom program would run as expected as long as your Batch user ID has proper authorizations for S_BTCH_ADM and S_BTCH_NAM and your dialog users can be restricted to S_BTCH_ADM= N

Option2: Create a transaction variant for SM36 in tcode SHD0 and make field "User" invisible and then link the transaction variant to a custom tcode which is to be created with start type "Transaction with Variant (variant transaction)".

Please refer to an SDN article for process of [creation of a transaction variant and linking it to a variant transaction|http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/40d1443e-0184-2c10-c68d-c612f771fe6f?quicklink=index&overridelayout=true]

Then have your custom program updated to call the custom tcode instead of SM36 and modify your user's roles to replace SM36 authorization with ZSM36 (Check indicator values of SM36 are pulled into the role). This will ensure your custom program can create jobs under a different user whereas when your user executes SM36 online, the field to change 'user' will not be visible and by default they would be forced to create jobs under their own IDs inspite of having S_BTCH_ADM=Y and S_BTCH_NAM= <your Batch user ID>

Hope this helps!

Sandipan

[Former Member]

Deleted post

Edited by: Sandipan Choudhury on Dec 28, 2010 1:16 AM

[Former Member]

A dummy value ' ' for S_BTCH_NAM should do the trick, if you had read the FAQ (the second thread on the forum) by Julius it would have helped, i guess

[;