BIRT Report Development [message #542431] |
Thu, 24 June 2010 19:26 |
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] |
Fri, 25 June 2010 00:49 |
Miles Parker Messages: 1341 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
|
|
|
|
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.05619 seconds