Pull to refresh

Python/JS-фреймворк для миграции с Lotus Notes

Краткая история появления нового фреймворка


С 1998 года мы разрабатывали СЭД на Lotus Notes для крупных и мелких гос. структур.
В 2012 решили делать коробочную версию системы на базе Open Source и выводить ее на рынок СЭД.
За два года мы переписали нашу систему в виде сервера на Python и клиента на HTML/CSS/JavaScript. В процессе этой работы появился дополнительный интересный продукт — фреймворк, годный для миграции систем с LN.

image


Мы планируем доработать его и выложить в Open Source.

Нужен ли такой продукт ИТ-сообществу?


Предлагаем обсудить этот вопрос. Подробности относительно СЭД и фреймворка мы решили оформить в виде вопросов, которые коллеги задавали нам по поводу нашей работы, и ответов на них.

Вопросы и ответы


Кто вы и как появилась ваша СЭД?
Мы — коллектив разработчиков, создавший первую версию нашей системы в 98 году на Lotus 4.5. Изначально СЭД создавалась для КУГИ СПб, затем — для Росимущества, Правительства Тверской области и прочих организаций. Развитие платформы и требования крупных заказчиков способствовали развитию системы, за время разработки на LN мы трижды делали глубокий рефакторинг с ревизией структуры баз, всех скриптов и интерфейса. В результате всех этих процессов получилось надежное промышленное решение, а его единственным крупным недостатком постепенно стала платформа Lotus.

Почему решили избавиться от Lotus'а?
Потому что он закрытый, дорогой, ограниченный и громоздкий. LotusScript и @-формулы — закрытые и неудобные инструменты, интерфейс LN у многих пользователей вызывает отторжение, и его нельзя переписать — он будет лотусовым. LN требует установки и настройки на каждой машине, Domino-серверы нужно администрировать — нужны весьма дорогие Lotus-администраторы. После периода развития в 90-х Lotus отстал от современных платформ, затем долго-долго отмирал и вот уже почти исчез, едва ли сейчас кто-то выбирает его для новых разработок. Но на нем уже написано немало, и со всем этим нужно что-то делать.

Как выбирали инструменты для разработки?
После некоторых раздумий и исследования современного состояния индустрии мы сформулировали требования к новой СЭД:
  • на свободном ПО — чтобы не зависеть от проприетарщины как раньше;
  • на современном скриптовом ЯП — чтобы переписать всё быстро;
  • в виде веб-сервера и тонкого клиента — чтобы были разные варианты установки СЭД и можно было работать как раньше в интранете или создать онлайн-сервис;
  • сохранить структуру данных и приложений похожими на Lotus — чтобы именно конвертировать СЭД, а не переписывать совсем с нуля.
И решили сделать так: сервер на питоне, данные в реляционной БД, тонкий клиент.

Что получилось?
За 2 года СЭД полностью переписана на Python/JavaScript/HTML/CSS, функционал ее сохранился и получил развитие, интерфейс приобрел все лучшее из мира Lotus и веб-приложений.

Данные хранятся в реляционной БД, но их структура соответствует лотусовой: есть множество БД с документами — и это единственный и универсальный метод хранения данных и элементов дизайна. Каждый документ содержит произвольный набор полей, вложений (файлов) и базовые свойства — UNID, даты создания/модификации, автор и т.д. Для работы с БД и документами создан набор инструментов, похожий на встроенные классы LotusScript. Представления, формы, агенты — все это тоже имеется и похоже на Lotus. Реализована авторизация пользователей, разделение прав доступа на уровне БД, хранение в документе истории изменений для каждого поля и пользователя, профайлы БД (служебные документы), репликация (со слиянием конфликтных документов на уровне отдельных полей), механизм представлений, статически хранимых в БД.

В общем, получился фреймворк, на который была переведена СЭД, и на котором теперь происходит ее дальнейшая разработка. Фреймворк решили назвать RSF (Result-Systems Framework).

А можно посмотреть?
Да. Вот здесь мы развернули демо-версию СЭД на VDS.
А вот так выглядит база с описаниями элементов дизайна:



RSF предназначен только для миграции систем с Lotus?
Это универсальный документо-ориентированный фреймворк, позволяющий создавать системы коллективного пользования для работы с документами. А в виде документов можно представить практически все — например, любые справочники, сообщения, файлы, страницы сайтов, активность в соц сетях и т.д. Таким образом, миграция систем с Lotus'а и разработка СЭД — это далеко не единственные применения RSF.

Как происходит миграция системы из Lotus'а?
В общем случае нужно:
  • создать в RSF базы, аналогичные лотусовым;
  • перерисовать все формы и подформы в HTML;
  • создать описания представлений и правил для отображения документов;
  • переписать на питоне логику (все, что было написано на @-формулах и Lotus-скрипте);
  • конвертировать документы.

Приложение будет иметь ту же структуру, что и лотусовое — там будут те же базы, в них — те же документы, что были в Lotus'е. Даже UNID’ы документов сохранятся.

После миграции пользователь получит привычную для себя среду с тем же функционалом, только не в клиенте LN, а в браузере?
В целом да, но это не самоцель. HTML, JS, CSS обеспечивают больше возможностей при проектировании экранных форм, чем клиент LN, соответственно формы можно сделать более наглядными и удобными. Что касается обработки данных на сервере, то в отличие от убогого LotusScript разработчику доступна вся мощь питоновских библиотек, что позволяет существенно расширить функционал приложения.

Создано и внедрено немало систем на LN. Как вы оцените сложность их перевода на RSF?
Это зависит от архитектуры системы. Имея опыт конвертации данных из некоторых СЭД, можем предположить, что «CompanyMedia» можно перенести относительно легко, т.к. продукт разработан в соответствии с философией LN. «БОСС-Референт», наверное, сложнее — в нем поручения вынесены в отдельную сущность, как это принято в реляционной БД, много формул и скриптов. Есть приложения LN, которые лучше переписать заново, чем пытаться портировать.

Возможна ли совместная работа Lotus'а и RSF?
Да, можно не переводить всю большую лотусовую систему сразу целиком в RSF, а начать с некоторой ее части. Например, в Правительстве Тверской области мы перевели несколько подсистем в RSF. Документы постоянно конвертируются в обе стороны, часть людей работает с RSF.

А не проще было взять в качестве БД что-то готовое, например, MongoDB?
На данный момент нет ни одной СЭД на Mongo. Судя по критике Mongo, у разработчиков возникают проблемы при интеграции с другими системами и при развитии приложений, коллекциям Mongo далеко до представлений LN. Мы сделали более простое и надежное хранилище на SQL-сервере, где в качестве представлений используются индексированные таблицы, а любой документ может входить в любое число представлений. Сами документы хранятся в виде мета-схемы, где единицей хранения является не документ, а поле документа.

Мета-схема с хранением отдельных полей? Это должно страшно тормозить!
Наши представления работают быстро, так как они хранятся в готовом виде (правила отображения документов работают в момент сохранения документа, а не при отгрузке данных представления). Чтение документа — тоже быстрая операция, один простой запрос по одной таблице. Самая дорогая операция — это запись документа, при этом нужно обновить все представления, в которые он входит. Но это и самая редкая операция. Если же нужна интенсивная запись документов (например, при конвертации данных), то есть возможность отложить обновление представлений на потом.

Как у вас реализованы права доступа?
Пока разделение прав доступа реализовано только на уровне БД. Планируем сделать это на уровне документа и отдельных секций документа. У нас есть специализированная база — адресная книга. В ней хранятся описания пользователей, групп, SQL серверов и пр. Для каждой базы создается Access Control Rule, в котором описаны права (роли) пользователей и групп. Это описание может храниться в самой БД или в адресной книге в виде шаблона, который относится сразу ко многим базам определенного типа. Когда количество баз измеряется тысячами, это упрощает администрирование. Для входа в систему по http/https применяется встроенная digest-аутентификация браузера (RFC 2617).

LN – это, в том числе, почтовая система. Что у вас?
Мы не пытаемся сделать свой LN, и у нас нет своего почтового сервера. Наша задача перевести существующие приложения на новую платформу. Стоит отметить важный момент: существующие приложения используют почту либо для отправки уведомлений, либо для отправки документов тем, кто не пользуется LN. У нас за отправку почты по SMTP отвечают агенты, использующие стандартные библиотеки Python: smtplib, email и др. Есть отправка SMS уведомлений (библиотека smpplib).br>

Расскажите об обработке событий.
Для каждой формы на сервере выполняются свои скрипты для событий «beforeOpen», «beforeSave», «afterSave». На клиенте для каждой формы вызывается JS «postOpenDoc» для инициализации и «setAndVerify» для пересчета полей и проверки значений перед сохранением документа.

В LN есть удобные, часто используемые функции @DbLookup и @DbColumn. У вас есть аналоги?
Прямых аналогов нет, но есть два механизма, тоже удобных:
  1. Механизм работы со справочниками на основе вложенных словарей Python. При старте сервера все справочники загружаются в словари из соответствующих баз, затем автоматически перегружаются при изменениях в этих базах. На сервере данные из справочников доступны непосредственно, на клиенте — добавляются в HTML при его формировании или динамически подгружаются через XHR. Память при этом расходуется, конечно, но, справочников не так много. Для СЭД уровня субъекта РФ (2000 баз, 3000 исполнителей) они отъедают на сервере меньше 30 Мб.
  2. Для диалогов есть аналог @PickList – он работает с представлением, т.е. с SQL таблицей, и, отработав, память освобождает.


Поддерживается ли многозначность полей как в LN?
Да, в поле можно записать много значений, для этого сделаны удобные контролы. Если в базе есть представление, отсортированное / категоризованное по этому полю, то документ может отображаться в нем многократно / входить в несколько категорий (это поведение настраивается).

Что было самым трудным при создании фреймворка?
Переписать лотусовые представления. Это одно из главных интерфейсных достижений Lotus'а, видимо, Lotus Development и IBM потратили немало усилий на их разработку и доводку. Им нет равных по удобству для пользователя: все документы (хоть миллион) отображаются в виде единого динамического списка, в котором мгновенно ищется нужная позиция с помощью быстрого поиска. Представление можно листать в любую сторону, выделять в нем сколько угодно документов, складывать/разворачивать подчиненные. И все это очень быстро работает даже на слабом железе. Такое не сравнить с куцыми постраничными списками веб-интерфейсов (или прожорливыми автодополняемыми). А обычный подход РБД-систем с нормализованной базой, когда нужно задавать какие-то критерии, чтобы увидеть документы — выглядит форменным издевательством над пользователем.

Каковы перспективы?
На данный момент RSF не является отдельным продуктом, он тесно связан с самой СЭД, для его отделения необходимо провести некоторую работу. Если получим отклик от сообщества разработчиков, будем активно развивать фреймворк. У нас масса идей по поводу новых возможностей. Планируем интернационализацию, подключение шаблонизаторов для форм, взаимодействие с веб-сервером по WSGI, возможно, свой браузер для тех, кто хочет толстого клиента с дополнительными фичами не на JavaScript. Также думаем о создании готовых решений на базе RSF (например, уже сделали небольшую CRM).

Вопросы сообществу:


Хотите ли вы использовать такой фреймворк для переноса приложений из Lotus'а?
А для создания новых систем для работы с документами?
Хотите принять участие в развитии фреймворка?
В какую сторону он должен развиваться?

Спасибо за внимание, будем рады вашим вопросам и предложениям.
Tags:
Hubs:
You can’t comment this publication because its author is not yet a full member of the community. You will be able to contact the author only after he or she has been invited by someone in the community. Until then, author’s username will be hidden by an alias.