h3. Introduction In the previous three parts of the blog series (ABAP calls Java via RFC (1): Introduction), we defined the scope and tools, setup the project by installing the required software, and created and adjusted the Software Components and Development Components to contain our actual code. In this part, we’re going to code the actual Enterprise Java Bean (EJB) which will encapsulate the functionality we’re exposing via the JCo RFC Provider Service. We will create an EJB 2.0 (more specifically: a Stateless Session Bean), and call it +RFCBlog+. It will be callable at RFC function module +Z_BLOG_RFC+.
h3. Create the EJB h4. Create the Bean Skeleton In the NetWeaver Developer Studio, switch to the J2EE perspective and right-click on the Development Component of type EJB called +blog/rfc/ejb+. Choose +New - EJB Session Bean 3.0+ to create an EJB Session Bean and call it +RFCBlog+. As default package, enter +de.thorstenster.blog.rfc+ as shown below. Please make sure not to activate the checkboxes for Remote and Local Business Interfaces. These are features of the EJB 3.0 specification, but the JCo RFC Provider service works with the EJB 2.0 specification and ignores these interfaces. We leave them out so as not to clutter up our project.
Click “Next” to reach the following screen. The Remote and Local Home and Component Interface offered here are features of the EJB 2.0 specification and the JCo RFC Provider Service uses them. For the EJB to work with the JCo RFC Provider Service, it needs a Local Home and Component Interface, so please activate the checkbox “Local” as shown below. 
After choosing “Finish”, the IDE generates a number of objects. Deriving their names from the name we gave our bean, +RFCBlog+, it has created the following objects (all in our package de.thorstenster.blog.rfc): * interface +RFCBlogLocalComponent +– This is the interface the JCo RFC Provider will see. We need to add a particular method definition to this interface for the JCo RFC Provider service to be able to work with it. * interface +RFCBlogLocalHome +which defines the bean’s create( ) method. As far as “business functionality” is concerned, the generated objects are mere skeletons. h4. Add Business Functionality In order to add business functionality to our EJB, we need to define a method in the Local Component interface +RFCBlogLocalComponent +and implement it in the bean implementation class +RFCBlogBean+. The JCo RFC Provider Service expects a method defined exactly as shown below in interface +RFCBlogLocalComponent+: public void processFunction(com.sap.mw.jco.JCO.Function function); If you’re getting build path errors here, switch to the Development Infrastructure perspective, right-click on DC +/blog/rfc/ejb+ in the Component Browser, and choose +Sync / Create Project – Sync used DCs+ as shown below. 
Add a method implementation (empty at first) in the bean implementation class +RFCBlogBean+: public void processFunction(Function function) { } The IDE isn’t able to resolve class Function because you probably haven’t added a required import yet, so please add it: import com.sap.mw.jco.JCO; If nothing has gone wrong, the build path errors will go away and you will be left with some warning about deprecation you can ignore for now. (For the details about the deprecation, please refer to note 975768 in the Service Marketplace.) The following implementation will cause the bean to act as a simple echo: It takes the value of importing parameter +IV_STRING+ and copies it to exporting parameter +EV_STRING+. Please note that we’re not handling the exception, nor are we putting much effort into metadata handling. I hope to cover these topics in a later blog – for now, I’m happy to present a crude but working walk-through. public void processFunction(Function function) { try { JCO.ParameterList input = function.getImportParameterList(); JCO.ParameterList output = function.getExportParameterList(); String ivString = input.getString("IV_STRING"); output.setValue( ivString, "EV_STRING"); } catch (Exception e) { // Not nice: Empty exception handler. "As sinners we are born..." } } h3. Maintain Deployment Descriptors Ah, deployment descriptors: I won’t comment on whether I like them or not. In the EJB project +blog/rfc/ejb+, two deployment descriptors will be needed.
h4. Deployment Descriptor ejb-j2ee-engine.xml The first deployment descriptor is created automatically with the project. In it, you define the mapping from EJB +RFCBlog +to JNDI-name +Z_BLOG_RFC+. This is going the name of the pseudo function module we’re exposing on the Java server. Consequently, this must be the exact name of the corresponding empty RFC function module in the ABAP system from which you’re going to call the Java server. h4. Deployment Descriptor ejb-jar.xml The second deployment descriptor is not created automatically. In order to create it, right-click on Deployment Descriptor in the Project Explorer view and choose “create ejb-jar.xml”. You will find the newly created +ejb-jar.xml +in the +ejbModule/META-INF+ folder in the project tree. In this deployment descriptor, you declare the EJB by giving its name (+RFCBlog+), the qualified name of the implementing bean class (+de.thorstenster.blog.rfc.RFCBlogBean+), and the session type (stateless). h3. Check JNDI tree If your EJB has been successfully deployed to the server, you can check if it shows up in the JNDI tree and, more specifically, if it shows up in the right place. To be visible to the JCo RFC Provider Service, it must show up under context name rfcaccessejb. This is where all the EJBs for the JCo RFC Provider Service show up with the pseudo function module name given in the JNDI-name parameter in one of our deployment descriptors. To check if the EJB is registered in the JNDI tree, start the NetWeaver Administrator and choose Problem Management – JNDI Browser. Now scroll down to context name rfcaccessejb and look for an object called Z_BLOG_RFC. Your screen should look as follows:
h3. Create the EJB h4. Create the Bean Skeleton In the NetWeaver Developer Studio, switch to the J2EE perspective and right-click on the Development Component of type EJB called +blog/rfc/ejb+. Choose +New - EJB Session Bean 3.0+ to create an EJB Session Bean and call it +RFCBlog+. As default package, enter +de.thorstenster.blog.rfc+ as shown below. Please make sure not to activate the checkboxes for Remote and Local Business Interfaces. These are features of the EJB 3.0 specification, but the JCo RFC Provider service works with the EJB 2.0 specification and ignores these interfaces. We leave them out so as not to clutter up our project.
Click “Next” to reach the following screen. The Remote and Local Home and Component Interface offered here are features of the EJB 2.0 specification and the JCo RFC Provider Service uses them. For the EJB to work with the JCo RFC Provider Service, it needs a Local Home and Component Interface, so please activate the checkbox “Local” as shown below. After choosing “Finish”, the IDE generates a number of objects. Deriving their names from the name we gave our bean, +RFCBlog+, it has created the following objects (all in our package de.thorstenster.blog.rfc): * interface +RFCBlogLocalComponent +– This is the interface the JCo RFC Provider will see. We need to add a particular method definition to this interface for the JCo RFC Provider service to be able to work with it. * interface +RFCBlogLocalHome +which defines the bean’s create( ) method. As far as “business functionality” is concerned, the generated objects are mere skeletons. h4. Add Business Functionality In order to add business functionality to our EJB, we need to define a method in the Local Component interface +RFCBlogLocalComponent +and implement it in the bean implementation class +RFCBlogBean+. The JCo RFC Provider Service expects a method defined exactly as shown below in interface +RFCBlogLocalComponent+: public void processFunction(com.sap.mw.jco.JCO.Function function); If you’re getting build path errors here, switch to the Development Infrastructure perspective, right-click on DC +/blog/rfc/ejb+ in the Component Browser, and choose +Sync / Create Project – Sync used DCs+ as shown below. Add a method implementation (empty at first) in the bean implementation class +RFCBlogBean+: public void processFunction(Function function) { } The IDE isn’t able to resolve class Function because you probably haven’t added a required import yet, so please add it: import com.sap.mw.jco.JCO; If nothing has gone wrong, the build path errors will go away and you will be left with some warning about deprecation you can ignore for now. (For the details about the deprecation, please refer to note 975768 in the Service Marketplace.) The following implementation will cause the bean to act as a simple echo: It takes the value of importing parameter +IV_STRING+ and copies it to exporting parameter +EV_STRING+. Please note that we’re not handling the exception, nor are we putting much effort into metadata handling. I hope to cover these topics in a later blog – for now, I’m happy to present a crude but working walk-through. public void processFunction(Function function) { try { JCO.ParameterList input = function.getImportParameterList(); JCO.ParameterList output = function.getExportParameterList(); String ivString = input.getString("IV_STRING"); output.setValue( ivString, "EV_STRING"); } catch (Exception e) { // Not nice: Empty exception handler. "As sinners we are born..." } } h3. Maintain Deployment Descriptors Ah, deployment descriptors: I won’t comment on whether I like them or not. In the EJB project +blog/rfc/ejb+, two deployment descriptors will be needed. h4. Deployment Descriptor ejb-j2ee-engine.xml The first deployment descriptor is created automatically with the project. In it, you define the mapping from EJB +RFCBlog +to JNDI-name +Z_BLOG_RFC+. This is going the name of the pseudo function module we’re exposing on the Java server. Consequently, this must be the exact name of the corresponding empty RFC function module in the ABAP system from which you’re going to call the Java server. h4. Deployment Descriptor ejb-jar.xml The second deployment descriptor is not created automatically. In order to create it, right-click on Deployment Descriptor in the Project Explorer view and choose “create ejb-jar.xml”. You will find the newly created +ejb-jar.xml +in the +ejbModule/META-INF+ folder in the project tree. In this deployment descriptor, you declare the EJB by giving its name (+RFCBlog+), the qualified name of the implementing bean class (+de.thorstenster.blog.rfc.RFCBlogBean+), and the session type (stateless). h3. Check JNDI tree If your EJB has been successfully deployed to the server, you can check if it shows up in the JNDI tree and, more specifically, if it shows up in the right place. To be visible to the JCo RFC Provider Service, it must show up under context name rfcaccessejb. This is where all the EJBs for the JCo RFC Provider Service show up with the pseudo function module name given in the JNDI-name parameter in one of our deployment descriptors. To check if the EJB is registered in the JNDI tree, start the NetWeaver Administrator and choose Problem Management – JNDI Browser. Now scroll down to context name rfcaccessejb and look for an object called Z_BLOG_RFC. Your screen should look as follows:
6 Comments
