In SAP S/4HANA Cloud, you can use the Schedule Billing Document Request Creation app to batch create billing document requests (BDRs) through scheduled jobs when you want to bill your service contracts. However, we observed some dumps caught by the backend program. One possible issue that causes dumps could be the resource shortage. It’s highly likely to occur with a BDR creation failure error after a very long time of job execution (over hours). To tackle that issue, SAP provided parallel processing as a solution.
App – Schedule Billing Document Request Creation (Service Contract)
This blog can help you understand how parallel processing works for the creation of billing document requests and when to use it.
We can assume that there’s a pool bringing in all the billing request lines (BRLs) pending creation of BDRs, but there’s only one pipe to deal with the BRLs one by one. When the BRLs in the pool are too numerous, say 10,000 in total, one single pipe is not sufficient and can easily fail. The failure may terminate the background job for the BDRs creation. To solve the problem and improve the performance, one may think about making more pipes, that is the “parallel processing” we’re talking about in this blog.
This parameter defines the maximum number of parallel tasks that can be assigned to one BDR creation job. It is visible in the Schedule Billing Document Request Creation app. The program allows two to five parallel tasks. A useful rule of thumb is that 2 or 3 at business hours while 4 or 5 at non-business hours. We recommend to increase the parallel tasks number only when the system is not busy because with parallel processing the job consumes more system resources than that without parallel processing.
This parameter means at least 100 billing request lines can be included in one package of the processing work process, unless the number of remaining billing request lines is less than 100. SAP predefined this parameter and it’s not visible in the app.
During the job execution, the BDR creation program packages BRLs at the service contract item level based on the minimal package size. Pay attention to the following basic rules:
The following diagram gives you an example that may help you understand.
For a pool with three service contracts that respectively contain two items with different numbers of BRLs. We choose 3 parallel tasks maximum. With the predefine 100 minimal package size, the program includes the 150 BRLs from the two items of the first service contract to Package A. Because the first item of the second service contract already contains 100 BRLs, the program puts all the BRLs to one package – Package B. Similarly, 200 BRLs in the second item of the second contract make up Package C. The rest 70 BRLs from the third service contract are less than 100, but since there’re no more BRLs in the pool, the program puts all of them in one package – Package D.
Then a dispatcher is responsible to assign the packages to the three parallel tasks. Parallel Task 3 processes Package C first and other tasks are still busy. Therefore, it starts processing Package D in the queue. Finally, the job finishes the creation of the total 520 BDRs!
Example: Parallel Processing
Before provision of parallel processing, we tested how much performance improvement can be achieved by it in SAP internal system. It’s also a key factor that we could finally release it as a solution. Our test result shows that the BDR creation of more than 5, 000 BRLs via parallel processing when maximum number of parallel tasks set to 5 is five times faster than that is dealt with by a single job.
You can see more details from the curve below. It’s clearly shown that from 1,000 BDRs, the parallel tasks start to make a difference and a big difference at the number of 5, 000 and 10,000.
Performance Test Result
A simple answer is by Simulation. SAP provided it so that you can test run the job execution without actually creating any BDRs. The simulation result tells you the number of BDRs that would be created for a certain number of service contracts. Therefore, for our case, if that number is too large, you can proactively decide to choose parallel processing. Our recommendation is to use parallel processing when the number of BDRs is more than 1,000.
In this blog, we explained how parallel processing makes the BDR creation job done and how it helps improve the job performance. A simplified example demonstrates the backend logic. By sharing you the performance test result in our internal system, we recommend best practices for you to set up the parallel processing.
If you have any questions about the topic, feel free to ask questions in Q&A forum of SAP Community or leave your comments below.
For more information, read our product assistance in the SAP Help Portal: