WebLogic Management Framework
Другое большое новшество в этом релизе это то, что инфраструктура управления WebLogic сервера используется для контроля агентов ODI вместо ранее использовавшегося OPMN сервера. Теперь агенты управляются тем же образом, что и остальные компоненты промежуточного ПО Fusion Middleware и для настройки используется специальный мастер - Fusion Middleware Configuration Wizzard.
На практике, автономный агент теперь инсталлируется вне папки ODI, в домене, схожем со стандартными WLS доменами. Плюсы такого подхода, помимо централизованного управления, в том что теперь агент поддерживает язык скриптов WebLogic - WLST и может мониториться через Enterprise Manager Fusion Middleware Control или Enterprise Manager Cloud Control. Также агент может быть запущен вручную или через Node Manager.
Компонентные модули знаний
Вместе со стандартными модулями знаний - называемыми теперь шаблонными, новый вид модулей знаний появился в этом релизе. Делая следующий шаг в повторном использовании кода компонентные модули знаний содержат шаги, которые задаются только один раз, а затем повторно используются остальными компонентными модулями. И эти модули знаний теперь не являются шаблонами кода с вызовами методов подстановки во время выполнения, а, напротив, являются сгенерированными библиотечными функциями, создающими текст программы базируясь на используемых в маппинге компонентах.
Компонентные модули знаний предоставляются в готовом виде и не являются редактируемыми. Выбор типа модуля знаний осуществляется на вкладке физической имплементации маппинга.
Редактор модулей знаний
Не переживайте, вы по-прежнему можете импортировать, редактировать или создавать шаблонные модули знаний. Папка, в которой их можно найти -
Хорошая новость еще и в том, что редактор модулей знаний был переработан, чтобы уменьшить количество ненужных переключений среди нескольких вкладок. Теперь, как только одна из задач модуля знаний выбрана, ее текст тут же отображается в редакторе свойств. Вдобавок, поддерживается выделение синтаксиса и автодополнение! Опции также управляются непосредственно из редактора, а не через работу с деревом проекта.
Внутрисессионный параллелизм
С ODI 12c стало возможным выполнять задачи выгрузки данных в параллельном режиме. Это, собственно, происходит по-умолчанию. Если два источника данных расположены в одном и том же модуле выполнения на вкладке физической имплементации, они будут запущены одновременно. Если же вы хотите выполнять загрузку последовательно, вам необходимо выделить один из источников в отдельный модуль, перетащив его на пустое пространство. Новый модуль создастся автоматически, а ODI определит в каком порядке запускать каждый из модулей на выполнение.
Благодаря этому подходу время выполнения может быть сокращенно, особенно, если ваши источники находятся на разных серверах.
В настройках топологии можно определить максимальное количество параллельных потоков для агента, так же как и максимальное количество потоков для отдельной сессии, чтобы не допустить узурпации ресурсов одной сессией.
Загрузка целевой таблицы в параллельном режиме
В ODI 11g если два интерфейса загружают данные в одну и ту же целевую таблицу, или, если один интерфейс запущен дважды, вы можете получить некоторые проблемы. Например, одна из сессий может удалить временную таблицу другой сессии.
Теперь это в прошлом, в ODI 12c появилась новая опция - "Использовать уникальные имена временных объектов", которая расположена во вкладке физической имплементации маппингов. Если вы ее установите, то для каждой сессии будут сгенерированы уникальные имена. Теперь другие сессии никак не повлияют на данные текущей сессии.
Я слышу голос опытного разработчика: "Что если выполнение маппинга прервется из-за ошибки? С этими уникальными именами временные таблицы не будут удалены при следующем выполнении маппинга". Не волнуйтесь, авторы ODI предусмотрели и это. Отдельная задача модуля знаний может быть помечена признаком "Очистка маппинга". Эта задача будет выполнена в конце маппинга, даже если он упадет с ошибкой. Отличная штука, которую я также буду использовать для моих задач логгирования.
"А что, если упадет агент? Эти шаги очистки не будут запущены все равно". И для этого есть решение - новая утилита ODI - OdiRemoveTemporaryObjects. Она запускает каждую незавершенную задачу очистки и эта утилита запускается по-умолчанию при каждом рестарте агента.
План выполнения сессии
Когда вы выполняете интеграционные задачи с помощью ODI, ваши отдельные задачи могут запускаться каждые несколько минут или даже секунд. На каждый вызов сценария агент ODI 11g получает из репозитория шаги и задачи, которые необходимо выполнить и синхронно записывает их в лог, еще до того, как что-либо выполнить. После выполнения он удаляет логи - в случае если выбран низкий уровень логирования. В конце дня, даже если уровень логирования был низок, в базе данных репозитория будет много реду и архивных логов.
Вместо получения шагов сценария для каждого запуска, агент ODI 12c теперь единожды получает план или схему выполнения сессии - так называемый Session Blueprint и сохраняет ее в кеше. И, раз это сохранено в кеше агента, больше не нужно обращаться к репозиторию, если эта же задача должна быть запущена снова через несколько минут. Агент также записывает - асинхронно - только то количество информации, которое задается уровнем логирования. Параметры, связанные с использованием схем выполнения задаются в топологии для физических агентов.
В итоге - благодаря схемам выполнения сессий нагрузка от множественного выполнения сессий значительно снижена, агенту необходимо меньше данных из репозитория и он не занимается добавлением-удалением ненужных логов, а если и пишет в БД репозитория - то делает это асинхронно. Ну, разве не замечательно?
Информирование об изменении таблиц
Последний раз это со мной произошло на прошлой неделе - нам нужно было переименовать колонку таблицы в модели, но мы не могли этого сделать, так как она использовалась как целевая таблица в интерфейсе. Решение в этом случае в том, чтобы удалить выражение в каждом из интерфейсов, где используется таблица.
Больше такого неудобства нет - в ODI 12c вы просто меняете таблицу в модели, а в маппингах появляется уведомление. В следующем примере я удалил колонку LOAD_DATE.
Секретный бумажник
Никогда с этим не сталкивались раньше? Выдача пароля к мастер репозиторию не очень безопасна, но и сохранение его в свойствах соединения с репозиторием не особо лучше, если разработчики не блокируют свой компьютер, когда от него отходят.
ODI 12c помогает и в этом. Вы теперь можете сохранить ваши настройки соединения в секретном кошельке, который сам закрывается на пароль. Один пароль чтобы закрыть всех!
Попробуйте!
Если вы хотите попробовать как выглядит ODI 12c вам необходимо следовать указаниям руководства и скачать преднастроенный образ виртуальной машины. В этой машине используется Oracle Enterprise Linux с базой данных Oracle XE Database 11.2.0. Само собой, вам понадобится Virtual Box чтобы запустить эту виртуальную машину.
Комментариев нет:
Отправить комментарий
Примечание. Отправлять комментарии могут только участники этого блога.