The Mirror feature can be used instead of Source Control and will automatically create and keep updated a mirror (a copy) of the source table you are reading and use this mirror to compare with in order to find out what has changed. In this way (like with Source Control), only the changed or added records will be sent to the other system.
The Mirror feature is typically used with MS Dynamics AX, MS Dynamics C5 and native database MS Dynamics NAV systems.
The following changes have been implemented:
- During Mirror initialize (when a transfer is starting), the mirror functionality now builds a log message and sends this message to the central RapidiOnline where it is entered in the Log. This makes it possible to view statistic information about the update of the mirror in the central Log.
- Also during Mirror initialize the a status message is now sent back to the server each 2 minutes to tell the server how far the mirror update has come. Before working with very large source tables (typically more than 50-100.000 records) could cause a timeout in the communication between the central and the RapidiConnector during mirror update. Now this is fixed and furthermore you can see in the central what is happening on the mirror side.
- The Mirror is now also totally rebuild (deleted and build from scratch) if the Source Filters of the transfer is changed. Before this only happened when the list of fields to read changed.
- It is now possible to get the Mirror the rebuild itself from scratch. If you set the RTI counter to -1 on the Transfer that is using the Mirror, then the mirror will Rebuild next time the transfer is run.
Changes to the Autogenerate Key feature when used with MS Dynamics NAV as Destination:
- The Autogenerate Key feature now works differently. Before the feature only worked on Sub-Transfers or with a fixed Dest. Filter on a Main transfer. Now the feature will check what fields are in the primary key on the (Destination) Table; Use the last field as the field to generate a number for; and look for Filter values to be set on all the remaining fields in the primary key. It will first look in Dest. Filters and Link-Filters (for a sub-transfer), then it will check the Table Link fields. If filter values used are coming from the Table Link, then a new Autogenrated start value is fetched from the Destination table for each record to be written. This makes the feature work as expected for both Main and Sub-transfers.
- For the Autogenerate Key feature, it is now possible to control the starting value (the value used if there are no records within the Filter in the table) and the Increment value. These values can be controlled by altering the setting in the Rapidi.CFG file used by the local RapidiConnector. The values to modify or add to Rapidi.CFG are NavisionAutogenerateKeyStartValue: (default 0) and NavisionAutogenerateKeyIncrementValue: (default 1).
Other changes:
- Salesforce.com: When using Salesforce.com as Source and using "Transferred Field" or "Store New Id Field" to write back information to Salesforce.com, you dont need to have the Id field in the Table Link anymore (before the writeback did not take place if the Id was not part of the Table Link).
- MS Dynamics CRM: Now you can use MS Dynamics CRM LIVE in Europe and ASIA too.
- Lotus Notes: Fixed a problem with updateing TextLists, NumberLists etc. in a Lotus Notes document in a local Lotus Notes database (updated using the RapidiConnector).
- Fixed a problem when using Gather and using a RapidiConnector on the Destination side and when the destination was running in optimized UpdateAdd mode (where all records are sent to the RapidiConnector and its up to the RapidiConnector to find out if a record should be updated or added). The Gather was not run until after the records were sent to the RapidiConnector. Now the Gather is run correctly before the data is sent to the Destination.
- Added description message to the POSTDEL formula.
