Anveo EDI Connect is build to have flexible mappings that can be changed at runtime. The core functionality is developed completely in Microsoft Dynamics NAV 2013R2 with all advantages and disadvantages. All settings are stored in the database and need to be retrieved during runtime to determine how the module will handle the EDI data.
The speed of the module heavily depends on a fast way for the Service Tier to retrieve the EDI properties. For each field that is read or written from a file the module will need to get a bunch of settings from the database to handle the data correctly. This is performed on a single CPU core on the service tier. So it is important to have enough single CPU core performance available at the service tier, to have a fast connection to the database and to have enough resources on the SQL server and service tier.
Run Performance Tests
Whenever you start a project with a high EDI load, or you want to import big files we recommend to setup the import mapping without all details and run performance tests. You can also contact our support to ask them for their advice whether your scenario can be safely handled with the module or whether you should test it first.
Each mapping runs in its own database transaction and might lock the tables that are used inside the mapping. Keeping mappings as fast and small as possible will help to reduce table locks on the tables used inside the mapping.
We have optimized our own system tables to be used by multiple EDI processes in parallel. However, this does not apply to our buffer tables, which, like any other table, can be locked by a mapping. We therefore recommend to execute EDI processes as serial as possible and to avoid parallel execution as far as possible.
If locks occur mainly on our buffer tables, e.g. the ANVEDI document, it may be useful to think about own buffer tables for processes with a high amount of data.
Table locks are mainly of concern in normal daytime operations, where users are waiting for resources and different loads can lead to different behavior. If the process allows it, we recommend to schedule EDI jobs at night, or for example at lunch time, in order to reduce the load on the system.
Certain properties will have a performance impact on your mapping. In general you should try to avoid any loops that are not necessary. If you import data most converters will check the retrieved data structure for each table line in write mode. You can gain performance, if you set the minimal repeat count on write tables if you know that the data will be present in the file. (And if you get a corrupted file the module will still give an error message, because the loop cannot be converted).
You should only import data to the buffer tables that is used either in the further processing of the data or by the user to find and understand errors. Importing data that has no value to the end user and is not used later on in the process will have a negative performance impact.
Reducing the count of lines in the mapping can improve the performance.
On import mappings you can delete any data element from the mapping that is not used. The module will only need the segment information. Each data element stores a position in the file, so removing elements before one that you need will not change the processing. The only downside of this approach is that you might have to add the element again, if you need to process the data in the future. If you put tables on the EDIFACT groups, you should set the min repeat on the table, if the group is mandatory.
On exports you can delete any data element that does not contain a value. The module will automatically write to the correct position if a few data elements are missing and you will speed up the whole mapping.
Reducing the count of lines in the mapping for a text file is often possible, if there is a structure at the end of the line that is not needed. Instead of reading all those fields you might want to use a single mapping line to read everything to the end of the line, if you do not need to process the information.