As usual, Nizam Mohamed (Enterprise Architect Sparx Systems User Group) has inspired me and I have made a breakthrough. I tested the USECASE_TEMPLATE. It worked OK, so I compared the positioning of containers with my RTFTemplate Fragment. I fixed my table-row-printing fragment VEIAD_ELEM_TABLE_ROW (specified in my DocumentGenerator API Jscript).
The problem was caused by the positioning of the table row inside the diagram element containers as follows:
package>
diagram>element> "my table row" <element<diagram.
<package
I fixed the problem by moving the position of the table row outside of the diagram containers as follows:
package>
diagram><diagram
element>"my table row"<element
<package
RTFTemplate Fragment VEIAD_ELEM_TABLE_ROW is now producing a table row for each eligible diagram element.
I still have one problem with one of the RTFTemplate Fragment sub-queries, even though the same sub-query works perfectly in my Virtual Document model. I am not using the Virtual Document model because it does not allow me to programmatically choose between diagrams with tables and diagrams without tables. This is why I have developed this JScript to use the DocumentGenerator API.
The current problem lies in {Template - VEIAD_ELEM_TABLE_SQL_01_RUNTIME}
RTFTemplate Fragment VEIAD_ELEM_TABLE_ROW contains a table with one row and 7 columns as follows:
Column 1: {Element.Name}
Column 2: {Element.Stereotype}:{Element.valueOf(04-Hostname)}
Column 3: {Template - VEIAD_ELEM_TABLE_SQL_02_OS}
Column 4: {Element.valueOf(01-CPU)}
Column 5: {Element.valueOf(02-Mem)}
Column 6: {Template - VEIAD_ELEM_TABLE_SQL_01_RUNTIME}
Column 7: {Element.valueOf(06-Total Storage/Tier)}
All columns are successful except for column 6. Columns 3 (successful) and 6 (unsuccessful) are described below.
RTFTemplate Fragment VEIAD_ELEM_TABLE_SQL_02_OS contains the following code
custom>
{OS}
<custom
RTFTemplate Fragment VEIAD_ELEM_TABLE_SQL_02_OS contains the following Custom SQL Custom Query
select distinct t_objectproperties.Value as OS from t_objectproperties where t_objectproperties.Property in ('02-OS') and t_objectproperties.Object_ID in (select t_connector.End_Object_ID from t_connector where t_connector.Connector_Type in ('Generalization', 'Realisation') and t_connector.Start_Object_ID=#OBJECTID#)
RTFTemplate Fragment VEIAD_ELEM_TABLE_SQL_01_RUNTIME contains the following code
custom>
{RuntimeEnv}
<custom
RTFTemplate Fragment VEIAD_ELEM_TABLE_SQL_01_RUNTIME contains the following Custom SQL Custom Query
select distinct t_objectproperties.Value as RuntimeEnv from t_objectproperties where t_objectproperties.Property in ('01-Runtime Env') and t_objectproperties.Object_ID in (select t_connector.End_Object_ID from t_connector where t_connector.Connector_Type in ('Generalization', 'Realisation') and t_connector.Start_Object_ID=#OBJECTID#)
Question
Even though
1. VEIAD_ELEM_TABLE_SQL_02 succeeds in retrieving {OS} in this DocumentGenerator API context
2. VEIAD_ELEM_TABLE_SQL_01_RUNTIME and VEIAD_ELEM_TABLE_SQL_02 both succeed perfectly in my Virtual Document model wherein the table row is inside the diagram element containers
why does VEIAD_ELEM_TABLE_SQL_01_RUNTIME fail to retrieve {RuntimeEnv} in this DocumentGenerator API context?
