Cube View using attribute based Hierarches. Cannot use as TI data source

[JohnO]

I'm interested to see if others have tried this.

I have a product dimension and have created attribute based hierarchies (Brand, Size, Colour etc) and then I created a cube view. The cube view created is pure MDX, not accessible in the old interfaces which is fine. What I wanted to then do was to use this cube view as a data source for a TI as we can do with traditional cube views. The Process editor in PAW had no objections to me using this view as a data source but expected the input dimensionality to be the same as the cube, not the same as the view. When I ran it of course it errored on all lines because there was a dimensionality mismatch. Of course one of the problems is that views which use attribute based dimensions can have variable numbers of dimensions so there needs to be a much smart way of using it as a data source than the traditional approach.

I'm wondering if anyone else has tried to go down this path and whether they found some other approach. I did try the approach of using ViewMDXGet (Which worked) to extract the MDX but I cannot see a way of then meaningfully using it to generate a data set within the PA world.

[Steve Rowe]

Hi JohnO,

I'm using MDX views as datasources in TIs so there should be no issue there.

From where you are saying you have multiple hierarchies from the same dimension in the view and therefore the dim count for the view does not match.

I would try pointing the TI at a cube (create one if you need to) with the same number of dimensions as there are hierarchies and dimensios in your source view.

Then switch the datasource at runtime to the actual cube and view you want to use.

It may be that this won't work either as it is probable that a TI is hardcoded to assume the same number of inputs as there are dimensions in the cube.

Whilst I can see why you would want to do what you are attempting, if your hierarchies are driven by attributes then these will still be available to you when processing a native view, so you should just be able to look up the attribute values when processing a view.

[JohnO]

Thanks. But the idea is that I want the user to define the view and then I want to use what they have defined and use that as a datasource. Do it needs to handle attribute dimensions and variable count . I do have a totally different approach to fall back on which involves legacy items but it will not be driven by a user engagement in the standard UI as one of the problems with a legacy view is that a user can only use attributes to filter dimension elements via MDX, which is very nasty for a user. My approach will involve them defining selections differently but they will not be able to see the results until they click a button and a view is generated.

Oh and there was another issue I encountered. When a user creates a view it is private and so we need to make it public to consume it in a TI. But PublishView does not work on MDX views.

[MarenC]

Hi,

Why can't you grab the Client inputs in PAW via the client attribute cube and build a view with MDX based on what the client enters into these attributes?

Maren

[PavoGa]

This sounds like this issue:

viewtopic.php?f=3&t=14714

which is a known issue and has been recognized by IBM as a bug. Using alternate hierarchies in an MDX view as a datasource does in fact change the order in which dimensions are processed.

[lotsaram]

... which is a known issue and has been recognized by IBM as a bug. Using alternate hierarchies in an MDX view as a datasource does in fact change the order in which dimensions are processed.

I have a case linked to "PH24729 WRONG VARIABLE ASSIGNMENT ORDER IN MDX-VIEW PROCESSING" which has been open for close to 2 years. The last update was in April 2020 which was to inform that the defect was recognized. I haven't tested in 2.0.9.5 but as PH24729 wasn't listed in the fixes for either 2.0.9.4 or 2.0.9.5 I'm assuming this frustrating bug is still there.

[JohnO]

... which is a known issue and has been recognized by IBM as a bug. Using alternate hierarchies in an MDX view as a datasource does in fact change the order in which dimensions are processed.

I have a case linked to "PH24729 WRONG VARIABLE ASSIGNMENT ORDER IN MDX-VIEW PROCESSING" which has been open for close to 2 years. The last update was in April 2020 which was to inform that the defect was recognized. I haven't tested in 2.0.9.5 but as PH24729 wasn't listed in the fixes for either 2.0.9.4 or 2.0.9.5 I'm assuming this frustrating bug is still there.

Thanks, I think what I am encountering is an extension of that issue. Not only does the order of dimensions in the MDX view not match that in the cube, the dimensionality itself is different (Using attribute based dimensions) and given I want the user to define the view we could never pre-define a TI based on such a view with the current design of TI's. I think this is more than a bug, I think it's a very fundamental matter that TI's expect the cube view to match both the dimensionality and the dimension order of the cube.