Здесь же будет постоянная страница со списком пожеланий и багов Oracle Data Integrator.
Ниже описаны проблемы и недостатки версии ODI 10.1.3.5.
Итак, интерфейс ODI плох тем, что:
- Написан на Java, соответственно, отсутствуют возможности работать по тем принципам, к которым привык в интерфейсе Windows. Особенно удручает отсутствие возможности "нажимать" на кнопки посредством клавиатурных сокращений.
Например, наличие такого понятия как кнопка по умолчанию приводит к тому, что только после запуска сценария, пакета или интерфейса можно, нажав один раз Ввод, запустить сценарий, а затем еще один раз нажав ввод - закрыть окно уведомления о том, что объект запущен на выполнение.
Во всех остальных случаях необходимо работать мышью. - Сообщения об ошибках с треком никому не нужных вызовов классов Java - совершенно не информативные. Если я не ошибаюсь, в 11 версии с этим должно быть немного получше.
- Необходимость нажимать Ввод для того, чтобы введенные в поля ввода значения сохранились. Присутствует при вводе значений для переменных при запуске сценария, установке опций модуля знаний, определении наименования шага в пакете и т.п.
Вполне можно было бы сохранять введенное значение при потере элементом редактирования фокуса. - Команда Undo в редактировании процедур, маппингов и прочих текстовых полях. Хотя бы на одно действие. Это же не видеоредактор, отмену можно было бы сделать.
- Список сценариев. При редактировании команды запуска сценария каждый раз при выборе сценариев из списка происходит обращение к репозиторию. Лучше было бы считывать этот список один раз, после первого обращения в пакете к этому списку, и отдельно дать возможность обновлять список некой кнопкой рефреш. Именно по причине длительности, я и рекомендовал такой вариант редактирования команды odiStartScen
- При перегенерации сценариев не работает опция, определяющая, удалять ли логи выполнения сценария. Подробнее тут.
- Иметь возможность добавлять свои пиктограммы для маркеров.
- При пропадании связи с репозиторием иметь возможность закрывать Дизайнер, даже если открыты какие-то объекты, особенно, если стоит галка для опции "Не блокировать объект при открытии".
- Переменные. Хотелось бы иметь возможность группировки переменных по папкам, а не одним большим списком, как сейчас.
- Переменные. При генерации сценария из пакета, если переменная в пакете не декларируется, а только обновляется - не использовать ее как входную переменную по-умолчанию, так как ее значение, в любом случае, будет проигнорированно.
- Оператор. Добавить возможность просмотра сессий по заданным ключевым словам в режиме иерархического просмотра сессий. В таком случае, должна отображаться сессия с установленным ключевым словом, а также все ее родительские сессии.
- Оператор. Расширить перечень колонок, которые можно отобразить в списке сценариев. Добавить время старта и окончания, а не только дату. Добавить время выполнения дочерних сессий в режим отображения дочерних сессий.
- Оператор. Возможность импортирования сценариев сразу в папку сценариев. Подробнее тут.
- Оператор. Отображение списка сценариев по наименованию сессии не учитывает ограничение на количество отображаемых сценариев. Подробнее тут.
- Процедуры. Возможность отображения в дереве проекта ветки Used in для процедур, так же как и для интерфейсов, чтобы была возможность сразу увидеть в каком пакете используется процедура.
И возможные небольшие изменения в реализации некоторых архитектурных моментов ODI.
- Отображать значения переменных в Операторе, например, в виде комментариев. Либо отображать тот SQL код, который выполняется по заданному шагу СУБД на отдельной вкладке. Основная цель - знать, что выполняла СУБД на каждом шаге достоверно.
- Практически каждый объект в ODI состоит из нескольких объектов или псевдообъектов. Например, при загрузке интерфейса последовательно происходит дергание запроса к БД для, например, каждой таблицы источника, целевой таблицы, опций модуля знаний и т.п. Загрузка пакета тем дольше происходит, чем больше в нем находится вызовов других объектов: переменных, процедур, интерфейсов и т.п.
При соединении с удаленным репозиторием, задержки к доступу к которому достаточно большие, например, при соединении через GPRS, открытие объекта - процесс очень небыстрый.
Соответственно, предложение состоит в том, чтобы исключить несколько запросов к БД репозитория, а получать всё сразу, а уже на клиенте разбирать результаты выборки на составляющие подобъекты.
- Ввиду того, что большинство объектов являются составными, не перезаписывать, при сохранении, те из них, которые не изменялись. Что я имею ввиду, например, интерфейс, в котором есть соединение двух таблиц источников. Это соединение сохраняется в репозитории ODI в отдельной таблице, в которой есть 4 служебных колонки. Кто и когда создал и кто и когда последний раз изменял.
Хотелось бы, чтобы была возможность, в большом коллективе разработчиков, определять, кто последний менял каждую подчасть объекта, а не просто открыл пакет, передвинул вызов сценария на 2 пискеля ниже, сохранил его - а теперь является ответственным за неправильную работу этого пакета. - Переменные. Хотелось бы иметь возможность обновления переменных в процедуре.
- Переменные. Хотелось бы иметь возможность использования переменных только в пакете, например, для организации циклов, без необходимости их создания в дереве проекта.
- Хотелось бы иметь возможность обращаться к репозиторию ODI прямо из объектов разработки. Сейчас такая возможность есть, но приходится, при передаче на пром эксплуатацию, менять в готовых сценариях текстовое название репозитория разработки на репозиторий пром выполнения.
Если бы была возможность читать и модифицировать тот репозиторий, в котором выполняется сценарий, было бы намного удобнее. Возможно, необходимо также будет предусмотреть какие-то сообщения или уведомления при импорте сценария, о том, что данный сценарий обращается к репозиторию, так как это несет некоторые угрозы для выполнения требований безопасности.
Удаление логов выполнения сессии через таблицы репозитория описано здесь.
- Добавить возможность получать через метод подстановки GetColList список не только колонок, но и то, к каким таблицам источникам они принадлежат.
Например, если необходимо сделать некие стандартные для всех источников действия перед их загрузкой в целевую или интеграционную таблицы, сбор статистики и т.п.
Несмотря на большое количество комментариев, я не считаю что необходимо делать возможность массового шифрования сценариев.
Баги в ODI.
- При клике на автоинкрементном маркере привязанном к объекту, маркер на объекте меняется, а в дереве зависимостей маркеров остается прежним.
- Неверная работа команды OdiGenerateAllScen для сценариев, генерируемых из вложенных папок. Подробности позже.
Комментировать здесь.