I worked in Japan for EDI project, the interface is between my client Haier and 8 biggest Japanese retailer, the Japanese retailers use the flat file for data exchange, within 1 file there are up to 1000 Idocs, I used the sales order as example to explain how I solve the performance problem for huge file, at the beginning we got shortdump all the time, this blog is my memory for the terrible disasters which happened in Japan and for my colleagues who are more courageous than me.
- Configure the Inbound processing
If you are interested in the configuration of partner profile and port of Unicode system, please check my another blog.
Here I explained the difference for the performance of inbound process. At the beginning I configured the system as trigger immediately, it works well when the idoc file contained less than 100 idocs, but when the file contained up to 1000 idocs, the system got shortdump each time. I thought it was my enhancement which cause the problem, after 2 weeks review and analyze, I realized that all the processes needed to obtain an application object number from the number range tables, the number ranges may need to be loaded into a buffer that needs a work processor, and this process could deadlock and indefinitely wait on resources which cause the performance bottleneck. So I changed the configuration of partner profile as trigger by background program.
- Trigger the inbound process
I wrote the program which call the function module EDI_DATA_INCOMING in the predefined the directory where received the file by FTP, the file name is also predefined by client, interface function, date and time. This step is generating the idoc, it’s not been proceeded in the application yet, so the status of all the idoc is 64.
I set the job of RBDAPP01 run right after the my customizing program, this job is based on each client.
The pack size is 100 which is the best performance for multiple idocs.
I set the parallel posting with the server group, the maximum number of attempt is 10. The reason I use server group is distributing the workload, like that I can handle up to 1000 idoc within 1 file.
- Configure the outbound processing
Actually the outbound processing is not so complicated. In the partner profile I set the collect idocs.
In the message control I set automatically proposal the message type and running the background job.
I runned the job rsenast00 for the message type, this step generated idoc in the system, it’s not a idoc file yet.
- Generating the outbound idoc file
I created the function module to generate the idoc file based on each client, and configure this function module in the port
I run the job of rseout00 based on the each client and port, the port determine the name of file and directory.