10 Steps to SAP BusinessObjects BI4 – Retiring Unused Content

Out with the old, useless, and broken

So far in this series, Eric Vallo and Ethan Jewett talked about gathering your stakeholders (of the IT and business varieties) and considerations when integrating BI 4 with BW. In this post, I’d like to take a few paragraphs to talk about ensuring that you venture into SAP BusinessObjects BI4 with a well groomed set of BI content.

Over the years of being on XI 3.1 or XI R2 (or maybe even classic BusinessObjects 6.5 or earlier), you have no doubt gathered lots of BI content. Some of it is useful. Some of it is not. Your users may have created hundreds of copies of your public BI content in an effort to create that perfect report for their individual needs. Each user may have done this a few times over on many Web Intelligence documents, Crystal Reports, or even Desktop Intelligence documents. You likely even have some public content or scheduled content that is never even being looked at by your users. The objective here is to point out the categories of content that you should consider either removing from your current deployment or specifically not migrating to BI4. So, let’s get on with the real information…

Redundant Content

Let’s start with one of the harder situations to handle. There are two primary ways that redundant content would exist in  your environment:

• Your users create copies of existing content in an effort to get that perfect report that provides them with the information that they need. 
• Your users or report developers are creating duplicate content because they don’t know that something similar already exists.

So, how do you handle these two scenarios?

In the first scenario, the duplicate content is likely either in the user’s folder or in a public folder that you’ve designated as a storage location for user content. One way to handle this is to have users themselves clean up content that they don’t need. Ha! Of course, you must give them a reason to do so otherwise they will just ignore your pleas for help. The carrot for them could be that their content will no longer be available once you get to the new deployment, but they will just come to you anyway when they can’t find that one report that they reallllllllllly need. I mean, can’t you just restore it from backup or something? A second option is to save user content for a later part of the migration and build a process for users to stage their own critical content for migration into the BI4 environment.

In the second scenario, the duplicate content probably exists throughout your public BI folders. This makes this scenario even more difficult to handle than the one above. You could try perform a search based on the name of the document and the last time that it was accessed or modified, but you still run the risk of deleting something that is important.

Shameless product plug: Luckily, we at EVtechnologies have you covered when it comes to identifying duplicate content via our Enterprise Report Finder, part of the Sherlock® Inspector Suite. We can show you which reports are duplicates of each other based on their underlying Universe, Query, and the Universe Objects contained in the reports.

Unused Content

The next set of content that is rife with the ability to clean is any content is unused. This could apply to either actual BI content (e.g., Web Intelligence documents), Universes, or user accounts. You can gather some of these details from your Audit database. The objective is to look at content that has never been used, not used in the past X number or days (where X is determined based on how often you expect your users to look at your content), Universes that are used infrequently or not at all, Universe Objects that are used infrequently or not at all, Database Connections that are not used, and users that do not login or haven’t logged in in the past 30, 60, 90, etc…. days.

Again, Sherlock® can assist with automating much of this; however, you could figure out a bit of this one your own via queries against auditor and manually inspecting your CMS. For more information how to use Sherlock® for clean-up activities you can check out my past blogs on Sherlock®KPI, Tracking Usefulness, and Eliminating Runaway Content.

Error Prone Content

Another step that you can take to reduce the number of headaches you encounter after the move is to correct or remove content that routinely causes errors. For example, perhaps you have a schedule that fails 25% of the time that it runs. Your administrators may just get around this by re-running it for the users until it’s successful rather than fixing the core problem. You may even have many reports that fail more frequently in the environment and you just aren’t aware of it. The specific areas on which you should focus for error causing content are: scheduled content, pre-built content, and ad hoc content creation.  For some of this, you can probably look at the history of your internal ticket tracking systems to determine which BI content or Universes are seeing the most frequent failures as reported by your users. In order to look at content proactively or that your users may not have reported, you’ll need to dig a bit deeper into the history for scheduled reports, the Instance Manager, or even logs for recurring errors.

Yep, you guessed it, Sherlock® can help you here too.  The report below allows Sherlock® users to proactively determine the reports that are failing in their deployment – likely before users even realize it.

We can provide similar information for your scheduled reports as well.

Content Causing Instability

So, what do I mean by content causing instability? Typically this would be anything that is of a large size or routinely takes a long time to run. You likely have users or specific divisions that demand more from your BI deployment than other users. It is important to embrace these users as they are the ones who can help you improve the performance and stability of your environment. Sure, they may cause you headaches as they push the boundaries of your system, but, in the end, they can help you make your deployment better for everyone.

You can start investigating this type of content by again looking back at the history in your internal ticket tracking system. You probably have support issues that were logged because a report was “taking too long to run” or a schedule never completed. You could also poll your users as part of the planning process to have them help you identify problematic content. Additionally, your DBAs can help you with identifying queries that take a long time to run.

Using Sherlock®, you could also identify problematic content using a variety of pre-built reports. One such report is shown below and allows you to track schedule durations and errors. In addition, we have other pre-built content that will alert of you ad hoc reports or pre-built, non-scheduled reports that routinely takes a long time to run or is larger than a defined size limit.

Die, Deski, Die

Our next to last topic of conversation is Desktop Intelligence content. I’m sure all of you are aware of the need to start transitioning your Desktop Intelligence content to another format type. The first step is to determine how much Desktop Intelligence content you actually have versus the other content types. After that, you need to determine how much of that Desktop Intelligence content is actually being used (i.e.g, viewed, edited, created, or refreshed). This will give you the actual number of documents for which you actually need to be concerned. Finally, with that list, you can then determine what features have been used in the documents and run through a test conversion.

Sherlock® can help here as it can show you how much of each BI content type exists in your deployment, how many aggregated views, edits, and refreshes each piece of content is seeing, and some of the underlying features for which you need to be concerned in the Desktop Intelligence documents.

Content Affected by Product Changes

The final step, when it comes to ensuring your content is ready for the migration is to determine which of your content will be impacted by changes to products as you upgrade. One frequent example of this is in the calculation engine for Web Intelligence. As such, you need to be concerned with the syntax being used within your Universe Objects, in your document level variables, and in your document level formulas. You can compare the list of known of issues and fixed issues from the various BI4 release notes to the formulas and variables you are using in your BI content. This will help you to identify any content that may be negatively impacted by the upgrade.

I hope that you have found this post useful and that it helps you as you plan for your upgrade to SAP BusinessObjects BI4. If you would like to learn a bit more about getting to BI4, you can check out my past presentation on this topic here. Additionally, we invite you to check out Sherlock® to determine whether it can help you on your quest to moving to BI4 and managing your SAP BusinessObjects or Crystal Server deployments.

Thanks for reading.