Hopefully quick, possibly stupid question re Analyst Macro and Admin Links

[andyhofer]

I am running 8.4 and I am using a contributor macro to run an analyst macro that runs a D-Link moving data from a contributor assumption cube in production to E-List D-cube. This was done so that I do not have to change assumption values in Analyst on the dev environment and then have to deploy it to our prod environment. It enables the user to change the assumption values and run a macro to cascade across the model themselves.

The question I have is once the values have been moved out of an assumption cube to a standard cube, is it better then to cascade the data across the rest of the model using a contributor macro to run an admin link, or should I continue to get the contributor macro to run another analyst macro to run a D-Link? Perhaps the outcome is the same, but best practice may dictate one over the other.

Thanks
???

[StuartS]

My thoughts.

If the further cascade of data is from the cube with the elist than I would suggest an admin link.  There may be too much data for an analyst link.

[andyhofer]

Thanks Stuart

Yes it would be from a cube with an E-List, although this E-List is just 1 item called "Dummy" because it's just pulling assumption values for the whole model from a contributor cube.

I assume that if I use the Analyst macro method I'd need to run Sync and GTP each time?

[StuartS]

On the analyst macro and the need to sync and gtp, it depends.

If the D-Cube you are updating is an assumption cube, no elist, then you need to sync and gtp.

If the D-Cube includes the elist then it depends on the options chosen in the D-Link.  In other words when you create the D-Link if you choose the production version of the contributor model then the gtp will happen automatically.  If you choose the development version then you need to gtp.  (no sync as not an assumption d-Cube, contains elist).

As a note, even though the D-Cube has one item called dummy, there still may be too much data if you have a large elist. 

A thought, if the users have run the analyst macro with assumptions, have you considered using a system link?  This is user executed.

Hope this helps.

Stuart

[andyhofer]

I have considered a system link, but the reason for the process is to avoid us having to do a deployment to get the info into the production servers. Our IT department do not allow us to access either Analyst or Cont Admin on the Production Servers. Therefore any Assumption cube changes are being done in Analyst Dev servers and then deployed which can take a couple of hours depended on how busy IT is.

We wanted to get round this and enter the Assumption changes ourselves (Contributor Cube) and then run a macro that would cascade the assumption across the whole model rather than individual end users having to system link every E-List (Cost Centre) individually, hence an Admin Link. The contributor admin macro would then be available over the web for the high level user to execute the Admin Link.

Hope that's clear.

Anyway, Thanks for the advice, I should be able to continue with creating the admin links

Andy

[andyhofer]

Just another quick question, I can see that you can do a D-Link from a cube with an E-List (Dummy) to an Assumption Cube, but can you do an Admin Link?

When trying to create an Admin Link the Assumption Cubes do not show up in the Target Application so therefore I guess you cannot use an Admin Link to update an Assumption Cube.

If I'm wrong you're allowed to call me stupid, along with some guidance of course...

Thanks All

[StuartS]

 ;D ;D

You cannot use an admin link to populate data in an assumptions d-cube.  (Im using 8.1 but dont think this changed in 8.4)

From what youve said gives you a problem...   ???

Cheers

Stuart

[andyhofer]

Mmmmm, problem then I have....

Perhaps I should change the assumption cube in my application to have an E-List called the same as the source cube "Dummy" and then get the Admin link the target all E-List items with the Dummy E-List value.

Therefore if I want all E-List (Cost Centres) to have the same inflation applied, the cube with the Dummy E-List would hold the one inflation value, and then when I create the Admin Link this one E-List would point to all target E-Lists and get them to use that same inflation rate.

Should work ???

Just so we are clear, the reason for this approach is so that what normally would be in an assumption cube and updated in Analyst is instead available over the web, therefore giving the impression that an assumption value is changed over the web and cascaded across the model by the Admin User using a web available macro.

Andy

[StuartS]

Dont you just love IT departments and their rules!!

Are you suggesting two elists in your model?  Dont believe you can do this.

Have you considered another approach. A technique I use.

I have an input D-Cube (Cognos Manager), or txt file, that is processed by an analyst model in a supporting library called dataprep.  There is an analyst macro that creates a series of txt files (@DCubeExport) that are then loaded into the model using a contributor macro (Copy, Load, Prepare).  This would get round your problem?  You could have an input cube, or txt file, then a user executed analyst macro and contributor macro.  Using this approach you could have small input file that then gets spread across the elists in the "dataprep" library.  This approach would also allow one input that leads to the creation of many txt files automatically, (1 txt file per D-Cube in your contirbutor model).

Stuart

  :)

[andyhofer]

Dont you just love IT departments and their rules!! :-X :-X Don't you just

Are you suggesting two elists in your model?  Dont believe you can do this.

I'm aware that you cannot have more than one E-List in a cube or an application, depends on your definition of a model, I see a model as a number of applications and as such you would be able to have more than 1 E-List per Model, ie, one per application.

My model is created so that all Assumptions would be handled in one application called "Assumptions", this would contain the "Dummy" E-List mentioned before, then when they are Admin Linked to other Applications I was thinking that the E-List in the source "Assumptions" app would map to all E-Lists in the Target Apps. I thought this may work and haven't actually tried it yet.

If you think this isn't doable then I'll look at your suggested technique, it's a bit early and it's making my head hurt, think I need a few Expressos.

Andy

[StuartS]

Interesting.  An "Assumptions" model is one of my future projects.

My approach to an assumptions model will be a mix of data load to that model and data entry.  The D-Cubes in my assumptions model will have an elist, as suggested with yours.

In this, and your example, this means a model to model admin link where the target has an elist.

An elegant solution!   ;D ;D

[kashif]

Andy, I am not sure if this is right, but I understand that you are populating a cube in an assumptions application over the contributor web client.  And you would like the updated assumption values reflected in the other models.

The way I see the process working is as follows:

1.  Update values over the web in an Assumptions application
2.  Run contributor macro from the web, which does the following
      2.1  Runs an analyst macro which downloads the latest data from the web and populates the assumption cube in Analyst.  Done using a D-link.
          2.1.1 The macro then executes another Analyst D-link which take the values from the assumption cube in Analyst to the other Analyst applications you want to update .
      2.2 The contributor macro then performs Sync and GTP of any applications that are being updated.
3.  The updated assumption values would then be visible over the web.

With the issue of development and production.  Once you create this in development and it gets promoted to Production.  It would be exactly the same procedure and should work fine.  To ensure that development and production remain in sync would require a further process to be developed.

Hope this helps.

Kash