Just some thoughts:
Using UUID for references in Archi and in Jasper Report queries.
Is it possible/ preferable to add support for the use of UUID in Archi in the properties or another mechanism to reference to objects en view?
First an reference to UUID instead of a name is more robust and can be reused in Jasper Report for Linking purposes.
support for custom queries
Beside the existing queries for the Japser Report plugin is it preferable to add custom queries, so that I can retrieve detail information of one specific object?
At this moment a use a full scan to extract information of one specific object in my Jasper Report templates.
Share me you ideas
Hi Bart,
I have to confess that I'm a bit rusty on the Jasper Archi code at the moment. :-\ I wonder if you could provide a use case / example?
Phil
Hi,
Well, I think it should be rewritten :-(
For some reasons, I should develop a plugin to export model in a SQLite db. I guess this could be used to create a new report plugin which could just run jasperreport over this db. We could then do whatever we want using sql queries...
JB
First. A specific case for my is that in a report I an internal reference to a view that describe or work out a specific building block in more detail.
At this moment I use the technique of matching a name, but that is a buggy one. By the use of a reference I can place an internal reference as a property.
With a SQLite solution you have the opportunity to query the model, but you haven't to possibility to create a (internal) reference to another view based on a stable solution.
My ultimate goal is to create/generate deliverables with Archi that are TOGAF compliant, that are based on artifacts (views), including a facility to create catalogs, matrices and diagrams. I know that ArchiMate is defines as a diagram language, but sometimes it is better to hide the diagram and only show the documentation including properties, for example like principles.
Where I thinking of is to expand a view existing queries/procedures in Archi.
- Expand the existing queries so that they also give a objectid back
- Create one query give me the details of that specific object with that objectid.
I agree also that Jasper Report hard to manage and I am also busy to find another ways to generate documentation, for example based on Latex. But it is hard to find a good solution that is capable to divide the content form layout.
If you wish I can try to program that in Archi if you agree.
Hi Bart,
Quote from: Bart Ratgers on September 08, 2014, 09:15:22 AM
First. A specific case for my is that in a report I an internal reference to a view that describe or work out a specific building block in more detail.
At this moment I use the technique of matching a name, but that is a buggy one. By the use of a reference I can place an internal reference as a property.
I'm not sure to catch you, do you mean you want to be able to create a property whose value is another object (thus its internal ID when you query it) ?
Quote
With a SQLite solution you have the opportunity to query the model, but you haven't to possibility to create a (internal) reference to another view based on a stable solution.
If previous point well understood, I agree that this is only part of the solution but what you want requires some changes in GUI. As a temporary solution, a property named UUID could be created on objects (manually created) and you could use this property value as a foreign key in other objects properties. An SQL based report should be able to manage this.
Quote
My ultimate goal is to create/generate deliverables with Archi that are TOGAF compliant, that are based on artifacts (views), including a facility to create catalogs, matrices and diagrams. I know that ArchiMate is defines as a diagram language, but sometimes it is better to hide the diagram and only show the documentation including properties, for example like principles.
I share this goal too ;-) That's why I think reports should be based on SQL queries. I think it requires some work, but it's worth the money.
Quote
Where I thinking of is to expand a view existing queries/procedures in Archi.
- Expand the existing queries so that they also give a objectid back
- Create one query give me the details of that specific object with that objectid.
This seems a good start and could help building some new reports, but most methods are already providing a pointer to objects that you can then query, so I guess you have something specific in mind...
Quote
I agree also that Jasper Report hard to manage and I am also busy to find another ways to generate documentation, for example based on Latex. But it is hard to find a good solution that is capable to divide the content form layout.
I don't really find jasper report hard to manage (or not harder than other similar tools). The real pain is the way data is gathered (java methods instead of SQL queries).
Quote
If you wish I can try to program that in Archi if you agree.
Every one can contribute, so you're welcome ;-)
Regards,
JB
Quote from: Bart Ratgers on September 05, 2014, 12:56:24 PM
Just some thoughts:
Using UUID for references in Archi and in Jasper Report queries.
Is it possible/ preferable to add support for the use of UUID in Archi in the properties or another mechanism to reference to objects en view?
First an reference to UUID instead of a name is more robust and can be reused in Jasper Report for Linking purposes.
If I understand you correctly I can add "id" as a field type, which can be declared as a string in the report template liek this:
<field name="id" class="java.lang.String"/>And used like this:
<textFieldExpression>$F{id}</textFieldExpression>Is this what you mean?
Yes, that's what I mean.
But that is step one.
Step two is to add new query type: getElement(id)With that element i must be able to retrieve the details of an object and with an additional existing query the properties. But how can we integrate the possibility of a object id into the GUI?
- The easier one is to add the object id in a field of the property window of that object, but I'm not sure if that's fit in the design philosophy of Archi.
Off the top of my head, I think you can query this:
getElement().getId();
Or do you need to find an element from its id from the model?
ArchimateModelDataSource#getElement(id)
?
Quote
With a SQLite solution you have the opportunity to query the model, but you haven't to possibility to create a (internal) reference to another view based on a stable solution.
Quote
If previous point well understood, I agree that this is only part of the solution but what you want requires some changes in GUI. As a temporary solution, a property named UUID could be created on objects (manually created) and you could use this property value as a foreign key in other objects properties. An SQL based report should be able to manage this.
That is an solution, but that requires a lot of manual administration, while the object id exist in Archi. Step one is to show these one in the GUI. STep two is to use these one in a query, like the proposed solution of Phil.
Quote
My ultimate goal is to create/generate deliverables with Archi that are TOGAF compliant, that are based on artifacts (views), including a facility to create catalogs, matrices and diagrams. I know that ArchiMate is defines as a diagram language, but sometimes it is better to hide the diagram and only show the documentation including properties, for example like principles.
QuoteI share this goal too ;-) That's why I think reports should be based on SQL queries. I think it requires some work, but it's worth the money.
Yes, a SQL database gives you more flexibility. But I think we must think about the opportunities to integrate some report processing elements in the GUI. One of the things I thinking of is to create a clickable SVG diagram or create internal reference to other objects.
One of the philosophy we can adopt is the way HTML is presented. For example: In HTML you can specify the way an object is represented on screen but also on print. Maybe we can add beside appearance tab also a report tab (An older idea I posted before on the previous forum).
Quote
Where I thinking of is to expand a view existing queries/procedures in Archi.
- Expand the existing queries so that they also give a objectid back
- Create one query give me the details of that specific object with that objectid.
QuoteThis seems a good start and could help building some new reports, but most methods are already providing a pointer to objects that you can then query, so I guess you have something specific in mind...
That's correct. At this moment I use this construction to create internal (clickable) references (_Link).
Quote
I agree also that Jasper Report hard to manage and I am also busy to find another ways to generate documentation, for example based on Latex. But it is hard to find a good solution that is capable to divide the content form layout.
QuoteI don't really find jasper report hard to manage (or not harder than other similar tools). The real pain is the way data is gathered (java methods instead of SQL queries).
The hard part is if you create/design a report template, you get sometimes strange error messages in case of a typo or a wrong syntax. Another thing is that the toolset to manipulate data is limited.
Quote
If you wish I can try to program that in Archi if you agree.
Every one can contribute, so you're welcome ;-)
Regards,
JB
Regards,
Bart
Quote from: Phil Beauvoir on September 08, 2014, 22:01:34 PM
Off the top of my head, I think you can query this:
getElement().getId();
Or do you need to find an element from its id from the model?
ArchimateModelDataSource#getElement(id)
?
I Obtain for the last one:
ArchimateModelDataSource#getElement(id)[/size]
OK, not too hard. I added this to ArchimateModelDataSource:
public Object getElementByID(String id)
Can be used in a report like this:
((com.archimatetool.jasperreports.data.ArchimateModelDataSource)$P{REPORT_DATA_SOURCE}).getElementByID("1234")
Hi guys,
As it seems we have Bart really motivated to enhance reporting in Archi (and I really support that), I think that we (and especially you Bart) should start writing specifications for this on the wiki (https://github.com/Phillipus/archi/wiki).
May I suggest to do the following:
- Define the target. My understanding is "support TOGAF artifacts".
- Assess Jasper Report for this. My feeling is that it can be used (but I may be wrong) so I assume we continue with it.
- Sketch how this seems to be doable with Jasper Report.
- List missing features (java methods to query model).
- Does it take longer to implement these features or to rewrite report plugin ?
- Do the implementation part.
- Do the reporting part in Jasper Report.
- Open a bottle of Champagne
- There's no 9. (@Phil: I told you I liked it ;D)
Still someone reading this message ?
JB
For testing purposes only
I've just found this (http://www.sqlite.org/cvstrac/wiki?p=ImportingFiles). There seems to be some mean to create vitual tables in SQLite and map them to CSV file.
My idea (absolutly not tested so if you try before me and your PC burns that's not my fault) is to create an SQLite DB with only virtual tables inside mapped on CSV files produced by the new CSV export plugin. This may allow to try some enhanced reports.
And don't blame me if it doesn't work.
I like the approach. Should i describe the case under Report in https://github.com/Phillipus/archi/wiki/Feature-requests-and-roadmap or should I create a new page?
And can I also add the ideas describe in: http://forum.archimatetool.com/index.php?topic=23.0 of should i address this in a separate page?
On the other hand we can start with #8 and do the rest later.
@Bart,
Just create a new wiki page and add a link from https://github.com/Phillipus/archi/wiki/Feature-requests-and-roadmap to this new page on the "Reporting" section.
For the moment let's put all reporting stuff in only one wiki page, we'll see later if we split it or not.
I agree about starting with #8.
JB
Hi,
Postit note: we should also add "Folder" in list of view related attributes that java methods return. This would allow us to generate reports on a (sub)folder basis.
JB
Quote from: Jean-Baptiste Sarrodie on September 09, 2014, 12:36:59 PM
For testing purposes only
I've just found this (http://www.sqlite.org/cvstrac/wiki?p=ImportingFiles). There seems to be some mean to create vitual tables in SQLite and map them to CSV file.
My idea (absolutly not tested so if you try before me and your PC burns that's not my fault) is to create an SQLite DB with only virtual tables inside mapped on CSV files produced by the new CSV export plugin. This may allow to try some enhanced reports.
And don't blame me if it doesn't work.
I just found similar thing for PostgreSQL (http://www.postgresql.org/docs/current/interactive/file-fdw.html)...
Hello JB,
I started a new page that the describe the context and a first set of requirements in the wiki on: https://github.com/Phillipus/archi/wiki/Generate-Delivarbles-(Reporting)-Requirements.
It's just a beginning.