Корпорация Microsoft, пожалуй, создала уникальный инструмент для автоматизации рабочих процессов – SharePoint. Без единой строчки кода с его помощью можно создавать системы управления документами, отвечающие практически всем современным требованиям. Сегодня поговорим о том, как решить задачу автоматизации корпоративного документооборота.
Под рукой у нас следующие инструменты:
- Служба Microsoft SharePoint Services, входящая в базовую установку Microsoft Windows Server 2003
- SharePoint Designer 2007
Простейшие процессы обработки документов не заставят потратить много времени. Я же хочу затронуть не совсем стандартный сценарий документооборота. Его главная идея выглядит так: в некую коллекцию документов автором (А) загружается документ, который необходимо просмотреть в двух инстанциях (И1 и И2). В зависимости от состояния документа, на каждой инстанции должна происходить проверка документа по каким-либо параметрам качества. В зависимости от них документ либо отвергается, либо принимается и передается на следующий шаг. Если документ отвергается, он передается на предыдущий шаг и так далее.
Блок-схема представлена на рисунке:
Блок-схема работы алгоритма.
Первым делом необходимо создать библиотеку документов. Назовем ее Tickets List В ней будет отображаться вся необходимая информация по создаваемым документам. Так же нам понадобится лист для задач Tasks List. Немного пояснений: при каждом перемещении документов на имя человека, которому передается документ, ставится задача обработать приходящий документ. Например, задача проверить документ или, либо передать дальше, либо передать обратно, в зависимости от успешности проверки.
Начало работы с Sharepoint Designer
Двигаемся в меню “Файл -> Новый -> Workflow”. После чего на экране появится мастер пошагового создания процесса обмена документами.
Создание нового workflow
Необходимо как-то назвать workflow. Среди обязательный полей нужно указать список документов, к которому он привязывается, а так же способы запуска. Существует три способа запуска workflow:
- Самостоятельный запуск вручную.
- Автоматический запуск сразу после создания документа из листа, который мы привязали выше.
- Автоматический запуск после любого изменения любого из документов в указанном листе.
В нашем случае мы создаем два отдельных процесса обработки документов и для каждого указываем подходящие параметры:
Workflow обработки документов (Tickets WF) будет запускаться либо вручную, либо (что предусмотрено автоматически) в результате изменения документов из листа Tickets List.
Второй workflow будет обрабатывать задания, выдаваемые в результате перемещения документов. Я назвал его Tasks WF, он так же будет привязан к листу Tickets List и будет запускаться, когда будет добавляться новый Ticket.
Заблаговременно было добавлено поле «Ticket status», где будет храниться статус документа. На первом шаге необходимо присвоить этому полю начальное значение.
Первый шаг алгоритма.
В результате создания нового документа (Ticket), срабатывает «триггер», который назначает задание ответственному лицу за выполнение первого шага. Механизм назначения заданий находится в Tasks WF, который будет рассмотрен сразу после Tickets WF.
На втором шаге перед присвоением Ticket’у следующего статуса, необходимо проверить состояние задания, которое было выдано в результате первого шага.
Второй шаг алгоритма.
Следующий (третий и последний) шаг Tickets WF необходим для проверки выполнения второго шага.
Tickets WF: Завершение работы.
Теперь перейдем к описанию Tasks WF. Выше уже были описаны начальные параметры этого workflow. Данный workflow запускается в результате всякого изменения статуса любого документа из Tickets List. На первом шаге проверяется изменившийся статус и в зависимости от этого назначаются соответствующие задания ответственным лицам:
- Если документ только создан и его статус «Pending» (1-е условие), задание назначается одному лицу (в данном случае это первый этап проверки документа)
- Если документ уже был проверен на первом этапе (2-е условие), задание назначается ответственному за второй этап проверки
- В случаях, если на каком-либо из двух этапов проверки документ отвергается (3-е и 4-е условия), назначается задание по перепроверки документа для лица, создавшего этот документ.
Обработка Tasks WF.
Особо нужно отметить способ, по которому привязываются задания к определенному документу. Делается это с помощью “Collect data from…”. Это действие позволяет назначить задание, отобразить необходимые поля, которые необходимо будет заполнить в процессе выполнения задания.
Tasks WF: Назначение задания.
На приведенном выше рисунке показаны шаги для формирования полей нового задания. Теперь после этого нужно привязать данное задание конкретной персоне. В моем случае при создании нового документа автор выбирал ответственных за каждый шаг. Таким образом, кликнув на “user” можно выбрать ответственного: Workflow Lookup -> Current Item -> Approval Request to. Данное поле можно заполнять любым способом по вашему усмотрению. Теперь это задание нужно однозначно присвоить некоему уникальному идентификатору, который будет использоваться в момент определения статуса документа, к которому привязана задача. Проще говоря, нужно заполнить поле “Output to:”. Я назвал эту переменную как Approval Request ID.
Теперь перейдем к самому ответственному этапу. Добавим еще одно действие “Set Workflow Variable”. В этой переменной будет хранится статус задачи, которую мы назначили только что. Для определения к какой именно задаче относится этот статус и будет использоваться переменная Approval Request ID. Переменную, в которую будет записан статус задачи назовем Approval Request status. В поле “to” сформируем поле так, как показано на следующем рисунке:
Tasks WF: Создание переменной.
После этого строка с переменной статуса должна выглядеть так:
Tasks WF: присвоение переменных.
Остальные условия формируются аналогичным образом, отличие состоит в том, какое задание и кому его назначать.
Необходимо создать еще один шаг в Tasks WF, на котором будет проверяться выполнение поставленных задач. Стоит обратить внимание на одно из условий, все они формируются по аналогии. В условии проверяется статус задачи с помощью “Compare any data source”. В качестве “any” выступает та самая переменная, в которую мы записали статус на предыдущем шаге:
Tasks WF: Проверка статуса задачи.
В поле “value” запишем значение статуса, при котором задача является выполненной. В моем случае это “Approved”. В качестве действия добавим смену статуса документа, движение которого продолжится дальше и перейдет к следующему ответственному, то есть продолжится Tickets WF. В итоге, вся проверка статусов задач в моем примере выглядит следующим образом:
Tasks WF: Проверка статусов поставленных задач.
На этом можно было бы закончить, но стоит упомянуть еще про возможность зацикливания задач: первый ответственный отвергает задачу – она возвращается к автору, который ее просматривает и отправляет опять к 1-му ответственному. После подтверждения документ переходит к следующему ответственному, который может как подтвердить документ (что приведет к завершению Tickets WF), так и может отвергнуть документ, в результате документ вернется к автору, который будет должен пересмотреть его. Один документ может постоянно переходить от исполнителя к ответственным по кругу, если в документе будут на каждом таком “кругу” находится новые замечания. Надеюсь в Вашем рабочем процессе таких циклов будет немного! 
Alexander Sulimanov