Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » AMP » BIRT Report Development
BIRT Report Development [message #542431] Thu, 24 June 2010 15:26 Go to next message
Tony Kennedy is currently offline Tony Kennedy
Messages: 17
Registered: June 2010
Junior Member
I have been asked to produce some BIRT reports to support the communication of results from some proof of concept modeling based on the ASPIN economic model, I note that you have a requirement for report development, has this been documented anywhere? or are there any ideas floating around that may make my efforts generally useful.

So far two mechanisms have been discussed internally: a simple reporting attachment to a function which creates a simple, maybe simplistic report of the given data set based on a collection of fixed templates to a specific media, PDF DITA Docbook etc. The second approach is two stage; first a collection of functions (snapshot filter etc.) is used to prepare the data for the report; this stage being performed by the MetaABM editor, on completion the BIRT template editor is invoked to design and edit the presentation of the data, the MetaABM editor providing the prepossessing of the data, the report template editor defining how the data will be shown, both contained in the AMP IDE producing a seamless application. The first concept as the advantage of simplicity and requires no knowledge of BIRT, the second released the full potential of the BIRT system and any future developments
Re: BIRT Report Development [message #542472 is a reply to message #542431] Thu, 24 June 2010 20:49 Go to previous messageGo to next message
Miles Parker is currently offline Miles Parker
Messages: 1338
Registered: July 2009
Senior Member
Kennedy wrote on Thu, 24 June 2010 15:26
I have been asked to produce some BIRT reports to support the communication of results from some proof of concept modeling based on the ASPIN economic model, I note that you have a requirement for report development, has this been documented anywhere? or are there any ideas floating around that may make my efforts generally useful.


First I'm assuming you know about the export to adata feature? That's a gap in the documentation but it creates an ecore .adata file.

Quote:
So far two mechanisms have been discussed internally: a simple reporting attachment to a function which creates a simple, maybe simplistic report of the given data set based on a collection of fixed templates to a specific media, PDF DITA Docbook etc. The second approach is two stage; first a collection of functions (snapshot filter etc.) is used to prepare the data for the report; this stage being performed by the MetaABM editor, on completion the BIRT template editor is invoked to design and edit the presentation of the data, the MetaABM editor providing the prepossessing of the data, the report template editor defining how the data will be shown, both contained in the AMP IDE producing a seamless application. The first concept as the advantage of simplicity and requires no knowledge of BIRT, the second released the full potential of the BIRT system and any future developments


That second approach sounds really cool! The first one is one that I think I might try myself just because it does an endrun around BIRT complexity. After all, XPand templates are super efficient at processing data. You could even add some tools to the .adata editor to allow users to select say flattened selections of the data.

But the intermediate approach is what I've been working on mostly. I haven't had enough success at this approach to have a good enough practice to document! But the basic idea here is simply to use the data as is along with a DTP driver. The real problem with this approach is that believe it or not there really isn't a good driver for ecore models despite a couple of strong efforts.

I first tried just using the XML drivers using the adata XMI as the schema just to exercise the adata model. This worked but the metadata is only for generic adata models -- what you really want to be able to do is get the associated .metaabm data such as attribute labels, etc..

Then I tried the ecore drivers. The original Ecore driver worked well but the representation of the data was still pretty indirect -- you could get the info from the metaabm model but that required doing manual data-source mapping for each new model.

The newer driver was really nice, you actually had access to the entire ecore data model and that made it much easier to do ocl based queries. But there were significant technical issues that I couldn't get around. Part of the issue has to do with BIRT caching issues -- AFAICT it seems that a lot of the BIRT data integration stuff is designed with web style access envisioned and there are issues with dealing with EMF objects..see:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=132958

In all of these the issue is to provide end-users / model explorers with easy to grok methods for creating reports. You and I can create them with the tools at hand but its a PITA and not something that you could expect a general user to figure out.

So my current thinking is that what would actually be really cool is to either create a custom adata data provider that could give users high level access to the metaabm meta-data or create templates that already had all of the data mappings. Probably the latter would be easiest but that would mean living with the issues above.

Or even simply create complete reports based on a cusotm interface. That's not as crazy s it sounds as the dimensions of data you'd want form an AMP model is not that extensive. I'd thought even of say taking something like the chart customizer and allowing people to get a data set form that.

Anyway, a lot of possibilities here. It would be really great to have more data handling capabilities available native from AMP! If you see any low-hanging fruit that it would be helpful to have to support an implementation for or if you want to get involved in AMP proper let me know.

cheers,

Miles
Re: BIRT Report Development [message #542499 is a reply to message #542472] Fri, 25 June 2010 02:15 Go to previous messageGo to next message
Tony Kennedy is currently offline Tony Kennedy
Messages: 17
Registered: June 2010
Junior Member
OK I will carry on with the second approach and leave you with the first and report back when progress is made or hanging fruit discovered
Re: BIRT Report Development [message #542737 is a reply to message #542499] Fri, 25 June 2010 14:29 Go to previous messageGo to next message
Miles Parker is currently offline Miles Parker
Messages: 1338
Registered: July 2009
Senior Member
Kennedy wrote on Fri, 25 June 2010 02:15
OK I will carry on with the second approach and leave you with the first and report back when progress is made or hanging fruit discovered


Cool. And of course feel free to drop patches / feature requests into bugzilla. I didn't mean to imply btw that I'm actually planning to do anything on option 1 in the near term so that might be an avenue that you would still find useful to explore.

One other variation would be to do some kind of M2M thing from AMP -> BIRT. Unfortuntaly, BIRT is not an ecore model, its just XML schema...so you could either do a transform to XML for templates / reports, or transform to XML and then export from that -- MoDisco might provide some tools for that I'm not sure. But the BIRT *Chart* API is all EMF so that would be pretty straightforward. The nice thing about that is that you would get charts and so on that you could use in Dynamic sharting as well.

BTW< have a look at the IDataProvider in o.e.a.agf.chart -- its pretty simple right now, but my idea here is to provide a generic (not even AMF specific) API for dynamic data. Yet another possibility would be to provide some kind of interface to the output of such a provider. That would be cool because it could be very generic yet still provide labels for output columns.
Re: BIRT Report Development [message #542785 is a reply to message #542737] Fri, 25 June 2010 23:25 Go to previous messageGo to next message
Tony Kennedy is currently offline Tony Kennedy
Messages: 17
Registered: June 2010
Junior Member
I was joking, I'm sure you have more than enough to do dealing with Eclipse project management, and of course the function approach is the first step on the road to complete BIRT integration. Anyway thanks for the information; in the coming week I will forward my project plan for the reporting exercise and some tech info I will put that on the dev site
Re: BIRT Report Development [message #542789 is a reply to message #542431] Sat, 26 June 2010 00:16 Go to previous messageGo to next message
Miles Parker is currently offline Miles Parker
Messages: 1338
Registered: July 2009
Senior Member
Right. Wink I've created a Wiki page to put this stuff:

http://wiki.eclipse.org/AMP/Reporting

Or set it up however you want. (Wiki is open to anyone with bugzilla access.) We can discuss development details on dev list if you'd like.
Re: BIRT Report Development [message #559151 is a reply to message #542789] Wed, 15 September 2010 15:08 Go to previous messageGo to next message
Tony Kennedy is currently offline Tony Kennedy
Messages: 17
Registered: June 2010
Junior Member
Hi Miles

Some Progress on the reporting front since my original thoughts a PoC has been produced and incorporated in various modelling projects; it would seem my original thoughts were woefully inadequate. We now have a three way / four way split in reporting:

The first an agent reporting function much as discussed in earlier posts

Second a progress error reporting function embedded in the experiment control function which in our case is based
mylin, more on this in another thread.

Third an enhanced reporting function based on the first but with text mining functionality.

Fourth a post simulation reporting facility which can cope with the large output volume of some of the longer simulations (TB simulation simplified is 200 days) and analyze and visualize the post-simulation output of multiple ABM's with an enhanced text mining functionality.

If you like I can start (or get some one to start using the wiki ) with some docs and examples as a straw-man to see if any further ideas spring up particularly in your GIS arena not yet covered by ourselves.
Re: BIRT Report Development [message #559443 is a reply to message #559151] Thu, 16 September 2010 11:45 Go to previous message
Miles Parker is currently offline Miles Parker
Messages: 1338
Registered: July 2009
Senior Member
Hi Tony,

please see responses below..

Tony Kennedy wrote on Wed, 15 September 2010 15:08
The first an agent reporting function much as discussed in earlier posts


Great, and Smile would be a most welcome contribution..

Quote:
Second a progress error reporting function embedded in the experiment control function which in our case is based
mylin, more on this in another thread.


Mylyn integration.. that would be a truly important differentiator.

Quote:
Third an enhanced reporting function based on the first but with text mining functionality.

Fourth a post simulation reporting facility which can cope with the large output volume of some of the longer simulations (TB simulation simplified is 200 days) and analyze and visualize the post-simulation output of multiple ABM's with an enhanced text mining functionality.


I'm interested to hear more about use cases for how the Text Mining functionality is used vs. configuring the output generated in the first place.

Quote:
If you like I can start (or get some one to start using the wiki ) with some docs and examples as a straw-man to see if any further ideas spring up particularly in your GIS arena not yet covered by ourselves.


Yes, as with GIS I think that would be really helpful. One thing I'd really like to begin thinking about is a feature set for Indigo release train / 1.0.0 release. If we don't start thinking about this seriously now, the train will leave the station. So any requirements effort should definitely involve some kind of ranking and triage I'd think.

Also, I don't know if this goes without saying, but please do open bugzillas for these pieces of functionality. Its fine to do so for higer level / somewhat vague functionality as we can always fill that out with more specific bugs.

Please see https://bugs.eclipse.org/bugs/show_bug.cgi?id=318274 for a very relevant discussion on all of this.
Previous Topic:AMP is Unavailable
Next Topic:Model/Experiment Management For AMP
Goto Forum:
  


Current Time: Wed Apr 16 00:26:34 EDT 2014

Powered by FUDForum. Page generated in 0.11584 seconds