Строим workflow на основе пользовательского ввода (User Input).

Приветствую.

В комментариях к записи Что такое переменная ODI, один из наших коллег спросил, каким образом можно сравнить две переменные, одна из которых имеет тип alphanumeric, а вторая - date.

Как отмечено в указанной записи, я не знаю удачных примеров использования переменных типа даты. Теперь есть пример не очень удачного использования, но, тем не менее, с помощью исключений и использования KO перехода в пакете задача решена.

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

Чем отличается Oracle Data Integrator от других средств загрузки и преобразования данных, например, от Информатики? Тем, что фактическую работу над преобразованиями выполняет не ODI, а кто-то другой. ODI только готовит команды, в том числе при помощи методов подстановки, запускает их на выполнение, проверяет результаты и сохраняет, как команды так и результаты, в репозитории.

Я возьму самый простой случай, когда тот самый другой, выполняющий наши команды, это СУБД. Можем ли мы при помощи SQL запроса определить, меньше ли введенное пользователем значение текущей даты или нет? Конечно, можем:

select case when #Variable < sysdate() then 'YES' else 'NO' end

На самом деле, нужно несколько больше усилий, тем не менее, можно заставить СУБД выполнить все проверки самостоятельно.

Например, для MS SQL сервера может быть использован такой вариант:

Нам осталось вместо строки TEST использовать переменную, значение для которой задается пользователем при запуске сценария на выполнение. А ведь переменные в Oracle Data Integrator чаще всего используются именно для подстановки значений в выполняемые команды, в нашем случае, в sql команду, возвращающую вполне определенный набор значений.

Что делать далее с полученным (опять же, в переменную ODI) значением? Дальше, в пакете, его можно непосредственно сравнить (Evaluate variable) с заранее известными константами, и, в зависимости от результатов, сформировать нужную последовательность выполнения шагов пакета.

Диаграмма пакета для примера:

Здесь на шаге 1 мы декларируем переменную, что позволяет нам на шаге 2 передать полученное значение в sql запрос, и, на том же шаге 2, так как это обновление переменной, получить результат вычисления нашего sql case оператора во вторую переменную. Далее, на шаге 3, мы сравниваем значение второй переменной с заранее заданными константами.

Если выбранный нами оператор возвращает Да - мы переходим в пакете по стрелке ОК и делаем нечто полезное. Ну, а если нет - завершаем работу с ошибкой. При этом в пакете можно сделать много таких вот шагов со сравнениями значения переменной и константы и соответствующим продолжением работы пакета в зависимости от результатов.

Хочу обратить внимание на тот факт, что предложенное решение это просто первое приближение. На самом деле, необходимо не просто преобразовать текущую дату в строку, и сравнивать ее с другой строкой, но и предусмотреть:

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

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

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