How to model OpenPages Reporting Framework with one single namespace only

1. Check list of all posts

   Context

Theoretically, Report authoring in OpenPages should be same as normal Cognos report authoring. However, it is not true, as report framework model is automatically generated by OpenPages. Therefore, report framework configuration and generation become extremely important. Unfortunately, report framework generation is very slow, normal range from 10 to 30 hours based on experience. We can create so many namespaces as needed, but it will take a lot more time to create report framework, which becomes unmanageable in practical situation.  This document is intended to explore whether it is doable to model OpenPages Reporting Framework with one single namespace only.

2. The model

Based on object model map, we can mode all objects with their associations.  Use the IBM sample below,

Besides two special relationships, or reclusive relationship and triangle relationship, we can simply to model these relationships below

Entity | Scenario Analysis

Entity | Loss event

Entity | Risk Assessment

Entity | Process

Entity | KRI

Scenario Analysis | loss event

Scenario Analysis | Risk

Loss Event | Loss Impact

Loss Event | Loss Recovery

Risk Assessment | Process

Process | Sub Process

Process | Risk

Sub Process | Risk

Risk | KRI

Risk | Control

KRI | KRI Value

3. Problems

Obviously, the single namespace will save a big time to generate report framework. However, you cannot simply drag different objects into Cognos studio(s) to generate report. There are 5 cases:

Case 1: select items from one single object.

Case 2: select items from one single object and business entity.

Case 3: select items from multiple objects, and there are no relationships among selected objects

Case 4: select items from multiple objects, and there are relationships among selected objects with a single unique path

Case 5: select items from multiple objects, and there are relationships among selected objects with multiple paths

Case 1 has no problem. This is a fundamental case, and does provide some value for data retrieval, as user can use, you can get currency fields and Enumeration Fields by simple drag and drop data item.  

Associated with business entity, many object can be used with GPC mode in case 2:  This case provides users with great flexibility, where all GPC functionalities can be leveraged.

Actually, the case 3 does NOT exist for the given sample before, as all objects are involved in the relationship. If there are such cases, the report won’t work as the normal cross join will be prohibited. If there is such a case, you need to two different queries and join in report studio.

Case 4 is perfect case; it will work with report studio, as Cognos knows exactly what to join to get data retrieved. For the sample above, there are a few paths listed below, where object does not have multiple parent

Risk > Control

KRI >  KRI Value

Loss Event > Loss Impact

Loss Event > Loss Recovery

Case 5 is for complicated report, where we can combine case #1, #2, #4 with relationship provided in reporting framework with parent context. Please sample below

The join is to join different cases together, sample below

If there is parent relationship, then parent context will be exposed. The sample below shows you all parent objects of issue. Therefore, we can very much connect issue with any object in report studio.

4. Note

The concept proposed is not implemented in real production, as I am not sure if IBM OpenPages can support multiple paths in reporting framework generation or not. Nevertheless, this concept does provide some idea to model object relations and report against the model.