Online Tutorials & Training Materials | STechies.com
Register Login

Preliminary steps in analyzing RFC (Remote Function Call) connections Interview Questions and Answers

|| 0

Preliminary steps in analyzing RFC (Remote Function Call) connections Interview Questions and Answers
Stechies

FAQ: Preliminary steps in analyzing RFC (Remote Function Call) connections

[1] Question: Which errors indicate connection problems?

One of the following messages or types of system behavior often indicates that a connection has terminated:

  • Dialog box appears on the frontend: disconnection
  • Connection reset by peer or WSAECONNRESET in trace dev_rd
  • Connection timed out in trace dev_rd
  • Connection to partner broken in trace dev_rd

If the frontend simply disappears, this indicates that there is an error in the frontend. In this case, assign your message to the BC-FES-GUI component.

 [2] Question: What are the preliminary steps of the analysis?

All of the above described messages must be followed up with an exact description of the error and the communication partners involved, as well as instructions on how to replicate the system behavior.
You can considerably reduce the time required to analyse and eliminate the connection errors by answering the following questions.

[3] Question: What information do I need about the connection? 

For closer examination of the connection, you also require information on the forwarding components and software used in addition to the communication end points (frontend, R3-System ...), for example:

  • Frontend or external program
  • Communication in the LAN or WAN
  • Router
  • Saprouter
  • Firewalls
  • VPN (Virtual Private Network)
  • NAT (Network Address Translation)

Details such as host names, operating systems used, IP addresses, system names and instance numbers are required for all components used.

[4] Question: How can I recognize the appearance of the malfunction?

The following details are important in recognizing the malfunction:

  • Frequency of occurrence
  • Random or repeatable occurrence
  • Occurrence during transfer of large datasets
  • Occurrence in conjunction with particular transactions
  • Occurrence after a phase of inactivity
  • Number of users involved
  • Occurrence of messages simultaneously on the application server and the frontend (communication partner)

[5] Question: How can I replicate the malfunction?

To maximize the information available, you will need to provide exact instructions. This is to allow detailed traces to be written, ... for example:

  • Call transaction "ABCD"
  • Select the "xyz" button and enter "1234" in the "fdsa" field
  • Select "Save"
  • ...

[6] Question: Do I have the current/required software version?

In addition to the current Support Package, the RFC library (librfc) version for external programs, kernel patch level and qRFC version with their supplements are also important. Note 545784 lists the relevant secondary details for the current versions.

[7] Question: Could my network be causing the malfunction?

To test the underlying network structure, an SAP tool called "niping", which one works on the network interface layer (NI layer) can be used, in addition to the conventional network tools such as a ping script or traceroute (tracert). This tool allows you to execute various datasets and long-term tests. For more details:
Note 500235, Network diagnosis with NIPING
Note 155147, WinNT: Connection reset by peer
The results of carrying out these two tests are of particular interest to us.

[8] Question: How do I obtain more information on the connection?

You can create traces for the different levels of the frontend, gateway, RFC, CPIC and other components of the connection.

For more details, see the following notes:
65325 Error and trace files for RFC
532918 RFC trace generation (..)


Related Articles