Skip to Content

BOXI 3.1/BI 4.X - Best practices for maintenance and onward migration of back end sources - Do we have them documented?

Hi All,

Greetings, hello and wishes. This is further to my various experiences with customers in the recent years and would like to understand if there have been well defined ways to help customers follow various best practices for maintenance of BO environment and help them on onward migration, or also in continuing a BO activity or in maintaining a BO environment as BAU - in real terms. Atleast I have never been able to find one such document from SAP. 😊 And have found my own ways of finding the health check of any environment and must say Query Builder really has been of great help. But that has been a huge exercise to adapt and to extract information - which is meaningful finally.

A few things which am trying to explore and understand while we are looking at some customers who have done a systems migration or upgrades or added new systems to the environments for back end data sources which are being used for Business reporting as well. While these things have happened, correcting the data at the source systems seems to be a great challenge. Especially when there is a great dependency of various source systems on the ETL side. And then we see that BI reports are not appropriate and then finding the RCA is a way anyhow.

But that seems to be a bit time consuming for me when am looking at a BO enviornment perspective as to how to handle this.

What am really looking at is : how to map the object used in one report - against various universes being used.

Or to state the challenges more explicity :

  • How to map OBJECTA used in WEBI REPORTA, which I have identified that data is wrong, which has come from the sourceA. I have identified that on one report. Now I want to know, how many reports are there in the system which has this OBJECTA

Can we do that mapping. And find out ? list of universes affected on this particular object identified as source data error.

Can we do this kind of reverse mapping - by any chance.

  • If my understanding is correct, these object properties are not stored in CMS but in the report itself.

  • The challenge is that,

When you look at an environment with more than 5k reports in use, and sources which are wide spread coming through multi-various ETL processes including legacy systems from different networks, (including those which are likely to be sunset in the coming years), but then, as on date, when I look at the BO application and look at the various reports which are in production, this kind of information is important for me to understand where all my reports are going to fail.

  • While one can say that monitoring is the way. But how much to monitor when you dont have much information about the systems or processes under consideration. Hence this post on the BO forums, to find out if anyone can help me.

Can anyone help me understand this please. And guide me with a few suggestions which could be used to identify the various problems - before an issue is actually reported by an end user - which actually happens after a few weeks or even after few months.

While I have started a huge activity of collating various data sources and tables / reports / universes etc, I would appreciate if anyone could help me few more logical ways to get this information in a much refined way, easily, that would help me flag - X no of reports \ being affected, due to source data issues. I wish to have this kind of proactive triggers on the system to be implemented. All suggestions welcome.

Thanks for your help in advance.

Kind regards

Indu

Add a comment
10|10000 characters needed characters exceeded

Related questions

1 Answer

  • Posted on Dec 27, 2013 at 01:20 PM

    I would recommend you to go and check for Information Steward which is meant for metadata management and lineage analysis. If license matters it is up to you to develop a custom application for your data analysis.

    Add a comment
    10|10000 characters needed characters exceeded

Before answering

You should only submit an answer when you are proposing a solution to the poster's problem. If you want the poster to clarify the question or provide more information, please leave a comment instead, requesting additional details. When answering, please include specifics, such as step-by-step instructions, context for the solution, and links to useful resources. Also, please make sure that you answer complies with our Rules of Engagement.
You must be Logged in to submit an answer.

Up to 10 attachments (including images) can be used with a maximum of 1.0 MB each and 10.5 MB total.