...

Автоматическое завершение параллельных задач

Тема в разделе "Вопросы по функционалу", создана пользователем Turuhansky, 25 фев 2021.

  1. Turuhansky

    Turuhansky Member

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

    Вложения:

  2. Turuhansky

    Turuhansky Member

    Есть идея создать переменную типа "Временной интервал" и назначить ее в качестве переменной таймера на переходах для отказа. Сейчас проверил, выставив на этапе инициатора 1 минуту, спустя назначенное время задачи утекли в шлюз сами. Вроде бы хорошо, но минимальный отрезок у переменной 1 минута. Можно ли с помощью сценария выставить этой переменной 1 сек?
     
  3. Turuhansky

    Turuhansky Member

    Проглядел, нужно было запретить переменной иметь пустое значение, тогда 0мин по умолчанию.
    Можно считать вопрос закрытым.
     
  4. Turuhansky

    Turuhansky Member

    Рано радовался. Этот прием в будущем пригодится конечно, но для озвученной ранее задачи абсолютно не годен.
    Идеальный вариант из базы знаний вот этот: https://www.elma-bpm.ru/KB/article-5998.html
    Но он прерывает лишь одну параллельную ветку, а таких параллельных задач потенциально может быть несколько.
    В принципе можно использовать сценарий прерывания всего процесса, тем более что в нашем случае при отказе любого участника дальнейшее движение документа вообще не предусмотрено. Я задам странный для многих вопрос, просто я не знаю, злоупотреблять экстренными прерываниями можно?
     
  5. Приветствую! Не могу спокойно смотреть, как вы общаетесь сами с собой. Но я тоже сейчас в таком же положении ))
    Поэтому, хоть пока еще я и не спец в Элме, решил вас поддержать ;)

    По вашей схеме не до конца понял суть процесса.

    Принцип "отказал один - отказали все" понятен. А по другим состояниям как?
    Если один отправил на доработку - отправили все, если один согласовал - согласовали все. Так?

    Вопрос второй. Чем обусловлено использование нескольких задач для одной зоны ответственности? Я же правильно понимаю, что если все Замы входят в зону ответственности "Зам 1", то достаточно одной задачи, которая будет приходить всем замам сразу. И при выборе любым из этих замов одного из переходов, задача будет считаться выполненной.
     
  6. Да, я имел в виду динамическую Зону ответственности с использованием механизма "Кто первый".
     
  7. Turuhansky

    Turuhansky Member

    Добрый день, спасибо..)

    Нет, у меня не динамическая зона. Я сделал 5 статических зон ответственности, задачи для которых одновременно раздаются от инициатора между двумя неисключающими шлюзами. Пяти или менее исполнителям по желанию.

    Задачу все назначенные исполнители выполнять могут одновременно и независимо друг от друга. Эту задачу должны обязательно выполнить все назначенные исполнители и у каждого может быть свое решение. Если хотя бы один затребовал доработку, то после закрывающего шлюза, даже если у других замечаний нет, задача уходит на доработку. Если одобрили все, то уже далее по финальному маршруту к конечному исполнителю (секретарю например), который в своей задаче видит все принятые решения. Тут проблем нет.

    Но встал вопрос об отказе. Если кто-то один этот отказ инициировал, то ждать решения остальных нет смысла, документ уже отказан. Но шлюз-то ждет, потому что в этом случае могут висеть в работе еще несколько задач. Их нужно закрыть разом, чтобы не ждать бесполезного решения остальных участников, которые уже ни на что не повлияют.

    Поэтому либо сценарий https://www.elma-bpm.ru/KB/article-5998.html (но он может закрыть только одну задачу между шлюзами и мне не подходит), либо прерывание процесса отказником. С рассылкой уведомлений остальным участникам. Это я уже сделал c помощью сценария https://www.elma-bpm.ru/KB/article-5538.html , повесив его в каждую задачу на кнопку "Отказать".
    Но мне интересно на всякий пожарный, любит ли ELMA подобные частые фокусы. Вопрос нуба наверное, но такие тоже приходится задавать.. =)

    Насчет динамических зон, при механизме "кто первый", задачу получают все, кто указан в настройках зоны. Что само по себе плохо, потому что исполнители заранее неизвестны. К тому же при выполнении задачи любым из них, задача снимается. Может быть я мало внимания уделил динамическим зонам, но база знаний говорит об этом. Мне кажется в моем конкретном случае статические зоны дают больше свободы действий.
     
    Последнее редактирование: 2 мар 2021
  8. Да, теперь стало понятно. Действительно, механизм "Кто первый" тут не годится. И вообще задачка не из простых.
    Идея с эскалацией по временному интервалу хорошая, и странно, что не подошла.
    Завтра попробую копнуть в эту сторону, вдруг получится. Самому стало интересно, да и в будущем пригодится.
    Насчет прерываний могу сказать, что пользовался подобным механизмом в другой BPM-системе, там было примерно по 1000 прерываний процессов за сутки. И до сих пор работает без проблем. Но всегда хочется более элегантного решения. ))
     
  9. У меня всё получилось. Правда, я не стал делать "Возврат на доработку", но в целом всё как надо. Отказал один - все задачи в течении 10 секунд завершаются автоматом, иначе же процесс ждет согласования всех троих.

    Делал так:
    1. Создал контекстную переменную для признака автоматического завершения Reject (тип Да/Нет, по умолчанию false)
    2. На ветке "Отклонить" поставил сценарий, в котором происходит установка Reject в "Да":
    Код:
    public virtual void RejectFix (Context context)
    {
        context.Reject = true;
    }
    3. Помимо веток "Согласовано" и "Отклонить" сделал третью безымянную ветку, в настройках которой указал эскалацию по Сценарию. В появившейся вкладке "Настройки сценария" создал новый сценарий RejectCheck и установил период проверки сценария 10 сек.
    Текст сценария такой:
    Код:
    public virtual bool RejectCheck (Context context)
    {
        return context.Reject;
    }
     

    Вложения:

    1 это нравится
  10. Turuhansky

    Turuhansky Member

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

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

    p.s.
    Хотя зачем в копилку, я ж в тест сдал. Пока щупают, я подправлю. Еще раз спасибо.
     
  11. Ну вот, одна голова хорошо, а две - лучше! ;)
     

Поделиться: