СПОСОБ И СИСТЕМА ВАЛИДАЦИИ СЛОЖНЫХ СТРУКТУР ДАННЫХ В КОМПЛЕКСНОЙ МИКРОСЕРВИСНОЙ АРХИТЕКТУРЕ С ВИЗУАЛЬНЫМ ОТОБРАЖЕНИЕМ РЕЗУЛЬТАТОВ Российский патент 2020 года по МПК G06F40/226 

ОБЛАСТЬ ТЕХНИКИ

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

УРОВЕНЬ ТЕХНИКИ

Из патента US7299408B1 (МПК G06F17/00, опубл. 2007-11-20) известно решение, описывающее валидацию электронных документов (ЭД). Известное решение включает прием ЭД, содержащего часть основных данных и часть для просмотра, причем часть основных данных может анализироваться отдельно от части просмотра, а часть просмотра включает в себя форматирование представления, по меньшей мере, для одного дисплея, соответствующего основной части данных; извлечение набора правил валидации, соответствующих ЭД, причем набор правил валидации включает в себя правила сравнения для определения, соответствует ли первое отображение, обеспеченное частью просмотра, основной части данных для первого набора значений; применение набора правил валидации к первому ЭД; определение того, что ЭД является действительным, на основе определения того, что первый дисплей по существу соответствует основной части данных для первого набора значений, при этом определение того, соответствует ли первый дисплей по существу основной части данных, включает в себя доступ к множеству связующих элементов в ЭД, в котором отдельные из множества связывающих элементов соответственно связывают первый атрибут и второй атрибут, причем первый атрибут соответствует значению основных данных для конкретного информационного поля в части основных данных, а второй атрибут соответствует данным вида значение для конкретного информационного поля в части просмотра и определение того, что первое отображение по существу соответствует основной части данных, где значение основных данных равно значению данных просмотра; и вывод результатов проверки ЭД для отражения определения того, что ЭД является действительным.

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

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

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

Кроме того, данное решение предполагает визуализацию результатов валидации на экраны, как один из этапов проведения проверки, тем самым не реализовано достаточное автоматизированное проведение проверок, что значительно увеличивает время проведения валидации.

Из уровня техники известно решение, описывающее способ исправления ЭД при его создании (наполнении структуры) и редактировании (US7657832B1, МПК G06F17/00, опубл. 2010-02-02). При этом способ содержит: выявление ошибки проверки в структуре ЭД XML, причем ошибка проверки является аспектом структуры ЭД XML, который не соответствует правилам определения типа документа XML или схеме XML, причем правила связаны с ЭД XML, причем ошибка валидации имеет особый вид, при этом идентификация ошибки валидации включает построение детерминированной конечной автоматизации из модели контента, определенной в определение типа документа ЭД XML, и определение ошибки валидации с использованием детерминированного конечного автомата; выбор шаблона предложения из множества шаблонов предложений в соответствии с конкретным видом ошибки проверки и использование выбранного шаблона предложения для предложения пользователю предложенных исправлений, которые предварительно определены в шаблоне для конкретного вида ошибки проверки, выбранного шаблона предложения включая логику, необходимую для изменения структуры ЭД XML в соответствии с правилами определения типа документа XML или схемы XML, при этом изменение структуры ЭД XML включает в себя переназначение элемента в структуре ЭД XML и перемещение элемента из текущего местоположение в новом месте в структуре ЭД XML; получение ввода, выбирающего одно из предложенных исправлений; и использование логики в выбранном шаблоне предложения для применения коррекции, выбранной входными данными, к электронному документу XML.

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

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

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

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

СУЩНОСТЬ ИЗОБРЕТЕНИЯ

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

Техническим результатом, достигающимся при решении вышеуказанной технической проблемы, является то, что использование способа валидации сложных структур данных в комплексной микросервисной архитектуре с визуальным отображением результатов способствует своевременному раннему обнаружению непригодных (неконсистентных) для дальнейшей обработки данных и ЭД, вносимых/загружаемых в систему дистанционного банковского обслуживания. При этом снижение уровня неконсистентных данных повышает качество обработки информации и увеличивает отказоустойчивость систем дистанционного банковского обслуживания клиентов.

Дополнительным результатом является повышение эффективности управления системами дистанционного банковского обслуживания за счет возможности выполнять настройки бизнес-контролей и задавать правила валидации для каждого отдельного ЭД и каждого его поля (атрибута).

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

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

получают сложную структуру данных (СД);

извлекают метаинформацию, соответствующую типу полученной СД из библиотеки метаинформации;

согласно метаинформации извлекают из библиотеки набор правил валидации, соответствующих полученной СД;

применяют набор правил валидации к СД для проверки целостности и достоверности первичных данных;

выявляют, по меньшей мере, одну ошибку проверки СД, причем ошибка проверки является аспектом структуры СД, которая не соответствует правилам валидации;

при этом выявленная, по меньшей мере, одна ошибка валидации включает построение детерминированной конечной автоматизации из модели контента;

выбирают шаблон из множества шаблонов предложений в соответствии с выявленным конкретным видом ошибки проверки и используют выбранный шаблон предложения;

исправляют по меньшей мере одну ошибку в соответствии с правилами валидации;

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

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

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

В другом частном варианте определение структуры СД включает в себя определение отсутствующего, постороннего, неуместного или несоответствующего структурного аспекта СД.

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

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

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

ОПИСАНИЕ ЧЕРТЕЖЕЙ

Реализация изобретения будет описана в дальнейшем в соответствии с прилагаемыми чертежами, которые представлены для пояснения сути изобретения и никоим образом не ограничивают область изобретения. К заявке прилагаются следующие чертежи:

Фиг. 1 иллюстрирует пример общей системы валидации сложных структур данных в комплексной микросервисной архитектуре;

Фиг. 2 иллюстрирует основные этапы реализации заявленного способа, в том числе этапов разработки компонентов системы.

ДЕТАЛЬНОЕ ОПИСАНИЕ ИЗОБРЕТЕНИЯ

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

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

С целью своевременной проверки данных и ЭД, получаемых от пользователей системой дистанционного банковского обслуживания (ДБО), для их своевременной обработки предложен способ валидации сложных структур данных в комплексной микросервисной архитектуре с визуальным отображением результатов.

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

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

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

Отличительной технической особенностью заявленного способа является декомпозиция процесса проверки, или контроля данных на независимые части, где,

• Первая часть - это данные;

• Вторая часть - это метаинформация, содержащая управляющую информацию о том, какие данные, где, когда и по каким правилам проверять (контролировать);

• Третья часть - это программный код, реализующий логику проверки данных.

Также отличительной особенностью способа является то, что проверка может проводиться в два этапа за счет использования правил Front-end и Back-end архитектур в компоновке системы, причем проведение проверок проводится, как и на Front-end контуре, так и на Back-end, таким образом, понижается нагрузка на модули Back-end архитектуры, что в свою очередь повышает отказоустойчивость предложенной системы валидации сложных структур данных

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

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

Исполняемая часть отвечает за реализацию проверок как на стороне сервера (Back-end), так и на стороне браузера пользователя (Front-end), в соответствии с определенными правилами проведения проверки каждого бизнес-контроля.

На Фиг. 1 представлен общий вид основных компонентов системы, управляющая часть выражена в микросервисе контролей (104), а исполняющая часть выражена в прикладном микросервисе (103). При этом технически возможно реализовать функции прикладного микросервиса и в компоненте (102), а также увеличить количество модулей для увеличения мощностей системы.

1) Компонент «101» - пользователь, который посредством браузера/мобильного приложения может вносить информацию, загружать данные и электронные документы в систему дистанционного обслуживания или формировать электронные документы самостоятельно. Таким пользователем может быть клиент, обслуживаемый в системе дистанционного обслуживания.

2) Компонент «102» - микросервис (или его фронтальная часть), расположенный в контуре front-end, который снабжен одним или несколькими программными модулями, функция которых заключается в хранении и применении наборов правил проведения проверок и правил (инструкций) для функционирования микросервиса. Компонент 102 взаимодействует с компонентом 103 посредством представления REST API для получения метаинформации бизнес-контролей, предусмотренных для выполнения валидации на front-end контуре.

3) Компонент «103» - микросервис, расположенный в контуре Back-end, который в свою очередь снабжен одним или несколькими программными сервисами, функция которых заключается в хранении и применении наборов базовых правил проведения проверок и правил (инструкций) микросервиса; базой данных, в которой хранится библиотека метаинформации бизнес-контролей, специфичных для каждого типа электронного документа (предусмотренных для обработки в системе дистанционного обслуживания); одним или несколькими программными сервисами для взаимодействия с библиотекой бизнес-контролей; модулем API микросервиса контролей.

Прикладной микросервис выполняет исполняющую часть заявленного способа.

4) Компонент «104» - микросервис, выполняющий функцию управления бизнес-контролями и применением правил, предоставляет REST API для управления метаинформацией контролей для конкретных типов ЭД. Микросервис снабжен несколькими модулями: базой данных, в которой хранятся настройки для управления проведением проверок, назовем это библиотекой бизнес-контролей; одним или несколькими модулями, функция которых заключается в управлении процедурой проверки электронного документа; модулем взаимодействия с библиотекой бизнес-контролей.

5) Компонент «105» - админ консоль - микросервис, который предоставляет внутреннему пользователю управлять параметрами микросервиса контролей по типам ЭД, предоставляет REST API для доступа к настройкам контролей.

Все правила реализуются единообразно и группируются в зависимости от типа ЭД и переносятся в систему. При этом общие контроли формируют отдельную библиотеку и могут быть применены для валидации как ЭД, так и прочих структур данных. Такой модульный подход позволяет организовать разработку и развертывание контролей, реализованных в разных функциональных стримах, независимо, и минимизировать их влияние друг на друга.

В реализации выделяются следующие элементы:

1. Библиотека управления метаданными реализует функциональность по созданию, конфигурированию и исполнению контролей. Предоставляет доступ к структурам данных в PostgreSQL в которых хранятся настройки контролей.

2. Back-end реализация (правило) предназначена для исполнения контролей на стороне сервера. Реализуется в виде набора Java-классов.

3. Front-end реализация (правило) предназначена для исполнения на стороне браузера пользователя. Реализуется в виде набора JavaScript- функций.

4. Микросервис предоставляет REST API для доступа к настройкам контролей.

Реализация на «Back-end» контуре - предназначена для исполнения контролей на стороне сервера (серверов). Реализация «Front-end» контуре - предназначена для исполнения на стороне фронтальной части в браузере/мобильном приложении пользователя и предполагается для выполнения элементарных проверок, например, таких как:

- Проверка поля на непустоту;

- Проверка поля на длину;

- Проверка поля на корректность введенных символов;

- Проверка значения поля;

- Номер документа не состоит из одних нулей.

Бизнес-контроль состоит из следующих частей:

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

Правило - исполняемая логика проверки. Каждое правило имеет уникальный идентификатор - ruleId.

Описание бизнес - контролей формируется заранее для каждого типа электронного документа заранее.

Это примерный перечень элементарных проверок, которым не ограничивается заявленное решение и, который может изменяться. Признак элементарности того или иного бизнес-контроля устанавливается в библиотеке бизнес-контролей.

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

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

• доменную модель и физическую структуру данных для хранения бизнес-контролей;

• сервисы для управления и использования бизнес-контролей;

• набор общих правил для конфигурирования бизнес-контролей.

Это самый первичный этап, который реализуется разработчиком системы и отображен на этапе «201».

Далее разработчик создает (202) модули, за счет которых возможно управлять бизнес-контролями, в том числе создавать и (или) удалять и (или) изменять бизнес-контроли, таким образом, разрабатывается логика функционирования прикладного микросервиса (103). Для управления бизнес-контролями разработчик реализует микросервис контролей (104), в рамках которого предоставляется API для взаимодействия с микросервисом админ консоль (105), функция которого заключается в управлении бизнес-контролями над ЭД пользователям (как правило, внутренним пользователям) системы.

Затем внутренний пользователь системы может приступать к управлению бизнес-контролями - этап «203». Это значит то, что теперь внутренний пользователь системы дистанционного обслуживания клиентов может настраивать бизнес-контроли, формировать перечни бизнес-контролей к виду электронного документа или другим образом вносить изменения в базу данных микросервиса контролей (104) - библиотеку бизнес-контролей. После того, как бизнес-контроли сформированы внутренним пользователем и в части логики исполнения контролей были добавлены в микросервис контролей (104), то метаинформация бизнес-контролей переносится (204) в исполняющую часть способа в прикладной микросервис (103) и сохраняется в библиотеке метаинформации.

Далее уже внешний пользователь системы, например, клиент, может создавать или загружать ЭД (205), а система будет осуществлять автоматическую процедуру валидации ЭД со сложной структурой данных (206).

Ниже в таблице 1 приведены обязательные параметры для метаданных контроля в заявленном способе.

Таблица 1

№ Параметр Свойства параметра 1 Наименование контроля Краткое наименование контроля. 2 Описание логики контроля Текстовое описание логики контроля. 3 Набор тегов Тег (или лэйбл) - категория, к которой относится контроль. Возможно создавать любой набор тегов и привязывать их контролю для дальнейшей фильтрации списка всех контролей. Возможные варианты: Запросы на депозит, Зарплатный проект, и т.д. 4 Принадлежность контроля типу документа/бизнес-объекту Системы Задает условие срабатывания контроля - принадлежность контроля к типу документа/объекта (например, Платежное поручение, Поручение на перевод валюты, Справочник корреспондентов и пр.).
Возможность изменения данного параметра предусмотрена только для элементарных контролей 5 Принадлежность контроля Клиенту (Внешнему Пользователю) Задает условие срабатывания контроля - принадлежность документа (к которому применяется контроль) Клиенту (организации).
Возможно задавать как общую принадлежность всем Клиентам Банка, так и конкретным Клиентам/группам Клиентов. При этом настройка по конкретным Клиентам имеет приоритет над общей настройкой. 6 Принадлежность контроля подразделению Банка Задает условие срабатывания контроля - принадлежность документа (к которому применяется контроль) подразделению Банка. Можно задавать как общую принадлежность всем подразделениям Банка, так и задавать конкретные подразделения. 7 Набор сервисов (каналов обслуживания) ДБО Задает условие срабатывания контроля - канал обслуживания ДБО (интернет-клиент/мобильный клиент и пр), в котором применен метод, вызывающий контроль. 8 Этап жизненного цикла (ЖЦ) Настройка параметра этапа жизненного цикла документа, на котором должен сработать контроль. Перечень этапов ЖЦ должен быть предопределен для каждого контроля. 9 Признак использования контроля Определяет, нужно ли запускать контроль. Возможные варианты: активен/неактивен 10 Признак применения контроля на front-end до обращения к back-end Суть механизма - при загрузке страницы на front-end, из back-end подтягиваются параметры таких контролей и встраиваются в код страницы.
При разработке контроля заложена соответствующая логика (алгоритм), реализующая данный механизм, а также определена возможность в целом использования данного механизма в контроле 11 Уровень проверки Определяет строгость проверки данных (влияет на результат применения метода к объекту). Возможные варианты: ошибка/предупреждение 12 Приоритет контроля Задает последовательность запуска контролей, объединенных в одну группу. Указывается порядковый номер, в соответствии с которым выполняется данная проверка. Например, 1,2,3,… 13 Набор изменяемых параметров проверки Для каждого контроля предоставлен набор параметров, которые можно изменять через UI (например, для контроля на длину номера документа - необходимо предоставить возможность изменять параметры контроля "Длина документа максимальная" и "Длина документа минимальная" (либо количество символов - от и до).
Для задания условий изменяемых параметров предусмотрена возможность использования регулярных выражений (например, для контроля на допустимые символы для числового поля условие проверки может выглядеть как [0-9]). 14 Логика проверки Непосредственно код (на java/javascript), реализующий логику проверки. На UI недоступен. 15 Дата и время вступления в силу новых настроек контроля Возможность применения настроек как моментально, так и начиная с заданной даты 16 Сообщение, отображаемое на UI в случае ошибки прохождения контроля. При этом на UI выделяется поле, в котором возникла ошибка контроля - т.е. предусмотрена привязка контроля к конкретному полю на UI.
Данный параметр формируется динамически. На основании выполнения логики проверки (параметр 14) возвращается ключ (идентификатор) сообщения об ошибке, по которому на UI определяется текст сообщения (хранится в файле локализационных ресурсов) на языке, установленном для пользовательского интерфейса (локально). 17 Сообщение подсказка для устранения ошибки Данный параметр формируется динамически аналогично параетру 16. Ключ сообщения формируется путем добавления суффикса '.help' к ключу соообщения об ошибке (см. параметр 16)

В таблице 2 приведена примерная библиотека выполняемых контролей.

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

Таблица 2

Тип Описание Требования к реализации Сообщение на GUI Реализация Параметры Общие контроли (независимо от типа электронного документа) Элементарный Проверка поля на непустоту 1. Контроль возможно использовать как на back-end, так и на front-end;
2. Через GUI должна быть предоставлена возможность указывать, к какому атрибуту документа должен быть применен контроль
3. Остальные параметры должны быть настраиваемы (в рамках концепции контролей). "Поле <FieldName> должно быть заполнено." NotNullRule
NotEmptyRule нет Элементарный Проверка поля на длину 1. Контроль возможно использовать как на back-end, так и на front-end;
2. Через GUI должна быть предоставлена возможность настройки следующих параметров:
1. указывать, к какому атрибуту документа должен быть применен контроль;
2. максимальное количество символов для поля (в случае применения на front-end возможно физически запретить ввод больше числа символов);
1. минимальное количество символов для поля.
2. Остальные параметры должны быть настраиваемы (в рамках концепции контролей). "Длина поля <FieldName> не должна превышать X символов" (в случае превышения)
"Длина поля <FieldName> не должна быть меньше Y символов" (в случае ввода меньшего числа символов) SizeRule 1. min - минимальное количество символов для поля;
2. max - максимальное количество символов для поля Элементарный Проверка поля на корректность введенных символов 1. онтроль возможно использовать как на back-end, так и на front-end;
2. Через GUI должна быть предоставлена возможность настройки следующих параметров:
1. указывать, к какому атрибуту документа должен быть применен контроль;
2. указывать допустимые либо запрещенные символы (в виде регулярного выражения);
3. Остальные параметры должны быть настраиваемы (в рамках концепции контролей). "В поле <FieldName> введены некорректные символы" PatternRule 1. regexp - регулярное выражение которому должно соответствовать значение поля Элементарный Проверка значения поля 1. Контроль возможно использовать как на back-end, так и на front-end;
2. Через GUI должна быть предоставлена возможность настройки следующих параметров:
1. указывать, к какому атрибуту документа должен быть применен контроль;
2. максимальное значение для поля;
3. минимальное значение для поля.
3. Остальные параметры должны быть настраиваемы (в рамках концепции контролей). "Значение поля <FieldName> не должна превышать X " (в случае превышения)
"Значение поля <FieldName> не должна быть меньше Y" (в случае меньшего значения) RangeRule 1. min - минимальное значение поля;
2. max - максимальное значение поля Неэлементарный Проверка дат 1. Контроль возможно использовать как на back-end, так и на front-end;
2. Через GUI должна быть предоставлена возможность настройки следующих параметров:
1. указывать, к какому атрибуту (дата) документа должен быть применен контроль;
2. указывать, с каким атрибутом (дата) будет происходить сравнение;
3. указывать, какую логическую операцию (например, FieldName > FieldName2); "Дата <FieldName> должна быть <больше/меньше/равной> дате <FieldName2>" CompareDateFieldsRule 1. operand - операция сравнения (">", "<", "=") Общие контроли для платежных документов Неэлементарный Проверка корректности заполнения ИНН 1. Контроль возможно использовать как на back-end, так и на front-end;
2. Сложный контроль - должен использовать следующую логику:
1. длина поля ИНН = 10, 12, 5 символов или 1 символ со значением "0")
3. Остальные параметры должны быть настраиваемы (в рамках концепции контролей). "ИНН имеет недопустимую длину." Нереализовано 1. innSize - количество символов в ИНН Неэлементарный Проверка допустимости даты 1. Контроль возможно использовать как на back-end, так и на front-end;
2. Сложный контроль - должен использовать следующую логику:
а. Допустимое число дней опережения;
b. Допустимое число дней просрочки;
3. Остальные параметры должны быть настраиваемы (в рамках концепции контролей). "В поле <FieldName> введена некорректная дата документа" ValidDataRule 1. minDays - допустимое число дней просрочки
2. maxDays - допустимое число дней опережения Элементарный Номер документа не состоит из одних нулей 1. Контроль возможно использовать как на back-end, так и на front-end;
2. Через GUI должна быть предоставлена возможность указывать, к какому атрибуту документа должен быть применен контроль "Поле <FieldName> не может быть заполнено нулями" PatternRule 1. regexp - регулярное выражение которому должно соответствовать значение поля Неэлементарный Проверка кода страны справочнику 1. Контроль возможно использовать как на back-end, так и на front-end;
2. Через GUI должна быть предоставлена возможность указывать, к какому атрибуту документа должен быть применен контроль "В поле <FieldName> данные о стране не совпадают со справочником стран" DictionaryByIdRule 1. clazz - имя класса, реализующего справочник
2. idField - наименование поля, являющегося первичным ключем в справочнике
1. checkedFields - наименнования полей справочника для сравнения

Все правила реализуются единообразно в виде Spring бинов, которые группируются в зависимости от типа ЭД и добавляются в систему в виде jar-файлов. При этом общие контроли формируют отдельную библиотеку и могут быть применены для валидации как ЭД. Такой модульный подход позволяет организовать разработку и развертывание контролей, реализованных в разных функциональных стримах, независимо, и минимизировать их влияние друг на друга.

При этом метаданные:

- Предназначены для хранения информации о доступных контролях, их реализациях и ассоциируемых с ними ЭД;

- Частично конфигурируются посредством административной консоли;

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

Back-end реализация:

- Каждый контроль реализуется в виде отдельного java-класса по общему шаблону;

- Контроли активируется в рамках переходов по жизненному циклу документа;

- В исполняемый модуль (jar) для каждого EP включаются все java-классы, реализующие контроли, ассоциируемые с типом ЭД для которого сконфигурирован данный EP;

- Список сконфигурированных контролей для каждого этапа жизненного цикла ЭД формируется непосредственно перед выполнением EP на основании обращения к метаданным.

Front-end реализация (только элементарные контроли) может быть настроена таким образом, чтобы применяться к отдельным типам электронных документов:

- Контроли реализуются в виде разделяемой javascript-библиотеки по общему шаблону;

- Список сконфигурированных контролей формируется и передается на front-end в процессе отрисовки конкретной экранной формы (REST-запрос к метаданным в back-end);

- Для каждого контроля передаются следующие данные:

- название javascript-функции, реализующей контроль;

- атрибут ЭД к которому применяется контроль;

- значения параметров, используемых javascript-функцией в процессе выполнения проверки.

- Выполнение контролей активируется соответствующим событием (например, нажатие кнопки "сохранить").

Таким образом, проведение процедуры, в ходе которых проводится проверка ЭД, имеющего сложную структуру данных, может происходить в несколько этапов - сначала может быть применены бизнес-контроли и валидация документа в контуре Front-end, затем применяются бизнес-контроли и валидация из контура Back-end.

Такое разделение позволяет не применять полностью все бизнес-контроли к документам, например, заполненным пользователем вручную в заранее обозначенные системой области, к которым достаточно применить бизнес-контроли по общему шаблону. Таким образом, пользователю сразу сообщают о наличии ошибки или, наоборот, о том, что данные введены верно.

Подробнее процедура проведения валидации разъясняется на приведенном ниже примере.

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

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

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

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

В случае если значение соответствует успешному прохождению бизнес-контроля, документ сохраняется в средствах хранения, в соответствующей структуре данных предназначенной для хранения данного типа документа для его последующей обработки в системе дистанционного обслуживания, а пользователю сообщается (207) статус валидации документа «Успешно».

Если в управляющей части установлено, что атрибут "Дата создания" не относится к категории элементарных контролей, то выполняется основная процедура валидации реализованная на контуре Back-end, и тогда валидация документа выполняется следующим образом:

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

2. Определив актуальный набор контролей (в примере ограничились одним бизнес-контролем для документа - это контроль атрибута "Дата создания", в реальной жизни их может быть сколько угодно много), выполняется последовательная проверка соответствия значений атрибутов документа правилам, сконфигурированным для найденных контролей.

При этом для каждого контроля выполняется следующая последовательность действий:

a. Получить значения атрибутов документа используемых в логике контроля;

b. Применить логику контроля к полученным значениям с учетом параметров контроля;

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

3. По результату применения всех контролей формируется итоговый список обнаруженных несоответствий.

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

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

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

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

Таким образом, заявленное решение позволяет осуществить автоматическую валидацию сложных структур данных в комплексной микросервисной архитектуре с визуальным отображением результатов, своевременно обнаруживать непригодные (неконсистентные) для дальнейшей обработки данные и ЭД, вносимые/загружаемые в систему банковского обслуживания. Дополнительно позволяет повысить эффективность управления системами банковского обслуживания за счет возможности выполнять настройки бизнес-контролей и задавать правила валидации для каждого отдельного ЭД и каждого его поля (атрибута), а также распределить нагрузку на исполняющие модули, что в свою очередь повышает отказоустойчивость предложенной системы валидации сложных структур данных в комплексной микросервисной архитектуре.

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

Изобретение относится к области вычислительной техники. Техническим результатом является обеспечение валидации сложных структур данных в комплексной микросервисной архитектуре. Раскрыт компьютерно-реализуемый способ валидации сложных структур данных в комплексной микросервисной архитектуре, содержащий этапы, на которых: получают сложную структуру данных (СД); извлекают метаинформацию, соответствующую типу полученной СД из библиотеки метаинформации; согласно метаинформации извлекают из библиотеки набор правил валидации, соответствующих полученной СД; применяют набор правил валидации к СД для проверки целостности и достоверности первичных данных; выявляют по меньшей мере одну ошибку проверки СД, причем ошибка проверки является аспектом структуры СД, которая не соответствует правилам валидации; при этом выявленная по меньшей мере одна ошибка валидации включает построение детерминированной конечной автоматизации из модели контента; выбирают шаблон из множества шаблонов предложений в соответствии с выявленным конкретным видом ошибки проверки и используют выбранный шаблон предложения; исправляют по меньшей мере одну ошибку в соответствии с правилами валидации; выводят результат проверки СД для отражения определения того, что СД является действительным. 2 н. и 5 з.п. ф-лы, 2 ил., 2 табл.

1. Компьютерно-реализуемый способ валидации сложных структур данных в комплексной микросервисной архитектуре, содержащий этапы, на которых:

получают сложную структуру данных (СД);

извлекают метаинформацию, соответствующую типу полученной СД из библиотеки метаинформации;

согласно метаинформации извлекают из библиотеки набор правил валидации, соответствующих полученной СД;

применяют набор правил валидации к СД для проверки целостности и достоверности первичных данных;

выявляют по меньшей мере одну ошибку проверки СД, причем ошибка проверки является аспектом структуры СД, которая не соответствует правилам валидации;

при этом выявленная по меньшей мере одна ошибка валидации включает построение детерминированной конечной автоматизации из модели контента;

выбирают шаблон из множества шаблонов предложений в соответствии с выявленным конкретным видом ошибки проверки и используют выбранный шаблон предложения;

исправляют по меньшей мере одну ошибку в соответствии с правилами валидации;

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

2. Способ по п. 1, характеризующийся тем, что выбирают шаблон из множества шаблонов в соответствии с выявленным конкретным видом ошибки проверки и используют выбранный шаблон.

3. Способ по п. 2, характеризующийся тем, что шаблон реализован в виде списка программ.

4. Способ по п. 1, характеризующийся тем, что определение структуры СД включает в себя определение отсутствующего, постороннего, неуместного или несоответствующего структурного аспекта СД.

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

6. Система валидации сложных структур данных в комплексной микросервисной архитектуре для реализации способа по любому из пп. 1-5, содержащая:

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

7. Система по п. 6, отличающаяся тем, что позволяет применять правила валидации СД как на стороне пользователя, так и на стороне прикладного микросервиса.