Overtime, I’ve written about keeping your TM1 model design “architecturally pure”. What this means is that you should strive to keep a models “areas of functionality” distinct within your design.

Common Components

I believe that all TM1 applications, for example, are made of only 4 distinct “areas of functionality”. They are absorption (of key information from external data sources), configuration (of assumptions about the absorbed data), calculation (where the specific “magic” happens; i.e. business logic is applied to the source data using the set assumptions) and consumption (of the information processed by the application and is ready to be reported on).

Some Advantages

Keeping functional areas distinct has many advantages:

• Reduces complexity and increases sustainability within components
• Reduces the possibility of one component negativity effecting another
• Enables the probability of reuse of the particular (distinct) components
• Promotes a technology independent design; meaning components can be built using the technology that best fits their particular objective
• Allows components to be designed, developed and supported by independent groups
• Diminishes duplication of code, logic, data, etc.
• Etc.

Resist the Urge

There is always a tendency to “jump in” and “do it all” using a single tool or technology or, in the case of Cognos TM1, a few enormous cubes and today, with every release of software, there are new “package connectors” that allow you to directly connect (even external) system components. In addition, you may “understand the mechanics” of how a certain technology works which will allow you to “build” something, but without comprehensive knowledge of architectural concepts, you may end up with something that does not scale, has unacceptable performance or is costly to sustain.

Final Thoughts

Some final thoughts:

• Try white boarding the functional areas before writing any code
• Once you have your “like areas” defined, search for already existing components that may meet your requirements
• If you do decide to “build new”, try to find other potential users for the new functionality. Could you partner and co-produce (and thus share the costs) a component that you both can use?
• Before building a new component, “try out” different technologies. Which best serves the need of these components objectives? (A rule of thumb, if you can find more than 3 other technologies or tools that better fit your requirements than the technology you planned to use, you’re in trouble!).

And finally:

Always remember, just because you “can” doesn’t mean you “should”.

Vision

Most organizations today have had successes implementing technology and they are happy to tell you about it. From a tactical perspective, they understand how to install, configure and use whatever software you are interested in. They are “practitioners”. But, how may can bring a “strategic vision” to a project or to your organization in general?

An “enterprise” or “strategic” vision is based upon an “evolutionary roadmap” that starts with the initial “evaluation and implementation” (of a technology or tool), continues with “building and using” and finally (hopefully) to the organization, optimization and management of all of the earned knowledge (with the tool or technology). You should expect that whoever you partner with can explain what their practice vision or mythology is or, at least talk to the “phases” of the evolution process:

Evaluation and Implementation

The discovery and evaluation that takes place with any new tool or technology is the first phase of a practices evolution. A practice should be able to explain how testing is accomplished and what it covers How was it that they determined if the tool/technology to be used will meet or exceed your organization’s needs? Once a decision is made, are they practiced at the installation, configuration and everything that may be involved in deploying the new tool or technology for use?

Build, Use, Repeat

Once deployed, and “building and using” components with that tool or technology begin, the efficiency at which these components are developed as well as the level of quality of those developed components will depend upon the level of experience (with the technology) that a practice possess. Typically, “building and using” is repeated with each successful “build” so how many times has the practice successfully used this technology? By human nature, once a solution is “built” and seems correct and valuable, it will be saved and used again. Hopefully, this solution would have been shared as a “knowledge object” across the practice. Although most may actually reach this phase, it is not uncommon to find:

• Objects with similar or duplicate functionality (they reinvented the wheel over and over).
• Poor naming and filing of objects (no one but the creator knows it exists or perhaps what it does)
• Objects not shared (objects visible only to specific groups or individuals, not the entire practice)
• Objects that are obsolete or do not work properly or optimally are being used.
• Etc.

Manage & Optimization

At some point, usually while (or after a certain number of) solutions have been developed, a practice will “mature its development or delivery process” to the point that it will begin investing time and perhaps dedicate resources to organize, manage and optimize its developed components (i.e. “organizational knowledge management”, sometimes known as IP or intellectual property).

You should expect a practice to have a recognized practice leader and a “governing committee” to help identify and manage knowledge developed by the practice and:

• inventory and evaluate all known (and future) knowledge objects
• establish appropriate naming standards and styles
• establishing appropriate development and delivery standards
• create, implement and enforce a formal testing strategy
• continually develop “the vision” for the practice (and perhaps the industry)

More

As I’ve mentioned, a practice needs to take a strategic or enterprise approach to how it develops and delivers and to do this it must develop its “vision”. A vision will ensure that the practice is leveraging its resources (and methodologies) to achieve the highest rate of success today and over time. This is not simply “administrating the environment” or “managing the projects” but involves structured thought, best practices and continued commitment to evolved improvement. What is your vision?

The OpenPages GRC platform includes 5 main “operational modules”. These modules are each designed to address specific organizational needs around Governance, Risk, and Compliance.

Operational Risk Management module “ORM”

The Operational Risk Management module is a document and process management tool which includes a monitoring and decision support system enabling an organization to analyze, manage, and mitigate risk simply and efficiently. The module automates the process of identifying, measuring, and monitoring operational risk by combining all risk data (such as risk and control self-assessments, loss events, scenario analysis, external losses, and key risk indicators (KRI)), into a single place.

Financial Controls Management module “FCM”

The Financial Controls Management module reduces time and resource costs associated with compliance for financial reporting regulations. This module combines document and process management with awesome interactive reporting capabilities in a flexible, adaptable easy-to-use environment, enabling users to easily perform all the necessary activities for complying with financial reporting regulations.

Policy and Compliance Management module “PCM”

The Policy and Compliance Management module is an enterprise-level compliance management solution that reduces the cost and complexity of compliance with multiple regulatory mandates and corporate policies. This model enables companies to manage and monitor compliance activities through a full set of integrated functionality:

• Regulatory Libraries & Change Management
• Risk & Control Assessments
• Policy Management, including Policy Creation, Review & Approval and Policy Awareness
• Control Testing & Issue Remediation
• Regulator Interaction Management
• Incident Tracking
• Key Performance Indicators
• Reporting, monitoring, and analytics

IBM OpenPages IT Governance module “ITG”

This module aligns IT services, risks, and policies with corporate business initiatives, strategies, and operational standards. Allowing the management of internal IT control and risk according to the business processes they support. In addition, this module unites “silos” of IT risk and compliance delivering visibility, better decision support, and ultimately enhanced performance.

IBM OpenPages Internal Audit Management module “IAM”

This module provides internal auditors with a view into an organizations governance, risk, and compliance, affording the chance to supplement and coexist with broader risk and compliance management activities throughout the organization.

One Solution

The IBM OpenPages GRC Platform Modules Object Model (“ORM”, “FCM”, “PCM”, “ITG” an “IAM”) interactively deliver a superior solution for Governance, Risk, and Compliance. More to come!

When preparing to deploy the OpenPages platform, you’ll need to follow these steps:

1. Determine which server environment you will deploy to – Windows or AIX.
2. Determine your topology – how many servers will you include as part of the environment? Multiple application servers? 1 or more reporting servers?
3. Perform the installation of the OpenPages prerequisite software for the chosen environment -and for each server’s designed purpose (database, application or reporting).
4. Perform the OpenPages installation, being conscious of the software that is installed as part of that process.

Topology

Depending upon your needs, you may find that you’ll want to use separate servers for your application, database and reporting servers. In addition, you may want to add additional application or reporting servers to your topology.

After the topology is determined you can use the following information to prepare your environment. I recommend clean installs (meaning starting with fresh or new machines and VM’s are just fine (“The VMWare performance on a virtualized system is comparable to native hardware. You can use the OpenPages hardware requirements for sizing VM environments” – IBM).

(Note – this is if you’ve chosen to go Oracle rather than DB2):

MS Windows Severs

All servers that will be part of the OpenPages environment must have the following installed before proceeding:

• Microsoft Windows Server 2008 R2 and later Service Packs (64-bit operating system)
• Microsoft Internet Explorer 7.0 (or 8.0 in Compatibility View mode)
• A file compression utility, such as WinZip
• A PDF reader (such as Adobe Acrobat)

The Database Server

In addition to the above “all servers” software, your database server will require the following software:

• Oracle 11gR2 (11.2.0.1) and any higher Patch Set – the minimum requirement is Oracle 11.2.0.1 October 2010 Critical Patch Update.

Application Server(s)

Again, in addition to the above “all servers” software, the server that hosts the OpenPages application modules should have the following software installed:

• JDK 1.6 or greater, 64-bit Note: This is a prerequisite only if your OpenPages product does not include WebLogic Server.
• Application Server Software (one of the following two options)

o   IBM Websphere Application Server ND 7.0.0.13 and any higher Fix Pack Note: Minimum requirement is Websphere 7.0.0.13.

o   Oracle WebLogic Server 10.3.2 and any higher Patch Set Note: Minimum requirement is Oracle WebLogic Server 10.3.2. This is a prerequisite only if your OpenPages product does not include Oracle WebLogic Server.

• Oracle Database Client 11gR2 (11.2.0.1) and any higher Patch Set

Reporting Server(s)

The server that you intend to host the OpenPages CommandCenter must have the following software installed (in addition to the above “all servers” software):

• Microsoft Internet Information Services (IIS) 7.0 or Apache HTTP Server 2.2.14 or greater
• Oracle Database Client 11g R2 (11.2.0.1) and any higher Patch Set

During the OpenPages Installation Process

As part of the OpenPages installation, the following is installed automatically:

For Oracle WebLogic Server & IBM WebSphere Application Server environments:

• The OpenPages application
• Fujitsu Interstage Business Process Manager (BPM) 10.1
• IBM Cognos 10.2
• OpenPages CommandCenter
• JRE 1.6 or greater

If your OpenPages product includes the Oracle WebLogic Server:

• Oracle WebLogic Server 10.3.2

If your OpenPages product includes the Oracle Database:

• Oracle Database Server Oracle 11G Release 2 (11.2.0.1) Standard Edition with October 2010 CPU Patch (on a database server system)
• Oracle Database Client 11g Release 2 (11.2.0.1) with October 2010 CPU Patch applied 64-bit (on an application server system)
• Oracle Database Client 11g Release 2 (11.2.0.1) with October 2010 CPU Patch applied 32-bit (on a reporting server system)

 Thanks!

In the beginning…

OpenPages was a company “born” in Massachusetts, providing Governance, Risk, and Compliancesoftware and services to customers. Founded in 1996, OpenPages had more than 200 customers worldwide including Barclays, Duke Energy, and TIAA-CREF. On October 21, 2010, OpenPages was officially acquired by IBM:

http://www-03.ibm.com/press/us/en/pressrelease/32808.wss

What is it?

OpenPages provides a technology driven way of understanding the full scope of risk an organization faces. In most cases, there is extreme fragmentation of a company’s risk information – like data collected and maintained in numerous disparate spreadsheets – making aggregation of the risks faced by a company extremely difficult and unmanageable.

Key Features

IBM’s OpenPages GRC Platform can help by providing many capabilities to simplify and centralize compliance and risk management activities. The key features include:

• Provides a shared content repository that can (logically) present the processes, risks and controls in many-to-many and shared relationships.
• Supports the import of corporate data and maintains an audit trail ensuring consistent regulatory enforcement and monitoring across multiple regulations.
• Supports dynamic decision making with its CommandCenter interface, which provides interactive, real-time executive dashboards and reports with drill-down.
• Is simple to configure and localize with detailed user-specific tasks and actions accessible from a personal browser based home page.
• Provides for Automation of Workflow for management assessment, process design reviews, control testing, issue remediation and sign-offs and certifications.
• Utilizes Web Services for Integration. OpenPages utilizes OpenAccess API Interoperate with leading third-party applications to enhance policies and procedures with actual business data.
  

Understanding the Topology

The OpenPages GRC Platform consists of the following 3 components:

• 1 database server
• 1 or more application servers
• 1 or more reporting servers

Database Server

The database is the centralized repository for metadata, (versions of) application data, and access control. OpenPages requires a set of database users and a tablespace (referred to as the “OpenPages database schema”). These database components install automatically during the OpenPages application installation, configuring all of the required elements. You can use either Oracle or DB2 for your OpenPages GRC Platform repository.

 Application Server(s)

The application server is required to host the OpenPages applications. The application server runs the application modules, and includes the definition and administration of business metadata, UI views, user profiles, and user authorization.

 Reporting Server

The OpenPages CommandCenter is installed on the same computer as IBM Cognos BI and acts as the reporting server.

Next Steps

An excellent next step would be to visit the ibm site and review the available slides and whitepapers. After that, keep tuned to this blog!

Recently I completed upgrading a client’s IBM Cognos environment – both TM1 and BI. It was a “jump” from Cognos 8 to version 10.2, and TM1 9.5 to version 10.2.2. In this environment, we had multiple virtual servers (Cognos lives on one, TM1 on one and the third is the gateway/webserver).

Once the software was all installed and configured (using IBM Cognos Configuration and, yes, you still need to edit the TM1 configuration cfg file), we started the services and (it appeared) everything looked good. I spin through the desktop applications (Perspectives, Architect, etc.) and then go the Web browser, first to test TM1Web:

http:// stingryweb:9510/tm1web/

The familiar page loads:

But when I enter my credentials, I get the following:

Go to Goggle

Since an installation and configuration is not something you do every day, goggle reports that there are evidentially 2 files that the installation placed on the web server that belong on the Cognos BI server. These files need to be located, edited and then copied to the correct location for TM1Web to use IBM Cognos authentication security.

What files?

There are 2 files; an XML file (variables_TM1.xml.sample) and an HTML file (tm1web.html). These can be found on the server that you installed TM1Web – or can they? Turns out, they are not found individually but are included in zip files:

Tm1web_app.zip (that is where you’ll find the xml file) and tm1web_gateway.zip (and that is where you will find tm1web.html):

I found mine in:

Program Files\ibm\cognos\tm1_64\webapps\tm1web\bi_files

Make them your own

Once you unzip (the files) you need to rename the xml file (to drop the “.sample”) and place it onto the Cognos BI server in:

Program Files\ibm\cognos\c10_64\templates\ps\portal.

Next, edit the file (even though it’s an XML file, its small so you can use notepad). What you need to do is modify the URL’s (the “localhost” string should be replaced with the name of the server running TM1Web.) within the <urls> tags. You’ll find three (one for TM1WebLogin.aspx, one for TM1WebLoginHandler.aspx and one for TM1WebMain.aspx).

Now, copy your tm1web.html file to (on the Cognos BI server)

Program Files\ibm\cognos\c10_64\webcontent\tm1\web and edit it (again, you can use notepad). One more thing, the folder “tm1” may need to be manually created.

The html file update is straight forward (you need to point to where Cognos TM1 Web is running) and there is only a single line in the file. You change:

var tm1webServices = [“http://localhost:8080”];

To:

var tm1webServices = [“http:// stingryweb:9510”];

Now, after stopping and starting the servers web services:

The above steps are simple; you just need to be aware of these extra, very manual steps….

IBM Cognos TM1 is well-known as the planning, analysis, and forecasting software that delivers flexible solutions to address requirements across an enterprise, as well as provide real-time analytics, reporting, and what-if scenario modeling and Perficient is well-known for delivering expertly designed TM1 based solutions.

Analytic Projects

Perhaps phase zero of a typical analytics project would involve our topology experts determining the exact server environment required to support the implementation of a number of TM1 servers (based upon not only industry proven practices, but our own breadth of practical “in the field” experiences). Next would be the procurement and configuration of said environment (and prerequisite software) and finally the installation of Cognos TM1.

It doesn’t stop there

As TM1 development begins, our engineers work closely with internal staff to outline processes for the (application and performance) testing and deployment (of developed TM1 models) but also to establish a maintainable support structure for after the “go live” date. “Support” includes not only the administration of the developed TM1 application but the “road map” to assign responsibilities such as:

• Hardware monitoring and administration
• Software upgrades
• Expansion or reconfiguration based upon additional requirements (i.e. data or user base changes or additional functionality or enhancements to deployed models)
• And so on…

Teaming Up

Earlier this year the Perficient analytics team teamed up with the IBM Cloud team to offer an interesting alternative to the “typical”: Cognos TM1 as a service in the cloud.

Using our internal TM1 models and colleagues literally all over the country, we evaluated and tested the viability of a fully cloud based TM1 solution.

What we found was, it works and works well, offering unique advantages to our customers:

• Lowers the “cost of entry” (getting TM1 deployed)
• Lowers the total cost of ownership (ongoing “care and feeding”)
• Reduces the level of capital expenditures (doesn’t require the procurement of internal hardware)
• Reduces IT involvement (and therefore expense)
• Removes the need to plan for, manage and execute upgrades when newer releases are available (new features are available sooner)
• (Licensed) users anywhere in world have access form day 1 (regardless of internal constraints)
• Provides for the availability of auxiliary environments for development and testing (without additional procurement and support)

In the field

Once we were intimate with all of the “ins and outs” of TM1 10.2 on a cloud platform, we were able to to work directly with IBM to demonstrate how a cloud based solution would work to address the specific needs of one of our larger customers. After that, the Perficient team “on the ground” developed and deployed a “proof of concept” using real customer data, and partnered with the customer for the “hands on” evaluation and testing. Once the results were in, it was unanimous: “full speed ahead!””.

A Versatile platform

During the project life-cycle, the cloud environment was seamless; allowing Perficient developers to work (at the client site or remotely) and complete all necessary tasks without issue. The IBM cloud team was available (24/7) to analyze any perceived bottlenecks and, when required, to “tweak” things per the Perficient team’s suggestions, ensuring an accurately configured cloud and a successful, on-time solution delivery.

Bottom Line

Built upon our internal teams experience and IBM’s support, our delivered cloud based solution is robust and cutting edge and infinitely scalable.

Major takeaways

Even given everyone’s extremely high expectations, the project team was delighted and reported back the following major takeaways from the experience:

• There is no “hardware administration” to worry about
• No software installation headaches to hold things up!
• The cloud provided an accurately configured VM -including dedicated RAM and CPU based exactly upon the needs of the solution.
• The application was easily accessible, yet also very secure.
• Everything was “powerfully fast” – did not experience any “WAN effects”.
• 24/7 support provided by the IBM cloud team was “stellar”
• The managed RAM and “no limits” CPU’s set things up to take full advantage of features like TM1’s MTQ.
• The users could choose a complete web based experience or install CAFÉ on their machines.

In addition, IBM Concert (provided as part of the cloud experience) is a (quote) “wonderful tool for our user community to combine both TM1 & BI to create intuitive workflows and custom dashboards”.

More to Come

To be sure, you’ll be hearing much more about Concert & Cognos in the cloud and when you do, you can count on the Perficient team for expert delivery.

In Framework Manager, an expression is any combination of operators, constants, functions, and other components that evaluates to a single value. You can build expressions to create calculation and filter definitions. A calculation is an expression that you use to create a new value from existing values contained within a data item. A filter is an expression that you use to retrieve a specific subset of records. Lets walk though a few simple examples:

Using a Session Parameter

I’ve talked before about session parameters in Framework manager (a session parameter is a variable that IBM Cognos Framework Manager associates with a session, for example user ID and preferred language and you also create your own) in a previous post.

It doesn’t matter if you use a default session parameter or one you’ve created, it’s easy to include a session parameter in your Framework Manager Meta Model.

Here is an example.

In a Query Subject (a query subject is a set of query items that have a relationship and are used to optimize the data being received for reporting); you can click on the Calculations tab and then click Add.

Framework Manager shows the Calculation Definition dialog where you can view and select from the Available Components to create a new Calculation. The Components are separated into 3 types – Model, Functions and Parameters.

I clicked on Parameters and then expanded Session Parameters. Here FM lists all of the default parameters and any I’ve created as well. I selected current_timestamp (to add as my Expression definition (note – FM wraps the expression with the # character to indicate that it’s a MACRO that will be resolved at runtime).

During some additional experimentation I found:

• You can add a reasonable name for your calculation
• You may have to (or want to) nest functions within the expression statement (i.e. I’ve added the function “sq” as an example. This function wraps the returned value in single quotes). Hint: the more functions you nest, the slower the performance, so think it thorough).
• If you’ve got the expression correct (the syntax anyway), the blue Run arrow lights up and you can test the expression and view the results the lower right hand pane of the dialog. Tips will show you errors/Results will show the runtime result of your expression.
• Finally, you can click OK to save your calculation expression with your Query Subject.

Filtering

Filtering works the same way as calculations. In my example I’m dealing with parts and inventories. If I’d like to create a query subject that perhaps lists only part numbers with a current inventory count of 5 or less, I can set a filter by clicking on the Filter tab and then Add (just like we just did for the calculation).

This time I can select the column InventoryCount from the Model tab and add it as my Expression definition. From there I can grab the “less than or equal to” operator (you can type it directly or select it from the Function list).

Filter works the same as Calculation as far as syntax and tips (but it does not give you a chance to preview your result or the effect of your filter).

Click OK to save your filter.

JOIN ME

Finally, my inventory report is based upon the SQL table named PartInventory which only provides a part number and an inventory count. I’d like to add part descriptions (which are in a table named simply “Part”) to my report so I click on the SQL tab and create a simple join query (joining the tables using PartNo):

To make sure everything looks right, I can click on the tab named Test and then click Test Sample.

You can see that you have a part name for each part number, the session parameter Time Stamp is displayed for each record and only those parts in the database where the inventory count is 5 or less:

By the way, back on the SQL tab, you can:

• Clear everything (and start over)
• Enter or Modify SQL directly (remember to click the Validate button to test your code)
• Insert an additional data source into your Query subject to include data from another source, perhaps an entirely different SQL database.
• Insert a Macro, For example, you can add inline macro functions to your SQL query.

Here is an example:

#$Corvette_Year_Grouping{$CarYear}#

Notice the # character to indicate the code within is a function to be resolved within the SQL query.

This code uses a parameter map (I’ve blogged about PM’s in the past) to convert a session parameter (set to a particular vehicle model year) to the name of a particular SQL table column (and include that column of information in my query subject result). So in other words, the database table column included in the query result will be decided at run time.

And our result:

You can see that these are simple but thought-provoking examples of the power of IBM Cognos Framework Manager.

Framework Manager is a metadata modeling tool that drives query generation for Cognos BI reporting. Every reporting project should begin with a solid meta model to ensure success. More to come…

A session parameter is a variable that IBM Cognos Framework Manager associates with a particular session. Examples include (current user name, current active language, current date and time, and others). Parameter maps are a method for substituting different values with different keys.

A parameter map can be thought of as simple data “look-up table”.

Each parameter map has two columns:

• a key column and
• a value column (holding the value that the key represents).

In Cognos TM1, Lookup (or mapping) cubes (and dimensions) are common (and I’ve blogged on them before).

So let’s create a simple Framework Manager Parameter Map:

Well, to construct your map, you can:

• enter the keys and values (for your map) manually,
• import them from an external file, or
• base them on query items in your Meta model

– it all depends upon the size and/or complexity of the parameter map you need to build.

Some helpful hints:

• All parameter map keys must be unique so that the Framework Manager can reliably obtain the correct value!
• The value of one parameter can be the value of another parameter, so you must enclose the entire value in number signs (#).
• There is a limit of five levels when nesting parameters in this way.

So let’s look at an example exercise. I chose to use the “source file” method to create my map.

In Framework Manager, right-click in the Parameter Maps icon, then select Create and Parameter Map:

From there, you can enter a name for your parameter map.

Since I am converting (or mapping) (Corvette) part numbers into part descriptions, I’m naming my new parameter map:

“Keen Corvette Restoration Parts”,

and then selecting the option “Manually enter the parameter keys and/or import them from a file”:

On the Create Parameter Map Wizard dialog, I entered a default value (a value to be used if a key doesn’t have a value in your map) and then clicked on Import File…

Navigated and selected mysource file (to use a .txt file for import, the values must be separated by tabs and the file must be saved as UTF8 or in the Unicode format. ANSI text files are not supported):

Clicked OK and Framework Manager created my parameter map. It looks good, (it does!) so I clicked on Finish:

And you can see my new map now existing in my project:

Done!

If you double-click on your map, the Parameter Map dialog opens again where you can clear your map, import a new source file (to over lay or add to your map), add new specific keys, export your map or edit it directly.

Next time I will illustrate how to use the new parameter map!

One of the goals of the Cognos Framework Manager modeler is to build a model that makes report authoring easier. To accomplish that, you “build in” business logic” (a loosely defined term here) into your meta model.

This business logic can be simple (like simply renaming or hiding a database table column) or quite complex (like modifying SQL commands to return only specific data from a datasource).

Some of the basics you can add to your model are:

• Stipulating attributes
• Renaming or hiding database columns
• Adding prompts
• Applying filters
• Creating calculations
• Adding formatting to data items
• Using folders and namespaces for grouping information
• Using shortcuts to include the same information in different places

Let’s explore a few of these.

Stipulating Attributes

A simple example is changing the attribute type of an imported database column. This is done for various reasons, but manly to dictate how Report Studio deals with the data in a report (for example, Report Studio may attempt to sum numeric fields which may, depending upon the database column, be a meaningless number).

An example (from my demo project) would be the ProductID field in the Products table (imported from SQL Server).It is imported as a FACT field (since it is defined as a numeric in the database table). To change this field’s attribute, I:

Select the database field (by clicking on it) and in the Framework Managers “Properties Pane” (hint, if you can’t find the properties pane, go to “view” on the FM menu and click Properties to make it visible), I locate the property “Usage”. There, I can change the attribute:

Renaming or hiding database columns

This is even easier. If you’d like to rename a database column (to something more “user friendly”) or perhaps hide it (for example, we don’t want to display Salary information to the report authors), you can just:

• right-click on the database column in the Framework Manager Explorer column and select (from the popup menu) “rename” or
• back in the properties pane, change the “Is Hidden” property to TRUE (to hide the column)
  

Applying filters

Filters are neat. For example, my demo includes a database table named Employee. Right now, the meta model includes all records (all employees) in the table. That would include both active and inactive employees. I want to make sure that reports only use active employees, so I can alter the FM query (to apply a query filter) to accomplish this:

1. Double-click on the table name Employee (in the FM explorer pane).
2. FM shows me the “Query Subject Definition” dialog.
3. Edit the SQL (hint: use the Validate button).
4. Click OK.

And so on. You can see that Cognos Framework Manager makes it easy to build out your meta model with your business logic but to be sure, the real work here is to identify what logic to include and obtain consensus from your business stakeholders on the correctness of the logic.

Until next time…

During a recent project of mine, I jumped “head first” into IBM Cognos Framework Manager.

Yes, it is an awesome tool, but where exactly does it “fit” into the Cognos environment? Are there similar or alternate tools that can be used?

I just had to have a quick look!

The Cognos Components

Okay, so the components of the Cognos 10 BI environment include:

• Business Insight & Insight Advanced
• Cognos Connection
• Cognos Viewer
• Query Studio
• Report Studio
• Analysis Studio
• Event Studio
• Metric Studio
• Admin
• Framework Manager
• Transformer
• Metric Designer

Of all these components, our “modeling tool options” are Framework Manager, Transformer and Metric Designer. Here is some background on each:

Framework Manager

This is a tool for creating business related metadata for use in IBM Cognos BI analysis and reporting. This metadata is then published for use by reporting tools as “packages”, which provide an integrated view of your data sources.

Framework Manager can be used to:

1. model for predictable results (star schema)
2. model for OLAP-style queries (model dimensionally)
3. create one or more business views
4. add calculations
5. create and apply filters
6. add prompts
7. set row level security

Transformer

This is a tool for modeling dimensional hierarchies and levels for PowerCubes. You can use Transformer to create a “business organization” of the information in your data sources.

You add dimensional metadata, specify measures, apply custom views, and then create PowerCubes (based on this model). You can than deploy these cubes to support OLAP reporting and analysis.

Metric Studio

This is a modelling tool used to create extracts for use in IBM Cognos scorecarding applications. You can use these extracts to map and transfer information from existing metadata sources (like Framework Manager!) Metric studio can be used to create scorecard content such as:

1. Watch lists
2. Scorecards
3. Strategies
4. Metric types
5. Individual metrics

Conclusion

My conclusion is that it is imperative for every Cognos developer to understand what modeling tools are available for use and where they “fit” in the overall environment. Of course, this is a general “rule of thumb” that is true in any profession – “know your tools”.

A proven practice for Framework Manager Meta Modeling is to divide your model into a series of layers, each layer having a specific purpose. (Originally IBM recommended the use of two layers (data and modeling), but later added a presentation layer, and (optionally) a separate dimensional layer).

The layers should be:

• The top layer – or the “presentation layer”,
• The middle layer – or the “logical layer” and
• The lowest level – or the “data layer”.

(The dimensional layer can be used to replace the presentation layer, or can be used in addition to the presentation layer).

The Data layer

Contains the data source or “query subjects”.

The Logical layer

Where most of the modeling is done, providing business context to the data layer. For example, you can join fields from multiple tables, rename fields, assign aliases, organize by folders, etc.

The Presentation layer

This is what the report author sees when you publish a package for report creation.

The Dimensional layer

The dimensional layer is required only for models which include Dimensionally Modeled Relation data (DMR) rather than only the relational data. Specifically, this is for creating regular and measure dimensional query subjects.

By Default…

In my last post, I created a new FM project named “corvette” and added a simple relational datasource (a SQL database).

You can see that by default, FM created a “namespace” named “FelxibleModel”.

In order to adhere to our “layers” proven practice, we need to make some changes to our project (before we do any real modeling). To do that you can simply right-click on the namespace and select Create and then Namespace”:

From there, rename the namespace as “Data Layer” (right-click on the namespace and select rename). Next, I moved my 2 database tables (Product and Sales) under it (click, drag and drop):

Now I can create my 2 other namespaces (Logical and Presentation):

Remember to save the project. One note, the names for the “layers” can be anything that makes senses within your organization, but give some thought to a convention as object names must be unique identifiers.

Now we are ready to do some real “meta modeling”. See you next post!