На WF можно сделать почти всё. Разница только в трудозатратах и сроках.
Что бы сделать механизм получения списка доступных команд в WF 3.5(4) нужно потратить пару недель (при этом документооборот у вас будет задаваться в разных местах код — это прямой путь к ошибках).
У нас список доступных команд определяется вызовом одного метода — GetAvailableCommands.
>>1.Указываем в метаинформации, не конкретного сотрудника, а группу/роль
Это приведет к усложнению вашей мета информации. Простым SQL фильтром не обойтись при выборке команд.
>>2. В случае отсутствия куратора согласует начальник департамента
Решается через общий механизм замещения.
В этом случае начальник департамента будет видеть лишние документы. Это не всегда подходит.
Не лучший потому что подходит только для простейших случаев, если процессы согласования в будущем будут усложняться, то прийдется переделывать.
Когда появился WF 4 в нем не было State Machine совсем, он не совместим с 3.5. А самое главное он не решал большей части проблем, а только добавлял новые.
>>Проблему с определением того, кто может нажать — в мета информации сохраняется ид пользователя, который может нажать на данную кнопку.
А что делать там не id пользователя, а условие? Например, согласовать может только сотрудник с ролью Куратор из родительского подразделения или в случае отсутствия куратора согласует начальник департамента.В этом случае обычным запросом к БД не обойтись. Так же это существенно усложняет мета данные и их обработку.
Можете выложить код, как проводите обработку мета-данных?
>>Согласование, а перечень лиц, вообще определяется в настройках системы (или задается пользователем).
Иногда мы делаем так же, но это не лучший вариант.
>>Единственное, что красиво пока не удалось решить, это вложенное согласование, так как WWF не поддерживает рекурсии в процессах.
У нас пока тоже это не реализовано. По плану должны сделать в марте. Я сейчас готовлю статью на тему «Подпроцессы в workflow и паралельное согласование». Статья будет опубликована на codeproject.com.
Что бы сделать механизм получения списка доступных команд в WF 3.5(4) нужно потратить пару недель (при этом документооборот у вас будет задаваться в разных местах код — это прямой путь к ошибках).
У нас список доступных команд определяется вызовом одного метода — GetAvailableCommands.
>>1.Указываем в метаинформации, не конкретного сотрудника, а группу/роль
Это приведет к усложнению вашей мета информации. Простым SQL фильтром не обойтись при выборке команд.
>>2. В случае отсутствия куратора согласует начальник департамента
Решается через общий механизм замещения.
В этом случае начальник департамента будет видеть лишние документы. Это не всегда подходит.
Не лучший потому что подходит только для простейших случаев, если процессы согласования в будущем будут усложняться, то прийдется переделывать.
Нам было легче сохранять в виде отдельных DLL, чем добавлять механизм сохранения в БД.
>>Проблему с определением того, кто может нажать — в мета информации сохраняется ид пользователя, который может нажать на данную кнопку.
А что делать там не id пользователя, а условие? Например, согласовать может только сотрудник с ролью Куратор из родительского подразделения или в случае отсутствия куратора согласует начальник департамента.В этом случае обычным запросом к БД не обойтись. Так же это существенно усложняет мета данные и их обработку.
Можете выложить код, как проводите обработку мета-данных?
>>Согласование, а перечень лиц, вообще определяется в настройках системы (или задается пользователем).
Иногда мы делаем так же, но это не лучший вариант.
>>Единственное, что красиво пока не удалось решить, это вложенное согласование, так как WWF не поддерживает рекурсии в процессах.
У нас пока тоже это не реализовано. По плану должны сделать в марте. Я сейчас готовлю статью на тему «Подпроцессы в workflow и паралельное согласование». Статья будет опубликована на codeproject.com.