Синхронизация контактов Outlook - Как определить правильный объект для синхронизации?

Question

У меня есть веб-приложение, которое синхронизирует контакты Outlook с базой данных (и обратно) через CDO. БД содержит каждый контакт только один раз (по крайней мере, теоретически, конечно же, случаются дубликаты), обеспечивая единую точку изменения для контакта, независимо от того, сколько пользователей имеют этот конкретный контакт в Outlook (например, Interaction или подобные продукты).

Процесс синхронизации не автоматический, а инициализированный пользователем. Может пройти произвольный промежуток времени, прежде чем пользователи решат синхронизировать свои контакты. Подмножество этих контактов, возможно, было обновлено другими пользователями.

Как правило, все работает нормально, но мне никогда не удавалось решить эту фундаментальную проблему:

Как безошибочно идентифицировать контактный объект в почтовом ящике?

1. Я не могу положиться на PR_ENTRYID, это изменение свойства при перемещении контакта или перемещение почтового ящика.
2. Я не могу полагаться на свои собственные идентификаторы (например, БД идентификатор таблицы), потому что они копируются с контактом.
3. Я абсолютно не могу положиться на поля как имя или адрес электронной почты, они могут быть изменены и обновлены.

В настоящее время я использую комбинацию 1 (предпочтительно) и 2 (запасной вариант). Но неизбежно, иногда пользователи сталкиваются с проблемой синхронизации с неправильным контактом, потому что нет ни одного с данным PR_ENTRYID, а два с одним и тем же идентификатором БД, из которых выбран неправильный.

Существует множество продуктов для синхронизации с Outlook, поэтому я думаю, что проблема должна быть решена.

Answer 1

У меня была похожая проблема, чтобы преодолеть с помощью внутреннего плагина Outlook, который выполняет синхронизацию контактов. В итоге я прикрепил идентификатор базы данных в объекте Outlook и обращался к нему при выполнении синхронизации.

Разница здесь в том, что в нашей системе есть куча дубликатов, которые впоследствии разрешаются пользователями. Когда они объединятся, я удалю старые записи и обновлю прогноз со всей новой информацией вместе с новым идентификатором.

Вы можете выполнить нечеткое сопоставление, чтобы идентифицировать дубликаты, но разрешение дубликатов - это забавная проблема, в большинстве случаев пробная и ошибочная. Мы успешно реализовали «нечеткую» логику сопоставления, используя алгоритм расстояния Левенштейна для имен и адресов, очищенных до хеш-кода.

Удачи, мой опыт синхронизации был несколько болезненным.