Hi Nick,
I've not done the exact scenario you've described, but I have incorporated multiple systems with Business Client, Keeping ERP or Gateway as the leading system and using it as a central access point.
Select one system as your 'leading' system - most traffic through there and occasional use for the other stuff.
You may do this in a few ways; for business objects you're using URLs, and to realize that you put the URLs e.g. for reports or folders into your PFCG role. You can define dynamic URLs (as obviously you wont want to hard code them) in your PFCG role and using transaction SM30_SSM_VAR.
To pull in WDYA/Transaction codes from another system you do that using RFC destinations/system aliases (SM59 to define the RFC connection, then table SM30_SSM_RFC to define the alias) e.g. SAP_ERP, SAP_GTS, etc for any remote system. Then in your role menu in your leading system, import role/transactions from the remote system and using the system alias as your defining factor. Again this means you can transport the role through and not have to do any manual change.
Lastly you've got the other option; use SAP's long term roadmap and use SAP Fiori Launchpad to pull in content. In an ideal scenario you'd use Launchpad on a separate Front end system, and so you can pull in any function and use Launchpad to action it. One way to achieve is to use transaction LPD_CUST to define navigational content, calling stuff in remote systems using system aliases. Then create your own custom tiles, calling the LPD_CUST configuration as your target mapping, when we implemented this, we did so using variables to pass through the details of our report differences, e.g. BO report ID, etc.
That should give you a good starter for 6, some lessons learned from personal experience; using the RFC aliases defined in SM30_SSM_VAR and SM30_SSM_RFC, they are both tables that are not client specific. What this means is things work fine in production, as there should be only one of everything. If you have multiple clients in non-production systems you have to get creative and either only test your full security solution in one set of clients, or, do some manual manipulation (we used an LSMW) to rewrite the security aliases in your roles. We did this, but only in systems where security testing was not the primary purpose, therefore maintaining the integrity of the roles.
Authentication wise, once things were set up correctly, we never had an issue.
Best of luck,
Di
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.