Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

Summary

Do you also work on one of those "historically grown" SAP BW Systems? Are you using the system for several years and keep upgrading from one version to the next. Your chances are good, that many things have piled up, that you actually don't need anymore!

Why should you clean up?

  • Because if it complicates your structure!
  • You stumble across those objects from time to time and you do not know why they are still around
  • or you actually want at some point to upgrade to SAP BW on HANA or even SAP BW/4HANA. As memory is precious (and "expensive") you only want to take objects with you, that you actually need.

Errors

No real errors here. As these are usually manual tasks, it takes quite some effort. In addition, there is always the "fear" to break something, just because of your good intentions to clean up something!

For the actual decision, if something can be deleted and does not break anything else, you need thorough analysis. Often people plan to do this "later" when they have "more time", but in real life, the "later" is actually a never, as new topics keep coming and coming! After a project/change request is before the next one.

Cause

Most tasks are done manually. Many aspects have to be considered for housekeeping activities to be successful. Identify cleanup candidates, understand dependencies, understand soft factors/information relevant to those elements and so on.

Solution

With the help of the Docu Performer, we can minimize your fear of taking a decision and cleaning up your SAP BW systems.
Check out how the Docu Performer can support you to:

Phase

Activities

How to support them with the Docu Performer

Possible Saving
(on each Activity)

Analysis
  1. Identify unneeded objects that can be deleted. This also includes the search for inactive DTPs, because the depending process chains would fail (1c).
  2. Identify Queries that have not been used for a long time.
  3. When working with reporting objects and not being careful with transports it might happen that you accidentally generate objects with the same technical name but with different GUIDs. This leads to confusion and mistakes.
  4. As you have identified the objects to be candidates for deletion you need to understand the dependencies from this specific SAP BW Object to nearly all other elements (including ABAP/AMDP).
  5. Specifically for Queries, you can immediately check the structure of the query to evaluate the dependency and the type of usage (free characteristic vs. selection vs. filter, etc.).
  6. You want to use consistent Naming Conventions.
  7. Understand if there are any other implications for the objects you want to delete. In addition, you can preserve your knowledge for later use, changes in team structure, etc. so that colleagues don't have to go through the same process ("We cannot clean up this object because ...")
  8. If you don't want to use any more queries that are for example having complex definitions, are for example input ready but should be (anymore), then you have to find all those different elements in your system.
  9. Find ABAP "BreakPoints"/"Select Single"/"..." that could be a problem for SystemLog or Performance or...
  10. Understand what is on which system available. Are all Queries/InfoProviders/etc. transported and available in all Systems? All emergency changes from PROD maintained in DEV as well? Can elements be deleted?
  1. There are several functions for that:
    1. List InfoProvider without Usage in Data Flows
    2. Last Load and Usage Analysis
    3. Show inactive Objects
    4. Unused InfoObjects
    5. Variables Analyzer
  2. Use "Grid View" with "Column Chooser" and column "Last Used Date": Column Chooser
  3. Show Entities with identical tech. Name
  4. Usage of BW Entities
  5. Analyze/Compare Elements
  6. /wiki/spaces/DPUM191/pages/437979234
  7. BW Commenting
  8. Selections by special Components
  9. /wiki/spaces/DPUM191/pages/437979286
  10. Mass comparison: /wiki/spaces/DPUM191/pages/437979240. Individual comparison: /wiki/spaces/DPUM191/pages/437979266 (can be also triggered form the mass comparison for individual elements; mass detailed comparison coming soon)
  1. 20%-50%
  2. ~5%
  3. 5%-15%
  4. at least 15% depending on how well used later!
  5. ~5%
  6. 5%-15%
  7. ~5%
  8. 10%-20%
  9. 10%-15%
  10. 50%-80%
Design

If you have a good idea, please let us know how we can support you even more and create a feature request!



Implementation
  1. While doing all the changes, you can easily add and preserve your results and special knowledge for later use. So when somebody is ill, on vacation or the team changes, everybody knows what to and why things happen. So you avoid repeated work and save time and money.

  1. BW Commenting
  1. 10%-40%
Testing

If you have a good idea, please let us know how we can support you even more and create a feature request!



Deploy

For deployment procedures, e.g. what needs to happen before/after transporting, any special steps needed, etc., have a look to documentation...

If you have a good idea, please let us know how we can support you even more and create a feature request!



Support

See documentation...

If you have a good idea in addition, please let us know how we can support you even more and create a feature request!



Documentation
  1. Just with a little added effort, you can create documentations for different target groups (Functional Department, Audits, IT, etc.) to inform about the different changes that happened through the cleanup.
  1. BW Documentation especially: Scenarios
  1. 10%-40%



  • No labels