You are currently browsing the archives for the ep category.
Okay, it has been almost half-a-year (oh, dears) since the last decent post on this blog. Russian one has suffered as well, I must note.
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 ))
Just a quick tip: read this cognoise thread thoroughly -- really in-depth discussion.
Go check the download page.
One wonders, what's that 64-bit BI server is all about -- they've really pushed the report server further, or that's just compatability release.
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.
With so-long waited new Contributor client, with expand\collapse and nest dimensions features. And a lot, lot more. ActiveX free ) Actually, as long as I'm with cognos ep (since adaytum 2.4), contributor was always the same good-old-rigid tool, so it's a revolution indeed.
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.
I already wrote some notes on choosing dimension for publish in this post.
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).
2 excellent Proven Practices documents were published today, describing how to speed up publising (cognos.com login is required):
Same old "If you are loading data, drop indexes" roams 
A lot of work stops me from investigating it further, but I've experienced some errors in admin links (dlinks) from cognos package when data contained double qoutes (").
I guess, this is due to the fact that package links generate an xml mapping file (source to destination) which contains lines like
Anybody out there with similar problems?
There are some situations when you definitely need some way of recognizing new input from user. These are rather rare occasions, but when it's nice to have such a tool is sack.
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.
In 8.2 we've got incremental publishing, allowing us to create real-time reporting on contributor data and that sets up new frontier in model data transfer speed. Now the slowest part of models are administration links (who'd guessed that when 7.3 appeared).
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.
Read the rest of this entry »
Powered by FireStats
Recent Comments