Now, with this feature, recipients can be collected separately. It has been seen to improve performance, and reduces the staging area space requirements.
On the summary screen you’ll see confirmation that we’re going to use the EV Index.
Items are collected. They’re not exported. Once some item data has been collected, the collection for sender and recipient information is handled via the EV Collector, and it will query the EV Index. All of the recipients will be collected and sent to the core. This collection can be retried if required.
The layout can be saved, if required.
User mappings can be created based on this collected sender/recipient information, and the mappings enabled. When this is done, the EV Export module will then begin to export the data for those mappings. This reduces the storage area space needed for a journal transformation migration.
Leavers are supported in this scenario as well.
An important thing to note is that the EV Collector must run under a service account which has access to query the index for the archives mapping for migration.
Finally the failed item page has been enhanced to introduce a new tab ‘Sender Recipient Collection’. This will show any issues with collection of sender/recipient information from the EV Index. These errors can be retried, if required.
There is a fallback mechanism for collection. Collection will retry 10 times, before being marked as permanently failed. These items are exported in the old way, in order to get the sender/recipient information from the item itself, and the sender/recipient information gathered from that.