Updated Report template

Started by Bart Ratgers, September 08, 2014, 21:25:47 PM

Previous topic - Next topic

Bart Ratgers

Hello,


I like to share an updated version of the Report template. This is the last version that is based on the initial templates that are offered a long time with Archi. The next version is more modular and extendable so can easily additional properties end report types.


What is new:

       
  • The possibility to hide ArchiMate concept types from a specific view. 
  • The possibility to add a Bibliography  (Just basic).
  • Add a description in a front page for a project view
  • And small changes
If you have any suggestions or comment, please drop a mail or a reply.


Friendly greets, Bart

Phil Beauvoir

Thanks, Bart. I'll definitely check these out!

Phil
If you value and use Archi, please consider making a donation!
Ask your ArchiMate related questions to the ArchiMate Community's Discussion Board.

Jean-Baptiste Sarrodie

#2
Hi Bart,

I will have a look soon.

FYI, I used your idea to show only views related to a project to create a new version of the "Customizable Report". I change it a little bit to:

  • Rename "Project" concept to "Tag" concept as it is more generic. The associated property name is "Report:View:Tag" (in line with convention already used)
  • Create a virtual tag "All": if a view has this tag assigned, it will be show on all reports, whichever tag is selected.

@Phil, I will commit it tomorrow, I think it should be updated for Archi 3 as it helps really a lot: I'm now able to work on only one big model and generate report based on either "Application" context or "Project" context (I double tag each view with application name and project code).

JB
If you value and use Archi, please consider making a donation!
Ask your ArchiMate related questions to the ArchiMate Community's Discussion Board.

Phil Beauvoir

Quote from: Jean-Baptiste Sarrodie on September 08, 2014, 21:36:10 PM
@Phil, I will commit it tomorrow, I think it should be updated for Archi 3 as it helps really a lot: I'm now able to work on only one big model and generate report based on either "Application" context or "Project" context (I double tag each view with application name and project code.

Nice.  :)
If you value and use Archi, please consider making a donation!
Ask your ArchiMate related questions to the ArchiMate Community's Discussion Board.

Jean-Baptiste Sarrodie

@Bart,

I will certainly "copy" your idea about icons, but I'm still trying to figure how to do it in a more generic way. What I'd like to do is to define a mapping between property names and icons. This mapping could be stored in a specific view or something like that. The same could be done to store "report profiles" (predefined set of report sections).

I think we should be able to do really powerfull (and customizable) reports.

One typical thing I'd like to do is to create Application Interaction matrix, but this requires to extract Flows relationships between some application components... The only idea I have to do this (untested) is to query the whole model to get all relationships and then compare source and target to application components selected in a view. That's not an easy thing without SQL queries ;-)

JB
If you value and use Archi, please consider making a donation!
Ask your ArchiMate related questions to the ArchiMate Community's Discussion Board.

Phil Beauvoir

Quote from: Jean-Baptiste Sarrodie on September 08, 2014, 21:51:10 PM
One typical thing I'd like to do is to create Application Interaction matrix, but this requires to extract Flows relationships between some application components... The only idea I have to do this (untested) is to query the whole model to get all relationships and then compare source and target to application components selected in a view. That's not an easy thing without SQL queries ;-)

Perhaps easy to do with Neo4j?
If you value and use Archi, please consider making a donation!
Ask your ArchiMate related questions to the ArchiMate Community's Discussion Board.

Bart Ratgers

Quote from: Jean-Baptiste Sarrodie on September 08, 2014, 21:51:10 PM
One typical thing I'd like to do is to create Application Interaction matrix, but this requires to extract Flows relationships between some application components... The only idea I have to do this (untested) is to query the whole model to get all relationships and then compare source and target to application components selected in a view. That's not an easy thing without SQL queries ;-)

JB


Hello JB,


I agree with you. At this moment I looking to redesign the report templates, one of the goals is to use a common solution for displaying Icons, but also a more generic solution to modify a specific view.


Jean-Baptiste Sarrodie

Hi Bart,

Did you have a look at the "Customizable Report" ? It may be a best starting point...

You'll find attached the latest version with tag support.

I wonder if we could agree on some naming convention for properties... In my case, I use Report:* for report directives, this means that I hide them everywhere using a simple pattern match. I then use Report:View:* for view specific directives.

Regarding icones, I imagined some thing like this: to assign a specific icon (e.g. computer.png) to a property (e.g. HardwareType), we could create a property "Report:Property:HardwareType#Icon" with value "computer.png".

The idea would be to look for  "Report:Property:*", the "*" would be the real name of a user defined property with a "#attribute" appended ("attribute" being the property attribute to set). The property value would contain some hit on how to display it. We could easily extend to define icons, show/hide property name, insert bullet point...

JB
If you value and use Archi, please consider making a donation!
Ask your ArchiMate related questions to the ArchiMate Community's Discussion Board.

Bart Ratgers

Hello JB,


I saw in previous version your approach to customized reporting and was considered to adopt these approach.
I like the OO approach which defines classes. And I agree that this approach ease the pain of decision in reporting.


The main reason to use the _<tag> feature is the ease to use by the user. The class notification can cause in large and unclear properties names.
How do you see the usability from user perspective of the class approach? Is a an way to shorten the class names and present them in a more attractive way.


I think it is good to use your template as a starting point and harmonize the concepts of properties.








Jean-Baptiste Sarrodie

Quote
The main reason to use the _<tag> feature is the ease to use by the user. The class notification can cause in large and unclear properties names.
How do you see the usability from user perspective of the class approach? Is a an way to shorten the class names and present them in a more attractive way.

I agree that it should be easy to use by end-users, but as Archi remember all properties defined and shows them in a menu I find it easy to select them (and not type them). The OO approach makes them easily accessible (as they are listed in alphabetical order).

That being said, I know no other people using it, so I'm open to remarks from the first user :-)

I think the question is, who will use these feature and how. I think (Enterprise) Architects can easily understand the concept and use it, so long property name should not be an issue (we can make them a little bit shorter using "Rtp" instead of "Report" and "Vw" instead of "Views", but is "Rpt:Vw:Hide" as readable as "Report:View:Hide" ?).

Another key thing in my opinion is to not enforce use of specific property name for real information associated with elements. If properties are created through CSV import from a CMDB, we should still be able to define the way they should appear in a report, hence my idea to create "Report:Property:PropertyName#Attribute" property, really long but self explanatory and defined only once in a model (and if one create a lot of model, he can still automate through templates).
If you value and use Archi, please consider making a donation!
Ask your ArchiMate related questions to the ArchiMate Community's Discussion Board.

Bart Ratgers

Hello JB,

Sorry for the late response, I had a very busy week.  I agree that properties must be self explained and I can follow in your idea to use  "Report:Property:PropertyName#Attribute" Attributes. 

But my main concern is at this moment the use of Properties in Archi. ATh this moment is is hard to find the correct properties in Archi in case of a lot of properties(types) are used in the model.  If the prefix are also looking the same then the usability is less good. The usability can be improved by a autocomplete feature in search and to separate the building block specific properties and the 'Report' aware properties. This make the properties more manageable then in the current situation.

With this in mind is that we can start with a new report strategy based on common approved requirements, described in the wiki.

P.S. Another thing I like to see is an advanced editor or at least an multiline editor for properties.

Phil Beauvoir

Quote from: Bart Ratgers on September 14, 2014, 21:13:49 PM
P.S. Another thing I like to see is an advanced editor or at least an multiline editor for properties.

In a version after 3.0, we need to ensure properties adhere to data types - string, boolean, number, date, currency and so on. String can be multiline as well.

Phil
If you value and use Archi, please consider making a donation!
Ask your ArchiMate related questions to the ArchiMate Community's Discussion Board.

Bart Ratgers

Quote from: Phil Beauvoir on September 14, 2014, 21:24:18 PM
In a version after 3.0, we need to ensure properties adhere to data types - string, boolean, number, date, currency and so on. String can be multiline as well.


Should we start with a separate page for properties in the wiki?


plecotus

Hello Bart,

I have an error executing your Jasper template. (see attach)
Could I have a solution?

Thanks in advanced

Rafa





bdendulk

Hi Bart (Ratgers),

I have the same error when using the report template in a different workplace environment than my own workplace. Could it be a problem with network shares (UNC names versus windows explorer names) since the problem arises when the report is used when it is located on a network share)?

Kind regards,

Bart den Dulk