cancel
Showing results for 
Search instead for 
Did you mean: 

SAPXPG Problems

Former Member
0 Kudos

Hi Experts,

OS: Linux RH4AS (x86_64)

SAP SRM 5.0, DB - Oracle 10.2.0.2

My jobs in DB13 currently are failing with the following error:

SXPG_COMMAND_EXECUTE failed for BRCONNECT - Reason: x_error

I am using a distributed environment with a standalone DB on one server and the CI on another server. I do <b>NOT</b> have a standalone gateway on the DB server and am trying to connect using remote calls. I have set the parameter gw/remsh to ssh.

What Works:

ssh between both servers have been setup and I can successfully test this from the OS level.

The <sid>adm user is setup on both servers with the same shell and permissions and I can access the DB server through ssh and run brtools functions.

The SAPDBHOST has been specified with the DB Server.

I have created an entry in SM69 for ssh and tested with SM49 successfully. Eg: If I pass the parameter ls -l, it returns with the list of files present.

/usr/bin/ssh -q srmdtst01 ls -al -


Works

/usr/bin/ssh -q srmdtst01 sapxpg ls -al -- Does NOT work.

What Does NOT Work:

SAPXPG when run with the above entry in SM69 returns nothing, which according to note 446172 is supposed to mean that everything is all right. But RFC SAPXPG_DBDEST_<DBSERVER> also fails the connection test. I've got Activation type in the RFC set to "Start on Explicit Host" and have even provided the full path to sapxpg on the DB Server. The RFC connection test fails with a "timeout during allocate".

What should I set the "start type of External Program" to in the RFC? Its currently set to Default Gateway Value but I've tried all the other options and it still fails.

Any other ideas on why sapxpg fails to start?

Regards,

Chengappa Ballachanda

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

Problem was that the server name was not fully qualified in the ssh known hosts file. This caused a "host key verification" failure causing the RFC to fail.

Regards,

Chengappa

Former Member
0 Kudos

Even nearly 5 years later this helped me in fixing the same problem. I did not use the fqdn when manually connecting through ssh.

Thank you for sharing!

Former Member
0 Kudos

Even 7 years later, this helpmed me fix this problem.
Thanks for sharing..

Former Member
0 Kudos

Big thank You - it helped me also after 2 days of struggle the solution was so easy.

Answers (3)

Answers (3)

Former Member
0 Kudos

Glad it continues to help even after all these years! ....Might put it up in a blog as well now.

Former Member
0 Kudos

9 years later, this helped me 🙂

Former Member
0 Kudos

8 years later, this helped me just one day before go live...

thanks for share