how to control data retrieval in rfc programming?

[Former Member]

I am using the following code:

CALL FUNCTION 'ZGET_COSS'

STARTING NEW TASK 'COSS'

DESTINATION IN GROUP DEFAULT

PERFORMING get_coss ON END OF TASK

EXPORTING

• objnr = objnr

gjahr = gjahr

TABLES

tbl_coss = t_coss.

CALL FUNCTION 'ZGET_COSP'

STARTING NEW TASK 'COSS'

DESTINATION IN GROUP DEFAULT

PERFORMING get_cosp ON END OF TASK

EXPORTING

• objnr = objnr

gjahr = gjahr

TABLES

tbl_coss = t_cosp.

wait until count = 2.

----

---

• Form get_cosp

----

---

FORM get_cosp USING name.

• Get the result back from the RFC FM

RECEIVE RESULTS FROM FUNCTION 'ZGET_COSP'

TABLES

tbl_cosp = t_cosp.

• Confirmation that FM is done processing

count = count + 1.

ENDFORM. " get_cosp

----

---

• Form get_coss

----

---

FORM get_coss USING name.

• Get the result back from the RFC FM

RECEIVE RESULTS FROM FUNCTION 'ZGET_COSS'

TABLES

tbl_coss = t_coss.

• Confirmation that FM is done processing

count = count + 1.

ENDFORM. " get_coss

The ZGET function modules have simple select statements with all the key fields populated.

But this fails when there is a large volume of data as the RECEIVE part is getting triggered even before the function modules completes data retrieval - and the program dumps.

How to control this?

Thanks

[Former Member]

I am using the following code:

CALL FUNCTION 'ZGET_COSS'

STARTING NEW TASK 'COSS'

DESTINATION IN GROUP DEFAULT

PERFORMING get_coss ON END OF TASK

EXPORTING

• objnr = objnr

gjahr = gjahr

TABLES

tbl_coss = t_coss.

CALL FUNCTION 'ZGET_COSP'

STARTING NEW TASK 'COSS'

DESTINATION IN GROUP DEFAULT

PERFORMING get_cosp ON END OF TASK

EXPORTING

• objnr = objnr

gjahr = gjahr

TABLES

tbl_coss = t_cosp.

wait until count = 2.

----

---

• Form get_cosp

----

---

FORM get_cosp USING name.

• Get the result back from the RFC FM

RECEIVE RESULTS FROM FUNCTION 'ZGET_COSP'

TABLES

tbl_cosp = t_cosp.

• Confirmation that FM is done processing

count = count + 1.

ENDFORM. " get_cosp

----

---

• Form get_coss

----

---

FORM get_coss USING name.

• Get the result back from the RFC FM

RECEIVE RESULTS FROM FUNCTION 'ZGET_COSS'

TABLES

tbl_coss = t_coss.

• Confirmation that FM is done processing

count = count + 1.

ENDFORM. " get_coss

The ZGET function modules have simple select statements with all the key fields populated.

But this fails when there is a large volume of data as the RECEIVE part is getting triggered even before the function modules completes data retrieval - and the program dumps.

How to control this?

Thanks

[ian_maxwell2]

I've used asynchrnous RFCs with return data several times without issue. A few questions:

- What exactly is it saying in the dump?

- How has the server side of the RFC been developed? Is it SAP/ABAP or another platform that is exposing itself via the RFC SDK?

- Do you know if there is a timeout occuring on the RFC call?

If it is an RFC implimented on the SAP/ABAP platform (i.e. you are using this in order to do divide and coquor processing by doign the two selects in parallel) then the calling program is either a background process or a dialog process but the called function is always running in a dialog process. Based on this you can sometimes have timeout issues on the called function module due to the time-out limit allowed for a dialog process.

Some more questions:

- What is the time-out limit for dialog processes in your system?

- How long is it running before it dumps?

~Ian

[Former Member]

This is data selection with in the same system. Since the volume of data is pretty huge, just thought of this task approach.

The dump does not really say much except that DBIF RSQL error.

It fails as soon as it hits the RECEIVE step. And it reaches the RECEIVE step within a couple of seconds.

Thanks

[ian_maxwell2]

hmmmm... Wish I was more help on this one, I haven't seen that happen before like that...

Do you know how much data it is attempting to pass back?

Is the RFC executing on the same instance as the caller? The reason I ask is that if it is there could be an incompatibility of version of the RFC specification.

~Ian

[Former Member]

Ian,

It is on the same server.

it is trying to retrieve some 1 million records belonging to 25000 orders.

[ian_maxwell2]

I don't think I've ever used this feature with that size of data. So you might be hitting somesort of internal issue with regards to the RFC protocol or memory restrictions on the two processes

Can you use a further divide and conquor the approach where you make a series of multiple calls to the RFC where on each call you are looking at a smaller subset? For example retrieving at most 1000 orders at a time and adding a where clause such that you are getting the next set of records greater then the last set that you had?

~Ian

[Former Member]

Ian,

I ama ctually putting this back into a regular process - no rfc calls or what so ever and will execute this in back ground.

I have a couple of other cases where the data is even larger.

Thanks for the dialog.

[karol_seman]

maybe the solution for you is to use select statement

SELECT u2026 UP TO n ROWS 

because only the requested number of data records are transferred from the database to the application.

so you add new input parameter to your FM like how much rows you want to return, resp. you can use this logic to implement from to n rows ...

[Former Member]

Resolved by eliminating the RFC access and reading the tables directly