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
Now when you go to NPL to check the user FIORIRFC, you'll see it was locked due to incorrect login
Checked the user change history to see when it was locked, which was long time ago on Apr. 27th
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
Now testing the SEGW again, still failed
Check the logs
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
Add the authorization to NPL developer role
Now retry SEGW in A4H, still failed, missing following authorization about table maintenance
We have no concerns to allow developers to change all these tables. So add auth group IWAD into S_TABU_DIS
Now try SEGW again in A4H, finally successful.
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)