Нужно решить следующую задачу:
1. Создать новое рабочее место и раздел в нем.
2. На странице раздела должен выводиться список кастомных объектов, каждый из которых имеет id (внешний, не тот который в базе bpmonline), название и ссылку (должна быть кликабельна). Объекты должны подгружаться со стороннего API.

Первый пункт проблем не доставил. А вот второй... Я сам являюсь одним из разработчиков того стороннего API, поэтому сначала возникла идея просто выводить таблицу внутри айфрейма, однако руководство поставило задачу сделать более "умным" способом.

Я решил попытаться сделать деталь с пользовательскими полями по туториалу (https://academy.terrasoft.ru/documents/technic-sdk/7-10/sozdanie-polzova...) версия системы у меня 7.10б однако, следуя примеру, родительским объектом детали следовало указать Base fields detail из пакета BaseFinance, но у меня он не установлен, и не понятно, установить его, или же не стоит тащить целый пакет ради одного объекта. Пытался по-другому создать делаь и вывести список на страницу раздела, но ничего так и не получилося.

После создания детали и добавления списка на страницу раздела, планировал при загрузке страницы посылать AJAX-запрос по API, потом с помощью службы DataService вытащить существующие объекты, сравнить с получены ответом, и с помощью этой же службы удалить неактуальные и добавить новые, и таким образом обойтись без конфигурационных сервисов, так как совсем не знаком с языком С#.

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

Нравится

2 комментария

Я думаю вам правильнее будет сделать самый обыкновенный раздел мастером разделов на основании объекта, с текстовой колонкой для ссылки, и с текстовой колонкой для внешнего id (если он guid), или числовой, если число.
Сделать несколько доработок что бы ссылка была кликабельной и вела во внешнюю систему.

А наполнять данный раздел с помощью интеграции. И тут открывается множество вариантов. Будь то запрос во внешнюю систему, с переодичностью. Либо внешняя система будет сохранять данные в bpm посредством odata каждый раз как таковые будут там созданы. Либо написать веб сервис в bpm и вызывать его из внешней системы. С вариантами интеграции можете ознакомится здесь:
https://academy.terrasoft.ru/documents/technic-sdk/7-10/integraciya-s-s…

"Максим Шевченко" написал:

Я думаю вам правильнее будет сделать самый обыкновенный раздел мастером разделов на основании объекта, с текстовой колонкой для ссылки, и с текстовой колонкой для внешнего id (если он guid), или числовой, если число.

Сделать несколько доработок что бы ссылка была кликабельной и вела во внешнюю систему.

А наполнять данный раздел с помощью интеграции. И тут открывается множество вариантов. Будь то запрос во внешнюю систему, с переодичностью. Либо внешняя система будет сохранять данные в bpm посредством odata каждый раз как таковые будут там созданы. Либо написать веб сервис в bpm и вызывать его из внешней системы. С вариантами интеграции можете ознакомится здесь:

https://academy.terrasoft.ru/documents/technic-sdk/7-10/integraciya-s-si...


Спасибо, буду смотреть и пробовать.

Показать все комментарии

Добрый день. Мне поступила задача создание раздела для автоматизации работы по дебиторской задолженности. Получил макет того что хотят от меня руководство но по моим представлениям не вписывается в в интерфейс и стандартные механизмы работы црм. Подскажите стоит ли изменять стандартные расположения вкладок обойтись практически без деталей а все запихать в карточку редактирования как это желает разработчик макета или стоит с ним поспорить и как объяснить что так будет не совсем правильно. Макет карточки в приложенных файлах.

Нравится

8 комментариев

Насколько я понимаю, что чем больше полей в карточке, тем медленнее она будет открываться (прорисовать все поля + все данные закачать из базы). Причем, это может быть критично.

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

Плюс деталей в том, что можно быстро посмотреть определенную информацию, не открывая карточки.
Минус в том, что работая с карточкой, приходится переключаться между окнами (при этом карточка уходит в background за окно реестра).

Помещая детали дополнительно в карточку, сталкиваемся с замедлением работы.

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

Как раз в прикрепленном файле вид карточки. Да и как раз получается что в карточке будут отображаться многие записи привязанные к той записи раздела дебитора. Вот думаю что это значительно замедлит открытие карточки.

Решать, конечно, Вам, но видно, что отображенные Вами закладки дублируют детали.
Соответственно - имеет ли смысл их дублировать в ущерб быстродействию?
Что касается удобности заполнения данной карточки - можно создать бизнес-процесс, отвечающий за пошаговое открытие карточек (как основной, так и деталей).
Что касается удобности работы - фактически без разницы - будут ли пользователи переходить по закладкам в карточке или по закладкам в деталях.
Для оптимизации рабочего места можно ограничить посредством TS Admin количество отображаемых по умолчанию деталей.

Или заполнять страницы карточки по необходимости, а не при ее открытии

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

Показать все комментарии