My new best friend, Mr. RFC_VERIFY_DESTINATION
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.
> CALL FUNCTION ‘RFC_VERIFY_DESTINATION’
EXPORTING
destination = tmp
TIMEOUT = 10
EXCEPTIONS
INTERNAL_FAILURE = 1
TIMEOUT = 2
DEST_COMMUNICATION_FAILURE = 3
DEST_SYSTEM_FAILURE = 4
UPDATE_FAILURE = 5
NO_UPDATE_AUTHORITY = 6
OTHERS = 7.
IF SY-SUBRC EQ ‘0’.
“* Do code here
ENDIF.
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
> *” EXPORTING
*” VALUE(RFCSI_EXPORT) LIKE RFCSI STRUCTURE RFCSI
*” VALUE(RFC_LOGIN_COMPLETE) LIKE SY-DEBUG
*” VALUE(DIALOG_USER_TYPE) LIKE SY-DEBUG
*” VALUE(CURRENT_RESOURCES) LIKE SY-INDEX
*” VALUE(MAXIMAL_RESOURCES) LIKE SY-INDEX
*” VALUE(RECOMMENDED_DELAY) LIKE SY-INDEX
*” VALUE(CHARSIZE) TYPE RFCOPT-RFCUNICODE
*” VALUE(UPDATED) TYPE CHAR1
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”.
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,
Alexander
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
Renald
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.
The other thing you can do if you are making a remote call is to be sure and catch the two special exceptions:
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.
I had down the CATCH on the exception but for some reason this FM just made more sense to me?
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?