Skip to Content

ABAP Calls Java via RFC (5): Configure the Connection and Run


First, apologies to everyone who worked through the ABAP calls Java via RFC (1): Introduction, only to wait a long time for the fifth and final part of the series to come out. I’ve been so busy with other things that my blogging activities came to a screeching halt. Now I’m up and running again. Thanks for being back, too.

In the ABAP calls Java via RFC (4): Implementing and Deploying the Enterprise Java Bean of the series, we created an EJB 2.0 Stateless Session Bean called RFCBlog and exposed it as an RFC function module which can be called from ABAP systems (and other systems using the Java Connector).

In this part, we will configure our Java and ABAP server to speak to each other, write a test report in ABAP to call the RFC module, and run it.

Configure the JCo RFC Destination

In the NetWeaver Administrator, go to “Configuration Management – Infrastructure – JCo RFC Destinations”

Create a new Destination named BLOG and enter the following values (adapt where appropriate):

  • Name: BLOG
  • Gateway Host: localhost (hostname of gateway, typically of the ABAP system)
  • Gateway Service: 3302 (typically 33 + System Number of the ABAP system)
  • Application Server Host: localhost (the hostname of your ABAP system)
  • System Number: 02 (the system number of your ABAP system)
  • Client: 000 (your ABAP client)
  • User: bcuser (service user in the ABAP system)
  • Password: minisap (password of your service user)

After saving the destination, you will see it in the overview, where you can start and stop it. You should restart it after each change you have made to the scenario, and when the Java server should re-establish the connection, for example after a restart of the ABAP server or if the ABAP server was unreachable during startup of the Java server.

Maintain the RFC Destination in the ABAP System

In transaction SM59, create an RFC connection of type TCP/IP. Choose “Registered Server Program” and enter the same Program ID you have used in the JCo RFC Destination on the Java side.

Enter the hostname and port number of the gateway. Typically, this will be the hostname of your ABAP system and 33 + System Number of the ABAP system.



Create the RFC Function Module

This function module is a stub: It is empty and will never be locally executed. It serves as a kind of proxy or placeholder for your code to program against, and provides metadata about the function module’s interface when a remote RFC call takes place. It is also possible to go without a local function module on the ABAP side, but you need to provide the metadata on the Java side in this case.

Define the importing parameter:

Define EV_STRING as the exporting parameter of the Function Module:

The source code of the function module is empty because it is only a stub.

*"*"Lokale Schnittstelle:

* It's only a stub


Create the Test Report

Our small test report calls the EJB and passes a character sequence as an inbound parameter. If the EJB works correctly, it will echo the same character sequence as its output parameter EV_STRING, which we will subsequently output on the screen.


*& Report  Z_BLOG_REPORT


  gv_string   TYPE char255,
  gv_rfc_mess TYPE c LENGTH 1024.

      iv_string             = 'Inbound String'
      ev_string             = gv_string
      system_failure        = 1  MESSAGE gv_rfc_mess
      communication_failure = 2  MESSAGE gv_rfc_mess.

  WRITE: / 'Return code:',   AT 20 sy-subrc,
         / 'Message:',       AT 20 gv_rfc_mess,
         / 'Result String:', gv_string(80).

Execute the Test Report

Run the test report to see if it generates the correct output.

What’s left to do

There are a number of things we have not covered but which you should consider when developing read applications.

  • Robustness and Error Handling – Handle exceptions properly and produce meaningful error messages for callers when something goes wrong
  • Security – Use the EJB security mechanisms provided by the container to ensure that only authorized users execute the EJB methods
  • User-mapping and single-sign on – Configure the systems so that logging and authorizations checks in the Java system are executed with respect to the user name and roles in the ABAP system
  • Sophisticated types – Work with more sophisticated RFC interfaces: Structures, tables, and so on.
  • Providing Metadata – Let the Java system provide metadata for the RFC so that the stub function module on the ABAP side will no longer be needed.
  • RFC types – Support advanced types of RFC calls from ABAP system. There’s an entire zoo of RFC types (aRFC, tRFC, qRFC, bgRFC, …), some of which may be used between the ABAP and Java system.
You must be Logged on to comment or reply to a post.
    • Hi Chad,
      I cannot try it under NW 7.0 because I don’t have a server and IDE with that release, but the coding of the EJB and the deployment descriptors should be the same for EJB 2.0, because they follow the EJB 2.0 specification.
      If you search on SDN, you’ll find some blogs and articles showing how to do it under NW 7.0 – I remember thinking that there’s plenty of information for 7.0 and none or little for 7.1. 🙂
      • Hi Thorsten,

        Thanks for the reply.  I don’t see the JCo RFC Destination link/functionality in the NW 7.0 version of the NW Administrator, which is what prompted my question (do you know if it should be there?).  Without that piece of the puzzle, I’m not sure I can accomplish this as I’m not sure what the Program ID would be in the SM59 connection.


  • Thorsten,

    Can you help me understand why you would want to do this?

    I thought SAPs direction was to use PI for these types of integration points?  Why wouldn’t you expose this functionality as a web-service or use RFC through PI.

    Why would my company spend money to buy and use SAP PI/XI if SAP is advocating to other customers to use RFC enabled FMs directly instead?

    Is there a particular use-case that helps you decide when this is the correct approach, and when using an integration scenario via PI is the correct approach?

    Are we reinventing the PI wheel here?  You have this simple scenario yet don’t have error handling, message resendability, etc.  In this solution you have proposed wouldn’t you have to code that in yourself?

    Please help me, and help my company make the right decision as to what SAP thinks its solution is for communicating with 3rd party systems in real-time!

    • My 2 cents – I have seen some clients often use RFCs for SAP to SAP calls, bypassing PI. But in all those cases, PI already had a heavy load for SAP – nonSAP interfaces. So I think the rationale there is to minimize overhead by skipping the middle layer. However, if there are many such point to point use cases, maintenance cost might become higher and PI might be the more logical solution.
      • Vijay — good comment, you make a long story short. Tomorrow or so, I will need a full blog post to present this argument and a few much weaker ones. 🙂
    • Hi Tim,
      Didn’t they tell you that PI is obsolete and no longer supported? Just kidding. 🙂
      Seriously, first please let me point out that I am not an employee of SAP, nor do I speak for SAP. They beauty of SCN is that it’s an open platform where non-SAP people from customers and independent software vendors have equal rights to share their opinions and experiences.
      Back on topic. Your questions are very good and you’re right in pointing out that one should seriously consider using PI or generally a central integration hub, enterprise service bus, middleware, or whatever you want to call it, instead of peer-to-peer calls, for the obvious advantages which I am sure I need not reiterate here.
      However, there are some use cases for direct RFCs even today. Some companies have good reasons not to use a middleware, and some do use a middleware, but allow exceptions in which it is bypassed by direct peer-to-peer interfaces. I’ll try to outline them in a blog post that is going to be online soon.
  • Hi!
    I’m trying to call an EJB from ABAP. This works fine as long as i don’t use importing or exporting parameters.

    Using this Java-Method:
         public void processFunction( JCO.Function func ) {
              File test;
              Writer fw = null;
              try {
                   test = new File(“/tmp/test.txt”);
                   fw = new FileWriter( test );
                   fw.write( func.getName() + ” \\ “);
                   fw.write( func.toString() + ” \\ “);
                   fw.write( func.getExportParameterList().toString() + ” \\ ” );                    
                   fw.write( func.getImportParameterList().toString() + ” \\ ” );
              } catch (Exception e){
              } finally {
                   try {
                   } catch (Exception e){

    i get the following output:
    ZAKEJB \ Name:   ZAKEJB

    The function call in ABAP looks like this:
        EXPORTING Param1 = ‘Test2.txt’
        IMPORTING Param2 = param
          system_failure        = 1
          communication_failure = 2.

    Can you help me? What do i do wrong? I need the parameters for my application.

    Axel Klein

    • Did you create an empty function in abap with the same name to define the import / export structure?

      As I was not able to see the stacktrace when something went wrong I wrote it to a textfile. I would try to do this and see which expeption occurs.

      Once there was a problem and after a system restart all went good. (But this could be luck.)

      Good luck and thanks to Thorsten for this great blog!

      • Yes i have an empty function in abap defining the import and expotr structure. Its name is ZAKEJB and it has one importing and one exporting named param1 and param2.

        But the output written to the text file sais that there are no parameters. No exception is thrown except a null-pointer when im trying do do fw.write( func.getExportParameterList().toString() + ” \\ ” ); which is ok since the parameter list is null …

        Any other ideas?

        Axel Klein

        • Well .. i found something like a solution. It seems that my system is too old. I did the same configuration steps on a new test system, a Netweaver 7.01, and everything works just fine. The old system is an Netweaver 7.00 SP 18.

          Sadly i found no note about it.

          Axel Klein

  • Thanks for the detailed configuration steps.

    Within a dual-stack environment, specifically PI, does this 5 step process need to be used?  My understanding of the PI architecture is that SAP developed communication between the ABAP and JAVA database schemas using JCo. So, is there a native ABAP FM to call the JAVA piece of the dual stack?

    The reason I ask – I would like to query the “XI_AF_MSG” java database table from ABAP and build a report based on the results of the query.

  • I know that this topic it was quite long time, but recently I need to implement XML Parser in EJB running on Portal which would be called from ABAP program. What I find it is impossible to passing parameters under structure format or Table to Java side. The function can only deal with primitive types but not structure or table type.


    Any suggestions ?