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.

The place to specify the sort order for a level is in the cube definition. In the Architect, open the cube you are using, select the level that you want to change the sort order for, and look at the Details panel for that level (on the right-hand side of the Architect page). In the "Sort option" dropdown, choose "asc numeric", and then compile your cube definition. (It is not necessary to rebuild the cube after making this change.) You should then be able to refresh the Analyzer, put the same level on rows, and see that it sorts in ascending numeric order.

Hi Lawrence,

Here's a general outline of the steps to create a DeepSee dashboard, starting from data that is somewhere on your system but not yet in a DeepSee cube:

- Get the data you want to use into a persistent class, referred to as your source class. Depending on what you are doing with the data that comes in via your REST service, you may already have such a class, or you may need to create one and store a copy of your data there after it comes in.

- Use the DeepSee Architect to define a cube based on your source class. This will allow you to specify which properties of your source class you want available for use in pivots and dashboards. You can then compile and build your cube, which will create a fact table (and several other tables) to store an indexed copy of the data you have specified. There is documentation on defining cube models here.

- Use the DeepSee Analyzer to create one or more pivot tables that display data from your cube. There is documentation on creating pivot tables here.

- In the DeepSee User Portal, create a new dashboard and add one or more widgets to it. For each widget, specify a pivot table as its data source, and then customize the widget to display a table or chart, adding any filters or other controls that you want to give users access to. There is documentation on creating dashboards here. (It sounds like you may already be familiar with this step, once you've created a pivot, but I'm including it for completeness.)

For some of these steps, there are alternative options to the ones I've mentioned here, but these are the most common options and I would recommend using them to start out (and really whenever possible). Please let me know if you're having problems with the specifics of some part of this.