Restrict users to groups with access to schedule background jobs

[Former Member]

The following is the requirement. Please check the requirement and provide some suggestion to solve it.

1) There are 3 different teams for job monitoring say A,B,C with access to tcodes sm36,sm37,sp01.Each team has 5 different members.

2) The requirement here is that team A should not view, delete or modify the background jobs scheduled by team B and vice versa.

3) Whereas Team C can view, delete, modify the background jobs scheduled by team A & B.

4) How can we restrict?

We tried using s_user_grp but it wasn't successful.

[arpan_paik]

Try exploring S_BTCH* objects....

And try search also if you want particular name. There are loads of thread here on this topic.

Regards,

Arpan Paik

[Former Member]

Hello,

I think S_BTCH_NAM can make this trick possible, it should be noted that every user can always enter himself as an authorized user when scheduling a job, Thus, an authorization for this object is only required if your users require users other than authorized users.

try designing something like this, A team is restricted with a set of users through which they can work with background jobs and B team should have different set of users. however C team will have * access for this object S_BTCH_NAM.

Hope this helps !

Regards,

Ananth

[Former Member]

Hi Abilesh,

It is not possible to restrict the background job authorization by authorization groups (teams).

If you wish to restrict the view, you can give transaction code SMX so that users can view the jobs that are scheduled by them. So all the 5 members in the team would be able to see the status of the jobs that are scheduled by them

Also, S_BTCH_NAM, S_BTCH_JOB, S_BTCH_ADM are the objects that controls background jobs. You can specify the individual names as an alternate in S_BTCH_NAM, which means you need to create different roles for each team with the consultant names in it (ofcourse not recommended to have those many roles).

Regards,

Raghu

[Former Member]

What you are looking for is Solution Manager.

I would suggest talking to your SolMan team.

In SolMan you have the possibility of an application layer for such controls of periodic jobs, and allow only local "ad hoc" reporting via background.

There are also some external job schedulers available as partner products, but if you use the functionality of SolMan and have your SolMan authorizations under control (no easy task...) then it can be avoided.

Cheers,

Julius

[Former Member]

I hope if only job group field in S_BTCH_JOB could have been used. Do not understand why SAP has reserved it to set as *. Maybe they never got a reason to develop it further.

I do not think other S_BTCH* objects will be able help you with this.

[Former Member]

AFAIK the field was reserved for later use if requirements were reported.

The concept of ad hoc reporting was available and end users immortalizing themselves in periodic jobs were replaced by the SYSTEM type user (in very old systems or clients you might even still find type D users).

This means that periodic job admin is the task of the "job administrator", so S_BTCH_ADM = 'Y' overrides the S_BTCH_JOB check for ad hoc releasing (RELE) of jobs and all other job actions, also client independently.

The granularity of the "job group" can be achieved by the S_BTCH_NAM object within the "job administrator" folks, but a central instance for such jobs make sense as a novice can cause a lot of havoc there (also when changing variants and layouts....).

That is my understanding of the 2nd field of S_BATCH_JOB and why you can give * if you are going to give RELE anyway for "ah hoc" reporting.

Cheers,

Julius

[Former Member]

> The granularity of the "job group" can be achieved by the S_BTCH_NAM object within the "job administrator" folks, but a central instance for such jobs make sense as a novice can cause a lot of havoc there (also when changing variants and layouts....).
> 
> Julius

Hi Julius,

I think the only granularity S_BTCH_NAM would achieve is in scheduling a batch job.

OP question on one group of batch admin (with access to SM36 & SM37 and I assume S_BTCH_ADM as Y) should not be able to view or modify or delete jobs created by other batch admin in another group is not possible to restrict via S_BTCH_NAM.

I actually schduled a suim report with my id and then created a test batch admin id with access to SM36, SM37 S_BTCH_ADM as Y and S_BTCH_JOB / S_BTCH_NAM deactivated.

I was sucessfully able to change or delete the job created by me from this test batch admin id though I do not have S_BTCH_NAM access.

So I still think JOB GROUP field should have been little enhanced by SAP for scenario like this one..

[Former Member]

NAM will control the steps.

ADM will override JOB anyway.

Within S_BTCH_JOB I dont think I would ever have used a grouping concept even if it was possible. What about the programs in the steps? Grouping them via S_PROGRAM for BTCSUBMIT cannot be claimed to have been successfully implemented and survived by anyone either IMO so job grouping makes less sense. It is just a matter of discipline between a small group of colleagues who admin the periodic jobs.

Like with variants of the step programs, the ability to "protect" a job would be useful. If there is interest, I would create a functionality wishlist entry in the wiki.

Cheers,

Julius

Edited by: Julius Bussche on Aug 6, 2011 12:29 AM