Этапы реализации проектов¶
Статья описывает общую логику реализации проектов в системе Юнидата: от момента работы над проектным решением до загрузки данных. Реализация выполняется в несколько этапов. Описанные ниже этапы имеют рекомендательный характер, и отражают сбалансированный подход к внедрению системы Юнидата. Помимо указанных работ могут выполняться и другие работы: вспомогательные, организационные и т.д.
Основные этапы¶
Этап 1. Разработка проектного решения
Этот этап позволяет подготовить все необходимые данные для реализации проекта в системе Юнидата. Этап может быть опущен, но рекомендован к прохождению.
Общий анализ проекта. Формируются цели проекта, описываются основные вехи и ключевые показатели, объем работ и т.д.
Профилирование данных. Определяются и анализируются все информационные системы, которые будут выступать как источники данных для системы. Производится профилирование данных (например, с помощью Ataccama), в результате которого определяются форматы данных, какие данные уникальные, какие данные подходят для справочников/перечислений, наличие связей и т.д.
Аналитика: основные объекты системы. Описывается, как будет выглядеть модель данных, включая реестры/справочники с атрибутами, связями, правилами качества и прочее. В описании модели данных также содержится информация о том, из каких источников данных приходит информация в реестр/справочник, какие типы атрибутов будут назначены каждому атрибуту каждого реестра/справочника. Описываются роли, права доступа ролей и так далее.
Схема интеграции (опционально). Описание взаимодействия информационных систем, направления обмена данных, потоки и т.д.
Этап 2. Реализация проекта
Этап посвящен непосредственной работе с системой Юнидата.
Роли пользователей и права доступа. Только что установленная система не содержит ничего, кроме учетной записи суперпользователя (администратора с максимально полными правами доступа). В качестве первых шагов рекомендуется создать роли и раздать ролям права доступа. Эта задача может выполняться в несколько шагов. Первым шагом может стать распределение прав доступа для ролей администраторов системы. Второй шаг: распределение прав доступа для операторов данных. Второй шаг рекомендуется выполнять после публикации финальной версии модели данных, так как распределение прав доступа на реестры/справочники возможно только при их наличии.
Учетные записи пользователей. Создание учетных записей и назначение им соответствующих ролей. По аналогии с ролями, рекомендуется выполнять в несколько шагов: сначала создать пользователей-администраторов, затем операторов данных.
Модель данных: реестры/справочники, их атрибуты и связи. Общая задача: наполнение модели данных реестрами/справочниками. Наполнение может производиться как на основе аналитики, выполненной на этапе 1, так и без предварительной подготовки. Основные шаги наполнения модели:
Создание реестра/справочника. Задание основных свойств нового объекта, таких, как имя, тип, способ генерации внешнего ключа и т.д. Рекомендуется сначала создавать справочники, затем реестры. Причем, начинать следует с реестров, на которые ссылаются другие реестры.
Создание атрибутов. При добавлении нового атрибута должно быть понимание типа атрибута, типа его значения, функция атрибута и доступность атрибута для пользователей. Для справочника должны быть выделены обязательные кодовые атрибуты, и определен тип кодового атрибута.
Создание связей. Если реестры/справочники создавались в рекомендованной последовательности, то создание связей не потребует возврата к другим реестрам/справочникам и создания реестра/справочника специально под нужную связь. Также можно сначала создать все реестры/справочники, не заполняя вкладку «Связи», а затем в следующей итерации задать все связи.
Настройка консолидации. Задание веса каждому источнику данных, из которого приходят данные в реестр/справочник. Вес означает уровень доверия к источнику, и чем число выше, тем выше уровень. Системный источник данных (то есть, данные, созданные в системе) имеет значение 100. Вес должен быть не нулевым. Доступна настройка как для реестра/справочника в целом, так и для каждого атрибута по отдельности.
Отображение записи. Необходимо продумать, как визуально будет отображаться карточка записи. Сгруппировать атрибуты, удобным способом разместить все блоки с атрибутами/связями. Может выполняться на этапе, когда созданы все реестры/справочники и загружены данные.
Модель данных: правила качества. Правила можно создавать как в процессе создания реестра/справочника, так и отдельно. Подробнее читайте Правила качества. Для редакции СЕ: правила валидации обрабатываются, но не отображаются в интерфейсе пользователя.
Правила поиска дубликатов. Работу с правилами рекомендуется начинать после публикации финальной версии модели данных. Правила выполняются последовательно, поэтому необходимо определить верную последовательность применения правил внутри каждого реестра/справочника. Рекомендуемый порядок: от менее точных к более точным. Важно: для ускорения первоначальной загрузки рекомендуется выключить правила поиска дубликатов.
Для Standart и Enterprise редакций. Бизнес-процессы. Работу с бизнес-процессами рекомендуется начинать после публикации модели данных. Подробнее читайте Бизнес-процессы. Для Standart редакции: Отсутствует назначение на реестры/справочники; задачи создаются только вручную.
Единицы измерения. Настройку единиц измерения рекомендуется начинать после публикации модели данных. Как правило, информацию о всех используемых единицах измерения собирают в процессе профилирования и аналитики (этап 1). Затем, уже для готовой модели данных, создают списки единиц измерения, где назначают базовые единицы. Например, товары от разных контрагентов могут закупаться в разной валюте, а затем единицы измерения будут сводить все валюты к базовой (к примеру, в доллары). За счет этого можно искать записи по базовой единице измерения. Настройка единиц измерения производится вне интерфейса пользователя, в файле .xml, который импортируется в систему после настройки.
Загрузка данных (первоначальный импорт) в систему. Данные размещаются на информационную структуру, созданную в процессе этапа 2.
Правила качества¶
Настройку правил качества рекомендуется выполнять на первых этапах внедрения системы Юнидата, одновременно с настройкой модели данных.
Предварительно:
Выполнена аналитика проекта переноса данных в систему Юнидата: готово описание модели данных, функций обработки данных, правил качества и т.д.
Созданы функции обработки данных, которые будут использоваться в правилах качества. Для реализации проекта могут потребоваться как стандартные функции, так и пользовательские (простые или композитные). Важно, чтобы функции создавались с учетом будущего режима работы правила качества, в котором будет использоваться функция.
Функция, которая будет использоваться в правиле качества, работающем в режиме валидации, должна иметь минимум 1 логический исходящий порт (порт может быть пустым).
Функция, которая будет использоваться в правиле, работающем в режиме обогащения, может иметь исходящие порты любых типов.
Функция, которая будет использоваться в правиле, сочетающем режимы валидация + обогащение, должна иметь: минимум 1 логический исходящий порт и минимум 1 порт любого типа.
Вы можете воспользоваться одним из подходов к созданию правил качества.
Подход 1:
Создается новый реестр/справочник. Настроены основные свойства.
Создаются атрибуты реестра/справочника.
Создаются правила качества для реестра/справочника.
Реестр/справочник сохраняется. Переход к следующему реестру/справочнику.
Подход 2:
Создается набор реестров/справочников, настраиваются свойства и атрибуты.
Опционально: модель данных может быть опубликована для тестирования.
Создается набор правил качества для каждого реестра/справочника.
Первый подход удобен в случае, если заранее и полностью известно, как должна выглядеть модель данных, и какие правила качества должны в ней содержаться. Второй подход будет удобнее, если правила качества настраиваются и корректируются по ходу изменения или доработки модели данных. Например, если в процессе внедрения системы Юнидата изначальные результаты аналитики изменяются.
Рекомендации перед загрузкой данных. Следует использовать один из следующих способов:
Либо перед первоначальной загрузкой данных из разных систем все правила качества должны быть выключены. Иначе часть данных не будет загружена из-за ошибок валидации.
Либо должны быть включены те правила качества, которые должны быть применены на этапе загрузки (например, нормализация и очистка), чтобы данные загружались корректно и не требовали повторной загрузки данных.
Бизнес-процессы¶
Настройка бизнес-процессов может производиться в несколько этапов, распределенных по времени.
Предварительно:
Созданы роли пользователей (либо определены логические имена будущих ролей).
Первый этап. Описание и подключение. На этом этапе создается два файла:
.xml-файл, который, основываясь на нотации BPMN 2.0, описывает ход бизнес-процесса по шагам (включая роли пользователей, отвечающих за каждый шаг). Шаги бизнес-процесса в последствии будут отдельными задачами. Описание создается с помощью Activiti.
Вспомогательный Java-класс.
Файлы помещаются в каталоги системы Юнидата, а также прописываются в конфигурации.
Первый этап не завязан на других работах по настройке системы, и может выполняться сразу после развертывания системы.
Второй этап. Назначение. Бизнес-процессы могут быть назначены на события изменения записей и на события изменения. Соответственно, назначать бизнес-процессы рекомендуется когда готова и опубликована модель данных.
Наличие или отсутствие данных при запуске бизнес-процессов должно определяться задачами, решаемыми в рамках проекта. Например, можно загрузить данные из нескольких информационных систем, обработать данные при помощи правил качества и только после этого назначить бизнес-процессы чтобы отслеживать новые изменения данных.