Использовались рисунки оригинального поста.
Всем привет.
Бьюсь об заклад, что все ODI разработчики путаются, когда работают с тэгами методов подстановки. Каждый раз, когда мне нужно с ними поработать, я должен повторить все мои проверки еще раз, так как я забываю, для чего какой тэг используется (несмотря на мой многолетний опыт работы с ODI). Это стало одной из причин, по которым я решил написать этот пост - я, в будущем, смог бы освежить свою память, прочитав его (где ты, память???). Так же потому что это хорошо - делиться своим опытом с другими, что пошло бы на пользу (я надеюсь на это) если у кого-то возникнут те же проблемы.
Что же такое тэги подстановки, для тех, кто с ними не слишком знаком? Тэги подстановки это те символы, которые вы видите если откроете модуль знаний или процедуру в ODI, точнее вот эти символы - <%>, <@>, <?>, <$>. Вот как на этом рисунке.
Тэги эти - это часть API методов подстановки и они используются для динамической генерации кода, на основе переменных ODI, фактических значений опций процедур, модели данных, используемом интерфейсе и т.п. Фактически, методы подстановки - самое мощное оружие разработчика в ODI (вот почему я люблю ODI так сильно), так как оно генерирует код основываясь на том, в каком месте и условиях эти методы выполняются. Компания Oracle хорошо описала этот аспект в своей документации здесь.
Несмотря на то, что Oracle описывает методы подстановки в своей документации, она не упоминает непосредственно тэгов подстановки и в своих примерах оперирует только самым часто используемым тэгом <%>. В действительности же мы имеем четыре типа тэгов, каждый из которых имеет свое собственное поведение. Тэги запускаются на выполнение в особом порядке, что влияет на результаты сильнее, чем вы можете себе представить.
Я объясню каждый тэг на основании реального рабочего примера, произошедшего некоторое время назад. Я работал на проекте, в котором было несколько серверов (ODI агентов) с разными операционными системами. Я разрабатывал часть кода, взаимодействовавшего с ОС, так что код должен был меняться в зависимости от того, где он выполняется. Если операционка была Linux то выполниться должна была одна команда, а если Windows - другая. Для проверки того, в какой ОС выполняется код, я использовал метод подстановки следующего вида, с тэгом, который я знал на тот момент - <%>:
<%= System.getProperty(“os.name”) %>
Код не работал так, как ожидалось. В результате выполнения возвращалось имя операционки, с которой я запускал процедуру (т.е. сторона клиента ODI), а не та, на которой выполнялся данный код (сторона агента ODI). Это меня озадачило, так что я начал изучать, какой бы вариант я смог бы использовать. Именно тогда я узнал о тэгах <@> и <?>, а позже и о тэге <$>. Каждый из них по своему влияет на генерацию кода ODI, так как каждый тэг обрабатывается на своем этапе интерпретации (парсинга) исходного кода. Очень ясная концепция, по настоящему влияющая на возможности динамической генерации кода в ODI.
Вот что я делал, чтобы протестировать все варианты тэгов. Для начала - мой клиент ODI работает на Windows 2003, а агента ODI на Windows Server 2008 R2 (Linux сейчас для меня недоступен, но для нашего примера Windows 2008 будет достаточно, так как просто нужна другая ОС, чем на клиенте). Я создал следующую процедуру.
Это простая процедура с кодом на Jython, где я вызываю исключение с наименованием операционной системы в виде текста ошибки. Я пометил данный шаг галкой игнорирования ошибок, так что смогу проверить все четыре варианта в других шагах процедуры. Я сделал по шагу на каждый тэг подстановки.
Дальше вы выполняете процедуру, убеждаясь в том, что используется агент ODI (базирующийся в другой ОС).
Давайте начнем с тэга <%>. После выполнения процедуры на вкладке Code в Операторе мы получим следующее:
Очень интересно и совпадает с моей предыдущей попыткой. Тэг <%> возвращает наименование ОС на клиенте ODI, что говорит нам о том, что метод подстановки генерирует команду перед отправкой этой команды агенту. Очевидно, когда мы пойдем на вкладку Definition то увидим ту же операционку в тексте команды - "Windows 2003":
Давайте посмотрим, что произойдет с тэгом <?>.
Отлично! Именно то, что мне было ранее необходимо - получили значение операционки у агента ODI. Код был сгенерирован на стороне сервера, на котором выполнялся агент, до того, как команда была послана в лог Оператора, но перед подстановкой фактических значений ODI переменных (подробнее об этом ниже). Если мы пойдем на вкладку Definition, мы увидим выполнение команды, показывающее значение "Windows Server 2008 R2".
Ок, посмотрим на <@>:
Хммм. Более интересный случай и понятно, почему я упоминул переменные ODI ранее. Код был сгенерирован агентом, но уже после того, как он попал в лог Оператора и после подстановки фактических значений переменных ODI.На вкладке Definition в команде мы по прежнему увидим значение "Windows Server 2008 R2".
Тэг <@> отлично подходит для того, чтобы менять свой код в зависимости от значения переменной ODI, как в примере ниже:
Фильтр в интерфейсе будет изменен в соответствие со значением переменной #V_COND. Если значение переменной - #V_COND = 1, значит отфильтруются все записи с BANK_ACCOUNT_TYPE = '1', в противном же случае будут загружены все записи.
Эти три примера замечательная демонстрация того факта, что каждый тэг подстановки выполняется в свой черед и со своим приоритетом. И сейчас вы наверное подумали, а значит ли это, что мы можем использовать разные тэги вперемешку и делать код еще более динамическим? О да, конечно же да! Вот пара примеров от парней из Sonra:
Sonra Часть 1
Sonra Часть 2
Примеры показывают как мы можем создать цикл одним тэгом и затем использовать результаты этого цикла с другим тэгом, получая максимально динамический код. Я уже говорил, что люблю ODI, верно?
Хорошо, но что насчет <$>? Я оставил этот тэг напоследок, потому что он был добавлен позже всего (похоже, он доступен только с версии 11.1.1.6) Этот тэг расположен между <?> и <@> что дает нам уникальную возможность генерации кода на стороне агента до отсылки команды в лог Оператора, но после того, как переменные ODI будут замещены своими актуальными значениями. Черт ногу сломит в этих тэгах, зачем нам еще один? Смысл здесь в том, что ODI уже заменит значения переменных на вычисленные (те, которые устанавливаются или обновляются в пакете) и именно этот код будет отображен в логе Оператора, что сделает этот самый код значительно более читабельным. Помимо этого, четыре фазы парсинга кода позволят сделать код еще более динамическим. Вот пример использования тэга <$> в ODI интерфейсе из Oracle ODI блога (место, в котором я и узнал о существовании <$>):
Oracle блог
В моем примере с операционными системами, тэг <$> даст ничем не отличающиймся от тэга <?> результат.
и на вкладке "Definition"
Это все, парни, в качестве выводов - список тэгов подстановки и порядка их выполнения:
<%>: генерирует команду перед отправкой агенту;
<?>: генерирует на стороне агента, ПЕРЕД тем, как команда появляется в логе Оператора и ПЕРЕД тем, как подставляются переменные ODI;
<$> (начиная с версии 11.1.1.6): генерирует код на стороне агента, ПЕРЕД отправкой в лог Оператора, но ПОСЛЕ подстановки переменных ODI;
<@>: генерирует код на стороне агента ПОСЛЕ лога Оператора и после подстановки переменных ODI.
Надеюсь, вам понравилось, увидимся в следующий раз.
Комментариев нет:
Отправить комментарий
Примечание. Отправлять комментарии могут только участники этого блога.