В связи с разработкой проекта интеграции ЛЭРС Учет с ЭнергоСбыт в нашем регионе, появились предложения и дополнения к имеющемуся Web-API.
Доступ к разделу Справочники
Оборудование (Получение списка моделей, серийных номеров, типов, места установки и !поверочная информация!).
Поверочная информация с привязкой к конкретному прибору и конкретному объекту.
Объект Node должен быть дополнен полем с доступом к разделу “Оборудование”
Node → Equipment → …
Работы на объектах
Получение Наименования, описания, Типа, на какой Объекте, исполнитель и даты
В R15 будут внесены изменения в обработку и хранение архива ошибок и интеграторов по времени действия НС, посему в Web-API (MeasurePointConsumptionRecord)
необходимо внести возможность получения списка НС на каждую дату отчетного периода, а так же времени действия (каждой НС в сутки,
суммарное количество по каждой НС за отчетный период). В MeasurePointConsumptionRecord есть поле WorkTime, наличие поля StopWorkTime так же необходимо.
!! StopWorkTime должен быть равен сумме всех НС на текущие сутки и суммарно за период.
Актуально и для полей *TotalsRecord
REST (http://habrahabr.ru/post/38730/) интерфейс - это CRUD (Create/Read/Update/Delete), который подразумевает не только получение той или иной информации через унифицированный
интерфейс, но и создание, обновление и удаление данных. Предлагаю обсудить возможность такой работы с текущим Web-API.
Подскажите, чем обусловлен выбор Web-Api для интеграции ЛЭРС Учет с Энергосбытом? В LERS Framework реализована большая часть необходимого для вас функционала.
В свою очередь Web-Api позиционируется как интерфейс выгрузки данных в другие системы, чаще всего принадлежащие разным владельцам. Данную задачи не всегда можно решить с помощью LERS Framework, т.к. он накладывает ограничение на совместимость версий между всеми системами.
Задачи редактирования никогда не стояли перед Web-Api, для этого существует LERS Framework.
Я не пишу на C# и не владею технологией .Net, поэтому реализация программы для выгрузки данных в xml для Энергосбыта было реализовано на веб-технологиях и платформе node.js и соответственно был взят Web API как Rest-интерфейс получения данных из Лэрс Учет.
PS: еще раз прошу добавить выборку из раздела Оборудование + поверки, очень нужно (ПО Энергосбыт привязывается по номеру вычислителя и его типу для того или иного адреса)!
Веб-служба вместе с точкой учета возвращает связанное с ней устройство. Сейчас у оборудования есть только серийный номер и модель оборудования. Мы можем добавить информацию о поверке и размещению оборудования.
Достаточно ли вам такого функционала без доступа к полному списку всего оборудования?
Возможности веб-службы в настоящее время ограничены и полным интерфейсом взаимодействия с ЛЭРС УЧЁТ является фреймворк. Он развивается гораздо быстрее, так как мы сами его используем. Развитие же веб-службы ведётся по заявкам пользователей, и в настоящее время мы не видим большой необходимости реализации полного REST-интерфейса.
Веб-службы продолжит развиваться, но в первую очередь как инструмента для интеграции. Например, сейчас в нашем плане работ на R15 числится давно востребованный функционал получения профиля мощности по точке учёта. Рано или поздно веб-служба будет реализовывать большинство функций по работе с объектами, но пока основной акцент в разработке мы делаем именно на нём.
.NET стал уже фактически стандартом в программировании под Windows, поэтому количество знающих его специалистов достаточно велико. Возможно, часть работ получится отдать на аутсорс?
Про .Net я спорить не буду. На аутсорс не рассматривали такой вариант. Нет смысла для нас. Вполне получается работоспособное приложение на базе Web-API и node.js - по сути сервер JavaScript, который может делать мощные штуки. REST имеет достаточно много + и так же -, которые специалисты всячески уже пытаются обойти, например Facebook разработал методику работы с данными, получаемыми из любого источника будто SQL или NoSQL хранилище (mongodb) - https://facebook.github.io/graphql/ (https://facebook.github.io/react/blog/2015/05/01/graphql-introduction.html#rest).
Опять же вопрос про Web-API и REST был ради интереса, нам важно знать ход ваших мыслей.
Мы добавили задачу по доработки НС на веб-службе в наш план работ, предварительно на R15
В ЛЭРС Учет не хранится информация по StopWorkTime, также не все оборудование возвращает данное значение.
Пожалуйста, опишите подробнее вашу задачу. Как вы собираетесь использовать работы на объектах?
StopWorkTime и его наличие как в приборе учета, так и в ПО, входит в зону нового законодательства. В отчетах же мы его можем выводить!?
По поводу работ на объекте. В нашем случае ситуация какая:
Этот функционал нужен для отслеживания действий, связанных со снятием оборудования в поверку, так как наше приложение для Энергосбыта должно оперативно отфильтровывать как нерабочие точки учета (с наличием НС), так и те объекты, где оборудование сдано в поверку. Дело в том, что даты поверок, которые занесены в базу не всегда являются достаточным условием для фильтрации объектов, потому что часто из-за поломки оборудования, эти даты смещаются. Если мы создаем работу на объекте - Поверка, сам факт наличия дает нам основание для исключения данного объекта из формирования xml для Энергосбыт.