Эпопея с закатом OWB тянется уже давно, и где-то на протяжении полутора лет мне, с разной частотой, попадались мнения разных людей, которые говорили или писали, что ODI и OWB скоро сольются.
Что вам сказать, похоже, сливание уже началось. Слияние. В текущей версии ODI мы имеем кучу багов и странных, тормознутых или кривых интерфейсных загогулин.
Попробуем пройтись по списку найденного.
Все это лучше было бы смотреть на видео, но, пока, до видео руки не дошли.
Абсолютно ненужные кнопки Новое и Сохранить все. Новое - ненужное, а сохранить все я бы даже сказал что вредное.
Чем бы вы ни занимались, разработкой пакетов или интерфейсов, моделями или правами пользователей, по кнопке новое вам будет показана вот такая вот галерея "очень нужных и повседневных" задач:
При перегенерации сценария из пакета, после добавления новых переменных можно их не получить в сценарий. Т.е. если у вас в пакете больше 10-12 переменных, то, добавив еще парочку, можно просто не увидеть, что эти переменные не выбраны для использования по-умолчанию. ODI автоматически не устанавливает для таких переменных признак использования.
Окно с переменными можно увеличить, конечно, но все равно лучше внимательно наблюдать за тем, что генерируется. Особенно при перегенерации большой группы сценариев.
Что тут можно было бы изменить? Можно, как мне кажется, показывать неиспользуемые переменные в начале списка переменных. Тогда их не пропустишь.
Разработчики ODI не предполагали, что он будет использоваться для загрузки больших объемов данных. Смотрите, в поле для отображения количества обработанных строк помещается всего 6,75 цифр.
Потеря фокуса в списках. Так это можно было бы назвать. Место - Оператор, отображение списка шагов процедуры или пакета.
Действие - при открытии шага на просмотр в отдельной вкладке.
Наверное, не приходило в голову, что ETL разработчику было бы удобно знать, какой элемент из списке он только что открыл во вкладке?
перед:
после:
Сравните с 10й версией:
Наверняка, во всем мире, среднее количество ETL разработчиков, работающих с одним репозитории (и просматривающих свои сессии в Операторе), не превышает одного, в крайнем случае, двух. И второй работает неполный рабочий день. Мне, почему-то, встрачались только ситуации, когда их было, как минимум, трое. Но даже для двоих разработчкиов узнать, кто запускал пакет или процедуру, представляет собой неординарную задачу.
Посмотрите на первую картинку по теме:
Почти все, что нужно, есть. Статус - есть, когда запустилось - есть, как пакет называется - есть, какое-то место под количество строк - тоже есть. Кто запустил - нету.
Единственный возможный путь - смотреть через список пользователей
И способ этот нормально применим только если выполняются два нехитрых условия - все полтора разработчика запускают по три пакета ежедневно, и второе условие - никого не интересует, что запускалось пару месяцев назад. А если вдруг заинтересует - можно ведь и по репозиторию SELECT организовать. Там-то вся информация наверняка есть.
Сравните с тем, как это было в 10й версии, кто не видел:
, уже не актуальны.
При работающей сессии, открытие конкретного шага во вкладке не перечитывает состояние шага из репозитория. Поясню немного подробнее, если у вас работает достаточно длительный интерфейс, то вы не сможете, открывая конкретный шаг этого интерфейса раз в пять минут узнать сразу и о том, что шаг выполнился, и о том, сколько конкретно строк он обработал.
Необходимо отдельно обновлять список выполнения сессии, и, после завершения шага, отдельно его открыть, чтобы увидеть нужную информацию. Как вы понимаете, в 10й версии все работало как нужно. Т.е. это теперь, постфактум, понятно, как нужно было.
Если из пункта 5 еще не стало понятно, то в новой версии отсутствует возможность просматривать результаты выполнения сессий в виде таблицы. Кроме удобства в плане поиска того, кто запускал процедуру или интерфейс, пропала, также, возможность просматривать список шагов интерфейса, со временем выполнения и количеством обработанных строк каждого из них, или, например, время выполнения дочерних сценариев.
Как раз об этом "улучшении" я услышал от коллег намного раньше, чем удалось увидеть ODI 11g вживую.
Следующее замечание больше похоже на баг, надеюсь, это так и есть. Представьте себе, что у вас есть пакет, в диаграмме которого есть интерфейс или процедура. Если открыть, двойным щелчком мыши, этот интерфейс, и захотеть запустить его отдельно, окажется, что сделать этого нельзя. Безотносительно того, выполнится ли этот интерфейс правильно или нет (скорее всего не выполнится, иначе зачем бы он находился в пакете?), запрещать возможность его запуска выглядит несколько странной. Так же можно и до ленточного интерфейса как в MS Office дойти.
Команда дуплицирования объекта в текущей версии называется Duplicate Selection. Зачем было менять название, если несколько объектов по прежнему нельзя сдуплицировать. Можно только удалить.
Было
Стало
Как-то в этот блог попали по такому запросу как "ODI жрет много памяти". Куда, интересно, делась кнопочка в виде мусорной корзинки, которая в 10й версии создавала ложное ощущение, что можно немного очистить память, занимаемую приложениями ODI? В текущей версии я ее не нашел, поэтому у меня стабильно доходит до того, что ODI Studio забирает у системы 1.2Гб памяти после, примерно, полудня работы, а кнопочки очистки и нет.
Если кто-то знает, куда она спрятана в 11 версии - расскажите в комментариях.
Вот такой вот вышла первая десятка. Первая не в смысле рейтинговости, а в смысле последовательности. Впереди не только описание недостатков новой оболочки ODI, но и куча просто ошибок, которых, к сожалению, хватает.
Почему я считаю, что эти вещи важны? По нескольким причинам. Одна из них - лучше об этом напишу я, чем фаны Информатики, которых намного больше %)
Вторая причина, и, я думаю, самая главная - удобство инструмента, легкость его использования и изучения - один из ключевых вопросов, которые интересуют людей при выборе нового ETL инструмента. А я бы хотел, чтобы выбирали именно ODI.
