Ошибка обработки GET запроса при работе УТМ на версии 4.2.0-b2497 : ЕГАИС в опте и рознице

Здравствуйте!
Помогите пожалуйста разобраться со следующей ситуацией.
После обновления версии УТМ на последнюю 4.2.0-b2497, при попытке загрузить входящие документы из УТМ стала возникать ошибка: HTTP/1.1 500.
В логе УТМ (transport_info.log ) значится следующее:
2022-08-22 20:39:54,834 ERROR ru.centerinform.transport.backbone.http.controller.workflow.WorkflowServerDoсController - Ошибка обработки GET запроса
java.io.FileNotFoundException: C:\UTM\transporter\bin\..\xml\ws\030x37471D9D-8F85-4A16-AE11-3085F32B0D41 (Не удается найти указанный файл)
При этом в папке «C:\UTM\transporter\xml\ws» этого файла действительно нет.

Видимо на очередной виток пошла проблема с целостностью БД УТМ при получении документа. Эта проблема особо никогда и не исчезала. Сначала выглядела как "Ошибка связи" на домашней странице УТМ, потом её "скрыли", но фактически она продолжала возникать.
Мое мнение, что повреждаются (криво записываются в БД) документы, в момент записи которых произошел запрос к БД УТМ со стороны учетной системы. Но пока доказать себе эту гипотезу не смог, это просто ощущения.
Исправить можно удалив витый документ через curl и перезапросив ТТН

Аналогичная проблема...
А как найти битый документ?

Он в исходящих в УТМ будет либо со статусом "8", либо со статусом "Ошибка связи"

В исходящих пусто.

значит у вас какая-то другая проблема:) Если проблема возникла по ИП - проверьте, не заблокировали ли его ФСРАР_ИД случаем. Если ИП зарегистрирован в ЕГАИС по месту жительства - могут забанить, сейчас идет такая "акция". Понять это можно зайдя в список мест деятельности для генерации ключа в ЛК ЕГАИС. Если там пусто - значит заблокировали ФСРАР_ИД.
Пришлите лог УТМ (transport-info) что ли, посмотрим что в нем

https://storage.olegon.ru/supermag/u...rt_info.log.7z
(0.21Мб)

Да, действительно, похоже что УТМ не может найти документ 030xE88F9E25-A112-4089-B5F9-6E8D34F8CC32 в базе и из-за этого не получает документы с сервера.
Могу посоветовать сделать следующее:
1. Остановите УТМ
2. Переименуйте папки C:\UTM\transporter\transportDB и C:\UTM\transporter\xml
3. Укажите в конфиге УТМ (C:\UTM\transporter\conf\transport.properties) в 4х полях ПИН Рутокена (12345678)

###############################################
# GOST keystore passwords
###############################################
crypto.lib.gost.keystorePassword=12345678
crypto.lib.gost.keyPassword=12345678
###############################################
# PKI keystore passwords
###############################################
crypto.lib.pki.keystorePassword=12345678
crypto.lib.pki.keyPassword=12345678
###############################################

4. Запустите УТМ
Если с первого раза не запустится - снова укажите ПИНы (повторите шаг 3) и снова запустите УТМ.

Документы с сервера ЕГАИС УТМ ПОЛУЧАЕТ!



Чеки ПОДПИСЫВАЕТ!
Стало быть, доступ в области Рутоекна pki и gost УТМ имеет
Сомневаюсь, что явное прописывание пин-кодов в конфиге поможет.

Напоминаю, проблема возникает при обращении товароучетного ПО к УТМ



Может проблема в товароучетке?

Миниатюры

 

ну это до пересоздания БД он доступ имеет. А после пересоздания - может начать выдавать ошибки. И вот тут поможет указание ПИНов в конфиге - это такая новая "фишечка" последних билдов УТМ, что ПИНы теперь хранятся в БД УТМ.
Боюсь, я исчерпал свои скудные возможности вам помочь. Попробуйте озадачить Дежурную линию РАР. Мы с УТМ 3* всю дорогу маялись в рандомное время получая от ДС ошибку 403 Forbidden. Я бы сказал, что симптомы похожи, но на 4* УТМ проблему с 403 Forbidden Центринформ вроде бы устранил.