2

I have an issue with the SAP .NET Connector

I have built a web application (ASP.NET, C#) that connects to SAP BAPI procedure to fetch results from SAP database.

I have connected it to SAP BAPI procedure and it also fetches the results for the web application.

My issue is, during the first attempt it takes 25 to 30 seconds to fetch the results, but from the second attempt onwards the results are fetched with no time.

I don't know exactly why it is taking so long to fetch the results on the first attempt.

Can somebody help me with this?

James Johnson
  • 45,496
  • 8
  • 73
  • 110
kumar
  • 21
  • 2

4 Answers4

1

It's been a long time since this one was opened, but it can be solved (it's even pretty easy if you know what to to).

We've had the very same problem, above 10 seconds delay till a connection was established. Within the targeted servers SM21 transaction, the connection wasn't visible till the client got the answer.

I've captured a network trace and saw that it's indeed the gateway taking it's time between request and response. In the servers dev_rd log file (gateway debug log) appeared (after the initial delay) a pretty obvious entry:

Fri Aug  3 07:55:20:963 2018
NiHLGetHostName: to get [private-ip] failed in 12004ms (tl=2000ms; MT; UC)
*** ERROR => NiHLGetHostName: NiPGetHostByAddr failed (rc=-1) [nixxhl.cpp   514]

Trying to get a DNS answer for that IP failed through the nslookup tool as well. The following requests are way faster as the gateway seems to cache the negative-hits, but as soon as the entry times out, you'll experience the delay again.

Therefore:

  1. Configure your DNS server (add the private zones with in-addr.arpa for successful reverse lookup), so that the gateway doesn't have to run into a timeout.

or (worse, as the reverse lookup zones should be set-up anyway)

  1. follow sap note 1055602, to permanently deactivate the reverse lookup via the rdisp/reverse_name_lookup parameter.
Dominik
  • 111
  • 1
  • 7
  • This is indeed the correct answer. If the IP address of the client program is not resolvable within the network of the SAP system (e.g. because there is NAT going on between client and server), then the first reverse lookup will hang until it times out. However, I think instead of disabling the reverse lookup for dispatcher (which handles DIAG connections), you have to disable it for the gateway (which handles RFC connections). So the parameter would be gw/resolve_phys_addr=0 See note 1950696 – Lanzelot May 25 '23 at 19:48
0

I see this delay also, and it's definitely at the point we use the connector to establish a connection with SAP rather than anything to do with SQL.

I'm theorising it's because on the first attempt the connector has to establish the connection, authenticate and initialise its own connection pooling.

It will depend on how loaded your SAP box is and where it's located relative to your web server of course, but there doesn't seem to be any way around it completely that I've found.

Your best course of action is just to make the connection once then reuse it as much as possible.

Gareth
  • 2,746
  • 4
  • 30
  • 44
0

This is common behavior and is actually caused by SAP NCo retrieving the metadata for the BAPI first time around.

Once it has retrieved the metadata, it caches it for subsequent calls, which should be quick.

I regularly see first call times to BAPI_PO_CREATE1 of ~10 seconds, subsequent calls are ~1second.

Darbio
  • 11,286
  • 12
  • 60
  • 100
0

I observed a similar behavior, that means a performance problem when using SAP S/4HANA 2022 systems that were deloyed via SAP Cloud Appliance Library using public IP adresses. In our case the initial log on using ABAP Development Tools (ADT) based on Eclipse was very slow while subsequent requests were running fast. It turned out that the framework tried to resolve the internal ip adress of a client which failed for the first call. Subsequent calls were fast since the ip adresses (that means in this case the ones that failed) were cached. As a result in a subsequent call the framework does not try to resolve these ip adresses a second time. In newer releases than the ones referred to in the above mentioned note there is a second parameter that can be set that is specific to the SAP Gateway service (not to be mixed up with SAP Gateway). rdisp/reverse_name_lookup gw/resolve_phys_addr Both can be set to 0. And this also works using transaction RZ11 temporarly as long as the application server is not restarted. I set both parameters to 0.

Andre Fischer
  • 21
  • 3