Раздача прав пользователям

[Guest]

Приветствую всех у кого есть мысли касательно одной маленькой, но очень большой проблеме.

У нас в документообороте используется иерархическая структура типа - входящий документ - резолюция - поручение - исполнение. В нашей системе раздача прав пользователю, т.е. исполнителю которому отписали допустим резолюцию, раздача прав проходит на сервере агентом. Проблема: при изменении агентом полей Readers в основном документе (главный документ иерархии), редко, но бывает что значений этих в документе просто нет. Агент тщательно залогирован, и сомнений в том что агент некорректно отработал нет. Исключается так же момент когда данный документ редактируется ке то из пользователей, т.к по документу так же ведется логирование на открытие, изменение, сохранение и т.д. В чем может быть причина, кто нибудь сталкивался с подобным? Начальство требует объяснить, но к логам придраться не могу.

 

[hosm]

Проблема: при изменении агентом полей Readers в основном документе (главный документ иерархии), редко, но бывает что значений этих в документе просто нет.

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

 

[Guest]

Поле не исчезло, просто нет того значения в поле которое должно добавиться. Добавленные значения логируются, агент логируется по всем произведенным изменениям, сохранениям и т д. Так же агент выводит в лог все значения этого поля в лог после завершения работы агента, чтобы убедиться что все в порядке, но в документе этого значения никак нет. Из ваших предположений ближе к истине может быть то, что параллельно создания текущей резолюции, может создавать еще кто - либо, тем самым пытаясь передать в основной документ какие то данные. В наших случаях по времени создания резолюции расходились по 5-10 мин, могло ли это повлиять. И отсюда еще вопрос - может ли быть конфликт одного и того же серверного агента, где выполняется изменение и сохранение данных 1 документа, если агент запустить одновременно с 2 - х машин, так как агентов влияющих на изменение данной карточки больше нет? Поле не переполнялось и репликаций с базой нет.

 

[nvyush]

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

 

[Guest]

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

 

[nvyush]

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

Добавлено

но министры не хотят ждать 5 минут пока его поручение перейдет к другому

А как часто Лотус-клиент министров проверяет приход новой почты?

 

[Guest]

Дело в том что лотусовой почтой они не пользуются, есть специально организованный АРМ Руководителя, который они почти не закрывают.