Как найти причину ошибки обмена СМЭВ4?

Этапы передачи запросов и ответов в СМЭВ4

Обмен в СМЭВ4 состоит из следующих этапов:

1.  Передача запроса от информационной системы (ИС) Потребителя до Агента СМЭВ4 Потребителя с использованием JDBC-драйвера или REST-интерфейса.
2. Подписание запроса и передача его от Агента СМЭВ4 Потребителя до Ядра СМЭВ4.
3. Проверка переданного запроса Ядром СМЭВ4 на предмет наличия полномочий выполнения запроса и форматно логический контроль (ФЛК). 
4. Передача запроса от Ядра СМЭВ4 в адрес Агента СМЭВ4 Поставщика и проверка подписи инициатора запроса.
5. Передача запроса от Агента СМЭВ4 Поставщика до Витрины Поставщика.
6. Обработка запроса на стороне Витрины Поставщика, подготовка ответа и передача результата Агенту СМЭВ4 Поставщика.
7. Подписание ответа и передача его от Агента СМЭВ4 в Ядро СМЭВ4.
8. Передача ответа от Ядра СМЭВ4 в адрес Агента СМЭВ4 Потребителя.
9. Передача ответа от Агент Потребителя в адрес информационной системы Потребителя с использованием JDBC-драйвера или REST-интерфейса (подробнее про обмены разных типов читайте в статье – «Что такое СМЭВ4»).

Для возможности мониторинга обмена на стороне Агента СМЭВ4 Потребителя каждому запросу присваивается уникальный идентификатор (query_id).

Query_id присваивается каждому запросу, при вызове РЗ. Для того, чтобы получить идентификатор запроса, необходимо направить в адрес Агента СМЭВ4 регламентированный запрос (РЗ) из консоли, или через jdbc-драйвер (как настроить jdbc-драйвер на работу Агента СМЭВ4 читайте в статье: «Настройка Агента для получения данных через JDBC»). На рисунке 1 представлен пример вызова РЗ:

Рисунок 1 – Вызов РЗ. Идентификатор запроса

В ответной части есть информация о времени отправки запроса и присвоенный ему идентификатор. Скопируйте его для того, чтобы проверить его статус.

Сервис «Судьба сообщения»

По query_id запроса в личном кабинете участника взаимодействия (ЛК УВ) можно определить статус его выполнения. Для этого в ЛК УВ необходимо перейти на вкладку Мониторинг и выбрать сервис Судьба сообщения СМЭВ4:

Рисунок 2 – ЛК УВ. Вкладка Мониторинг

В открывшемся окне инструмента «Судьба сообщения СМЭВ4» необходимо ввести query_id обмена в поле Идентификатор клиента или обмена для поиска сеанса обмена, при этом среда обмена определяется самостоятельно.

На рисунке 3 представлен пример сеанса успешного обмена:

Рисунок 3 – ЛК УВ. Судьба сообщения СМЭВ4

Слева отображаются все стадии передачи запроса и ответа, а также время завершения каждой стадии обмена (Рисунок 4):

Рисунок 4 – ЛК УВ. Судьба сообщения СМЭВ4. Стадии обработки запроса и ответа

Справа сверху отображается идентификатор обмена, общая длительность обмена и его текущий статус. В приведенном примере обмен завершен успешно (Рисунок 5):

Рисунок 5 – ЛК УВ. Судьба сообщения СМЭВ4. Общая продолжительность обмена. Статус

Ниже представлен пример результата успешного обмена. На РЗ, вызванный из консоли, вернулся ответ, содержащий в себе бизнес-данные, полученные из таблиц базы данных витрины ГородаРФ (Рисунок 6):

Рисунок 6 – Успешный ответ на РЗ

Иногда в процессе выполнения запроса на разных стадиях могут возникать ошибки.

Сервис «Судьба сообщения» поможет определить стадию, на которой обмен завершился и сузит поиски возможной причины ошибки. Как уже было сказано в начале статьи полноценный обмен состоит из 9 этапов.

Рассмотрим, как можно найти причину ошибки обмена на некоторых из них.

Ошибки выполнения запроса на разных стадиях обработки:

1) Обработка запроса на стороне Агента Потребителя СМЭВ4 (пример прерывания выполнения запроса на этапе передачи запроса в Ядро СМЭВ4 показан на рисунке 7):

Рисунок 7 – ЛК УВ. Судьба сообщения СМЭВ4. Прерывание обработки запроса. Статус: «В процессе»

На рисунке 7, статус обмена завис на статусе «В процессе». В данном примере ошибка возникла на стороне Агента Потребителя СМЭВ4. Для анализа проблем необходимо собрать лог Агента. 

  Примечание

 Лог Агента СМЭВ4 собирается разными способами, в зависимости от установки Агента из docker или через сервис systemd. Оба варианта с настройкой ротации логов описаны в Руководстве администратора Агента СМЭВ4.

В случае наличия в логах Агента СМЭВ4 ошибок, определить возможную причину можно с помощью статьи «Типовые ошибки Агента СМЭВ4».

Рекомендуется просмотреть лог на наличие записей со статусом: "ERROR". Рассмотрим пример ошибки при просмотре лога:

"exception":"java.lang.RuntimeException: RuntimeException: Ошибка при передаче SQL запроса в ядро, IllegalArgumentException: Список подключений к Pulsar пуст

Надпись: Список подключений к Pulsar пуст говорит о том, что подключение по Pulsar невозможно. 

Решение: необходимо переключить настройку на работу по целевой архитектуре (в конфигурационном файле Агента СМЭВ4 application.yml необходимо указать: "use-ca: true").

  Примечание

 Начиная с версии Агента СМЭВ4 3.18.0 работа осуществляется только по ЦА

2) Обработка на стороне Ядра СМЭВ4 (пример прерывания выполнения запроса с ошибкой на этапе обработки запроса на Ядре СМЭВ4 показан на рисунке 8):

Рисунок 8 – ЛК УВ. Судьба сообщения СМЭВ4. Обмен прерван с ошибкой

Как мы видим на рисунке 8 статус обмена «Прерван с ошибкой». В данном примере ошибка возникла на обработке запроса на стороне Ядра СМЭВ4 и указана причина ошибки: «В запросе неверно вызван регламентированный SQL-запрос». В данном случае пользователям рекомендуется перепроверить правильно ли прописаны параметры РЗ при вызове. Для детального изучения проблемы следует также собрать лог Агента СМЭВ4.

Пример ошибки в логе Агента СМЭВ4:

"StateAwareInputStreamException: Ошибка во входящем потоке, CustomRSocketException: INTERNAL: Недостаточно параметров для выполнения запроса"

Решение: необходимо проверить сколько входных параметров в описании РЗ в ЕИП НСУД и сверить их с количеством параметров, передаваемых в РЗ. Для этого в ЕИП НСУД необходимо перейти в Модель данных и выбрать Регламентированные запросы (Запросы SQL). В открывшемся списке РЗ необходимо выбрать нужный РЗ, для удобства справа начните вводить название мнемоники РЗ (Рисунок 9):

Рисунок 9 – ЕИП НСУД. Выбор РЗ

В открывшейся карточке РЗ необходимо найти окно с Запрашиваемыми данными (Рисунок 10):

Рисунок 10 – ЕИП НСУД. Карточка РЗ. Запрашиваемые данные

В примере вызова регламентированного запроса указан полный запрос с ожидаемыми входными параметрами при вызове РЗ. Необходимо убедиться, что при составлении запроса были указаны все входящие параметры.

Пример вызова такого РЗ из консоли имеет следующий вид:

Рисунок 11 – Пример вызова РЗ

Также наиболее частая ошибка при обработке запроса на стороне Ядра СМЭВ4 – это ошибка доступа.

Ошибка доступа

В случае ошибки доступа необходимо убедиться, что информационной системой (ИС) Потребителя получен доступ к РЗ в ЛК УВ. Описание способов получения доступа к РЗ в ЛК УВ описано в Руководстве пользователя ЛК УВ на портале ЕСКС в разделе Документы ЛК УВ (см. п.п.5.7.5 Получение доступов к регламентированным запросам типа SQL-запрос).

В случае, если доступ к РЗ не был получен, при попытке вызвать запрос в ответе вернётся соответствующая ошибка: "PERMISSION_DENIED: AuthorizeRequestException: Доступ запрещён":

Рисунок 12 – Обмен, завершившийся ошибкой: Доступ запрещён

Если проверить данный обмен в ЛК УВ можно увидеть следующее:

Рисунок 13 – ЛК УВ. Судьба сообщения СМЭВ4

В результате сеанса обмена можно увидеть, что запрос прервался на этапе обработки на стороне Ядра СМЭВ4 ошибкой: Нет прав на выполнение запроса.

Если ответа на РЗ нет, то есть ответ не успевает вернуться в пределах заданного таймаута, это означает, что существуют проблемы на стороне Витрины Поставщика данных (при условии, что Агент Потребителя настроен корректно и отрабатывает тестовый запрос Select 1). В этом случае рекомендуется проверить работу любого другого РЗ, чтобы убедиться в этом. Если подтвердится, что проблема действительно на стороне Витрины Поставщика, необходимо связаться с её владельцем. Официально это можно сделать, оформив заявку в СЦ с указанием: Назначить на ведомство поставщика.

3) Обработка запроса на стороне Агента Поставщика СМЭВ4 (пример прерывания выполнения запроса на этапе обработки запроса на Агенте Поставщика СМЭВ4 показан на рисунке 14). Между третьей и четвертой стадией обработки также происходит обработка запроса на стороне Витрины данных Поставщика (для анализа возникающих проблем необходимо это учитывать).

Рисунок 14 – ЛК УВ. Судьба сообщения СМЭВ4. Прерывание обработки запроса. Статус: «В процессе»

На рисунке 14, статус обмена завис на статусе «В процессе». Для анализа проблем необходимо собрать лог с Агента Поставщика СМЭВ4, проверить доступность Витрины данных и связь витрины с Агентом (см. раздел: Рекомендации для Поставщиков данных).

  Что делать Потребителям данных в случае ошибок на стороне Поставщика?

 Необходимо оформить заявку в СЦ с указанием проблемы и Назначить на ведомство поставщика

4) Обработка ответа на стороне Агента Поставщика СМЭВ4 (пример прерывания выполнения запроса на этапе обработки ответа на Агенте Поставщика СМЭВ4 показан на рисунке 15):

Рисунок 15 – ЛК УВ. Судьба сообщения СМЭВ4. Обмен с ошибкой

На рисунке 15 статус обмена «Прерван с ошибкой». Но в данном примере ошибка возникла на обработке ответа на стороне Агента Поставщика СМЭВ4 (ошибка: «Внутренняя ошибка СМЭВ4»). В качестве рекомендации предлагается: «Привлечь службу эксплуатации на стороне участника взаимодействия». В данном случае причины могут быть как в настройках Витрины данных, так и в настройках Агента СМЭВ4 (для определения причин см. раздел: Рекомендации для Поставщиков данных).

Потребителям данных необходимо оформить заявку в СЦ с указанием проблемы и Назначить на ведомство поставщика.

5) Обработка ответа на стороне Ядра СМЭВ4 (пример прерывания выполнения запроса на этапе обработки ответа на стороне Ядра СМЭВ4 показан на рисунке 16):

Рисунок 16 – ЛК УВ. Судьба сообщения СМЭВ4. Обмен с ошибкой

На рисунке 16 статус обмена «Прерван с ошибкой». В данном примере ошибка возникла на обработке ответа на стороне Ядра СМЭВ4. В ошибке обмена на стороне Ядра СМЭВ4 отображается следующая фраза: «Отмена запроса из-за истечения предельного срока выполнения запроса». Одна из причин – в самом запросе был выставлен лимит на выполнение, по истечению которого запрос прервался в ошибку (решение: выставить больше в -m 30).

Также бывают ошибки для асинхронных обменов (Рисунок 17):

Рисунок 17 – ЛК УВ. Судьба сообщения СМЭВ4. Обмен с ошибкой

В данном случае причин может быть несколько:

–   РЗ вызывался в асинхронном режиме. В рамках первого HTTP-запроса (метод POST) передался SQL-запрос с заданным таймаутом. Второй HTTP-запроса (метод GET) не был выполнен в заданный таймаут;
–   Также могли вызвать такой запрос, удалить и потом пытаться результат получить.

Мы рассмотрели всевозможные причины ошибок обмена на разных стадиях обработки запроса.

  Примечание

 Перед началом работы с РЗ необходимо проверить работу Агента СМЭВ4 (актуально как для поставщиков, так и для потребителей данных), чтобы убедиться, что Агент СМЭВ4 настроен корректно и у него есть связь с Ядром СМЭВ4

Для этого из консоли нужно направить в адрес Агента СМЭВ4 тестовый запрос Select 1:

curl -X POST -H "Accept-Version:1" -H "Content-Type: application/json" -d '{"sql": {"sql": "select 1"}}' http://localhost:8192/query --silent -m 30

Пример успешного ответа представлен на рисунке 18:

Рисунок 18 – Успешный ответ на тестовый запрос Select 1

В случае, если в ответ возвращается ошибка, рекомендуется просмотреть лог Агента СМЭВ4 на наличие ошибок.

Рекомендации для Поставщиков данных

На стороне Поставщика данных необходимо убедиться, что Витрина данных запущена и БД отвечает на запросы. Проверку можно осуществить в DBeaver. Для того, чтобы подключиться к БД, необходимо настроить DBeaver на работу через jdbc-драйвер (поставляется вместе с ПО «Витрина данных»).

Настройка jdbc-драйвера

1.      Откройте программу DBeaver.

2.      В главном меню программы необходимо выбрать вкладку Базы данных и нажать пункт Управление драйверами:

Рисунок 19 – ПО DBeaver

3.      В открывшемся окне Менеджер драйверов необходимо нажать кнопку«Новый»:

Рисунок 20 – ПО DBeaver. Менеджер драйверов

4.      В открывшемся окне «Создать драйвер» заполните следующую информацию:

• Имя драйвера: DtmDriver;
• Имя класса: ru.datamart.prostore.jdbc.Driver;
• Шаблон URL: jdbc:prostore://{host}:{port}.

Рисунок 21 – ПО DBeaver. Создание драйвера

5.      Установите маркер в поле «Без авторизации» и «Пустой пароль».

6.      Перейдите на вкладку Библиотеки, нажмите кнопку «Добавить файл» и укажите путь к jar-файлу jdbc-драйвера.

Рисунок 22 – ПО DBeaver. Создание драйвера

7.      Далее нажать кнопку «Ок»:

Рисунок 23 – ПО DBeaver. Создание драйвера

8.      После чего необходимо убедиться, что драйвер создался. Необходимо выбрать его из списка драйверов и нажать кнопку «Изменить» для того, чтобы подтянуть класс:

Рисунок 24 – ПО DBeaver. Менеджер драйверов

9.      В открывшемся окне драйвера необходимо перейти на вкладку Библиотеки, затем нажать на добавленный драйвер, чтобы выбрать его. Ниже в поле Класс драйвера: нажать кнопку «Найти Класс». Далее программа предложит выбрать класс ru.datamart.prostore.jdbc.Driver – необходимо выбрать класс, нажав на него, следом закрыть окно, нажав кнопку «Ок»:

Рисунок 25 – ПО DBeaver. Редактирование драйвера

Подключение к БД

Для подключения к базам данных через jdbc-драйвер выполните следующие действия:

1.      Откройте Dbeaver.

2.      В главном меню программы выберите пункт База данных > Новое соединение (Рисунок 26):

Рисунок 26 – ПО DBeaver

3.      В окне Создать соединение для удобства в поисковой строке необходимо ввести dtmdriver, выбрать созданный драйвер и после активации – нажать Далее >:

Рисунок 27 – ПО DBeaver. Создать соединение

4.      В открывшемся окне с настройками базового соединения на вкладке Главное необходимо ввести хост и порт машины где развёрнута база данных. В соответствии с этими данными необходимо вписать IP-адрес ВМ в хост, и порт (по умолчанию: 9090) и проверить соединение, нажав кнопку «Тест соединения …» внизу окна:

Рисунок 28 – ПО DBeaver. Создать соединение

В результате должно появиться окно с успешным соединением с базой данных по jdbc-драйверу (Рисунок 29):

Рисунок 29 – ПО DBeaver. Тест соединения с базой данных

5.      Чтобы сохранить настройки нажмите кнопку «Ок» и «Готово» в окне с настройками соединения.

6.      В результате в правой панели ПО DBeaver отобразится соединение с БД.

7.      Для начала убедитесь, что запущен Prostore. Проверка работы Prostore осуществляется запросом check_versions(); (Рисунок 30):

Рисунок 30 – ПО DBeaver. Запрос проверки версии Prostore

В случае, если Prostore не отвечает, необходимо подключиться к серверу, на котором располагается контейнер Prostore, и проверить что он запущен. Сделать это можно командой для отображения запущенных контейнеров:

docker ps

Найдите среди контейнеров контейнер dtm-query-execution-core. Пример ниже:

Рисунок 31 – Сервер с Prostore. Команда просмотра запущенных контейнеров

На примере можно увидеть, что приложение запущено 2 дня назад. Необходимо просмотреть логи контейнера. Пример командой ниже:

docker logs dtm-query-execution-core

В логах необходимо отследить и проанализировать причину ошибки. В случае необходимости собрать лог и направить с заявкой в СЦ на команду Витрин данных. В случае рестарта контейнера необходимо также оформить заявку в СЦ.

8.      Далее необходимо проверить что данные в БД есть. Проверка наполнения БД осуществляется запросом к таблице витрины. 

use name_db; select * from name_db.table limit 1

где: 

–   name_bd – это название базы данных (часто совпадает с мнемоникой Витрины данных);
–   table – название таблицы Витрины данных.

Первый запрос оповещает Витрину данных о том, что следующие запросы будут обращаться к данной БД витрины. Пример ниже:

Рисунок 32 – ПО DBeaver. Запрос к БД Витрины данных

Второй запрос – запрос к таблице БД Витрины данных. Пример ниже:

Рисунок 33 – ПО DBeaver. Запрос к таблице БД Витрины данных

В результате мы убедились, что Витрина данных работает и в ней есть данные. Далее необходимо убедиться, что у Витрины данных есть связь с Агентом Поставщиком.

Проверка связи Агента с Витриной данных

При условии, что Агент Поставщик работает исправно (тестовый запрос Select 1 отрабатывает – смотри рисунок 18), для проверки достаточно направить простой запрос в таблицу витрины.

Пример такого запроса:

curl -X POST -H "Accept-Version:1" -H "Content-Type: application/json" -d '{"sql": 
{"sql": "Select * from мнемоника_витрины.название_таблицы limit 10"}}' 
http://localhost:8192/query --silent -m 30

Данный запрос выведет все данные из таблицы, которые есть в БД. Рекомендуется задавать лимиты в таком запросе, если данных в БД много. В примере с витриной ГородаРФ в базе данных содержится всего одна добавленная запись, поэтому применяется запрос без лимита:

curl -X POST -H "Accept-Version:1" -H "Content-Type: application/json" -d '{"sql": 
{"sql": "select * from i_u038_gorodarf.gorodarf"}}' http://localhost:8192/query --silent -m 30

В результате можно увидеть одну запись в БД витрины (Рисунок 34):

Рисунок 34– Результат выполнения запроса к таблице витрины

В данном примере можно сделать вывод, что связь Витрины данных и Агента Поставщика установлена.

Что делать, если ответ на запрос не приходит (ответ не успевает вернуться в течение заданного таймаута)? Необходимо разбираться в причинах. 

При отправке запроса Агент СМЭВ4 должен положить сообщение в топик Витрины данных .query.rq. После этого компонент podd_adapter_query вычитывает это сообщение и передаёт Prostore. Далее Prostore передает сообщение в podd_adapter_mppr. В случае успеха podd_adapter_query кладет ответ в топик Витрины данных .query.rs, в случае ошибки кладет сообщение об ошибке в топик Витрины данных .query.err. Необходимо найти запрос в логе Агента, затем отследить, в какой из топиков он долетел, следом проверить в логах, попал ли он в Prostore. 

Для удобства просмотра содержимого топиков Kafka используется соответствующее лицензионное ПО. В качестве примера представлено приложение Offset Explorer. Настройка производится на порт ZooKeeper. При успешном подключении с права отобразятся все созданные топики Витрины данных:

Рисунок 35 – ПО Offset Explorer для отображения топиков kafka

Для детального разбора проблем следует составить заявку в СЦ и приложить к ней логи компонентов, в которых наблюдаются ошибки. Для помощи в составлении заявки рекомендуем воспользоваться статьёй – Алгоритм действия при возникновении проблем в работе витрины данных.