Recently I was asked to look at an interface which had some serious performance issues. The interface was responsible for downloading tasks (and sub-tasks) into the database, and was taking around 35 minutes to complete: Pre-Optimisation Performance The setup was as follows: Pre-Optimisation Workflow The database call was split up as follows: • Pre-processing • Insert tasks (one call per task) • Insert sub-tasks (one call per sub-task) • Post-processing PI has the ability to contain all of these parts in one message, which in this case is a necessity because the sender interface is synchronous. However, PI has some more flexibility with asynchronous interfaces, and in this particular scenario, ECC did not require the response (which was left unhandled). We were able to implement a tRFC in ECC (which is an asynchronous version of RFC). This meant we could split the message into 4 parts, each processed separately. Using the Interface determination for this avoids the need for BPM, and allows us to assign separate communication channels for each part. It also allows us to maintain the order in which parts have to be processed (naturally, the post-processing must happen after all the rest). Using this setup allows us to optimise each part separately. The two insert tasks benefitted greatly from using the batch-insert option provided in the JDBC adapter, and after also enabling bind variables, the processing time was just a fraction of the original (around 200x faster): Post-Optimisation Performance Original: ~5000 records in 35 minutes Optimised: ~7500 records in 15 seconds

11 Jun Recently I was asked to look at an interface which had some serious performance issues. The interface was responsible for downloading tasks (and sub-tasks) into the database, and was taking around 35 minutes to complete: Pre-Optimisation Performance The setup was as follows: Pre-Optimisation Workflow The database call was split up as follows: • Pre-processing • Insert tasks (one call per task) • Insert sub-tasks (one call per sub-task) • Post-processing PI has the ability to contain all of these parts in one message, which in this case is a necessity because the sender interface is synchronous. However, PI has some more flexibility with asynchronous interfaces, and in this particular scenario, ECC did not require the response (which was left unhandled). We were able to implement a tRFC in ECC (which is an asynchronous version of RFC). This meant we could split the message into 4 parts, each processed separately. Using the Interface determination for this avoids the need for BPM, and allows us to assign separate communication channels for each part. It also allows us to maintain the order in which parts have to be processed (naturally, the post-processing must happen after all the rest). Using this setup allows us to optimise each part separately. The two insert tasks benefitted greatly from using the batch-insert option provided in the JDBC adapter, and after also enabling bind variables, the processing time was just a fraction of the original (around 200x faster): Post-Optimisation Performance Original: ~5000 records in 35 minutes Optimised: ~7500 records in 15 seconds

Recently I was asked to look at an interface which had some serious performance issues. The interface was responsible for downloading tasks (and sub-tasks) into the database, and was taking around 35 minutes to complete:

The setup was as follows:

The database call was split up as follows:
• Pre-processing
• Insert tasks (one call per task)
• Insert sub-tasks (one call per sub-task)
• Post-processing

PI has the ability to contain all of these parts in one message, which in this case is a necessity because the sender interface is synchronous.

However, PI has some more flexibility with asynchronous interfaces, and in this particular scenario, ECC did not require the response (which was left unhandled). We were able to implement a tRFC in ECC (which is an asynchronous version of RFC).

This meant we could split the message into 4 parts, each processed separately. Using the Interface determination for this avoids the need for BPM, and allows us to assign separate communication channels for each part. It also allows us to maintain the order in which parts have to be processed (naturally, the post-processing must happen after all the rest).

Using this setup allows us to optimise each part separately. The two insert tasks benefitted greatly from using the batch-insert option provided in the JDBC adapter, and after also enabling bind variables, the processing time was just a fraction of the original (around 200x faster):

Original: ~5000 records in 35 minutes
Optimised: ~7500 records in 15 seconds