Что такое сценарий ODI (Scenario).

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

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

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

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

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

При вызове сценария из пакета с помощью команды odiStartScen можно, при помощи параметра -SCEN_VERSION определить конкретный номер или название версии сценария для запуска, или указать значение -1, тогда ODI выберет для запуска сценарий с максимальным значением версии.

Во время генерации сценария через контекстное меню объекта в дереве проекта, либо на соответствующей вкладке окна редактирования объекта, можно установить какие переменные, используемые в объекте, будут доступны как пути передачи входных параметров сценария. Подробнее о переменных в сценариях тут.

Итак, насколько же сценарий независим от тех объектов, из которых он создан?
Хочу проверить два предположения, касающихся сценариев.
Первое - можно ли удалить исходный объект, из которого сгенерирован сценарий.
Второе - можно ли удалить составляющие, использованные при генерировании сценария, например, таблицу источник из модели, или модуль знаний, который используется в сценарии.

Удаляем оригинальный объект.

1. Пакет small, созданный для иллюстрации того, как создать workflow в ODI, я буду использовать в качестве подопытного экземпляра. Для одного из интерфейсов, входящих в этот пакет установлено использование копии модуля знаний.
2. Генерируем сценарий и делаем его экспорт.
3. Удаляем оригинальный пакет, что приводит к удалению и его сценария.
4. Импортируем сценарий обратно в репозиторий, но уже через Оператор.
   
   
   
   
   Сценарий импортирован успешно.
5. Попробуем найти, куда в дереве проекта попал этот сценарий. Найти этот сценарий я смог только через поиск. Вручную, раскрывая ветки дерева, этого сделать мне не удалось.
   
   
   
6. Запускаем найденный сценарий на выполнение.
   
   
   

Итак, первый эксперимент оказался удачным, сценарий выполняется, несмотря на то, что пакет, из которого он создан, уже удален.

Удаляем модуль знаний.
Теперь попробую удалить дубликат модуля знаний и запустить сценарий. Удалить модуль знания пришлось после удаления интерфейса, который использует этот модуль, и который входил в пакет small. Запуск сценария после этих удалений прошел успешно, и этот запуск упал "точно по графику":

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

Что внути сценария?
При экспорте, как я уже упоминал, объекты сохраняются в виде xml файлов. Если открыть файл small.xml в интернет эксплорере, можно увидеть примерно следующую картину:

Вот где-то среди этих описаний и находятся используемые модули знаний, переменные и шаги процедур.

<Object class="com.sunopsis.dwg.dbobj.SnpScenTxt">
<Field name="Enc" type="java.lang.String">null</Field>
<Field name="EncKey" type="java.lang.String">null</Field>
<Field name="Nno" type="com.sunopsis.sql.DbInt"><![CDATA[3]]></Field>
<Field name="OrdType" type="java.lang.String"><![CDATA[D]]></Field>
<Field name="ScenNo" type="com.sunopsis.sql.DbInt"><![CDATA[13948105]]></Field>
<Field name="ScenTaskNo" type="com.sunopsis.sql.DbInt"><![CDATA[4]]></Field>
<Field name="Txt" type="java.lang.String"><![CDATA[drop table <?=snpRef.getObjectName("L", "%INT_PRFE_ACCESS_POINT", "W") ?>]]></Field>
<Field name="TxtOrd" type="com.sunopsis.sql.DbInt"><![CDATA[0]]></Field>
</Object>

Судя по вызову метода подстановки getObjectName, с использованием префикса %INT_PRF и имени таблицы E_ACCESS_POINT удалять таблицу, используемую в интерфейсе, из модели нельзя. Вернее, удалить можно, но сценарий, в таком случае, правильно не отработает, так как произойдут ошибки в вызовах методов подстановки.

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