DeepEdit!

Сегодня я хочу рассказать о методах подстановки, которые ODI использует для построения набора команд, используемых в ETL задачах. Для общего обзора наилучшим источником, на мой взгляд, является документация, поэтому я постарался перевести некоторые части файла Knowledge Modules Developer's Guide.

Модули знаний ODI написаны как шаблоны, которые используют методы подстановки (substitution API). Методы подстановки это методы JAVA, которые возвращают значение в виде строки символов. Все эти методы являются методами объекта odiRef. Одни и те же методы могут возвращать разные значения, в зависимости от типа модуля знаний, из которого они вызываются.

Для обратной совместимости вызов методов подстановки через odiRef может быть осуществлен через snpRef. На самом деле это синонимы одного и того же объекта, но snpRef является устаревшим вариантом.

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

Код в модуле знаний

Create table <%=odiRef.getTable("L", "INT_NAME", "A")%>

(

<%=odiRef.getColList("", "\t[COL_NAME] [DEST_CRE_DT]", ",\n", "", "")%>

)

Сгенерированный код для целевой таблицы PRODUCT

Create table db_staging.I$_PRODUCT

(

PRODUCT_ID numeric(10),

PRODUCT_NAME varchar(250),

FAMILY_ID numeric(4),

SKU varchar(13),

LAST_DATE timestamp

)

Сгенерированный код для целевой таблицы CUSTOMER

Create table db_staging.I$_CUSTOMER

(

CUST_ID numeric(10),

CUST_NAME varchar(250),

ADDRESS varchar(250),

CITY varchar(50),

ZIP_CODE varchar(12),

COUNTRY_ID varchar(3)

)

В данном примере используется два метода подстановки, odiRef.getTable – для получения имени временной таблицы, которая будет использована как стейджевая таблица для целевой таблицы; getColList - для получения списка колонок целевой таблицы в случае создания этой таблицы с использованием технологии, в которой эта таблица определена (определяется параметром DEST_CRE_DT).

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

При разработке ETL процедур, вам практически никогда не стоит указывать явные наименования серверов или схем БД, так как они для разных контекстов выполнения могут меняться. ODI сам установит корректные значения для "физической привязки" таблиц к СУБД во время выполнения.

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