Skip to Content
author's profile photo
Former Member

How to avoid standard Authorization checks in BAPI_MATERIAL_SAVEREPLICA

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

Add comment
10|10000 characters needed characters exceeded

  • Follow
  • Get RSS Feed

3 Answers

  • author's profile photo
    Former Member
    Nov 24, 2013 at 07:05 PM

    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

    Add comment
    10|10000 characters needed characters exceeded

    • Former Member Martin Voros

      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

  • Nov 24, 2013 at 06:54 PM

    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

    Add comment
    10|10000 characters needed characters exceeded

  • author's profile photo
    Former Member
    Nov 27, 2013 at 06:16 PM

    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.

    Add comment
    10|10000 characters needed characters exceeded

    • Former Member 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