Hi Denuwanthi, Firstly, this was discussed a little earlier, and apologies for not updating the Redmine issue with this information. Now that you are working on this issue, please update it with this info.
The idea is that we will push all types of analytics into BAM and produce reports out of that. This is structurally similar to what's done in API Manager, but the gadgets and layouts are obviously different. Aruna et al built some of these UIs already. When this gets integrated into G-Reg, we need to focus on a few things. Firstly, some analytics do not make sense at service-level, but some do. If so, we need to find ways to display them depending on the level of granularity that we have chose. If its at project-level, we will probably hide the gadget or show blank information. If its at service-level, we will figure out the project to which it belongs and then populate the relevant project assets. But, the concept of service-level and project-level both need to be supported. And, some gadgets obviously, will get reused. For these kinds of gadgets, we will need to get them to display data on the level of granularity (i.e. service or project). So, as you might be wondering, we should be able to tell the gadgets (or the entire dashboard), what level to display (whether it is service or project) in addition to what to display. This is what we need to figure out. AFAIU, we can use the same dashboard but have two attributes to capture name of asset and type of asset (i.e. service or project). Another option is to use separate dashboards for service and project and use just the name attribute. This is something we need to decide. Having the same dashboard IMO will allow us to switch between services and projects without having to reload the dashboard, which is somewhat attractive to the end user. But, this might also need some help from the BAM end. Thanks, Senaka. On Fri, Aug 1, 2014 at 7:55 AM, Denuwanthi De Silva <[email protected]> wrote: > Hi Senaka et. al, > > I'm working on $subject. The corresponding Redmine link is at [1] > > *Current Implementation* > As for now, G-reg only support, moving from several lifecycle states > (Development, Testing. Production) for services. It supports validation of > each state via checklists. > > *New Feature* > Now, we plan to support a lifecycle state aware dashboards/view for > services. > That is, for each lifecycle state of a service, we plan to provide a > customized view corresponding to that state. > Ex: Details > > - Development state - The dashboard can show contributers, source > repository URLs, no of commits, highest committer, stats related to its > source control system etc > > > - Testing state - The dashboard can show jenkins builder test results, > etc. > > > - Production state - (have to decide on what stats to show) showing > run time request/response stats for the service is one option. > > > *Challenges* > But, if we are going to provide this in service level, for each service we > will have to provide these details. > > - So, where should we keep all those details (described above) ? > > > - Is it ideal to provide this state aware dashboards/views per service > or should we go to an approach like using the concept of 'project' > (discussed in Unified Governance Model) which will contain several services > & handle the lifecycle state aware details (described above), on 'project' > level? > > > Is there anything need to be added or removed from above? > > > [1] https://redmine.wso2.com/issues/3073 > > > Thanks, > -- > Denuwanthi De Silva > Software Engineer; > WSO2 Inc.; http://wso2.com, > Email: [email protected] > > > -- *[image: http://wso2.com] <http://wso2.com> Senaka Fernando* Software Architect; WSO2 Inc.; http://wso2.com * Member; Apache Software Foundation; http://apache.org <http://apache.org>E-mail: senaka AT wso2.com <http://wso2.com>**P: +1 408 754 7388; ext: 51736*; *M: +44 782 741 1966 Linked-In: http://linkedin.com/in/senakafernando <http://linkedin.com/in/senakafernando>*Lean . Enterprise . Middleware
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
