cancel
Showing results for 
Search instead for 
Did you mean: 

ChaRM: Trusted RFC a must?

Former Member
0 Kudos

Hi!

1) Are the Trusted RFC a "must" within ChaRM approach, If Yes in which clients?

2) Which authorizations does the user for the RFC connection between SOLMAN and satellite system need (besides authorization object S_RFCACL)

Thank you very much!

Thom

Accepted Solutions (0)

Answers (2)

Answers (2)

0 Kudos

Generate the RFCs from SMSY transaction fro every client involved in ChaRM. THis will assign the necessart roles automatically.

Regards

Farzan

Former Member
0 Kudos

Hi.

I guess it's not mandatory but in most cases kind of annoying not to use Trusted RFC.

One example is the action "Logon to System" which is performed from within a Change Document. User may logon to the system where he wants to perform developement in without being prompted for user name and password.

Which basically is the answer to the question "in which clients?": all the ones you want to work in.

As for RFC authorization:

The users SOLTMW<SID><CLIENT> and SOLMAN<SID><CLIENT> for Non-Trusted RFCs are being generated and should get the correct profiles automatically.

SOLTMW<SID><CLIENT>

S_BDLSM_READ

S_CSMREG

S_CUS_CMP

S_TMW_CREATE

S_TMW_IMPORT

SOLMAN<SID><CLIENT>

S_BDLSM_READ

S_CSMREG

S_CUS_CMP

The users who use Trusted RFC should have objects S_RFCACL and S_RFC.

And of course all other authorizations they need for the work in the target system.

Hope this helps.

/cheers

Former Member
0 Kudos

Hi Christian,

many thank's for your response.

Is it possible to bundle the users SOLTMW<SID><CLIENT> and SOLMAN<SID><CLIENT> into one communication user SOLMAN?

Do we need other communication or dialog users?

Is the usage of tasks in task plan with log on the only disadvantage in case of usage none-Trusted RFC's? Or we have here more disadvantages e.g. problems with automatic collection and sending data from satellite systems to SOLMAN?

Former Member
0 Kudos

Hi Thom.

You can use one user for both connections if he got the appropriate authorizations in target system.

In tx. SMSY when generating those RFCs you may select option to use an existing user. It is not a must to use generated users.

Why don't you want to use Trusted RFCs?

I am not sure which connection is used to create/release transport requests in the target system. I guess it's the _TMW connection but not sure.

Ad hoc I can not think of any other RFC connection beside _TMW, _READ and _TRUSTED (and the default TMS connections) which may be of concern for ChaRM.

/cheers

Former Member
0 Kudos

Hi!

Thank you very much!

We would like avoid the following situation:

the user log ons into DEV system goes via Trusted RFC to SOLMAN and from there via Trusted RFC into PRD-system.

So with other words, we would avoid any Trusted RFC for productive system.

Do you how to close this gap?

Thank you very much!

Former Member
0 Kudos

Hi.

It's all about athorization. Someone needs a user AND auth. object S_RFCACL in the target system to use Trusted RFC for "system-hopping". Without that he/she will not be able to do so.

So someone without user in PRD or someone with user in PRD but without appropriate authorization object will not be able to use Trusted RFC.

And for all those who got an user in the target system(s) anyway why would you want to prevent those to use Trusted RFC system logon?!

It's not hard to avoid unrequested system access this way.

/cheers