WSO2 Analytics Dashboard serves as a common place to visualize analytical data that comes from both realtime(CEP) and batch(BAM) datasources. Goal of this dashboard is to create a dashboard and add visualizations to it with less effort.
Below describes the concepts,components and internals related to Analytics Dashboard. Dashboard, Widget and DataView There are three major concepts associated with Analytics Dashboard. *Dashboard* is a container for Widgets and there can be many widgets inside a Dashboard. *Widget* is the smallest unit of visualization. A widget holds a visualization such as bar chart,line chart etc. A given widget can exist in multiple Dashboards. *DataView* is an abstraction that specifies how widget should access data at the runtime. Simply put, DataView acts as a datasource for widgets. In the design time, widget can specify which DataView it is going to be bound at runtime. DataView resembles a materialised view in traditional RDBMS domain. A DataView can be created using a BAM's Analytics table or CEP event stream definition. Let's refer them as Datasources. There can be many DataViews created using a single Datasource. Upon creation, users specify which data fields(columns) should exist in a DataView and filter conditions applied against the datasource. Once a DataView has been created, users would generate a Widget and attach it to the DataView. Goal of this approach is to provide multiple representations for a single dataset. For instance, a dataset that is having region wise sales information can be represented using a bar chart, pie chart, area chart and a line chart. So a DataView can be considered as a self contained package that bundles metadata about datasource + collection of widgets that visualize the underlying dataset. Dashboard Components Analytics Dashboard application consists of following components. 1. *Widget renderer * Renders the widgets in a particluar dashboard 2. *Widget Generation Wizard * Provides a wizard based approach to generate a Widget and add it to a DataView. 3. *DataView Management UI * Performs CRUD operations on DataViews. 4. *BindingSource * Manages the runtime data binding for widgets in a pub/sub way. Basically this listens/polls the backend and updates the widgets in a Dashboard. This is a client side Javascript library. Main User Stories Following are the main activities that a new user would follow to add a Widget to a Dashboard. 1. Login to Analytics Dashboard 2. Create a new Dashboard. 3. Create a new DataView. 4. Generate a new Widget and add it to the DataView. Repeat this untill user adds desired number of charts to the DataView created above. 5. Select the prefered widgets that should go into the Dashboard from the DataView created above. Mock screens for the above steps are attached below. Run time data binding - All widgets in a given Dashboard register themselves with the *BindingSource* which is globally available to all dashboards. This happens when dashboard is displayed. - Widget registers with BindingSource by providing widgetId and the DataView name . - BindingSource internally maintains a subscriber list which is keyed by DataView name. That will look like following. DataView1 => wiget1,widget2 DataView2 => widget3, widget4,widget1 - There are two types of data providers that push data into BindingSource. - *PollingDataProvider* polls a remote endpoint while *PushDataProvider* listens for incoming data such as Websockets. Upon data arrival, both providers push received data into the BindingSource so that it will inspect the DataView that data comes from and call update() method of all the widgets subscribed to that DataView. - For batch datasources, there'll be REST based endpoint for data access. It'll be having an operation called 'getDataForDataView(dataView)' which will return a JSON response. PollingDataProviders periodically poll this endpoint to get data for a given DataView. Response data will be pushed to the BindingSource so that all widgets subscribed to that DataView will get updated. Artifact storage location and storage formats Dashboard and DataView has their own JSON formats. Please refer to the attached JSON files accordingly. Those structures will be stored in the Governance registry as JSON strings. Widget Visualization All visualizations in widgets are rendered using *igviz.js *library which is written on top of d3.js. Plese refer mail thread [1] for more information about igviz.js. Currently igviz supports chart types including bar,line, area, stacked bar, stacked area, map and bar chart with drill down capability. Extensibility/Customization There will be a clientside Javascript API available for the developers who intend to create custom widgets. They will bypass the DataView implementation and directly talk to the Analytics data service or a websocket endpoint exposed by CEP. Any thoughts/suggestions are highly appreciated. [1] RFC: Building a Generic Configurable UI Gadget for Analytics Regards, Dunith Dhanushka, Senior Software Engineer - BAM, WSO2 Inc, Mobile - +94 71 8615744 Blog - dunithd.wordpress.com <http://blog.dunith.com> Twitter - @dunithd <http://twitter.com/dunithd> Analytics_Dashboard_Mockups <https://docs.google.com/a/wso2.com/folderview?id=0B_cumaqOYEgufllVUThFUzJLZlR4Z2hrZW5ueUJmd1o4ZktzRzdGRUtONlVrZHdHVUU3OXM&usp=drive_web>
dashboard.json
Description: application/json
dataview.json
Description: application/json
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
