ERP Software Corner
- Category: ABAP
- Published on Tuesday, 14 October 2008 22:54
- Written by Anon
- Hits: 16934
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. 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:
o The function module must be defined as remotely callable in SE37
o The called function module may not include a function call to the destination “BACK.”
o 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.
o 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.
· 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:
- SPBT_GET_PP_DESTINATION: Optional function module.
- SPBT_DO_NOT_USE_SERVER: Optional function module.
- WAIT: ABAP keyword
- RECEIVE: ABAP keyword
RECEIVE RESULTS FROM FUNCTION RemotefunctionRequired 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
The addition first determines the amount of resources (work processes) currently available (i.e. in all servers or in a group of application servers, comparable with login servers). The resources available for executing asynchronous calls on each application server depends on the current system load. The applications developer is responsible for the availability of RFC groups in the production system (i.e. the customer's system). For details on how to maintain the RFC groups, see Below Maintaining Group Destinations). After determining the available resources, the asynchronous call is executed in an available application server. If no resources are available at that particular time, the system executes the exception routine RESOURCE_FAILURE (see the addition Exceptions). In the case of an asynchronous function module call, this exception must be handled by the application program.The process for determining available resources in an RFC group is as follows:First, the system determines the length of the dispatcher queue for the relevant application server. If it is greater than 10% of the overall length, the server makes no resources available. If it is smaller, the system makes available the current number of free dialog processes minus 2 (as a reserve instance for other purposes, e.g. for logon to the system or administration programs). Thus, one application server must have at least 3 dialog processes if RFC parallel processing is taken into account.
· At present, only one RFC group per program environment is supported for parallel execution of asynchronous calls. Using both additions (DESTINATION IN GROUP Groupname and DESTINATION IN GROUP DEFAULT) in one program is not allowed.
· The exception routine RESOURCE_FAILURE is only triggered in connection with asynchronous RFCs with the additions DESTINATION IN GROUP Groupname and DESTINATION IN GROUP DEFAULT.You are recommended (for performance and other reasons) to use an RFC group with sufficient resources for parallel processing of asynchronous calls
Maintaining Group Destinations
To achieve a balanced load distribution in the target system, you must define a group of application servers as an RFC destination. When processing tasks in parallel, you can use the group destination only in connection with the asynchronous RFC.The resources available on each application server depends on the current system load. To display and maintain the RFC groups, proceed as follows:
1. Call transaction SM59.
2. From the RFC destination overview screen, choose RFC ® RFC groups.
You then see:
· the names of any RFC groups that have already been defined
· a list of the instances (host, system and instance number) in your SAP system
· the current status (active or not) of each server.
3. To define an RFC group, choose Edit ® Create. Enter a server group name and an instance in the dialog window.To add instances to an existing group, double click the group name and enter a new instance in the dialog window.
By creating duplicate entries, you can assign a server to more than one group. In this case, jobs that use the group will compete for free work processes on the shared server(s).