Skip to Content

Emigall PAYMENT object performance optimization


We have a requirement to migrate FICA history for 1 year ( opened and closed items). For migration of open items we are using EMIGALL object DOCUMENT and we are migrating around 8 million documents per hour.

For migration of closing open items (payments) we are using PAYMENT object in emigall, and we are migrating around 300.000 per hour, much less then documents but usage of CPU and DB resources is much higher. Also when we migrate payments for every background process there are around 5 dialog processes connected to tRFC queues.

For optimization of import we implemented chapter 7.12 PAYMENT from EMIGALL performance guide, applied note

775917 (“Performance migration FACTS, DOCUMENT, PAYMENT”) and note

2140916 - Performance issues in RFC processing (Oracle) but no significant performance was gained.

Our goal is to reach around 3 million PAYMENT object per hour using multiple threads. Did someone had similar requirements and what optimization need to be done to raise the performance?

thank you and kind regards,


Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

2 Answers

  • Best Answer
    Apr 25, 2018 at 12:42 PM

    Hello Amlan,

    Thank you for suggestions but solution was something else.

    As I mentioned migration triggered creation of many RFC calls and processing started in dialog. Other FICA objects were processed by BCKG processes. So I did event trace with transaction SWELS and there was and event that was risen forcing processing into tRFC queues. We disabled it during migration and this is where we found our missing performance. After that PAYMENTs were processed in background with similar performance as DOCUMENTs.

    Kind regards,


    Add comment
    10|10000 characters needed characters exceeded

  • Nov 15, 2017 at 05:04 PM

    Hi Danko,

    Some suggestions for optimising the performance of migration object PAYMENT are as follows:

    1. Do not use number range buffering, as mass processing in FI-CA is used
    2. Create a sufficient amount of number range intervals and assign them to the used document type in Customizing
    3. Commit buffering. Please note that every document to be settled may only be settled or partly settled once within the same import run and LUW. So its recommended that you do not import payments for one business partner in different parallel runs, otherwise lock problems can occur. These locks are only released by the Commit Work statement. If consecutive documents do not often settle the same original posting, you can use a low value – say 10 – for buffering. You can recognize problems that originate from these restrictions by a high number of error messages “completing processing"
    4. Configure additional DIA work processes for the central instance. Ensure that the number is at least equal to the number of parallel running import jobs. RFC calls are always triggered to the central instance because the import runs read information from the server. If no idle DIA work processes are found, the status of the import job changes to “waiting - CPIC“ and only continues when another DIA work process is available. Alternatively you could run the import on a really powerful central instance instead of on the application servers. This allows you to avoid the overhead triggered by the RFC calls.

    Hope it helps



    Add comment
    10|10000 characters needed characters exceeded