| Romanches |
13.12.2023 07:31 |
Цитата:
Сообщение от MartynenkoES
(Сообщение 206383)
Цитата:
Сообщение от Romanches
(Сообщение 206379)
Доброго времени суток, коллеги. Возвращаясь к прошлой ситуации с невозможностью получения данных по 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. |
