Вызов сценария выбора через ODI (Oracle Data Integrator)

Question

Могу ли я высказать ваше мнение по следующим запросам, пожалуйста: Вариант 1: У меня под рукой есть скрипт выбора, который извлекает данные путем объединения многих исходных таблиц и выполняет некоторые преобразования, такие как агрегации (сгруппированные по), преобразование данных , подстрока et c. Могу ли я вызвать этот сценарий через отображение ODI и вернуть результаты (преобразованные выходные данные) в целевую область отображения ODI? Option2: Преобразование сценария выбора в эквивалентное отображение ODI с использованием эквивалентных преобразований ODI, функций, поисков и т. Д. c и использование различных таблиц (таблиц в предложении соединения) в качестве источника отображений. По сути, разработайте отображение ODI, которое эквивалентно предоставленному скрипту выбора и целевой таблице для вставки записей в него. Мне нужно знать плюсы и минусы обоих вариантов выше (если вариант 1 возможен). Можно ли по-прежнему отслеживать ошибки преобразования, объединять исходные таблицы и где ошибки, связанные с условием условия, и т.д. c через ODI с опцией 1? Файл журнала для сбоя сопоставления будет иметь детализацию уровня детализации, предложенную в варианте 2? Могу ли я по-прежнему включать управление потоком в модуле знаний и перенаправлять ошибки выбора сценариев в таблицы ошибок E $ _, предоставляемые ODI?

Спасибо, Раджни sh

Answer 1

Вариант 1: ODI 12 c включает эту концепцию из коробки. На физической вкладке сопоставления нажмите на исходный узел (хранилище данных). Затем на панели свойств есть опция CUSTOM_TEMPLATE в меню «Параметры извлечения». Это позволяет вводить пользовательский оператор SQL, который будет использоваться вместо кода, сгенерированного ODI.

Однако он, вероятно, менее удобен во времени, чем вариант 2. SQL менее нагляден, чем компоненты отображения. Также, если вам нужно массово изменить его, это будет сложнее. Изменение компонента в нескольких сопоставлениях может быть сделано с помощью SDK. Изменение кода SQL потребует его анализа. У вас действительно может быть меньше информации в журналах вашего оператора, так как SQL будет рассматриваться только как один блок кода. Это также не обеспечит никакого происхождения.

Я полагаю, что использование управления потоком будет работать, но я не проверял его.

Вариант 2 занял бы больше времени, но с этим вы выиграете из всех функциональных возможностей ODI.

Я бы предпочел иногда использовать опцию 1 для действительно сложных SQL запросов, но использовать опцию 2 для большинства обычных случаев использования.