Для реализации проекта по модернизации существующей системы ЛЭРС Учет прошу разработать утилиту для импорта данных ЛЭРС Учета из одного экземпляра системы в другой.
Опишу конкретное приложение.
Сейчас объект (НПС - насосно-повысительная станция) уже включен в ЛЭРС Учет предприятия. Заказчик, для контроля персоналом тех.процесса, на объекте организует рабочее место ЛЭРС Учет. А для непрерывности поступления данных, чтобы не зависеть от связи, планируется установить на объекте сервер с ЛЭРС Учет.
При этом данные с объекта должны поступать и в центральную систему ЛЭРС Учет.
Т.е. нужно обеспечить импорт данных из системы ЛЭРС Учет на объекте в центральную систему ЛЭРС Учет.
Периодичность импорта должна быть настраиваемой, но возможностью задать частоту импорта данных не реже 1 раз минуту.
Мы подготовили предварительную версию утилиты. Утилита импортирует текущие, часовые, суточные, месячные данные. Подробное описание лежит в архиве рядом с утилитой.
Попробовали утилиту. Возникло не понимание.
В документации написано следующее:
“Перед первым запуском импорта данных необходимо настроить параметры импорта, которые задаются
в файле Lers.DataImport.xml.
MeasurePoints – список номеров точек учета для которых нужно выполнить импорт данных. Если
параметр не указан, то импортируются данные по всем точкам учета.”
Но, по моему пониманию, для утилиты требуется указать 2 номера: номер источника и номер приемника.
И было бы хорошо в документацию приложить пример Lers.DataImport.xml с заполненным списком точек для импорта, чтобы не гадать синтаксисом.
Надеюсь на оперативный ответ.
Поиск точки учета происходит по ее номеру. Номер точки учета должен быть задан и быть одинаковым на обоих серверах.
Добавили пример файла конфигурации в документацию.
Дублирую здесь:
<?xml version="1.0" encoding="utf-8" ?>
<Settings MeasurePoints="1,2,3">
<SourceServer Address="192.168.1.10" Port="10000" Login="admin" Password="admin" />
<DestinationServer Address="192.168.1.20" Port="10000" Login="admin" Password="admin" />
</Settings>
Спасибо за ответ.
Но зачем такое ограничение?
Хотел использовать ее еще в одном проекте у того же заказчика: С нескольких систем диспетчиеризации управляющих и обслуживающих компаний данные должны поступать на сервер к теплоснабжающей компании. У теплоснабжающей компании стоит ЛЭРС Учет. Среди систем-источников тоже попадется 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 года. И искать концы будет проблематично. Даже при наличии написанных регламентов.
Вы писали готовый инструментарий для решения этой задачи, но сейчас не могу найти его следы.
Есть ли сейчас это? И где его искать?
?
Добрый день!
Утилита не доработана, так используемый в ней подход не работал даже на наших тестовых системах. Если требуется, то вот её исходники.