Диалоги. Под микроскопом

Продолжение про функционал диалогов: часть 2 (часть 1). На конкретном примере посмотрим ограничения, которые мешают реализовать данный кейс. Задача проста: с помощью диалога реализовать запрос  информации пользователя, далее  на основе полученных данных сформировать  документ по шаблону (служебную записку) на предоставление доступа к ИС  и направить сформированный документ на согласование по бизнес-процессу. 

И схема создания диалога уже описана в предыдущем примере.

Присаживайтесь, поехали!

Нюанс при создании параметров сущностей

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

Ошибочка вышла!

Ну ок, создать параметры сущностей можно в уже существующих, но желательно, если не сказать - обязательно  указывать описание для каждого параметра, иначе со временем при большом количестве возникнет путаница.  Такая ситуация вполне возможна, если создать  к примеру диалогов 10 и для каждого диалога описывать свои параметры.  Назовем это нюансом,  те. это как бы и не ограничение! Логика разработчиков мне здесь понятна, но соответственно есть и вопрос: а почему нельзя так как на первом скрине? что мешает? Соответственно все параметры сущностей для одного типа формируем в одном месте.   

При  формировании диалога  через  раздел проводника Администрирование - Диалоги сложностей нет. Тут все просто. Приведу пример диалога для нашего кейса - прототип для создания рабочего варианта. 

Конфигурирование диалога

А теперь по сложностям при конфигурировании диалога при создании документа из шаблона:

1. При настройке свойств нет возможности указать шаблон, по которому будет формироваться документ. Я не зря написал, что хочу оформить служебную записку на предоставление доступа. В моей рабочей системе  создано как минимум 3 шаблона для данного типа документа, которые используются сотрудниками при создании документов. При формировании  документа из шаблона  будет создан документ по шаблону,  идентификатор  которого является наименьшим. В данном случае это явный просчет. Разумеется, есть  обходной путь в виде создания шаблона для типа документа, у которого данный шаблон будет один в списке, тогда документ будет формироваться по нужному шаблону, но надо признать, что это фактически "костыли", которые  не устраивают.

К тому же если просто создать параметр в форме диалога и указать его как объект, который будет указывать на  справочник доступных шаблонов, то такая связка не сработает.  Документ будет формироваться только по шаблону по умолчанию.  Или я чего то не знаю. Получается , что например, что такой параметр как  "процесс" указать можно, а такой параметр как шаблон - указать нельзя.

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

Параметры сущности для типа Служебная записка

В  шаблоне указываем  параметры, которые будут связаны в конечном случае с параметрами диалога

В свойствах создания документа из шаблону указываем

И в результате наш формируемый документ получится таким (пример). 

TRUE.. Интересно, как такое будет читать руководитель, который получит  сформированный документ в рамках согласования по бизнес процессу, т.е. с преобразованием выбранных  значений, в данном случае, логических значений,  из диалога в удобочитаемый формат в документе никак не озаботились...  Либо эту возможность допиливать самому..

3.  Конфигурируем параметры задачи. 

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

Для тестового варианта  отработки данного диалога был создан самый простой  вариант процесса, состоящий из одного блока "Уведомление".  И система по нему отработала без ошибок. 

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