Securing parameter based transactions

[Former Member]

Hello all,

I have a custom workflow Z transaction that is parameter based. This means that when executed it calls WF_START with specific workflow parameters which is held in table TSTCP.

Problem is, I don't want to give access to WF_START as it is too broad but my Z transaction won't run without also including WF_START in S_TCODE.

Is there any way to not include WF_START in S_TCODE and still keep the Z transaction as parameter based? The only other alternative is to have the Z transaction call the WF_START program and pass the variables to the screen that way versus calling the transaction directly...

Thanks!

[Former Member]

Loomin SE93 and select your custom transaction. As it looks like the S_TCODE object is called with WF_START, replace that value for the Z... value

[Former Member]

That's the problem. In SE93, the Z transaction has WF_START with "Skip initial screen." Then at the bottom are the parameters that the Z transaction is passing to WF_START.

Essentially, we are passing preset values to WF_START and bypassing the initial screen, but we don't want to give WF_START direct access to the users.

There may not be a way to secure the transaction this way but thought I would check.

Regards, Dylan

[WolfgangJanzen]

So you have defined a "parameter transaction" (and not a "variant transaction").

Well, but even then, the system should perform an S_TCODE check on the parameter transaction name (instead of an S_TCODE check on the name of the corresponding core transaction).

Can you provide more information on the way you call the transaction?

Is it via "CALL TRANSACTION" (programmatically) or via the "Easy Access Menu" (as favorite) or via SAPGUI ok-code field? In case of the later one, try to enter first "/n" (and submit the request) and then submit a second request entering the name of your parameter transaction (in the ok-code field). The first statement will terminate the "Easy Access Menu" resulting in a dynpro where you'll find a button "Start SAP Easy Access".

Cheers, Wolfgang

[Former Member]

Hello Wofgang, The transaction variant worked.

By creating the transaction variant (SHD0) and then assigning a Z transaction to that transaction variant, the auth check is no longer done on the WF_START transaction. It's an interesting finding as the option "Transaction with parameter" still performs a check on the core transaction. They are also stored differently in the TSTCP table:

Transaction with parameter stores the values as: "/*WF_START........"

Transaction with variant stores the values as: "@@WF_START......."

Thanks for the help! -Dylan

[WolfgangJanzen]

Thanks for the feedback - it's good to end the year with success.

I wish you continuous success in the New Year.

Cheers, Wolfgang

PS: in our time zone the last working day in 2006 is going to end in a few hours ...

[WolfgangJanzen]

The proper approach is:

- define a transaction variant for WF_START

- define a variant transaction Z... for that transaction variant

- allow users to call that variant transaction Z..., only (granting S_TCODE authorization)

Cheers, Wolfgang (wishing everybody a Happy New Year 2007)

[Former Member]

Wolfgang, I'll give it a try and get back to you ASAP. -Dylan