05 декабря 2008

Маленький совет

Так как мой проект почти завершился и даже себестоимость в OPM стала считаться правильно, то делать мне нечего и я периодически помогаю решать знакомым и не знакомым проблемы с их внедрениями Hyperion Planning.

Так вот, уже не первый раз сталкиваюсь с тем, что везде написано, но никто не принимает к сведению - код не должен быть привязан к названию элемента. Это вредно, а в случае использования EPMA еще и опасно.

Если вы вдруг изменили в EPMA какой-то код, то всячески советую стоять перед серваком и молиться во время проноса (deploy) приложения. Сам сталкивался с этим когда кто-то место десяти ноликов вбил девять. Тогда часа три было убито на то, чтобы восстановить приложение.

Ну и сразу еще один совет - не используйте EPMA, используйте ODI. Благо сейчас уже достаточно материалов чтобы самостоятельно и без лишней нервотрепки его освоить (например в блоге Джона Гудвина (John Goodwin) все описано с подробностями, картинками и примерами использования).

5 комментариев:

  1. Хм... а почему не рекомендуешь использовать EPMA?

    Кроме того, что он конкретно засирает реляционку логами транзакций (которые, кстати, можно отключить) и версиями измерений (хотя версионность сама по себе полезна, даже если различные версии недоступны из интерфейса продукта), особых недостатков, мешающих использованию, я у него не обнаружил, а удобств куча - интерфейс для ручного редактирования измерений зоопарка приложений лучше иметь, чем не иметь, а если его не хватает, то он понимает простой текстовый формат импорта (и заметь, ни какого ODI :-).

    А в 11-й он вообще стал на порядок удобней благодаря локальным библиотекам приложений и Grid Editor'y.

    ОтветитьУдалить
  2. Поделись как отключить?:-)

    Я банально не понимаю зачем он нужен? Справочники в нем вести нереально по многим причинам. Т.е. приходим к тому, что он должен выкачивать их из других мест. Тут перед нами встает задача выбора - ADS или Database Tables. При этом стоит взглянуть на описание форматов чтобы понять, что все, приехали, ETL своими руками или все тот же ODI/OWB (можно еще что-то, только эти тулзы в данном конкретном случае халявные скорее всего).

    С EPMA:
    Источник->ETL->EPMA->Planninng->Essbase
    С ODI:
    Источник->ODI->Planning->Essbase

    Зачем платить больше?

    При этом стоит отметить некую тяжеловатость EPMA - на наших стандартных машинках с 512 мегами он еле дышит.

    С 11 вообще все весело - он не схавал ads'ку, которая получилась из 9.3.1 при помощи EPMAExtractor'а, который для 9ки... EPMAExtractor, который идет в дистрибе 11 вообще не смог ничего выгрузить из 9.3.1...

    Можно и больше написать, но на поезд опаздываю, удачи!

    ОтветитьУдалить
  3. Чем больше рукотворного в проекте - тем меньше молитв перед волшебной кнопкой %)

    И если есть возможность одно и тоже сделать двумя разными способами - то это лучшая защита от сырого продукта. Например можно использовать одно из приложений Planning'а (на оракловом RDB) в качестве источника метаданных для других, для этого прекрасно подойдут метки привязки к кубу :)

    Лично я против EPMA, так как привык все делать через HAL, - но за EPMA будущее - и видимо пора изучать ее ER модель дабы обходить неприятности с несовместимостью форматов между версиями.


    essbase.ru

    ОтветитьУдалить
  4. Прошу извинить за доооолгий ответ – быстро не смог ответить, а потом начатый диалог забылся. Исправляюсь сейчас.

    Что такое EPMA и зачем он нужен?

    EPMA (EPM Architect, а ранее – BPM Architect) – это ГРАФИЧЕСКИЙ ПОЛЬЗОВАТЕЛЬСКИЙ ИНТЕРФЕЙС ДЛЯ РЕДАКТИРОВАНИЯ и синхронизации метаданных (и синхронизации данных) НЕСКОЛЬКИХ приложений комплексной системы EPM, построенной с использованием РАЗЛИЧНЫХ продуктов. Именно и в первую очередь ИНТЕРФЕЙС ДЛЯ РЕДАКТИРОВАНИЯ, а не просто замена HAL для импорта данных/метаданных и не полноценный инструмент для ETL.

    И для указанной задачи в нем есть все необходимое. Сыроватое и глючное, но полезное :-)

    А вот для любых других задач там ничего нет. Это значит, что если нужно импортировать метаданные из некоторой мастер-базы, например план счетов или список компаний из OEBS, то нужен нормальный человеческий ETL – волшебных палочек не существует и системы, предназначенные для разных бизнес-процессов и построенные на разных технологиях, сами собой не синтегрируются :-)

    Также не имеет смысла EPMA противопоставлять HAL – они решают разные задачи. HAL мог бы повоевать только с ODI, но и тут на стороне ODI есть преимущества: он универсален, а значит требуется разработчик с одним навыком для построения единого процесса ETL по наполнению хранилища и по проталкиванию данных/метаданных в Planning/HFM (а если данные толкать не напрямую в приложения Hyperion, а в интерфейсные таблицы EPMA, то архитектура получится совсем красивой); кроме того, ODI проще развивать, т.к. в отличие от HAL это уже родной продукт Oracle, который вписывается в единую стратегию развития всех приложений(как утверждает Oracle ;-)

    При этом сценарий использования EPMA я вижу такой (с точки зрения EPM-вской части большой аналитической системы большой компании):

    Во время разработки:
    -- первичное наполнение измерений: Excel -(генерация ads, есть стадартная утилита, а для себя я написал скрипт на VBA)-> файл.ads -(ручная заливка через веб)-> EPMA
    -- редактирование готовых измерений: ручное редактирование в вебе (Grid Editor действительно рулит) или перезаливка измерений из Excel

    В продуктиве: -(процедура ETL, например в ODI)-> интерфейсные таблицы EPMA -(запуск по расписанию или по команде консольного командного интерпретатора EPMA)-> EPMA

    После того, как справочники из мастер-систем проимпортированы в EPMA их можно дополнять, создавая, например, новые расчетные KPI или моделируя различные представления орг. структуры (текущая финансовая, управленческая или даже какая-нибудь новая управленческая, которая будет принята в следующем году). Согласись, реализовывать все эти "игры" со справочниками в большой ERP-системе (только ради того, чтобы потом можно было метданные "просто" проимпортировать в систему EPM) как-то не с руки. Да и по факту - обычно так ни кто не делает - даже до внедрения систем класса EPM все эти "игры" с расчетными KPI или управленческой структурой происходят в Excel или презентациях для высшего руководства, но не в ERP.

    Про тяжесть EPMA и про несовместимость форматов – всё правда :-) Несовместимости форматов между разными версиями это, надеюсь, детская болезнь нового продукта и в будушем пройдет. А тяжесть лечится нормальной серверной железкой и очисткой реляционной базы EPMA от лишних транзаций.

    Про очистку лога транзакций. Можно отучить EPMA для заданного приложения не сохранять лог изменений его метаданных. Для этого в файле %HYPERION_HOME%\products\Foundation\BPMA\AppServer\DimensionServer\ServerEngine\metadataOnly\System.metadata.xml у свойства "PurgeTransactionHistoryOnSuccess" для тегов "isHidden" и "isReadOnly" задать значение false (по-умолчанию стоит true) и перезапустить все сервисы EPMA.

    После этого в Dimension Library в системных свойства ПРИЛОЖЕНИЯ (категория System) появится новое свойство "Current Deployment Purge History on Success". На нем нужно поставить галочку и сохранить настройки приложения.

    ОтветитьУдалить
  5. Роман, спасибо огромное за информацию об очистке!

    ОтветитьУдалить