Модуль извещений

Автор silver, 28.05.15, 11:08:07

« назад - далее »

0 Пользователи и 1 гость просматривают эту тему.

silver

Всем добрый день!

Хочу поделится, попыткой настроить процесс согласование извещений, в лоцмане при помощи модуля извещений. Рассказать о проблемах с которыми столкнулся, а также может быть услышать советы как эти проблемки преодолеть.
Началось все с того что в далеком бородатом году закупили у нас Лоцман 2011. На момент внедрения планировали его использовать просто как электронный архив документации и не более. Но с течением времени появилась потребность в электронном документообороте. В лоцмане вроде все для этого есть а значит нужно это использовать. В общем решил начать с согласования извещений, потому как есть готовый модуль, типовые процессы, документация описывающая настройки модуля. Но столкнулся со следующим:
1. Выяснилось что не работает автооперация "Включить/Выключить следующую операцию" а именно функция SetActuated выполняется, выдает положительный результат но следующая операция как была неактивной так такой и остается, обратился в ТП, там мне это подтвердили, посочувствовали, так как обновления на Лоцман 2011 больше не выпускаются. Но надо сказать спасибо подсказали как эту проблемку можно обойти, а именно не делать ее активной, а перевести ее в состояние psConsider - задание направлено участнику, после чего даже если операция неактивна задание все равно приходит.
2. Со следующей проблемой столкнулся, когда уже процесс согласования был готов, опробован и уже планировалось запустить все в работу, но выяснилось что если один из участников процесса отказал в согласовании извещения, то при следующем согласовании, после корректировки извещения, участник который в прошлый раз отказал в согласовании не может завершить задание, выходит сообщение об ошибке в котором пишется что: автооперация "Запросить резолюцию и перевести объект в состояние разрешено к применению" возвращает отрицательный результат.  А возвращает отрицательный результат, она по тому что, не может найти тот самый лист согласования который нужно перевести в указанное состояние, так как к операции участника он оказывается не прикрепился при повторном запуске процесса. Т.е. если участник отказал, его лист согласования переходит в состояние "не разрешено к применению", а на данное состояние у обычного  конструктора, права только чтение, то при следующем запуске процесса в результате выполнения автооперации "синхронизировать листы согласования" в момент когда выполняется функция CheckCoordPages из Changes_WFSP.dll, новые листы согласования прикрепляются ко всем стадиям кроме того у которого состояние листа согласования было "не разрешено к применению". Самое интересное что в ходе общения с ТП выяснилось что данная ошибка выходит также и в Лоцман 2014, может и в 2013. Пока писал это сочинение, от ТП пришло сообщение с советом дать специалистам максимальный доступ на состояние "не разрешено к применению" чтение/запись. Думаю это должно сработать надо попробовать.
3. Есть еще один, пока не решенный, у меня момент, это то что хотелось бы настроить рассылку сообщений о поступивших и выполненных заданиях по электронной почте. В лоцмане данная функция есть, своя почта на предприятии есть, но оказалось что для рассылки нужно чтоб smtp сервер не  запрашивал аутентификацию. С рабочего почтового сервера ни кто аутентификацию убирать не хочет, оно и понятно, по этому думаю поставить отдельный smtp для рассылки сообщений лоцмана. Может кто может подсказать какой нибудь маленький простенький в настройке и желательно бесплатный сервер, подходящий для этих целей?

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

Chipollino

Мы используем модуль извещений, но без WorkFlow - в нём у нас другие БП описаны и к ним большинство автоопераций пришлось писать самостоятельно.
По мне, так лучше не переводить в состояние "не разрешено к применению" при отказе - это будет проще, или писать в этом случае ещё одну автооперацию по принципу - если лист уже существует но в некорректном состоянии, то сделать на него новую версию. Это будет правильнее с точки зрения сохранения истории

Danila

29.05.15, 08:01:17 #2 Последнее редактирование: 29.05.15, 08:13:41 от Danila
Мы также используем отдельно логику бизнес-процессов и отдельно создание, проведение извещений, а также собственная логика проведения контроля за исполнением всех правил по подготовке документации для утверждения документации.
Все с помощью практически только своих модулей, так как со стандартным модулем "наелись" выше крыши.

silver

  Пока довел весь процесс до нынешнего состояния тоже пришлось написать не мало автоопераций.
  Вчера опробовал решение предложенное ТП, чтоб дать максимальный доступ на состояние как чтение/запись, в итоге данная ошибка вроде больше не выходит. Но в этом случае терзает тот факт что, инициатор процесса имеет доступ к листу согласования и теоретически может изменить, хотя смысла от этого не будет.
  И только избавился от этой проблемы как появилась другая. Есть такая злополучная автооперация "Запросить резолюцию и перевести объект в состояние разрешено к применению", так вот если все лицензии лоцман заняты, при этом одна из них у меня, и я жму "Завершить задание", то лоцман выполняя вышеуказанную операцию выдает ошибку, мол автооперация вернула отрицательный результат, при этом окно выбора резолюции из списка даже не появляется. Как только кто нибудь закрывает лоцман, автооперация выполняется без ошибок. Все подозрения падают на то что при выполнении этой автооперации занимается еще одна лицензия Лоцман. К сожалению Лоцман я так понял не поддерживает освобождение лицензии при бездействие в течении определенного времени. В итоге чтоб такого не повторялось пришлось переписать операцию. Так как "Заключение о внедрении" мы не используем, вместо использования функции "AskResolution" модуля "Changes_WF.dll", в атрибут "Заключение о внедрении" теперь вносится текст комментария исполнителя. На других автооперациях использующих ExecDllFunctionEx пока такого не замечал. Сталкивался ли кто с подобной ситуацией?

Danila

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

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

silver

Согласен, в нашем случае наверное лучше все таки не переводить "лист согласования" в состояние "не разрешено к применению", так с правами меньше проблем будет, а состояние листа согласования в процессе ни на что не повлияет.