cancel
Showing results for 
Search instead for 
Did you mean: 
Subscribe

Hello gurus,

We have a FM 'ZTEST1' which is called via STARTING NEW TASK gv_name IN GROUP p_group. This FM is executed in a DO ... ENDDO cycle. Each time when the FM is executed name of the task gv_name is different (it is a kind of counter). We have a global array of data and each time the FM is executed in the parameter IT_ITEM part of this global array is passed. (for example 1000 items) The FM is executed until all data of the global array is callculated. The problem is that when retreiving data in the subroutine END_OF_TASK system returns duplicated data. I.e. when retreiving data for the 1st task - data for the 1st tasks are returned. But when retreiving data for the 3 task - data of the 3d task + data for the 2nd and the 1st tasks are retreived. This is a constant behavior and continues with the next tasks. This problem however occurs in our new productive system, in the old one it does not occur.

System details of the old prd system - program works fine.

SAP ECC 6.0
Linux
x86_64
ORACLE, 11.2.0.4.0
Packages:
SAP_BASIS	701	0008	SAPKB70108
SAP_ABA	701	0008	SAPKA70108

System details of the new prd system - issues occur.

SAP ECC 6.0
Windows NT
4x X86_64
MSSQL
packages:
SAP_BASIS	701	0012	SAPKB70112
SAP_ABA	701	0012	SAPKA70112

This is how the FM is called:

CALL FUNCTION 'ZTEST1'
        STARTING NEW TASK gv_name
        DESTINATION IN GROUP p_group
        PERFORMING end_of_task ON END OF TASK
          EXPORTING
            it_item           = gt_item
        EXCEPTIONS
          system_failure        = 1
          communication_failure = 2
          resource_failure      = 3.

Result of the asynchronous FM is retrieved in a subroutine:

FORM end_of_task USING iv_taskname TYPE clike.
  "...
refresh lt_data. RECEIVE RESULTS FROM FUNCTION 'ZTEST1' IMPORTING et_data = lt_data EXCEPTIONS system_failure = 1 communication_failure = 2. ENDFORM.

Detailed problem description:
This is how the program is working in our old productive system (no issues here):
When END_OF_TASK is performed in the output parameter ET_DATA we retreive the callculated data. Example: During CALL FUNCTION 'ZTEST1' with taskname = 'T000001' we pass items with keys from 0 to 1000. In subroutine END_OF_TASK with iv_taskname = 'T000001' we retreive data in param ET_DATA for the same group of items with the same keys from 0 to 1000. During CALL FUNCTION 'ZTEST1' with taskname = 'T000002' we pass items with keys from 1001 to 2000. In subroutine END_OF_TASK with iv_taskname = 'T000002' we retreive data in param ET_DATA for the same group of items with the same keys from 1001 to 2000. ....

This is how the program is working in our new productive system - issues occur:
Example: (1-st pass is fine, no issue) - During CALL FUNCTION 'ZTEST1' with taskname = 'T000001' we pass items with keys from 0 to 1000. In subroutine END_OF_TASK with iv_taskname = 'T000001' we retreive data in param ET_DATA for the same group of items with the same keys from 0 to 1000. (The next, second or third pass leads to an issue) - During CALL FUNCTION 'ZTEST1' with taskname = 'T000002' and items with keys from 1001 to 2000. In subroutine END_OF_TASK with iv_taskname = 'T000002' we retreive data in param ET_DATA for the same group of items with the same keys from 1001 to 2000 plus data of the previous task or previous tasks(if there are more than two) i.e. items with keys from 0 to 1001 or plus the data of the previously executed tasks. I.e. we retreive results not only for the data passed in the specified task but results from any random number of tasks. This leads to a performance issue because we process millions of records.

Please if someone have an idea how this problem could be solved, share it.

Thank you,
Rosen

0 Likes
View Entire Topic
UweFetzer_se38
Active Contributor
0 Likes

Have you tried to clear also the ET_DATA in the beginning of the function module?

You are using IN GROUP... Maybe on the old system you always got different application servers and in your new system you always run on the same application server. Shouldn't make any diffenerence, but if this is really the reason for the different behaviour it is an SAP bug in my opinion.