get Oracle SmartView plugin

Про овец и капусту. (Все что хотели знать о производительности расчетов BSO, но боялись спросить.)

… по следам оптимизации одного расчета с 40 до 2 минут.

Continue reading “Про овец и капусту. (Все что хотели знать о производительности расчетов BSO, но боялись спросить.)”

Planning: Calculate Data Form

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

Автоматически создается бизнес правило, которое имеет вид : в FIX отправляются все что в форме определено как PoV ( срез данных), в тело вставляется значение аналитик , которые определены в строках. Измерения , определенные в столбцах остаются за скобками.

Например

FIX (“BUD”,”VR_Work”,”ICFO_NA”,”FY13,iLE_NA,”CFO_0AAA”,”LE_10AA”)
“Account_FRG_15”;
“Account _FRG_13”;
“Sparce_Total”;
ENDFIX

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

CalcScript : казнить нельзя помиловать (,)

“Есть всего 2 типа языков: те, на которые все жалуются и те, которыми никто не пользуется.” — Бьерн Страуструп

Несколько слов в эпистолярном жанре о судьбе программирования для Essbase на CalcScipt. По мотивам статьи «Десять вещей, которые я терпеть не могу в ООП».

 
 

CalcScript, как следует из его названия, это язык расчетов данных в многомерной модели, которому чужды такие парадигмы программирования как «процедурность»( данные + алгоритмы, ), «объектность»( объекты + сообщения. ) и «функциональность» (функции + функции). Итого: CalcScript – это работа с данными, которые функционально разложены в многомерной модели или «CalcScript – это расчет данных»

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

К счастью, такая ситуация не является новостью, и эти все проблемы выявляются на этапе «опытно-промышленной» эксплуатации. И при выполнении нескольких условий, есть возможность вдохнуть жизнь в этот «трупик сознания»: в последующих реализациях модели расчетов все больше опираться на признаки метаданных (атрибуты, место в иерархии, составное имя элемента) . Т.е. уйти от модели разработки «CalcScript – это расчет данных» в сторону «процедурности»( данные + алгоритмы) или «CalcScript – это получение данных и расчет ». Т.е. предлагается в существующую алгоритмическую область расчетов искусственно внести сущность управления данными.

Как подход к разработке «CalcScript – получение данных и расчет » выглядит в реальной жизни:

  • На уровне описания функциональных требований и документации: Для каждого алгоритма описывается часть «Источник данных(получение данных)» и «Часть расчет» . Например
    • Шаг 1. Получить данные по оборотам (Форма 0101 Движение расходных материалов.))
    • …..
    • Шаг N. Рассчитать Остаток на конец = Остаток на начало + Движение материалов
    • ….
  • На уровне модели отдельно выделяется срез исходных данных и срез расчетов и корректировок. Для этого выделяется аналитика с соответствующими элементами (ближайший аналог направление «Value» в Hyperion Financial Management).
  • Для каждого алгоритма выделяют отдельное графическое правило (которое состоит из множества скриптов) , в котором часть «источник данных» описана как получение среза данных через функции отношения элементов в иерархии с определенным набором признаков
    • Т.е. для выборки определенного элемента в справочнике используется не его семантическое значение («А1», «A2» .. ), а его функциональная часть (все элементы, помеченные как центр расходов и относящиеся к региону «Восток»)
    • Часть «расчет» представляет собой отдельный скрипт, который инкапсулируется в нужных местах общего правила. Его реализация должна описывать алгоритм расчета, а не расположение элементов в модели.

 
 

Описанный подход требует особой дисциплины разработки, так как ничто не мешает программисту «упасть» в хардкод.

З.Ы. Перенос расчета из Essbase в PL-SQL физически разделяет слои «Получение данных» и «Расчет»

 
 

 
 

  

Запуск бизнес правил Hyperion Planning из командной строчки

Для запуска правил и набора правил из Hyperion Planning в интерфейсе командной строки нужно использовать программу CalcMgrCmdLineLauncher.cmd (CalcMgrCmdLineLauncher.sh для Unix)
Важные замечания:
Continue reading “Запуск бизнес правил Hyperion Planning из командной строчки”

Essbase: Calculation tips

При проектировании расчетов,  всегда встает вопрос какой один из трех способов (расчет по модели, использование формул или скриптов расчета) лучше использовать в том или ином случае. Когда  оправдано использование формулы на элементе, а когда нет.  Ниже мои рекомендации по выбору стиля программирования под EssBase.

Как всегда, нет универсального решения, которое бы перекрыло бы 100% вопросов  возникающих в процессе разработки бизнес правил. Поэтому я выделил  аспекты являющиеся краеугольными при разработке, а затем описал стиль программирования, который удовлетворяет данному аспекту.

Continue reading “Essbase: Calculation tips”