Who's Online

We have 1 guest online
Home
Welcome to the fastest growing COGNOS community on the web!
Friday, 08 May 2009

COGNOiSe.com began life in July 2005 as a COGNOS technical forum but now boasts an ever-increasing arsenal of tools that encourage the effective use and development of the COGNOS product range.

BrightStar Partners, a Cognos Corporate Performance Management professional services and solution provider, proudly owns, hosts and operates this site.

CLICK HERE TO JOIN

 
COGNOiSe.com Articles
Monday, 29 June 2009

Size Limit of Framework Manager

By Avdhesh Singh, BrightStar Partners, Consultant

6/29/2009
Contrary to popular belief, there is no size limit for a Framework Manager model or package. The model file is stored on the hard disk, and the file could be as large as available on the hard disk. With that being said, there could be some problems in report authoring if the package size is extremely large.  

For example: if you have one package pointing to a JD Edward database, AS 400 databases etc.. The package gets loaded into memory when you author any report based on that package. Since the package is being loaded into memory, you may experience performance issues based on the package size.

The biggest question is really, “What goes into one model of Framework Manger?”  The answer differs depending upon the situation. A model should be designed based on business subject areas, and I personally prefer taking an object oriented approach. Therefore, it is often best to divide the model design into different layers.

  1. The First layer is the database layer - All database objects which are related to one another in one fashion or another, properties of query items (attribute, identifier or fact) and relationship between query subjects are maintained in this layer. You may want to use folders (not namespaces) to organize these tables.

  2. The Second layer is the performance layer - This is layer where you may want to combine two database columns or create any calculations. In case of snow flake modeling, you may want to combine two related dimensions. You can also rename columns, add filters, organize, etc.

  3. The Third layer is the business layer - The package is created from this layer. I prefer to create a namespace based on the business requirements here. For example, if I have budget at only product line level then I will have a namespace with four objects - Product Class, Product Line, Actual and Budget in Namespace1. There will be another namespace, Namespace2, with four objects - Product Class, Product Line, Product and Actual. In this way, I do not have to train user not to pull product while putting budget and actual in same list report. I can then use shortcuts in Namespace1 and Namespace2. This helps me when I modify anything in a query subject, this will get replicated into Namespace1 or Namespace2. 

In conclusion, the size of framework manager model depends only on what is manageable. If you have proper enterprise MDM in place, then you can choose to have all data marts or an entire data warehouse modeled in one FM model. If MDM is not in place then a package should be based on business need.

Setting up security in Cognos 8.3 Transformer cubes using Active Directory

By S.J. Van Jaarsveld, BrightStar Partners, Consultant

5/26/2009

The following steps provide a summary for setting up security in Cognos 8.3 Transformer cubes using Active Directory. It also lists a few pitfalls to be aware of.
 
Steps:

  • Create the necessary Active Directory groups, and add the users for each AD group. You may also create an AD group that contains users that need access to all data, for example, all countries in the 'Americas' territory.

  • In Transformer, open the diagram, and select the Custom Views tab. Create a custom view for the appropriate dimension's parent level (e.g. create an 'Americas' territory custom view). This custom view will represent users that need access to all data in the 'Americas' territory.

  • In the properties for this group, click 'Assign Security' and select the AD group that needs access to all data.

  • Within the parent level custom view, right click and create a custom view for the first member (e.g. 'United States'). Click 'Assign Security' and select the AD group for the 'United States'.

  • Continue to create the remainder of the custom views and assign the security in the same fashion.

  • In the diagram, restrict the access for every group as required (using the Exclude option).

  • When you have completed assigning security for every group, drag the parent custom view from the Custom View list, and drop it on top of your cube in the PowerCubes list. Continue to drag the children custom views, and drop them on top of the parent custom view on your cube in the PowerCubes list.

  • Continue to run the report and select a year when prompted. The Year-to-Date value will be displayed next to the month value.


Additional Information

  • After publishing the cube to Cognos Connection, you may receive an error: 'PDS-PPE-0083 -- The system is out of memory. (Security)'. Increasing the Read cache size (MB) in Cognos Administration will resolve this error.

If your environment has Transformer installed on a Windows server, you may run into the following problem: testing the cube using PowerPlay (on the Windows server), PowerPlay may not authenticate user security back to AD. This will cause an error: 'Access is denied. The user is not authenticated or the cube does not support any of the user classes.' Publishing the cube to Cognos Connection, and accessing the cube in Analysis Studio will resolve this issue.
 

DATA MANAGER FACT BUILD DELIVERY METHODS

By Greg Jungels, BrightStar Partners, Consultant
5/12/2009

When using SQL Server 2005/2008 as your target for a Data Warehouse, there is a new Fact Delivery method available that provides increased performance: "SQL Server Bulk Copy via API Delivery."

This new Delivery method uses the SQL Server 2005/2008 supplied API for bulk copying of records.
 
The drawback of using this delivery method is that it does not support UPDATE or UPDATE/INSERT, making it useful primarily for work/temp tables.
Below is a test scenario comparing the performance of the standard Relational Table Delivery and the SQL Server Bulk Copy via API Delivery.  This scenario was set up to demonstrate the Delivery method only.  There were no transformations and/or calculations involved.
Test scenario: 11,986,030 records in SQL Server 2005 database

 Build Run Time 

           Relational Table

      SQL Server Bulk Copy via API

 Build Run Time

           1:38

      0:31

 Insert Start Time

           8:19

      9:15

 Insert End Time

           9:57

      9:29


Result: Although it took about 15 minutes for the "SQL Server Bulk Copy via API" delivery method to commit the records, it still had a 200% improvement (or 1/3 the time) over the "Relational Table" delivery method.  For any questions, e-mail .

 
(C) 2009 BrightStar Partners, Inc
Joomla! is Free Software released under the GNU/GPL License.