Issue Desc:
1.use Z305924 to lon on A4H.
2.use SEGW to register Odataservice to Gatewayhub(NPL system)
3.popup a error message.

Action have been done:
1.Use SM59 to test RFC destination NPL_BGRFC_DEST,
connection test is ok,remote log on is ok.

Error message:
Could not connect to the selected system. Check log for details.
Message no. /IWBEP/CM_SBLMTOOLS015

Diagnosis
The following errors might have occurred while connecting to the selected SAP Gateway hub system:

Communication failure, System failure

System Response
Could not connect to the selected system..

Procedure

Check the error log in the current system using the transaction /IWBEP/ERROR_LOG.

572c7d5f0e011.jpg

Issue Desc: 1.use Z305924 to lon on A4H. 2.use SEGW to register Odataservice to Gatewayhub(NPL system) 3.popup a error message. Action have been done: 1.Use SM59 to test RFC destination NPL_BGRFC_DEST, connection test is ok,remote log on is ok. Error message: Could not connect to the selected system. Check log for details. Message no. /IWBEP/CM_SBLMTOOLS015 Diagnosis The following errors might have occurred while connecting to the selected SAP Gateway hub system: Communication failure, System failure System Response Could not connect to the selected system.. Procedure Check the error log in the current system using the transaction /IWBEP/ERROR_LOG. ![572c7d5f0e011.jpg](serve/attachment&path=572c7d5f0e011.jpg)

Hey dear lxj2007499,

The reason is, the RFC connection NPL_BGRFC_DEST is not working properly.

When you check the definition of NPL_BGRFC_DEST, you'll see it's not a trusted connection, and hard coded with user name FIORIRFC with password. When you try testing 'Remote login', it popped up a logging screen which is not correct

572c8d394a4d7.jpg

572c8d3fd0f1c.jpg

Now when you go to NPL to check the user FIORIRFC, you'll see it was locked due to incorrect login

572c8d83c900c.jpg

Checked the user change history to see when it was locked, which was long time ago on Apr. 27th

572c8dca25cdd.jpg

Considering this user FIORIRFC has high privilege and was defined as a service type of user, so at this time we don't want to unlock it. Instead you may want to use the trusted RFC from A4H to connect to NPL, so here I'll change the RFC NPL_BGRFC_DEST to trusted RFC

572c8f96ae729.jpg

Now testing the SEGW again, still failed

572c90617d1cb.jpg

Check the logs

572c908b23eaa.jpg

So missing authorizations. Now we add these authorization into the roles. Please note that when the user LEO1 try to register gateway from A4H, the actual authorization failure is happening in the target system that connected via RFC, which is NPL

572c91cb3a6f4.jpg

Add the authorization to NPL developer role

572c9244dfcd9.jpg

Now retry SEGW in A4H, still failed, missing following authorization about table maintenance

572c92b3525e9.jpg

We have no concerns to allow developers to change all these tables. So add auth group IWAD into S_TABU_DIS

572c930b15382.jpg

Now try SEGW again in A4H, finally successful.

572c936035b34.jpg
572c9365a2a8e.jpg

Hey dear lxj2007499, The reason is, the RFC connection NPL_BGRFC_DEST is not working properly. When you check the definition of NPL_BGRFC_DEST, you'll see it's not a trusted connection, and hard coded with user name FIORIRFC with password. When you try testing 'Remote login', it popped up a logging screen which is not correct ![572c8d394a4d7.jpg](serve/attachment&path=572c8d394a4d7.jpg) ![572c8d3fd0f1c.jpg](serve/attachment&path=572c8d3fd0f1c.jpg) Now when you go to NPL to check the user FIORIRFC, you'll see it was locked due to incorrect login ![572c8d83c900c.jpg](serve/attachment&path=572c8d83c900c.jpg) Checked the user change history to see when it was locked, which was long time ago on Apr. 27th ![572c8dca25cdd.jpg](serve/attachment&path=572c8dca25cdd.jpg) Considering this user FIORIRFC has high privilege and was defined as a service type of user, so at this time we don't want to unlock it. Instead you may want to use the trusted RFC from A4H to connect to NPL, so here I'll change the RFC NPL_BGRFC_DEST to trusted RFC ![572c8f96ae729.jpg](serve/attachment&path=572c8f96ae729.jpg) Now testing the SEGW again, still failed ![572c90617d1cb.jpg](serve/attachment&path=572c90617d1cb.jpg) Check the logs ![572c908b23eaa.jpg](serve/attachment&path=572c908b23eaa.jpg) So missing authorizations. Now we add these authorization into the roles. **Please note that when the user LEO1 try to register gateway from A4H, the actual authorization failure is happening in the target system that connected via RFC, which is NPL** ![572c91cb3a6f4.jpg](serve/attachment&path=572c91cb3a6f4.jpg) Add the authorization to NPL developer role ![572c9244dfcd9.jpg](serve/attachment&path=572c9244dfcd9.jpg) Now retry SEGW in A4H, still failed, missing following authorization about table maintenance ![572c92b3525e9.jpg](serve/attachment&path=572c92b3525e9.jpg) We have no concerns to allow developers to change all these tables. So add auth group IWAD into S_TABU_DIS ![572c930b15382.jpg](serve/attachment&path=572c930b15382.jpg) Now try SEGW again in A4H, finally successful. ![572c936035b34.jpg](serve/attachment&path=572c936035b34.jpg) ![572c9365a2a8e.jpg](serve/attachment&path=572c9365a2a8e.jpg)

Project 'Clam' founder

1.65k
views
1
replies
0
followers
live preview
enter atleast 10 characters
WARNING: You mentioned %MENTIONS%, but they cannot see this message and will not be notified
Saving...
Saved
All posts under this topic will be deleted ?
Pending draft ... Click to resume editing
Discard draft