Hi Colin,

It's been a while since I used them, but I think POST /Info/Filters returns some information on dimensions/hierarchies/levels, and POST /Info/FilterMembers returns information on the members of a level. If you need metadata on properties specifically, I'm not sure if that is included. I don't think we have information on namespaces as part of the REST API for IRIS BI, but maybe someone has a suggestion of other ways to get that kind of information about an IRIS instance over REST. Anyway, I'd recommend taking a look at those two /Info services, and possibly opening a WRC issue if you find that they don't provide what you need.

Hi Jenna,

Is something like this what you have in mind?

SAMPLES>set relatedFilters("[DateOfSale].[Actual].[YearSold]") = "&[2021]"
 
SAMPLES>set sc = ##class(%DeepSee.Utils).%GetDimensionMembers("HOLEFOODS","[DateOfSale].[Actual].[MonthSold]","filter",.members,,.memberClass,.relatedFilters)
 
SAMPLES>zwrite members                                                         
members(1)=$lb("[NOW]","NOW","NOW","NOW")
members(2)=$lb("[Jan-2021]","Jan-2021","202101","202101","")
members(3)=$lb("[Feb-2021]","Feb-2021","202102","202102","")
members(4)=$lb("[Mar-2021]","Mar-2021","202103","202103","")
members(5)=$lb("[Apr-2021]","Apr-2021","202104","202104","")
members(6)=$lb("[May-2021]","May-2021","202105","202105","")
members(7)=$lb("[Jun-2021]","Jun-2021","202106","202106","")
members(8)=$lb("[Jul-2021]","Jul-2021","202107","202107","")
members(9)=$lb("[Aug-2021]","Aug-2021","202108","202108","")
members(10)=$lb("[Sep-2021]","Sep-2021","202109","202109","")
members(11)=$lb("[Oct-2021]","Oct-2021","202110","202110","")
members(12)=$lb("[Nov-2021]","Nov-2021","202111","202111","")
members(13)=$lb("[Dec-2021]","Dec-2021","202112","202112","")

I'll admit I'm not completely sure why the NOW member is coming back in this case, since there shouldn't be any data with a year of 2021 and a month of NOW, but other than that I think this may be what you were describing.

Hi David,

When you selected the "Sort members" option in the pivot table, did you do it from the gear icon next to the "Rows" header, or from the one next to the specific level that you had put on rows? On IRIS 2019.1, I'm finding that the sort order remains when I drill down if I do the former, but not if I do the latter.

The KPI doesn't need to be the data source for the widget. You can specify the KPI class as the actionClass for a cube (this is an attribute of a <cube> element) and then the actions in it will be available to pivots based on that cube. That will in turn make those actions available as controls on widgets whose data source is a pivot based on that cube.

If the data source for a widget isn't a pivot or a KPI, I'm not sure whether it's possible to use custom actions on that widget.

Hi Lee,

The "range" language may be a bit confusing, so to be clear - %TIMERANGE() returns a single member expression.

I'm on a different version, but COUNT(%TIMERANGE(...)) appears to work for me, and it returns 1 (which is expected because %TIMERANGE() returns a single member). In general, member expressions like the result of %TIMERANGE() can also be interpreted as set expressions containing a single item, so I would expect COUNT(%TIMERANGE(...)) and the like to be valid MDX.

I'd suggest opening a WRC issue for this as well - it's great to post questions like this on the Developer Community when you're uncertain about the expected behavior, but once we've determined that the behavior you're seeing is unexpected, there is more that we can do to investigate and help you in the context of a support issue.

Hi Lawrence,

The shortest build frequency that the Cube Registry allows you to specify is once per day.

Hi Lawrence,

The .DFI files that define the pivots and dashboards will themselves always be found in the "Other" branch of the workspace due to their type. However, it's possible to package pivots, dashboards, and other DeepSee folder items into classes as described here. The resulting .CLS file(s) would be found in the "Classes" branch.

After looking at this some more, there are another couple of suggestions I would make:

- If you want to display each member of the [Gerencia].[Gerencia].[Gerencia] level in its own row, you should use [Gerencia].[Gerencia].[Gerencia].MEMBERS as the set expression on rows. Your current syntax will return a single row.

- It's unnecessary to wrap the set expressions on rows and columns in parentheses. (You may, of course, need to use parentheses in these expressions if they involve functions such as NONEMPTYCROSSJOIN(level1.MEMBERS,level2.MEMBERS), but an expression like [Gerencia].[Gerencia].[Gerencia].MEMBERS by itself doesn't need them.)

- If you aren't already using it, you may find it helpful to use the Analyzer, as this gives you an interface to create pivot tables to display the data you want without having to write the MDX from scratch and worry about its syntax. When you create or modify a pivot table in the Analyzer, the underlying MDX query is generated, and is executed either automatically (by default) or when you refresh the pivot. If your goal is to create pivot tables and dashboards, you may not need to interact with the query text at all if you don't want to; if you're running queries programmatically, you can create a pivot table and then view the MDX that was generated (click on the pencil-and-paper icon above the "Columns" box) and use it as a template for your queries.

Hi Lawrence,

You can create cube relationships as documented here, which will allow you to reference data in one cube from another cube (if records in the source class of one cube are related to records in the source class of the other). However, if I'm understanding your question correctly, that may not be the best approach in your case.

For one thing, I'm not sure why you have created two cubes instead of one cube with some additional elements. Is each of these items you're discussing a single record (i.e. a fact in your cube)? Or is it a property of each record (i.e. a model element in your cube)? If it's the former, you could add properties to your existing levels as necessary, whose values could be the human-readable names, generated/fetched if necessary by source expressions. If it's the latter, you could add display names to these elements in your cube definition.

It sounds to me like it might make sense to open a WRC issue to work with support on these questions, since they're fairly specific to the cubes you are creating - please feel free to do that if you'd like, and one of my colleagues or I will be able to work with you on this.

Hi Laura,

After installing the JRE, I believe you need to restart either the Caché instance you're using or the server you just installed it on before you can use it to export PDFs from DeepSee - have you tried doing that? I haven't had a chance yet to test and figure out which is necessary (based on the fact that you can use the JRE from the command line, restarting the instance might be sufficient), but if it's convenient to try that, it might help.