1

For example for parallel processing use following links.

http://www.teamabap.com/2014/05/parallel-processing-in-abap.html
Parallel Processing Most of the time when dealing with huge amount of data, the run time /
execution time of a program should be within the specified time limit. To overcome this, SAP has
provided a wonderful tool called "Parallel processing".
Parallel Processing means Asynchronous Type of function module. Generally when we call a
function module, it will stop the current program , execute another ( called ) program and then
returns control to original program and again original program starts execution.
With asynchronous function module control will start parallelly without stopping the current
program from which you called the function module.
We use parallel processing when we have to process large amount of data.
The usual way of programming is serial processing. The program executes one line at a time and
if you call a function that will wait until the control returns from the function and executes the
rest of the code. In some case you might be calling the same function again and again for
different set of master data. You know that there wont be any conflict between the data and you
would like to execute the same function multiple times with different set of data. We need to do
this in parallel processing this way the process will be completed much faster with multiple
processes in different servers.
Parallel processing can be use to fetch data, save data and upload data to database.
With this statement, you are instructing the SAP system to process function module calls in
parallel. Syntax:-

CALL FUNCTION
func_name STARTING NEW TASK task_name
DESTINATION {dest | {IN GROUP {group_name | Default}}}]
Parameter list
[{PERFORMING subr}|{CALLING meth} ON END OF TASK].

For group_name, you must specify a data object of the type RZLLI_APCL from the ABAP
Dictionary. This is usually one of the RFC server group created in transaction RZ12.
For each asynchronous RFC where the group is specified, the most suitable application server is
determined automatically, and the called function module is executed on this.
Call the FM 'SPBT_INITIALIZE' to know the Maximum work process and free work process by
passing the server group name (parallel_generators). This can be checked using transaction
RZ12.
The RFC is executed in the next available work process in the said server group and the results
are captured under "Call back routine" ON END OF TASK.
CALL FUNCTION Remotefunction ( FM Name ) STARTING NEW TASK Taskname :- With
this ABAP statement, you are telling the SAP system to process function module calls in parallel.
Typically, you'll place this keyword in a loop in which you divide up the data that is to be
processed into work packets.
DESTINATION IN GROUP :- Specifying IN GROUP as a destination allows you to execute
multiple function modules in parallel on a predefined group of application servers in the current
SAP system. For group, you must specify a data object of the type RZLLI_APCL from the ABAP
Dictionary, one that is either initial, or one that includes the name of an RFC server group

2
created in transaction RZ12.
When specifying DEFAULT, or if group is initial, all application
servers that are currently available in the current SAP system are used as a group.
ON END OF TASK :- You can use this addition to specify either a subprogram subr or, a method
meth as a callback routine, which is executed after the asynchronously called function module
has finished. The method meth must be public, and can have only one non-optional input
parameter p_task of type clike.

RECEIVE RESULTS FROM FUNCTION func

parameter list
[KEEPING TASK].

Required if you wish to receive the results of the processing of an asynchronous RFC. RECEIVE
retrieves IMPORT and TABLE parameters as well as messages and return codes.
This statement can be used in a callback routine specified for the asynchronous RFC, in order to
receive output parameters of an asynchronously called function func in the parameter
list parameter list, and to assign return values to exceptions.
With the addition KEEPING
context of the called function
ID, the same global data of
TASK, an asynchronous RFC
results are copied.

TASK, the asynchronous RFC connection is retained, as is the

module along with it. When a new call is made with the same task
the function group is addressed. Without the addition KEEPING
connection is finished after the remote function is executed or the

When we call function module

with IMPORTING and CHANGING.

in

parallel

processing,

REPORT ztest1.
parameters: p_kunnr type kna1-kunnr.
data: functioncall1(1) type c,
cstgdetail1 type bapicustomer_kna1.
constants: done(1) type c value 'X'.

start-of-selection.
call function 'BAPI_CUSTOMER_GETDETAIL2'
starting new task 'FUNC1'
destination 'NONE'
performing set_function1_done on end of task
exporting
customerno
= p_kunnr.
* Receive remaining asynchronous replies
wait until functioncall1 = done.

no

values

can

be

copied

3
write:/ cstgdetail1.
************************************************************************
*
FORM FUNCTION1_DONE
************************************************************************
form set_function1_done using taskname.
receive results from function 'BAPI_CUSTOMER_GETDETAIL2'
importing
customergeneraldetail = cstgdetail1.
functioncall1 = done.
endform.
SPTA Framework - Parallel Processing Technique in SAP ABAP
With the huge volume of data we are facing problems:
Scheduled jobs are not finishing within the timeframe.
Dump for ABAP memory issue for huge data processing.
Dump for timeout error for huge data processing.
SAP offers a solution for the problem: called parallel processing.
There are different frameworks available for parallel processing; SPTA is the most popular one.
Lets begin with one example of parallel processing with SPTA framework.

We can predefine three parameters for SPTA framework.

1. Server Group Instances (maintained in RZ12).
2. Maximum number of work packet per server instance.
3. Maximum number of records per work packet.
Result:
Lets assume one record takes 1 sec for processing.
Before implementing SPTA

4
1000 records get processed one by one and it will take 1000 sec (16 min approx) to be
processed.
After implementing SPTA
All the 1000 records get processed into 10 different tasks and that runs parallel, so by this way it
takes 100 records processing time to complete 1000 records process and that is 100 sec (2 min
approx).
So the total performance improvement would be 800% which can turn around whole day running
job into few minutes.

SPTA Framework in Details:

The SAP standard FM is SPTA_PARA_PROCESS_START_2.
There are three parameters by which we will call three subroutines to build our own logic for
parallel processing.

BEFORE_RFC_CALLBACK_FORM: This routine is called by the function module before

calling the RFC function module. Here we have to build different work packets which we want
to process in the RFC function module.
IN_RFC_CALLBACK_FORM: This routine is called by the function module after work
packets are created. In this routine we can use our own RFC enabled function module or
custom code to process each work packets.
AFTER_RFC_CALLBACK_FORM: This routine is called at the end by the function
module. After processing of all the work packets we have to collect all the processed data.

Other mandatory parameters are

SERVER_GROUP (we can pass our server group name which has been created from
RZ12).

CALLBACK_PROG (The calling program name).

USER_PARAM (Data to be processed in SPTA process).

The main step in BEFORE_RFC_CALLBACK_FORM is WP (work packet) creation.

creating WP with maximum 10 records inside.

Here we are

After finishing all the WP creation, all the WP will run in different tasks in parallel mode in
IN_RFC_CALLBACK_FORM.

Debugging SPTA using SRDEBUG:

Its good to remember that sometime when different server instances being used in SPTA
processing then only the external breakpoint would not work to go into debug mode. In this case
we need to use SRDEBUG.

8
Parallel tasks (sessions) in SPTA:
Here I have tried to make a clear picture of all the WP creation and how all the WP run in
different sessions or tasks.
I have putted a breakpoint in the IN_RFC subroutine and run the main program, all the WP being
created in BEFORE_RFC and then all the task will run in parallel mode in IN_RFC.

SAP has provided a sample demo program to understand SPTA Framework easily.
Program name SPTA_PARA_DEMO_1 Simple parallelization (without individual task dependence)

Purpose & Overview: We all know how to upload data into SAP but many of us not aware of
best possible way to upload the data in to sap. Now, if you are dealing with small volume of data
then there will be no problem but when it comes to huge volume of data then execution time is
important.
So, what will be best possible way?
There are different solutions available. But SAP has provided wonderful solutions called Parallel
Processing. There are two types of parallel processing available.

With Release 3.1G, SAP offers a solution to the short nights problem: parallel-processed
background jobs. Long-running SAP reports can now implement parallel processing, which
lets them parcel out the work to be done to available dialog work processes in the SAP
system and then collect the results.Parallel-processing is implemented with a special variant
of asynchronous RFC. Its important that you use only the correct variant for your own
parallel processing applications: the CALL FUNCTION STARTING NEW TASK DESTINATION IN
GROUP keyword.

Another one is the best one and most effective one. SPTA Framework. Performance wise
this is best possible parallel process. It takes minimum time to execute compare to other
parallel processes.

My attempt is to provide a good example of both and give a comparison between two parallel
processes.
Business Requirement: In this example for both the cases we have to upload data from legacy
file to Z table in SAP.
Lets Start with Process 1:
Step1: First create a Z table: This is the table where we will update the data.

Step2- Create Function Module: We will create a function module, through which we will
upload the data. Create import export parameter.

10
Step3: Function Module Coding:
FUNCTION zemp_data_upd1.
*"---------------------------------------------------------------------*"*"Local Interface:
*" IMPORTING
*"
VALUE(IM_DATA) TYPE ZEMP_DATA OPTIONAL
*" EXPORTING
*"
VALUE(EX_RESULT) TYPE ZUPD_RESULT
*"---------------------------------------------------------------------IF NOT im_data IS INITIAL.
INSERT zemp_data FROM im_data.
IF sy-subrc EQ 0.
ex_result-empid = im_data-empid.
ex_result-message = 'Updated'.
ELSE.
ex_result-empid = im_data-empid.
ex_result-message = 'Not-Updated'.
ENDIF.
COMMIT WORK.
ENDIF.
ENDFUNCTION.
Step4: Build the report
Report ZABHI_PARA_PROCESS_1.
TABLES: zemp_data.
TYPES:
ty_result TYPE zupd_result,
tty_result TYPE STANDARD TABLE OF zupd_result,
tty_emp TYPE STANDARD TABLE OF zemp_data.
DATA:
gt_emp TYPE tty_emp,
gt_result TYPE tty_result.
DATA: gv_snd_task TYPE i,
gv_ptask
TYPE i,
gv_rcv_task TYPE i.
FIELD-SYMBOLS: <gfs_result> TYPE zupd_result.
SELECTION-SCREEN BEGIN OF BLOCK b1 WITH FRAME TITLE text-001.
PARAMETERS:
p_rfcgr TYPE spta_rfcgr OBLIGATORY MEMORY ID spta_rfcgr,
p_file TYPE rlgrap-filename.
SELECTION-SCREEN END OF BLOCK b1.
I.
INITIALIZATION.
* Not just anybody may execute this report
AUTHORITY-CHECK OBJECT 'S_ADMI_FCD'
ID 'S_ADMI_FCD' FIELD 'PADM'.
IF NOT sy-subrc IS INITIAL.
RAISE no_authority_for_report.

11
ENDIF.
AT SELECTION-SCREEN ON VALUE-REQUEST FOR p_file .
PERFORM f_get_file .
START-OF-SELECTION.
PERFORM f_sub_get_data USING p_file
CHANGING gt_emp.
DELETE FROM zemp_data WHERE empid NE space.
IF sy-subrc = 0.
COMMIT WORK.
ENDIF.
PERFORM f_sub_upload_data USING gt_emp
CHANGING gt_result.
END-OF-SELECTION.
WRITE: 'EMPLOYEE DETAILS'.
SKIP.
LOOP AT gt_result ASSIGNING <gfs_result>.
WRITE:/ 'Emp-Id:', <gfs_result>-empid.
WRITE: 'Status:', <gfs_result>-message.
ENDLOOP.
*&---------------------------------------------------------------------*
*&
Form F_GET_FILE
*&---------------------------------------------------------------------*
*
text
*----------------------------------------------------------------------*
* --> p1
text
* <-- p2
text
*----------------------------------------------------------------------*
FORM f_get_file .
CALL FUNCTION 'F4_FILENAME'
EXPORTING
program_name = syst-cprog
dynpro_number = syst-dynnr
field_name = ' '
IMPORTING
file_name
= p_file.
ENDFORM.
" F_GET_FILE
*&---------------------------------------------------------------------*
*&
Form F_SUB_GET_DATA
*&---------------------------------------------------------------------*
*
text
*----------------------------------------------------------------------*
*
-->P_P_FILE text
*
<--P_gt_emp text
*----------------------------------------------------------------------*
FORM f_sub_get_data USING p_file TYPE localfile
CHANGING p_gt_tab TYPE tty_emp.
DATA: ls_work_area TYPE tty_emp,
lv_filename TYPE string.

12
CLEAR lv_filename.
MOVE p_file TO lv_filename.
CALL FUNCTION 'GUI_UPLOAD'
EXPORTING
filename
= lv_filename
filetype
= 'ASC'
has_field_separator
= 'X'
TABLES
data_tab
= p_gt_tab
EXCEPTIONS
file_open_error
=1
file_read_error
=2
no_batch
=3
gui_refuse_filetransfer = 4
invalid_type
=5
no_authority
=6
unknown_error
=7
bad_data_format
=8
header_not_allowed
=9
separator_not_allowed = 10
header_too_long
= 11
unknown_dp_error
= 12
access_denied
= 13
dp_out_of_memory
= 14
disk_full
= 15
dp_timeout
= 16
OTHERS
= 17.
IF sy-subrc <> 0.
* Implement suitable error handling here
ENDIF.
ENDFORM.
" F_SUB_GET_DATA
*&---------------------------------------------------------------------*
*&
Form F_SUB_UPLOAD_DATA
*&---------------------------------------------------------------------*
*
text
*----------------------------------------------------------------------*
*
-->P_GT_EMP text
*
<--P_GT_RESULT text
*----------------------------------------------------------------------*
FORM f_sub_upload_data USING p_gt_emp TYPE tty_emp
CHANGING p_gt_result TYPE tty_result.
DATA: lv_lines
TYPE i,
ls_result
TYPE zupd_result,
ls_data
TYPE zemp_data,
lv_msg(80) TYPE c,
lv_taskname TYPE numc10 VALUE '0',
lv_excp_flag TYPE flag.
FIELD-SYMBOLS: <lfs_emp> TYPE zemp_data.
CLEAR:ls_data,
ls_result,

13
gv_snd_task,
gv_rcv_task,
lv_lines.
*

DESCRIBE TABLE p_gt_emp LINES lv_lines.

LOOP AT p_gt_emp ASSIGNING <lfs_emp>.
gv_ptask = gv_ptask + 1.
MOVE <lfs_emp> TO ls_data.
CLEAR: lv_excp_flag.
DO.
ADD 1 TO lv_taskname.
CLEAR lv_excp_flag.
CALL FUNCTION 'ZEMP_DATA_UPD1'
STARTING NEW TASK lv_taskname
DESTINATION IN GROUP p_rfcgr
PERFORMING process_callback_prog ON END OF TASK
EXPORTING
im_data
= ls_data
EXCEPTIONS
communication_failure = 1 MESSAGE lv_msg
system_failure
= 2 MESSAGE lv_msg
resource_failure
= 3 "No work processes are
OTHERS
= 4. "Add exceptions generated by

*the called function module here. Exceptions are returned to you and you can
* respond to them here.
CASE sy-subrc.
WHEN 0.
ADD 1 TO gv_snd_task.
WHEN 1 OR 2.
CLEAR: ls_result.
MOVE <lfs_emp>-empid TO ls_result-empid.
MOVE 'Not_Updated' TO ls_result-message.
APPEND ls_result
TO p_gt_result.
CLEAR ls_result.
WHEN 3.
lv_excp_flag = 'X'.
WAIT UNTIL gv_rcv_task >= gv_snd_task UP TO '1' SECONDS.
WHEN OTHERS.
CLEAR ls_result.
ENDCASE.
IF lv_excp_flag IS INITIAL.
EXIT.
ENDIF.
ENDDO.
ENDLOOP.
*--- wait till everything ends
WAIT UNTIL gv_rcv_task >= gv_snd_task UP TO 10 SECONDS.
ENDFORM.
" F_SUB_UPLOAD_LINK
*&---------------------------------------------------------------------*
*&
Form PROCESS_UPLOAD_LINK
*&---------------------------------------------------------------------*

14
*
text
*----------------------------------------------------------------------*
*----------------------------------------------------------------------*
FORM process_callback_prog USING gv_task.
DATA: ls_result TYPE zupd_result.
gv_ptask = gv_ptask - 1.
RECEIVE RESULTS FROM FUNCTION 'ZEMP_DATA_UPD1'
IMPORTING
ex_result = ls_result
EXCEPTIONS
no_update = 1
OTHERS = 2.
gv_rcv_task = gv_rcv_task + 1.
APPEND ls_result TO gt_result.
CLEAR ls_result.
A.
ENDFORM.
" PROCESS_CALLBACK_PROG
Step 5- Test the program: Activate the program and then execute it. Select server group from
existing otherwise you can create a Z server group by executing transaction code RZ12 - RFC
Server Group Maintenance.

Step 5: Execute it and see the result: Employee details in Ztable will be updated and the
report is also generate.

15

*------------------------------------------------------------------------PROCESS 1 IS COMPLETE
---------------------------------------------------------------------------------------------------------------*
Lets Start Process 2:
Step1-Creation of Ztable: For this process also, we will use same table to update
employee details:

Step2- Create Function Module: We will create a function module, through which we will
upload the data. Create import export parameter.

16

Step3: Function Module Coding:

See the difference of two function module. In this FM no COMMIT WORK inside the function
module.
FUNCTION zemp_data_upd.
*"---------------------------------------------------------------------*"*"Local Interface:
*" IMPORTING
*"
VALUE(IM_DATA) TYPE ZEMP_DATA OPTIONAL
*" EXPORTING
*"
VALUE(EX_RESULT) TYPE ZUPD_RESULT
*"---------------------------------------------------------------------IF NOT im_data IS INITIAL.
INSERT zemp_data FROM im_data.
IF sy-subrc EQ 0.
ex_result-empid = im_data-empid.
ex_result-message = 'Updated'.
ELSE.
ex_result-empid = im_data-empid.
ex_result-message = 'Not-Updated'.
ENDIF.
ENDIF.
ENDFUNCTION.
Step4: Build the report:
REPORT zabhi_para_process_2 .
*---- ZEMP_DATA - This table is getting updated through this process

17
TABLES: zemp_data.
TYPE-POOLS: spta.
* Define a type that contains ALL the input & output data
* needed for the RFC
TYPES:
ty_result TYPE zupd_result,
tty_result TYPE STANDARD TABLE OF zupd_result,
tty_emp
TYPE STANDARD TABLE OF zemp_data.
DATA:
gt_emp
TYPE tty_emp,
gt_result
TYPE tty_result,
gv_repid
TYPE syrepid,
gv_error_count TYPE syindex.
TYPES: BEGIN OF gty_rfcdata,
BEGIN OF importing,
emp_data LIKE gt_emp , " TYPE ty_emp,
END OF importing,
BEGIN OF exporting,
emp_result LIKE gt_result , "TYPE ty_result,
END OF exporting,
END OF gty_rfcdata.
FIELD-SYMBOLS: <gfs_result> TYPE zupd_result.
SELECTION-SCREEN BEGIN OF BLOCK b1 WITH FRAME TITLE text-001.
PARAMETERS:
p_rfcgr TYPE spta_rfcgr OBLIGATORY MEMORY ID spta_rfcgr,
p_maxtak LIKE sy-index DEFAULT '10',
p_start LIKE sy-index DEFAULT '1',
p_end LIKE sy-index DEFAULT '100',
p_file TYPE rlgrap-filename.
SELECTION-SCREEN END OF BLOCK b1.
I.

INITIALIZATION.
* Not just anybody may execute this report
AUTHORITY-CHECK OBJECT 'S_ADMI_FCD'
ID 'S_ADMI_FCD' FIELD 'PADM'.
IF NOT sy-subrc IS INITIAL.
RAISE no_authority_for_report.
ENDIF.
AT SELECTION-SCREEN ON VALUE-REQUEST FOR p_file .
PERFORM f_get_file .
START-OF-SELECTION.
PERFORM f_sub_get_data USING p_file
CHANGING gt_emp.

18
DELETE FROM zemp_data WHERE empid NE space.
IF sy-subrc = 0.
COMMIT WORK.
ENDIF.
gv_repid = sy-repid.
CLEAR: gv_error_count.
CALL FUNCTION 'SPTA_PARA_PROCESS_START_2'
EXPORTING
server_group
= p_rfcgr
max_no_of_tasks
= p_maxtak
before_rfc_callback_form = 'F_BEFORE_RFC'
in_rfc_callback_form
= 'F_IN_RFC'
after_rfc_callback_form = 'F_AFTER_RFC'
callback_prog
= gv_repid
EXCEPTIONS
invalid_server_group
=1
no_resources_available = 2
OTHERS
= 3.
END-OF-SELECTION.
WRITE: 'EMPLOYEE DETAILS'.
SKIP.
LOOP AT gt_result ASSIGNING <gfs_result>.
WRITE:/ 'Emp-Id:', <gfs_result>-empid.
WRITE: 'Status:', <gfs_result>-message.
ENDLOOP.
*&---------------------------------------------------------------------*
*&
Form F_before_rfc
*&---------------------------------------------------------------------*
*
text
*----------------------------------------------------------------------*
*
-->P_BEFORE_RFC_IMP
text
*
-->P_BEFORE_RFC_EXP
text
*
-->PT_RFCDATA
text
*
-->P_FAILED_OBJECTS
text
*
-->P_OBJECTS_IN_PROCESS text
*
-->P_USER_PARAM
text
*----------------------------------------------------------------------*
FORM f_before_rfc
USING
p_before_rfc_imp
TYPE spta_t_before_rfc_imp
CHANGING
p_before_rfc_exp
TYPE spta_t_before_rfc_exp
pt_rfcdata
TYPE spta_t_indxtab
p_failed_objects
TYPE spta_t_failed_objects
p_objects_in_process TYPE spta_t_objects_in_process
p_user_param.
DATA:
lv_package_size TYPE sytabix,
ls_task_data
TYPE gty_rfcdata,

" ***CUSTOM

19
ls_emp
TYPE zemp_data,
" ***CUSTOM
ls_failed_obj
TYPE spta_t_failed_object,
ls_obj_in_process TYPE spta_t_pending_object.
FIELD-SYMBOLS:
<lfs_work>
TYPE zemp_data.
* Delete list of objects in process
CLEAR ls_obj_in_process.
* Check if there are objects from previously failed tasks left ...
READ TABLE p_failed_objects INDEX 1 INTO ls_failed_obj.
IF sy-subrc = 0.
* Yes there are.
* Take first object and delete it from list of failed objects
DELETE p_failed_objects INDEX 1.
ls_obj_in_process = ls_failed_obj.
ls_emp-empid = ls_obj_in_process-obj_id(10).
APPEND ls_emp TO ls_task_data-importing-emp_data.
* Add list of objects that are about to be processed
* to list of "objects in process"
* so the task manager has that information
APPEND ls_obj_in_process TO p_objects_in_process.
ELSE.
* No there aren't.
* Take objects from regular input list of objects
*
*
*
*
*

The number of objects that are processed at once is determined

by the application. This sample coding here uses a dynamically
determined package size (one 5th of remaining objects).
In order to avoid extremly large or extremly small packages
there is a maximum and minimum package size.

READ TABLE gt_emp ASSIGNING <lfs_work> INDEX 1.

IF sy-subrc IS INITIAL.
CLEAR ls_emp.
MOVE <lfs_work> TO ls_emp.
APPEND ls_emp TO ls_task_data-importing-emp_data.
ls_obj_in_process-obj_id(10) = ls_emp-empid.
DELETE gt_emp INDEX 1.
* Add list of objects that are about to be processed
* to list of "objects in process"
* so the task manager has that information
APPEND ls_obj_in_process TO p_objects_in_process.
ENDIF.
ENDIF.
*
*
*
*
*
*
*
*
*

If there is (currently) nothing to do, clear the

START_RFC field and leave the form.
This informs the task manager that no rfc has to be started.
If there are no more RFCs in process this also ends
the processing of the task manager
If there are still RFCs in process the BEFORE_RFC form
will be invoked after each RFC has been received to give
the application an opportunity to launch new RFCs that have been
waiting on the RFC that was just received.
IF p_objects_in_process IS INITIAL.

20
CLEAR p_before_rfc_exp-start_rfc.
EXIT.
ENDIF.
* Convert the input data into the INDX structure
* that is needed for the RFC
CALL FUNCTION 'SPTA_INDX_PACKAGE_ENCODE'
EXPORTING
data = ls_task_data
IMPORTING
indxtab = pt_rfcdata.
* Inform task manager that an RFC can be started from the
* data compiled
p_before_rfc_exp-start_rfc = 'X'.
ENDFORM.

"BEFORE_RFC

*---------------------------------------------------------------------*
*
FORM IN_RFC *
*---------------------------------------------------------------------*
*
Callback-Form invoked within the RFC
*
*---------------------------------------------------------------------*
FORM f_in_rfc
USING
p_in_rfc_imp TYPE spta_t_in_rfc_imp
CHANGING
p_in_rfc_exp TYPE spta_t_in_rfc_exp
p_rfcdata
TYPE spta_t_indxtab.
DATA:
ls_taskdata TYPE gty_rfcdata,
ls_data
TYPE zemp_data,
ls_result
TYPE zupd_result.
FIELD-SYMBOLS:
<lfs_data> TYPE zemp_data.
*
*
*
*
*

Force synchronous update

This is the most efficient method for parallel processing
since no update data will be written to the DB but rather
stored in memory.
This statement must be reissued after each COMMIT WORK !!!!
SET UPDATE TASK LOCAL.

* Unpack RFC input data (that has been packed in the BEFORE_RFC form)
CALL FUNCTION 'SPTA_INDX_PACKAGE_DECODE'
EXPORTING
indxtab = p_rfcdata
IMPORTING
data = ls_taskdata.
*--- Begin processing of RFC
*------ Prepare your import data from -importing-workarea ( can define as per req )
CLEAR ls_data.

21
READ TABLE ls_taskdata-importing-emp_data ASSIGNING <lfs_data> INDEX 1.
IF sy-subrc EQ 0.
MOVE <lfs_data> TO ls_data.
ENDIF.
*------ Prepare your import data from -importing-workarea ( can define as per req )
CALL FUNCTION 'ZEMP_DATA_UPD'
EXPORTING
im_data = ls_data
IMPORTING
ex_result = ls_result
EXCEPTIONS
no_update = 1
OTHERS = 2.
IF sy-subrc <> 0.
* Implement suitable error handling here
ENDIF.
* Fill result tables
* This would include data for result lists, message handler etc.
* lS_taskdata-exporting-workarea = lS_taskdata-importing-workarea.
* Clear all data that is unnecessary for the AFTER_RFC form
* This keeps the amount of data transfered over the network
* small and makes the RFC more efficient!
REFRESH: ls_taskdata-exporting-emp_result[].
APPEND ls_result TO ls_taskdata-exporting-emp_result.
* Repack output data for AFTER_RFC form
CALL FUNCTION 'SPTA_INDX_PACKAGE_ENCODE'
EXPORTING
data = ls_taskdata
IMPORTING
indxtab = p_rfcdata.
* Don't forget to COMMIT your data, because if you don't, the
* RFC will end with an automatic rollback and data written to the
* database will be lost.
COMMIT WORK.
ENDFORM.

"F_in_rfc

*&---------------------------------------------------------------------*
*&
Form F_after_rfc
*&---------------------------------------------------------------------*
*
text
*----------------------------------------------------------------------*
*
-->P_RFCDATA
text
*
-->P_RFCSUBRC
text
*
-->P_RFCMSG
text
*
-->P_OBJECTS_IN_PROCESS text
*
-->P_AFTER_RFC_IMP
text
*
-->P_AFTER_RFC_EXP
text
*
-->P_USER_PARAM
text
*----------------------------------------------------------------------*

22
FORM f_after_rfc
USING
p_rfcdata
TYPE spta_t_indxtab
p_rfcsubrc
TYPE sy-subrc
p_rfcmsg
TYPE spta_t_rfcmsg
p_objects_in_process TYPE spta_t_objects_in_process
p_after_rfc_imp
TYPE spta_t_after_rfc_imp
CHANGING
p_after_rfc_exp
TYPE spta_t_after_rfc_exp
p_user_param.
DATA:
ls_obj_in_process
TYPE spta_t_pending_object,
lv_tabsize
TYPE sytabix,
ls_taskdata
TYPE gty_rfcdata.
DATA:
ls_emp TYPE zemp_data.
IF p_rfcsubrc IS INITIAL.
* No RFC error occured
* Unpack RFC output data and add RFC-results to global data,
* e.g. output list, message handler etc.
CALL FUNCTION 'SPTA_INDX_PACKAGE_DECODE'
EXPORTING
indxtab = p_rfcdata
IMPORTING
data = ls_taskdata.
APPEND LINES OF ls_taskdata-exporting-emp_result
TO gt_result.
EXIT.
ENDIF.
* Error handling
DESCRIBE TABLE p_objects_in_process LINES lv_tabsize.
IF lv_tabsize = 1.
* The failed task contained one object
* Inform task manager not to resubmit objects
p_after_rfc_exp-no_resubmission_on_error = 'X'.
* about the nature of the error.
READ TABLE p_objects_in_process INDEX 1
INTO ls_obj_in_process.
IF sy-subrc NE 0.
CLEAR ls_obj_in_process.
ENDIF.
ELSE.
* The failed taks contained several objects.
* Enable resubmission to process objects individually.
CLEAR p_after_rfc_exp-no_resubmission_on_error.
ENDIF.
ENDFORM.
"AFTER_RFC
*&---------------------------------------------------------------------*
*&
Form F_GET_FILE
*&---------------------------------------------------------------------*

23
*
text
*----------------------------------------------------------------------*
* --> p1
text
* <-- p2
text
*----------------------------------------------------------------------*
FORM f_get_file .
CALL FUNCTION 'F4_FILENAME'
EXPORTING
program_name = syst-cprog
dynpro_number = syst-dynnr
field_name = ' '
IMPORTING
file_name
= p_file.
A.
ENDFORM.
" F_GET_FILE
*&---------------------------------------------------------------------*
*&
Form F_SUB_GET_DATA
*&---------------------------------------------------------------------*
*
text
*----------------------------------------------------------------------*
*
-->P_P_FILE text
*
<--P_gt_emp text
*----------------------------------------------------------------------*
FORM f_sub_get_data USING p_file TYPE localfile
CHANGING p_gt_tab TYPE tty_emp.
DATA: ls_work_area TYPE tty_emp,
lv_filename TYPE string.
CLEAR lv_filename.
MOVE p_file TO lv_filename.
CALL FUNCTION 'GUI_UPLOAD'
EXPORTING
filename
= lv_filename
filetype
= 'ASC'
has_field_separator
= 'X'
TABLES
data_tab
= p_gt_tab
EXCEPTIONS
file_open_error
=1
file_read_error
=2
no_batch
=3
gui_refuse_filetransfer = 4
invalid_type
=5
no_authority
=6
unknown_error
=7
bad_data_format
=8
header_not_allowed
=9
separator_not_allowed = 10
header_too_long
= 11
unknown_dp_error
= 12
access_denied
= 13
dp_out_of_memory
= 14
disk_full
= 15
dp_timeout
= 16
OTHERS
= 17.

24
IF sy-subrc <> 0.
REFRESH: p_gt_tab.
ENDIF.
ENDFORM.

" F_SUB_GET_DATA

Step 5 - Test the program:

Activate the program and then execute it. Select server group from existing otherwise you can
create a Z server group by executing transaction code RZ12 - RFC Server Group Maintenance.
For this case one extra selection field has been taken for defining maximum task.

We will delete first from the table and upload the same file which has been used earlier.

Step 5: Execute it and see the result: Employee details have been updated.

25

*----------------------------------------------------------------------------- End of Process

2--------------------------------------------------------------------------------------------------------------------------*
Now we are going to compare which parallel process performance is better. For better
comparison, take large volume of data because in small volume of data you will not find the
difference.
Go to SE30 or SAT and Compare the result:
Process 1:

26
Execute it :

Process 2:

Result:

27

See the time difference is very less. For better statistics use large volume of data.