Пока да, подключение и синхронизация календаря на мобильных устройствах пока только через Exchange.
Были идеи сделать CalDav апи (но по другой задаче не связанными с календарями и до их переделки), но ее отложили. Сейчас вернулись к мысли добавить такой функционал решив сразу две задачи)
Видимо мы не правильно выразились, "нестабильность" здесь имеется ввиду (что подкреплено графиками) временем ответов за календарями, а не "постоянными падениями"; Да, бывают проблемы у EWS но чаще всего это связано с плановыми работами, которые увы иногда проходят в рабочее время либо пошли не по плану. (Повлиять на время работ мы не можем)
Да и мы не отвечаем за Exchange, им занимается другой отдел другого направления, поэтому даже если бы мы захотели, помочь с ним не могли бы, мы отвечаем только за внутреннюю соц сеть)
Календарь мы не просто разгоняли, а реализовывали свой и синхронизировали его с Exchange (потому что он в текущий момент первоисточник) , чтобы решить не только проблемы производительности, но и минимум еще несколько озвученных в статье цели:
Подстраховаться на случай миграции на другое решение отличное от Exchange, с реализацией только коннектора к другому решению без внесения изменений в логику и код сервиса;
Автономность внутреннего календаря - в случае неисправности внешней системы или в принципе перехода на другое решение, функционал бронирования помещений и планирование занятости (календарь) не должны быть деградированны
Изоляция действия на тестовых площадках (по факту дополнение к п.2)
Привет!) Да, это забыли написать в статье) Мы написали внутреннюю реализацию календаря, которая полностью обслуживает запросы пользователей и интеграции из других внутренних сервисов или пользовательских скриптов.
Внутренний календарь синхронизируется через коннектор с Exchange через события. Коннектор слушает события происходящие в Exchange и в нашем календаре и пересылает их между системами.
Это позволило увеличить производительность и стабильность календарей и актуальность отображения информации по встречам для всех участников; Пользователи не замечают проблем в случае неисправности с Exchange (к примеру сегодня одна нода EWS приболела и часть запросов падало, но пользователи которые работают с календарями через внутреннюю соц сеть даже не заметили (а таких большинство).
Так же тестовые площадки получили возможность работать "не с реальным" календарем, тем самым написание и тестирование не приводит к изменениям в реальных календарях пользователей или переговорок.
Как работало до: мы просто ходили напрямую в Exchange)
Мне помогает следующий метод: Пользуйся своим проектом. В процессе использования понимаешь, что не так и что надо добавить, чтобы самому было комфортнее пользоваться.
Пока да, подключение и синхронизация календаря на мобильных устройствах пока только через Exchange.
Были идеи сделать CalDav апи (но по другой задаче не связанными с календарями и до их переделки), но ее отложили. Сейчас вернулись к мысли добавить такой функционал решив сразу две задачи)
Видимо мы не правильно выразились, "нестабильность" здесь имеется ввиду (что подкреплено графиками) временем ответов за календарями, а не "постоянными падениями";
Да, бывают проблемы у EWS но чаще всего это связано с плановыми работами, которые увы иногда проходят в рабочее время либо пошли не по плану. (Повлиять на время работ мы не можем)
Да и мы не отвечаем за Exchange, им занимается другой отдел другого направления, поэтому даже если бы мы захотели, помочь с ним не могли бы, мы отвечаем только за внутреннюю соц сеть)
Календарь мы не просто разгоняли, а реализовывали свой и синхронизировали его с Exchange (потому что он в текущий момент первоисточник) , чтобы решить не только проблемы производительности, но и минимум еще несколько озвученных в статье цели:
Подстраховаться на случай миграции на другое решение отличное от Exchange, с реализацией только коннектора к другому решению без внесения изменений в логику и код сервиса;
Автономность внутреннего календаря - в случае неисправности внешней системы или в принципе перехода на другое решение, функционал бронирования помещений и планирование занятости (календарь) не должны быть деградированны
Изоляция действия на тестовых площадках (по факту дополнение к п.2)
Привет!) Да, это забыли написать в статье)
Мы написали внутреннюю реализацию календаря, которая полностью обслуживает запросы пользователей и интеграции из других внутренних сервисов или пользовательских скриптов.
Внутренний календарь синхронизируется через коннектор с Exchange через события. Коннектор слушает события происходящие в Exchange и в нашем календаре и пересылает их между системами.
Это позволило увеличить производительность и стабильность календарей и актуальность отображения информации по встречам для всех участников; Пользователи не замечают проблем в случае неисправности с Exchange (к примеру сегодня одна нода EWS приболела и часть запросов падало, но пользователи которые работают с календарями через внутреннюю соц сеть даже не заметили (а таких большинство).
Так же тестовые площадки получили возможность работать "не с реальным" календарем, тем самым написание и тестирование не приводит к изменениям в реальных календарях пользователей или переговорок.
Как работало до: мы просто ходили напрямую в Exchange)
Видел еще один эмулятор флеша, оставлю ссылку, вдруг кому пригодится: https://github.com/lightspark/lightspark
Мне помогает следующий метод: Пользуйся своим проектом. В процессе использования понимаешь, что не так и что надо добавить, чтобы самому было комфортнее пользоваться.