How to avoid standard Authorization checks in BAPI_MATERIAL_SAVEREPLICA

[former_member1031088]

Hi Experts,

Currently we are using standard BAPI "BAPI_MATERIAL_SAVEREPLICA" to build material master. We are facing an issue when security roles come into picture. As of now the accounting view and costing view access is only given to Finance user but the material needs to be created by the inventory person. We have built a custom tcode to look into default data from custom tables and populate in all the views of material master.

Since this BAPI is doing a standard authority check the Inventory user is not able to create the material as he does not have authorization to costing view (code=G) or accounting view.

My Question : Is there a way to bypass the standard authorization check by BAPI so that my custom material create program will not check the authorizations of the user and create the part in one go. Do i need to copy the satandard BAPI and build a ZBAPI with input parameter of "NO_AUTHORITY" to avoid any authoruization check when creating a material master ?

Any sugestions/Comments will be appreciated. Thanks in advance.

Alen

[martin_voros]

Hi,

you can use a workflow trick. There is a RFC destination for workflow that has predefined user WF-BATCH. This user has a traditionally broad authorization. Because you have a custom transaction you can just call that BAPI with specified RFC destination. The only disadvantage of this approach is that change log will contain WF-BATCH instead of actual user who created material. This causes some issues with attribution. Your custom transaction could create additional log but it's not ideal.

Cheers

[Former Member]

If you have a local transaction context and not calling the BAPI remotely, then you can set the indicators in SU24 to "no check" in the same way as other normal transactions.

Cheers,

Julius

[martin_voros]

Yeah, much better solution. Always forget about this.

Cheers

[Former Member]

Also the "authorization convenience" for calls to WORKFLOW* destinations should ideally not be (mis)used outside the context of WAPIs (Workflow APIs).

There is however nothing wrong with creating your own logical destination for such update calls (I use it sometimes as well) but that makes it transparent what the call is for and you have better chances to restrict the access of WF-BATCH to WAPI only based processing APIs and the application auths it needs, and alternately your own scenarios. This is actually safer than SU24 in some cases as parallel processing via destination group IDs might loose the transaction context in some cases.

--> you should only use WAPIs for Workflow, even if it is very tempting not to...  🙂

Otherwise you have limited chances to restrict WF-BATCH (but you can also change the name of the user ID in the WAPI calls - it is not hard coded).

Cheers,

Julius

[former_member1031088]

Fianally we are going with a ghost ID which security will give access to all the views for that custom authorization object. We are still playing with it. If that does not work we will go with WF-BATCH.

[Former Member]

You will be much better off with a transaction context (if your application has one) and using SU24. Less destinations or services, less user management, less roles, less error prone, applies only to that transaction and not to all callers....

Cheers,

Julius

[former_member1031088]

Thanks Julius.

We are following the standard documentation in

SPRO-->Logistics - General-->Material Master-->Configuring the Material Master-->Here's How (Quick Guide Using an Example)

Now only few users who are added in OMT3E tcode will have accounting and costing views in display mode.

[Former Member]

Yes, you can validations to some extent and even use them to simplify the role concept, but you will generally still need to authorize the user -> this means that code which does not pass through the validation will still authorized the user. Additionally it will confuse audit results to no end...

Perhaps the biggest pain with using table based user list validations (it is optional, as an enhancement, modifications, etc) is that it is difficult to provision them. You cannot just find the job role and expect it to work...

I guess it depends on how many users you have and how often they fluctuate as well.

A central repository for message handling which offers user based behaviour also exists -> table T100C. If you are going to do this, then it is better to centralize the mechanism.

Cheers,

Julius