Being able to create the dashboards the user want is the advanced use case. What about the simple use case of simple pre-defined dashboards?
In others words, like in the case of UES, we should have various "profiles" of users in here and cater for them all: lame:average:advanced:geek On Wed, Jul 17, 2013 at 4:06 PM, Shiroshica Kulatilake <[email protected]>wrote: > Hi All, > > The following are architectural notes that were made after having quick > chats with AmilaM and Nuwan regarding the dashboard effort for aPaaS. > > *1. Expectation of the aPaaS dashboards.* > - A user of aPaaS should be able to create dashboards for various > events that are created within aPaaS (i.e. within the application creation > process as well as the runtimes). These dashboards should be context > specific based on what the user wants to see. e.g CXO needs to see CXO > level dashboard whereas a PM needs to see a different type of a dashboard. > Once a user logs in to the dashboard creator (UES) gadgets can be selected > and datasources which have been predefined can be linked to these. A > dashboard can be created for a particular role type in a tenant - so if > another user who has the same role logs in, then he/she would see the same > dashboard. The driving force behind allowing the user to create dashboards > themselves is to reduce changes that may sometimes be conflicting amongst > separate clients. > > *2. BAM integration * > - There will be a BAM server which will be shared across the AF setup > plus the runtime environments. AF will publish event data into BAM through > a BAMPublisher which is a osgi bundle which AF depends on. > AF will simply send the data to the BAMPublisher and from thereon > BAMPublisher will push that data into BAM. All data will be published into > the super tenant's space. > > *3. UES integration* > - In UES we will provide pre-created data sources that can be selected via > a dropdown. These would be linked to the UES gadgets that can be selected. > - Since UES follows the normal platform multi-tenancy in place, we will > show dashboards based on a tenant and the role which that logged user > belongs to. This way once a dashboard has been created for a particular > role it will be shown to all users who have the same role. > > *4. Things that need to be finalized.* > - We have not finalized on which UES to use still. (i.e. seperate UES on > AF or the one with BAM) > - We also need to talk with the BAM folks to get details as to when they > will be integrating UES into BAM. > - There is still a grey area on a user seeing a dashboard for a role and > then being able to edit it thereby - right now it can be seen as a feature > but we need to address this soon as to whether that should be allowed or > not. (preferably via configuration) > - We also need to incorporate the logs into the dashboard. > > The top level diagram is shown below. > [image: Inline image 1] > The tasks for the above have been created in the milestone > plan<https://docs.google.com/a/wso2.com/spreadsheet/ccc?key=0Aq1ORUvnyMi6dGJNb0MtRlhBalJGTk9Ha2QzbWVnUUE#gid=5>and > the redmine issues have been created beneath version 1.1.0 under the > AppFactory > project. <https://redmine.wso2.com/projects/wso2-app-factory/roadmap> > > > Thoughts and suggestions are welcome. > > > Thank you, > Shiro > > -- > Shiroshica Kulatilake > > Architect, > WSO2, Inc. http://wso2.com/ > Phone: +94 776523867 > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Thanks, Samisa... Samisa Abeysinghe VP Engineering WSO2 Inc. http://wso2.com http://wso2.org
<<aPaaSDashboard.jpg>>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
