Debugging SAP RFCs when using the SAP Adapter / SAP ADO.NET Provider

The RFC SDK supports the ABAP_DEBUG option, which allows you to break into the RFC ABAP code when invoking an RFC from your application. The SAP Adapter and the SAP ADO.NET Provider also expose this setting.

The main advantage of this - consider this scenario - you invoke an RFC using the SAP Adapter, pass in some input parameters, the call returns and you get the output values, and to your horror, find that the values are unexpected! Using the Abap Debug option, you can break into the Abap code, verify that the input values received by the RFC are the actual values you passed in to the adapter, and that the values being returned by the RFC are the same which the adapter gives you back in the response.

Note that in order to be able to break into the Abap code, you need to install the SAP GUI on your client machine (because the SAP GUI will act as the "IDE" displaying the ABAP code).

Another thing, when using the Abap Debug option, you might invoke an RFC named RFC_FOO, but when the SAP GUI starts up and breaks into ABAP code, you might find yourself in another RFC. The reason being - the adapter internally makes a few extra RFC calls to retrieve metadata. Hence, before your actual RFC_FOO call is invoked, the adapter might have made calls to RFCs such as RFC_GET_FUNCTION_INTERFACE, RFC_GET_STRUCTURE_DEFINITION, IDOC_RECORD_READ, IDOCTYPE_READ_COMPLETE, etc. Return from those functions in the debugger, and in a short while you should find yourself in the RFC of interest in the debugger.

The URI for the adapter when using the Abap Debug option is of the form:

sap://Client=800;Lang=EN@A/SAPSERVER/00?AbapDebug=True

The connection string when using the Abap Debug option from the ADO Provider is of the form:

ASHOST=SAPSERVER;CLIENT=800;LANG=EN;USER=blah;PASSWORD=blah;ABAPDEBUG=True;