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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

не поверите, в Логике СЭД это тоже уже несколько лет как есть и просмотр документов в вебе. и сравнение версий со сканом на базе ScanDifFinder (ABBYY ScanDifFinder SDK). ну а использовать Java и сторонний веб-сервер на Domino вообще никто не запрещает. как пример: Apache as a reverse proxy for IBM Domino iNotes with home server redirection

 

@Иван Пахомов извините, лень по пунктам цитировать, да длинно получится
я изначально упомянул продукты на базе XPD коим и является CleverDesk как пример - чего ожидаешь, но я не знаю сетпень её допиленности, в демке воркфло показался бедноватым (или я чего не усмотрел).
Логика СЭД http://demo-zone.boss-referent.ru/Referent331/br_switch.nsf 500 ошибка
ТЕЗИС мне ставили в виртуалку, я его крутил - положительное впечатление по кастомизации и администрированию.
Стороннее ставить над доминой, разумеется, возможно и даже (на мой взгляд) нужно, к этому и идет развитие в виде ноды. Тем и ценна домина - широкими возможностями интеграции. А вот ср-ва разработки очень подкачали, дизигнер оставляет гнетущее ощущение и прибит гвоздями к винде, а без него сборка невозможна (я не знаю)
для Логика СЭД есть свои ср-ва разработки?

 

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

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

 

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

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

 

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

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

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

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

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

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

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

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

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

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

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

-Логика СЭД http://demo-zone.boss-referent.ru/Referent331/br_switch.nsf ошибка

Сейчас идут работы по наращиванию функционала на демозоне после выхода версии 3.7.1, в частности добавление функционала WebDAV при работу с файлами в вебе, поэтому ресурс пока доступен только по https https://demo-zone.boss-referent.ru/

 

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

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

 

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

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

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

 

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

 

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

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

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

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

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

 

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

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

 

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

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

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

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

 

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

 

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

 

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

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

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

 

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

 

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

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

 

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

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

 

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

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

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

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

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

она есть, но "как говорят" есть у неё и особенности, у коуча есть такое , но я поддерживаю подход

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

вот прям пример распределенной транзакции на кластере Distributed Transactions from the Java SDK | Couchbase Docs

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

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

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

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

 

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

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