This post is an introduction to Tree Views in OneStream Dashboards, a type of widget that can render hierarchical data. Their complexity can vary, as you will see below, but once mastered they will be a powerful weapon in your reporting arsenal.
Let’s start with the simple no-code examples. These are recommended for their simplicity.
No Code – Member Select Button
We can generate a hierarchical view of a dimension in OneStream simply using a button. In this example we use the Button Type Select Member.
Once we chose the button type, we get some additional options (highlighted below) where we are prompted to add Dimension Type and we can supply the Dimension, Cube and Member Filter if we want to restrict the result that is returned - in which case, one can set Use All Dimensions for Dimension Type to False.
We also add a Bound Parameter, here called mbrSelect. This will contain the parameter value generated by our selection, to be used elsewhere in the Dashboard.
The result will look like this, once the user clicks on our button:
No Code – Member Tree
Another commonly used approach to get a Tree View that does not require code (just configuration), is by using the Member Tree dashboard component. Here we can take a Parameter of type Member Dialog and input the Cube, Dimension Type, Dimension and Member Filter.
We can then create a Member Tree component and add this Parameter as the Bound Parameter, and add this component to a dashboard.
The result will look like this:
Between this approach and the previous one, you'll likely be able to manage most situations where you might want to display a hierarchical view of metadata members. However, for ultimate flexibility, you can reach for some programming to achieve exactly what you want.
Code (Simple) – Tree View
We will now see some of the concepts and basic ways to generate a Tree View using code, working with a simple hierarchy - TOT_GOLFSTREAM and its children, as seen below.
Let’s start with the Business Rule. We need to use a Dashboard Dataset rule, which will return the representation of our tree in table form. To generate it easily, we will have to create an object of type XFTreeItemCollection, itself storing a list of XFTreeItem objects representing each member.
After retrieving a list of Member objects that represent children members, we can loop over the list to generate equivalent XFTreeItem objects. The constructor for XFTreeItem accepts a number of parameters, which can be used to define the appearance of each member - text colour, images, etc.
Note that the constructor also accepts a list of children items - we will use that when dealing with the parent.
Now we can create our XFTreeItemCollection, and add to it a new XFTreeItem object representing the parent member; when creating that object, we pass the list of children, so they will appear as leaves of the parent node.
Finally we create a Dataset from the XFTreeItemCollection, using the .CreateDataSet utility method, and return the output to conclude our Dashboard DataSet generation.
We then set up a Data Adapter to execute the rule:
If we test it, we can see that the returned dataset consists of two Datatables, Items and Relationships. In order to generate a Tree View with code, we need both these tables - one to list the items, and one to determine their hierarchical relationship.
Technically speaking, you could generate these tables any way you wanted, but XFTreeItemCollection makes it easier. You can see this approach is already more complex than using the previous ones...
Next, let’s look at the Tree View Component that will display our tree.
Here we add the Data Adapter previously created, and a Bound Parameter to catch the result of user selection. We can then configure Tree View options that determine what the tree will look like.
- The Tree Type option can switch between Standard, Filtered or Searched, to provide additional capabilities in the widget.
- The Show Images option must be set to True if we want the Tree View to render icons next to our members; in our case we are returning the standard StatusGrayBall image.
This Component can then be attached to a Dashboard in the usual way.
Conclusions
In this post, we have seen three different ways to render a tree, concluding with a basic code-based solution that provides ultimate flexibility.
A final note: when dealing with metadata members, we would recommend to stick with the no-code solutions, since they are very simple to set up and will likely cover 99% of your requirements. One should reach for code-based options only when dealing with very complex situations, or with items that are not metadata members. Dashboard DataSets will be harder to maintain and harder to write - particularly when trying to generate deeper relationships. We will explore some of these advanced uses in future posts, but they are not for the faint of heart!
