В NodaLogic добавились чаты и мессенджинг в широком смысле (как доставка сообщений и как пользовательские чаты) и это имеет целью стереть границы между классическим интерфейсом работы с бизнес-процессами и лентой чата, создать глубоко интегрированную пользовательскую среду работы с документами и событиями, а в будущем – переиспользование этой инфраструктуры для LLM. Кроме того инфраструктура обмена сообщениями используется для обмена между объектами и обработчиками, а не только в "человекочитаемых" чатах что позволяет разработчику избавиться от многих забот по организации обменов данными и представляет из себя своеобразную шину данных.
Перечислю коротко основные особенности и факты по мере нарастания интересности:
Интерактивные объекты в чатах
В чаты (p2p и групповые) можно кидать любые объекты (в NL любые объекты называются «узлы») - документы, задачи и т.д. и работать с ними там. Это полноценные формы документов или справочников, такие же как в обычном интерфейсе. Также принятые объекты просто отображаются в отдельном списке вне чатов (типа как папка «Загруженные»)
Можно работать, не заходя в объект – вытащить на обложку любые элементы. Активные элементы обложки вызывают события, обработчики меняют данные. Объект обновляется у участников группы или p2p чата мгновенно (для этого используются специальные служебные сообщения) и также мгновенно отображается.
Дискуссии по объекту
Можно вести дискуссию по объекту. Это просто сообщения, привязанные к объекту которым поделились. За счет API это можно встроить во внешние системы также.
Объекты из внешних систем
В чат можно кидать объекты за пределами своей информационной системы, не как условно PDF – а именно объект с активными формами, обложкой, бизнес-логикой, обработчиками, хранением и т.д. Даже если ваша система не NodaLogic Вот статья об интеграции с 1С – решение для коммуникации на полном автомате: в 1С на лету генерируется разметка и логика: https://infostart.ru/1c/tools/2682705/
Как это работает:
В NL такая архитектура, что узлы (объекты, документы) всегда выполняются локально, т.е. например устройство не просто отрисовывает, а и хранит данные и исполняет
Но при этом есть сервер и синхронизации с ним.
Когда вы делитесь узлом внутри NodaLogic вы можете выбрать Share by link тогда вместе с данными узла уйдет просто ссылка на класс (имя класса в конфигурации), ведь у получателя и на сервере уже есть эта конфигурации, в ней есть класс, а в нем все необходимое для работы узла
Но узлом можно поделиться в режиме Package class. Я называю это «самостоятельные объекты» или «все свое ношу с собой». Это по сути JSON в котором есть класс с разметкой и обработчиками, данные и прочие необходимые поля. Им можно поделиться изнутри клиента (пока только мобильная платформа)
В результате возникает ссылка download_url и дальше уже система работает с ней.
В примере с 1С этот объект пассивный – т.е. участники просто пишут данные в объект, он обновляется (его _data) по ссылке и его всегда можно качнуть по этой ссылке, забрать данные. Т.е. такой расшаренный JSON. Но это не единственный вариант, см. далее.
API обработчиков и внешних систем
То что было до этого – это пользовательский базовый уровень - то есть обмен сообщениями между людьми. Но в системе живут процессы у которых есть события и обработчики и интеграция конечно же касается их. Под словом «живут» я подразумевал то, что узлы самостоятельно выполняются на клиентах, это отличие NL от подобных систем, но также может быть задействован и сервер, поэтому далее рассмотрена интеграция на разных уровнях раздельно. И это, обработчики и методы сообщений – пожалуй самое интересное, потому что это и делает систему живой. Так, возможен обмен сообщениями между узлами и "человеческими чатами" и узлами между собой невидимыми Data-сообщениями. И это все как на уровне "клиент-клиент" так и на уровне "сервер-клиент"
HTTP API
Есть REST API для внешних систем для размещения узлов и ведения в них дискуссий
POST /api/user/<username or group>/nodes-message – отправка узла «все в одном» - узел деплоится, т.е. получает свой url и дальше уже отпарвляется сообщение пользователю или группе. Для группы формат group:<group_id>
POST /api/node-discussion/by-node/<path:node_id>/messages отправка сообщение в дискуссию по узлу.
GET /api/node-discussion/by-node/<path:node_id>/messages получение всех сообщений в дискуссию по узлу.
Функции и обработчики событий уровня клиент
Функции для отображаемых сообщений
Из обработчиков можно писать «человеческие» - т.е. отображаемые сообщения как в чаты так и в дискуссии по узлу
Так как в NL в обработчиках на выбор 2 языка – python и собственный NodaScript то пишу примеры по обоим, сигнатуры методов одинаковые. Этот пост можно сразу читать как документацию.
В получателях можно указывать как логин получателя (p2p-чаты) так и группу в формате group:<ид_группы>
sendTextMessage(String target,String text) оправка текстового сообщения
sendImageMessage(String target, String text, String filename) отправляют картинку или картинку с подписью. Картинка – ссылка на s3.
sendNodeMessage(target,id) – отправляет сам узел в чат
sendTextToNodeDiscussion(NodeEx node,String text) – отправка сообщения в дискуссию по узлу
sendImageToNodeDiscussion(NodeEx node,String text, String filename) – отправка картинки в дискуссию по узлу
Обработчики уровня узла на клиенте (в формате событие/listener)
onInput/onDiscussionMessage – событие появления в дискуссии по узлу сообщения. В _data попадают переменные:
"_message_text" – текст сообщения
"_message_image_url" -картинка если есть
"_message_sender_user" – отправитель
"_message_sender_user_display_name" – отправитель, отображаемое имя
В python-обработчиках также у объекта-узла доступны:
self._deploy(self) - опубликовать/обновить узел в режиме "самостоятельного узла"
self._send(self,target) - опубликовать и послать узел получателю
Data-сообщения
Было бы кощунством не переиспользовать инфраструктуру доставки, кеширования т.д. и т.д. для обмена сообщениями между обработчиками. И я конечно же сделал это. Это мощная штука – по сути не надо заботиться об инфраструктуре гарантированной доставки(очереди, кеширование, ack/pending , адресация на устройства и т.д.) а просто написать 1 команду и указать получателя. В отличии от WebSocket например – не держит радиоканал, а получает данные от FCM (и pending если не было связи).
Например рассмотрим сборку товара по одному заказу или строке заказа разными сборщиками: от "пикают" товар и как только они пикнули - отправляют данные к этому узлу на другие устройства (для более двух можно использовать "групповой чат") и все - сообщение помещается в очередь доставки, как будет связь оно дойдет до всех устройств получаетеля, вызовет событие узла onInput в котором прописано что то наподобие "обновить таблицу товаров на экране"
sendDataToNode – отправка произвольных данных (json) в узел на стороне получателя. Сообщение не отображается в чатах, по нему срабатывает событие узла onInput c listener = onDataMessage в котором приходят в data переменная message_payload – туда приходит то, что указано в payload
payload= {"action":"я нажал кнопку"}; sendDataToNode("_server",_data.my_node,payload)
sendDataToConfiguration(String target, String configurationUid, JSONObject payload) – отправка произвольных данных не узлу а целиком конфигурации. Предполагается, что у получателя стоит конфигурация, которая будет принимать сообщения (как правило это та же, что и у отправителя, но не обязательно) и в ней прописано общее событие onDataMessage – входом для него будет payload, который отправил отправитель. Напомню, что немного по-разному python-обработчики и NodaScript обработчики устроены: для NS это будет просто data, а для python это будет параметр функции inputdata
Функции и обработчики уровня Сервер. Чат боты.
В рассмотренном выше примере сборки заказа и обмена сообщениями между пользователями в одноранговой сети есть недостаток - не хватает оркестрации. Лучше сделать схему клиент-сервер-клиент. Т.е. пикнули товар на клиентском устройстве, отправили на сервер, сервер проконтролировал логику выполнения, возможно пообщался с внешней системой, возможно заказ уже собран и надо всех оповестить/выдать другую задачу. В общем, я к тому, что если надо ввести в это уравнение сервер то это делается проще простого.
В сообщении sendDataToNode можно указать предопределенное "_server" в target и тогда оно не пойдет дальше сервера. Собственно если узел хранится на сервере то обратиться к нему можно и напрямую, без системы мессенджинга, правда например может не быть связи… Но дело даже не в этом. Дело в том, что узел может не стоять на сервере. Помните в самом начале – узлом может поделиться внешняя система, это по сути JSON имеющий url для доступа и ничего более. Как же он может принять и обработать сообщение?
Оказывается может точно также как и с узлом из конфигурации. Но есть нюансы – так как это узел не развернут то и python-модули обработчиков не развернуты. Для этого случая обработчики надо писать на специальном portable-скрипте python, в системе он называется PythonScript. В чем суть? Вы пишете как скрипт обработчика в окне конфигуратора, потом он сохраняется в виде s3-ссылки (он и доступен по ней, она публичная). В класс упаковывается ссыка на скрипт, когда надо выполнить – она достаётся из s3. Естественно, оно кешируется как и сам узел в download_url чтобы не скачивать по новой каждый раз.
В итоге узел получает onInputServer/onDataMessage уже на сервере
И также сервер (по той же схеме) может перехватывать сообщения в дискуссии по узлу. По сути узел на сервере может быть своеобразным чат-ботом - перехватывать всю переписку и писать по мере надобности в чаты.
Сервер можно подписать на событие по каждому сообщению в переписке по узлу (событие уровня узла) onInputServer/onDiscussionMessage и соответственно сервер через message_text видит что вы ему написали.
При этом узел на сервере сам может писать в чаты:
sendTextMessage(target: str, text: str)
sendImageMessage(target: str, text: str, filename: str)
sendTextToNodeDiscussion(node, text: str)
sendImageToNodeDiscussion(node, text: str, filename: str)
Некоторая техническая информация
Серверная часть написана на python и доступна на Github (ссылки в конце статьи), т.е. можно скачать и развернуть у себя – это вместе с всей остальной базовой функциональностью NodaLogic – сервером узлов, веб-клиентами, конфигуратором. Если этого не делать – то все проходит через nmaker.pw. Тогда данные будут все у вас – узлы, сообщения. Но есть работа с Firebase Messaging она только на стороне nmaker так как учетка храниться там. Т.е. единственное, что недоступно – это отправка пушей. При схеме «сервер у вас» вам просто надо будет пинать nmaker чтобы он отправил пуш.
Еще в этой схеме широко используются s3-хранилище – для изображений и для обработчиков. Тут такая схема – для безопасности это обернуто в серверное API, т.е. на клиенте не хранятся ключи доступа к s3 на запись (предполагается что на чтение ключей не надо – оно публичное, если нет, нужно добавить авторизацию и на чтение). Клиент получает временный токен, записывает с ним данные и получает ссылку. В nmaker свое хранилище, если вы будете разворачивать свой NL-сервер, вам понадобится также s3-хранилище (в случае, если вы будете использовать PythonScript обработчики или картинки) и надо будет прописать данные своей учетки в boto3.client
Что дальше к этой функциональности?
Есть инфраструктура чатов (человеческих) и обмен сообщениями между обработчиками и объектами. Данные не надо доставать запросами – единообразная структура БД – JSON/NoSQL все решения строятся из одного кирпичика – «узла». Узлы могут читать сообщения как на уровне устройств так и на уровне сервера. И писать. И кидать картинки. И все это можно развернуть локально без утечки данных в облака… Ничего не напрашивается? Конечно же привинтить LLM к этому – как локально так и на устройствах. В виде тех же узлов-чат-ботов которые имею доступ к данным, событиям и интерфейсам и могут оперативно реагировать на события в реале.Ну и с ними можно переписываться в чатиках. Кстати, интерфейсы в NL изначально могут реагировать на события из фона/сервера что было сделано как раз для такого рода интеграции. Это следующий шаг, уже больше не на уровне платформы (в платформе для этого все есть), а на уровне прикладных решений. Ну и ждем Gemini Nano для Android чтобы локально работать с узлами на устройствах без интернета.
Также до сих пор не реализованы некоторые моменты из запланированного – например сквозное шифрование. Что несколько нивелируется что система может быть развернута на своем сервере и передача по https.
Ссылки
Статья по NodaLogic в целом: https://habr.com/ru/articles/1011090/
GitHub, чтобы развернуть локально (конструктор+сервер+веб-клиенты): https://github.com/dvdocumentation/nodalogic
Облако, с тем же функционалом, чтобы попробовать сразу (конструктор+сервер+веб-клиенты): https://nmaker.pw/
ТГ-канал платформы: https://t.me/thinknodes_ru
Приложение в GooglePlay (мобильная платформа): https://play.google.com/store/apps/details?id=com.dv.noda и RuStore: https://www.rustore.ru/catalog/app/com.dv.noda
