No 'processFunction' method found on RFM call - JNDI questions

Question

I have beens struggling with calling a Java RFM from ABAP.
ABAP makes the call with the name of the function all in upper case, apparently.  (Can anyone confirm that?)  Unfortunately, the bean name is in mixed case, and after deployment, the RFC engine is unable to find the function.  It was my belief that I could define a JNDI name for the Enterprise Bean>Session Bean>JNDI name.  However, when I do so, and then deploy, the name doesn't seem to appear in the JNDI directory using Visual Administrator.
Q1:  Is there soem series of operations that must take place in order for the bean's JNDI name to get placed into he directory, other than deployment?  It feels like the JNDI directory isn't really getting updated at deployment, but after I bounce the server...
At any rate, after much thrashing, restarting servers, etc., lo and behold! the JNDI name showed up in the directory root, and apparently the RFC engine was able to find it, because he quit dumping me off with 'function not found'.  However, now he's saying that the processFunction method is missing (which it's not). I'm wondering if I've generated the correct JNDI entry, and if not, what should I do to fix it?
Q2.  Here are the JNDI directory root entries for my JNDI name - do they look right?  (The string of periods don't exist - just trying to show indentation) How does this entry lead the RFC entry to my bean?
Z_RFC_EXAMPLE  (which is my JNDI name)
....[Class Name]: com.sap.engine.interfaces.cross.ObjectReferenceImpl
....[Object Value]: 95
I also found these entries in the JNDI directory: localejbs [Context]
...Z_RFC_EXAMPLE
........[Class Name]: <package>.<Z_rfc_exampleLocalHomeImpl0
........[Object Value]: NON Serializable Object 
I also found:
rfcaccessejb [Context]
....Z_RFC_EXAMPLE
......[Class Name]: javax.naming.Reference
......[Object Value]: Reference Class Name: localejbs/Z_RFC_EXAMPLE
Q3:  Are these entries enough for the RFC engine to handle a call from ABAP for Z_RFC_EXAMPLE and invoke my bean Z_rfc_exampleBean?  If so, how come he can't find my processFunction() method?  If not, how do I specify things for deployment so that he can find the right bean and method?
Sure hope someone out there can help on this; it's very frustrating...

Answer 1

Hi David,
> ABAP makes the call with the name of the function all
> in upper case, apparently.  (Can anyone confirm
> that?)
Function module names are always uppercase in ABAP, so the call will be in uppercase, too.
>  Unfortunately, the bean name is in mixed
> case, and after deployment, the RFC engine is unable
> to find the function.  It was my belief that I could
> define a JNDI name for the Enterprise Bean-->Session
> Bean-->JNDI name. 
This is true, the bean name doesn't matter actually, if you define the JNDI name of the bean as the uppercase name of the function module, which should be called. If the function module in the ABAP system is "RFC_CALL_J2EE", then the JNDI name of the bean, which handles the call, should also be "RFC_CALL_J2EE".
>However, when I do so, and then
> deploy, the name doesn't seem to appear in the JNDI
> directory using Visual Administrator.
>
> Q1:  Is there soem series of operations that must
> take place in order for the bean's JNDI name to get
> placed into he directory, other than deployment?
> It feels like the JNDI directory isn't really
> y getting updated at deployment, but after I bounce
> the server...
No, the server application (containing the beans you want to use to be called) must be deployed without errors <b>and</b> must be running. If both is true, the JNDI entries "contained" in the server application are added to the JNDI registry. You can check, if an application is deployed and running using the "Deploy" service of the visual admin.
>
> At any rate, after much thrashing, restarting
> servers, etc., lo and behold! the JNDI name showed up
> in the directory root, and apparently the RFC engine
> was able to find it, because he quit dumping me off
> with 'function not found'.  However, now he's saying
> that the processFunction method is missing (which
> it's not). I'm wondering if I've generated the
> correct JNDI entry, and if not, what should I do to
> fix it?
>
If the processFunction method is searched, the RFC provider service is able to find the bean, so the JNDI entry is correct.
> Q2.  Here are the JNDI directory root entries for my
> JNDI name - do they look right?  (The string of
> periods don't exist - just trying to show
> indentation) How does this entry lead the RFC entry
> to my bean?
>
> Z_RFC_EXAMPLE  (which is my JNDI name)
> ....[Class Name]:
> com.sap.engine.interfaces.cross.ObjectReferenceImpl
> ....[Object Value]: 95
>
>
> I also found these entries in the JNDI directory:
> localejbs [Context]
> ...Z_RFC_EXAMPLE
> ........[Class Name]:
> <package>.<Z_rfc_exampleLocalHomeImpl0
> ........[Object Value]: NON Serializable Object 
>
> I also found:
>
> rfcaccessejb [Context]
> ....Z_RFC_EXAMPLE
> ......[Class Name]: javax.naming.Reference
> ......[Object Value]: Reference Class Name:
> localejbs/Z_RFC_EXAMPLE
>
Yes, they're ok. The RFC provider service uses the "rfcaccessejb/Z_RFC_EXAMPLE" for the lookup. Since the service is able to find the bean, this problem is solved.
> Q3:  Are these entries enough for the RFC engine to
> handle a call from ABAP for Z_RFC_EXAMPLE and invoke
> my bean Z_rfc_exampleBean?  If so, how come he can't
> find my processFunction() method?  If not, how do I
> specify things for deployment so that he can find
> the right bean and method?
>
There are (at least) two important things for the method search to succeed:
1. The method signature has to be:
public <anyReturnType> processFunction(com.sap.mw.jco.JCO.Function.class) throws <exceptionList>
The return type and exception list don't matter, since they are not relevant for a method search via reflection.
2. The server application classloader must "know" JCO. So please ensure, that you have added the reference to the JCO library to you EAR project also, NOT only to your EJB module project.
Hope that helps.
Regards
Stefan