Having build a range of custom Dashboards, including custom tables, I want to pass on some of the knowledge obtained from this. In this first blog post (wuhuu) from a helicopter perspective with some core tips to think about when building dashboards in OneStream.
1. Study the MarketPlace apps
To get some knowledge on how OneStream builds Dashboards, install some of the MarketPlace apps and have a look at how OneStream have used parameters for global settings, dashboard layout structure, naming convention etc. As much as possible, use the same approach as OneStream do (steal with pride)
2. Make a plan
Jumping right into just dumping a lot of dashboard components in your solution will bite you in the behind. Renaming components and rearrange items have become easier in the OneStream development IDE, but building the dashboard on paper first, makes is much more easy to implement.
3. Parameters are King
Parameters are essential in Dashboard building, so get in depth with how they work and what kind of parameter to use. A Literal parameter and an Input Value parameter are very different in what they should be used for. Read the documentation and study how parameters are used in MarketPlace applications, especially around the use of Bound List parameters, and how the parameters are used in relation to CubeViews. Having control of your parameters and especially keeping a consistent naming, can make or break your day.
4. Think as a Web Developer
The technical architecture of how a OneStream application works is basically the same way a Web application works. This means you have a Client side (OneStream Windows Application) and a Server side (backend). In short, when a user request a dashboard to open:
- The backend server triggers to collect the data for the client (calling database, collecting dashboard structure etc)
- When the data-collection for the dashboard is ready, it is delivered to the client (through the network)
- The client application reads the data-collection received, and renders the client side, so the dashboard is presented to the user
- If the user then clicks on a button, this triggers a new request to the backend server. The request to the backend will contain changed parameter values
- Based on the request, the server once again collects data for the dashboard, and sends the information to the client.
If you want to do some custom logic in a Dashboard, it’s really beneficial to know how you can make use of the event handlers in a custom Dashboard Extender business rule
5. Study the OneStream API
Building Dashboards differs in complexity. Sometimes almost no custom logic through an Dashboard Extender file is required, and sometimes you build a lot of custom logic to handle the application/business logic. But no matter what, get to know the OneStream API. Read the documentation. For playing with the API create a new Extender Business Rule and use the “Execute Extender” button to execute a function. I have put together a little demonstration video (it will open in a separate window)