Интеграция Activiti

Материал из Course Orchestra
Перейти к: навигация, поиск

Ресурсы

  1. Activiti in Action
  2. Руководство пользователя
  3. Javadoc

Гранула управления процессами

Мониторинг процессов

Развертывание процессов

  • Грид с развернутыми процессами
  • Подчиненный грид с предыдущими версиями
  • Возможность загрузить новый процесс/новую версию процесса
  • Процесс загружается из xml-файла
  • Существует возможность отобразить процесс
  • Существует возможность запустить процесс

Запуск процессов

Мониторинг активных экземпляров процессов

Базовая статистика по реализации процессов

Дизайнер процессов

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

Управление задачами

  • Возможность просматривать перечень задач
  • Возможность просматривать свои задачи
  • Возможность выполнять задачи
  • Возможность работать с задачами вида "взять на исполнение"

Конструктор форм

  • Возможность создания форм и их инициализации по идентификатора
  • Возможность прописывать правила мэппинга форм на переменные процесса

Работа с документами

Требования к интеграции движка в showcase

  • (+) Скрипт jython должен получать ссылку на объект ProcessEngine
  • Должны поддерживаться задачи вида.
<scriptTask id="theScriptTask" name="Execute script" scriptFormat="python">
  <script>
    sum = 0
    for ( i in inputArray ) {
      sum += i
    }
  </script>
</scriptTask>

При этом должна обеспечиваться возможность доступа из скрипта к celesta-connection.

  • (+) Хотелось бы предыдущую задачу решить, как минимум, в упрощенном виде и передавать соединение к СУБД
  • Должен обеспечиваться мониторинг события создания пользовательской задачи и запускаться celesta-скрипт

Интеграция с БРС

  • Требуется доработать подсистему обращений.
    • Необходимо в обращении добавить ссылку на act_ru_task (без вторичного ключа).
    • Требуется создать два новых вида обращения.
      • (необязательный) Позволяет просто сказать: выполнено
      • Позволяет при выполнении указать: документ согласован или не согласован. В обоих случаях можно сделать примечание.
    • Если с обращением связана задача activiti, необходимо инициировать ее закрытие. При этом требуется заполнить переменные процесса требуемыми значениями. Предварительно предлагаю заранее заложить следующие переменные: not_approved, not_approved_comment, approved_list (массив: пользователь, отметка о согласовании, комментарий)
    • Если с обращением связана задача и у нее определяется конкретный исполнитель (взять на исполнение), он должен назначаться и в задаче activiti
  • Требуется развернуть таблицы activiti а БД dbVector
  • Требуется поставить триггер на act_ru_task, который создает связанное обращение (если получится, то не через триггер, а через вызов обработчика события).

Доработки, связанные с реализацией статусной модели

Для каждого документа, требующего согласования, используется следующая базовая статусная модель:

  1. Подготавливается
  2. На согласовании
  3. На доработке
  4. Согласован

Данные могут быть изменены только в статусах «подготавливается» и «на доработке».

  • Требуется реализовать в приказах и учебных планах кнопку: запустить на согласование. Это кнопка запускает последнюю версию процесса согласования для данного типа/основания приказа или учебного плана.
  • Если приказ/план находится статусе "на согласовании", то кнопка Запустить на согласование заменяется на "Статус согласования". При нажатии на эту кнопку отображается процесс и место текущего согласования.
  • В случае, если согласование не прошло, необходимо выставлять статус "на доработке". С точки зрения разграничения прав доступа он аналогичен статусу "Подготавливается"

Доработки, связанные с отслеживанием версий

  • В момент создания документа ему присваивается уникальный цифровой код_лист согласования.
  • Уникальный цифровой код содержит 21 символ и формируется по стандартному алгоритму Вектора.
  • Для проекта документа (статус Подготавливается) лист согласования = 0.
  • Пример уникального цифрового кода проекта документа 001113082620105497026_0
  • Уникальный код на бумажной версии документа всегда присутствует в виде цифрового кода и QRCode.
  • Кодировка листа согласования в уникальном коде документа начинается в момент передачи изменения статус «На согласовании».
  • Для кодирования листа согласования используется следующий подход: префикс подразделения[Кол-во прохождений(3 символа)][Согласован (0/1)]
  • Если документ проходит согласование в нескольких подразделениях в кодирование листа согласования добавляется несколько подразделений: [префикс подразделения, осуществившего возврат][количество прохождений][ [Согласован (да/нет)]].[префикс другого подразделения][количество возвратов] [Согласован (да/нет)]
    • Например, если приказ дважды проходил через деканом, был им согласован и переведен в УМУ на согласование, он будет иметь код:

001113082620105497026.д21.у20 (в данном случае «д» – декан, «у» – УМО)

    • Буквы определяются параметрами настройки процесса

Требования к реализации процесса согласования

  • Необходимо определить, кто делает согласование в системе для учебных планов и для приказов. На начальном этапе я предлагаю просто для каждого вида согласования указывать набор кандидатов, например, "Проректор по учебной части": пользователь 1, пользователь 2. В данном случае можно указать самого проректора и его секретаря.
  • На начальном этапе лучше всего каждое согласование изображать в виде действия и с помощью шлюза выбирать дальнейший путь действия (как в подготовленном для ДС примере)
  • В результате реализации процесса необходимо изменять статус согласуемого объекта. Это необходимо скриптом. Для этого необходимо, чтобы showcase в скрипт передавал соединение к БД