Распределенка+СЭД+репликация

  • Автор темы Akupaka
  • Дата начала
A

Akupaka

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

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

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

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

ToxaRat

Чёрный маг
Green Team
06.11.2007
3 332
42
BIT
0
Akupaka
я так понимаю нужно заблокировать док пока работает один из них?
самый быстрый способ на обоих репликах установить один административный сервер и влючить лоченье документов, тогда пока работает первый - второй отдыхает
 
T

TIA

Блокировка - лучший вариант, когда допустимо ожидание пользователем возможности выполнить операцию. Без ожидания, можно предложить такие варианты:
1. По какому-либо признаку определять, что замещаемый работает в системе и тогда не давать замещающему создавать решение. Таким признаком может быть sametime-статус, запись в log.nsf или можт ещё есть какой системный признак.
2.Если заранее известно, кто должен выносить решения, то зарезервировать UNID для каждого решения. При создании документа с решением, присваивать ему зарезервированный UNID. Т.о. при создании решения замещаемым на С1 и замещающим на С2, оба документа будут иметь один UNID и после репликации один из них станет конфликтным. Минус в том, что дата создания документа св-вах будет отображаться не та, когда он создан, а когда зарезервирован.
 
A

Akupaka

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

1) sametime-сервера нету, и на него не могу полагаться в виду вышесказанного.
запись в логе и т.п. - та же беда, зависит от периода репликации.

2) не знаю как резервируется unid... просто создать док и запомнить его унид без сохранения?..
не хотелось бы использовать стандартные конфликты в своих механизмах, т.к. они обычно пугают как пользователей, так и админов, да и разрабу очи муляють ;)


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

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

блин, мне начинает казаться, что репликация и ДО не совместимы... вернее, репликация и ДО, и наши пользователи не совместимы... ))
 
T

TIA

как будет срабатывать блокировка, если репликация, к примеру, раз в час?
Можно свой механизм блокировок создать. Например, на почтовых сообщениях для оперативности. Или каком-нибудь стороннем сервисе доставки сообщений.

2) не знаю как резервируется unid... просто создать док и запомнить его унид без сохранения?..
не хотелось бы использовать стандартные конфликты в своих механизмах, т.к. они обычно пугают как пользователей, так и админов, да и разрабу очи муляють smile.gif
Да, именно такое резервирование и имел в виду. Для твоего предложения разруливания спорных решений по принципу "победил замещаемый" такой подход тоже приемлем. Т.е. решение замещаемого делать не конфликтным. Если не разруливать, то удалять конфликты агентом. Конфликты можно не отображать во вьюхах, чтоб не пугать.

я тут подумал, а как вам вариант такой:
- для каждого из исполнивших действие создается свой док-решение, а при обработке документа перед следующей стадией, при наличии нескольких спорных решений, можно было бы создавать дополнительную стадию, которую должен был бы разрулить основной исполнитель предыдущей стадии...
А если основной исполнитель как раз в этот момент и отсутствует, то кто разрулит, замещающий? ;)
Сначала с бизнес-логикой бы определиться. Равноправны ли решения замещающего и замещаемого.
 
A

Akupaka

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

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

ладно, пока что спасибо за советы, если что - тема открыта ;)
 
T

TIA

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

Тогда для создания решения принудить делать заявку на создание. И только после её удовлетворения, сопровождающемся блокировкой, разрешать создавать решение. На один сенс репликации больше и сценарий использования усложняется.
 
A

Akupaka

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

TIA

Правильно понял. Вариант с блокировкой и приводит к затягиванию и пригоден если затягивание допустимо. А разрешения пусть спрашивает система.
 

ToxaRat

Чёрный маг
Green Team
06.11.2007
3 332
42
BIT
0
как будет срабатывать блокировка, если репликация, к примеру, раз в час?
возможно, я был не прав, что не уточнил, что это не сервера в одном офисе, и репликация между ними проходит не каждые 5-10 мин.
предполагается общий случай, что период репликации не известен заранее, и реплики могут быть локальными, а пользователи выходят в сеть только для репликации...
пользователь на адиминистративном сервере при входе сразу проверяется есть флаг или нету
если пользователь не на административном сервере хочет залочить, то єтот сервер формирует запрос на административній о необходимости залочить
от периода репликации єто не зависит
 
Мы в соцсетях:

Обучение наступательной кибербезопасности в игровой форме. Начать игру!