SAP PARALLEL PROCESSING INTRODUCTION

Parallel processing is to use “divide and conquer” strategy to increase business process throughput and cut processing time by engaging more system resources. This post would take about SAP parallel processing and cover: What is parallel processing? What is pros and cons of parallel processing? What are driving factors to implement parallel processing? What influence performance of parallel process? Technical overview of SAP parallel process implementation. Parallel process solution implemented via background job. Parallel process solution implemented via SAP dialog work process. What are steps to implement a parallel process? Some standard SAP parallel solution. 1 What is parallel processing? Let’s begin with an example, 10 customer orders are to create online in SAP system and each order would take 1 minute. There are two ways to get 10 orders created in the system: You can give 10 orders to a single user and the user then create two orders one by one sequentially. You can divide 10 orders into two packages equally and ask two users to work on one of two packages to create order one by one at the same time. The former is called sequential/serial processing and the latter is called parallel processing. In case of parallel processing, we divide the workload ( to create 10 sales orders) on hand and we engaged more resources(2 SAP work processes through 2 users ) to do the same action( to create sales order) at the same time, This is what parallel processing normally mean in a SAP context – a SAP parent program would automatically divide the workload into smaller packages based on packet size which can be predefined or calculated dynamically, then start a number of child processes to process those packages concurrently, each child process would process one package at one time, when one child process finishes processing the package and there are un-processed packages, the program would launch new child process to pick up next package until all packages are processed. Child process engaged in parallel processing can be SAP dialog or background work process in a SAP system. Let’s continue our example. When 10 orders are created via one process sequentially, it would take at least 10 minutes but this does not meet performance requirement – 10 orders should be created in 5 minutes. So 10 orders are created via two parallel processes and that cuts runtime to 5 minutes. What we should do if 10 orders have to be created in 2 minutes in this case? 10 orders needs to be divided into 5 packages equally and use 5 concurrent child processes to create order and that would finish creating orders in 2 minutes. Let’s assume that creating one order via 1 work process would consume 1 resources, then relation between the runtime and resource needed to create 10 orders and number of users (Number of child process) is showed in table – 1. Table 1 – how runtime is related to number of parallel child process Case 1 Case 2 Case 3 Case 5 # of child process 1 2 5 10 Run Time 10 minutes 5 minutes 2 minutes 1 minute Resource usage/minute 1 2 5 10 Total resource( resource used/minute x duration) 1 x 10 2 x 5 5 x 2 10 x 1 From table 1, you can see that when number of parallel child process is increased, the runtime is decreased but resource usage per time unit is creased even total resource usage to create 10 orders remains the same. This is a simplified version to help you understand basic concept of parallel processing. You can ask two users to do two different things at the same time – one is to create a sales order, the other is to create an invoice – Even these two tasks are done in parallel but this not what SAP parallel processing is referring to since different tasks (such as different business logic/operation/program) are executed. 2 What is pros and cons of parallel processing? What is pros and cons of parallel processing? You can refer to table -1 to understand this. Parallel processing is to increase throughput and cut processing time – this is critical in many cases. To pay for that gain, more system resource is needed or used and order of processing of each package is random. For example, using 2 child processes, it takes 5 minutes to create 10 orders in our case. That is half of the time needed to create 10 orders one by one. The cons is that system resources usage in parallel processing period is doubled what used in serial processing period in a per minute basis. In serial processing, 10 orders can be created in a fashion of “First-in-First-out” in the same time sequence they arrive. This is impossible for parallel processing. 3 What are driving factors to implement parallel processing? The business need and technical need -The business need is that business needs to get job done sooner than later. The technical need is might be due to load contention – for example, system has more idle resource during 1st half the processing and 2nd half processing. system is overloaded in 2nd half processing. If we use parallel process and can cut time to half, this would relieve the contention on the 2nd half processing. Most of parallel solutions are developed to meet business process need. The fitness – The business process is suitable for parallel processing – degree of independence, dividable and type of resources engaged. Parallel process benefit would be very limited for a business process whose transactions have a lot of dependence/sequence. You cannot ask several people to create one order at the same time no matter how big the order is and how long it takes to create it since a single order cannot be further divided. A process which is doing a lot of calculations is more suitable than the one which involves a lot of database access even database management system has its setting/configuration/techniques which control parallel processing at database level. The capabilities – The system has needed resources/configuration to support parallel processing. If your system consists of single server with single CPU, parallel processing might help little on the performance. 4 What influence performance of parallel process solution? Assuming that a business process is fit for parallel processing, following factors can influence performance of parallel solutions from SAP parallel solution design point view The way which workload is divided. When total workload can be “evenly” in a way that each package can be processed in same amount of time, then the time is needed to process the total workload would be reduced. If total workload is divided into 2 packages, you use two parallel processes. If one package takes 10 minutes and the other package takes 1 hour, the system would use two work processes and take 1 hour to process the total workload. But one process would run for 10 minutes and the other process would run for 1 hour – this is an uneven situation. It would be ideal that total workload can be divided into two packages but each of two packages takes 35 minutes so the whole workload can be processed via two parallel work processes in 35 minutes. Size of package can influence performance depends on business situation. In some special situation, you need to consider resource usage of each package under a specific size to make sure that overall resource usage by all parallel processes is what the system can afford. Parallel solution can engage SAP background process or SAP dialog process. When SAP dialog process is used, you need to make sure that size of package would not cause timeout of child process due to hitting system limit. Parallelizing degree or the number of parallel processes allowed. Parallelizing degree – This is number of SAP work processes which can be engaged at the same time to handle workload. Higher degree means more SAP work processes for parallel processing – so more package can be processed at the same time, so the workload can be processed faster – this is what table-1 tells us. How many parallel processes a parallel solution should use? This depends on available system capacity and business performance requirement normally. The typical system resource used in parallel processing is CPU power. Each parallel process would need to use a CPU. Number of parallel processes used in a solution should not be more than number of CPU which a system has assuming that parallel process is the only program running in the system. In a SAP ERP system, there are normally many activities going on at the same time, this would reduce available CPU power for parallel processing. In a SAP ERP system, all business transactions would involve database/IO operation, during database/IO operation, it would not use CPU power of application server, this would allow you to use more parallel processes than number of CPUs which your application servers have. Business performance requirement is important to determine how many parallel processes you need. If a system resource is not enough to support the parallel processing, then resource has to be added. If system has more resources than what is needed to meet business performance requirement. Should we design the solution to use all available resource and let the parallel solution to finish as soon as possible? This depends. I normally prefer to give just enough resources to meet business performance requirement. In addition to CPU, if your solution is using a lot of memory, then you need to consider whether server memory can be a limit factor for parallel solution. In reality, database operation is a significant portion of many SAP transactions/programs runtime, more parallel processes would have a higher chance of creating “wait” situation in database operation. Performance benefit with increased parallelizing degree would go down and while cost would go up after a certain number of parallel processes. Parallel solution is going to amplify risk which a non-parallel solution might have. Running one copy of bad code might be ok to the system but running 10 copies of the same bad code might bring a system down. Order in which packages are processed. This is important when number of packages for processing is bigger than number of SAP parallel work processes allowed and processing time of each package varies a lot, the overall processing would be shorter if packages which take more time are processed first. For example, every package needs 1 minute and 2 parallel processes, then it would take 50 minutes for 2 parallel processes to process 100 packages. Now, imagine one specific package out of 100 packages would need 100 minutes, if this package is processed as 1st package or last package, what difference would the order difference make to the time needed to process 100 packages? It is 149 minutes against 100 minutes. There are other factors which can influence performance of parallel processing like type of server, IO system and database etc. but these are not unique to parallel processing. Last not least, characteristics of business solution itself can impact performance of parallel solution. But we cannot go around itself if we need to use parallel solution to increase the performance. 5 Technical overview of SAP parallel process implementation All works in SAP system are executed via various SAP work processes. An execution of a SAP business transaction/program always starts with a SAP dialog or background process and engages other types of SAP work process whenever needs arise dependent on the nature of underlying SAP program. All business logic of a SAP program is executed via SAP dialog or SAP background work process. So SAP parallel solution is implemented via SAP dialog work processes and/or SAP background work processes. If there is no free dialog/background SAP work process, no user can execute any program online and no background job can start. 5.1 Parallel process solution implemented via background job Every package of workload is processed by one SAP job/SAP background process. But more than one job which is running the same SAP program is processing packages at the same time. The total workload to be processed is divided into smaller packages which are represented by program variants in SAP. Then more than one copy of the program is executed concurrently in background – each works on one package via one of aforementioned variants. It is the parent program logic to divide the workload into smaller packages based on predefined criteria, then loop through those packages, keep launching child job to process those packages while SAP background process is available and there are unprocessed packages. The standard SAP Function modules like “Job_submit” etc. in SAP function group “BTCH” are used to create, schedule and monitor child jobs. If you are interested in how to program this, please check SAP document – SAP programming with background processing system. How many SAP background processes can be used to process those packages? This can be controlled by program and system setting A predefine number of parallel SAP job/background process which a business process is allowed. A SAP server or a SAP job server group for your parallel solution – then all available SAP background processes in the SAP server or SAP job server group can be used for parallel processing. If the server group contains all servers in the SAP system, then parallel solution can use all available SAP background processes from the SAP system. SAP transaction SM61 can be used to maintain SAP job server group Whole SAP system – if you do not use a predefined number, a server or a server group, then it can use all available SAP background processes. When you design this, please bear in mind the points discussed related to parallel degree. So how many SAP background processes would be actually engaged when a parallel solution is running. This depends on how many packages and smaller of two values: allowed parallel degree and number of free background processes. A work process is free mean it is not engaged in any work and ready for new task. For example, assuming allowed parallel degree is 10 background processes, if number of packages is 2, you can see up to 2 active SAP jobs at the same time in SAP job monitor transaction SM37 or up to 2 running background processes in SAP process monitor transaction SM50/SM66. If number of packages is 100, you can see up to 10 active SAP jobs or SAP background processes at the same time via SAP SM37 or SAP SM50/SM66. In ideal situation, the parent program should launch 10 jobs then launch next job whenever one of 10 job finishes and there are outstanding packages. In SAP IDOC processing or SAP interface, background processes can be launched by SAP automatically due to “volume” or “communication” failure or shortage of SAP dialog work process. When this happens, this is normally related to system or interface setting which is control via SAP transaction WE20 and SAP transaction SM59. 5.2 Parallel process solution implemented via SAP dialog work process Every package of workload is processed by one SAP dialog work process. But more than one SAP dialog process which is executing the same SAP program is running to process packages at the same time. Even though the idea is similar to parallel processing via background job through SAP background work process, but there are technical difference – Each package is passed to child process via program internal tables/variables instead of program variants which can be maintained via SAP transaction SE38. Child process is started via SAP asynchronous RFC (Remote Function Call) instead of SAP background job scheduling system. Please note term “Remote” – not mean that Function module called (executed in child process) is always executed in different server/system. In parallel solution, The function module is always executed in the same server/system where the parent program/process is running Each Package is processed via a SAP dialog work process instead of a background work process. SAP dialog work process is subjected to “timeout” setting which is specified via SAP system parameter rdisp/max_wprun_time while SAP background work process has no such limit. From SAP programming point view, parallel process is implemented via CALL FUNCTION statement similar to what you seen in figure 1 Figure 1 – Asynchronous RFC call for parallel processing Figure 1 is a piece of standard SAP code. It is from standard inbound IDOC processing program RBDAPP01. The key words for asynchronous RFC are “CALL FUNCTION“, “starting new task” and “DESTINATION“. So if you see three key words in a SAP ABAP statement, you know the program is using asynchronous RFC call for parallel processing. If you are interested in how to program this, please check SAP document – Implement Parallel Processing. How many SAP dialog work processes can be used to process those packages? This depends on specification of “DESTINATION” and configuration of destination as well as free dialog work processes of the destination. If the ABAP program specifies a destination “NONE” – this means that the program would use free dialog work process on the server where the program is executed. So Number of dialog processes can be used is up to the free dialog process in the server. If the system has only one server, then it is whole system. If the ABAP program uses “group” destination like figure 1 – then number of dialog processes can be used is determined by RFC server group configuration (determined by SAP program parameter P_rfcGR in figure 1). SAP RFC server group controls which server of a system can be used for parallel processing and how many processes can be engaged from each server of the sever group. This is the typical parallel solution setting. RFC server group is maintained via SAP transaction RZ12. So how many SAP dialog processes would be actually engaged when a parallel solution is running. This depends on how many packages and smaller of two values: allowed parallel degree and number of free dialog work processes. You can review parallel process via SM50/SM66. But you could not review them via SAP transaction SM37 which is for background job. However how many parallel processes you can actually see in SM50/SM66 might be different from what are actually active since SAP dialog work process are shared and a program can be rolled out of a dialog work process during waiting. In SAP IDOC processing or SAP interface, EDI/ALE partner profile setting can have an actual effect of parallel processing. When the partner profile setting for a message has a real-time or “immediate” processing setting for an inbound IDOC processing, when many IDOCs are arrived at the system in the same/short time, each IDOC would be processed via one dialog processes subject to availability of free dialog process in the whole system, this kind of “parallel processing” can bring down system when volume is high. SAP has provided utility to execute current SAP program in parallel with minor configuration. This is enabled via SAP transaction WLCPAR and WLCPARC. This might be handy when needs arise. 5.3 What are steps to implement a parallel process? With above knowledge on parallel processing, it is time to discuss what are the steps to implement a parallel process: Figure 2 – Parallel process implementation steps Quantified performance requirement includes what volume should be processed and duration which the volume should be processed. Design or code for a program which used in parallel processing should be well tuned before a parallel solution is considered. Parallel solution is going to run the program in more than one copies. Any expensive operation would be amplified in parallel solution. Sometime, a solution can meet performance requirement without engaging parallel solution by using alternative design or coding, Design of parallel solution includes implementation technique (should we use SAP background work process via job scheduling or should we use SAP dialog work processes via asynchronous RFC or both ), criteria of divided workload or the total volume (should we based on date-time, SAP organization unit, number range, number of business objects etc), packet size determination (fixed packet size or dynamic calculation of packet size), package process order (if this matters), parallel process degree ( how many child processes is enough), server group ( should server group be used or not). RFC server group or Job group itself is not within program design scope – it is a joint decision among business owner, solution technical owner and performance capacity guy. Parallel degree should consider “available system capacity” when the parallel solution hits the system. One factor to influence whether we should use the SAP background process or SAP dialog process is how long the child process would run. Dialog work process is subject to timeout setting. Since business and system is very dynamic – it is good that packet size and server group etc. parameters should be flexible and easy to be maintained whenever there is a need instead of hard-coded somewhere. Validate parallel solution is to check parallel solution works well, meets business performance requirement, verifies resource usage and confirms there is no negative impact on the system which it is executed. 6 Some standard SAP parallel solution Following is a list of SAP functions which I encountered with parallel function. Inbound IDOC processing – SAP inbound program RBDAPP01, RBDMANI2. SD delivery creation – SAP transaction VL10A etc. SD billing creation – SAP program RV60SBAT. SAP workflow processing – SAP transaction SWEQADM_1. TRFC/QRFC processing – SAP transaction SMQS or SMQR. SAP MRP function – SAP program RMMPS000 and RMMRP000. SCM model integration – SAP program RIMODINI, RIMODAC2 etc. SCM CIF comparison/Reconciliation processes. BW data load and activation and reporting GATP Backorder processing. Except SAP program RV60SBAT and GATP backorder processing, all other functions use “dialog work process” for parallel solution. 7 Further information In this post, SAP transaction RZ12 and RZ61 are mentioned. I plan to write a post on how to define RFC server group via RZ12 in the future. You can click link SMQS and SMQR for more information on how to use those transaction for performance analysis and tuning in this website. If you would like to know how do we analyze/verify performance of an existing parallel process. I would cover this in my future post.