Reasons vary, but mostly it's that I've been, you know, busy-busy. As I now start to reflect on it, it's always a point of view thing and a question of self-control and ability to say no )

But enough philosphy, brief recap on what happend while I was out "there" in real world. I'll divide this into two parts (by vendors ))

Big Blue

Made some POCs in autumn, nothing that special (some neat integration, but not cognos-related). Carried on a couple of projects with  EP+BI typicalities. All in all, nothing that new.

BUT I've finally completed the other certification path there is at Cognos\IBM, notably, the "BI Professional" road. It's a deal longer, as of now, you have to pass 3 "role-based" exams, 2 mandatory (Report Author and Metadata Model Developer) and one of you choice to get a chance of passing BI Pro exam. It's used to coast 10k, which could be cut down to reasonable 200$ if you attended a Cognos Workshop (which costed 2,5k), but thanks to IBM that's gone and now it's 200$ from the start. Just opened certifications link and I'm, frankly, quite surprised with new IBM names for old Cognos certifications. According to this I'm:

• IBM Certified Designer -- Cognos 8 BI Reports
• IBM Certified Developer -- Cognos 8 BI Metadata Models
• IBM Certified Developer -- Cognos 8 BI OLAP Models
• IBM Certified Solution Expert -- Cognos 8 BI

and it turns out I was an

• IBM Certified Solution Expert -- Cognos 8 Enterprise Planning

instead of Cognos EP Professional.

Wording is something you cannot easily take from IBM ) Will put that list in about page, just to get more mail asking for exam questions.

Hint: In comparison with the old Modeler exam, current one is easier.

And in the first 2 months of this year we did a "nightmare-style" POC with EP + TM1 + BI, where I could finally get an idea of what TM1 really is and fully realize some ideas like incremental administration links and, therefore, "real-time" EP -> TM1  data propagation. I'm planning to write about this in separate posts, though. And, boy, it was hard, and we flanked the final presentation due to me being ill and bla-bla, and I'm still recovering breath from this.

But enough about IBM, let's turn to

Oracle

We've made a really nice billion-facts cube with our colleagues from "SportMaster" and talked about it in exceeding detail on Russian Oracle Technical Forum 2008 and Oracle BI Forum 2009. Essbase turned out to be a good engine for this kind of task and the moment when it finally kicked-in on 100gb dataset will retain as one of best in 2008. The fact that one of dimensions was a million rows parent-child didn't raise that much of a problem.

Moreover on another site we duly built dimension outline with around 30 mln members. Although duly is not the right word, "kicking and screaming" would be a better wording ) And the whole area of trying to tune something in underlying Berkeley DB is still open. But I must admit, an 8 gb outline file is really impressive.

So I've spent pretty much time toying around with essbase (except when I wasn't with TM1)). And I'm also a Hyperion Essbase 9.3 Developer Certified Expert (I won't enter Prometric for a while, I hope).

So it was a rather crowded time and I hope that nothing will stop me from blogging some details and future encounters. At least, I'd try my best to. Cheers to your patience, folks )

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.

Well, with a huge lot of bugs inside, it's time, gentlemen, to power up virtual machines and start testing it all over. We need to log on maximum of bugs before sp1.

New enterprise planning goes under Cognos 8.4 (BI version was out a month earlier), and this minor number increase doesn't reflect the amount of changes. They'd better start it of with 9.0 it seems.

Today I just want to add some of points:

1 If you're up to publishing some serious amount of data, variant with adding a dummy dlist with 1 item and using it as dimension for publish seems a very bad idea.  You're terribly slowing proccessing and wasting tablespace. So you have to choose a dimension for publish to reduce table size and speed things up

2 Dimension for publish must be:

a Stable. It shouldn't change or change very rarely, since these changes will cause Framework Manager models \ ETL models changes.
b Have sane (~3-33) number of elements. If less than 3, there's no win in performance. If more than 30, ensure it won't change, because big dimensions change more often than small ones.

3 There are dlists that are naturally stable aka measures, like {Quantity;Price;Sales}

4 In other cases timescale seems a really good choice. For example, if months dimension doesn't have year signs in name (like Jan, Feb, Mar), columns in publish won't change ever.  To work with timescale published data you can use sql unpivot queries, that will virtually turn it into view publish, but it'll way more effective than publishing it by 1elem dimension in first place. I've settled for this variant in my current project. Moreover, if you wrap this unpivot sql into ETL procedure, you can treat all published data uniformly while loading into datamarts (publish all needed cubes on timescale, use the same etl procedure).

- using oracle

- using ms sql server

Same old "If you are loading data, drop indexes" roams

One of the applications was discussed in this communities topic. By the way, I'm spending much time on communities these days (it's a very slow site, so no surprise) and I recommend it as a valuable resource for finding cognos-related answers. A steady pace of 10 topics a day gives a rather solid knowledge base now, after 4 months of uptime. If only it was faster, sigh...

So how to catch the fact that user changed this specific cell?

Simple, you just have to remember about virtual dimensions and calculation rules to build a "trigger".

1 You add a simple dlist {value, old_value, new_value_flag}, with new_value_flag = (value?=old_value). new_value_flag is a dlist-formatted element with (yes\no) elements.
2 After user inputs new data into cell, this flag will change to yes (by IF formula) and you can use this data by writing an accumulation dlink using only new data (select yes value from new_value_flag virtual dimension).
3 When you've finished processing freshly inputed data, you just run another link that copies value to old_value, and that sets the flag back.

Ps: It's too bad we didn't follow that topic on communities to a logical end.

Here are some ideas of how to speed admin links up, using the same principle as in incremental publish: transfer only changed data. So when only 2 CFO's submitted data, all 200 don't have to be moved and recalculated once again.

Let's look at the scheme of incremental publish:
- every time inc publish is run, a timestamp is set to point the run time
- during run inc publish selects only elists with change date more than inc timestamp, this meaning that these elists data was changed since last inc publish

So we need 2 tools:
- One to set & store & query the run time. Let's call it "Egg-Clock"
- Other to run the task selecting only limited number of elists. Lets call it "Select Elists, Run Job" or "SERJ" )

Egg-Clock is pretty simple in all cases, you just record the timestamp somewhere (text file, table etc) and return it back.
SERJ was almost simple for publish -- you've had to recreate publish macro, specifying needed elist guids.

How can we do this with administration links? I'm pretty sure some people in Cognos are writing built-in utility for inc admin links right now, but sometimes you have to get things done without waiting for another major release.

1 Use query subjects and package import
How to:
* You set up incremental publish on application to make it's data always ready for transfer.
* Create a query subject on that published data that you need to transfer
* Set up a filter on that query subject using Egg Clock to select only elists that have changed since last incremental admin link run time
* Create an administration link from filtered query subject to your target application.
* Create a macro that will run this link and update Egg Clock and there you go. You can add an incremental publish in this macro to make it completely independent

It's a rather straight-forward solution and quite easy to set up.

2 Use duplicate applications and No Data Settings
We'll try to use following rule: when administration links are run No-Data items are not transfered. It's rather cumbersome solution, but maybe someone will like it )

* Create a copy of your source application (yep, the same application, just another copy)
* Add an imported access table in that application, opening selected elists on read or write. Set default level to No-Data. It should apply to all cubes in application, delete other ATs if necessary.
* Use Egg Clock to generate this access table, select only elists changed since last run time.
* Create link, copying your source application to this duplicated application.
* Create all your desired links from duplicated application rather than from source one.
And in macro do following:
1 Create access table based on Egg Clock -- only changed elists
2 Import this AT into duplicate application
3 GTP duplicate -- this will cut-down all other elists, except changed ones
4 Run links from source to duplicate -- since No-Data is applied only changed will transfer
5 Run links from duplicate to target -- again only No-Data elements

3 Try to modify .cal export files and import them back
Just to mention -- don't do it.