|Report data binding design patterns [message #5704]
||Wed, 06 December 2006 21:06
| Sheldon Lee-Loy
Registered: July 2009
I opened this thread to capture some of the data binding design|
patterns people have observed integrating with a reporting
infrastructure such as BIRT.
I view reporting in the context of Cosmos as follows:
Organize a complex data structure into simpler views to allow users to
visualize trends in the data.
This is my initial limited assumption to start thinking about the
necessary data layer APIs that the data reporting components requires.
Assuming BIRT is the reporting engine that will be consumed, report
design template will be created for each of these "simple views".
Ultimately these report design templates are bound to datasets which
are flatten table like structures with key and value pairs. This is
one of the reasons why SQL queries can be easily created for BIRT
As a result the data layer APIs must transform a complex data
structure to a flatten table like structure. The data layer apis
should also provide the following data manipulations to help organize
the data in reports.
- data filtering - ability to show certain data that meet a specific
criteria (e.g. create a report to show hosts available in a specific
- data grouping - organize the data based on a grouping criteria (e.g.
create a report that shows available application grouped by host)
- data sorting - provide apis to sort the data (e.g. create a report
that shows the top 10 cpu usage computers)
- data counts - provide apis to count a set of data that meets a
certain criteria(e.g. display a bar chart that show total # of
applications running per host)
- apis should be locale dependant. Time formats or strings may need
to go through some locale specific transformation before presenting
the information in a report.
An ODA would be created to surface these apis to the report template
Powered by FUDForum
. Page generated in 0.01568 seconds