IBM Support

Changes to TM1 Application deployment and rights-saving in TM1 10.2

Technote (troubleshooting)


Problem(Abstract)

In IBM® Cognos® TM1 10.2, the TM1 Application Server permits an Approval Hierarchy dimension to be shared across Applications, and allows multiple Applications to be deployed on the same underlying cube. This is achieved by delineating each Application through the use of a Control dimension.

This new design flexibility adds additional complexity to the deployment process. For this reason, there is a one-time cost when deploying an Application and saving Rights for the very first time.

Ongoing routine updates to an Application should be performed quickly; only incremental changes to rights are processed, and there is a configuration option that permits parallel processing using multiple cores in the TM1 server.

This note applies only to Approval and Responsibility applications. The TM1 Application Server does not create any additional security structures for Central applications.

Cause

Overview
The TM1 Application Server takes the Rights that the modeler specifies for an Application’s Approval Hierarchy and translates them into security objects in the TM1 Server. In TM1 10.1.1 and earlier, the TM1 Application Server enforced the Rights through the use of element security on the Approval Hierarchy dimension. One effect of this was that the Approval Hierarchy dimension was tied to that Application only.

In TM1 10.2, TM1 Applications have a new concept of a Control dimension. This is intended to delineate the scope of different Applications so that the Approval Hierarchy dimension can be re-used, and so that multiple Applications can be deployed against different slices of the same cube; for example, to have a Budget and a Forecast application that could be deployed and secured independently. In TM1 10.2, the TM1 Application Server takes the Rights for the Application and enforces them by using cell security on the cube(s) in the Application that contain the approval hierarchy.

Deployments & Rights

The use of cell security has changed the way in which deployment and application right saving work. This technote discusses these operations, and their performance characteristics (including new configuration parameters that permit some processing to be performed in parallel to improve performance).

Application Deployment:

The first time an application is deployed, the TM1 Application Server generates a control dimension called }tp_task_{App GUID}. This dimension is a copy of the approval hierarchy subset and this is the dimension that is displayed on the workflow page of an application. It is against this dimension that element security is applied ( }ElementSecurity}tp_task_{App GUID}) to ensure users only see their relevant approval hierarchy nodes in the workflow page.

There are a number of other control objects which utilize this dimension. Below are some of the objects. Note that the modeler does not need to edit these objects directly; the TM1 Application Server updates them as required):
- }CellSecurity}tp_application_permission
- }ElementAttribute_}tp_task_{App GUID}
- }tp_application_permission
- }tp_applicationstate_{App GUID}
- }tp_task_navigation_{App GUID}
- ]tp_task_security}VIEW{App GUID}

The length of time the deployment operation takes is dependent upon the size of the approval hierarchy and the number of views in the application.

This operation incurs a one-time cost the first time it is performed, due mainly to the initial creation of the }tp_task_{App GUID} dimension. Thereafter, any changes are applied incrementally and will be faster than the initial deployment time. However, if any material changes occur to an application (eg. a large of number of views are added or deleted) deployment may take longer.

The creation of the }tp_task_{App GUID} dimension is a single-threaded process, which does not benefit from the new configuration option to parallelize some of the rights-saving process, as described below.

Application Rights Saving:
Once an application is deployed, rights can be applied to define the user groups that can access given nodes in the approval hierarchy. Access is granted at the following levels;
- View
- Edit
- Submit
- Review (if parent node)
Modelers also have the option to enable Reviewer Edit and set View and Review Depth.

The TM1 Application Server executes a number of TurboIntegrator processes to update various control structures in the TM1 server. This operation can consume a significant amount of time, depending on the size of the application (i.e. the length of the approval hierarchy, the number of views in the application and whether or not a control dimension is present). However, similar to the deployment operation, there is a one-time cost the first the time this is performed.

At a high level, each time an application rights save takes place, data moves from the Application Rights to the }tp_intermediate_RDCLS}<cubename> cubes. These are interim security cubes which collate rights for an application or across applications (when applications share an approval hierarchy). In turn, they then populate cell security cubes for the data cubes deployed in the application. There is one }tp_intermediate_RDCLS} <cubename> cube and one cell security cube for each data cube defined in the application. The }tp_intermediate_RDCLS}<cubename> cubes consist of the following dimensions:

- }Groups (list the user groups available in the TM1 server)
- Approval Hierarchy
- }tp_intermediate_security_applications (a list of applications sharing the approval hierarchy dimension)
- }tp_intermediate_security_measures (Rights, Static rights, ReadCount & WriteCount)
- Control Dimension (if present in your application)

When the application rights are processed, the TM1 Application Server runs a TurboIntegrator process that populates the Rightsslice of the above cube for the given application, based on the security defined in the application rights.

This cube then nets out the rights across multiple applications, where more than one application shares the approval hierarchy (at the ‘all applications’ level). The resulting rights (derived from a rule) are then copied into the StaticRights slice of the cube (at the ‘all applications’ level). This step is needed, as there may be situations where a given group has different rights to the same approval hierarchy node in different Applications (for example).

It is this slice of the cube that is used to populate the cell security cube, via a rule. The data is copied into the StaticRightsslice of the }tp_intermediate_RDCLS{<cubename> cube to ensure that the cell security cube, which references the StaticRightsslice, can be queried as efficiently as possible.

As of TM1 10.2.0 FP1 there is an option to have a significant part of the right-saving process executed using parallel TurboIntegrator processes. This can be configured in the pmpsvc_config.xml file; the line to add in the <service> section is:

<deployment maxThreads="X"/>

For example:

<fpm_service>
<config class="com.ibm.cognos.pmpsvc.PMPSVCConfig"/>
<service name="PMPService">
<method name="setClients" sessionOptional="true"/>
</service>
</fpm_service>
<service>
<eventHandler class="com.ibm.ba.pm.service.pmpsvc.notification.app.contributor.event.handler.PMMobileEventHandler"/>
<!-- Uncomment the line below to change the location of the planning service application files -->
<!--appdef path="Location of planning service application files" /-->
<folder name="IBM Cognos TM1 Application - My Applications"/>
<appdef path=""/>
<notifications emailProvider=""/>
<deployment maxThreads="4"/>
</service>
<clients>

Where X is the maximum number of threads allocated. We recommend a number between 4 and 8 for an 8-16 core TM1 server. Testing indicates that there is little benefit from increasing the number of threads above this level. We suggest that customers test with a lower number of threads initially (e.g. 4) and then increase gradually, observing the incremental benefit.

As mentioned above, there is a one-time cost when applying rights for the first time; however subsequent updates of rights process only the incremental changes since rights were last saved. Once an application is in routine operation, ongoing incremental changes to the rights should be processed significantly faster than the first-time loading of rights. This part of the process will again benefit from running TurboIntegrator processes in parallel.

Creation of cell security cubes

In TM1 10.2, it is no longer necessary for a cell security cube to use all of the dimensions of the parent cube (as the case was in 10.1.1 and prior releases). When a cube is deployed in a TM1 Application, the TM1 Application Server creates a cell security cube (if none exists already) for that parent cube. The TM1 Application Server creates the cell security cube with the minimum necessary dimensionality; if the Application has both an Approval Hierarchy and a Control dimension specified, then the cell security cube will contain these two dimensions along with the }Groups dimension. The use of a Control dimension is optional; if no Control dimension is specified for the Application, then the cell security cube contains just the Approval Hierarchy dimension and the }Groups dimension. By default, when an Application is upgraded from TM1 10.1.1 or earlier, no Control dimension is specified. The modeller can choose to add a control dimension to an upgraded application in Performance Modeler by dragging and dropping a dimension subset onto the “Control Dimension”. All slices in the control subset become writable slices by default after you redeploy the application. The modeller can set different rights to the Control dimension slices using the Control dimension tab in the Application’s Rights page (either inside Performance Modeler or in the TM1 Applications portal).

The modeler can open the cell security cube in Performance Modeler and supplement these dimensions with additional ones if desired, by using the Change dimensionality button on the Security Editor toolbar.

If a cell security cube already exists for a given cube deployed in the TM1 Application, then the following action is taken:

- If the existing cell security cube had a rule applied, then the full dimensionality of the cell security cube is retained, along with the existing rules. The TM1 Application Server inserts a new rule to enforce the application Rights at the top of the rule string for the cell security cube.

- If the existing cell security cube had no rule applied, then it is destroyed and re-created with the minimum necessary dimensionality – i.e. just the Approval Hierarchy and Control dimensions, plus }Groups. Again, the TM1 Application Server then inserts a new rule to enforce the application Rights at the top of the rule string for the cell security cube. This is done for ease of modelling and to ensure the minimum memory footprint for the cell security cube. If you had an existing cell security cube that you had populated with hard string values (rather than using Rules), you should export and back up the cube data before proceeding with the upgrade.

In TM1 10.1.1 and earlier, the TM1 Application Server took control of element security for the Approval Hierarchy dimension. Once the upgrade to 10.2 is performed, any existing element security cube for the Approval Hierarchy dimension will be removed.

Once the cell security cube is in place (with the required dimensionality), the TM1 Application Server enforces the Approval Hierarchy Rights by writing a rule into the cell security cube that references a system cube that the TM1 Application Server uses to store details of the application Rights. You should not attempt to delete or disable this Rule, but you can move it within the rule string (to get the correct Rule precedence) if you want to supplement cell security for other purposes. This is discussed further below.


Default behaviour of Cell Security

When a Cell Security cube is created in 10.2, it behaves as in prior releases – i.e. if there is an entry in the Cell Security cube for a given tuple in the parent cube, then Cell Security overrides any other security; but if Cell Security is empty, then other TM1 security (e.g. element security) still takes effect for the corresponding cells in the parent cube.

This behavior can be changed using a setting in the new }CubeSecurityProperties cube.

When a new Cell Security cube is created, the CELLSECURITYDEFAULTVALUE is initially blank – this implies the behavior from prior release.

This parameter may instead be set to NONE, READ or WRITE. The TM1 Application Server will set this value to NONE for any cube deployed in a TM1 Application. The purpose of }CubeSecurityProperties cube is to define the default value for a cell security if it is empty. For example, if you set NONE for a cell security cube in }CubeSecurityProperties cube, then any cells with empty value in that cell security cube will become NONE.

Cross reference information
Segment Product Component Platform Version Edition
Business Analytics Cognos TM1 TM1 Performance Modeler Windows 10.2 Edition Independent

Document information

More support for: Cognos TM1
TM1 Contributor

Software version: 10.2

Operating system(s): Windows

Reference #: 1659476

Modified date: 22 March 2016