Поиск обработчика задачи в потоке операций

С потоками операций на проектах при настройке, так называемой, расширенной функциональности, консультант сталкивается очень часто. Неважно, работаете ли вы с заявками на поиск кандидатов (e-recruiting), заявками на отпуск (leave request), или с индивидуальными планами развития сотрудников (performance management). Основной упор при настройке потоков, как правило, делается на маршруты согласования. В самом начале этапа настройки потоков‚ консультант выясняет у бизнес-пользователей сколько участников согласования должно присутствовать в том или ином потоке операций и _могут ли добавляться новые участники в процесс согласования/просмотра _и т.д. и т.п. В данной заметке я хочу рассмотреть и описать такую задачу, как поиск обработчика задачи в потоке операций, на самом простом примере, который только смог придумать.

Как уже сказано выше, я попробую рассмотреть процесс поиска обработчика задачи в потоке операций на каком-нибудь простом примере, не уходя в высшие материи. Возможно, что изложение материала покажется куцым и недостаточно развернутым. Но, как говорится, фарш не провернуть назад...

0. Задача

Создать новый поток операций для согласования документа оценки, взяв за основу стандартный поток. В потоке операций определить обработчика задачи по просмотру документа оценки, используя нижеуказанный алгоритм:

1. По штатной должности оцениваемого сотрудника (appraisee) найти соединенную с ней штатную должность по соединению вида **Z01. **Затем определить табельный номер сотрудника, который занимает эту соединенную штатную должность;
2. У найденного сотрудника считать идентификатор пользователя, который сохранен в инфо-типе 0105 — «Communication», подтип 0001 — «System user name».

N.B. С точки зрения _архитектуры документа оценки _рассматриваемый пример не очень корректен, так как я ищу обработчика, который не имеет отношения к документу оценки. Получается, что обработчик, который будет найден в потоке операций, сможет только открыть документ оценки, при этом ему будут недоступны никакие поля на изменение.

См. заметку Реакция документов оценки по отношению к пользователю

На время погружения в материал заметки, предлагаю об этом не думать, но, конечно же, иметь ввиду в будущем. Неважно, работаем мы с документами оценки через потоки операций или же без них, открыть и изменять его сможет пользователь, который является либо проводящим оценку, либо оцениваемым, либо другим участником оценки (по аналогии с участниками, используемыми в оценке 360 градусов: коллега, руководитель, функциональный руководитель, руководитель проекта, архитектор и т.д.)

1. Что у нас есть?

Исходя из условий поставленной выше задачи, у нас есть следующие входные данные:

1. Какой-то документ оценки, в котором обязательно должны быть сохранены данные (под данными я имею ввиду табельный номер) по оценивающему и оцениваемому сотрудникам;
2. Соединение вида Z01 для штатной должности оцениваемого сотрудника с какой-то другой штатной должностью;
3. Стандартный поток операций, который следует использовать в качестве шаблона.

Теперь по порядку. В качестве документа оценки в данной заметке будет использоваться документ вида:

От документа оценки нам нужен будет только его идентификатор (appraisal id), а также табельный номер оцениваемого сотрудника (appraisee).

Для демонстрации и тестирования всех манипуляций с потоком операций, я буду использовать подготовленный пример, а именно: для штатной должности оцениваемого сотрудника предварительно создано соединение вида Z01 с другой штатной должностью

Соединенной по связи Z01 штатной должности _присвоен _сотрудник, в инфо-типе 0105 которого наличествует следующая запись

Теперь поток операций.

В качестве стандартного потока операций предлагаю использовать следующий шаблон WS12300116

В данном потоке операций происходит генерация ссылки на документ оценки, которая затем пересылается оцениваемому сотруднику. Сотрудник, который должен быть обработчиком документа оценки, определяется с помощью правила 12300010

А уже в самом правиле используется функциональный модуль HRHAP_DOC_WF_ACTOR_APPRAISEE, определяющий идентификатор пользователя оцениваемого сотрудника

Для нужд данной заметки поток операций полностью подходит. Все что нужно сделать (ну или почти все) — это скопировать его в новый и создать задачу, в которой, используя алгоритм, представленный выше, определить обработчика.

2. Создание нового потока операций

Откройте транзакцию PFTC, введите идентификатор стандартного потока, который будет использован в качестве шаблона, и нажмите на кнопку 

В результате выполненного копирования вашему потоку операций будет присвоен новый восьмизначный идентификатор

Поток готов для дальнейшей работы.

3. Создание utility-класса

В заметке про отладку фоновых задач потоков операций я немного затрагивал тему utility-классов, которые используются в потоках операций. В этой заметке будет использоваться этот тип класса для того, чтобы найти нового обработчика задачи в потоке

См. ABAP Classes in Workflow

Создайте новый класс, с помощью транзакции SE24

Перейдите на закладку Interfaces,_ _введите IF_WORKFLOW и нажмите Enter

Перейдите на закладку Methods и введите наименование нового метода, который будет отвечать за определение обработчика задачи

Обратите внимание на то, что для нового метода должен быть выбран тип Static Method, доступность — Public. Как для любого другого метода класса, необходимо определить параметры, которые будут передаваться на вход и выход соответственно. В нашем случае, на вход в метод необходимо передать идентификатор документа оценки (appraisal_id), с помощью которого можно будет определить идентификатор оцениваемого сотрудника/его штатную должность и далее по нашему алгоритму. Получается

Параметр APPRAISAL_ID будет содержать идентификатор документа оценки, а в параметр EX_APPROVER будет записан считанный идентификатор сотрудника, который и будет обработчиком задачи. Сохраните внесенные изменения. Ну а далее встречаем нашего старого доброго знакомого. ABAP, baby! Чтобы не пугать всех читающих эту заметку своим быдлокодом, я не стану приводить пример кода, который я написал при подготовке данной заметки. Катарсис испытать при виде его не получится. Я проверял. Разве что немного грусти и жалости к самому себе

Алгоритм заполнения параметра EX_APPOVER следующий:

1. По считанному идентификатору документа оценки (APPRAISAL_ID) необходимо получить табельный номер оцениваемого работника;
2. По его табельному номеру определяем штатную должность;
3. По штатной должности читаем соединенную по связи Z01 штатную должность;
4. По этой штатной должности определяем владельца и читаем инфо-тип 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

На этом этапе необходимо выполнить мэппинг элементов контейнера потока операций и новой задачи, для того чтобы:

1. Передать правильный элемент контейнера потока операций, в котором содержится идентификатор документа оценки, на входв задачу
2. И получить корректно заполненный элемент потока операций, в котором содержится имя пользователя, на выходеиз задачи

Идентификатор документа оценки (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. Возьмите за правило, что в потоках операций, в которых предполагается какое-либо согласование и поиск обработчиков по каким-либо алгоритмам (как в нашем примере), необходимо обрабатывать ситуации в которых обработчик не будет найден. Например, если обработчик не найден, необходимо направить информационное письмо группе пользователей, которую можно будет определить с помощью правила ответственности, с текстом вида: «...вы получили это письмо, так как обработчик задачи такой-то не найден...»

Резюме

Про потоки операций можно говорить долго и нудно. К сожалению, многое из того, что также могло бы быть в данной заметке, осталось не упомянутым. Отчасти это связано с довольно большим объемом того, что можно было бы сказать, а отчасти — потому что этот материал вполне себе может потянуть на отдельную(ые) заметку(и).  Думаю, что представленная заметка все равно найдет своего читателя, и данное описание сможет помочь консультантам и всем страждущим интересующимся, которые работают с потоками операций. То, что представлено в данной заметке является каплей в море, по сравнению с тем, что еще можно делать в потоках операций. Начало положено, а все остальное — дело времени и желания. Удачи!