Fiori asset transfer app throws 'Authorization Error' for asset lifecycle users after recent patch

PLM SAP PLM
, , , , , , , ,
1

We’re experiencing authorization failures in our Fiori asset transfer application running on SAP PLM 2022. When users attempt to transfer assets between locations, they receive ‘Authorization Error - Missing object S_ASSET_TRF’. The error appears immediately after clicking the Transfer button.

The authorization check fails with:


Authority-check for S_ASSET_TRF failed
Missing authorization: ACTVT = '02'
User: ASSET_USER01, Transaction: /IWFND/GW_CLIENT

We recently applied OSS Note 3245678 which included patch authorization changes for asset lifecycle management. I’ve run SU53 trace for affected users but the authorization object seems properly assigned in their roles. The role update was deployed last week through PFCG mass transport. What’s puzzling is that some users can transfer assets without issues while others with identical role assignments cannot. Is there a specific authorization sequence or additional object required post-patch?

2

I’ve seen similar issues after authorization patches. The S_ASSET_TRF object might not be the only culprit here. Check if the affected users have S_RFC authorization for the backend RFC calls that Fiori makes during asset transfer. Also verify that the service /IWBEP/IF_SB_DPC_COMM_SERVICES has proper authorization mappings in transaction /IWFND/MAINT_SERVICE. Sometimes the gateway service authorizations don’t sync properly after role transports.

3

Don’t add S_DEVELOP to business user roles - that’s a red flag for audit. The issue is likely in how the Fiori app is calling the backend service. Check if the app is using the correct OData service path. After patches, sometimes the service binding in /IWFND/MAINT_SERVICE points to the wrong implementation class. Verify the DPC_EXT class hasn’t changed and that the service is activated properly in both frontend and backend systems. For S_TABU_DIS, you might need to create a custom authorization object that restricts table access more granularly rather than giving direct ANLA read access.

4

Run ST01 trace alongside SU53. SU53 only shows the last failed auth check, but ST01 will capture the entire authorization sequence during the transfer operation. I suspect there’s a secondary auth check happening in the backend BAPI that’s failing silently. Also check table AGR_TCODES to ensure the Fiori transaction code is properly linked to the roles after the mass transport.

5

I’ll provide a comprehensive solution addressing the patch authorization changes, SU53 trace findings, and role update issues you’ve encountered.

Root Cause Analysis: The OSS Note 3245678 introduced authorization field-level checks that aren’t properly reflected in your transported roles. The intermittent failures indicate authorization buffer synchronization issues post-transport.

Step 1 - Authorization Object Correction: The patch added field-level authorization requirements to S_ASSET_TRF. Run transaction SU24 and check the authorization default values for transaction code used by your Fiori app. You’ll likely find that ACTVT field now requires values ‘01’ (Create), ‘02’ (Change), AND ‘23’ (Maintain) for complete transfer operations, not just ‘02’ as shown in your trace.

Update your roles in PFCG:


S_ASSET_TRF:
  ACTVT: 01,02,23
  ASSET_TYPE: * (or specific types)
  WERKS: * (or specific plants)

Step 2 - Gateway Service Authorization: The Fiori app requires proper gateway authorization mapping. Execute these steps:

  1. Transaction /IWFND/MAINT_SERVICE - select your asset transfer service
  2. Click ‘Add System Alias’ if backend system isn’t properly registered
  3. Under ‘Authorization’ tab, ensure these objects are maintained:
    • S_SERVICE with full authorization for your service name
    • S_ICF for the ICF node /sap/opu/odata/sap/ASSET_TRANSFER_SRV

Step 3 - Address SU53 Trace Findings: For the S_TABU_DIS requirement you discovered:

  • Don’t grant direct table authorization to business users
  • Instead, ensure the backend service account (technical user) has S_TABU_DIS for ANLA
  • The Fiori app should use this service account for backend calls, not the end user’s credentials
  • Check /IWFND/ERROR_LOG to verify the correct user context is being passed

Step 4 - Role Update Synchronization: After making role changes, you must synchronize authorization buffers:

  1. Run transaction PFCG for each modified role
  2. Click ‘Change Authorization Data’ → ‘Generate’ (even if no changes shown)
  3. Save and transport
  4. In production, run program RHAUTUPD_NEW immediately after import:
    • SE38 → RHAUTUPD_NEW
    • Execute with parameters: User = * (all users), Date = current date
    • This rebuilds authorization buffers without waiting for scheduled job

Step 5 - Verify User Assignments: For users who still can’t transfer:


SU01 → Select user → Display
Check 'Roles' tab → Click 'Authorization Data'
Verify 'To' date isn't expired
Check 'Change Documents' tab for recent role assignment changes

If validity dates are correct but issues persist, remove and re-assign the role (forces buffer refresh).

Step 6 - Post-Patch Configuration: Execute transaction SUIM → ‘Roles by Authorization Object’ → Enter S_ASSET_TRF

Verify all asset-related roles appear. If your custom roles are missing, the patch may have overwritten authorization defaults. Restore from your pre-patch backup of table AGR_1251.

Validation: Have affected users log out completely (not just /nex), log back in, clear browser cache, then test transfer. The complete logout ensures authorization buffer refresh. Monitor transaction SM21 for any remaining authorization failures.

This solution addresses all three focus areas: properly implements patch authorization changes, resolves SU53 trace findings without compromising security, and ensures role updates propagate correctly across your user base.

6

Thanks for the suggestions. I ran ST01 trace and found additional failed checks for S_TABU_DIS (table authorization) and S_DEVELOP. The trace shows the transfer process tries to read table ANLA directly, which requires S_TABU_DIS with ACTVT=03. This wasn’t documented in the OSS note. Should I add these objects to the standard asset user roles or is there a configuration issue?