AcumatiCares
Acumatica, positioned as a mid-market ERP, can be deployed for a wide variety of companies – large, medium, or small. As companies experience growth, the amount of data it needs to manage grows. However, in my experience developing custom code on the Acumatica platform, I find a significant number of organizations I work with punching above their weight when it comes to managing and processing data.
Acumatica has a wide variety of processing screens to perform various tasks “en masse”, and additionally has a robust yet easy framework to follow for implementing your own processing screens. Out of the box, however, records are processed sequentially (1,2,3 etc.). Fortunately, it is possible to enable parallel processing for clients with large data processing requirements.
Parallel processing takes advantage of the fact that applications can utilize more than a single processing thread at once. Think of the days before computers, where clerks manually processed transactions by hand. How did you speed up the number of transactions you can record? Either you search high and low for the wonder clerk who is super-fast, or you simply hire more clerks and split the work evenly amongst them. Acumatica can be configured similarly.
To enable Parallel processing, you need to add the following keys to the web.config file under the Configuration/Appsettings node:
GIST: https://gist.github.com/lekker-solutions/320b32b5eeb15e36ce29957095862b3d
To test this, lets add these keys to the web.config file and create a basic processing screen that processes a list of records:
GIST: https://gist.github.com/lekker-solutions/46b8a010c4ceae41bea63707b8e9ba22
Even though we have added the keys, the processing screen still returns the entire list of GL Batches when “Process All” is selected.
This is due to the keys only setting a global rule on processing. It still needs to be enabled on your custom screen itself. The code below demonstrates how:
GIST: https://gist.github.com/lekker-solutions/33552d7e645905d0a995a9df7f56db49
Now let’s try the process the all button:
When you look at the result of the processing screen, you can see that all records have been processed even though that thread we caught only saw 10:
Here is a diagram illustrating the difference between the two, and where the breakpoint is caught in the code:
During sequential processing, the thread (aka the clerk) saw the entire list of items to process. In parallel processing, the thread only saw the max number of items (specified at a max level in the web.config file and additionally in the parallel processing options at the screen level).
Parallel processing, while not a silver bullet, can significantly increase the processing capability for Acumatica users working with large amounts of data. With just a few changes to the web.config file, you can easily enable it on both the base ERP code and your custom code. There is no need to manage your own threads and the other complexities that come with it.
I hope that this article will help you with the data processing volume that is ever increasing at a faster and faster pace in this digitally transforming world.
Happy Coding!
