Nickorurk,

У шарика ниша несколько другая чем у докуметума и опентекста, так что по фичам здесь тягаться совершенно бессмысленно - остаются только деньги и предпочтения эксплуатанта.

TimyTim,

то ли ваш друг не в теме, то ли вы слишком много чая выпили.

МихаилР,

попробую в кратце....

TimyTimМысль товарища проста, EMC Documentum сильно просел за последние несколько лет и скатиться ещё больше в ближайшем будущем с такой политикой.Это правда, но причины иные.

TimyTimDocumentum - это огромная мощь при практически полной отсутствии гибкости. Так что давите в требованиях про гибкостиь, сроки и кастомизацию.Мощь при отсутствии гибкости - это какой-то оксюморон. В принципе на документуме можно реализовать любые хотелки заказчика, по крайней мере я еще не встречал случаев, когда нельзя что-то сделать, основная проблема больше заключается в том, что заказчик зачастую сам не понимает что он хочет, к примеру, ФЗ в жизни видел только лотус и поэтому хочет чтобы было все как в лотусе, причем бестпрактис и консалтиг категорически игнорирует (вот тут ссылка в тему: http://aiim.typepad.com/aiim_blog/2010/02/8-ways-to-kill-your-ecm-project.html ). Также подобное мнение об отсуствии гибкости может быть вызвано тем, что у большинства интеграторов за долгий срок накопились какие-то собственные наработки (кто-то даже решением называет) под определенного заказчика, зачастую кривые, и они пытаются эти наработки впарить совершенно нецелевой аудитории, и получается, что перелапатить легаси-код под новые требования гораздо сложнее, чем что-то построить с нуля.

TimyTimбольшинство партнёров EMC сейчас столкнулись с очередной проблемой - EMC в очередной раз поменяли пользовательский интерфейс, т.е. меньше чем за 10 лет они меняют его в четвертый раз, самое интересное, что они не совместимы между собой.Сейчас есть такие вебморды:
webtop и производные - несколько старый интерфейс (хотя на одном нашем проекте со стороны пользоввателя выглядит довольно достойно), API существенно не менялось уже наверное лет 8, поддерживает почти все возможности Content Server, в webtop вбухано столько денег и ресурсов, что просто так взять и прикрыть его не получится, в роадмапе евойная жизнь пока обозначена до 2020 года (в прошлом году сейлы бегали как угорелые и рассказывали что webtop собираются прикрыть - обманывали).

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

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

D2 - EMC купили французкую компанию, которая пилила свое решение, сейчас его активно пилят, выгдялит довольно прилично

xCP2 - официально называется последователем xCP, но платформа совершенно другая, выпустили год назад, пока все очень сыро, и если не бросят пилить, то года через 3 может чего достойное и выйдет.

В итоге то что действительно похороили - xCP, но лично мне изначально казалось что он не жилец особо, к нам как-то приходил сейл из EMC и пытался впарить коробку EPFM, проблема в том, что EPFM начали делать через год-два после появления xCP, вот только проблема в том, что сделано оно на webtop, что говорит само за себя о возможностях xCP. Вот это вот:
TimyTimТ.е. все, что партнеры за это время разработали на предыдущих интерфейсах можно смело выкинуть.правильно было бы сказать так: то что наработали партнеры можно выкинуть.

TimyTimБолее того, в последнее время EMC просто начали откровенно наглеть, начали уже брать проекты без привлечения своих партнеров.Я встречал некоторые мелкие проекты, которые изначально делались EMC, но так чтобы EMC делало самостоятельно что-то действительно крупное (пользователей тыщ на 20) еще не встречал. По факту в конкурсах бывает так, что у EMC просят референс на определенного партнера и тут некоторые, естественно, пролетают.

TimyTimКто то из партнёров EMC Documentum считают убытки и покупают новую версию системы, а кто то выбирает другую систему.С версиями у них реально сейчас наблюдается бардак. Время жизни последних релизов что-то в районе двух лет, после EOL поддержка уже услуги не оказывает и заставляет обновляться (за лицензии платить не нужно, потому что они куплены), но в самих версиях особо-то ничего не меняется: идет какой-то багфиксинг, навешивается новый шильдик, если посмотреть на то, что поменялось за последние лет 5, но от силы можно насчитать с десяток крупных изменений, причем их реальная полезность довольно спорная. Я за последние полтора года довольно усердно сношал поддержку в плане ошибок (завел в районе 300 дефектов, именно дефектов, а не обращений в поддержку) в итоге они все критичное нам зафиксили на нашем релизе и куда-то обновляться в принципе смысла вообще не имеет.

TimyTimПоэтому многие российские партнёры EMC смотрят в разные стороны, кто в сторону OpenText, кто в сторону Alfresco, кто в сторону решений от Microsoft, включая упомянутый Sharepoint и решения на его основе. Смотреть партнеры могут много куда, но в действительности шарик и альфреска играют уровнем ниже, тут скорее всего акцент на том, что крупных заказчиков не осталось, а мелким Documentum не нужен.

по поводу недостатков в документуме.

Основной недостаток - для людей с бэкграундом в .Net документум будет неподъемным - у документума весь стек построен на жаве, т.е. непосредственно с контент-севером (работа идет не с базой напрямую, а через отдельный сервис, который умеет некое подобие SQL + примитивный набор операций) может работать только жавская библиотека. EMC конечно за последнее время прикрутила поддержку SOAP, CMIS и REST, но они все работают через жавское API. При этом беспрактис по обеспечению консистентности данных - писать реализацию бизнес-объектов на жаве, в противном случае один и тот же бизнес-код придется таскать по всем системам и его везде поддерживать, такое в природе конечно встречается, но как показывает практика работает довольно чрезжопно. Поэтому если ТС в жаве не зуб ногой (при этом нужно еще знать и контент-сервер, и API и иметь какой-то опыт с документумом вообще), то что-то сделать самостоятельно вряди получится. Для самостоятельного внедрения и поддерки не плохо было бы у себя иметь человека два-три в штате, которые во всей документовской кухне разбираются (причем еще фиг найдешь кого-то вменяемого (думаю с OpenText и P8 ситуация такая же)), причем поддерка EMC кастомные решения поддерживать не будет - они хотят кейсы на некастомном коде.

NickorurkСистема максимум на 5000-6000 юзеров, одновременных до 2000.
Планировали закрыть этот всё за 6-8 месяцев максимум.Для документума здесь нет ничего сложного.

sergeynsNickorurk,
1) озадачьте HR просьбой поискать на рынке спецов по Документуму - много ли найдут? На этом форуме, помнится, разработчика для документума искали несколько раз, по пол-года...Ну по opentext и P8 найти сложнее, насчет альфрески не в курсе, но я точно знаю, что пилить ее куда сложнее чем тот же документум (мы для внутренних целей используем альфреску, причем в наличии есть грамотные разработчики, впечатление такое, что коробочный webtop куда функциональнее и удобнее чем альфреска, кроме этого по отзывам разработчиков складывается впечатление, что альфреска представляет из себя некий фарш из жавы и сервеного жаваскрипта, кроме этого база используется как EAV, так что с отчетами и поиском ой какая беда)

sergeyns2) попросите подрядчика сводить, "показать" уже внедренный Документум.. Если смогут показать довольного заказчика, то
- либо решаемая задача примитивна, и не требовала кастомизации этого монстра
- либо спросите сколько стоило "допилить" документум до вменяемого состояния.. Тут больше вопрос в ожиданиях заказчика, насколько я понял ТС хочет документооборот по ГОСТ + возможность допилить всякого рода интеграции, и ТС изначально позиционирует предложенные варианты (opentext и documentum) как СЭД, но ни opentext ни documentum СЭД не являются - это просто платформы, можно там реализовать ГОСТ? В документуме точно можно, но про наличие готовых релазизаций в том же documentum мне ничего не известно, причем я точно знаю почему - потому заказчикам, которые внедряют "монстров", этот ГОСТ нафиг не впился - им нужно решать другие задачи, т.е. целевая аудитория продукта несколько иная нежели у коробочных СЭД.

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

Partisan MЯ хорошо знаю DocumentumНе особо вяжется с этой мурзилкой: Documentum - есть ли там понятие "транзакция БД" ? :)

NickorurkНам показывали свои коробки корус и терралинк, но это делопроизводство и документооборот в чистой воде не более. Остальное - их услуги.

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

Partisan MВяжется.конечно, Ваше утверждение "я знаю документум" и 10985752 корелируют с коэффициентом -1.

Что-то не увидел в каком месте состояние ЖЦ является согласованым набором атрибутов. Состояния ЖЦ в документуме это всего-лишь способ сделать некоторые изменения в СУБД/контенте/etc при наступлении события "у документа изменилось состояние ЖЦ", ни о какой согласованности при этом говорить нельзя (т.е. если у документа такое состояние ЖЦ, то значит у него значения определенных атрибутов соответствуют этому состоянию) - процедура, переводящая документ в новое состояние отработала - все, с документом могут дальше происходить какие-угодно изменения. До DFC6 жизненные циклы были одной из возможностью сделать кастомизацию для объектов без кастомного TBO, после появления аспектов и эскалации привилегий в DFC6 жизненые циклы - просто лишняя сущность.

Partisan MОни связаны с блокировками (lock) объектов. Есть нескольуо уровней блокировки, на самом строгом она осуществляется и на уровне базы данных. Эти уровни:
- самая слабая - метод fetch () в классе IDfPersistentObject. Не обеспечивает закрепления объекта за одним пользователем (другие могут менять), а только получение последней версии.
- затем выписка (checkout(), checkin(), save(), savelock()) - это блокировка для редактирования одним пользователем, осуществляется Content Server-ом с помощью "неявной транзакции" на уровне хранилища (не базы данных)
- явные транзакции, то есть запрограммированные в приложении. Они помогают добавить проверку согласованности атрибутов перед сохранинием. Осуществляются с помощью beginTransaction () в классе IDfSessionManager (посмотреть также описание "сессий" и при знании Java - документацию JavaDoc по DFC по этим классам). То, что в Документуме называется транзакциями - явные и неявные, осуществляются Content Server-ом, то есть на уровне хранилища.
- блокировка на уровне СУБД (самая строгая), нужна редко, происходит если вызвать метод lock () или lockEx () класса IDfPersistentObject. Это предотвращает неудачу записи изменённого объекта если он во время редактирования изменялся ещё и автоматически Документумом. Итак, для "транзакции БД" нужно вызывать метод lockEх() внутри транзакции, начатой по beginTransaction(). Это бывает нужно редко (мне ни разу не понадобилось), но разработчики должны разбираться в методах блокировки и правильно применять нужные.
Транзакции к блокировкам никакого отношения не имеют, разве что пессимистичную блокировку можно сделать только в транзакции. Жавский вызов fetch() - это вообще не блокировка, а жавский метод, актуализирующий текущее состояние объекта с СУБД. При этом на клиент запоминает текущий i_vstamp объекта (по факту счетчик сохранений) и при вызове save() передает запомненное значение обратно контет-серверу, тот в свою очередь сохраняет изменения в СУБД примерно таким вот запросом:




Если запрос не обновил ни одной строки (т.е. в базе нет совпадений для пары (r_object_id, i_vstamp)), то контент выкидывает клиенту ошибку DM_OBJ_MGR_E_VERSION_MISMATCH. То что описано выше - реализация оптимистичной блокировки, не более и не менее. К транзакициям это имеет ровно только одно отношение: контент-сервер инвалидирует транзакцию в случае возниковения ошибки:



checkout() - метод, предназначенный для закрепления права редактирования документа (свойств и контента) за определенным пользователем, вся магия, которая в нем делается - выставление атрибутов r_lock_owner, r_lock_date и r_lock_machine (последний полезен разве что в случае нескольких серверов, обслуживающих один репозиторий), дальше идет исключительно конвенция - если атрибут r_lock_owner не пустой и не равен имени текущего пользователя, то текущий пользователь не может вносить изменения в объект. Ввиду того, что это просто конвенция, то реализовать какие-либо блокировки на ней нельзя. Справедливости ради нужно сказать, что индусы-разработчики также полагают, что checkout() реализует блокировку, хотя это не так, пример как две сессии успешно "блокируют" объект одновременно:


checkin() - метод, определяющий ветвление версий, save() - сохранение объекта в СУБД со снятием флага r_lock_owner, если таковой взведен, saveLock() - сохранение объекта в СУБД без снятия флага r_lock_owner. Вообщем тут опять не про транзакции.


До DFC6, действительно, транзакцию можно было начать только в менеджере сессий, но при именно при этом вызове транзакция начитается в жавском коде, транзакции, начатые через менеджер сессий реализуют только часть XA - сам лично заводил дефекты, когда в одной сессии изменения сохраняются в СУБД, а во второй - облом. Начиная с DFC6 транзакции можно начинать на уровне сессии, при этом все последующие RPC будут идти в транзакции. Но тут есть один довольно плохой момент - транзакции также вяжутся к жавскому-потоку, поэтому выполять траезакционный код можно только в одном потоке.

lock() - жавский метод, заставляющий контент-сервер выпонять такой запрос:

Т.е. по сути в СУБД на строку накладывается row-level lock, больше никакой магии тут нет. Поскольку row-level lock можно снять только либо закоммитив либо прервав транзакцию, то метод lock() должен выполняться в транзакции (чисто формально такое ограничение накладывает только DFC, а не контент-сервер, поэтому можно извернуться явно транзакцию не начинать, то смысла это не несет). lockEx() от lock() отличается только тем, что позволяет узнать модифицировался ли объект пока вызвов lockEx() пытался заблокировать строку или нет, что само по себе смысла никакого не имеет, потому что типичый паттерн исподьзования lock() выглядит так:




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



Partisan MЕсли отбросить словесный мусор, то правда в этом тексте состояла в том, что кроме Java API существует JavaScript API. Пользоваться им необязательно, но ничего плохого нет в том, что предоставлена такая возможность. Конечно, можете еще рассказать как там полностью отсуствует поиск по значениям атрибутов - можно использовать только полнотекстовый lucene, также расскажите как альфреска начинает замечательно глючить, если вдруг полнотекстовый индекс похерился.

iscrafmЗаказчиков можно понять. Тоже самое можно сделать гораздо разумнее и проще.Главное чтобы заказчик понимал что он действительно хочет, а тут зачастую бывает что ФЗ - делопроизводы, требования пишут IT, а на выходе крокодил. Делать маленькие проекты на документуме смысла нет - они будут задействовать от силы процетов 10 функциональности платформы, а бабки за лицензии будут платиться за то, что успели написать индусы за много лет. Сейчас обещают сделать бесплатный (соответствено неподдерживаемый) порт на postgresql, если сделают на основе прямого билда, то по лицензиям можно довольно сильно упасть будет.

iscrafmа что в том тексте вас смущает кстати? А то вы уже второй раз его приводите, но при этом и слова не сказали что-же в нем неправильногоВ целом - все, под спойлером написано почему.

iscrafmпод спойлером программерские рассуждения на туже тему. Вы наверное не совсем поняли о чем оппонент говорил и тоже самое с кучей кода зачем-то привелиВ каком месте вы считаете, что то же самое?
авторсамая слабая (блокирвка) - метод fetch () в классе IDfPersistentObject бред, пояснил по какой причине.
авторзатем выпискабред, пояснил по какой причине. и т.д.

iscrafmя заметил что там тоже самое, но другими словами, с точки зрения кодера. Если для оппонента блокировка ресурса означает одно, то для вас - другое. Не болееТам топик исключительно про то, что почему пограмисты пишут хрень. Если вы пожете разумно пояснить почему fetch() (чтение актуального состояние объекта из СУБД) внезапно стал блокировкой, то я с Вами, пожалуй, соглашусь

iscrafmделать маленькие проекты на нем смысла нет по другой причине, выше озвучил: тоже самое можно сделать другими средствами проще и разумней. Возможности Documеntum здесь не причем. Как у любого монстрообразного продукта, разрабатываемого разными коллективами и в разные годы - родовая травма: сборная солянка. Поэтому ввязываться можно только если проект огромный, по причине отсутствия проверенных предложенийВы не могли бы развернуть свою мысль более подробно? Вот берем ядро: Content Server + DFC, это 474 вызова RPC в контент-сервере, некоторый набор базовых сущностей (пользователь, группа, папка, документ и пр.) + некий шлак в виде небазовых сущностей, которые впихнул вендор, чтобы можно было продать продукт без кастомизации + стек DFC, реализующий все RPC на клиенте и поддерживающий базовые правила работы с баовыми сущностями. Здесь вроде как солянки нет, за исключением того, что отмечено как "шлак" (который вроде как и не заметен особо), вместо солянки присуствует куча legacy-функционала (например те же жизненные циклы), который убрать нельзя, потому что текущие заказчики дадут п.ды. Дальше BPM: 6 (могу ошибаться) вариантов выбора исполнителей активностей, 2 вида активностей (ручные/автоматические), пара десятков предустановленных шаблонов активностей - в целом ничего лишнего нет, наблюдается скорее отсуствие функционала (ну например встроенных decision rules ой как не хватат). Webtop - здесь да, проблема: в коде нет вообще никакой конвенции, разные компоненты реализованы по-разному (в плане конвенции), что творится в кастомизациях партнеров вообще уму непостижимо. xCP/xCP2/D2 - точно без солянки, но у них родовая травма другого рода - кода как такового нет, потому что предполагается большую часть функционала реализовывать настройками, соответсвенно СКВ не прикручивается, найти почему что-то работает не так как нужно - упаришься. DFS/CMIS/REST - ну это просто сервисы, реализующие некоторую часть DFC, то что сверху - ответственность исполнителя.

iscrafmт.е. вы понятие "блокировка" не воспринимаете дальше, чем его интерпретирует СУБД. То, что, например, пользователь закрепил за собой право распоряжаться каким-то объектом другим способом "блокировкой" уже по вашему не является.Почему же не воспринимаю? Оно для пользователя выглядит так: если никто не выписал, то значка нет, если выписал текущий пользователь, то ключик, если не текущий - замочек. Т.е. в зависимости от того, какое значение атрибута, пользователь видит ту или иную иконку, и лишний раз никуда не лезет, т.е. для бизнес-пользователя оно работает ожидаемо, но
авторэто блокировка для редактирования одним пользователем, осуществляется Content Server-ом с помощью "неявной транзакции" на уровне хранилища (не базы данных) бред.

iscrafmт.е. разница только в том, что ваш оппонент назвал гарантированное чтение объекта с обеспечение его логической целостности на данный момент времени "блокировкой", в терминах. По большому счету это можно назвать кратковременной блокировкой на момент чтения, гарантированно получить целостный объектВообще совершенно разные понятия. Вы приходите в магазин смотрите сколько стоит арбуз и сколько примерно есть - это fetch, никакой блокировкой тут не пахнет, дальше подходите к продавцу и просите принести 10 арбузов (вы прикинули что десяток точно наберется), продавец ушел за арбузом - Вы пессимистичо заблокировали продавца (его никто больше использовать не может), пока продавец ходил арбузы разобали и осталось 9, он приходит и говорит: "Осталось 9" - это оптимистичная блокировка, Вы в праве решить брать 9 или уйти, что там Вы видели в начале своей бизнес-транзакции никого не волнует - нужно было резервировать нужное количество в самом начале (пессимистичная блокировка)

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

iscrafmхорошо. давайте на бытовых примерах.
...У Вас пример несколько натянут для того, чтобы попытаться приплести RC к блокировке, ну нет там блокировки и все. Кроме этого гаратий тоже нет никаких: пока продавец выходил в подсобку халат украли, клиент данные вроде как получил, которые были консистентны мгновение назад, но смысла в них нет никакого. В документуме работает по-умолчанию оптимистичная блокировка, но реализуется она двумя вызовами: fetch() (который с клову сказать бывает неявным и бывает холостым) и save().

iscrafm,

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

Garya,

Я хотел бы обратить Ваше внимание на то, что обсуждается вполне определеный продукт, работающий со вполне определенными СУБД с вполне определенными (вендором) настройками. Для ORACLE UR вообще нет, для MSSQL рекомедуется READ_COMMITTED_SNAPSHOT=ON, поэтому все гипотетические предположения о том, что продукт (т.е. documentum) при реализации определенных RPC накладывает блокировки в СУБД, остаются гипотетическими. Можно скольку угодно пытаться найти хоть какую-то истину в изначально неверном утверждении, но ни к чему толковому это не приведет.

Garya,

Ничего особеного не происходит, у каждой своя собственная копия объекта, эти копии между сессиями никак не синхронизируются, копия представляет из себя некоторое состояние объекта полученное из СУБД + изменения произведенные клиентским кодом, эти локальные изменения можно "откатить" до актуального состояния объекта, также можно сравнить текущий объект с актуальным состоянием. GaryaЧто значит "нет блокировок"?на двух самых популярных поддерживаемыз СУБД (насчет DB2 не знаю ничего) читатели не блокируют писателей, и наоборот. Факт того, что сохранение объекта происходит в актуальную версию устанавливается только при сохранении объекта в СУБД - при апдейте выясняется актуальность пары (id_объекта, счетчик_сохранений), сохранение объекта в одной сессии не инвалидируют копии этого объекта в других сессиях, т.е. шаблон сохранения изменений такой:

1. получить актуальную копию (fetch из JVM)
2. внести изменения (меняется копия объекта в JVM)
3. попытаться сохранить (сохраение измеений в СУБД)
4. если сохранить не удалось из-за неактуального состояния, то 1

iscrafmтогда не актуальную версию, а snapshot на момент чтенияКак Вам будет угодно, главное не называть блокировкой. Хотя технически нельзя сказать, что fetch - получение снапшота объекта из базы: после того как сессия один раз читает объект он сохраняется в ее кеше, в следствие чего последующие вызовы fetch() в большинстве случаев получаются холостыми: он сначала проверяет, насколько пара (id_объекта, счетчик_сохранений) актуальна и только в случае неактуальности делает чтение из базы (тут может возникнуть ситуация, когда кто-то сделал изменения в СУБД при помощи SQL и эти изменения в JVM не засосутся), получается, что если объект модифицировался в JVM, то fetch либо ничего не делает с объектом, либо затирает все изменения в зависимости от текущего значения счетчика сохранений. В действительности для уже существующего в JVM синхронизация с СУБД выполняется только при вызовах revert() и save().

iscrafm,

вроде уже писал: 15437081