Судя по всему большинство пользователей даже не подозревает о подобном функционале (например я). Почему бы не добавить информацию об этом в руководство пользователя? Или я плохо искал?
Несколько нелогичным выглядит присутствие системных задач в веб интерфейсе и одновременно отсутствие в АРМ. По опыту администраторы используют именно АРМ, а веб больше для пользователей.
Тут, что называется, “отрицательный результат - тоже результат”. Ошибки при поиске не возникло, данные о поверки устройства не найдены. Подразумевается, что их нет в АРШИНе, и повторять поиск ранее чем через 7 дней не нужно.
Мы ведём работы над улучшением поиска, чтобы он производился по номерам моделей в реестре СИ. Пожалуйста, наберитесь терпения. Думаю, в 3.49 уже успеем включить новый алгоритм. В нём ложноотрицательных результатов будет куда меньше.
а вы не могли бы описать алгоритм который вы планируете сделать? Я просто так и эдак тестировал их апи, и теперь в гугл таблицах успешно обновляется поверка… может смогу что-то посоветовать…
Поиск будет выполняться не по связке Название модели + Серийный номер, а по связке Номер модели в реестре СИ + Серийный номер. Это уже должно ускорить поиск и снизить до минимума ложные срабатывания.
Для всех моделей мы прописали все возможные номера в реестре СИ, чтобы синхронизация работала для всех поддерживаемых моделей.
Если у модели несколько номеров в реестре, поиск выполняется по всем номерам.
Помимо номера в модели, можно будет вручную указать номер СИ в реестре для конкретного экземпляра оборудования. Это позволит ускорить поиск. В предыдущем пункте описано, что поиск выполняется по всем номерам. Но если номер задан в конкретном экземпляре устройства, берётся только он.
вместо обработки ошибки 429 я не отправляю запрос по следующему экземпляру до получения ответа на предыдущий запрос. Так же добавил таймаут ожидания ответа на запрос в 2 минуты. Получилось вроде бы надёжно, все запросы на протяжении недели успешные.
Мы тоже отправляем запросы последовательно, дожидаясь ответа. 429 может возникать если их отправлять слишком часто. Такую ситуацию мы предусмотрели. В 3.49 синхронизация должна работать надёжнее.
Ограничение в 3 года сделано дабы защитить от информации о предыдущих поверках? Не страшно - эти данные реальны, хоть и не актуальны. Вынудит лишний раз перепроверить и выявить недостаток алгоритма. Зато на текущий момент отдыхают все СИ с интервалами 6+ лет(электросчётчики бывают с интервалами 12+ лет)
Почему интервал в 7 дней? ежедневная проверка перед началом рабочего дня - вот что нам нужно. Приборы ходят в ремонт и поверка обновляется.
P.S. позвольте настроить глубину опроса к релизу. Это по сути единственная критическая проблема на текущий момент.
Для большинства пользователей этих параметров будет достаточно. К релизу мы дадим возможность настройки, но не через системные параметры, а через Lers.Server.xml или переменные среды.
Например,так как вы используете Docker, вы сможете в docker-compose.yml в секцию lers/environment добавить параметры:
Название
Назначение
SearchYears
За сколько лет система будет запрашивать результаты проверки для каждого устройства.
MinDays
Периодичность синхронизации если не получены данные о поверке.
MinDaysBeforeScheduledCalibration
За сколько дней до планируемой поверки начинать синхронизацию.