Для реализации проекта по модернизации существующей системы ЛЭРС Учет прошу разработать утилиту для импорта данных ЛЭРС Учета из одного экземпляра системы в другой.
Опишу конкретное приложение.
Сейчас объект (НПС - насосно-повысительная станция) уже включен в ЛЭРС Учет предприятия. Заказчик, для контроля персоналом тех.процесса, на объекте организует рабочее место ЛЭРС Учет. А для непрерывности поступления данных, чтобы не зависеть от связи, планируется установить на объекте сервер с ЛЭРС Учет.
При этом данные с объекта должны поступать и в центральную систему ЛЭРС Учет.
Т.е. нужно обеспечить импорт данных из системы ЛЭРС Учет на объекте в центральную систему ЛЭРС Учет.
Периодичность импорта должна быть настраиваемой, но возможностью задать частоту импорта данных не реже 1 раз минуту.
Мы подготовили предварительную версию утилиты. Утилита импортирует текущие, часовые, суточные, месячные данные. Подробное описание лежит в архиве рядом с утилитой.
Попробовали утилиту. Возникло не понимание.
В документации написано следующее:
“Перед первым запуском импорта данных необходимо настроить параметры импорта, которые задаются
в файле Lers.DataImport.xml.
MeasurePoints – список номеров точек учета для которых нужно выполнить импорт данных. Если
параметр не указан, то импортируются данные по всем точкам учета.”
Но, по моему пониманию, для утилиты требуется указать 2 номера: номер источника и номер приемника.
И было бы хорошо в документацию приложить пример Lers.DataImport.xml с заполненным списком точек для импорта, чтобы не гадать синтаксисом.
Хотел использовать ее еще в одном проекте у того же заказчика: С нескольких систем диспетчиеризации управляющих и обслуживающих компаний данные должны поступать на сервер к теплоснабжающей компании. У теплоснабжающей компании стоит ЛЭРС Учет. Среди систем-источников тоже попадется 3-4 ЛЭРС Учета. Сейчас предстоит работа с 1-ой.
По сути это задача для данной утилиты. Но … т.к. системы источники не управляемы мною, то вероятность совпадения номеров точек учета для 2 источников очень велика (номер же точки генерируется автоматически от одинаковому для всех алгоритму). Получается забрать данные я смогу только из одной системы, и то сменив номера точек учета в системе-приемнике.
Странное ограничение.
И выяснилось еще органичение, утилита для работы требует, чтобы версии ЛЭРСа и на источнике и на приемнике были одинаковые. А насколько это обязательное требование? Можно ли от него отказаться? Выполнить его нереально.
Утилита была разработана для изначальной задачи по синхронизации серверов. Сейчас вы озвучиваете совсем другую задачу, с совсем другими начальными требованиями.
Мы предлагаем вам создать новую тему с предложением для разработки адаптера данных.
Давайте вернемся к изначальной задаче. Мы считаем что дочерний сервер должен обязательно обновляться от головного, что исключит разницу версий и различных проблем при импорте. Также, номера точек учета должны соответствовать головному серверу, ограничивает ли вас данное условие именно в текущей задаче?
Пересмотрел все переписку по этому вопросу. Только в первом письме, более полгода назад, в проекте ТЗ от Заказчика было слово “репликация”. В дальнейшем я писал всегда про импорт. И в Вашей документации написано импорт. Поэтому и ожидал увидеть именно утилиту для импорта.
Тем более, в моем понимании, синхронизация в Вашей реализации очень похожа на импорт данных (т.е. на работу адаптера данных, в Вашей терминологии). И “адаптер данных” и текущая утилита, запускаемые службой задач ОС, вроде решают одну и ту же задачу, одними и теми же способами.
Отсюда вопрос. Может быть целесообразнее превратить эту утилиту для синхронизации данных в “адаптер данных”? Адаптер данных, на мой взгляд, будет выполнять синхронизацию. Применение его шире, чем утилиты для синхронизации. И Вам не придется поддерживать несколько идентичных программ.
Если я не прав, значит оформлю новую заявку.
Отвечаю на заданные вопросы.
Про номер точки учета. Это органичивает, т.к. неожиданно возникает связь всех синхронизируемых серверов по номерам точек учета. И соответственно, потребуется управлять этими номерами, следить за их уникальностью при любой модернизации, любого из серверов. И делать это придется полностью вручную. При текущей организации управления системами аналогичными ЛЭРСу, будут дополнительные ошибки.
Проверка версии. На первый взгляд Вы правы. Но в жизни включается иная логика. В системах:
1 центральный сервер и несколько маленьких;
или 2 дублирующих сервера
часть серверов сразу или через короткий промежуток времени начинают принадлежать разным юр.лицам. А далее уже директора этих юр.лиц принимают решение об оплате подписки, и кто-то всегда задерживается с оплатой, а то и долго разбирается в обоснованности оплаты подписки, она же добровольная. А обновляться в системе в многими серверами приходится.
Мы с вами согласны. Если обе системы уже установлены и используются, тогда проще задать соответствия в файле конфигурации. Но, в той ситуации, когда второй сервер еще не установлен, вы зададите все номера точек учета при настройки системы. Мы можем доработать утилиту в будущем, но сейчас мы не видим в этом необходимости.
Все остальные вопросы не относятся к изначальной постановки задачи, и данная утилита не сможет их решить. Мы по прежнему готовы обсуждать их, но в отдельной теме.
Вам решать. Но использовать эту утилиту я не решусь даже для описанного объекта.
В плюс к указанным замечаниям, есть еще одна проблема - обновление. Обновления такой системы - уже серьезная процедура. Ведь эксплуатировать эту утилиту планировалось с частотой обновления 1-3-5 мин. При таком режиме обновлять нужно одновременно, иначе обмен встанет. Причем даже те сервера, для которых не требуется обновление, кроме как для синхронизации. А т.к. таких объектов в перспективе станет больше, то обновление станет еще сложнее.
Т.е. учитывая все замечания эти ограничения создают слишком много “подводных камней” для администрирования такой системы.
Обновление в более чем 2/3 случаев ситуационное, возникающее из-за того, что начинаем использовать имеющие функции новым способом. И результат такой работы отличается от требуемого.
Тут нет смысла усреднять. Есть системы, где я обновлял 2 раза в месяц в течении 3 месяцев (проблемы с интеграторами ТСРВ), а есть где 1-2 раза в два года - норма.
Поэтому я не могу ответить на вопрос о частоте обновления.
Я уже вроде все расписал все. Проблем несколько:
организационная: владельцы этих 2 систем в процессе эксплуатации меняются и могут стать разными. Это не теория, а реалии у конкретного заказчика. И решение об оплате подписки принимают разные люди.
организационная: усложняется процесс обновления, а т.к. это непериодическая процедура, то при смене администраторов будут ошибки. А администраторы меняются часто. Да и ЛЭРС Учет не 1С, он требует значительно меньше внимания и администраторы обращают на него меньше внимания.
финансовая: владелец не захочет оплачивать подписку для тех систем, которые не требуют обновления. А маленькие системы из которых планируется забирать данные скорее всего не потребуют обновления. И при этом обоснования для подписки не будет, кроме как работа утилиты по синхронизации. Но тут включается 4 пункт.
техническая: Вы так и не объяснили в чем причина требования единой версии, если утилита работает через LERS FrameWork? Вроде FrameWork как раз и позволяет избавиться от этот привязки. И это в том числе следует из того, что написано про FrameWork на Вашем сайте и было услышано при личном разговоре с сотрудниками ХЦЭС.
Все эти проблемы проявятся не сразу, а в процессе эксплуатации через 0,5-1-2 года. И искать концы будет проблематично. Даже при наличии написанных регламентов.