10. Проверка форматно-логического контроля

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

Таблица 10.15 Список реализованных проверок

Наименование проверки	Код ошибки	Кирилическое описание
Проверка уникальности	dublicate	Дубликат файла/группы
Проверка парсинга файла	parsingErr	Ошибка парсинга: текст ошибки
Проверка кодирования	encodingErr	Кодировка файла не соответствует кодировке UTF-8
Проверка превышения предельного размера файла (больше 512 Мб)	tooLargeFile	Слишком большой файл
Проверка наличия данных в файле	emptyFile	Пустой файл
Проверка соответствия заголовков инфосхеме	wrongMetadata	Структура файла не соответствует схеме
Проверка соответствия числа столбцов в строке	wrongFieldsCount	Некорректное число столбцов в строке
Проверка соответствия типам полей	wrongFieldType	Значение не соответствует типу требуемый тип
Проверка уникальности полей	nonUniq	Значение не отвечает требованиям уникальности
Проверка регулярных выражений	nonMatchRegex	Значение не соответствует регулярному выражению регулярное выражение
Проверка соответствия условию	nonMatchConstant	Значение не соответствует условию условие
Таймаут валидации	validationTimeout	Истек таймаут валидации файла

10.1. Синхронная проверка ФЛК

Примечание

• выполняются вне зависимости от настроек модуля REST-Uploader;

• являются блокирующими;

• ошибки синхронных проверок возвращаются в теле ответа по REST-API.

К синхронным проверкам относятся:

• проверка соответствия инфосхеме:

  • проверка соответствия имен и количества полей в заголовках;

  • проверка типа данных;

  • проверка экранирования данных: проверка соответствия числа столбцов по каждой строке;

• проверка соответствия файла кодировке UTF-8 , отсутствие BOM (при наличии BOM отрезаем при загрузке начальные байты ef bb bf);

• проверка размера файла и наличия данных:

  • проверка предельного размера загружаемого файла 512Мб;

  • проверка наличия данных в файле.

10.2. Асинхронная проверка

Примечание

• выполняются в зависимости от настроек модуля;

• проверки не являются блокирующими (поведение при их наличии определяется конфигурацией модуля);

• список проверок уникален для каждой таблицы и хранится в Zookeeper в виде отдельного YAML файла.

К асинхронным проверкам относятся:

• проверка уникальности полей:

  • по сочетанию атрибутов (для комплексных ключей);

  • по заданному атрибуту;

• сравнение значения с константой;

• соответствие регулярному выражению.

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

10.2.1. Проверка уникальности по одному или по сочетанию полей

Проверка уникальности проводится:

• в рамках группы файлов, если заданы headers - для проверки в рамках группы обязательно заполнения всех полей:

  • group_id;

  • group_file_num;

  • group_file_count.

• при проверке в рамках группы значения ключей для проверки уникальности в рамках группы хранится в Redis

  • по всем файлам в рамках группы при наличии групповых атрибутов

  • по одному файлу, при отсутствии групповых атрибутов

Пример запроса для проверки уникальности по группе файлов:

--проверка по сочетанию полей
fields:
  id:
    uniq: true
    uniq-with: [type,region]
--проверка уникальности по одному полю
  snils:
    match: "/^[-\s\d]{11}$/"
    uniq: true

10.2.2. Проверка соответствия заданному значению

• Проверка соответствия заданному значению проводится для каждого файла вне зависимости от наличия group_id

• Проверка осуществляется для значений каждого поля в соответствии с заданным правилом

• Проверка соответствия заданному значению включает в себя:

  • проверку сравнения с константой („>“, „<“, ‘> =“, „<=“, „=“, „!=“ );

  • проверку соответствия регулярному выражению (должна выполняться на основе Java Util Regexp https://docs.oracle.com/javase/7/docs/api/java/util/regex/package-summary.html )

10.2.3. Поведение в случае таймаута валидации

Период выполнения асинхронных проверок определяется конфигурационным параметром validation-timeout и по умолчанию составляет 60 минут.

В случае, если за указанное в настройках время асинхронные проверки не были выполнены, файл удаляется из очереди с обогащением отчета о найденных ошибках ошибкой validationTimeout.

В случае возникновения подобной ошибки рекомендуется:

• проверить регулярные выражения, по которым происходит проверка, так как неверно заданное регулярное выражение кратно увеличивает скорость проверки;

• увеличить значение validation-timeout и повторить загрузку данных.

10.3. Статусная модель

Таблица 10.16 Статусная модель

Статус	Наименование	Описание статусов
-1	Загрузка данных в буффер	Получение данных от клиента и загрузка их на сервер
0	Запрос буфферизирован	Загружаемые данные, получены сервером и находятся в очереди на обработку
1	Ожидает открытия дельты	Загружаемые данные находятся на сервере и ожидают открытия дельты в сервисе Prostore
2	В обработке (модулем DATA-Uploader)	Выполняется загрузка данных в Prostore модулями Витрины
3	Успешно обработан	Данные успешно загружены
4	Ошибка обработки запроса	В процессе загрузки данных возникла ошибка
5	Идентификатор запроса не обнаружен	Запрошен статус по неизвестному идентификатору запроса
6	Форматно-логический контроль	Выполняется форматно-логический контроль загружаемых данных
7	Ошибки ФЛК	В процессе выполнения форматно-логического контроля загружаемых данных возникли ошибки. При возникновении ошибки можно выполнить GET запрос requests/{request_id}/report/