Two Different Types of Parallel Processing Examples in SAP

22
Two Different types of Parallel Processing examples created by Abhijit Mandal on Apr 28, 2014 4:43 PM, last modified by Abhijit Mandal on Apr 28, 2014 6:38 PM Version 3 inShare 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. It’s 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.

description

Two Different Types of Parallel Processing Examples in SAP

Transcript of Two Different Types of Parallel Processing Examples in SAP

Two Different types of Parallel Processing examplescreated byAbhijit Mandalon Apr 28, 2014 4:43 PM, last modified byAbhijit Mandalon Apr 28, 2014 6:38 PMVersion 3inSharePurpose & 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.

Step3: Function Module Coding:FUNCTIONzemp_data_upd1.*"----------------------------------------------------------------------*"*"Local Interface:*" IMPORTING*" VALUE(IM_DATA) TYPE ZEMP_DATA OPTIONAL*" EXPORTING*" VALUE(EX_RESULT) TYPE ZUPD_RESULT*"----------------------------------------------------------------------IF NOTim_dataIS INITIAL.

INSERTzemp_dataFROMim_data.

IFsy-subrcEQ0.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 reportReport 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: 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. 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 . WRITE:/ 'Emp-Id:', -empid. WRITE: 'Status:', -message. ENDLOOP.*&---------------------------------------------------------------------**& Form F_GET_FILE*&---------------------------------------------------------------------** text*----------------------------------------------------------------------** --> p1 text* P_GT_EMP text* = 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*&---------------------------------------------------------------------** 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_PROGStep 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 codeRZ12- 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.

*------------------------------------------------------------------------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.

Step3: Function Module Coding:See the difference of two function module. In this FM no COMMIT WORK inside the function module.FUNCTIONzemp_data_upd.*"----------------------------------------------------------------------*"*"Local Interface:*" IMPORTING*" VALUE(IM_DATA) TYPE ZEMP_DATA OPTIONAL*" EXPORTING*" VALUE(EX_RESULT) TYPE ZUPD_RESULT*"----------------------------------------------------------------------IF NOTim_dataIS INITIAL.

INSERTzemp_dataFROMim_data.

IFsy-subrcEQ0.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 processTABLES: zemp_data.TYPE-POOLS: spta.* Define a type that contains ALL the input & output data* needed for the RFCTYPES: 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: 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. 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 . WRITE:/ 'Emp-Id:', -empid. WRITE: 'Status:', -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 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: 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 INDEX 1. IF sy-subrc IS INITIAL. CLEAR ls_emp. MOVE 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. 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: 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. READ TABLE ls_taskdata-importing-emp_data ASSIGNING INDEX 1. IF sy-subrc EQ 0. MOVE 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*----------------------------------------------------------------------*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*&---------------------------------------------------------------------** text*----------------------------------------------------------------------** --> p1 text*