JCA connections and FM caching

[Former Member]

Hi everyone

I have a Java application running on CE 7.1 that calls function modules in an ABAP system running on NW 7.0. There appears to be some kind of caching of FM signatures, etc. within the Java system, which causes major problems when the FM signature changes in ABAP.

For example: I have a function module with a single importing parameter and a single exporting parameter. There is a method on one of my EJB's that calls this FM. The FM is then modified to return an additional exporting parameter, and the Java code is modified accordingly. Now, when calling the FM since the changes were activated, it no longer works. After restarting the SAP system, everything is fine again.

This leads me to believe that something is being cached on the Java side and it's not calling the FM properly.

So here are my questions:

1. Is there some kind of caching on the Java system with regards to calls to ABAP function modules using JCA?

2. If yes to Q1, how can I get around this without having to restart the system?

3. If no to Q1, what might be going wrong here? (bear in mind that a simple system restart solved the issue - i.e. the same code that didn't work before the restart, did work after it)

Any help would be great!

Thanks

Stuart

[Former Member · Accepted solution]

Hello,

I know those kind of issues on NW 7.0 from programming web dynpro there. If you use the RFC destinations (instead of programming everythink on your own) there are some caches involved.

With web dynpro for example you always got the "warning" message to do a restart after changes on RFC's. And this warning was to be taken serious, as you got really "nice" effects if you didn't do that. For example if you had string variables you can see values intermixed. Thats because the JCo code reads by position from a binary data blob coming over the wire. And exactly this information where to find what in that blob is cached... By the way thats the reason why you have to configure for web dynpro always two connections. One for the data, one for the meta information...

So even its hard to do that, you may have to stick with restarting. At least on 7.0 there was no way around that caching for web dynpro and RFC.

Frank

[Former Member · Accepted solution]

Thanks Frank

I think this should be addressed by SAP though. We shouldn't need to restart the entire instance for something as simple as this. FM's change frequently during development, and restarting a development system every time is just irresponsible.

Can anyone from SAP comment on whether this will be addressed?

Surely we should be able to simply restart the JCA-related services? At least this will minimise disruption to other developers.

[Benny]

Hi Stuart,

it's not a stateless Session EJB, is it? If so, are you aware that those go to a pool after use and will come back from that pool in the state you put them in?

Stateless for Beans means you have to make sure that they lose state after being used that means you have to implement on of those lifecycle methods to make sure the data is deleted when the bean goes back into the pool.

This is standard EJB behaviour.

Regards,

Benny

[Former Member]

Hi Benny

Yes, it is a stateless Session EJB - but it truly has no state. There are only 2 class-level variables, which are both injected by the EJB container... otherwise I'm only using method level variables, which would go out of scope after each method call anyway. So there is no state to clean up in the lifecycle methods.

Or am I perhaps missing something else?

Thanks

Stuart

[Vlado]

No, this issue has nothing to do with SLSB pooling whatsoever. (BTW, there is no lifecycle method for SLSB to clean up "state" before returning them into the pool.)

I believe this is somehow related to JCo but I'm not an expert there. I've already asked a colleague who should be able to shed some light on this, but he's currently on vacation. Hopefully, he'll reply when he's back.

Regards,

\-- Vladimir

[Benny]

>

> BTW, there is no lifecycle method for SLSB to clean up "state" before returning them into the pool.)
> \-- Vladimir

ejbremove() should be still there, isn't it?

[Former Member]

Hi Vladimir

It'll be very helpful to hear from your colleague! Thanks for passing on the question to him.

I'm very interested to hear his thoughts.

Cheers

Stuart

[Vlado]

>

> ejbremove() should be still there, isn't it?

ejbRemove() (or PreDestroy callbacks in EJB 3) is called when the bean is removed from the pool or destroyed. This ends the life of the SLSB instance.

[Benny]

Interesting. Learnt something new....

I put some points on your accout though

Regards,

Benny