Реактивная привязка к данным, или инициация принудительной загрузки/отрисовки
В большом количестве юзкейсов очень удобно использовать бизнес-процессы.
Но так-же с этим связана весьма существенная проблема:
Если бизнес-процессом были затронуты какие-то данные, например изменен статус обращений, и у пользователя на момент его выполнения была открыта страница соответствующего реестра, то данные в нем не отобразятся пока пользователь принудительно не обновит страницу или не прогуляется в другой раздел.
Каким образом можно обеспечить "реактивную привязку к данным"
(для SPA приложений это уже как стандарт де-факто иметь такую функциональность)
Ну и даже если это невозможно, то как инициировать по факту окончания отработки бизнес-процесса инициировать принудительное обновление данных у пользователей ?
Нравится
Здравствуйте!
Добавьте элемент "Открыть страницу редактирования". В результате выполнения элемента у пользователя откроется страница с новыми значениями.
Также хочу обратить внимание, что расчет значений в бизнес-процессе - это трата ресурсов сервера. Аналогичные действия можно выполнить на странице редактирования кодом.
Для того чтобы открыть страницу редактирования, необходимо ее указать, в то время как у пользователя может быть открыт как реестр (раздел) где измененные значения выведены в колонках, так и сама непосредственно карточка, и какую открывать страницу редактирования - не ясно.
Да и вообще не желательно пользователям что либо открывать, когда работают фоновые процессы, они могут довольно большое количество раз отработать за сравнительно небольшой промежуток времени.
Вопрос стоял в том, как из кода, в идеале из JS - инициировать, ререндеринг целевых элементов, ну или в крайнем случае страниц.
:smile:
Также хочу обратить внимание, что расчет значений в бизнес-процессе - это трата ресурсов сервера. Аналогичные действия можно выполнить на странице редактирования кодом.
ну на то он и сервер :) клиентские ресурсы само приложение и так "не слабо" задействует :)
Вот типичный пример илюстрирующий проблему.
К типовым обращениям добавлена некая логика, которой кстати непонятно почему нет в типовом решении, ну да ладно.
Реализуем статус "Прочитано/Не прочитано" на сообщениях, а так-же вводим сущность которая описывает содержит ли обращение одно или несколько непрочитанных сообщений.
Итого получаем некое поле для объекта Case для удобства пользователей значение которого выведено в колонке реестра:
Ну соответственно поле у активности с типом Email, которое так-же выведено в колонках соответствующей детали.
Поступление новых сообщений и установку соответствующих статусов производит бизнес-процесс, карточка же самой активности расширена таким образом чтобы при ее открытии, менялся статус на "Прочтено" если не было до этого, а так-же запускается бизнес процесс, который проверяет есть ли еще у этого обращения связанные с ним непрочитанные email, если их нет устанавливает самому обращению соответствующий статус.
Так вот открываем сообщение из карточки - последнее непрочитанное.
И закрываем его - логика отработала, значения в базе изменены, но что мы видим - в детали как были значения так и остались, закроет карточку - в реестре ка были значения так и остались и только перезагрузка страницы обогащает их изменившимися данными.
Здравствуйте!
Вариант решения:
1. В процессе сгенерировать сообщение по Web-socket.
2. В схеме страницы редактирования подписаться на сообщения.
3. В методе “прослушки” сообщения вызывать метод который обновит страницу и отобразит актуальные данные.
Обновить страницу редактирования:
reloadEntity() – refresh page
Обновить реестр детали:
- this.updateDetails()
- this.updateDetail({detail: "DetailName"}); - где DetailName имя детали
Пример генерации и подписки на сообщение рассмотрен на форуме - http://www.community.terrasoft.ru/forum/topic/11784