ODI 11g. Настройка репозиториев (Setting up Repositories).

Продолжаю публикацию перевода некоторых частей документа Oracle Data Integrator Best Practices for a Data Warehouse.

---

Стандартная схема использования репозиториев Oracle Data Integrator

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

• Один мастер репозиторий для хранения топологии и прав доступа. Все рабочие репозитории подключаются к этому мастер репозиторию. Этот мастер репозиторий содержит версии всех объектов, созданных разработчиками.
• Рабочий репозиторий разработки, который использует группа разработчиков. Этот репозиторий содержит все проекты и модели, работа над которыми ведется в данный момент.
• Рабочий репозиторий тестирования, который использует команда тестировщиков. Этот репозиторий содержит все проекты и модели, которые в данный момент тестируются.
• Рабочий репозиторий приемки, который разделяется между тестировщиками и бизнес-аналитиками. Этот репозиторий содержит проекты и модели, которые готовятся к переходу на ПРОМ сервер. Бизнес-аналитики с помощью приложения Console, проверяют сценарии и преобразования перед передачей их в промышленную среду загрузки данных.
• Рабочий репозиторий для промышленной загрузки. Этот репозиторий используется технологами и бизнес-аналитиками в режиме только для чтения. Репозиторий содержит готовые метаданные и сценарии, которые используются для промышленной загрузки ХД.
• Рабочий репозиторий срочных изменений используется группой разработки и группой поддержки. Этот репозиторий обычно пуст. В случае возникновения критической ошибки на пром сервере, группа поддержки восстанавливает проект и модели в этом репозитории, и, с помощью разработчиков, вносит исправления в соответствующие объекты. После исправления ошибки, сценарии передаются непосредственно на пром сервер, а изменения в моделях или проектах сохраняются в виде версий в мастер репозитории.

Рекомендуемая схема построения репозиториев:

Мастер репозиторий и все рабочие репозитории обычно создаются в одной СУБД, в разных базах данных или схемах.

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

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

Создание отдельного репозитория для пром сервера

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

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

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

• Создать контекст для прома.
• Создать все подключения к дата серверам и все физические схемы Топологии.
• Связать созданные физические схемы с существующими логическими схемами, созданными разработчиками, через пром контекст.
• Не удалять и не изменять существующие контексты или логические схемы.
• Изменить права доступа, чтобы только технологи и бизнес-аналитики имели доступ к репозиторию.
• Создать рабочий репозиторий для прома, и дать ему идентификатор, отличный от идентификаторов всех остальных рабочих репозиториев (разработки, срочных исправлений, тестирования, приемки). См. также Влияние идентификатора рабочего репозитория.
• Каждый раз, когда изменяется мастер репозиторий разработки, необходимо вручную переносить изменения в мастер репозиторий прома.
• Экспортировать проекты, модели и сценарии, готовые к внедрению на пром, из мастер репозитория разработки в XML файлы. Для этого может быть использован "Браузер Версий". Другой подход - использование "Решений", и выгрузка этих решений в архивированный файл.
• Последний шаг - подключение к рабочему репозиторию прома Дизайнером и загрузка XML файлов или сжатых файлов решений в репозиторий.

Влияние идентификатора рабочего репозитория

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

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

Каждый объект в репозитории Oracle Data Integrator, имеет уникальный идентификатор, созданный по следующей схеме:

<сгенерированный_номер> конкатенация <идентификатор репозитория>

Например, если внутренний идентификатор некоторого интерфейса - 4721105, то можно сразу сказать, что данный интерфейс изначально был создан в рабочем репозитории с номером 105.

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

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

---