[Romanches]

Сообщение от Romanches

Доброго времени суток, коллеги. Возвращаясь к прошлой ситуации с невозможностью получения данных по HTTP API предоставляемого AutoGRAPH.NET service - проблема крылась в версионности программного обеспечения. Исходно, схемы на сервер загружались из клиентского ПО AutoGRAPH 5 2016. Но данная версия ПО не работает с современным API картографических сервисов. После того, как меня закрепили за сопровождением системы, я проверил возможность работы последнего доступного релиза клиентского ПО с существующим сервером, пришел к выводу, что система работоспособна. Эта же версия использовалась для редактирования схемы. Выяснилось, что компонент AutoGRAPH.NET Service не поддерживает работу с новым форматом схемы. Собственно, устаревание ПО и сподвигло меня прорабатывать варианты модернизации системы. Я запросил КП на обновление серверного по и переход с толстых клиентов на web-приложение, созванивался с менеджером ЕВРААСа, присылал развернутое описание объекта автоматизации на почту техотдела. Прошло пол года, КП мы так и не получили. За это время я набросал простенькое MVP web-приложения, презентовал руководству и получил карт-бланш на разработку web-ui для существующей системы спутникового мониторинга. Прошу извинить за столь длинную прелюдию к следующему вопросу. Имеем версию серверного по 5.2.53 и версию службы Autograph.NET Service 2016.9.15. HTTP API работает так, как описано в документации, за исключением методов GetReport и GetReports. В первом случае возникает исключение Нажмите для просмотра содержимого... Код: xx:xx:xx ERROR JSON 192.168.xx.xx:xxxxxx Схема1 GetReport SD=08.12.2023 08:00:00 ED=08.12.2023 10:00:00 IDs=xxxx94f8f-7bb1-49d4-a72a-18a6408cxxxx Report=coordinates.frx Split= Format=PDF Exception[DryIoc.ContainerException]: Unable to resolve DBDomain.Interfaces.IReportFactory. Where no service registrations found and number of Rules.FallbackContainers: 0 and number of Rules.UnknownServiceResolvers: 0 xx:xx:xx ERROR JSON 192.168.xx.xx:xxxxxx Схема1 GetReport SD=08.12.2023 08:00:00 ED=08.12.2023 10:00:00 IDs=xxxx94f8f-7bb1-49d4-a72a-18a6408cxxxx Report=coordinates.frx Split= Format=PDF Exception[DryIoc.ContainerException]: в DryIoc.Throw.It(Int32 error, Object arg0, Object arg1, Object arg2, Object arg3) в DryIoc.Container.ThrowUnableToResolve(Request request) в DryIoc.Container.DryIoc.IContainer.ResolveFactory(Request request) в DryIoc.Container.ResolveAndCacheDefaultDelegate(Type serviceType, Boolean ifUnresolvedReturnDefault, IScope scope) в AutoGRAPHService.AutoGRAPHSvcCommon.(GlobalSettings , REnumDevices , String , String , Guid[] , DateTime , DateTime , Int32 , ReportFormat ) в AutoGRAPHService.AutoGRAPHSvcBase. .() Во втором случае всегда возвращается пустой массив. Понимаю, что прошу помощи с EOL продуктом, и скорее всего сломался DI внутри приложения и починить его не имея исходника невозможно. Но может кто то сталкивался с подобным или есть способы обхода ошибки "малой кровью" путем регистрации или установки недостающих компонентов. Спасибо всем откликнувшимся!

Вы используете устаревшую версию, причём из периода времени, когда для ПО активно искались направления развития. С тех пор сменилась программная платформа (с .NET на .NET Core), произошли глобальные изменения в основных модулях программы, производительность расчетного ядра выросла, наверное, на порядок. Появилась официальная поддержка внешних модулей, заметно изменился диалект API.
Ну и изменилась схема лицензирования ПО.
На данный момент мне кажется, что вы проделали большую, но очень бесперспективную работу.
Вы не думали над тем, чтобы обратиться к другому дилеру или производителю за помощью в этой ситуации? Или этому есть препятствия в действующем договоре?
Из самого приложения отчёты вызываются корректно?

Вопрос необходимости поиска нового системного интегратора был мной озвучен, но пока это вопрос отдаленной перспективы. То, что продукт развивается мне тоже известно, но, к сожалению, работаю с тем, что было унаследовано. Производительность существующего решения при текущем количестве ТС и пользователей узким местом не является. Во всяком случае не являлась. По поводу бесперспективности проделанной работы - не соглашусь, большей части наших пользователей требуется 5% функциональности толстого клиента, а именно посмотреть где находится закрепленное за подразделением ТС, зафиксировать факт посещения определенных геозон, получить итоговые данные по рейсу. И эта информация им будет доступна с любого рабочего места посредством корпоративного портала. Отчеты - вишенка на торте, можно и без них. То, что меняется схема API от версии к версии - по заветам дедушки Фаулера выносим бизнес логику работы с API в отдельный слой, описываем интерфейсы обработчиков и возвращаемых объектов, пишем реализации под конкретные версии API, указываем используемую версию в переменной окружения при старте контейнера с приложением. Этот архитектурный паттерн уже реализован. Я бегло потыкал в сваггер текущей версии API по адресу demo.tk-nav.com и не увидел каких либо препятствий реализовать его поддержку в нужном нам объеме, тем самым переход на актуальную версию серверного ПО не "хоронит" наработки. Что касается отчетов, отчеты полностью работоспособны на толстых клиентах AutoGRAPH 5 в версиях 2016 и 2020.