Modeling Mapping Workflows
In Anveo EDI Connect, you normally use multiple mappings to model an EDI process. In the following we will have a look at very simple examples and another more complex one. The module is very flexible and you can map the process the way you want to, but the following examples are our recommended way to model the process.
Before we go into too much detail, let us clarify a few concepts. A mapping in Anveo EDI Connect can be executed. Then there is the concept of a database transaction. Put simply, a database transaction collects all changes to the database during a transaction. At the end of the transaction, the data can either be stored permanently, which is called a database commit. Or the changes can be reset, that is, all changes made during the transaction are undone and not saved. Each execution of a mapping is done in a separate database transaction. If there is an error during the mapping execution, the transaction is rolled-back. Otherwise the transaction is committed. (This is true for most mappings. In Anveo EDI Connect there are table triggers that can run arbitrary code. If that code contains a COMMIT command, the module cannot roll-back the changes. This can lead to unwanted behavior.)
Incoming XML Sales Order
We use three mappings in this example, to import a XML file. This is the recommended minimum. In the first step we will map the external data structure to buffer tables. The idea is to import the data, even if not all data can be processed. This will enable the end-user to correct errors in the EDI transaction, without the knowledge about the external data format. Of course this is only possible, if there are data errors, not if the file structure cannot be parsed.
The next step is to check the data. Here you can add any logical checks on the business data. We recommend to do this in a separate step before the processing to collect multiple error messages and give the end-user a complete error protocol. If you need to lookup data from the system table and want to persist it, we would do that in a fourth step between the external and the check mapping.
The last step is the creation of the Microsoft Dynamics NAV 2009R2 Classic document. We do this in a separate step, to keep table locks on system tables as short as possible.
Outgoing EDIFACT Invoice
On outgoing documents, you have usually some values, which are not directly stored in the Microsoft Dynamics NAV 2009R2 Classic source table. To give the end-user the possibility to see this data and to simplify the external data format mapping, we recommend to write the data to a buffer table first. In this step you can lookup values and do calculations.
The export mapping just takes the buffered data and writes it in the target format.
EDI Process with Confirmation
The process does not have to be linear. If you need to send confirmations or if you want to group data, you can always call multiple mappings from one mapping. You can also use conditions and conditional branching, to execute different mappings based on the data.