Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
cancel
Showing results for 
Search instead for 
Did you mean: 

Sub: To explore limits/boudaries of Dashboard Designer with respect to file size, performance and content volumes

Dashboard designer as a tool is very efficient in delivering dashboard functionalities with a lower lead time as compared to similar solution on a Java application settings or a Design Studio.

However this comes with certain limitation in flexibility of the tool. This document deals with helping users to overcome rigidity in the tool and deliver world class dashboards.

Generally it is observed that when developers work on dashboard designer tool, there is more focus on visual appearance and in doing so, the process of gaining knowledge on tool performance and limitations takes a lower priority. However, problems do crop up when we cross these limits and to make it worse there is very less content available on knowledge sharing portals, regarding finer aspects of dashboard limitations.

To list out few of the known recommendations:

1) Filters should be limited to 1000 rows maximum.

2) Try to keep dashboard on higher levels, and for finer details provide links to reports.

3) Following maximum 2000 records limit will not give performance issues.

4) Too complex navigation can lead to increase in swf size and give performance issues. You can use some hard coding if situation permits to reduce runtime calculations load.

5) The xlf size should not exceed 3MB limit as a thumb rule.

Room where developer can play around the above design limits and simultaneously deliver high performance dashboards.

1) While the 3MB limit exists for dashboard .xlf file, however you can exceed the limits if the file does not generate a large swf. (You can increase hard coding to reduce runtime calculation loads in swf)

2) Design data flow in such a way that at a time only max 2000 rows of data is fetched in the system, for extra data make it query in runtime.

3) Use BIWS for better performance. Have data staged in BO instances.

4) Split use cases and divide dashboard into proportions to optimize data volume in runtime.

5) Design a dashboard GUI which has multiple swf running in background, but for user the GUI is camouflaged and he will experience the whole thing as one dashboard. (With my experience in this solution, i can say for sure that lot of thinking would be required to manage the navigation and its timings withing swfs, as you may land up in a spiral of opening one swf into another and further another into the previous.)

1 Comment
Labels in this area