cancel
Showing results for 
Search instead for 
Did you mean: 

RFC Maintenance errors - can't create Read RFC?

bernie_krause
Participant
0 Kudos

We've recently upgraded to SP10 for SM 7.1, started going through Managed System config and ran across a problem with RFC Maintenance under Connect System step. 

When creating a Read RFC, I get the following sequence of messages with absolutely no error text, related to creating the Read and TMW RFC users on the managed system.

AUTHORITY_NOT_AVAILABLE (not always)

Establish connection to System <sid/instance> SID_CLient

Name or password is incorrect (repeat logon)

No RFC for system SID/Client

Seems to be trying to use passwords that I've entered even though I've entered none for that user ID - using the Generate user and Password option.  Error message at top of screen says "

The passwords specified must be identical

Display Help

Is this being buffered somewhere?  How do I clear this out?

Solman Admin and Managed System Config User credential tests pass, no issues there.

Managed System Config User has appropriate credentials as it can assign the correct role once the RFC user has been created.  Appears also to only be an issue with the Read user.

I know that manually creating the RFC and user ID works as I've done that in some of our lower systems that I have access to, but we don't have access to all of the higher systems to perform these activities due to security concerns, we need to have Solman RFC maintenance working properly. 

I saw some notes about this last week but did not make a note of the number and now I can't find the reference!!!  grr...  hate it when I can't find the correct search keywords or they're too common.

Appreciate anyone pointing out the notes/solution for this problem ("do it manually" doesn't count)

Thanks.
Bernie

Accepted Solutions (1)

Accepted Solutions (1)

francois_keen
Participant
0 Kudos

Hi Bernie

Just wanted to let you know that applying the central note 1875627 v17 , in my case, has solved the issue.

Best regards

bernie_krause
Participant
0 Kudos

Ok, thanks for the update.  We'll look at that too. 

Answers (1)

Answers (1)

tanmeya_mohan
Active Participant
0 Kudos

Hi Bernie,

In case of error "Authority_Not_Available", create/modify a role to add authorization objects "S_RFC" & "S_RFCACL" with full authorization to its corresponding fields.

Assign this role to the user ID you are using to login to solution manager as well as the managed system in which you are trying to generate the RFC(s).

These authorizations objects are required RFC administration in a managed system & is not a part of profiles "SAP_ALL" / "S.A_SYSTEM".

Try this & do reply in case your issue persists.

Best Regards,

Tanmeya

bernie_krause
Participant
0 Kudos

oddly enough that Authority_not_available only shows up once in a while.  We tried again today, ran a trace on the user ID that was used as the Managed System Config User and it showed errors relating to "generic table access by RFC to AGR_FLAGS and AGR_1016 tables, although it already had that access.  We even granted SAP_All to see if that would help.  It didn't

The User ID doesn't exist in the target system, the RFC doesn't exist in the Source system, but Solman won't create them. 

One thing I just noticed however - LMDB RFCs listed by SM59 shows 5 clients in the target system with RFCs from Solman, yet RFC maintenance screen only shows 3 clients with RFCs.  How is that possible?  What tables are used to populate the two functions?  Does RFC Maintenance not use SM59 information?  All of the RFCs work in Sm59, so it's not as if these are leftover from old clients that no longer exist.

bernie_krause
Participant
0 Kudos

Scratch that last comment about the 5 clients with RFCs.  2 of the clients had been deleted, but the connection test still works (how does that happen?) but the authorization tests failed, so I deleted the RFCs to the obsolete clients which were deleted. .

Now - I would expect that LMDB would reflect that as it says "RFC Destinations as Defined in Transaction SM59" , but apparently that is not true.  The RFCs still show up in LMDB, even though they are gone from SM59 and our SLD only shows the correct currently existing clients.

What is going on here???   Where is LMDB reading this information from?  Just did a resynch from SLD, no change, the extra RFCs are still showing up.  

grrr...

tanmeya_mohan
Active Participant
0 Kudos

Hi Bernie,

Just to provide you a little clarification on the working on LMDB & SLD of a SolMan system.

First of all you add a system to the SLD (for ABAP system, settings maintained in SLDAPICUST & RZ70 folowed by scheduling a job for regular execution | for JAVA system, HTTP destination SLD_DataSupplier is maintained followed by a Collect & Send data)

This collects & pushes the data of a managed system to SLD. As a result entries are available under Technical Systems in SLD. Check last updated date to verify.

This usually replicates a system in LMDB (might take some time) with having the name of Technical system same to its SID.

In case an entry was manually created using the SID before, the system is created with SID00001 in LMDB. The only difference is with the name, but nothing in its functioning.

Manual set-up of a Technical system in LMDB requires a Databse host to be set-up with correct IP & FQDN/hostname. Then create the Technical system (AS ABAP/AS JAVA) with a relation to the Database host. Sync with SLD to have updated information. This step brings the technical system to similar state as SLD automatically creating/replicating a Technical system in LMDB.

Thus in case of inconsistencies / failure to resync with SLD, a Technical system can always be deleted & manually set-up using the above approach.

Then one needs to manually set-up RFC(s) like READ, WRITE, TRUSTED, BACK etc. from LMDB under setion RFC Destinations -> RFC Administration.

RFC(s) generated only for the master clients are enough & are not actually required for all the existing clients.

For generation of RFC(s) a username & password with appropriate authorization (like SAP_ALL + S_RFC + S_RFCACL) let-us-say BKRAUSE needs to be supplied for both Solman system & the managed system to generate the RFC(s).

The user BKRAUSE is needed for login to both SolMan system & managed system to create users & RFC destinations, and is not actually maintained in any of the RFC(s).

Once this is done, a Product system needs to be manually created (usually with the same name - SID) & assigned to the Technical System in LMDB.

After this Verification Check needs to be performed for the assigned Product System, till the status is green. This step basically uses the generated RFC(s) to read the component information in the system & replicate it for the Product system in LMDB. Thus the verification check suggests the components to be assigned / removed from the Product system, and a re-check is done after appropriate modifications are done.

That is all what is required from SLD & LMDB perspective.

Hope it helps.

Best Regards,

Tanmeya

bernie_krause
Participant
0 Kudos

Tanmeya - that's actually one of the best writeups of SLD/LMDB that I've seen.    But...  that's not where my problem is.  We've had SLD/LMDB running quite smoothly now for a couple of years, have a good understanding of how it works. 

It really seems as if that RFC Maintenance page isn't working correctly.  I can't even create RFCs with specify user and password.  It gives the same error regardless.  Almost as if some entry has been buffered somewhere and won't regenerate.  I've cleared my cache, cleared buffers on the affected systems, no luck with anything.  And it's inconsistent.  From one SM system I can create to client 100 but not 110, with the other SM system I can create to 110 on the same managed system but not 100. 

If you look at the screen shot you can see that even with "do nothing" selected the system has inserted characters into the password fields and it keeps reinserting something there even if I clear them out with different options.  I don't remember that happening prior to our sp10 upgrade and this problem didn't exist prior to SP10 either. 

francois_keen
Participant
0 Kudos

Hi Bernie

I have exactly the same problem. This is the first time I refreshed my test managed systems since I've been on solman 7.1 SP10 and I got the exact same "No RFC for system <SID> client nnn" plus " Name or password is incorrect (repeat logon)". So yes, this strange RFC maintenance behavior looked to have been introduced with SP10 [before I was on SP07 and I didn't have the issue]

Just like you i think i also have a good understanding of how solman works but this time I'm very much stuck!

I haven't seen an OSS note with that problem symptom so far....

Have you managed to solve your problem or did you end up opening an incident with SAP?

Thanks and best regards

Francois

francois_keen
Participant
0 Kudos

Quick update.

I couldn't reproduce the issue in my solman dev environment though but i found a few OSS notes mentioning RFCs. I will apply the central note 1875627 v17 next week in my prod environment. Will keep you updated with the results.

cheers

Francois

bernie_krause
Participant
0 Kudos

Francois - I opened an OSS message.  So far no luck, it seems to work for SAP..      He did give me a list of notes to check, fairly lengthy.  I'll take a look through them, see what I can find.  Some deal with the role update problems, others with the status lights being incorrect..  who knows what they've got buried in them.

1944399 User Roles Cannot Be Updated in SOLMAN_SETUP

1894531 Check Configuration in managed system checks wrong roles

1864848 Issue with Custom role names in Check Configuration activity

2025811 Issues with RFC creation for managed system which is on 46C

1995491 Update of RFC destination with CUA locks user

1964058 SOLMAN_SETUP: issues in the RFC destinations status

Edit - to me 1944399 looks like the best candidate, although the others all clean up other issues with the role status lights. 

2025811 hasn't been released yet.

Thanks.

Bernie

bernie_krause
Participant
0 Kudos

Francois - take a look at note 1971260.  In my case the auth object SM_SMUA was missing from our SM_BASIC_SETTINGS role, AND from the SAP_SM_BASIC_SETTINGS role, although another version ZSAP_SM_BASIC_SETTINGS had it.  I granted myself that role and now it seems to work.

Something to check for, anyhow.

hth

bk