When a program is running in SAP ECC, the "system stack" stores all global variable irrespective of what modules/programs are called in that single session.
When it's calling RFC-enabled Function Modules (FM), a new system stack is created in the called system and only the export parameters defined in the called FM can be retrieved in ECC when the called FM has finished.
Is there a way to access another system stack's global variables in ABAP?
For example, in my case:
The FM BAPI_MATERIAL_AVAILABILITY in the ECC system calls via RFC the FM BAPI_APOATP_CHECK in the APO system.
When the APO FM finishes, I want to access some global variables of the APO system stack apart from the parameters defined in the APO RFC Function module. I need to access GTC object reference in ECC system.
PS: normally we use below ABAP statement to access memory from same stack, but it doesn't work when the memory is in another system:
ASSIGN '(PrgmName)Globalvariable' TO FIELD-SYMBOLS(<lo_data>).
As the RFC connection is not automatically closed after the call, the memory of the user session is retained, right after this call, so you may call a custom RFC-enabled function module that you create in the APO system, that accesses the memory you wish and return its value. Note that an object reference cannot be passed via RFC.
So that you better understand, I adapted the official figure about memory areas to show how a RFC call reuses the memory when the connection is not closed between 2 ABAP systems:
Legend (arrows "1" and "2"):
At the first RFC call, a connection is opened, a new User Session is created, ABAP session and internal session. The global variables are stored in the block entitled "(Data) Object" inside the internal session. At the end of the call, the connection is retained, including the first internal session and its global variables.
At the next RFC call using the same connection (the existing connection is reused), the user session is reused (along with its ABAP and internal sessions) to execute the function module, consequently it may access the global variables of the previous call(s).
Related
How to get the name of the calling program from within an asynchronous remote function call (aRFC) ?
CALL FUNCTION 'BAPI_MATERIAL_SAVEREPLICA' STARTING NEW TASK lv_taskname
DESTINATION IN GROUP DEFAULT
The called BAPI triggers a user exit that I need to disable for this particular calling program. However, the local part of the stack is lost after the RFC and the name of the calling program on the local system is unknown.
The closest solution I could think of was disabling the user exit when the calling program is SAPMSSY1 (RFC calls), but that it not as accurate.
Maybe the parameter CALLER_PROGRAM of the function module RFC_GET_ATTRIBUTES. I'm not sure it works in all kinds of RFC calls.
I was trying to invoke BAPI_MATERIAL_DISPLAY functional module from SAP JCO, This is how i pass my input parameter.
function.getImportParameterList().setValue("MATERIAL", "10");
From my program output i got
The material 10 does not exist or is not activated.
If I execute BAPI_MATERIAL_DISPLAY using SAP logon, iam getting the entry. Using debugger I found that,
My input is going as 00000000000010. And so returning response.
Dunno, how to handle this in a proper way in SAPJCO.
I had directly passed the value 00000000000010 from SAPJCo and this time i got an error,
com.sap.conn.jco.JCoException: (104) JCO_ERROR_SYSTEM_FAILURE: Screen output without connection to user.
Hope SAP is opening a popup. Let me know how to solve both the issues in SAPJCO
Field Material has a conversion exit routine. See also its domain MATNR in the DDIC.
These conversion exits are always called automatically by SE37 but not when the Remote Function Module is called directly - like here from outside from a a JCo program.
So if the BAPI expects to get certain parameters in their SAP internal representation format (I don't know if this is the case here), then you have to do this data transformation on your own beforehand, either by doing this purely within an own routine at Java side, or by calling the appropriate conversion routines at ABAP side via RFC.
For more details on this I recommend to study SAP note 206068.
Regarding your second question with the error message "Screen output without connection to user", I guess that this BAPI expects to have a connection to an SAP GUI for displaying the selected data. With a remote function call you don't have a SAP GUI connection by default, but you can attach a SAP GUI to your RFC connection with JCo, namely by specifying the additional logon parameter jco.client.use_sapgui=1. For this to work, an SAP GUI frontend (either for Windows or for Java) also needs to be installed on your host where JCo is running, of course.
Using Geode 1.2 and 9.1 Pivotal native client the following code:
IRegion<string, IPdxInstance> r = cache.GetRegion<string, IPdxInstance>("myRegion");
return r[key];
then triggers an AfterCreate event for myRegion. Why does that happen when no data is created, only read?
Same here, never used Native Client. I agreed with what #Urizen suspected - you are calling r[key] from an instance of Geode that doesn't have the entry, so it pulls the data from other instance, which "create" the entry locally.
You have a few options here:
Performing an interest registration for the instance you are initiating the call using registerAllKeys() (doc here). There is a catch here: (might not be applicable for native client), in Java API, you have an option to register interest with an InterestResultPolicy. If you use KEYS_VALUES, you will load all data to local from remote on startup WITHOUT triggering afterCreate callback. If you choose KEYS only or NONE, you will likely have similar problem.
You can check for boolean flag remoteOrigin in EntryEvent. If it is false, it is purely local. In a non-WAN setup, this should be enough to distinguish your local operation from remotely initiated operation (be it a cache syncing or a genuine creation initiated by other cache). Vaguely remembering WAN works a bit different here.
I've never used the Native Client but, at a first glance, it should be expected for the afterCreate event to be invoked on the client side as the entry is actually being created on the local cache. What I mean is that the entry might exists on the server but, internally, the client needs to retrieve it from the server, and then create it locally (thus invoking the afterCreate for the locally installed CacheListener). Makes sense?.
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?
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.
The answer is yes. In order to make it work, you need to implement two tasks:
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".
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);
}
Can We initialize Win sock in DLL_DETACH ? actulay i want to send some data when a process get terminated(DLL_DETACH)
DLL_DETACH is actually DLL_PROCESS_DETACH.
It is possible (i don't think that's any mechanism to prevent it) but it's not recommended.
WSAStartup lies in ws2_32.dll. Here's a fragment from DllMain official doc (Remarks section):
Calling functions that require DLLs other than Kernel32.dll may result in problems that are difficult to diagnose. For example, calling User, Shell, and COM functions can cause access violation errors, because some functions load other system components. Conversely, calling functions such as these during termination can cause access violation errors because the corresponding component may already have been unloaded or uninitialized.
Also, from WSAStartup official doc (same Remarks section):
The WSAStartup function typically leads to protocol-specific helper DLLs being loaded. As a result, the WSAStartup function should not be called from the DllMain function in a application DLL. This can potentially cause deadlocks. For more information, please see the DLL Main Function.
As an alternative sending the data (including the overhead of initializing the socket engine, creating the connection, and uninitializing the socket engine) could be achieved at the end of main (WinMain).
Calling WSAStartup() in DllMain() will result in a deadlock due to the loader lock. WSAStartup() can result in DLLs being loaded.
A better solution would be to install a service that can do the sending for. Talk to the service from DllMain() using your preferred interprocess comms method (shared memory, named pipes, etc).