A couple of small, but oh-so vital Cognos Enterprise Planning Enchancements

ykud — Thu, 11 Sep 2008 06:19:10 +0000

Why am I writing this?

Well, sometime it helped and we now have allocation tables in administration links. Although I’m sure my post didn’t have any impact, some deem hope remains

I’m going to repost this into Communities and into Insight. And, maybe, we can create some noise by voting for these enchancements in Insight aka registering those enchancements again (they get piled up together, as I’ve found out).

Some those two echs are:

1) Easy as: “Add the ability to import Calculation Options and Weighting while importing a dlist”

If you’ve ever done some external dimension management, you know that:

- you have to use unique names to keep dlist IID the same when names (but not unique codes) of items change

- you can import formulas as calculation text, just put item names in curly brackets )

- if you use Update\Remove obsolete it always deletes all Calc Options and Weighting from dlist. That means that you cannot update any cacluation dimensions, such as Accounts.

So you manage all simlple dimensions by updating them (with Remove Obsolete selected) and unique names, and you manage all dimensions with weighting by manually changing them.

Shouldn’t be like that.

2) Even simpler: Add a Contributor macro for importing translations

It seems weird to have a single table with translations for Cognos BI and then to manually (or semi-automatically by text import) copy it into Contirbutor application. Shouldn’t be hard, ability to import translation text is already there, just need a macro step

3) And another one (maybe no one will notice): Import deployment packages as a macro step too

Automating dev-prod. backup-restore — all those things that should be automagical

So, if these things annoy you as well — drop me a line, and I’ll send you Cognos Insight ench numbers to vote for.

Enterprise PLanning Objects Naming Convention.

ykud — Fri, 16 May 2008 10:54:50 +0000

As I’ve promised, here are naming conventions I tend to follow in EP projects.
Setting up naming rules doesn’t seem so crucial at project start, but generally hits on you on the head on final phase, when development turns to support. And trying to support your colleagues model will leave you thinking about naming objects the same way more than once So naming conventions are one of main project documents for me now.

I really expect and encourage comments on this naming proposal. Maybe together we will create something like Sun Java Code Conventions )

Object	Naming rule	Example
Analyst:
Library	Library names are not that important, though if you use Analyst with Contributor, consider creating stub libraries for importing data to\from Contributor, as I’ve described here. No data in skeleton library is a motto that will help you more than once, I guarantee. Library codes are important if you want to keep a single store of projects (in consulting company, or competency center) and you’d better create some seeding rules for creating unique 9 numbers for projects. A simple scheme of xxxxyylll, where xs are project code, ys — library type and ls — library order number will be sufficient in most of cases.	Sales_Planning_skl with code 777701001
Dlist	The main difference with Cognos initial coding standard. Dlists are numbered not up by their functions, but by type calculations happening in this dlist. I’ve got initial table from [Erik Thomsen's OLAP book][1] and modified it to suit EP better. So it goes like this: 1 – IF-ELSE formulas 2 – *,^, / 3 – Common Sums 4 – Timescale Sums 5 – No calculations Second difference: these numbers are used as suffixes of dlists names, not as prefixes. This allows quick search by first letter of dlist name when you’re browsing the library and all product dlists will be kept together, regardless of type. Third rule: only latin names with spaces substituted by _ (underscore). This guarantees that published tables will be named meaningfully and their names won’t mutate after time (a real problem with cyrillic dlist\dcube names).	Balance_Sheet_1 Products_3 Months_4
Dlist item names	One really useful hint: mark all calculation temporary elements (not to be seen user) with leading # symbol. This allows creating simple saved selection with filter that will easily hide all unnecessary elements from users in Contributor	#temporary_allocation_element
DCubes	Once again, only latin names with underscores to keep publish tables names sane. Contributor translations allow you to rename these cubes for end users with whatever names they’d like. No i\o\c, we’re out of kindergarten	Product_Sales_Global
Dlinks	“<" instead of ":" in separating source from target. And some hints like + when you've got an add link, - for subtract, to allow better understanding of link logic while viewing it in update list table.	BalanceSheet”<"Cashflow(+)
Macros	Latin verbs or sentences describing what you’re doing with macro. Latin due to necessity for batch running.	Update_Products_Export_Elists
Allocation Tables	Similar to links, just the allocated dimensions with some commentaries	ProductGroups”<"Products
File Maps	Whatever you like, I prefer filename	pl_export.csv
Contributor
Applications	Rather strict rules are implied by Contributor itself, so i’d just advise to name aplications meaningfully, given that these names will always appear in browser connection string. No doubt that seeing “sales_plan_v8_will_it_ever_work” will ensure users. No grammar mistakes or typos, please.	sales_plan_by_brands
Access Tables	Access Tables should always be named. It’s best to write a short sentence, describing access table meaning	Closing product list based on managers responsibility
Saved selections	Plain common sense: explain what this selection selects )	Accounts_special_calc_items
Administration links	Need suggestions here. Since Administration link is a pack of links, I use macro notation — verbs describing the process, but I put target application first	sales_plan_by_brands update from regions
Macros	Need suggestions here too. Again some action descriptions, but I don’t have a common approach of separating macros by applications they’re working with or smth like that. Moreover macros aren’t grouped anyhow, so I sometimes tend to prefix macros with some block group with following description	Sales_submission sales by brands to sales by regions
System Links	These are for users, so names should be descriptive actions	Load new currency rates

~~Whoa, it’s a really huge document, maybe I’ll it finish someday…~~

[1]: http://www.amazon.com/OLAP-Solutions-Building-Multidimensional-Information/dp/0471400300

Applied dimensionality » analyst

A couple of small, but oh-so vital Cognos Enterprise Planning Enchancements

Enterprise PLanning Objects Naming Convention.