Уменьшаем количество переменных ODI.

Привет всем.

Мне кажется, что я уже писал о том, что надо стремиться сдерживать рост количества переменных в проекте. Можно минимизировать этот показатель организационными методами, например, установлением правил наименования переменных или запретом на изменение переменных обычными разработчиками. Можно минимизировать необходимость использования переменных в интерфейсе с помошью новых возможностей ODI 11g по использованию lookup-ов.

Кроме того, следует, где это возможно, использовать все возможности переменных, которые нам предоставляет Oracle Data Integrator. Хороший демонстрационный пример - использование введенного пользователем значения для построения workflow.

Какие особенности переменных ODI позволят сократить количество использованых переменных в этом проекте в два и более раз?*

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

Не забываем о том, что для сценариев можно установить свои значения по-умолчанию для переменных, так как переменные в сценариях - фактически дубликаты переменных из проекта.

2. Используем значение переменной в обновлении (refresh) переменной. Хоть это и выглядит несколько в стиле C++, но мы можем в процессе установления значения переменной использовать существующее её значение.

SELECT CASE
WHEN UPPER('#ETL.WorkFlowVar') = 'NOT SET' then 'WRONG'
WHEN convert(date, '#ETL.WorkFlowVar', 120) >= convert(date, getdate(), 120) THEN 'WRONG'
ELSE convert(char(10), convert(date, '#ETL.WorkFlowVar', 120), 110)
END

Как это будет выглядеть в нашем примере? Пользователь ввел значение для переменной при запуске сценария, мы его проверили при обновлении переменной, если значение корректное, мы возвращаем то же, что ввел пользователь, если значение некорректное, мы возвращаем текст 'WRONG', что будет признаком завершения работы пакета.

Раз уж мы начали в духе С++, то в последнем варианте оператора (ELSE) выполняется двойное преобразование введенной пользователем строки: сначала в дату, затем обратно в строку, но уже в другом формате.

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

Работает согласно ожиданиям, насколько я могу судить.


* - если указанный проект использует только один пакет. Если пакет не использует других переменных. Если для проверки факта отсутствия ввода использовалась третья переменная.