NiHLGetNodeAddr: hostname cached as unknown, although it is the server's public domain name

[jeaveme]

Hello.

First and foremost, kudos to the people who is developing this wrapper for the great work they are doing.

I think I am facing a pretty strange error while trying to connect to a SAP server. However, I am a pretty newbie to RFC. I am trying to connect from an Ubuntu 14.04 LTS server (pyrfc-1.9.5-py2.7-linux-x86_64 and SAP NW RFC SDK 7.20) to SAP through a SAPRouter, but this is the exception PyRFC keeps raising:

>>> conn = Connection(**conn_params)
Traceback (most recent call last):
  File "<console>", line 1, in <module>
  File "src/pyrfc/_pyrfc.pyx", line 164, in pyrfc._pyrfc.Connection.__init__ (src/pyrfc/_pyrfc.c:2685)
  File "src/pyrfc/_pyrfc.pyx", line 202, in pyrfc._pyrfc.Connection._open (src/pyrfc/_pyrfc.c:3312)
  File "src/pyrfc/_pyrfc.pyx", line 232, in pyrfc._pyrfc.Connection._error (src/pyrfc/_pyrfc.c:3532)
CommunicationError: RFC_COMMUNICATION_FAILURE (rc=1): key=RFC_COMMUNICATION_FAILURE, message=
LOCATION    CPIC (TCP/IP) on local host with Unicode
ERROR       hostname '<My server's public domain name>' unknown
TIME        Fri Mar 31 06:04:02 2017
RELEASE     721
COMPONENT   NI (network interface)
VERSION     40
RC          -2
MODULE      nixxhl.cpp
LINE        193
DETAIL      NiHLGetNodeAddr: hostname cached as unknown
COUNTER     4
 [MSG: class=, type=, number=, v1-4:=;;;]

It seems like the error is being produced by my server itself because it isn't able to solve its own name. This is weird, because the domain name is public and it can be solved from the shell without problems.

Thanks!

[bsrdjan]

The RFC protocol is TCP/IP based but does not hop across network segments as easy as HTTP, it is different. The "public domain name" is in regard to RFC protocol public only within the saprouter network segment, not outside.

Did you check if niping utility can reach the backend server ? If the niping test is positive, then the same saprouter and host working for niping, should work for RFC and pyrfc connection as well. You may also try with IP address. If the niping fails, a network/basis expert shall check why.

[jeaveme]

Thanks for your prompt reply! I'll follow your suggestion and I am going to do the niping check to see if the SAP server is reached.

[jeaveme]

Hello, dear @bsrdjan.

I could connect to the SAP backend successfully via niping, but the problem still persists with PyRFC. After checking the backend logs, it seems like the request didn't leave the local node.

According to the backtrace raised while establishing the connection, the problem has to do with the local name. However, /etc/hosts is properly configured and I can ping myself using this name without any problems.

How can I configure PyRFC to use the bare IP as origin? Thank you very much, I appreciate your help!

Kind regards,
Jesús Avellaneda

[mathewanil]

Hi Jesus,

I am facing a similar issue. Did you ever get a solution to this problem?

Anil

[jeaveme]

Hi, Anil.

I found out that I could execute remote calls from my local development machine, so the problem was in the server.

The sysadmins in my organisation made some debug and found some bug or incompatibility between IPv6 and SAP NW RFC SDK, so they deactivated IPv6 and got it working.

I hope that helps you, because this issue blocked me for a long time.

Kind regards,
Jesús Avellaneda

[bsrdjan]

Closed due to inactivity, looks like network config issue.

[JulianSincu]

@jeaveme
Thanks for sharing the information. Do you have any more details on the issue what exactly was wrong with IPv6?
Kind regards and thanks
Julian