Quantcast
Channel: SCN: Message List - ABAP Connectivity
Viewing all articles
Browse latest Browse all 3125

Re: JCo client support for asynchronous RFC calls

$
0
0

Hi Johannes,

 

JCoRequest/Response is for synchronous RFC calls. If you want to use background RFC (asynchronous RFC), you need to

  • create one (or more) JCoFunction object(s) and fill their IMPORTING/TABLES parameters
  • create one JCoFunctionUnit object and add the JCoFunction(s) to it
  • add the queue name of the bgRFC queue, into which the function modules shall be inserted
  • call commit()

 

The commit() will send the entire LUW to R/3, insert them into the specified bgRFC queue and then return immediately. The bgRFC Scheduler will pick up the LUW from the queue at some point of time and then execute the contained function modules.

(You can query the backend system about the execution status of the LUW later via JCoDestination.getFunctionUnitState(). Basically it will tell you, whether the LUW is still pending, whether it has already been executed successfully, or whether it was executed and ran into an error.)

 

Note: a bit of care needs to be taken in order to ensure "transactional security", i.e. in order to ensure that the LUW neither gets lost nor gets executed twice:

  1. First, get the UnitIdentifier from the JCoFunctionUnit object and store it in a safe place (e.g. a DB).
  2. If commit() returns without any error, you can be sure that the LUW has been submitted successfully. Delete all the data of the LUW and the unit identifier locally and then call JCoDestination.confirmFunctionUnit() for that identifier.
  3. If commit() throws an Exception, you cannot be sure: the error could have happened on the way to the backend, so the unit might not have reached its destination, or the error could have happened on the way back, e.g. the unit reached the backend successfully and was stored in the queue and the error happened afterwards (e.g. network connection broke down on the way back). But it doesn't matter: just keep sending the unit again using commit() (e.g. once every hour or so), until commit() finally returns successfully. As long as you have not called confirmFunctionUnit() on that unit, the backend will just "ignore" duplicate units, if it already received that one successfully. Once commit() succeeds, you again delete your data and the unit ID and call confirmFunctionUnit(). After that, however, you must never repeat this unit, because the backend is no longer protected against this unit ID. If you repeat the unit after the confirm, you will create a duplicate!

 

This process is pretty similar to how tRFC (transactional RFC) works. I described this once, not for JCo (Java) but for the NetWeaver RFC Library (C/C++), but the concept remains the same, so you might benefit from reading it (and then "translating" it from C to Java and from tRFC to bgRFC):

https://scn.sap.com/docs/DOC-52888

 

Best Regards, Ulrich


Viewing all articles
Browse latest Browse all 3125

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>