Introduction
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.
FUNCTION Z_BLOG_RFC.
*"-----------------------------------------------------
*"*"Lokale Schnittstelle:
*" IMPORTING
*" VALUE(IV_STRING) TYPE CHAR255 OPTIONAL
*" EXPORTING
*" VALUE(EV_STRING) TYPE CHAR255
*"-----------------------------------------------------
* It's only a stub
ENDFUNCTION.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
*&----------------------------------------------------*
REPORT Z_BLOG_REPORT.
DATA:
gv_string TYPE char255,
gv_rfc_mess TYPE c LENGTH 1024.
START-OF-SELECTION.
CALL FUNCTION 'Z_BLOG_RFC'
DESTINATION 'JCO_CE1'
EXPORTING
iv_string = 'Inbound String'
IMPORTING
ev_string = gv_string
EXCEPTIONS
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.
17 Comments
