Let’s say you need to add the following confidentiality statement to each of your footers in dozens of existing Cognos reports: “The information contained within this report is proprietary and confidential. No part of this report may be disclosed in any manner to a third party without prior written consent.”
IBM Cognos and Motio Best Practices Blog
When it comes to getting some very common and crucial tasks done in IBM Cognos TM1, we found that there are many quite painful tasks to do. They are so painful, that the thought untangling Christmas tree lights for a living seems much more appealing! One such painful task we are going to focus on today is managing security in TM1.
Have you ever lost or corrupted a Cognos Framework Manager Model? Have you ever wished you could recover the lost model based on information which is stored in your Cognos Content Store (e.g. a package which was published from the lost model)? You're in luck! You can use MotioPI (a free tool for Cognos admins) to recreate your Framework Manager Model's "model.xml" file with just a few simple clicks.
When I get a brand new, flawless, unsullied anything- laptop, smart phone, car, BI software system, or whatever the item...I vow to keep it lean and mean and tell myself, "This time I'm not going to accumulate any unnecessary content, apps, data, trash, take out Chinese food containers, etc., and I am going to stay on top of regular maintenance." Right.
A Cognos user (let's call him "Carlos") tries to run a report but receives an error message indicating that the attempt to connect to the data source failed. Carlos alerts you, the administrator, about the issue and you are now tasked with finding the cause. Meanwhile, Carlos' workflow is interrupted and he must switch gears to something less important until the data source issue gets resolved for him to be able to access reports again. What if you could avoid the frequency of this data source connectivity problem hitting Carlos and the rest of your Cognos users? Well, you can and we'll show you how in this blog post.
We recently broadcast a "skills session" webinar for testing IBM Cognos administrative objects with MotioCI software. One of the featured objects we demonstrated how to test was data source connections. Data source connectivity can be automatically and continuously tested by MotioCI and comes preconfigured with the software, out-of-the box. Let's take a look...
It seems like there is a different tech conference every month these days, so sifting through the noise and determining which one is truly beneficial for you and your personal career growth (along with which events will benefit your organization) is a task not to be taken lightly.
One of MotioPI Pro's basic fundamentals is to improve workflows and how administrative tasks are done in IBM Cognos in order to "give time back" to Cognos users. Today's blog will discuss how to improve the workflow around editing Cognos Framework Manager model element names, descriptions, and tooltips. We will demonstrate a MotioPI Pro feature that makes it easy to update the information that business users see- model terminology elements.
Creating shortcuts in Cognos is a convenient way to access the information you use frequently. Shortcuts point to Cognos objects such as reports, report views, jobs, folders, and so on. However, when you move objects to new folders/locations within Cognos, the shortcuts that reference them turn into broken links. You would then have to go into Cognos and recreate all of the shortcuts to those objects that were moved.
Or, you could conveniently move the Cognos objects within MotioPI Pro in order to prevent broken shortcuts and avoid the pain of having to recreate them.
In some situations employees leave companies and the organization has not fully prepared for their exit. One specific scenario when an employee leaves that causes a great deal of extra work on IBM Cognos administrators involves the ex-employee's scheduled jobs, reports, etc.
Let's say that Ed has configured many scheduled jobs and reports that go out to a number of people, but he has left the company. Shortly after Ed's last day, several of these people are not receiving their scheduled Cognos reports. These employees contact their administrator. The administrator investigates and sees that these specific failed reports are attempting to use Ed's account and since he has left the company, his account in LDAP is inactive, causing the reports to fail.
In IBM Cognos, schedules are associated with a "credential," which is a security token that is associated with a Cognos user. In this case, Ed's schedules execute and authenticate through his credential. His stored credential passes to the authentication source (e.g. LDAP, Active Directory, etc.) to get logged in. After an employee leaves, their account becomes inactive in LDAP, AD, or the like, and all of their many scheduled jobs and reports will fail. The Cognos admin is then tasked with figuring out how to find and then reassign all of the ex-employee's schedules.
In Cognos, there is no easy way to do this. There is no search feature that allows you to find all schedules that use a specific Cognos user's credential.
When you need to reconfigure an existing Cognos environment to a use a different external security source (e.g. Active Directory, LDAP, etc), there are a handful of approaches you can take. I like to call them, "The Good, the Bad, and the Ugly." Before we explore these Good, Bad, and Ugly approaches, let's take a look at some common scenarios that tend to drive authentication namespace changes in a Cognos environment.