Skip to Content
Technical Articles

Call a Remote Function Module (RFC) From SAP Cloud Platform ABAP Environment

I got recently involved in ABAP Restful Programming and while SAP provides excellent tutorials for this matter (see SAP’s Tutorial Navigator), I was struggling with one very basic task – calling an on-premise function (or RFC) from the Cloud Platform ABAP Environment. Here again SAP provides a tutorial (see Call a Remote Function Module From ABAP Environment), but I had a real hard time to get it to work. This was my motivation for the following blog post.

First some important prerequisites (because I noticed these myself just late somewhere in the fine print after spending [wasting] some time trying things in my own trial accounts)

  • You need a Global Enterprise Cloud Account – i.e. not just a trial account
  • You need this for both, the SAP Cloud Foundry and the SAP Cloud Neo environment
  • SAP Cloud Foundry and the SAP Cloud Neo need to be in the same region

While SAP is providing generously trial accounts with pretty much all features for Neo and for Foundry, there is one essential feature missing in Foundry – the ABAP Service Instance does not allow to manage communications (i.e. the Communication Management group is not provided in the Dashboard).

So if you have access to an enterprise cloud account and you are interested in RFC calls from the Cloud Platform ABAP Environment to on-premise, then the following is for you.

In a nutshell, there are the following steps to perform:

  • On-premise

    • Install SAP Cloud Connector
    • Configure Cloud Connector to connect to your SAP Cloud Neo Subaccount
    • Grant RFC access in Cloud Connector to your on-premise SAP system(s)
  • SAP Cloud Neo Subaccount

    • pretty much nothing todo – perhaps just verifying if the Cloud Connector is indeed successfully connected
  • SAP Cloud Foundry Subaccount

    • Create a Communication System – this is the link from Foundry to Neo
    • Create Communication Arrangements – one to “arrange” the connection to the created Communication System, and another one to arrange a connection to your Destination Service Instance
    • Define your Destinations for the RFC call(s) in the Destination Service Instance
  • Eclipse / ABAP Cloud Project

    • Implement the required ABAP code to obtain the destination for your RFC call

I’m not going to talk about the installation and configuration of the SAP Cloud Connector, as I assume you are already familiar with this task – or if not, there is much information out there already. No need to repeat …

But the tasks to be done in the Foundry is what I will describe in detail. I’m however not repeating the steps to “get started”, i.e. how to create the ABAP Service Instance, how to create the Destination Service Instance nor how to connect with Eclipse to just your ABAP Service Instance. You need to be familiar with this part. Therefore you must have mastered already the first challenge and output the Hello World to your Eclipse console. (which is really easy)

Having this completed, you might know as well how to reach the ABAP Dashboard. The ABAP Dashboard is where we need to define our Communication System and our Communication Arrangements. This is how to access the ABAP Dashboard: In your Foundry Subaccount you go to your Space (in my environment named DEV) in which your ABAP Service Instance is running

A new browser tab opens and you are in your Dashboard (perhaps bookmark your Dashboard as you will frequently return to it). Navigate to group Communication Management and find the tiles for Communication System and Communication Arrangements.

Our first task is the creation of the Communication System. Remember – we are in a Cloud Foundry Subaccount and we want to reach the Neo Subaccount in order to utilize the Cloud Connector connection(s) to the on-premise systems. In a Communication System we define the technical information required for such communication, that is hostname, identity, user information, certificates, etc.

Click the Communication Systems tile and you will see a list of already existing Communication systems – if any, the list might still be empty. Click the New button and enter a System ID – I chose to call it NEO_XXX, as I’m creating here the “communication” to the Neo Subaccount.

On the next screen you will have to provide Host Name and Port. Here was the first time I was struggling with what exactly to enter. The correct value is the host name where your Neo Subaccount is running. There are several ways to find out:

  • go in your browser to your Neo subaccount and check the URL. It might look like this
           https://account.eu2.hana.ondemand.com/cockpit/….. 
    just take the part between account. and /cockpit, i.e. eu2.hana.ondemand.com
  • go in your on-premise system to the cloud connector and get the value from your Region Host

After having obtained the correct host name, the port is always 443.

Still in your Communication System scroll down to Users for Outbound Communication. Click on the + button and enter your user ID and password. Which user? The very one you use to authenticate yourself upon logging into the Cloud Platform. Not your email (which can be used as well for the Cloud Platform login), but the ID used in the member area. The same ID used as well in the Cloud Connector to establish the connection to the Neo host. In my case it is my S-user, for others it might as well be your P-user or whatever you got

Confirm your entries with the Create button and save your Communication System. Done! Now your Foundry Subaccount knows how to connect to your Neo Subaccount. All Cloud Connector connections registered in the Neo Subaccount can now be reached.

Return to your Dashboard home screen and we will now create our first of two Communication Arrangements.

With a Communication Arrangement, you enable the communication between your solution (our later Cloud ABAP application) and a service of another system (the Communication System we just created, i.e. the communication to our Neo Subaccount – which in turn gives us access through the Cloud Connectors to the on-premise systems).

In the Dashboard select the tile Communication Arrangements and on the following list screen select the New button. This popup will open.

use the value help to select the correct Scenario.

The Scenario you need to select here is SAP_COM_0200 – SAP Cloud Connector Integration. This is exactly what we want to achieve – integrate with our arrangement the access to the Cloud Connector. Selecting the scenario will copy its name into both the Scenario and the Arrangement Name. The Arrangement Name can be changed to be more meaningful – I changed it to CF_NEO_CC_COM (trying to say “Cloud Foundry to Neo Cloud Connector communication).

Click Create and find yourself on the detail screen of your arrangement

Here we identify first the Communication System – which is the communication system we created before. Click on the value help and select the NEO_XXX entry. Notice that the User Name in Outbound Communication was populated as well and that under Outbound Services the Service URL is filled as well. Of course – this information comes from the Communication System we just chose. Leaves the last important value to be provided – the Account Name.

Here are again two ways to get to the correct account name value:

  • in your Cloud Platform Cockpit go to your Neo Subaccount to the Overview and pick the value under Technical Name (highlighted in red below)
  • in your on-premise Cloud Connector get the value in column Subaccount (highlighted again in red)

The completed Communication Arrangement looks like this

 

Now we created the first communication arrangement letting Cloud Foundry know how to reach the Neo based Cloud Connectors. The next communication arrangement we need to create is about how to reach the destinations maintained in the Destination Service Instance. Before we can create this communication arrangement, we need first to create such a Destination Service Instance. For this you navigate in your Foundry Subaccount to your Space (in my case DEV) and go to Services – Service Marketplace 

On the next screen choose Instances, click New Instance and in the popup a wizard will guide you through the Destination Service Instance definition. Accept all defaults on the first 3 steps – just in the last step you need to give your Instance a name – I choose EXTERNAL_API

Save your Destination Service Instance by clicking Finish. Back on the overview select your new instance EXTERNAL_API and go to Service Keys. Click the button Create Service Key. Copy the generated service key to Notepad or similar – we need this key in a moment in order to create our next Communication Arrangement.

Now we need to return to the Dashboard (go to your ABAP Service Instance and click the Dashboard icon). Navigate to Communication Management and select Communication Arrangements. Click New

Choose again the correct scenario from the dropdown. This time it is SAP_COM_0276 – SAP CF Destination Service Integration. That is what we want to do this time – we want to create an arrangement to integrate the Cloud Foundry Destination Service Instance – the one we just created in the previous step.

Selecting this scenario, the popup changes and offers an additional input area for the service key.

Paste the service key you copied when the Destination Service Instance was created and change the Arrangement Name to something else than the default value SAP_COM_0276. I chose CA_EXTERNAL_API – meaning: Communication Arrangement for Destination Service Instance EXTERNAL_API

There is actually nothing else to do – the communication arrangement is fully defined. There is however one little detail I changed here – optionally.  I changed the property value Service Instance Name to the value CA_EXTERNAL_API_SIN – just in order to emphasize the importance of this property. The suffix _SIN I added stands for Service Instance Name – we will see in the later ABAP coding where this value is used (and not to be confused with the name of the Communication Arrangement !)

Before we can start coding our ABAP RFC to an on-premise backend system, we still need to define the corresponding destination (we created a Destination Service Instance before – but so far without any destinations). So we need to return to our Space DEV in the Cloud Foundry Subaccount, goto our Destination Instance Service EXTERNAL_API and create a destination.

Select New Destination and provide the data for your back end SAP system. Do not forget to maintain the Additional Properties

  • jco.client.ashost = < your on premise SAP host as defined in the Cloud Connector >
  • jco.client.client   = < SAP Client >
  • jco.client.sysnr   = < SAP System Instance >
  • jco.destination.proxy_type = OnPremise

 

Now we go to Eclipse and create a new ABAP class calling the RFC_SYSTEM_INFO function module from one of our on-premise SAP systems.

CLASS zcl_jm_rfc_sys_info DEFINITION
  PUBLIC
  FINAL
  CREATE PUBLIC .

  PUBLIC SECTION.
    INTERFACES if_oo_adt_classrun.

  PROTECTED SECTION.
  PRIVATE SECTION.
ENDCLASS.



CLASS zcl_jm_rfc_sys_info IMPLEMENTATION.
  METHOD if_oo_adt_classrun~main.
    DATA msg       TYPE c LENGTH 255.
    DATA lv_result TYPE c LENGTH 200.

    TRY.
        DATA(lo_rfc_dest) = cl_rfc_destination_provider=>create_by_cloud_destination(
                               i_name = |FSD_RFC|  
                               i_service_instance_name = |CA_EXTERNAL_API_SIN| ).

        DATA(lv_rfc_dest) = lo_rfc_dest->get_destination_name( ).
  
        CALL FUNCTION 'RFC_SYSTEM_INFO' DESTINATION lv_rfc_dest
          IMPORTING
            rfcsi_export          = lv_result
          EXCEPTIONS
            system_failure        = 1 MESSAGE msg
            communication_failure = 2 MESSAGE msg
            OTHERS                = 3.

        CASE sy-subrc.
          WHEN 0.
            out->write( lv_result ).
          WHEN 1.
            out->write( |EXCEPTION SYSTEM_FAILURE | && msg ).
          WHEN 2.
            out->write( |EXCEPTION COMMUNICATION_FAILURE | && msg ).
          WHEN 3.
            out->write( |EXCEPTION OTHERS| ).
        ENDCASE.

      CATCH cx_root INTO DATA(lx_root).
        out->write( lx_root->get_text( ) ).
    ENDTRY.
  ENDMETHOD.
ENDCLASS.

That’s it – test your code in Eclipse with F9 and see in Eclipse console the system info of your remote on-premise system.

Now you how you can consume any RFC enabled on-premise functions out of your cloud ABAP.

 

11 Comments
You must be Logged on to comment or reply to a post.
  • Hi Jurgen,

    nice blog! Thank you for sharing your experience with calling of on-premise RFC function module from SAP Cloud Platform ABAP Environment.

    Could you please kindly correct from “RAP” to “SAP Cloud Platform ABAP Environment” in the title and inside of the text in the blog to avoid misunderstanding by readers, since you are meaning SAP’s ABAP environment in the cloud. RAP ist  ABAP RESTful Programming Model defining the programming model of modern ABAP development, which is available on-premise with SAP S/4HANA 1909 and in the cloud with SAP Cloud Platform ABAP Environment.

    Thank you very much!

    Kind Regards,

    Olga.

      • Hi Jürgen,

        I wrote the tutorial – sorry to hear you are having problems. Two things:

        1. The tutorial is actually part of a mission; it wasn’t originally designed to be done stand-alone.
        2. The “key” icon in the tutorial title means “You must have a license”.

        However, I accept that the UI does not make this clear. The UI is designed centrally, so I will raise this as an issue with the team.

        Thanks for blogging.

        Best wishes,

        Julie.

        • Please do not feel criticized – if I had problems, then this might just show that I’m perhaps not that smart. After all SAP employs you and not me ….

          And (!) – without your tutorial I couldn’t have even started

          • Hi Jürgen,

            “this might just show that I’m perhaps not that smart”… No, I don’t think so! It’s very polite of you to say, but if the tutorial is not laid out in a user-friendly way, then that’s on me / the team ;-).

            I don’t feel criticized – your feedback was very helpful. The info about the regions is crucial – I will improve my tutorial accordingly.

            Any time you want to give feedback on my tutorials, please feel free – everybody wins!

            Best wishes Julie.

      • Hello Jurgen Meinshausen,

        Thanks for the blog post. I am also currently doing a project with ABAP restful model where i am using an RFC to fetch data from on premise. Here I am dealing with millions of records. But the Eclispe ABAP editor hangs when dealing with lot of records. How did you handle this situation if ever you have faced this issue.

        • Are you trying to display your fetched records in Eclipse? I believe every UI (think classic list report or ALV) would hang with millions of records. Apart from trying to display such volume anywhere – in any kind of UI – think as well about transferring such load over the internet, i.e. from on-premise to the SAP Cloud. SAP might have other tools for this purpose. On-premise SAP provides SLT for data replication. I’m not sure if there is an option for this as well to replicate into the cloud ….