Feeding from an alias

[tm1starter]

Hello all,

I have a problem with a feeder, see below;

(Simplified example)
I have cube 'Employee' with dimensions;
Scenario
Period
EmployeeMeasure
Employee

And the cube 'Result' with dimensions;
Scenario
Period
Account

I have a alias in 'EmployeeMeasure' called 'TargetAccount' which holds account numbers from the Account dimension. To get the values from the employee cube to the result cube, I have the next rule;

Code: Select all

[]=N:IF(DIMIX('EmployeeMeasure', !Account)<>0,
			DB('Employee', !Scenario, !Period, !Account, 'All employees'),
			CONTINUE);

It's working fine.

In the cube 'Employee' for example I have the feeder;

Code: Select all

['411']  => DB('Result', !Scenario, !Period, !CostCenter, '411');

In which '411' is an account in the account dim and an alias for one of the measures in EmployeeMeasure. This feeder is working fine but only for one measure
I want this rule also to work for the other measure with a target account. Therefore i created a C-element 'TransferedValues' which holds all the measures that have a target account. So I created this rule;

Code: Select all

['TransferedValues'] => DB('Result', !Scenario, !Period, !CostCenter, !EmployeeMeasure); 

This one isn't working, and i think it should. I feed from a c-element what is actually feeding from the leaf n-elements and the alias should match the accounts.

I've also tested this one;

Code: Select all

['411']  => DB('Result', !Scenario, !Period, !CostCenter, !EmployeeMeasure);

This one isn't working also.

So, I think I'm missing something about feeding and aliases. I've seen some posts on this issue but they are not clear to me (http://forums.olapforums.com/viewtopic.php?f=3&t=681).

Hope someone can help me, thanks in advance!

[lotsaram]

As identified in the post you referred to aliases work when pulling values via a rule but do not work when pushing via a feeder.

What you need to do is convert the employee measure into the correct account name as the alias won't be interpreted as a match for a feeder it must be an element name. Your feeder would then look something like:

Code: Select all

['TransferedValues'] => 
DB('Result', !Scenario, !Period, !CostCenter, AttrS('EmployeeMeasure', !EmployeeMeasure, 'TargetAccount') ); 

Note it doesn't have to be an alias. In situations like this I actually find it better to have matching text attributes with "opposite polarity" in each dimension to do the mapping and always do the conversion in each direction by nesting an AttrS function. That way it is much more obvious what is going (i.e. a mapping of one dimension to another) on and also easier to debug.

[tm1starter]

Thank you, it works now. Haven't tried this one because I thought ATTRS wouldn't get me the alias, but it does!

[jstrygner]

I thought ATTRS wouldn't get me the alias, but it does!

There is a trick with ATTRS returning aliases though. I think it is not an issue in the case of this post, but it is good to be aware that when element basic name and element alias name are the same, ATTRS will return an empty string.

This is because in the }ElementAttributes_ cubes only aliases that differ from the basic name are stored, otherwise cells are empty and that is what ATTRS returns.

Example:
So probably in your 'Month' dimension, where you decided to have a 'Short Name' alias for elements from '1' to '12' you'll probably get:
- ATTRS('Months', '1', 'Short Name') will return 'Jan'
- ATTRS('Months', 'Q1', 'Short Name') will return ''

Workaround:
Check if ATTRS returns '' and if it does, take basic name - in TI does not look that terrible but in rules it does

[lotsaram]

There is a trick with ATTRS returning aliases though. I think it is not an issue in the case of this post, but it is good to be aware that when element basic name and element alias name are the same, ATTRS will return an empty string.

This is because in the }ElementAttributes_ cubes only aliases that differ from the basic name are stored, otherwise cells are empty and that is what ATTRS returns.

I don't think that's the case. Maybe if you use the attribute editor UI to hand type attribute values (but who does that? ) But if attribute values are entered via AttrPutS or DBSA or entering strings into the }ElementAttributes cube then you can force TM1 to hold strings for alias values that are the same as the element principal name (or the same as the principal name but with more or less space characters) and then AttrS will return the correct value not a null sring.

[jstrygner]

Maybe if you use the attribute editor UI to hand type attribute values (but who does that? )

Well... in case of Months I do it this way . And in such a case cells are blank (even if you paste the whole column of aliases, not just for elements that have different aliases and basic names).

I checked what you wrote on my 9.5.1 HF 11 and it is just the way you posted.

But till now I was sure I had such an issue in one of former versions (definitely before 9.5), so I tried those days to type the aliases manually in the }ElementAttributes cube and they were there only till server restarting. After that they came back to blank. Now I am not so sure about it.

On 9.5.1 HF 11 after server restarting all aliases remain. Good to know, thanks.

[qml]

But till now I was sure I had such an issue in one of former versions (definitely before 9.5), so I tried those days to type the aliases manually in the }ElementAttributes cube and they were there only till server restarting. After that they came back to blank. Now I am not so sure about it.

On 9.5.1 HF 11 after server restarting all aliases remain. Good to know, thanks.

As you might remember we have checked this in a couple of different 9.4.x versions and it worked the way you said (i.e. no duplicated alias values stored in the cube).

They must've changed that and, as usually, documented the change pretty well.

[lotsaram]

Well there you go, I only tested on 9.5.1. Although I can't recall ever coming across issues from AttrS returning empty strings for aliases in the past, but nothing would surprise me in terms of changes being made to functionality and not documented.