Calling Methods Via RFC With a Generic Wrapper Program

If you’re an ABAP developer like me, chances are you’ve needed to call a method in a class that resides in another SAP ...

Contact us

If you’re an ABAP developer like me, chances are you’ve needed to call a method in a class that resides in another SAP system.  Since it is not possible to call a method remotely, we are required to create a remote-enabled function module wrapper containing the method call.  This leads to the creation of multiple new objects (function group and module) for each required method.  These objects add to the vast number of custom objects that need to be maintained long-term.  What if there was an alternative?

It turns out there is another option.  We can create a single remote-enabled function module that uses dynamic method calls.

This solution is not perfect for multiple reasons:

  1. Since dynamic method calls use reference variables and reference variables cannot be used in RFCs, we have to serialize the method parameters. This leads to a lot of overhead to call the function.  If the code needs to be called in multiple programs, it would likely be easier to create a custom one-off function module.
  2. It is, at best, very difficult to call classes with constructor parameters. The generic function module would need to know to call a constructor and then call the required method.  The same applies to classes with static methods that create the instance.

With those limitations in mind, here is the solution!

Note: the full code of each object is attached at the end of this blog.

The first thing is to create the “wrapper” remote-enabled function module.  I admittedly cut a few corners in error handling.  I’d recommend doing a better job in this area when implementing this in a productive environment.

These are the parameters:

Parameter CH_PARAMETER_TAB is an XML string of ABAP_PARMBIND_TAB, which is in the ABAP type-pool.  I will cover the XML serialization a little later in this blog.

ZTT_ABAP_EXCPBIND is the same as ABAP_EXCPBIND_TAB, which can also be found in the ABAP type-pool.  This needs to be declared as a DDIC object so it can be used in an RFC.

The first thing we need to do in the function module is to deserialize the method call parameters into the correct object type.  We will use a simple transformation for this.

The next step is to determine the method type.  If it is a static method, we can call the method directly.  However, if it is an instance method, we need to instantiate the object before we can call the method.  As I had mentioned before, this is where this instantiation could get very complex when there are constructor parameters or “factory”-type methods.

With this LV_LEVEL variable, which tells us whether it is a static or an instance method, we can call the method appropriately.

As you can see, we create the class instance prior to calling the method if the method level is instance.

After the method call, we need to re-serialize the parameters so we can send them back to the calling program.  As you will see in the calling program, all export, changing, and returning parameters are returned via the dynamic parameter table.

Now that the function module exists, let’s test it!

This test uses a static method (the sample code also includes an instance method).  Our example is method CREATE of class CL_XLF_DATE_TIME.  This is a simple method that returns the ISO date format from a standard SAP timestamp.

These are the parameters of the class.  We need to add these to a table of type ABAP_PARMBIND_TAB first.

These are the parameters of the class.  We need to add these to a table of type ABAP_PARMBIND_TAB first.

Adding the parameters to the table is simple.  A couple notes – first, the field VALUE is defined as a reference to DATA, so we need to account for that.  Second, note that the field KIND for field TIMESTAMP is type IMPORTING above and EXPORTING below.  This is how it would be defined in the calling program, so it needs to be the same here.  You will receive an exception of type CX_SY_DYN_CALL_ILLEGAL_TYPE if this is reversed.

Prior to calling the function module, we need to convert this parameter table to XML.  Note the addition of option “heap-or-create”.  Without this option, field VALUE will not serialize correctly.

Next, we call the function module.

If the RFC was successful, we should have the ISO date available in the return parameter.

Let’s run the program and see if it works…

Success!

If there is a method that needs to be called remotely by many different programs, it is likely worth the time to create a custom wrapper program that handles the parameters without serialization/de-serialization in order to save the additional overhead.  However, this can be a good solution to have in your production environment for the one-off requirements.

PDFs

Class ZCL_TEST_CLASS_INST

FM Z_CALL_METHOD_RFC

Report Z_CALL_DYNAMIC_RFC

Mike Berg

Mike Berg

Mike Berg is a Senior SAP Developer at Mindset. He leverages his 18+ years of experience across various SAP technologies and functional areas to bring optimal solutions for customers to light. Mike focuses on bringing the best user experience possible to users, which in turn maximizes ROI for the organization. He does this by emphasizing the correct technology, be it Fiori, Personas, or other, and by optimizing application performance and ease-of-use. Mike is a regular contributor to Mindset’s blog and development tips newsletter, as well as a speaker at SAP Sapphire and ASUG events.

Let’s make your SAP better, together.

  • This field is for validation purposes and should be left unchanged.