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

 

 

Important – this Blog Post is obsolete as of September 9 2020 

see my updated Blog Post here

From that day forward the Cloud platform will support RFC calls to On-Premise systems for destinations maintained in the Cloud Foundry Subaccount. Special communication arrangements with the NEO platform will then not be required any more (as covered in this post below).

In addition, the NEO platform will be closed soon. NEO trial will be closed on Nov. 13th 2020. I’m not sure when the NEO Enterprise platform will be closed. In any case – NEO is not required any more. 

See my updated blog post how to implement an RFC call from ABAP in the Cloud Platform to ABAP On-Premise now, without NEO (much more simple !!).  

*********

Here is my original Blog Post which required special configurations between Cloud Foundry and Cloud NEO

 

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.