Skip to Content

Introduction

Welcome to the third part of this blog series about calling Java EE functionality from ABAP. In the ABAP calls Java via RFC (1): Introduction we set our goal and defined the tools we are going to use, and in the ABAP calls Java via RFC (2): Setting up the Project we talked about downloading and installing the required software (AS Java, AS ABAP, and NWDS).

In this part, we’re working in the NWDS Development Infrastructure perspective and create a Software Component and two Development Components which are going to contain our development. We will model the dependencies of the Software Component and Development Components, thereby making it easy for you to transfer this tutorial to an NWDI-based development scenario.

1. Create software component RFC-BLOG

Open perspective Development Infrastructure.

Under “Local Development”, create a new Software Component.

 Please maintain its properties as follows.

For this Java EE project in which we’re going to create DCs of type Enterprise Archive and Enterprise Java Bean, our SC needs only SCs ENGFACADE and SAP_BUILDT. If you want to add other types of DCs such as Web Dynpro later, you will need to add dependencies from other software components. (For a matrix showing which SCs are needed for which type of development, please consult note 1080927.)

2. Create Enterprise Archive  DC /blog/rfc/ear

Right-click on the new Software Component to create a new Development Component. Select type “Enterprise Application” and name it /blog/rfc/ear.

Do not accept the system’s suggestion to switch to the J2EE perspective, because we’re going to create another Development Component before we switch into the programming environment.

3. Create an EJB Module DC /blog/rfc/ejb

In the same SC, create another DC of type “EJB Module” named /blog/rfc/ejb. Again, refuse to switch to the Java EE perspective.

4. Declare the dependency at DC level

Now we need to declare dependencies between the two DCs. These will result in the EJB DC being bundled with the EAR DC.

Right-click on the EAR DC and select “Show in – Component Properties”.

In the Component Properties view, select tab “Dependencies” and click on “Add”.

In the resulting pop-up window, select the EJB DC you created earlier.

In the following window, mark all three checkboxes on the right side.

Please note that our new EJB DC already has two public parts even though we didn’t create them explicitly. For EJB DCs, these are automatically generated. Public Part “client” contains the interface definitions of EJBs within the DC for use by remote or local clients. Public Part “ejbjar” is for EAR DCs which bundle the EJBs at build time.

5. Add project-specific dependencies

As a specific requirement for our current project, we need the Core JRFC API of the server. For the Jco RFC Provider Service to be able to expose our EJB, we must add a dependency from our EJB DC to DC tc/bl/jrfc/api which is located in Software Component ENGFACADE.

Since ENGFACADE is an SC for which we have already declared a dependency in our own SC, we don’t need to change our SC but can go directly to the Component Properties view of our EJB DC.

In the Dependencies tab, select “Add”. Now choose DC tc/bl/jrfc/api by searching for “*jrfc*”. Add the new DC to be referenced and mark all three checkboxes in the following screen.

Wrapping it up

This is it for today. We have created a Software Component and two Development Components, for which we have declared all dependencies from required Development Components.

A look at our EAR DC in the Component Navigator view shows the resulting software structure at the DC level.

Previous Parts

ABAP calls Java via RFC (1): Introduction

ABAP calls Java via RFC (2): Setting up the Project

In the next part…

…we will work in the J2EE perspective and create an Enterprise Java Bean. The EJB will encapsulate the functionality we’re going to expose and call from the ABAP server.

To report this post you need to login first.

5 Comments

You must be Logged on to comment or reply to a post.

    1. Louis Taljaard
      Apparently the need for a stub/signature/skeleton function module on the backend system is a common requirement for Java RMI (e.g. with Business Connector) – I didn’t know that!
      (0) 
      1. Thorsten Franz Post author
        Hello Louis,
        after a bit of research, I found that instead of having the skeleton function module you can also use a metadata repository on the Java side to achieve looser coupling between ABAP and Java.
        I’m currently looking for information on using custom metadata repositories in a JCo RFC Provider service scenario (as opposed to Java calls ABAP and ABAP calls Non-J2EE-Jco), but it’s hard to find anything.
        Cheers,
        Thorsten
        (0) 

Leave a Reply