Can I use the User Name in Aut. Objects's value

[Former Member]

Hello everyone, I need to know if is possible to use a variable with the SAP User Name in values of the Autorization Objects in some roles.

Thank you to everyone

--

Maximiliano Valin

[Former Member]

Hi Maxi,

for instance the auth object S_SPO_ACT has a field named SPOAUTH where we assign the SAP user name. This is used to diaplay the spools of that particular user and other users cannot see spools generated by User names not listed in this place.

Is it something similar to what u r looking for or am i missing something.

Br,

Sri

Your points drive us

[Former Member]

Hi Maxi

There is an object for Background Jobs called:

S_BTCH_NAM where it has a field called BTCUNAME where we assign a user name.

It determines the authorized users, which users can choose from when scheduling a background job.

Hope this would clarrify your doubt to an extent

[WolfgangJanzen]

I assume that you are referring to something like a variable $USER$ (which has the value SY-UNAME).

Sorry, but that does not make any sense to me.

That would be equivalent to "IF SY-UNAME = SY-UNAME".

But maybe I've understood you wrongly.

Please elaborate your inquiry.

Cheers, Wolfgang

[Former Member]

Hi Max,

yes it is possible as others have rightly pointed out. We in our project had an SOX related requirement pertaining to auth object s_btch_nam. To be specific what we needed was that every user should be able to schedule job in his own name only. For this we made the use of value sy-uname in the field for btcname and it worked.

Regards.

Ruchit.

[Former Member]

You do not need S_BTCH_NAM to schedule a job in your own sy-uname. S_BTCH_JOB is sufficient to control this, until it is over-ridden by S_BTCH_ADM.

sy-uname = sy-uname makes about as much sense as SCP_CHAR_ECHO.

[Former Member]

Hi Juluis,

Sorry may be I didnot put it explicitily enough. What I meant was that when you are trying to schedule a job thru SM36 and go to step option there there is an option for user id. here unless you have auth for other users you cannot schedule the job in his name. the other users can be system users with lots of authorizations. This is helpful coz when reports get executed in background authority check is performed for the step user and not the user who actually scheduled the job. also just an interesting fact (not related to this topic) even if the user who scheduled the job is deleted the job will not get affected as long the step user exists. the job will continue running.

of course as correctly pointed out by you s_btch_job is needed for scheduling/releasing/displaying etc the job.But that is different from step user auth concept.

regards.

Ruchit.

[Former Member]

Thanks Ruchit, I misread your post.

There are infact some special cases where the system does infact check to see whether not only the job step user is authorized, but also the job scheduler.

* Intercepted jobs are only released only if the current user
* has proper authorization.
  DATA: wa_tbtccntxt LIKE tbtccntxt.
  GET TIME.
  DATA: wa_tbtco LIKE tbtco.
  SELECT SINGLE * FROM tbtco INTO wa_tbtco
    WHERE jobname  = jobname AND
          jobcount = jobcount AND
          status = btc_scheduled.
  IF sy-subrc = 0.
    IF global_job-status = btc_scheduled AND
       (
         ( NOT dont_release IS INITIAL AND
           ( release_stdt-sdlstrtdt < sy-datum OR
             ( release_stdt-sdlstrtdt = sy-datum AND
               release_stdt-sdlstrttm < sy-uzeit
             )
           )
         ) OR
         dont_release IS INITIAL
       ).
      IF sy-subrc = 0.
        SELECT SINGLE * FROM tbtccntxt INTO wa_tbtccntxt
          WHERE jobname  = jobname AND
                jobcount = jobcount AND
                ctxttype = 'INTERCEPTED'.
        IF sy-subrc = 0.
          AUTHORITY-CHECK OBJECT 'S_RZL_ADM'
                   ID 'ACTVT' FIELD '01'.
          IF sy-subrc <> 0.
            ret = err_no_authority.
            RAISE cant_start_job_immediately.
          ENDIF.
        ENDIF.
      ENDIF.
    ENDIF.
  ENDIF.

Kind regards,

Julius

[Former Member]

Thank for every answer and I apologize for me English

I try to explain better the situation. I have a Z-program and this program call a particular Tx and it run a batch input with the Session Name as User Name.

The user needs to see the Batch Input's logs, for that I create a role with the Tx SM35 and into the authorization object S_BDC_MONI I put the name of the user that needs to see the logs, for example for the user MVALIN:

Aut. Object = S_BDC_MONI

BDCAKTI = ABTC, ANAL

BDCGROUPID = MVALIN

My question is, if possible replace the string with the user name, in this example MVALIN, with a system variable with the user name like SY-UNAME?, and how can I do that?

Thank everyone, and I hope have explained everything correct.

--

Maximiliano Valin

[Former Member]

My first reaction to that is: Yes, it is possible.

But before we go down that route, the concept sounds like a bit of an over-kill. If the various groups of users (differenciated by their roles) have similar functions, then why should they not have the same BDCGROUPID value and be able to see each other's batch sessions or check the logs. There might even be a valid Segregation of Duties reason for sy-uname = mvalin to check that BDCGROUID = jbussche has a clean log.

Or am I missing something confidential?,

Cheers,

Julius

[Frank_Buchholz]

Hello Maximiliano,

as far as I understand you like to restrict access using Tx SM35 to everybodys own Batch Input logs.

Yes, you can create, the Batch Inputs using the userid as the group id. But you cannot enter any variable namens into the authorizations of a role or a profile. You have to use manually created roles for every single user. (You can turn the authorization field BDCGROUPID into an org-level field to use a derived role for every user).

Well, I assume this will not be applicable...

Kind regards

Frank Buchholz

[Former Member]

I hardcoded the username.

[Former Member]

It is usefull here to have a well thought out naming convention for these user IDs, along with the same for their user groups and role names...

That way you can isolate them and use wild cards within conventions (for example, for batch administrators and monitoring access to batch-input sessions).

The same goes for RFC users and webservice proxies.

Cheers,

Julius