Browse Prior Art Database

Approach for data fetch optimization for busy dashboards.

IP.com Disclosure Number: IPCOM000232281D
Publication Date: 2013-Oct-30
Document File: 5 page(s) / 301K

Publishing Venue

The IP.com Prior Art Database

Abstract

This article discusses an approach for data fetch optimization for Busy Dashboards. Using this approach, implementers of busy dashboards can significantly reduce resources for data fetch (like database connections), leading to better performance and faster loading/reloading of widget data.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 48% of the total text.

Page 01 of 5

Approach for data fetch optimization for busy dashboards .

Background:

In management information systems, a dashboard is "An easy to read, often single page, real-time user interface, showing a graphical presentation of the current status (snapshot) and historical trends of an organization's Key Performance Indicators (KPIs) to enable instantaneous and informed decisions to be made at a glance." (source: Wikipedia)

Three main types of digital dashboards dominate the market today: stand alone software applications, web-browser based applications, and desktop applications. The approach discussed in this article can be applied to all types of dashboards.

For illustration, we are referring to a web-browser based dashboard (portal) which are usually created with smaller web widgets called portlets or dashlets. A portal/dashboard contains multiple portlets/dashlets.

Portlets are pluggable user interface software components that are managed and displayed in a web portal. Portlets produce fragments of markup code that are aggregated into the portal. Typically, following the desktop metaphor, a portal page is displayed as a collection of portlet windows, where each portlet window displays a portlet. Hence a portlet (or collection of portlets) resembles a web-based application that is hosted in a portal. Some examples of portlet applications are email, weather reports, discussion forums and news.

1


Page 02 of 5

Each portlet/dashlet is designed or can connect with different backend data sources (DS) and the data is rendered according to the user preference set on the portlet. The portlets can be arranged in the page as per the user preference and there is mechanism to connect/wire between portlets for mutual interaction.

A portal page with lot of portlets/widgets is called a "busy dashboard" for the discussion in this article.

Known limitations with design of busy dashboards :

1. Multiple portlets/UI widgets could be talking to the same data source in the backend. As shown in the example P1, P7 and P10 are all connecting with the same data source (DS2) probably through a web service or data fetch query.


2. This results in increased load on the bandwidth usage and inefficiency

3. This also causes performance issues and slow refresh of the portal/dashboard leading to poor user experience

4. Typically dashboards are created by end users via simple design techniques like drag and drop and hence it is difficult to foresee and optimize a page during portlet/widget development

In our proposed solution, we have 3 new components that provide policy based optimized fetch of data for a busy dashboard with multiple UI widgets/ portals.

The components are:

Data Source Analyzer (DSA)

2


Page 03 of 5

1. Responsible for intersecting the backend calls to the data sources from the portal and analyzing if there is a gain by using the data fetch optimizer.


2. DSA would identify portlets making requests to the same Data Source.

3. The DSA would analyze the cost...