CODEWITHSUNDEEP
saprfcjco
Carlos DaSilva
Carlos DaSilva

Reputation: 101

Keeping SAP's RFC data for consecutive calls of RFC using JCO

I was wondering if it was possible to keep an RFC called via JCO opened in SAP memory so I can cache stuff, this is the scenario I have in mind:

Suppose a simple function increments a number. The function starts with 0, so the first time I call it with import parameter 1 it should return 1.

The second time I call it, it should return 2 and so on.

Is this possible with JCO?

If I have the function object and make two successive calls it always return 1.

Can I do what I'm depicting?

Upvotes: 1

Views: 945

Answers (2)

Lanzelot
Lanzelot

Reputation: 16595

The answer is yes. In order to make it work, you need to implement two tasks:

  1. The ABAP code needs to store its variable in the ABAP session memory. A variable in the function group's global section will do that. Or alternatively you could use the standard ABAP technique "EXPORT TO MEMORY/IMPORT FROM MEMORY".
  2. JCo needs to keep the user session between calls. By default, JCo resets the backend-side user session after every call, which of course destroys all data stored in that user session memory. In order to prevent it, you need to use JCoContext.begin() and JCoContext.end() to get a stateful RFC connection that keeps the user session alive on backend side.

Sample code:

JCoDestination dest = ...
JCoFunction func = ...
try{
   JCoContext.begin(dest);
   func.execute(dest); // Will return "1"
   func.execute(dest); // Will return "2"
}
catch (JCoException e){
   // Handle network problems, ABAP exceptions, SYSTEM_FAILUREs
}
finally{
   // Make sure to release the stateful connection, otherwise you have
   // a resource-leak in your program and on backend side!
   JCoContext.end(dest);
}

Upvotes: 0

vwegert
vwegert

Reputation: 18483

Designing an application around the stability of a certain connection is almost never a good idea (unless you're building a stability monitoring software). Build your software so that it just works, no matter how often the connection is closed and re-opened and no matter how often the session is initialized and destroyed on the server side. You may want to persist some state using the database, or you may need to (or want to) use the shared memory mechanisms provided by the system. All of this is inconsequential for the RFC handling itself.

Note, however, that you may need to ensure that a sequence of calls happen in a single context or "business transaction". See this question and my answer for an example. These contexts are short-lived and allow for what you probably intended to get in the first place - just be aware that you should not design your application so that it has to keep these contexts alive for minutes or hours.

Upvotes: 1

Related Questions