Change SY-UNAME

[Former Member]

i need to change the user name before calling a function module which releases an invoice frompayment block.

actually scenario is a user will release the blocked invoice using the bapi BAPI_INCOMINGINVOICE_RELEASE.

But he has no authorization to release the invoice.

So can i change the user name just before calling the function module so that the new user id will be used for authorizatio- check.

i have tried to do this.but the user name being reset to the current user in each step of execution.

is there any way to chagne the user for security check?

[Former Member]

> actually scenario is a user will release the blocked invoice using the bapi BAPI_INCOMINGINVOICE_RELEASE.
> But he has no authorization to release the invoice.

Isn't your scenario a big security issue? If the user doesn't have the authorization to release it, the user should not release it. It is as simple as that. If the user should have that authorization, then they should get it from the security folks in your basis team.

What is the purpose of having an authorization check if you want to bypass it? If you think this check should not be there at all, simply add the necessary authorization in every user profile. Do not change SY-UNAME in the code. It will be a big audit issue.

[Former Member]

Hi lavanya,

why didn't you or the basis give the user authority which he needs to execute the report (bapi).

I think if the user shell not get the authority he shell not be allowed the bapi: BAPI_INCOMINGINVOICE_RELEASE.

That's my opinion.

Regards, Dieter

[former_member191735]

You cannot change and even if you can it is not advisable... If the user does not have authorization, give him the authorization or bypass the authorization

[Former Member]

Perhaps ask BASIS to set up a new userid for this test in order for you to check authorisation is correctly configured.

[Former Member]

You cannot (and should not) change sy-uname this way.

I see two options for you:

- Send the release call into the workflow engine and let it pass the authority-check. Some workflow API's have the ability to import the user ID of the caller and "use it" in the update.

- Use SU24 to make a transaction context sensitive disabling of the return code on the authority-check. This can be usefull in some cases, so that users cannot perform the same task from other transaction contexts. You need to choose the object carefully and ensure that in your cosing prior to the call, you have made the other necessary checks to ensure that it cannot be misused. I recommend calling FM AUTHORITY_CHECK_TCODE as well in such a use case.

Cheers,

Julius

[Former Member]

see.. even if you change sy-uname from your code, as this is a system field this will get filled again with actual value when it goes into the FM or next processing block.

so changing it wont help you with authorization. you can ask you BASIS guys to add that authorization to your username.

[Clemenss]

Solution: [Change SY-UNAME |http://www.google.cn/search?hl=zh-CN&q=ChangeSY-UNAME++&btnG=Google%E6%90%9C%E7%B4%A2&aq=f&oq=]

[romanweise]

Hi,

I am not a pro in the area of invoice handling but there are 2 approaches which might work if the funktion module is independent and not using any global variables. I admit they are both hacks but if it is only about working, sometimes the only way.

You could call the function module via rfc in the same system using an rfc connection with a user maintained. So the function module would be processed under the user in the rfc connect. If the function module is not rfc enabled itself you might build a customer wrapping fm around.

You could put the funtion module into a report and dynamically plan the report as batch under the other user.passing parameters might be a bit tricky but nothing which can't be solved. If this is to complicated you could just put the data into a table where a periodical batch job planned under the authorized user reads it from. Noone said that if the function module has to be processed under a certain user that this has to be a synchronous process!

And tomorrow we learn what cool things can be done with CLIENT SPECIFIED operations on USR02 table ;o)

Cheers, Roman

PS: If the real problem is just that you cannot grant the authorization on a certain function module as it is used in different standard applications so the authorization for your program would result in to powerful authorizations in sap standard transactions, the I would copy the function module and use it. This Z fm could be authorized bypassing this problem.

[Former Member]

I don't consider those to be "hacks" in my book

They are just bad design approaches:

In the first case, you will loose the audit trail to the caller.

In the second case you will be forced to grant authority to the end user to open a step in another user's context. That will open another backdoor for them as well in SM37 etc...

> PS: If the real problem is just that you cannot grant the authorization on a certain function module as it is used in different standard applications so the authorization for your program would result in to powerful authorizations in sap standard transactions, the I would copy the function module and use it. This Z fm could be authorized bypassing this problem.

A better option with less coding involved, would be to use SU24. This way you keep the audit trail and isolate the transaction as being an exception to the standard checks for one specific object. An auditor might wonder why a user can release a PO when they don't have one of the required objects, but they will easily find it if they know where to look.

It is also easy to do this in a secure way, such that you can document it for the auditor and give it to them upfront to understand. A good auditor should understand and appreciate that.

If you achieve this programmatically with tricks, you will have a tough time... (as will the auditor).

I have done many audits and also hunted down some dodgey coding in my time. The idea should not be to run away from the auditors, but rather expect that they know what they are talking about and make your design compliant with their and your client's control requirements.

This should be the approach regardless of whether or not you can change sy-uname as a developer.

The original question might also have been: "Can I pass a backdated authority-check against a user who once had the authorizations way back when?" Same thing... bad idea...

Cheers,

Julius

[Former Member]

> And tomorrow we learn what cool things can be done with CLIENT SPECIFIED operations on USR02 table ;o)

No, tomorrow the extended syntax checks on table operations will be errors, and not just warnings.

The user BAPI's are very mature in my opinion. There is no reason to select anything from USR02 anymore, unless you want to interpret single fields and make big mistakes. In release 7.00 without using downward compatible passwords, about 40% of the single fields of USR02 are obsolete. The other fields have a myriad of dependencies.

All round bad idea.

Cheers,

Julius

[romanweise]

Julius,

I am doing development quality assurance on my own and of course this would never pass any of my reviews. lavanya did not mention what is the setting which leads to this requirement. There is development for products or production customer solutions and there is development for throwing together stuff the night before so sap sales can present function in road shows which are not existing in the product years after. Sometimes it is just about running and looking good. As it was not clear which is the scenario I offered possible solutions but indicated they would not be 1st choice. Don't fear my avarage production coding can compete with sap standard easily ;o).

No, tomorrow the extended syntax checks on table operations will be errors, and not just warnings.

For the records. Some of the extended syntax checks were implented as I persuaded someone at sap to built them as they seemed to be a great idea to me. And with all respect, i know how to run SCI over sap coding and I have seen the result. My friend, this will never happen! I would be already celebrating if someone at sap would start to care about package interface and finally build some so i won't get tons of warnings when implenting a single BAdI.

But no need to argue i think positions are clear.

Ciao

Roman

[Former Member]

At the risk of loosing lavanya's interest in the tread here:

> And with all respect, i know how to run SCI over sap coding and I have seen the result. My friend, this will never happen! I would be already celebrating if someone at sap would start to care about package interface and finally build some so i won't get tons of warnings when implenting a single BAdI.

I can only imagine a very major (future) release change to implement this, but ABAP has evolved a lot and there are plenty of (syntax) warnings heading in this direction already.

Lets take a dualstack installation as an example, where the user logged onto the Java system can use functions implemented in ABAP. Here you can map the users even. But for manageing them and administrating and auditing them consistently without a huge "tricky" overhead of coding... SAP has clearly distanced itself from this installation approach.

Of course there is a lot of software logistics and legacy coding (and customers) to consider, but that doesn't make it wrong.

I am sure you have seen some of the coding here at SDN and elsewhere in the internet. Some of it will not even survive an SP update, let alone an audit or release upgrade. But when large customers have crossed the rubicon to webservices and federation to propogate user ID's (changing sy-uname?), then I doubt those little backend ABAP tricks will be considerered for long.

An exception might be workflow. Personally, it is my prefered weapon of choice in an audit.

Cheers,

Julius

[Former Member]

Guess you can use the destination concept. For this scenario, no need to change sy-uname or need authorization. May be the below coding may help.

Step 1

Use function module OWN_LOGICAL_SYSTEM_GET to get the current system logical system

Output

Export parameters Value

OWN_LOGICAL_SYSTEM l_logicaldest

Step 2

then call the BAPI..

BAPI_INCOMINGINVOICE_RELEASE destination l_logicaldest

Thanks,

D

[venkat_o]

This message was moderated.

[Former Member]

solved

[Former Member]

Hi Lavanya,

Can you please tell me how did you solve this issue? I have same issue now. I am trying to release the invoice from a ztransaction and calling this BAPI in that.

Thanks,

Naveen.