DIRECTUM Client for Outlook

Увидел и удивился - кто это на столько крут, что взял и переделал техническое решение "Outlook как offline-клиент DIRECTUM" в "DIRECTUM Client for Outlook". Потом заметил, что видео размещено на www.akelon.com, степень удивления уменьшилась. Но всё равно, отличная работа.

Есть вопрос, про фразу "полностью перенести работу с заданиями и задачами в Outlook" и про существующие ограничения этого переноса. Думаю его в деталях зададут заинтересованные в продукте лица.

История была проще ). Крупный клиент сказал "надо". Мы посмотрели на имеющееся решение. Оказалось, что оно с одной стороны еще в бете, с другой что не работает с задачами. А именно задачи были нужны - руководство компании ставит поручения из Outlook. 

Также не удовлетворил подход к реализации транспорта - в решении "Outlook как offline-клиент DIRECTUM" на сервере формируется письмо и отправляется получателю. Какие тут минусы? не обновляется статус переписки например. Сложно управлять версионностью вложений и т.д. 

Мы же сделали собственный транспорт, который именно что синхронизирует (а не только пересылает) объекты.

Там ведь не только задачи... Вот делает вы задачу в офф-лайн. Где-то надо брать список пользователей Директума, например. И таких ситуаций не мало. 

Это не переделка - это совсем другой подход. Выглядит безусловно круче, но не закрывает 100% возможностей старых продуктов (соответственно и потребностей тех, для кого разрабатывались старые решения).

А как решена проблема с запрашиваемыми параметрами если задание приходит по какому то маршруту? как реализована обработка событий задания: до запроса параметров, после запроса параметров.

Или весь функционал этого клиента также выполнен на законченные результаты задания? без взаимодействия с пользователем? или все взаимодейтсвие заключается только в изменнии текста и выборе соответствующего пункта?

В трансляции ISBL кода собака и зарыта. Как обычно. По факту мы сейчас имеем две версии DCO.

1. Коробка - там только вариант выполнения и текст задания, плюс работа с вложениями. В целом покрывает при незначительном усилии со стороны внедрения 90% задач пользователя.

DCO все таки не есть полная замена толстому клиенту - функций меньше, а значит и использование системы может теоретически деградировать в организации при массовом его использовании. DCO - решение для мобильных пользователей и пользователей с предельно простыми задачами. Отправить поручение, выполнить задание и согласовать документ. С последним кстати тоже все не просто имея ввиду шифрование, ЭЦП и безопасность, хотя решения и есть.

Вот коробка и пойдет в "серию".

2. Конструктор. Мы (компания) интегратор. И собственно если клиент имеет потребность - мы ее удовлетворяем. Т.е. в отличии от DIRECTUM который нацелен на производство продуктов широкого потребления, мы можем позволить себе делать и "заточенное" ПО.

Так вот для таких случаев наше внедрение имеет возможность писать код на .NET для обработки запроса параметров и обработки событий. Выглядит для них все просто - надо сделать сборку на .NET с указанными методами и перекомилировать весь Add-In. Вот поскольку вся эта операция не из простых - в коробке ее пока и нет.

В целом RoadMap (как планируем развивать) выглядит так?

1. работа с документами через Общую папку Outlook (синхронизация папки "Избранное"). тут все упирается в производительность, пока думаем еще...

2. обеспечение возможности подключения сборок без компиляции всего проекта (или как минимум защитить основной код и давать возможность собирать проект с нашими библиотеками). Это надо прежде всего для нас - существенно упростит разработку кастомизированных клиентов.

3. разработка клиента для Outlook mobile. C точки зрения хранения информации все есть, осталось портирование интерфейса.

уточню себя ).

в решении на уровне структуры классов, DataMember (не знаю как перевести) и сервисов предусмотрено хранение и передача параметров при выполнении задания или старте задачи. Также объект "Задание" несет информацию о маршруте, по которому оно запущено и блоке workflow.

Поэтому разработчику надо сделать обработку для всех используемых типовых маршрутов (предполагаемых к использованию в DCO).

Интерес в офф-лайн клиенте есть, если этот механизм экономит конкурентные лицензии в самом Директуме. Пока непонятно как этот продукт будет лицензироваться. Мне показалось, что очень накручено всё, вполне достаточно того функционала, как этот клиент был реализован в Docvision (по информации 2-х годичной давности, сейчас не знаю куда они продвигаются). Просто и со вкусом.

Отвечая на вопрос: " А людям  это надо?" - ДА, но предварительно его надо пощупать. Предлагаю выпустить пробный релиз и сделать доступным его для народа. Попробуем - ответим конкретно.

Экономии точно не выйдет ). Это же политический вопрос.

Можно насчет ЭЦП и шифрования подробней, есть ли возможность:

1. Подписывать документы/получать информацию о подписях?

2. Работать с шифрованными документами? Насколько я понимаю - при работе через desktop-клиент, он и расшифровывает документ, а что произойдет в случае использования DCO - промежуточное перешифрование?

1. ЭЦП. Если документ имеет ЭЦП он будет передан в OverDoc. Однако эта операция существенно снижает производительность. Причина: просто документ мы берем прямо из SQL. А OverDoc - задействуем объектную модель.

Соответственно и поставить ЭЦП в OverDoc можно.

2. Безопасность. Тут все сложнее. Стандартное шифрование отпадает сразу - механизм закрыт. Перешифровать нельзя т.к. нет закрытых ключей у сервера.

Тут мы подходим к задачам шире и используем MS RMS. По сути документ передаваемый в DCO покидает периметр безопасности организации. В момент передачи мы можем его шифровать через RMS, установить мандат безопасности через DRM (например, ограничить время жизни за пределами периметра). Минусы: комфортная работа только с документами MS Office, и это заменяет шифрование Директума (а значит надо еще лицензировать, поддерживать и т.д.).

Второй пункт реализован только как прототип. Сейчас вот будет тендер - выйграем, будет готовое решение ).

Фишка в том, что если используется файловое хранилище, то в SQL базе тела документа не будет (тело будет находиться на диске ФХ). Другими словами, в механизме есть дефект, который проявится в связке с ФХ (если, конечно, я правильно всё понял). 

В целом все правильно. Но случай хранения в ФХ мы тоже обрабатываем, но забираем также напрямую - в данном случае обращаясь к файловому хранилищу. Только права должны быть соответственно открыты для учетной записи сервера.

Все эти "усилия" нужны ибо разница в скорости действительно существенна.

1. Рассматривается ли при этом признак заблокированности документа кем(чем) - либо в DIRECTUM? Выгруженный документ может иметь неактуальные данные через N-ое время.

Идем на компромисс между "логикой" и производительностью.

Алгоритм заданий такой:

1. документ передан в DCO.
2. никакие обновления при периодических синхронизациях не идут.
3. при выполнении задания, если штампы времени на клиенте и сервер отличаются, документ из клиента передается на сервер и сохраняется как новая версия с соответствующими пометками. Новые вложения загружаются на сервер как новые документы.

По задачам:

1. Вложения уходят на сервер.
2. При периодических сравнениях по штампу времени сверяются документы - и обновляются. Новые документы загружаются в клиента.

Это упрощенно, вообще там есть большая "матрица" событий. Еще же есть прекращение задач, рестарт задач... еще что-то. Так глубоко уже не помню, надо смотреть по документации...

В новых версиях планируем:

1. Документы сравнивать по хешу (ибо надежнее).

2. В интерфейс задания добавить кнопку Обновить - для загрузки актуальных версий (с уведомлением что есть и все такое). Но она будет работать только при активное соединении.

кстати путь для "жесткого обновления" простой - удалить задание и щелкнуть "Синхронизировать"...

Теперь для всех доступна полнофункциональная версия DCO.

Можно скачать тут: Ссылка

Ага, только за деньги -) 

Демка же бесплатно...