2015 Mar 26 10:08 AM
Hi Friends
In one of the old program to update storage location and other data BDCs were getting used but due to very slow performance it get replaced with
BAPI ' BAPI_MATERIAL_SAVEDATA ' but issue with this bapi is , only user is getting 'No Authorization for this transaction ' rest we all able to upload data , but client not ready to give any other access to the user and want us to handle this at program level only ,
few options I got are ,
1) SU24 can help to suppress auth checks but not acceptable and good idea for long run ,
,2) FM - > CALL_TRANSACTION_FROM_TABLE
3) FM - > C160_TRANSACTION_CALL
but these all above not advisable as se37 access need to provide ,
finally one option suggested to replace this BAPI with FM ' MATERIAL_MAINTAIN_DARK ' not sure it will work or not am starting working on this .
mean time does any body have any other suggestion or best option .
Regards
Meeta
'
2015 Mar 26 10:14 AM
What is the authorisation object that is triggering the no authorisation message? Use SU53 for this information.
As a general principle, if a user needs an authorisation to do a task for which there is a business requirement, they are given the authorisation. Presumably there is a business requirement, so the authorisation concept should be updated.
Use of unreleased function modules is not supported by SAP; so it is not a good idea.
I would return to the client and tell them the options are
1) Modify the authorisation concept - fully supported by SAP
2) Suppress via SU24 - which will cause a massive stink if the client has an external security audit
3) Use unreleased function modules which are not supported by SAP
Then see what their response is. Usually a business requirement trumps everything, and suddenly option 1) becomes acceptable.
2015 Mar 26 10:14 AM
What is the authorisation object that is triggering the no authorisation message? Use SU53 for this information.
As a general principle, if a user needs an authorisation to do a task for which there is a business requirement, they are given the authorisation. Presumably there is a business requirement, so the authorisation concept should be updated.
Use of unreleased function modules is not supported by SAP; so it is not a good idea.
I would return to the client and tell them the options are
1) Modify the authorisation concept - fully supported by SAP
2) Suppress via SU24 - which will cause a massive stink if the client has an external security audit
3) Use unreleased function modules which are not supported by SAP
Then see what their response is. Usually a business requirement trumps everything, and suddenly option 1) becomes acceptable.
2015 Mar 26 5:51 PM
Moderator message: this solution is not recommended. See Paul Bakker's response below.
Although I completely agree with Matt, there is an option that I found recently. I would not comment whether its is right or wrong to use this approach in your case but our requirement was a little different where, in order to allow a certain functionality a lot of authorizations were to be allowed. In order to over come this issue:
Add the below code:
***************************** set the user ********************
concatenate 'WORKFLOW_LOCAL' sy-mandt to destination separated by space.
***************************** set the user ********************
Then call the function using the above destination. This sets the user as WORKFLOW which will have a better authorization.
CALL FUNCTION 'XYZ' destination lv_dest.
Inputs are most welcome.
Thanks,
Vikram.M
Message was edited by: Matthew Billingham
2015 Mar 27 5:54 AM
Vikram,
Have you actually tried that yourself? I ask because I can see some factual errors in your post. It won't work as it stands.
And if it did somehow work, you would be effectively circumventing all authorisations in the system as well as performing updates under another user's name (ie the workflow system user). If anyone tried that at my company they would be terminated immediately.
So have you actually done this?
cheers
Paul
2015 Mar 27 5:59 AM
2015 Mar 27 7:15 AM
solutions proposed like the one above also call out why systems user accounts should be restricted and not assigned SAP_ALL
2015 Mar 27 9:24 AM
Hi Thanks to all for your valuable inputs ,
Actually these below options are possible for this BAPI error ,
1) To add authorization object for all the “maintenance status” to user’s role.
> 2) Program modification
> Ignore the error message for authorization.
> 3) Program modification
> Submit another program by using user: UC4BATCH in order to avoid an authorization error
> 4) Program modification
> Somehow, avoid passing the authorization values for unnecessary “maintenance status”
but they very first want to know if option 4 can we an solution or not ? as user was able to update using BDC before code change ( replace bdc with bapi ) ,, as other options they need to give more access .
we updating same data only through BAPI. But, does this BAPI always require the authorization for all the maintenance status?
2015 Mar 27 10:27 AM
It becomes clearer. It seems then that the BAPI doesn't properly apply the users authorisations. It should check that the user has the authorisation to change at least what they have authority to change.
Maybe the way forward would be to raise a call with SAP asking for the BAPI to be updated? (This is what I did when a support pack enlarged the scope of a BAPI, but that required the users to suddenly have the authorisation to do all the enlarged scope - I did get a response and a fix quite quickly).
However, I've search this site (which is what you should have done first of all) and it seems this is a common problem. One poster suggests that although you get the error message - the change is made. If that is the case, then just ignore the error message.
2015 Mar 27 2:00 PM
Paul,
I cannot agree more on what you have stated. It is true that it overwrites the authorization and in order to over come the same the actual program in which this was coded was controlled by proper authorization.
fortunately this is not something that I coded but came across whIle I was making changes.
The idea was not to encourage others using this option. I never knew some thing like this would work before I came across this recently.
Thanks,
Vikram
2015 Mar 27 3:38 PM
The reason why this should never be done is that it subverts the whole authorisation concept. It might not just land a programmer who used it in serious trouble, but it would also land any regulated industry in trouble. Imagine a company where the person creating new customers, new purchased orders and approving invoices...
2015 Mar 30 7:53 PM
Hi Friends
Thanks for your valuable suggestions , but still they want to first try level best for all possible options without giving any role / access as their simple query is using BDC user was able to update then
same they expecting with this BAPI as well . 😞
This issue is still open ad am getting suggestions like to copy this BAPI into custome one BAPI_MATERIAL_SAVEDATA into Z Bapi and make try to look option if authorization message can be skipped . but am not sure this will success or not or its good suggestion .?
Regards
Meeta
2015 Mar 30 10:39 PM
Matt already correctly pointed out above that if BAPI does not handle authorization checks correctly then the right thing to do is to ask SAP to fix it (by opening an incident).
You could easily do an authorization trace (ST01) with the old program (or just standard transaction) and then with the BAPI. Then look at the differences and if there seems to be excessive authorizations required by BAPI then it's perfectly reasonable to ask SAP what the heck.
Any other "creative" solution will be either a violation of the authorization concept or a redundancy that someone will have to address at later time, just like now you're trying to replace BDC with something better. At the same time countless other developers will continue having the same issue because no one thought about solving the root cause.
2015 Mar 31 7:03 AM
Copying a standard function module (or BAPI) is nearly always a really bad idea. You don't benefit from any fixes through service packs, and, worst case (I've seen it happen), the copy might stop working due to changes elsewhere - necessitating a re-clone.
Finally, if you create your own code to update standard SAP tables (which is what your copy would effectively be) then that if something goes wrong, SAP will not fix your database without charging significant sums of money.
2015 Mar 31 10:36 AM
2015 Mar 31 2:09 PM
[banging my head on the desk] Is there some issue with opening an incident with SAP? They don't bite (usually).
What do you think about the solution in the linked post? If it was acceptable in your case to run the program in a background job then we probably wouldn't be having this discussion. Just thinking.
2015 Mar 31 2:32 PM
There would only be an issue if the SAP system in question wasn't licensed. So it can't be that.
2015 Mar 31 7:24 PM
Sorry as am under pressure to check maximum possibility to handle this at program level,
But now I have raised this to SAP ,