Пример правила автоматизации 4
Создание цикла повторной обработки в рабочем процессе
Когда завершение задачи не удалось, статус предыдущих задач не обновляется до ‘Назначена’, и рабочий процесс переходит в состояние ‘Выполнение остановлено’. Менеджер рабочего процесса может решить, как возобновить выполнение. Для некоторых рабочих процессов это всегда означает переработку ранее выполненной задачи.
В этом примере есть 3 задачи, которые должны быть выполнены последовательно:
- Разработать новый релиз
- Передать новый релиз на тестирование
- Протестировать новый релиз
- Передать новый релиз на тестирование
Если третья задача не будет выполнена, менеджер рабочего процесса хочет, чтобы правило автоматизации установило статус первой задачи обратно на ‘Назначена’ а двух других задач - на ‘Зарегистрирована’. Это обеспечит возврат рабочего процесса к первой задаче.
В следующих разделах описывается, как менеджер рабочего процесса может определить ключевые части этого правила автоматизации.
Триггер
Поскольку правило должно быть выполнено после того, как третья задача будет установлена в значение ‘Не удалось’, в поле Триггер выбрана опция ‘При обновлении статуса’.
Выражения
Следующие выражения определены для правила, чтобы впоследствии их можно было использовать для определения условия правила, а также действий, которые оно должно выполнить:
1. has_failed
Выражение has_failed
указывает, что поле "Статус" третьей задачи установлено в значение ‘Не удалось’. Оно определяется следующим образом:
status = failed
2. note
Выражение note
добавляется для поиска заметки, которая была добавлена к третьей задаче, когда ее статус был установлен в ‘Не удалось’. Это будет последнее примечание к задаче, и оно должно описывать причину неудачи. Это выражение определяется следующим образом:
note[last].text
3. develop_task
Выражение develop_task
используется для идентификации задачи по разработке нового релиза. Тема этой задачи - ‘Разработать новый релиз’, а значит, выражение можно определить следующим образом:
workflow.tasks['Разработать новый релиз']
4. transfer_task
Выражение develop_task
используется для определения задачи по переносу нового релиза в тестовую среду. Поскольку темой этой задачи является ‘Перенос нового релиза в тестовую среду’, выражение можно определить следующим образом:
workflow.tasks['Перенос нового релиза в тестовую среду']
Условие
После того как выражения определены в правиле, можно задать условие, которое должно быть выполнено для того, чтобы правило было выполнено. В этом примере статус задачи должен быть ‘Не удалось’. Поскольку для этого уже есть выражение, условие, которое должно быть истинным, просто:
has_failed
Это все, что нужно ввести в поле "Условие" правила.
Обновление 1
Первое действие, которое должно быть выполнено правилом — это добавление примечания в задачу разработки, чтобы сообщить разработчику, почему задача была открыта заново. Для этой задачи уже существует выражение develop_task
. Поэтому это выражение можно выбрать в поле Обновить.
Добавить примечание
Поскольку целью первого действия является добавление примечания к задаче разработки, опцию по умолчанию ‘Установить’ необходимо изменить на ‘Добавить примечание’. При этом появится текстовое поле, в котором можно задать примечание. Чтобы включить последнее примечание неудачной задачи, в примечании можно использовать выражение, которое было определено для этого последнего примечания:
Новый релиз не прошел все тесты:
{{note
}}
Обновление 2
Второе действие правила требует повторного открытия задачи разработки. Поэтому снова в поле "Обновить" можно установить выражение develop_task
.
Установить
Поскольку целью второго действия является установка статуса задачи разработки обратно в ‘Назначена’, в поле "Установить" нужно указать следующее::
status = assigned
Обновление 3
Третье действие правила должно обновить задачу передачи. Поэтому в поле "Обновить" можно установить выражение transfer_task
.
Установить
Цель третьего действия - вернуть статус задания на передачу в значение ‘Зарегистрировано’. Это можно указать в поле "Установить" следующим образом:
status = registered
Обновление 4
Четвертое действие правила должно обновить статус тестовой задачи. Поскольку это задача, для которой определено правило автоматизации, поле "Обновить" не должно иметь значения. Поэтому по умолчанию оно будет соответствовать текущей записи (т. е. тестовой задаче).
Установить
Четвертое действие должно установить статус тестовой задачи обратно на ‘Зарегистрировано’, что можно определить в поле "Установить" следующим образом:
status = registered
Обновление 5
Пятое действие должно обновить статус рабочего процесса, который был установлен на ‘Прогресс остановлен’ после того, как тестовое задание потерпело неудачу. Чтобы указать, что рабочий процесс необходимо обновить, просто укажите workflow
в поле "Обновить".
Установить
Чтобы пятое действие вернуло статус рабочего процесса к значению ‘Выполнение’, в поле "Установить" нужно указать следующее:
status = implementation