Не секрет, что в качестве участников workflow-процессов в К2 могут выступать:
В отличие от всех иных перечисленных вариантов, использование К2 ролей крайне удобно в процессах, шаги которого могут быть довольно продолжительными по времени, и существует ощутимая вероятность того, что в течение времени выполнения шага количественный состав пользователей - исполнителей данного шага может меняться. Например, несколько рабочих процессов компании могут назначать задачи целым отделам - бухгалтерии, отделу кадров, администрации, ИТ-поддержке и т.п. То есть, с точки зрения процесса, задача назначается всем сотрудникам отдела и совершенно без разницы, кто эту задачу возьмет и выполнит.
Очевидно, что состав отделов, особенно больших, довольно непостоянен с течением времени - могут приходить новые люди, увольняться или переходить в иные отделы другие сотрудники и так далее.
Использование ролей решает проблему переназначения задач - новому сотруднику отдела должны быть автоматически назначены задачи, которые пришли на отдел до его появления и находятся в активном состоянии в настоящий момент, а с ушедших сотрудников, наоборот, задачи отдела должны быть сняты. В этом отношении роли К2 являются динамическими сущностями, они могут быть легко созданы в K2 Workspace, и также легко изменены там, без необходимости внесения каких-либо изменений в сами workflow-процессы. Но самое главное - у всех ролей есть собственное расписание обновления своего состава, по умолчанию - каждые 8 часов происходит обновление задач для членов роли - новым участникам задачи назначаются, у выбывших - удаляются.
Это объясняет ошибочность ожидания немедленного переназначения задачи отдела на только что добавленного пользователя - это произойдет, по умолчанию, только в момент очередного обновления роли.
Но что делать, если требуется произвести обновление немедленно, не дожидаясь очередного обновления. Ответ - сбросить кэш ролей, принудительно установив время их обновления в текущий момент.
Вообще, информация о времени обновления роли находится в таблице Identity.Identity базы данных К2 (или K2HostServer для неконсолидированной БД), и можно просто изменить время обновления нужной роли. Однако, чтобы не сделать случайной ошибки, можно воспользоваться следующим скриптом, выполнив его в БД K2 (или K2HostServer):
UPDATE [K2HostServer].[Identity].[Identity]
SET [ExpireOn] = GETDATE()
,[Resolved] = 0
,[ContainersResolved] = 0
,[ContainersExpireOn] = GETDATE()
,[MembersResolved] = 0
,[MembersExpireOn] = GETDATE()
GO
Все роли будут обновлены в течение нескольких минут.
- отдельные пользователи (учетные записи Active Directory или SharePoint);
- группы пользователей (группы Active Directory или SharePoint);
- пользователи, определенные в структуре таблиц MS SQL сервер, т.н. SQLUM;
- пользователи, определяемые правилами кастомного Security Provider;
- а также K2-роли
В отличие от всех иных перечисленных вариантов, использование К2 ролей крайне удобно в процессах, шаги которого могут быть довольно продолжительными по времени, и существует ощутимая вероятность того, что в течение времени выполнения шага количественный состав пользователей - исполнителей данного шага может меняться. Например, несколько рабочих процессов компании могут назначать задачи целым отделам - бухгалтерии, отделу кадров, администрации, ИТ-поддержке и т.п. То есть, с точки зрения процесса, задача назначается всем сотрудникам отдела и совершенно без разницы, кто эту задачу возьмет и выполнит.
Очевидно, что состав отделов, особенно больших, довольно непостоянен с течением времени - могут приходить новые люди, увольняться или переходить в иные отделы другие сотрудники и так далее.
Использование ролей решает проблему переназначения задач - новому сотруднику отдела должны быть автоматически назначены задачи, которые пришли на отдел до его появления и находятся в активном состоянии в настоящий момент, а с ушедших сотрудников, наоборот, задачи отдела должны быть сняты. В этом отношении роли К2 являются динамическими сущностями, они могут быть легко созданы в K2 Workspace, и также легко изменены там, без необходимости внесения каких-либо изменений в сами workflow-процессы. Но самое главное - у всех ролей есть собственное расписание обновления своего состава, по умолчанию - каждые 8 часов происходит обновление задач для членов роли - новым участникам задачи назначаются, у выбывших - удаляются.
Это объясняет ошибочность ожидания немедленного переназначения задачи отдела на только что добавленного пользователя - это произойдет, по умолчанию, только в момент очередного обновления роли.
Но что делать, если требуется произвести обновление немедленно, не дожидаясь очередного обновления. Ответ - сбросить кэш ролей, принудительно установив время их обновления в текущий момент.
Вообще, информация о времени обновления роли находится в таблице Identity.Identity базы данных К2 (или K2HostServer для неконсолидированной БД), и можно просто изменить время обновления нужной роли. Однако, чтобы не сделать случайной ошибки, можно воспользоваться следующим скриптом, выполнив его в БД K2 (или K2HostServer):
UPDATE [K2HostServer].[Identity].[Identity]
SET [ExpireOn] = GETDATE()
,[Resolved] = 0
,[ContainersResolved] = 0
,[ContainersExpireOn] = GETDATE()
,[MembersResolved] = 0
,[MembersExpireOn] = GETDATE()
GO
Комментариев нет:
Отправить комментарий