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, you must 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 require long-term maintenance. What if an alternative is available?
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:
- 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.
- 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 present 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 return 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.
RFC
Adding the parameters to the table is simple. A couple of notes – first, the field VALUEs definition is 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 the calling program would define it, so it needs to be the same here. You will receive an exception of type CX_SY_DYN_CALL_ILLEGAL_TYPE if this is reverse.
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, the 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…
Call Dynamic Class / Method RFC
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
If you are interested in viewing similar articles, visit our blog, here.
View our LinkedIn, here.