Доступ к собственному репозиторию из сценария.

Приветствую коллеги.

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

Кстати, для тех, кто пока не считает себя великим ODI гуру - крайне полезно будет пройти по всем записям этого блога за 2010 год, начиная прямо с июля месяца. Я уверен, вы найдете там массу интересного.

Пример был работающий, но его применимость была несколько ограниченной. Объясню почему. У нас на проекте настройка контекстов, например, DEV и TEST была, в основном, связана с взаимоувязкой физической схемы дев источника данных с физической схемой приемника данных опять же на дев сервере. Тоже самое касалось контекста TEST, где связывались между собой две физических схемы на том же сервере: тест-источник <-> тест приемник.

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

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

Не уверен, что написал понятными словами, но дальше будет яснее, с картинками.

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

Оказывается, для этого есть вполне подходящие инструменты, просто раньше я о них не знал. Правда, применять эти инструменты придется несколько нестандартным путем.

Итак, нам понадобится:
1. Копия модуля знаний реверса.
2. Новый пакет.
3. Скрипт для проверки.

Последовательность действий простая. Модифицируем модуль знаний реверса, оставляем в нем всего один шаг со следующим кодом:

update SNP_SESSION
set SESS_NAME = SESS_NAME + ' Updated successfuly'
where SESS_NO = <%=odiRef.getSession( "SESS_NO" )%>
and 1 = 0

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

Запускаем пакет и проверяем результат.

Убираем защиту и запускаем еще раз:

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