Комментарии 7
А что конкретно сделали-то? :) Как общая архитектура выглядела "до" и "после"? Из описания у меня создается впечатление, что вы написали некий "бэкэнд" (для чего?), который работает быстрее, чем Exchange, но при этом сам работает через Exchange, т.е. по сути является оптимизирующим работу прокси.
Привет!) Да, это забыли написать в статье)
Мы написали внутреннюю реализацию календаря, которая полностью обслуживает запросы пользователей и интеграции из других внутренних сервисов или пользовательских скриптов.
Внутренний календарь синхронизируется через коннектор с Exchange через события. Коннектор слушает события происходящие в Exchange и в нашем календаре и пересылает их между системами.
Это позволило увеличить производительность и стабильность календарей и актуальность отображения информации по встречам для всех участников; Пользователи не замечают проблем в случае неисправности с Exchange (к примеру сегодня одна нода EWS приболела и часть запросов падало, но пользователи которые работают с календарями через внутреннюю соц сеть даже не заметили (а таких большинство).
Так же тестовые площадки получили возможность работать "не с реальным" календарем, тем самым написание и тестирование не приводит к изменениям в реальных календарях пользователей или переговорок.
Как работало до: мы просто ходили напрямую в Exchange)
Эммм. А просто забалансить ноды Exchange вашим админам религия не позволила? Хотя ладно... Зачем я это пишу.
Велосипед знатный, опыта хапнули не по детски, что тоже хорошо.
Каждый проект внедрения успешный, просто не всегда для заказчика.
Немного смутило что у ребят эксч падает постоянно, а они календарь разгоняют.
Видимо мы не правильно выразились, "нестабильность" здесь имеется ввиду (что подкреплено графиками) временем ответов за календарями, а не "постоянными падениями";
Да, бывают проблемы у EWS но чаще всего это связано с плановыми работами, которые увы иногда проходят в рабочее время либо пошли не по плану. (Повлиять на время работ мы не можем)
Да и мы не отвечаем за Exchange, им занимается другой отдел другого направления, поэтому даже если бы мы захотели, помочь с ним не могли бы, мы отвечаем только за внутреннюю соц сеть)
Календарь мы не просто разгоняли, а реализовывали свой и синхронизировали его с Exchange (потому что он в текущий момент первоисточник) , чтобы решить не только проблемы производительности, но и минимум еще несколько озвученных в статье цели:
Подстраховаться на случай миграции на другое решение отличное от Exchange, с реализацией только коннектора к другому решению без внесения изменений в логику и код сервиса;
Автономность внутреннего календаря - в случае неисправности внешней системы или в принципе перехода на другое решение, функционал бронирования помещений и планирование занятости (календарь) не должны быть деградированны
Изоляция действия на тестовых площадках (по факту дополнение к п.2)
Синхронизация на мобильные устройства работает через Exch?
Нам надоела нестабильность Microsoft Exchange, и мы перевели компанию на новый бэк календарей