Миграция с Lotus'а (делимся опытом)

[savl]

отказались от платформы или только от студии? Смысл платформы , в контексте ДО - ТЕЗИС

и от платформы и от студии.
Сам ТЕЗИС не смотрели, так как не полноценный ДО делали, а свой "дом удовольствий с барышнями и преферансом".

 

[Иван Пахомов]

я с этими системами детально не знакомился по причине именно

Ссылка скрыта от гостей

, его интерфейс, мягко-говоря не гибок (при всей моей любви у уважении к платформе)

а вот на этой странице уже вполне приятный веб:

Ссылка скрыта от гостей

не говоря о том, что в Логики бизнеса с начала нулевых ставка на веб-интерфейс, а с 2014 года есть ещё и резиновый и конфигурируемый XPages интерфейс для своей СЭД. да его и на другие СЭД при желании можно натянуть. по крайней мере на старый БР его натягивали. жаль, что не смотрели продукты с такими большими инвестициями, где многое уже оформлено в виде компонент

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

можно мавеном собирать проекты, если хочется и оправдано практикой:

Ссылка скрыта от гостей

- BPMN (хотябы) или интерактивное рисование схем процесса - как там с этим?

в Логике СЭД точно нет, да и не нужно вроде, там иной подход к автоматизации БД. есть конечно Lotus Workflow Architect. да-да, не ржите свои задачи решает. но это не юзер-тул, конечно
за Эскадо не скажу, тоже только начинаю с ними знакомиться
а вот в ClevaDesk (которая раньше xpage dynamics была). там заявлена такая возможность:

Ссылка скрыта от гостей

выглядит очень симпатично, по-моему

- веб-интерфейс (если он есть) - отдельно от нотус интерфейса (как оно и бывает для классики)

как золотой партнёр по Логике СЭД могу сказать, что в этой СЭД интерфейс сделан на "компонентах", т.е. подформах под каждый атрибут, который отображается одинаково в нотесе и вебе. что сильно упрощает и разработку, отладку и развитие решения. как сделано в Эскадо и CompanyMedia, не скажу, свечку не держал. может, коллеги, кто работает с этими продуктами пояснит. ClevaDesk - изначально веб-ориентированная платформа

- интеграция с офисом - через обрыдлый и убогий КОМ?

в вебе по WebDAV подключается редактирование вложений. профит. если автозаполнение полей, то серверные активности, вестимо

- распознавание и превью аттачей - опять загадка (МСО свистоперделки и КОМ)

тут for whom how
где-то HTML5, где-то плагин, где-то чисто серверные активности без валидации. превью - конвертация на лету, куча свободных и несвободных компонент под это. мне кажется, все это давно умеют

- еще куча всякого по отображению и модификации docx/odt и вовсе офисных форматов

согласен, это есть. но а где его нет, приведите пример? если формат (DOCX) заявлен как открытый, а по факту не всегда, то да, будут косяки при отображении

Др. словами как только "система" упирается в ограничения нотусни - начинается активное педалирование через виндовые причемосы, что не кроссплатформенно (это автоматом дает разделение на разные интерфайсы для разных устройств) и чревато многочисленными граблями

я пока только про кривизну отображения в веб офисных форматов услышал. это не проблема Domino, ясен перец. та же ClevaDesk прекрасно себя чувствует на Linux. у Вас либо какие-то специфические кейс и реализации или я не понимаю. мне было бы лаже интересно узнать, что у Вас за кейсы, можно в личку, можно тут. может, доклад на митапе (Meetup пользователей Domino/Notes) сделаем с разбором?

CUBA - это java и tomcat, с известными библиотеками, интеграцией со популярными ИДЕ, мне это понравилось
C офисными документами в ТЗИС, на момент тестирования, были особенности (для редактирования нужен отдельный плагин и у меня он не всегда давал желаемый результат), но сказали что думают над сервервисом редактирования и отображения офисных документов (без установки "офисов"). Но там уже был просмотр. (прям в браузере) и сравнение доков, в т.ч. со сканом (как мне сказали - на движке от ABBY)

не поверите, в Логике СЭД это тоже уже несколько лет как есть и просмотр документов в вебе. и сравнение версий со сканом на базе ScanDifFinder (

Ссылка скрыта от гостей

). ну а использовать Java и сторонний веб-сервер на Domino вообще никто не запрещает. как пример:

Ссылка скрыта от гостей

 

[lmike]

@Иван Пахомов извините, лень по пунктам цитировать, да длинно получится
я изначально упомянул продукты на базе XPD коим и является CleverDesk как пример - чего ожидаешь, но я не знаю сетпень её допиленности, в демке воркфло показался бедноватым (или я чего не усмотрел).
Логика СЭД

Ссылка скрыта от гостей

500 ошибка
ТЕЗИС мне ставили в виртуалку, я его крутил - положительное впечатление по кастомизации и администрированию.
Стороннее ставить над доминой, разумеется, возможно и даже (на мой взгляд) нужно, к этому и идет развитие в виде ноды. Тем и ценна домина - широкими возможностями интеграции. А вот ср-ва разработки очень подкачали, дизигнер оставляет гнетущее ощущение и прибит гвоздями к винде, а без него сборка невозможна (я не знаю)
для Логика СЭД есть свои ср-ва разработки?

 

[VladSh]

есть конечно Lotus Workflow Architect. да-да, не ржите свои задачи решает

Это где при отправке на параллельное согласование ста человекам создаётся 100 копий документа? Нет, спасибо!)))

 

[Иван Пахомов]

Это где при отправке на параллельное согласование ста человекам создаётся 100 копий документа? Нет, спасибо!)))

100 согласующих? у вас там бюджет страны что ли в госдуму вносится? интересно, в каких случаях бывает нужно 100 согласований получить. поделитесь?

 

[launcher]

Я разработчик Логика СЭД, прокомментирую.

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

Размазанный код это скорее культура разработки, соберите весь код в классы, функции в библиотеках, поставьте в местах вызова просто вызовы и больше не ходите в формы для написания кода.

- веб-интерфейс (если он есть) - отдельно от нотус интерфейса (как оно и бывает для классики)

Сейчас Логика СЭД имеет интерфейс построенный на компонентах, компонент профилируется параметрами и размещается на форме. он одинаково работает на клиенте и в вебе, ну и xPages интерфейс тоже.

- интеграция с офисом - через обрыдлый и убогий КОМ?

Логика СЭД полностью кросс-платформенный продукт и не позволяет себе такие вещи как COM, все интеграции со сторонними сервисами сделаны через web-сервисы.
Есть интеграция с Office 365 через сервисы из коробки.

- распознавание и превью аттачей - опять загадка (МСО свистоперделки и КОМ)

Распознавание, и сравнение оригинала с копией сделано на базе Abbyy Recognition Server и ScanDiffFinder SDK через сервисы, превью в вебе сделан через рендеринг в html5 на серверном компоненте.

-Это где при отправке на параллельное согласование ста человекам создаётся 100 копий документа? Нет, спасибо!)))

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

-Логика СЭД

Ссылка скрыта от гостей

ошибка

Сейчас идут работы по наращиванию функционала на демозоне после выхода версии 3.7.1, в частности добавление функционала WebDAV при работу с файлами в вебе, поэтому ресурс пока доступен только по https

Ссылка скрыта от гостей

 

[VladSh]

100 согласующих? у вас там бюджет страны что ли в госдуму вносится? интересно, в каких случаях бывает нужно 100 согласований получить. поделитесь?

Это к слову. Движок один и тот же используется и для согласований, и для исполнений, и для ознакомлений. Согласований сейчас слёту нашёл 15. Но бывает до 30-ти. Ознакомлений бывают тысячи.
В любом случае - решение идиотское. Как оно могло родиться в недрах IBM - загадка.

 

[VladSh]

-Это где при отправке на параллельное согласование ста человекам создаётся 100 копий документа? Нет, спасибо!)))
В парадигме продукта и платформы, это наиболее уместно, каждый рецензент работает с изолированной копией только непосредственно в стадии рецензирования, при выходе их рецензирования персональная копия сливается с основным документом и удаляется. Множественные копии процесса не видят пользователи, для них документ один как был так и остался. Если коротко это темповые документы. Если еще резон делать именно так - это поддержка распределенной работы. Логика СЭД позволяется полнофункционально работать в распределенной инсталляции в том числе в цикле рецензирования.

У нас было аналогичное решение, как только начали писать свою СЭД в 99-м. Устарело оно в уже 2001-м. В 2002-м заменили на запросную систему - распределённая работа поддерживается в полном объёме. На данный момент решений, построенных на запросной системе, уже далеко не одно.
Некоторые из наших причин, почему мы ушли от такого решения - куча ненужных документов, влияющих на скорость БД, влияющих на db.Search, репликацию (Authors/Readers-поля для персональных копий) и т.д., ненужные алгоритмы слияния и усложнения с этим связанные, анализ множества документов при разборе тех.специалистами, вместо анализа одного и т.д., и т.п.
По сути "персональная копия" нужна для временного сохранения где-то каких-то данных (если документ не смог быть заблокирован, и данные не добавились напрямую), чтобы потом перенести их в основной документ. Никакого смысла делать это в основной БД нет. Причём, при запросной системе схлопывание всех изменений, накопленных с предыдущей отработки, может происходить за одно сохранение основного документа (в одну "транзакцию"), что сильно уменьшает фрагментированность БД, соответственно повышая её скорость.

Есть и другие решения, где к документу при отправке единожды раздаются доступы, а отметки хранятся в отдельной БД, и схлопывание инфы по документу происходит единожды, в момент архивирования. Это решение похуже (нужно дополнительно вычитывать отметки), но позволяет делать отметки по документу тысячами, т.е. подходит для крупных компаний.

 

[launcher]

"Запросная" реализация возможна когда между площадками есть постоянная онлайн связь, но при наличии такой связи скорее всего уместна вообще централизованная инсталляция. В нашем случае площадки вовсе необязательно должны иметь онлайн между собой. Если онлайн не обеспечивается, то на удаленной площадке все равно надо хранить какие-то данные документа, чтобы пользователь (часто в абс. другом часовом поясе) мог отреагировать на запрос выполнения действия. Работа происходит ассинхронно на домашней площадке пользователя при отсутствии онлайна до "домашней" площадки документа. Так решается проблема в общем виде, без предъявления каких-либо требований к каналам.

 

[Иван Пахомов]

Это к слову. Движок один и тот же используется и для согласований, и для исполнений, и для ознакомлений. Согласований сейчас слёту нашёл 15. Но бывает до 30-ти. Ознакомлений бывают тысячи.

в Логика СЭД ЛВФ используется только для согласований. для исполнений, рассылки и ознакомлений - отдельные небольшие служебные сущности. и да, ознакомлений бывают тысячи. согласен, при правильной архитектуре приложения, ничего не ломается

В любом случае - решение идиотское. Как оно могло родиться в недрах IBM - загадка.

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

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

 

[VladSh]

"Запросная" реализация возможна когда между площадками есть постоянная онлайн связь

Это какая-то не такая "запросная" реализация.
Для такой постоянной связи ненужно.

 

[VladSh]

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

Из опыта. И нами продавалось в том числе. Потом переделали и вздохнули свободно. Потом уже сам делал СЭД для одной конторы - всё работает отлично. А сейчас вынужден поддерживать решение на модели с "персональными копиями" - опять едим кактус... Никто переделывать ничего глобально не будет, т.к. огромное количество баз + скорее всего Лотус будет всё-таки выводиться из эксплуатации.
Кто-то скорее всего просто остановился на решении, которое лежало на поверхности, а на другие не стал тратить время) Потому что это полный пересмотр архитектуры, а это никто не любит. Я в первой конторе додавил шефа на это. У нас был полный пересмотр и переделка каждые 2 года: полтора года эксплуатируем, ищем недостатки и узкие места, ищем решения..., а пол года - полная переделка с написанием конвертера, чтобы прийти к заказчикам, и после установки новой версии нажать кнопку, которая позволила бы поменять старый формат данных на новый. Вот так.
Всем в любом случае стоит поаплодировать - наверное нет ни одной системы, кроме Лотуса, после которой мозг смог бы научиться так изворачиваться

кстати, насчёт обменяться опытом

В конце 2008-го в Киеве в Аплане была конфа для разрабов, где я делал подробный доклад по архитектурам бесконфликтной работы в СЭД на Lotus и "запросной" системе. Сейчас не потяну уже. Всё надо делать вовремя)
Тут делюсь вот, - не жалко. Когда бывает на это время.

 

[savl]

@VladSh а записи доклада нет? Я бы глянул.

 

[VladSh]

Тогда ещё не было привычки снимать)

 

[lmike]

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

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

нынче пых не модно (TS/JS), а для совместимости яб взял couchDB, ведь полюбасу нужен бэк

 

[VladSh]

А я бы MongoDb. Из преимуществ:
- обалденная настройка индексов (аналог вьюх);
- возможность блокировки документа;
- полноценная транзакционность (в транзакции может быть неограниченное количество документов);
- возможность изменения/получения части документов;
- возможность шифрования отдельных полей.

 

[alexas1]

А я бы MongoDb. Из преимуществ:
- обалденная настройка индексов (аналог вьюх);
- возможность блокировки документа;
- полноценная транзакционность (в транзакции может быть неограниченное количество документов);
- возможность изменения/получения части документов;
- возможность шифрования отдельных полей.

смотря для чего) минусов и неудобства - выше крыши
коуч мне оказался куда ближе
хотя, нотусу нет равных, несмотря на застой и не полную открытость, граничащий с идиотизмом
а ващще, фломастеры это всё)

 

[VladSh]

смотря для чего) минусов и неудобства - выше крыши
коуч мне оказался куда ближе

Я рассматриваю для целей построения СЭД.
Раскрой тему подробнее) А я потом перенесу в отдельную тему.

 

[lmike]

А я бы MongoDb. Из преимуществ:
- обалденная настройка индексов (аналог вьюх);

у коуча - это родное, а еше есть

Ссылка скрыта от гостей

- возможность блокировки документа;

решается на апликейшн левел, в базе - это зло

- полноценная транзакционность (в транзакции может быть неограниченное количество документов);

она есть, но "как говорят" есть у неё и особенности, у коуча есть

Ссылка скрыта от гостей

, но я поддерживаю подход

In many use cases, it should be possible to combine data into a single document to take advantage of these ACID properties.

вот прям пример распределенной транзакции на кластере

Ссылка скрыта от гостей

- возможность изменения/получения части документов;

для любого REST(коими явл. интерфейс коуч) это типичноа фича или я не понял фразу

- возможность шифрования отдельных полей.

сомнительное преимущество, решается на уровне апсервера

 

[VladSh]

> возможность блокировки документа
решается на апликейшн левел, в базе - это зло

Со всем выше согласен, но не с этим. Зачем что-то воротить, если это можно сделать на уровне базы? Тем более, что логика может сказать "ДА", а база по какой-то причине "НЕТ".
Если база даёт согласие/отлуп по блокировке, тогда включается логика на APP-уровне.