2008 May 20 7:13 AM
HI PALS,
I WANT THE COMPLETE DIFFERENCES BETWEEN PARALLEL AND SEQUENTIAL PROCESSING!
IN THE CONTEXT OF RFC.
2008 May 20 9:50 AM
Hi
Parallel Processing
To achieve a balanced distribution of the system load, you can use destination additions to execute function modules in parallel tasks in any application server or in a predefined application server group of an SAP system.
Parallel-processing is implemented with a special variant of asynchonous RFC. Itu2019s important that you use only the correct variant for your own parallel processing applications: the CALL FUNCTION STARTING NEW TASK DESTINATION IN GROUP keyword. Using other variants of asynchronous RFC circumvents the built-in safeguards in the correct keyword, and can bring your system to its knees
Details are discussed in the following subsections:
· Prerequisites for Parallel Processing
· Function Modules and ABAP Keywords for Parallel Processing
· Managing Resources in Parallel Processing
Prerequisites for Parallel Processing
Before you implement parallel processing, make sure that your application and your SAP system meet these requirements:
· Logically-independent units of work:
The data processing task that is to be carried out in parallel must be logically independent of other instances of the task. That is, the task can be carried out without reference to other records from the same data set that are also being processed in parallel, and the task is not dependent upon the results of others of the parallel operations. For example, parallel processing is not suitable for data that must be sequentially processed or in which the processing of one data item is dependent upon the processing of another item of the data.
By definition, there is no guarantee that data will be processed in a particular order in parallel processing or that a particular result will be available at a given point in processing.
· ABAP requirements:
¡ The function module that you call must be marked as externally callable. This attribute is specified in the Remote function call supported field in the function module definition (transaction SE37).
¡ The called function module may not include a function call to the destination u201CBACK.u201D
¡ The calling program should not change to a new internal session after making an asynchronous RFC call. That is, you should not use SUBMIT or CALL TRANSACTION in such a report after using CALL FUNCTION STARTING NEW TASK.
¡ You cannot use the CALL FUNCTION STARTING NEW TASK DESTINATION IN GROUP keyword to start external programs.
· System resources:
In order to process tasks from parallel jobs, a server in your SAP system must have at least 3 dialog work processes. It must also meet the workload criteria of the parallel processing system: Dispatcher queue less than 10% full, at least one dialog work process free for processing tasks from the parallel job.
Function Modules and ABAP Keywords for Parallel Processing
You can implement parallel processing in your applications by using the following function modules and ABAP keywords:
· SPBT_INITIALIZE: Optional function module.
Use to determine the availability of resources for parallel processing.
You can do the following:
¡ check that the parallel processing group that you have specified is correct.
¡ find out how many work processes are available so that you can more efficiently size the packets of data that are to be processed in your data.
· CALL FUNCTION Remotefunction STARTING NEW TASK Taskname DESTINATION IN GROUP:
With this ABAP statement, you are telling the SAP system to process function module calls in parallel. Typically, youu2019ll place this keyword in a loop in which you divide up the data that is to be processed into work packets. You can pass the data that is to be processed in the form of an internal table (EXPORT, TABLE arguments). The keyword implements parallel processing by dispatching asynchronous RFC calls to the servers that are available in the RFC server group specified for the processing.
Note that your RFC calls with CALL FUNCTION are processed in work processes of type DIALOG. The DIALOG limit on processing of one dialog step (by default 300 seconds, system profile parameter rdisp/max_wprun_time) applies to these RFC calls. Keep this limit in mind when you divide up data for parallel processing calls.
· SPBT_GET_PP_DESTINATION: Optional function module.
Call immediately after the CALL FUNCTION keyword to get the name of the server on which the parallel processing task will be run.
· SPBT_DO_NOT_USE_SERVER: Optional function module.
Excludes a particular server from further use for processing parallel processing tasks. Use in conjunction with SPBT_GET_PP_DESTINATION if you determine that a particular server is not available for parallel processing (for example, COMMUNICATION FAILURE exception if a server becomes unavailable).
· WAIT: ABAP keyword
WAIT UNTIL
Required if you wish to wait for all of the asynchronous parallel tasks created with CALL FUNCTION to return. This is normally a requirement for orderly background processing. May be used only if the CALL FUNCTION includes the PERFORMING ON RETURN addition.
· RECEIVE: ABAP keyword
RECEIVE RESULTS FROM FUNCTION Remotefunction
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.
Managing Resources in Parallel Processing
You use the following destination additions to perform parallel execution of function modules (asynchronous calls) in the SAP system:
In a predefined group of application servers:
CALL FUNCTION Remotefunction STARTING NEW TASK Taskname
DESTINATION IN GROUP Groupname
In all currently available and active application servers:
CALL FUNCTION Remotefunction STARTING NEW TASK Taskname
DESTINATION IN GROUP DEFAULT
Sequential Processing
In the following cases, the system chooses sequential (non-parallel) processing:
● In table RSADMIN, entry QUERY_MAX_WP_DIAG has value (column value) 1.
● The entire query consists of one sub-access only.
● The query is running in a batch process.
● The query was started from the query monitor (transaction RSRT) using various debug options (for example, SQL query display, execution plan display). See, Dividing a MultiProvider Query into Sub-Queries.
● The query requests non-cumulative key figures.
● Insufficient dialog processes are available when the query is executed. These are required for parallel processing.
● The query is configured for non-parallel processing.
● You want to save the result of the query in a file or a table.
In Release SAP NetWeaver 7.0, the system can efficiently manage the large intermediate results produced by parallel processing. In previous releases, the system terminated when it reached a particular intermediate result size and proceeded to read data sequentially. This is no longer the case. Therefore, the RSADMIN parameter that was used in previous releases for reading a MultiProvider sequentially is no longer used.
Reward If Helpfull,
Naresh
2008 May 20 9:48 AM
Hi,
Please go through this link
http://help.sap.com/saphelp_nw04/helpdata/en/22/0425c6488911d189490000e829fbbd/frameset.htm
http://help.sap.com/saphelp_erp2004/helpdata/en/74/e8caaea70d7a41b03dc82637ae0fa5/frameset.htm
it its useful reward points
2008 May 20 9:50 AM
Hi
Parallel Processing
To achieve a balanced distribution of the system load, you can use destination additions to execute function modules in parallel tasks in any application server or in a predefined application server group of an SAP system.
Parallel-processing is implemented with a special variant of asynchonous RFC. Itu2019s important that you use only the correct variant for your own parallel processing applications: the CALL FUNCTION STARTING NEW TASK DESTINATION IN GROUP keyword. Using other variants of asynchronous RFC circumvents the built-in safeguards in the correct keyword, and can bring your system to its knees
Details are discussed in the following subsections:
· Prerequisites for Parallel Processing
· Function Modules and ABAP Keywords for Parallel Processing
· Managing Resources in Parallel Processing
Prerequisites for Parallel Processing
Before you implement parallel processing, make sure that your application and your SAP system meet these requirements:
· Logically-independent units of work:
The data processing task that is to be carried out in parallel must be logically independent of other instances of the task. That is, the task can be carried out without reference to other records from the same data set that are also being processed in parallel, and the task is not dependent upon the results of others of the parallel operations. For example, parallel processing is not suitable for data that must be sequentially processed or in which the processing of one data item is dependent upon the processing of another item of the data.
By definition, there is no guarantee that data will be processed in a particular order in parallel processing or that a particular result will be available at a given point in processing.
· ABAP requirements:
¡ The function module that you call must be marked as externally callable. This attribute is specified in the Remote function call supported field in the function module definition (transaction SE37).
¡ The called function module may not include a function call to the destination u201CBACK.u201D
¡ The calling program should not change to a new internal session after making an asynchronous RFC call. That is, you should not use SUBMIT or CALL TRANSACTION in such a report after using CALL FUNCTION STARTING NEW TASK.
¡ You cannot use the CALL FUNCTION STARTING NEW TASK DESTINATION IN GROUP keyword to start external programs.
· System resources:
In order to process tasks from parallel jobs, a server in your SAP system must have at least 3 dialog work processes. It must also meet the workload criteria of the parallel processing system: Dispatcher queue less than 10% full, at least one dialog work process free for processing tasks from the parallel job.
Function Modules and ABAP Keywords for Parallel Processing
You can implement parallel processing in your applications by using the following function modules and ABAP keywords:
· SPBT_INITIALIZE: Optional function module.
Use to determine the availability of resources for parallel processing.
You can do the following:
¡ check that the parallel processing group that you have specified is correct.
¡ find out how many work processes are available so that you can more efficiently size the packets of data that are to be processed in your data.
· CALL FUNCTION Remotefunction STARTING NEW TASK Taskname DESTINATION IN GROUP:
With this ABAP statement, you are telling the SAP system to process function module calls in parallel. Typically, youu2019ll place this keyword in a loop in which you divide up the data that is to be processed into work packets. You can pass the data that is to be processed in the form of an internal table (EXPORT, TABLE arguments). The keyword implements parallel processing by dispatching asynchronous RFC calls to the servers that are available in the RFC server group specified for the processing.
Note that your RFC calls with CALL FUNCTION are processed in work processes of type DIALOG. The DIALOG limit on processing of one dialog step (by default 300 seconds, system profile parameter rdisp/max_wprun_time) applies to these RFC calls. Keep this limit in mind when you divide up data for parallel processing calls.
· SPBT_GET_PP_DESTINATION: Optional function module.
Call immediately after the CALL FUNCTION keyword to get the name of the server on which the parallel processing task will be run.
· SPBT_DO_NOT_USE_SERVER: Optional function module.
Excludes a particular server from further use for processing parallel processing tasks. Use in conjunction with SPBT_GET_PP_DESTINATION if you determine that a particular server is not available for parallel processing (for example, COMMUNICATION FAILURE exception if a server becomes unavailable).
· WAIT: ABAP keyword
WAIT UNTIL
Required if you wish to wait for all of the asynchronous parallel tasks created with CALL FUNCTION to return. This is normally a requirement for orderly background processing. May be used only if the CALL FUNCTION includes the PERFORMING ON RETURN addition.
· RECEIVE: ABAP keyword
RECEIVE RESULTS FROM FUNCTION Remotefunction
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.
Managing Resources in Parallel Processing
You use the following destination additions to perform parallel execution of function modules (asynchronous calls) in the SAP system:
In a predefined group of application servers:
CALL FUNCTION Remotefunction STARTING NEW TASK Taskname
DESTINATION IN GROUP Groupname
In all currently available and active application servers:
CALL FUNCTION Remotefunction STARTING NEW TASK Taskname
DESTINATION IN GROUP DEFAULT
Sequential Processing
In the following cases, the system chooses sequential (non-parallel) processing:
● In table RSADMIN, entry QUERY_MAX_WP_DIAG has value (column value) 1.
● The entire query consists of one sub-access only.
● The query is running in a batch process.
● The query was started from the query monitor (transaction RSRT) using various debug options (for example, SQL query display, execution plan display). See, Dividing a MultiProvider Query into Sub-Queries.
● The query requests non-cumulative key figures.
● Insufficient dialog processes are available when the query is executed. These are required for parallel processing.
● The query is configured for non-parallel processing.
● You want to save the result of the query in a file or a table.
In Release SAP NetWeaver 7.0, the system can efficiently manage the large intermediate results produced by parallel processing. In previous releases, the system terminated when it reached a particular intermediate result size and proceeded to read data sequentially. This is no longer the case. Therefore, the RSADMIN parameter that was used in previous releases for reading a MultiProvider sequentially is no longer used.
Reward If Helpfull,
Naresh