More on Contrib APs.

It’s more a list of demands for Cognos :)

We need allocation cubes with an elist. There is no other way round the idea of dynamic Contributor applications. Dynamic as Analyst ones — by changing allocations in cube, you change data flow. Ain’t that analytic?

What if we use footage as driver for lease costs? Or, maybe, headcount?

That’s a click&go in Analyst, and a click&synchronize&reconcile&what happened to everyones budgets in Contributor.

And, of course, we need some kind of alloc cubes/allocation tables for Administration Links. Because any way of manual allocations is potential threat to system “clearness” and reason ability. And, just for remark, no “virtual” dims in amdin links.

But we need to build systems right now, so I propose such variant.

Two Contrib APs, A and B. Data ought to be transfered from A.Cube1 to B.Cube2 and they are of entirely different formats. So possible admin links will have a huge amount of manual allocation.

So we create a “transformation application” (TA), that has, for our example, Cube1, Cube2 and a set of allocation cubes, used to transform data X->Y. Those allocations cubes do not have an elist and are updated in Analyst and synchronized later.

So to send data from A to B we first send it to TA.Cube1 and then get data from TA.Cube2 to application B.

A.Cube1->TA.Cube1->TA.Cube2->B.Cube2

Click on the scheme to enlarge it.

TA_Scheme

Pluses of such scheme are:

1 speed compared to A->Analyst transformation->B. Everything is transferred via Admin links, clustering and etc

2 control. All Admin links are mathced desc, and transformation is dictated by alloc cubes, managed from Analyst.

Minuses

1 speed compared to A->B, with manual alloc in admin links. Minus 1 link executed and 1 gtp (getting data to TA).

I’ll stick to this scheme until elist-enabled allocation cubes are avallaible.

UPDATE: There’s a workaround for making simple allocation cubes in Contributor — see this post

  • Pingback: Contributor Allocation Cubes | ykud

  • Pablo

    Great Idea,

    but I have a question. The TA application has an Elist with only one node ?

  • http://ykud.com ykud

    “The TA application has an Elist with only one node ?”

    Only if there’s no other way.
    If both apps (source, target) have the same elist, then TA has that elist.
    If elists are different, then I’d choose largest common dlist of source and target apps as an elist. There’s always time dimension or something.

    Large elist allows admin links and reconciles to be chunked into more pieces and that will leverage your job cluster.

  • Pingback: Applied dimensionality - A couple of small, but oh-so vital Cognos Enterprise Planning Enchancements