Поиск обработчика задачи в потоке операций
С потоками операций на проектах при настройке, так называемой, расширенной функциональности, консультант сталкивается очень часто. Неважно, работаете ли вы с заявками на поиск кандидатов (e-recruiting), заявками на отпуск (leave request), или с индивидуальными планами развития сотрудников (performance management). Основной упор при настройке потоков, как правило, делается на маршруты согласования. В самом начале этапа настройки потоков‚ консультант выясняет у бизнес-пользователей сколько участников согласования должно присутствовать в том или ином потоке операций и _могут ли добавляться новые участники в процесс согласования/просмотра _и т.д. и т.п. В данной заметке я хочу рассмотреть и описать такую задачу, как поиск обработчика задачи в потоке операций, на самом простом примере, который только смог придумать.
Как уже сказано выше, я попробую рассмотреть процесс поиска обработчика задачи в потоке операций на каком-нибудь простом примере, не уходя в высшие материи. Возможно, что изложение материала покажется куцым и недостаточно развернутым. Но, как говорится, фарш не провернуть назад...
0. Задача
Создать новый поток операций для согласования документа оценки, взяв за основу стандартный поток. В потоке операций определить обработчика задачи по просмотру документа оценки, используя нижеуказанный алгоритм:
- По штатной должности оцениваемого сотрудника (appraisee) найти соединенную с ней штатную должность по соединению вида **Z01. **Затем определить табельный номер сотрудника, который занимает эту соединенную штатную должность;
- У найденного сотрудника считать идентификатор пользователя, который сохранен в инфо-типе 0105 — «Communication», подтип 0001 — «System user name».
N.B. С точки зрения _архитектуры документа оценки _рассматриваемый пример не очень корректен, так как я ищу обработчика, который не имеет отношения к документу оценки. Получается, что обработчик, который будет найден в потоке операций, сможет только открыть документ оценки, при этом ему будут недоступны никакие поля на изменение.
См. заметку Реакция документов оценки по отношению к пользователю
На время погружения в материал заметки, предлагаю об этом не думать, но, конечно же, иметь ввиду в будущем. Неважно, работаем мы с документами оценки через потоки операций или же без них, открыть и изменять его сможет пользователь, который является либо проводящим оценку, либо оцениваемым, либо другим участником оценки (по аналогии с участниками, используемыми в оценке 360 градусов: коллега, руководитель, функциональный руководитель, руководитель проекта, архитектор и т.д.)
1. Что у нас есть?
Исходя из условий поставленной выше задачи, у нас есть следующие входные данные:
- Какой-то документ оценки, в котором обязательно должны быть сохранены данные (под данными я имею ввиду табельный номер) по оценивающему и оцениваемому сотрудникам;
- Соединение вида Z01 для штатной должности оцениваемого сотрудника с какой-то другой штатной должностью;
- Стандартный поток операций, который следует использовать в качестве шаблона.
Теперь по порядку. В качестве документа оценки в данной заметке будет использоваться документ вида:
От документа оценки нам нужен будет только его идентификатор (appraisal id), а также табельный номер оцениваемого сотрудника (appraisee).
Для демонстрации и тестирования всех манипуляций с потоком операций, я буду использовать подготовленный пример, а именно: для штатной должности оцениваемого сотрудника предварительно создано соединение вида Z01 с другой штатной должностью
Соединенной по связи Z01 штатной должности _присвоен _сотрудник, в инфо-типе 0105 которого наличествует следующая запись
Теперь поток операций.
В качестве стандартного потока операций предлагаю использовать следующий шаблон WS12300116
В данном потоке операций происходит генерация ссылки на документ оценки, которая затем пересылается оцениваемому сотруднику. Сотрудник, который должен быть обработчиком документа оценки, определяется с помощью правила 12300010
А уже в самом правиле используется функциональный модуль HRHAP_DOC_WF_ACTOR_APPRAISEE, определяющий идентификатор пользователя оцениваемого сотрудника
Для нужд данной заметки поток операций полностью подходит. Все что нужно сделать (ну или почти все) — это скопировать его в новый и создать задачу, в которой, используя алгоритм, представленный выше, определить обработчика.
2. Создание нового потока операций
Откройте транзакцию PFTC, введите идентификатор стандартного потока, который будет использован в качестве шаблона, и нажмите на кнопку 
В результате выполненного копирования вашему потоку операций будет присвоен новый восьмизначный идентификатор
Поток готов для дальнейшей работы.
3. Создание utility-класса
В заметке про отладку фоновых задач потоков операций я немного затрагивал тему utility-классов, которые используются в потоках операций. В этой заметке будет использоваться этот тип класса для того, чтобы найти нового обработчика задачи в потоке
Создайте новый класс, с помощью транзакции SE24
Перейдите на закладку Interfaces,_ _введите IF_WORKFLOW и нажмите Enter
Перейдите на закладку Methods и введите наименование нового метода, который будет отвечать за определение обработчика задачи
Обратите внимание на то, что для нового метода должен быть выбран тип Static Method, доступность — Public. Как для любого другого метода класса, необходимо определить параметры, которые будут передаваться на вход и выход соответственно. В нашем случае, на вход в метод необходимо передать идентификатор документа оценки (appraisal_id), с помощью которого можно будет определить идентификатор оцениваемого сотрудника/его штатную должность и далее по нашему алгоритму. Получается
Параметр APPRAISAL_ID будет содержать идентификатор документа оценки, а в параметр EX_APPROVER будет записан считанный идентификатор сотрудника, который и будет обработчиком задачи. Сохраните внесенные изменения. Ну а далее встречаем нашего старого доброго знакомого. ABAP, baby! Чтобы не пугать всех читающих эту заметку своим быдлокодом, я не стану приводить пример кода, который я написал при подготовке данной заметки. Катарсис испытать при виде его не получится. Я проверял. Разве что немного грусти и жалости к самому себе
Алгоритм заполнения параметра EX_APPOVER следующий:
- По считанному идентификатору документа оценки (APPRAISAL_ID) необходимо получить табельный номер оцениваемого работника;
- По его табельному номеру определяем штатную должность;
- По штатной должности читаем соединенную по связи Z01 штатную должность;
- По этой штатной должности определяем владельца и читаем инфо-тип 0105, подтип 0001
Для считанного значения из пункта #4, необходимо добавить текстовую строку «US», иначе поток операций не сможет определить тип объекта, который мы будем его подсовывать в качестве обработчика. Для программиста реализовать данный алгоритм не составит большого труда.
Итак, код написан, метод сохранен. Вернитесь к списку всех методов, которые доступны в вашем классе, и активируйте их все, не забывая про:
- BI_PERSISTENT~FIND_BY_LPOR
- BI_PERSISTENT~LPOR
- BI_PERSISTENT~REFRESH
- BI_OBJECT~DEFAULT_ATTRIBUTE_VALUE
- BI_OBJECT~EXECUTE_DEFAULT_METHOD
- BI_OBJECT~RELEASE
4. Промежуточное тестирование метода
Для тестирования нового метода достаточно создать документ оценки и скопировать его идентификатор. Создание документа оценки можно выполнить с помощью транзакции PHAP_CREATE
С помощью транзакции PHAP_ADMIN скопируйте идентификатор документа оценки
Выполните тестирование нового метода, передав на вход скопированный идентификатор документа оценки
Параметр EX_APPROVER должен быть заполнен считанным идентификатором пользователя с добавлением US
Готово. Переходим к потоку операций.
5. Настройка потока операций
В новом потоке операций, который был подготовлен ранее (см. пункт # 2. Создание нового потока операций), необходимо добавить задачу, с помощью которой будет определяться обработчик по придуманному мной алгоритму (см. пункт # 0. Задача). Напомню, что обработчик будет определен посредством созданного метода utility-класса. А теперь по пунктам.
5.1 Добавление нового элемента контейнера потока операций
Откройте новый шаблон потока операций в режиме на изменение с помощью транзакции SWDD.
Добавьте новый элемент контейнера потока операций, в который будет записано значение обработчика задачи. Для этого нажмите на кнопку 
и выберите в меню Workflow Container
Затем нажмите 
и определите наименование элемента
На закладке Properties активируйте флаги Import и Export
Сохраните выполненные изменения в потоке операций.
5.2 Добавление новой задачи в поток операций
Теперь необходимо добавить новую задачу, в которой и будет определяться обработчик, посредством созданного ранее класса.
Нажмите на кнопку и выберите в меню Step Types That Can Be Inserted
Перетащите тип шага 
на схему потока операций, расположенную в правой части экрана, между задачами Generate URL и Info to Appraisee - Approve
В контекстном меню поля Task выберите Create task
На открывшемся экране создания новой задачи введите ее наименование. В группе полей Object method выберите категорию Abap Class и укажите наименование класса и метода, который был создан ранее
Откройте вкладку Container и обратите внимание на то, чтобы параметры, определенные для вашего utility-класса, были доступны в списке
Активируйте опции Background processing и Synchronous Object Method
Затем нажмите на кнопку Binding Object Method
Выполните следующий мэппинг элементов контейнера потока операций и задачи, в которой будет определяться обработчик
Сохраните выполненные изменения, вернитесь на экран создания задачи и нажмите на кнопку Binding
На этом этапе необходимо выполнить мэппинг элементов контейнера потока операций и новой задачи, для того чтобы:
- Передать правильный элемент контейнера потока операций, в котором содержится идентификатор документа оценки, на входв задачу
- И получить корректно заполненный элемент потока операций, в котором содержится имя пользователя, на выходеиз задачи
Идентификатор документа оценки (APPRAISAL_ID) будет автоматически заполнен благодаря бизнес-объекту APPR_DOC
На вход мы передали идентификатор документа оценки (ID) в параметр задачи APPRAISAL_ID. На выходе получаем заполненный параметр EX_APPROVER и возвращаем его в элемент контейнера потока операций APPROVER.
Сохраните выполненные изменения.
5.3 Настройка инициирующих событий
В связи с тем, что новый поток операций был скопирован со стандартного, ему также стали доступны инициирующие события стандартного потока операций. Активируем их, нажав на кнопку Basic data
Откройте закладку Start Events и нажмите на кнопку Activate
Теперь необходимо активировать опции Импорта/Экспорта для элемента AppraisalDocument контейнера потока операций, который заполняется бизнес-объектом APPR_DOC. Кликните два раза по этому элементу
5.4 Считывание нового обработчика в потоке операций
Выходим на финишную прямую. Для задачи Info to Appraisee - Approve нашего потока операций необходимо указать элемент контейнера потока операций в котором записан идентификатор пользователя-обработчика задачи. А сделать это проще, чем могло показаться. Откройте задачу Info to Appraisee - Approve
В поле Expression выберите элемент потока операций APPROVER
Активируйте поток операций.
6. Тестирование
После активации потока операций, находясь в окне транзакции SWDD, нажмите на клавишу **F8 **или на кнопку 
. Выберите элемент AppraisalDocument
В открывшемся окне введите идентификатор документа оценки (см. пункт # 3. Промежуточное тестирование метода)
Запустите поток операций
В случае успешного запуска потока операций сформируется информационное сообщение вида 
Для того, чтобы посмотреть какой обработчик был присвоен задаче просмотра документа оценки, необходимо воспользоваться либо транзакцией SWIA, либо SWWL_TOPLEVEL (кому что нравится).
Я воспользуюсь транзакцией SWWL_TOPLEVEL. Для начала убеждаюсь, что поток не завершился с ошибкой. Об этом свидетельствует его статус STARTED
Затем необходимо посмотреть, как отработал наш класс, и как были заполнены элементы потока операций. Нажмите на кнопку 
Выберите соответствующую задачу, и перейдите на закладку Container
Отлично. Требуемый обработчик был найден, а значение идентификатора пользователя было записано в требуемый элемент контейнера потока. Теперь можно посмотреть, кто является обработчиком для последней задачи потока операций
То, что нужно. Пользователь был успешно присвоен в качестве обработчика для задачи потока операций.
N.B. Возьмите за правило, что в потоках операций, в которых предполагается какое-либо согласование и поиск обработчиков по каким-либо алгоритмам (как в нашем примере), необходимо обрабатывать ситуации в которых обработчик не будет найден. Например, если обработчик не найден, необходимо направить информационное письмо группе пользователей, которую можно будет определить с помощью правила ответственности, с текстом вида: «...вы получили это письмо, так как обработчик задачи такой-то не найден...»
Резюме
Про потоки операций можно говорить долго и нудно. К сожалению, многое из того, что также могло бы быть в данной заметке, осталось не упомянутым. Отчасти это связано с довольно большим объемом того, что можно было бы сказать, а отчасти — потому что этот материал вполне себе может потянуть на отдельную(ые) заметку(и). Думаю, что представленная заметка все равно найдет своего читателя, и данное описание сможет помочь консультантам и всем страждущим интересующимся, которые работают с потоками операций. То, что представлено в данной заметке является каплей в море, по сравнению с тем, что еще можно делать в потоках операций. Начало положено, а все остальное — дело времени и желания. Удачи!