Hi All,

We have connection with SAP with USER ABC.
But calling SAP RFC with User XYZ.

When we test in Dev Env, the RFC ran with User XYZ but when we test in QA the same RFC is running with ABC and it dont have permissions to that RFC and failing with below error message.

com.wm.lang.flow.FlowException: Service failed with error: [ART.117.4002] Adapter Runtime (Adapter Service): Unable to invoke adapter service Z_PM_XXX_XXXX. [SAP.102.9000] JCo error: No RFC authorization for function module Z_PM_XXX_XXXX…

Can anyone please help me why the RFC is running with main User like with ABC in QA and why its running with XYZ in Dev.

Thanks all in advanced.

The default user of any RFC connection should have the sufficient rights to execute metadata lookups calls - this is also mentioned in the WmSAP User’s Guide.

Recommended best practice is to have only one RFC connection for each SAP system, and to override the user/password in the pipeline during runtime if more users are required.

If this is not feasible, then a ‘master repo connection’ with proper default user should be placed in a separate folder which depends on WmSAP, and all other connections to the same SAP system should be placed in other folder(s) depending on the ‘master folder’. This ensures that the ‘master connection’ is always loaded first and will then act as repository connection to all other RFC connections to the same SAP system.

Please note that this approach requires installation of WAR_9.7_Fix2 (or equivalent ART fix for other IS versions).

The order in which RFC connections are enabled during WmSAP adapter startup is crucial here. The first enabled connection to a SAP system XYZ becomes the ‘master repo connection’ for all other connections to the same SAP system XYZ. This mechanism became necessary to reduce the number of repo connections to just one, which can be significant in more complex
scenarios.

The start-up order of ART connections is arbitrary and not deterministic, it can depend on the order in which connections or folders have been created or modified, so the start-up order of the same connections can be rather different on different WmSAP installations or after a migration. Which means that the issue can occur on one system but not necessarily on the other although the connections are the same.

To make the start-up order of RFC connections deterministic, it is necessary to place the connections in folders and define a clear dependency between the folders, with the ‘master repo connection’ being placed in a folder which is directly dependent on WmSAP so that it is always loaded first, as described above.

The approach to solve the issue is like what Anurag has said. Most of the time due to a middleware server is shared by multiple parties/projects and different implementer, they tend to have different credential to SAP server. The connection used by metadata lookup with required the highest access to SAP server in order to execute without error. Otherwise if the connection that has only limited scope being used by meta lookup initially become the predominant connection, then the scenario will be encountered.

It’s advisable to define your SAP connections in a separate package, and this one depends on WmSAP.

For example:
WmSAP
zzSAP_conn (depends on WmSAP)
zzSAP (depends on zzSAP_conn)

With this, you can keep all your connections configuration intact and avoid this issue.

I believe there are knowledgebase articles in Empower that documented this as well.