Forum Discussion

RossLikesOS's avatar
RossLikesOS
New Contributor II
4 days ago
Solved

Alias Dimension Property in V9.1

The newest release (9.1) of OneStream introduces the Alias property for just about all of the dimensions.  The only place so far where I have found the Alias as being useful is in search.  I have not been able to figure out the correct syntax to be able to use the alias in Cube Views, Quick Views or any business rule.  My guess is that we are going to have to create a custom business rule that will allow us to call the Alias name and present in a viewable format.

Does anyone have an example of where they have been able to display an Alias value in a Cube View or Quick view instead of displaying the default member name and/or description?

  • You should not need any rule to use aliases. The point of aliases is not to display; they are meant to be used for references, so that you can use A#MyAccount or A#MyAliasAccount and the cube view will show MyAccount either way.

    They are mostly expected to be used incrementally, as metadata evolves, to avoid artefacts from breaking when members are renamed. From the documentation (the bold is mine):

    Aliases are optional names that you can use as alternative ways to reference members from areas such as Member Filters, Cube Views, or Business Rules. This enables you to use additional, readable names for dimension members in new or existing solutions, without disrupting existing solutions that reference the main dimension member names. For example, you can add the original dimension member name as an alias before renaming the dimension member name to ensure existing solutions referencing the dimension member do not break after the name change. Multiple aliases can also be added to the same dimension member through a comma-delimited list.

    Note that this property should not be confused with what the documentation calls "Alias Member Descriptions"; those are culture-specific descriptions that will only be displayed when the user is configured with a different Culture in the Security page, or when you force a Cube View to display with a specific Culture.

3 Replies

  • JackLacava's avatar
    JackLacava
    Icon for OneStream Employee rankOneStream Employee

    You should not need any rule to use aliases. The point of aliases is not to display; they are meant to be used for references, so that you can use A#MyAccount or A#MyAliasAccount and the cube view will show MyAccount either way.

    They are mostly expected to be used incrementally, as metadata evolves, to avoid artefacts from breaking when members are renamed. From the documentation (the bold is mine):

    Aliases are optional names that you can use as alternative ways to reference members from areas such as Member Filters, Cube Views, or Business Rules. This enables you to use additional, readable names for dimension members in new or existing solutions, without disrupting existing solutions that reference the main dimension member names. For example, you can add the original dimension member name as an alias before renaming the dimension member name to ensure existing solutions referencing the dimension member do not break after the name change. Multiple aliases can also be added to the same dimension member through a comma-delimited list.

    Note that this property should not be confused with what the documentation calls "Alias Member Descriptions"; those are culture-specific descriptions that will only be displayed when the user is configured with a different Culture in the Security page, or when you force a Cube View to display with a specific Culture.

    • RossLikesOS's avatar
      RossLikesOS
      New Contributor II

      Thank you Jack!  Great explanation.  I was thinking this I would have been able to use XFGetMemberInfo or XFGetMemberProperty to pull the value in the Alias field.  Doesn't seem to work that way.  I pulled the alias succesfully in a cube view and in a quick view using the alias in place of the member name.  Works as expected.

    • RobbSalzmann's avatar
      RobbSalzmann
      Valued Contributor II

      Excellent description Jack!
      So if i'm understanding the concept, would this be another way of putting it?:

      For a robust, flexible application: code & parameterize by alias, report by member name.

      Taken a step further, if I have calculation logic that needs to be changed, e.g. point to a different driver, then I leave the code alone, and move the alias to the new driver account?