Inconsistent query behavior


UPDATE:  this is fixed in RPE 1.1.2.1

There is a known defect in RPE that causes inconsistent query behavior in some circumstances. To avoid these issues the general rules to follow when designing RPE templates are:

  • keep the nesting simple
  • organize duplicated queries under the same parent query
  • queries with “content” should be defined in the context of a parent query that matches the parent element in the schema
  • avoid nesting a higher level query ( shorter query path – a/b) in a child query ( longer query path – a/b/c/d)

How does the problem manifests itself?
Queries are not executed (no results) or the data returned is duplicated.

When and why does the issue occur?
The problem is caused by special types of query nesting and duplication.

Scenario 1
I will use Requirements Composer schema to define the scenario in which the problem manifests itself and the solution. The schema looks like this:

--- dataSource
----- artifact
------- content
--------- requirement
----------- attribute
------------- @name    
------------- @value

Now define the following structure

- query 1: dataSource/artifact
--- query 2: dataSource/artifact/content/requirement/attribute ( in context of 1)
--- query 3: dataSource/artifact/content/requirement/attribute ( in context of 1)

Note that query 2 and 3 are identical ($4 and $10 in the image bellow) but they (might) reference different attributes ( name vs value). As you execute the template multiple times on the same data you will notice that the first ( or second) query comes empty while it shouldn’t do so.

How to fix it?
Change the template structure such that the queries with “content” ( the ones for which attributes are used) are defined in the context of the closes parent in the schema. For the example at hand restructure the template to look like the following:

- query 1: dataSource/artifact
--- query 2: dataSource/artifact/content/requirement ( in context of 1)
----- query 3: dataSource/artifact/content/requirement/attribute ( in context of 2)
----- query 4: dataSource/artifact/content/requirement/attribute ( in context of 2)

Note that a new query was interposed between query1 and the former query2 and query3. The 2 queries with content are now defined in a much simpler context ( dataSource/artifact/content/requirement).

In the image bellow $3 and $5 are in the context of  $1 which in turn is in the context of  $2.

Scenario 2
I will use System Architect schema to define the scenario in which the problem manifests itself and the solution. The schema looks like this:

--- Encyclopedia
----- Diagrams
------- System Architecture
---------- Symbols
------------ Application
--------------- Relation
------------------- Connects
------------ Data Flow

Now define the following structure

- query 1: Encyclopedia/Diagrams/System Architecture
--- query 2: Encyclopedia/Diagrams/System Architecture/Symbols ( in context of 1)
------ query 3: Encyclopedia/Diagrams/System Architecture/Symbols/Application ( in context of 2)
---------- query 4: Encyclopedia/Diagrams/System Architecture/Symbols/Application/Relation/Connects ( in context of 3)
-------------- query 5: Encyclopedia/Diagrams/System Architecture/Symbols/Data Flow ( in context of 2)

The problem is that query 5 is nested in query 4 but its parent is query 2. You can observe in the image bellow how $12 is nested in $13.

How to fix it?

Avoid nesting a higher level query ( shorter query path) in a child query ( longer query path) when the logic of the report you want to produce does not require it. 

For the example at hand move query 5 outside query 4. This fixes the issue and it does not change the meaning of the template as the two queries ( 4 and 5 ) are unrelated anyway, the results of 5 do not depend on the results of query 4.

- query 1: Encyclopedia/Diagrams/System Architecture
--- query 2: Encyclopedia/Diagrams/System Architecture/Symbols ( in context of 1)
------ query 3: Encyclopedia/Diagrams/System Architecture/Symbols/Application ( in context of 2)
---------- query 4: Encyclopedia/Diagrams/System Architecture/Symbols/Application/Relation/Connects ( in context of 3)
---------- query 5: Encyclopedia/Diagrams/System Architecture/Symbols/Data Flow ( in context of 2)

You can observe in the image bellow how $12 was moved at the same level at $13.

Advertisements

Author: Dragos Cojocari

Architect for Rational Publishing Engine

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s