Transaction Variant Restrictions

[Former Member]

Hi Guys,

We have a transaction variant ZXK02 which is getting executed through one custom screen. Now requirement is: users should not be able to execute this tcode in standard way(through SAP Easy Access screen). But can access only through custom screen(using call transaction 'ZXK02').

How can we achieve this functionality.

Regards

[Bernhard_SAP]

My idea is to remove the s_tcode-authorization for ZXK02.

Of course users have to be restricted if they may start the calling t-code in which your screen resides or not. If only authorized users can access the coding with the call_transaction zxk02, you can remove the check for s_tcode zxk02 in SE97 for this calling/called couple.

Effect: users cannot start zxk02 as they don't have S_TCODE zxk02, but if they come from your screen, no check on S_TCODE is performed.

b.rgds, Bernhard

[Former Member]

Thanks Bernhard.

SE97 solved my problem.

[martin_voros]

Unfortunately, you can't achieve this. You can't block direct execution of transaction using authorization. If user has authorization S_TCODE for ZXK02 then she can execute it directly or from other program. You can't also add an additional check to ZXK02. There is no standard way of recognizing if the transaction was called directly or not. I can image to check ABAP call stack to see if there is a record for your custom program but it's a really dodgy way. May I ask what is your original requirement? Why can't your users execute ZXK02 directly?

Whoops, I did not know about SE97. Thanks for this info. It would be nice if there was a note about SE97 in documentation for authorization object S_TCODE.

Cheers

Edited by: Martin Voros on May 18, 2010 12:27 PM

[Former Member]

We are working on workflow based Vendor create/edit solution, where requesters will edit vendor data using one custum screens, then on saving data, request will go to approvers.

Reqesters editing vendor data through transaction variants which are called from an custom screen. So requester should

not be able to directly execute the transaction variants if at all somebody tries to do so.

[Former Member]

Hi

Check with your developers if applying a user exit will help in this situation.

Thanks.

Anjan

[Bernhard_SAP]

> Whoops, I did not know about SE97. Thanks for this info. It would be nice if there was a note about SE97 in documentation for authorization object S_TCODE.

Hi Martin,

please have a look at [SAP Note 515130|https://service.sap.com/sap/support/notes/515130]

b.rgds, Bernhard

[Former Member]

>

> We are working on workflow based Vendor create/edit solution, where requesters will edit vendor data using one custum screens, then on saving data, request will go to approvers.
> Reqesters editing vendor data through transaction variants which are called from an custom screen. So requester should 
> not be able to directly execute the transaction variants if at all somebody tries to do so.

In that case a CALL TRANSACTION with implicit commits is not the correct approach, even if you do find a way to hobble the tcode into being not-executable for the user (via call stack validation, or attempting to find all the calling transactions and trust them).

Speak to your workflow developers about WAPIs (Workflow Application Program Interfaces). They are like BAPIs, except they are on steriods and serve special purposes...

Cheers,

Julius

[martin_voros]

Hi,

we had a similar requirement but instead of creating/editing vendor master we had to give users ability to modify restricted set of material master attributes. We developed our own custom transaction which performs additional checks and it uses standard BAPI to modify material master. Obviously, this approach requires additional development. Basically, this is a basic idea of SOA. You have set of services (in this case BAPIs) and you build your own application on top of these services where you implement your additional logic.

Cheers

[Former Member]

Hi,

If your requirement is this, then removing the TCODE from S_TCODE should only help . Those having authorization for the program( via a ParameterTransaction - TCODE calling another TCODE) which calls the custom screen, should be able to do it.

Hope this helps.

Regards,

Manisha

[Former Member]

Hi

Here is the link to post on SE97.

Might be of some help in this case.

Thanks.

Anjan