В процессе переезда в одном из наших решений на новый аддон Bproc хотелось получить больше гибкости: дать возможность пользователям значительно модифицировать существующие процессы и создавать новые без вмешательства к код приложения, чисто на уровне конструктора моделей. Причем создавать процессы как интегрированные с сущностями приложения, так и “отвлеченные” от основного назначения приложения.
С виду в новом аддоне для этого несравненно больше возможностей:
- Можно создавать в конструкторе процессы, интегрированные с сущностями и экранами приложения.
- Для процессов прямо в конструкторе создать простые процессные формы и формы для задач.
- Можно просто использовать в качестве процессных форм существующие экраны редактирования сальностей, реализованные в приложении. Порой это очень полезно.
И все это очень здорово, но заточено под сценарий использования “пойди на экран запуска процессов, запусти процесс и он на экране запуска заставит ввести тебя все нужные данные, выбрать файлы и сущности и т.п.”
Но такой use-case удобен далеко не всегда.
Есть множество процессов, которые должны стартоваться с уже открытого экрана редактирования сущности и с экрана сущности должны отрабатываться процессные задачи:
- Это классические сценарии типа “согласование/разработка документа”
- Процессы типа обработки различных заявок
- Работа с договорами.
- …
Сущность со значительным обвесом уже есть, в какой-то момент, работая с экраном пользователь должен стартануть процесс.
При этом в инстанс процесса нужно передать ряд атрибутов сущности и часть параметров дать заполнить вручную, возможно, провести стандартные для сущности или типа процесса верификации до старта.
И вот тут есть ряд неприятных моментов…
Я изучил близкие о смыслу старые темы:
Bproc. Переменная типа “Entity list” и параметр формы - Вопросы и проблемы - CUBA.Platform (cuba-platform.ru)
Передача параметра в Бизнес-процесс - Вопросы и проблемы - CUBA.Platform (cuba-platform.ru)
Но до конца картинка так и не сложилась: или реально в аддоне не хватает некоторых возможностей, либо они есть но я их не вижу/не осознаю.
Сценарий работы, который хотелось бы реализовать на примере всем понятного процесса “согласование документа”.
Но тут “Документ” это не просто файл, а сущность (Письмо, Договор, Акт, Ком.предлжение и т.п.) со значительным обвесом в виде Файлов, связанных Документов, обсуждений и т.п.
- Процесс должен стартоваться с экрана редактирования сущности.
- При этом надо всегда передать в переменные процесса “согласуемую сущность”, приложенные к ней файлы (сопроводив опционально файлы комментарием на стартовом экране).
Остальные параметры формы запуска нужно определять в конструкторе процессов. - Часть параметров процесса заполнить умолчательными значениями и дать редактировать их на экране запуска (списки исполнителей задач, дедлайн процесса или отдельных задач и т.п.)
- В зависимости от класса сущности провести до запуска процесса некие верификации. Например, если согласуемая сущность Договор, то в Договоре обязательно должны быть заполнены поля Сумма и Срок.
- Запущенный процесс надо отображать на экране редактирования сущности, для которой он запущен. И там же отображать кнопки активных задач для данного пользователя.
- Форма задачи должна давать возможность не только указать outcome, но сопроводить его комментарием (обязательным или опциональным в зависимости от outcome) и опционально приложить свою редакцию фалоа(ов) документов.
В идеале нужна возможность добавить в конструкторе процессов для конкретной задачи процесса на форму дополнительные параметры, которые пользователь будет заполнять на форме.
С пунктом 1 и 5 проблем нет. Легко накидал фрагмент экрана, который отображает доступные пользователю процессы, дает возможность выбрать процесс, запустить его, а при наличии активного процесса для сущности отображаемой на экране - показывает активные задачи для данного пользователя и позволяет из штатно исполнить.
Хотя, поддержу тут @sergeevms.33 - хорошо бы иметь штатную возможность в Конструкторе определить то, для каких сущностей применим процесс. В своих пожеланиях 2 года назад он писал про нечто вроде справочника, в котором можно было бы определить без хардкода применимость того или иного процесса для той или иной сущности.
А вот с Process Form и Task Form пока не вытанцовывается нормальное решение…
Тип формы Input dialog дает возможность в конструкторе описать практически все варианты параметров формы, но:
- UI очень аскетичный
- При запуске процесса с такой стартовой формой я не могу передать в нее нужные параметры. Например, согласуемую сущность, файл, типовой список исполнителей задачи и т.п.
На форме задачи не могу затребовать обязательный комментарий для определённого outcome и т.п. - Верификацию полей сущности до запуска процесса тоже не поучится сделать.
Но оно и логично, т.к. этот тип экрана для простых типовых случаев.
Тип формы Cuba screen не вариант уже потому, что в этом случае в конструкторе вообще нельзя определить свои специфичные для процесса или задачи параметры. Тут подразумевается, что все определяется кодом со стороны экрана.
Custom process/tasks forms вроде как раз наш случай - когда надо отобразить форму своим нестандартным образом.
Есть API для получения параметров форм, заданных в конструкторе в модели процесса.
Если я запускаю процесс со своего фрагмента на экране редактирования сущности, то могу передать в него нужные мне параметры (согласуемую сущность, файлы и т.п.) и их затрамбовать в переменные процесса. Еще до запуска процесса могу провести стандартные верификации согласуемой сущности.
Т.е. с виду остается сделать кастомные экраны для запуска процесса “Согласование документа” и задачи “outcome согласования”, реализовать в них нужную “железобетонную часть логики процесса”, типа предварительной проверки сущности и передачи в параметры процесса согласуемой сущности и ассоциированных с ней файлов, возможности приложить к файл к outcome и т.п.
И читая заказанные в процессе параметры форм через getStartFormData и getTaskFormData - динамически отрисовывать остальные параметры экрана для Конкретного варианта процесса или Конкретной задачи процесса. Т.е. аналогично Input dialog но с нужной спецификой UI и тонкостями.
Но если для формы типа Input dialog в конструкторе процессов можно очень детально описать параметры процесса, включая тип данных, обязательность заполнения и многое другое, что относится к отображению их на форме, то для Custon form, задавая параметры формы в конструкторе я могу только указать Имя параметра и его значение или источник значения.
Если описания параметров параметров кастомной формы настолько куцые, то получается, что Типы данных- этих параметров, обязательность параметра и т.п. - все это должно быть прибито хардкодом в этой кастомной форме?
И тогда мы опять теряем возможность серьезно модифицировать процессы чисто на уровне конструктора, без изменения кода.
Ведь добавление задачи в процесс - это добавление новых параметров задачи, новых переменных процесса. Но в случае кастомной формы я могу задать только имя параметра, тип и обязательность я задать не могу, и в итоге, на базе этих данных о параметрах формы не смогу отрисовать UI в кастомной форме. Ведь я знаю только имя нового параметра новой задачи, но даже не знаю его тип.
@gorbunkov Почему для кастомной формы так сильно урезаны возможности описания параметров формы относительно того же Input dialog?
Я ожидал увидеть те же возможности описания параметров в конструкторе, что и в Input dialog, а в своем кастомном экране отрисовать UI так, как мне нужно, с нужными верификациями, прописав еще и общую для процесса логику передачи части полей сущности в параметры процесса, дефолтного заполнения некоторых параметров процесса и т.п. тонкости.
И пока не понимаю желаемой реализации, с сохранением возможности значительно модифицировать процессы на уровне конструктора, без изменения кода приложения.
