on 04-30-2013 3:20 PM
I need advice how to best solve the following issue:
We have an APO system and ERP system which we connect with CIF.
For CIF we follow note
Authorization role for the SAP SCM ‒ SAP R/3 |
In addition we have BW on the APO and extract historical data from the ERP for DP forecasting.
We create the source system in APO BW in RSA1.
We follow note
SAP Note Number | Title |
BW-Authorizations for Remote-User in BW and OLTP |
CIF needs an RFC Destination from ERP to APO which needs to be called exactly as the logical system.
for example APOCLNT100
In this RFC destination we assign user RFCCOMUSER (user name is an example) as type communication and the role SAP_SCM_INTEGRATION_SCM.
The wizard in RSA1 creates the source system for ERP and also uses the same RFC destination from ERP to APO which is also called exactly as the logical system APOCLNT100.
But note 150315 recommends to use user BWREMOTE as user of type system in the RFC destination with profile S_BI-WHM_RFC.
So I face a conflict with the RFC destination from ERP to APO.
note 727839 recommends role SAP_SCM_INTEGRATION_SCM of type communiction and
note 150315 reccomends profile S_BI-WHM_RFC of type system
for the same RFC destination APOCLNT100.
Role SAP_SCM_INTEGRATION_SCM does not contain all authorizations of profile S_BI-WHM_RFC.
How has this problem been solved at other projects?
Note that you are not forced to use user BWREMOTE for BW. It is just an example and in the customizing you can propose the user name, but the destination is independent of that.
The destination must work and be authorized of course, regardless of which user is really enetered into it.
RFC destinations are system level connectivity in most cases and many applications using RFC will work better if the logical system name is the same as the destination name, but you are not forced to use it. You can also map the logical system name to a different technical RFC destination name if you want to or if the system connection scenarios are incompatible with each other.
For example... the one connection does not support the RFC login screen so you must use a fixed user in the connection, but an application requests trusted RFC for the connection with the current user. In this case you can split them.
Another example (for SOLMAN) is that one connection wants to perform simple monitoring of the target, but another wants to be able to navigate to it with SAPGui interaction and yet a third one is for the CUA. In this case you will have at least 3 connections as you dont want to mix the functionality and application authorizations in the target. On thhe client side you can then optionally use authorization object S_ICF to create "security zones" for the outbound destinations once you have split them,
But you should however try to keep the number of connection types to a minimum as you have to "house keep" them, so only split them if there is a functional or security requirement to split the user context for the call to the backend.
Cheers,
Julius
ps: you should use users of type SYSTEM and not COMMUNICATION!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Frank,
At our end, we added both the role SAP_SCM_INTEGRATION_DIMP and profile S_BI-WHM_RFC to a user account (e.g. RFCCOMUSER) created in the ECC system.This ECC user account is assigned to two separate ABAP RFC connections in APO system to manage CIF and BI related communications.
Thanks,
Rajesh
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
11 | |
4 | |
3 | |
2 | |
1 | |
1 | |
1 | |
1 | |
1 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.