Немного про ТМ - работа с блоками (Ожидание, Условие, Мониторинг).

6 5

Итак. Первое. Условие

 - что мы о нем знаем и как к нему обращаемся?

Уверен, что на старте своего тернистого пути, все мы начинали с самого примитивного варианта работы этого блока - Сравнением. Согласен - он просто и понятен без особой подготовки и больше подходит Администраторам, но никак не разработчикам! Стоит немного разобраться в системе, как становится понятно, что вариант работы Условия намного больше чем простое условие! Поясню на примере, как это было раньше:

Примитив на лицо. Сравнение, равенство и добуквенное совпадение с признаком из Параметров. Работает и ладно. Однако, вот тот же самый пример в ином исполнении:

Казалось бы - "Ну и что?", те же яйца, только в профиль. Мы Всего лишь передали те же самые параметры в виде кода в раздел вычисления и описали оба выхода через "RESULT", в чем достижение? Однако, помимо того, что мы вычислили кто и куда должен идти, мы можем провернуть еще очень много необходимых действий! Показываю один раз:

И вот, у нас уже не просто ответ на вопрос, да или нет в операции сравнения на равно или нет, а полноценный вычислитель, не занимающий у нас дополнительных параметров для своей работы. Используя это вычисление, совсем несложно спрогнозировать поведение задачи и все последствия от принятого решения. Разумеется, нам ничего не стоит разнести эти вычисления на уровень старта последующих задач, но для чего нам разбираться в этом и запоминать что и где, если наши ответы идут не на один блок, а на несколько? По мне так, вычисление в данном блоке, ни что иное как спасение логики и правил наполнения маршрута условиями и решениями. Для чего тянуть вычисление Условия в рабочие блоки, когда именно тут им и место?

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

Решение, конечно за вами, но прислушайтесь к себе, где логичнее описывать условие раннего выбора? В блоке Согласования, или все же в Условии?

Итак. Второе. Мониторинг

 - тоже, довольно часто игнорируемый инструмент разработчика. Как я успел понять, администраторы его не сильно жалуют, так как у него нет дружелюбного интерфейса как у "Условия", да и плюс к этому каждый раз как Мониторинг срабатывает, он есть ресурсы WorkFlow (цельный процесс на мониторинг!), и если собрать таких мониторингов очень много - он станет проблемой вполне ощутимой. Однако он от того не менее крутой в плане работы на краткие сроки или на специфическую работу.

Лень - двигатель прогресса. И вот в одной из моих задач, я (как администрирующий СЭД) должен был заводить сотрудников в систему. Проблема в том, что у нас есть сценарий, который в ночь обращается в систему Кадрового учета и собирает из него все необходимые данные для этого процесса и утром, сотрудник уже в системе. Однако, после появления такого зверя, как "Сотрудник по договору ГПХ", наша система дала сбой, так как эти пользователи заводятся в кадровой системе абсолютно иначе. Это означало то, что я должен каждое утро проверять, что у нас за сотрудник и был ли он заведен в систему автоматически, или мне надо его завести вручную. Ну, два раза я это сделал, а потом добавил убер-плюшку в маршрут:

Да при этом он еще и простой как 5 копеек:

Вот до чего может довести лень человеческая. Теперь до меня, доходят только задачи, где действительно нужно что-то делать, а проверкой у меня занимается мониторинг с весьма незамысловатым кодом. Как говориться: "Дешево и со вкусом". 

Итак. Третье. Ожидание

Вот мы и добрались до еще одного не самого популярного блока в Типовых маршрутах:

 - самая простая и дружелюбная примочка в работе с маршрутами.

Согласитесь, не всегда очевидно, для чего же нам нужна такая штука, как "Ожидание", но это пока вам не поставят задачу со сроками в дни, недели, месяцы... Да-да, и такое бывает:

Казалось бы - ну и пусть бы висело все 90 дней, жрать же не просит! Однако, за три месяца, в составе согласующих маршрута, могут произойти немалые изменения! Группы могут изменить состав, а роли иногда и по два раза за этот период меняют своего главного пользователя. Так что по завершению ожидания, задача продолжит свой путь по тому списку работников, которые и должны его получить! А висящая задача у кого-то на глазах, так или иначе раздражает. 

Сразу отвечу: "зачем нам 90 дней?" - После запуска какой-то акции, ее эффект можно оценить только по прошествию квартала, и поэтому после 90 дневного перерыва, задача сама упадет на разных аналитиков, где они увидят, кто, что, когда и что из этого получилось.

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

Удачного дня!

Александр Манохин

Тарас, а какая у вас версия DIRECTUM? В 5.5 появился очень полезный блок Пауза, который тоже можно было бы описать, в каком-то смысле, в противовес блоку Мониторинг – некоторые задачи лучше решаются именно с блоком Пауза, т.к. он не нагружает службу Workflow.

Тарас Асачев

Александр Манохин, (4.9.1; 5.0; 5.6; 5.7 )Я с вами согласен,в целом да - можно было бы и заменить. Да и я же не навязываю решение. "ПАУЗА" - тоже отличный блок, со своими примочками 

Александр Манохин

Тарас Асачев, я скорее предлагал не заменить блок мониторинга, а просто также в этой статье описать Паузу, дополнить ее. Тем более, что в справке она как раз сравнивается с блоками Мониторинг и Ожидание

Тарас Асачев

Александр Манохин, думаю это мой личный промах... Не уследил... 

Михаил Тарасов

В одной разработке использовали блок "Пауза" в связке с серверными событиями, как более функциональная замена "мониторингу". Блок "Мониторинг" либо проверяет условия с некоторой периодичностью, либо отслеживает подзадачи с специальным механизмом со своими табличками в БД... Собственно, в головной задаче надо было следить за подзадачами. Использовать периодичные проверки не хотелось, но и сециальный механизм не давал нужного результата. При входе на блок мониторинга в этих специальных табличках фиксируются задачи, перечисленные в параметре. Если в процессе работы блока мониторинга появляется новая подзадача и вносится в параметр ТМ из которого взят список подзадач, отслеживаемых мониторингом, то эта новая задача им не отслеживается. А это было важно. Применение же блока "Пауза" позволило делать проверку не с периодичностью, а при завершении каждой подзадачи и при этом проверять все подзадачи из параметра ТМ...

 

Авторизуйтесь, чтобы написать комментарий