Дальнейшая судьба внешних модулей

Исходя из последних сообщений разработчиков касательно АРМ оператора под Linux:

А так же планы включения в реестр отечественного ПО:

Можно сделать вывод что упор сейчас делается на веб интерфейс, и АРМ оператора дальнейшего развития вряд ли получит, если вообще останется в системе в будущем.
Исходя из этого хочется узнать существуют ли некие планы касательно существующих внешних модулей - будут ли они хотя бы частично (имеется ввиду их функционал) перенесены в веб?

Так же хочу попросить вашего совета каким образом на текущий момент можно реализовывать “нестандартные” функции через LERS Framework, при условии что у наших клиентов во всю идет “импортозамещение” и рабочие ПК находятся под управлением RedOS. Имеется ввиду что они работают через веб, и на данный момент в нем не предусмотрены внешние модули.

Ну мы об этом прямо заявляем, основной вектор разработки у нас теперь на веб-интерфейсе.

Пока планов удалять АРМ оператора нет. Мы будем поддерживать его столько, сколько будет возможно. Если в реестр будет включено новое ПО, оно будет совместимо с существующим АРМ оператора.

Возможно, часть новых функций может быть доступна только через WEB. В этом случае мы сделаем возможность перехода к этим функциям прямо из АРМ. Скорее всего, веб будет открываться в отдельной закладке АРМ оператора. Но это не точно, пока на уровне идеи.

Сейчас нет. Мы работаем над вебом, чтобы достичь паритета по функциям с АРМ, это процесс медленный. Над внешними модулями для веба будем думать не раньше чем через год.

Ядро LERS Framework может использоваться на linux, за исключением функций, относящихся как раз ко внешним модулям. Они находится в сборках Lers.Plugins и Lers.UI.

Вы можете делать расширения следующими способами:

Приложения, под linux которые используют LERS Framework. Это могут быть консольные утилиты, или программы с интерфейсом пользователя, например, написанные на Avalonia. LERS.Framework собран под платформу netstandard2.0, что позволяет использовать его как в NET Framework под Windows, так и в любых версиях .NET под Linux.

Чуть более сложный в реализации, но простой для пользователя вариант - собственный WEB-интерфейс, который использует открытый REST API ЛЭРС УЧЁТ. Пользователю в этом случае не нужно отдельно устанавливать приложение, можно будет открыть ваш веб-интерфейс в браузере.

Вообще, я бы рекомендовал для новых интеграций использовать открытый REST API. Framework будет поддерживаться долго, так как на нём основан АРМ оператора. Но новые функции в него не добавляем. Он свою задачу выполнил, и теперь переходит в стадию долговременной поддержки.

В будущем мы будем работать над возможностью расширения нашего веб-интерфейса. Но конкретные сроки сегодня назвать не могу.

Примерно в этом направлении и хотели работать. Но тут проблема в том, что для пользователя это будет отдельный “сайт”. Перейти в него можно будет только по прямой ссылке/из закладок браузера.
Быть может продумать какой то механизм, чтобы допустим из точки учета можно было кликнуть на ссылку, и она бы открыла пользовательский URL и как вариант передала в GET запросе номер точки учета?
В общем предлагаю обсудить как можно “соединить” интерфейс веб ЛЭРСа и пользовательские веб сервисы.

Ну например, можно в карточке точки/объекта показывать значения атрибутов, если в них сохранён URI. Проблема в том, что потребуется повторная авторизация. Тут бы пригодился механизм OIDC, но у нас его сейчас нет. Как я уже говорил, вопросов много, мы их постепенно обсуждаем в процессе доработки веба.

Для начала это подойдет. Было бы здорово увидеть прототип такого функционала в одной из будущих beta.
Важны 2 момента:

  1. Этот атрибут должен быть кликабельным и открывать страницу в новом окне
  2. Крайне желательно иметь возможность отдельно задавать URI и текст, отображаемый пользователю

Это был только пример. При проектировании могут быть приняты другие решения, и делать сходу такую функцию не стоит. Ее, может быть, придется полностью удалять.

Может быть даже в web-интерфейсе будет реализована некая система плагинов, для реализации пользовательского функционала? Единая система авторизации, тут же встроенные методы rest api, инструменты для формирования отчётов в различных форматов - и всё в едином интерфейсе ЛЭРС. Так, посорю тут своими фантазиями :slight_smile:

1 лайк

Да, скорее всего, модули веба будут встроены в существующий интерфейс, и для них будут доступны открытые сервисы rest api. Но опять же, проектирование пока не делали, сказать сейчас тяжело.

У нас появилось понимание каким образом сделать механизмы для расширения веб-интерфейсе. Как доказательство концепции сделали внешний модуль удалённого пульта КМ-5.

Как это будет работать

Наш веб-интерфейс - это SPA angular приложение, которое раздаётся сервером ЛЭРС УЧЁТ на всех маршрутах, кроме некоторых зарезервированных. Мы сделаем в сервере возможность раздавать не только веб-интерфейс, но и другие SPA-приложения. Для этого будет зарезервирован маршут _plugin/ИМЯ_МОДУЛЯ. Например, если наш веб-интерфейс работает на адресе https://my.lers.ru, то установленный внешний модуль будет открываться по пути https://my.lers.ru/_plugin/km5-remote-console.

Каким образом модуль будет встроен в веб

Точно так же, как и в АРМ оператора будет возможность встроить модуль в список объектов, точек и в меню “Сервис”. Для этого нужно будет разместить в папке с вашим SPA-приложением json-файл с манифестом, в котором будет указано куда будут встроены пункты меню модуля.

После того как пользователь выбрал этот пункт, веб-интерфейс откроет новую вкладку с адресом веб-интерфейса и идентификатором точки или объекта в качестве параметра запроса. Например, внешний модуль удалённого пульта со списка точек или объектов откроется с адресом https://my.lers.ru/_plugin/km5-remote-console?measurePointId=123 SPA-приложение должно получить идентификатор точки или объекта из строки запроса и работать с ним.

Как быть с авторизацией

Так как, с точки зрения браузера, оба этих приложения это один сайт, им доступно локальное хранилище браузера, в котором уже сохранён рабочий токен для выполнения запросов к серверу. Ваш внешний модуль после загрузки должен обратиться к локальному хранилищу, запросить этот токен и использовать для дальнейших запросов к серверу.

Как быть с REST API

Как и в предыдущем пункте, браузер считает, что это тот же самый сайт, так что внешний модуль может без проблем отправлять запросы к REST API сервера, используя маршруты вида /api/v1/serverInfo. Адрес сервера указывать не нужно, достаточно относительного маршрута.

Кроме того, вы можете сгенерировать классы для работы с REST API, так как наш сервер предоставляет спецификацию OpenAPI.

Как обновлять такой плагин

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

Будет ли каталог

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

Что это даёт

Вы сможете написать своё SPA-приложение на любом фреймворке. Это может быть Angular, Vue, React, Svetle, или что угодно другое. Ссылка на это приложение будет автоматически встроена в наш веб-интерфейс, что позволит вам расширить своими функциями.

Скорее всего, мы опубликуем библиотеку для того, чтобы проще писать внешние модули, но она будет только под angular, так как мы пишем веб-интерфейс на нём, и наши внешние модули так же будут основаны на нём.

В общем, идеи примерно такие. Хотелось бы выслушать мнения и предложения пользователей, которым это интересно.

1 лайк

Новости отличные!
Чтобы были какие то предложения - думаю нужно попробовать что-то свое реализовать (перенести уже существующие модули на веб).
Поэтому пока ждем от вас примеров реализации внешних модулей, вроде тех, что сейчас лежат на гитхаб.
Большой плюс таких модулей вижу в том, что ими можно будет пользоваться с мобильных устройств. Нам этого очень не хватало.

Как будут работать удалённые пульты (как приведенный вами пульт КМ-5):
Каким образом внешний модуль будет взаимодействовать с прибором учета (направлять ему запросы и получать ответы)?

Так же, как модули АРМ. Через API запросы к серверу, он транслирует их службе опроса, та выполняет запрос и обратно по цепочке шлёт ответ прибора, или ошибку.

Когда планируется открыть доступ к данному API ?

Приветствую. Я за любой кипишь, кроме голодовки =))) Ребята, творите, самое главное что бы это стабильно работало. Сам не очень приветствую веб интерфейс, но это скорее к вопросу: Что лучше ноутбук или стационарный комп, я за стационарный комп. В связи с этим ставлю у контрагентов, (пользователей), бесплатную версию ЛЭРС УЧЕТ и а адресую на свой сервер.

API открыт, это наш обычный REST, всё работает через него. Механизм загрузки модулей опубликуем когда будем готовы. Скорее всего, после того как разберёмся с вопросом включения в реестр ПО. Пока много сил уходит на это.

Сейчас нет другого простого способа сделать приложение, которое будет работать на Windows, Linux и мобильниках, кроме веба. Это тренд развития современных систем, и с ним придётся считаться.

Не понимаю зачем ставить бесплатную версию с сервером, сервером БД, и другими компонентами, когда хватит только АРМ оператора. Для него можно скачать на нашем сайте отдельный лёгкий установщик.

Да не, =))) я ставлю арм, зачем им сервер? Я про браузерный лэрс и программный.

Не нашел в документации каким образом через REST API можно отправить запрос прибору и получить его ответ.

Ну да, это пока закрытый API, мы его пока не открывали. Опять же, потому что ещё не готовы.