Parallel Processing of IDOCs to optimize performance

[Former Member]

Optimizing System Performance using Parallel Processing of IDOCs

What is Parallel Processing?

Processing multiple IDOCs at the same time in different dialog processes. This reduces the waiting time for multiple IDOCs in same dialog process.

e.g of a Typical Scenario:

In Direct Store Delivery(DSD), Sales Person synchs multiple orders from Handheld  to SAP. In SAP these Orders are processed as IDOCs and they need to be processed in a very short span of time and Information is to be sent back to Handheld. This activity is very much time critical and hence IDOC processing performance counts a lot.

Necessity for Parallel Processing:

While sending and processing mass idocs in ECC system there might be performance issues as generally idocs get processed one by one in single dialog process and then they wait in queue which increases overall lead time. Some real time applications where mass update is very much time critical, parallel processing helps to optimize overall performance.

Steps to achieve parallel processing in ECC:

 Step 1: Setting up server group to handle parallel processes

How to Achieve: Basis needs to define Server Group and allocate certain dialog processes to that server group.  These dialog processes will be specifically allocated to parallel processing used for this server group.

e.g.: Define Server Group as Parallel Process and allocate 8 dialog processes to this group.

This will allow mass IDOCs in all dialog processes parallel and more the number of processes more IDOCs will be picked up at runtime and improving processing time

CONS:  System Resources should be capable of dedicating the designated number of processes to parallel processing otherwise it could slow down the system performance for other processes due to lack of enough resources. The total number of dialog processes to be allocated to server group is totally a basis team's call depending on system load.

STEP 2: BD51 Config

Configure the function module for inbound processing to handle MASS Processing in INPUTTYPE. These transfer packets of IDOCs for which individual IDOCs are updated in the same Logical Unit of Work (LUW). For rest options, only single IDOC gets processed in one LUW.

Step 3: Setting up job with RBDAPP01

 We need to take care of 2 options while setting up variant for RBDAPP01:

1. Packet Size: Packet processing enables one program or one function      module to process batches of data of the same type. This reduces the      number of dialog processes called and improves system performance. Packet      processing and parallelism complement one another. Packet processing and      parallelism complement each other, although in some situations they may      compete with each other. If there are too many master data objects in each      process, possibly not all available dialog processes will be used.

Ideally we should give 20-100 as packets,

2. Give      Server Group Under Parallel Processing option

3     Execution      of program: We can set up background job with variant and execute it.SAP      recommends that we should schedule next RBD job once the existing ones is      finished else it could lead to locking issues.            

Consider       scenario of ECC receiving 50 idocs

• Parallel Process Server group is ready with allocated 8 processes
• RBDAPP01 Program is set for parallel processing with packet size 5

 

Following Diagram depicts parallel processing:

40 idocs will be processed at the same time and rest 10 will be waiting to be picked up.

5 idocs will be processed at a time within same LUW due to mass processing option and packet size.

Benefits achieved:

If we had not enabled Parallel processing option, all 50 idocs would have been fed to RBD program and will be processed one after other as per availability of dialog process at run time and we don’t have control on number of idocs being processed at one go.

This definitely slows down idoc processing time.

However, in case of parallel processing, since we have multiple processes dedicated to server group, it improves overall performance.

Challenges involved in Parallel Processing:

1. In      case we have requirement to run RBDAPP01 program in duration where earlier      program has not finished yet, same idoc might get picked up by multiple      processes and thus causing duplicate orders. This happens because RBDAPP01      pick up idocs only with status 64 and 66. So when Process picks up IDOC,      its changes to 66 only at the end and then it changes to 51/53 only at the      end. So in between all the time if idoc status in still 64, it gets picked      up by another process.

       This in turn causes duplicate idoc processing issues.

       SAP Note 902806   states the same problem and hence if we have such a        situation, we should try to customize above solution a bit.

Solution to overcome Duplicate IDOC Processing:

Create a custom RBDAPP01 program which picks up IDOC and  set it’s custom status in Custom table and  also checks custom status before processing IDOC so once IDOC is picked up, there are no chances of it getting picked again.

But make sure to handle update on any custom table in parallel processing be controlled via ENQUEUE /DEQUEUE.