Skip to Content
Awhile back, Piers wrote a weblog about RFC_READ_TABLE – my old faithful – what has happened to you? and as most developers within the SAP world know this is one FM that just can’t go away.

Recently though I came across another one that has proven to be invaluable to me. We have lots of different systems here and in my BSP Development I tend to find some reason to connect to all of them for data using RFC Destinations.

Well the other day I had major problems, it turns out that one my RFC destinations was basically dead but I had never bothered to do that much needed error checking in the programming, yes a slap in the face to me and not considered good programming.

So I began playing around with TRY ENDTRY and CATCH and ENDCATCH commands and all of that stuff then I thought, there must be a way to do this easier. So I started searching around in our 6.40 SP12 system and I came across a function module.


That is what I found and I just love it. Very easy to implement and to use, just make a quick call and check the SY-SUBRC value.

      destination = tmp
      TIMEOUT = 10
      TIMEOUT = 2
      OTHERS = 7.

    “* Do code here

Just have to give the RFC destination you want to verify, this is a parameter with the type STRING. Oh, another really nice feature is the TIMEOUT default is set to 60 (seconds) so you can really fine tune your connection settings to get the performance you want, I mean no sense in pulling a huge set of data over if your connection takes to long now is it?

There are several EXPORTING parameters you may find very useful as well. Although for me I just needed to ensure the system was there but I have recently started checking the available resources of the system before connecting to ensure a quick execution time.

Exporting Parameters


This little guy has proven to be a gem for me and so I thought I would share with everyone that doesn’t know about it. What’s really nice, I haven’t found any OSS notes telling me “NOT RELEASED FOR CUSTOMER USE”.

To report this post you need to login first.


You must be Logged on to comment or reply to a post.

  1. Former Member
    Hi Craig,

    Good weblog as usual. Even as a Technical consultant this “Developer Network” helps me a lot.

    Just had a quick check in the systems available to me at the moment. In our CRM system I saw 31 Jan 2001 as the date in version management, but I suspect it older then that date.

    Best regards,


  2. Renald Wittwer
    Hi Craig,
    very good weblog, thank you very much. I will use this FM.

    Another option to test if you can reach a RFC-destination is to use the FM RFC_PING. It is not as comfortable as RFC_VERIFY_DESTINATION, but it works, too. Perhaps it is a little bit faster 🙂

    Best regards

    1. Former Member

      I tried the RFC_PING as well but had trouble because of the timeout, with lots of RFC destinations to check it became a problem.

    2. Thomas Jung
      The problem with RFC_PING is that it doesn’t test authorizations.  I don’t know if RFC_VERIFY_DESTINATION does or not.  However if you are using Trusted RFC, this test of authorization to logon is very important. 

      The other thing you can do if you are making a remote call is to be sure and catch the two special exceptions:
            communication_failure   = 1  message msg_text
            system_failure          = 2  message msg_text

      These will return a message with the details of why either failure occured.  This catches connection failures, bad RFC Destination names, and even authorization failures.

      Another useful tool on this subject is the function module: RFC_GET_FUNCTION_INTERFACE_P.  It will pass back the function interface for any other function module. Combine this with the RTTS and you can do some cool things – almost achieving dynamic Remote Function Module interfaces.

      1. Former Member
        Thanks for the info Thomas!! I’ve not had to try this with Trusted RFC’s so I’m not sure how it’ll work out.

        I had down the CATCH on the exception but for some reason this FM just made more sense to me?

  3. Former Member
    Hi Craig,

    I have a problem with function module RFC_VERIFY_DESTINATION.
    I’m testing several desstinations using a loop. For the first destination I’ve selected a timeout of 5 Sekunden seconds. I’ve set a breakpoint on this destination. This causes the destination, as I have expected, to have a timeout. When I test the next destination with a timeout specification of 10 seconds, this destination also gets a timeout (even though this destination is available).
    If the test of the second destination is not executed because the task is still running in the first one – does the function module continue working with the same dialog process?
    Or is the problem that another dialog process is not available?

    During the testing process I also noticed that the first server returned the following error message:
    “timeout during allocate of registered program – TP JCO_JAVA init/busy for more than 60 sec”.
    So I waited for 60 seconds after the first timeout and the subsequent test for the second destination did not determine a timeout.

    Does this mean that there is an SAP setting in transaction RZ11 that you can use to decrease the 60 second timeout?

    1. Former Member
      If I remember correctly and this was ages ago there is a configuration setting for the default timeout, however whether the system starts a new dialog process or not I simply don’t temember. Perhaps one of the others still actively coding would know 🙁

Leave a Reply