Подсистема контроля типов и

шаблонов данных
(Расширение задачи Задача №12492)

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

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

Общее описание решение

Реализация подсистемы контроля типов и шаблонов данных (далее КТШ или подсистема) должна
состоять из следующих механизмов:

1. Механизм справочника данных - описание всех поступающих в систему данных, включая: тип,
условия применения формата, условия обязательности, прочее условия (точка расширения).
2. Механизм базового контроля – проверка поступающих данных, выполняемая как на стороне
серверной части системы, так и на сторонне клиентской части.
3. Механизм оперативного контроля – непосредственная проверка данных в процессе их
редактирование (ввода) выполняемая на стороне клиента.
4. Абстрактной механизм конвертирование данных – специальная часть механизмов
интеграции с внешними ИС, выполняемая как неотъемлемая часть конкретного
интеграционного процесса, но основанная на общем для системы справочнике данных.
Основой КТШ является Механизм справочника данных (МСД), все остальные механизмы
функционируют на его основе, что должно обеспечивать простое, централизованное управление
форматами данных без изменения программного кода.

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

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

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

Механизм справочника данных (МСД)

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

МСД должен включать:

1. Подсистему хранение метаданных в форма справочника.
2. Механизм редактирования метаданных.
3. Подсистему выгрузку и передачи метаданных клиентским приложениям.

Подсистема хранение метаданных

Состоит из трех элементов:
1. Формат хранения.
2. Язык описание правил применения шаблонов.
3. Языка описания шаблонов.

Формат хранения – должен основываться на существующем формате хранения метаданных,

используемом для механизма настройка обязательного заполнения полей КВ (Настройки ->
Администрирование -> Настройка обязательных поле…).

Или (что значительно проще(!)) являться простым XML файлом. Такая реализация должна
иметь подробную ХSD-схему описывающую пользовательские типы данных с учетом всех
возможный перечислений (а не только базовый типов) – что позволить полностью исключить
ошибки пополнения справочника при его ручном редактировании.

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

Является полным аналогам «языка описания правил условий обязательности», задачи №12492..

Языка описания шаблонов - должен быть реализован в виде простого интерпретатора,

основанного на методе «рекурсивного спуска» (описание языка см. в приложении
«Предварительное описание языка шаблонов»).

Основным требование к языку описания шаблонов является требование простоты реализации и

расширяемость.

Механизм редактирования метаданных

Механизм редактирования метаданных может основываться на существующем механизме
настройки обязательного заполнения полей КВ (Настройки -> Администрирование ->
Настройка обязательных поле…).

Или (что значительно проще(!)) являться простым XML файлом, который одновременно
может являться и форматом хранения, что значительно проще для реализации.

Механизм выгрузки и передачи метаданных.

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

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

Механизм базового контроля (МБК)

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

На промежуточном этапе реализации, когда часть системы может использовать старые

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

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

Состав частей МБК:

1. Механизм загрузки и обновления метаданных.
2. Механизм контроля соответствия условию обязательности.
3. Механизм контроля соответствия условию типа.
4. Механизм контроля соответствия условию шаблона.
5. Механизмы для прочих видов контроля (точка расширения).

Механизм загрузки и обновления метаданных

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

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

В общем случае, рекомендуемый механизм обновления НСИ следующий:

1. При первом входе в систему (или как часть инсталляционного процесса) должна
осуществляться полная загрузка НСИ.
2. Далее должна быть выполнена подписка на обновления с контролем номера последнего
успешно полученного обновления.
3. При обнаружении пропусков обновлений, должен выполняться запрос на обновление с
последнего успешного номера.

При обновлении НСИ должны учитываться не только новые, но и удаленные и измененные

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

Механизм контроль соответствия условию обязательности

Контроль соответствия условию обязательности (описан в задача №12492) и включает проверку
безусловной и условной обязательности на основе правил «язык правил условно
обязательности».

Контроль соответствия условию типа

Для строго типизированных ЯП выполняется автоматически как часть декларации типов
переменных.
Для слабо типизированных ЯП должно выполняться приведение к требуемому типу на основе
МСД.

Контроль соответствия условию шаблона

Контроль соответствия условию шаблона может состоять из двух вариантов проверок:

1. Проверка на основе регулярных выражений, основанная на стандартных библиотеках.

2. Проверка на основе шаблона.

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

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

МОК включает:

1. Механизм предоставления пользователю оперативной информации о данных.

2. Механизм оперативной проверки по полным и неполным данным.
3. Механизм оперативного преобразования данных в соответствие с требованиями шаблона.

Механизм предоставления пользователь оперативной информации

Форма ввода данный должны иметь возможность информировать пользователя о данных
использую различные индикаторы:

 специальный тип поля ввода для определенного типа данных;

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

Механизм оперативной проверки данных по полным, и неполным данным

Проверка по полным данным.

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

Конкретная реализация должна советовать существующим правилам построение GUI.

Проверка по неполным данным.

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

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

Механизм оперативного контроля (МОК)

Является специальным расширением оперативной проверки. Может использоваться как
дополнение для всех описанных механизмов подсистемы.
Проверка должна позволять выполнять следующие простые преобразования:

 авто-перевод символа в другой регистр;

 авто-перевод символа в требуемую клавиатурную раскладку;
 авто-вставка последующего константного символа.
 авто-перевод последовательности чисел в дату и/или время;
 авто-формирование следующего номера (идентификатора)
 и т.п.

Абстрактный механизм конвертирования данных (АМКД)

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

АМКД не является самостоятельным модулем и в конечном виде должен быть реализован как
неотъемлемая часть конкретного интеграционного механизма (шлюза, адаптера и т.п.).

Т.к. при интеграции с внешними ИС их формат обмена данными заранее не известен (или может
со временем меняться), АМКД должен представлять из себя набор абстрактных сущностей
(видимо классов) определяющих на сами действия, а принципы реализации.

АМКД включает:

1. Абстрактный конвертор входящих данный.

2. Абстрактный конвертора исходящий данных.

Абстрактный конвертор входящих данный

Должен обеспечивать:

1. Получение некоторого набора данный от внешней ИС , без уточнения его состава.

2. Преобразования каждого элемента полученный данных в советующий элемент
справочника данный. Правила преобразования определится для каждого элемента
отдельно.
3. Передачу отдельного элемента или его группы элементов в МБК для проверки.

Абстрактный конвертора исходящий данных

Должен обеспечивать:

1. Получение некоторого набора данный сервисов системы.

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

Приложения
Предварительное описание языка шаблонов и правил (ЯШ/П)
После согласования подсистемы.

Предварительное описание интерпретатора ЯШ/П.

После согласования ЯШП.