Sparx Systems Forum

Enterprise Architect => General Board => Topic started by: robinch on August 29, 2013, 01:22:58 am

Title: RTF reporting ignores << Document >> artifacts
Post by: robinch on August 29, 2013, 01:22:58 am

Hi,

With Enterprise Architect 10.0.1008 Ultimate Edition, I am trying to generate RTF reports which include RTF fragments from << Document >> artifacts associated with packages.

According to the documentation, the RTF template needs to include a "linked document" section to pull the RTF fragment from either the package's "Linked Document" or from << Document >> artifacts associated with the package. While an RTF fragment defined using the "Linked Document" method appears in the generated report, RTF fragments defined in << Document >> artifacts associated with the package do not.

Maybe I am not associating << Document >> artifacts with the package correctly. The documentation, in my opinion, is unclear on how to do it so what I have tried is:

• Add the artifacts as children of the package.
• Add the artifacts at the same level as the package and create << trace >> dependencies from the package to the artifacts.

Does someone see an obvious mistake in what I am doing?


Here follows in more details what I am trying to achieve.

The idea is to generate Word documents that follow company standards on the structure of their contents and their layouts from data exclusively contained in EA projects. The obvious way of achieving this is to create one RTF template for each type of documents but I see two disadvantages with this:

• All the boilerplate sections such as intro, purpose, scope, review and approval table, ... would have to be edited in the templates, hence making it cumbersome to reuse the templates across projects and, more importantly, adding complexity to version control tasks. We are using the manual way of maintaining EA projects under version control by tracking changes in exported XMI files (top level models under "Package Control"). Having to also frequently export the selected parts of "Reference Data" which contain the templates to track changes in the documentation sounds like a bad idea to me.
• It seems difficult to collect in a single template selected information spread in various places of the model.

For these reasons, I chose to go for the "Master and Virtual Documents" solution. The boilerplate sections are then stored in << Document >> artifacts associated with dummy packages so the whole documentation is part of the model while keeping generic templates as "Reference Data".

Thanks for any advice,

Robin