Рекомендации к Web-API

В связи с разработкой проекта интеграции ЛЭРС Учет с ЭнергоСбыт в нашем регионе, появились предложения и дополнения к имеющемуся Web-API.

  1. Доступ к разделу Справочники
  • Оборудование (Получение списка моделей, серийных номеров, типов, места установки и !поверочная информация!).
    Поверочная информация с привязкой к конкретному прибору и конкретному объекту.
  • Объект Node должен быть дополнен полем с доступом к разделу “Оборудование”
    Node → Equipment → …
  1. Работы на объектах
  • Получение Наименования, описания, Типа, на какой Объекте, исполнитель и даты
  1. В R15 будут внесены изменения в обработку и хранение архива ошибок и интеграторов по времени действия НС, посему в Web-API (MeasurePointConsumptionRecord)
    необходимо внести возможность получения списка НС на каждую дату отчетного периода, а так же времени действия (каждой НС в сутки,
    суммарное количество по каждой НС за отчетный период). В MeasurePointConsumptionRecord есть поле WorkTime, наличие поля StopWorkTime так же необходимо.
    !! StopWorkTime должен быть равен сумме всех НС на текущие сутки и суммарно за период.
    Актуально и для полей *TotalsRecord

REST (http://habrahabr.ru/post/38730/) интерфейс - это CRUD (Create/Read/Update/Delete), который подразумевает не только получение той или иной информации через унифицированный
интерфейс, но и создание, обновление и удаление данных. Предлагаю обсудить возможность такой работы с текущим Web-API.

Первый пункт актуален на сейчас, большая просьба добавить этот функционал в версии R14!

Даже желательно в следующем обновлении R14.06!

Спасибо.

Подскажите, чем обусловлен выбор Web-Api для интеграции ЛЭРС Учет с Энергосбытом? В LERS Framework реализована большая часть необходимого для вас функционала.
В свою очередь Web-Api позиционируется как интерфейс выгрузки данных в другие системы, чаще всего принадлежащие разным владельцам. Данную задачи не всегда можно решить с помощью LERS Framework, т.к. он накладывает ограничение на совместимость версий между всеми системами.

Задачи редактирования никогда не стояли перед Web-Api, для этого существует LERS Framework.

Я не пишу на C# и не владею технологией .Net, поэтому реализация программы для выгрузки данных в xml для Энергосбыта было реализовано на веб-технологиях и платформе node.js и соответственно был взят Web API как Rest-интерфейс получения данных из Лэрс Учет.

PS: еще раз прошу добавить выборку из раздела Оборудование + поверки, очень нужно (ПО Энергосбыт привязывается по номеру вычислителя и его типу для того или иного адреса)!

Веб-служба вместе с точкой учета возвращает связанное с ней устройство. Сейчас у оборудования есть только серийный номер и модель оборудования. Мы можем добавить информацию о поверке и размещению оборудования.

Достаточно ли вам такого функционала без доступа к полному списку всего оборудования?

Да на данный момент поверка и размещение устроит.

Вопрос про объект NodeEquipment и EquipmentModel, от какого объекта они наследуются? (что то в http://soft.lers.ru/manual/api_interfaces.html не вижу)

Возможности веб-службы в настоящее время ограничены и полным интерфейсом взаимодействия с ЛЭРС УЧЁТ является фреймворк. Он развивается гораздо быстрее, так как мы сами его используем. Развитие же веб-службы ведётся по заявкам пользователей, и в настоящее время мы не видим большой необходимости реализации полного 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.

Объект NodeEquipment (Объект оборудование объекта учета), то есть все таки получается, что он наследуется от объекта Node?

Мы добавили задачу по доработки НС на веб-службе в наш план работ, предварительно на R15
В ЛЭРС Учет не хранится информация по StopWorkTime, также не все оборудование возвращает данное значение.

Пожалуйста, опишите подробнее вашу задачу. Как вы собираетесь использовать работы на объектах?

NodeEquipment был переименован в Equipment в R14. Данный класс не наследуется, имеет поля серийный номер и модель оборудования.

Имел ввиду каким образом мне связать запрос Объектов/Точек с оборудованием, которое установлено и серийный номер. Вы сказали выше, что

Веб-служба вместе с точкой учета возвращает связанное с ней устройство. Сейчас у оборудования есть только серийный номер и модель оборудования.

StopWorkTime и его наличие как в приборе учета, так и в ПО, входит в зону нового законодательства. В отчетах же мы его можем выводить!?

По поводу работ на объекте. В нашем случае ситуация какая:

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

По 3) пункту и архиву ошибок, привожу строку из xml для Энергосбыт

<?xml version="1.0" encoding="WINDOWS-1251"?>
.........
<ПоказаниеПУ d="16.11.2015" Q="3.088" M1="112.02" V1="115.35" M2="112.99" V2="114.54" t1="81.5" t2="54" dt="27.5" Tw="24" 
Tост="0" ErrE="0" ErrU="0" ErrD="0" ErrG="0" ErrGg="0" ta="-2.1" />
.........
<ИтогПоказаниеПУ d1="17.10.2015" d2="16.11.2015" Q_d1="653.898" Q_d2="766.355" Q="112.458" M1_d1="34223.98" M1_d2="37532.19" M1="3308.22" 
V1_d1="35183.33" V1_d2="38612.94" V1="3429.61" M2_d1="34572.17" M2_d2="37908.96" M2="3336.79" V2_d1="35137.13" V2_d2="38525.58" V2="3388.45" 
t1="91.4" t2="57.3" Tw_d1="5927.57" Tw_d2="6647.57" Tw="720" Tост="0" ErrE="0" ErrU="0" ErrD="0" ErrG="0" ErrGg="0" ta="-7.4"/>

где
ErrU - Период отключения питания
ErrE - Период функц.отказа
ErrD - Период t2-t1 < min
ErrG - Период G>max
ErrGg - Период G<min

Tост - общее время действия НС за отчетный период

У вас слишком много вопросов в одной теме. Мне уже тяжело понять в чём именно заключается проблема, которую мы решаем.

Насколько я могу понять, их три.

  1. Работы на объекта.
  2. Получение информации об оборудовании на объекте учёта.
  3. Вопрос про НС.

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

Первоочередность такая:

  1. Информация об оборудовании на объекте учета - получаем через Web API + поверочная информация
  2. Работы на объектах
  3. Получение архива ошибок

PS: разделю на отдельные темы