SAP BO Universe Best Practice check list
Below are best practice guidelines for Universe development
• Universe Name & Universe Description should be defined with proper Business Name and description in the Universe properties.
• Class name should be started in INIT cap.
• Objects name should be started in INIT cap.
• Object should be placed in alphabetical order in the class.
• Measure Objects in any class should be placed after the dimensions/detail objects.
• Always define every object with meaningful description so that it helps user easily understand the purpose of it which avoids going through heavy documentation.
• Measure objects should be created with aggregate functions like sum, max, min etc. This will ensure that only required aggregated data is returned to reports instead of whole set of raw data.
• Create the context with proper business logic names. It will help you to find out what context is used in a particular report.
• Always place any derived tables or isolated tables down in the universe structure pane so that they are easily identifiable.
• Alias’ names should be same as those of the respective base table’s name followed by the (short) name which identifies the purpose of its creation. For Example:- DIM_DT is a date dimension for which, the Aliases, Start Date and End Date may be named “DIM_DT_START_DATE and DIM_DT_END_ DATE respectively.
• Avoid automatic creation of Classes/Objects as this process lacks the analysis of user needs.
• Short Names or Abbreviations of classes/objects should be uniform across the universe (like Number may be replaced with “Nbr” or “Num” but, it should be uniformly practiced).
• Custom Hierarchies may be built wherever necessary to make sure that all reports using drill analysis will fetch consistent results.
• Predefined / prompted condition objects should be placed in a separate class.
• Turn on the LOV only on the required objects.
• Create LOV’s on master tables instead of actual data/fact table.
• Try to resolve all complexities (data relationship, formatting) in universe itself otherwise it may become tedious in reporting side. For instance, take Revenue as a measure that you created in universe without any formatting. It is the biggest trouble for any report developer to format for currency. This would be easy for one report but what if the developer has to do it for some 50 reports that have Revenue measure in it. So try to do all formatting for numbers, currencies from universe side itself. If it is done, then it’s just a drag n drop for the developer
• After developing the complete universe, always have a complete Integrity Check which will ensure that everything in placed in perfect place and will work properly.
• Always import a new copy from the repository and do the development. Anyway, the inbuilt Version Control System of Business Objects is going to warn if you export an older version of the universe when the latest version exists in the repository. But the best practice is to get the latest version from the repository to avoid any kind of discrepancies.
• Hide all the objects from the universe that are not often used for reporting and not going to be used for some time.
• Use contexts and alias table to resolve fan trap and chasm traps in universe.
• Universe Name & Universe Description should be defined with proper Business Name and description in the Universe properties.
• Class name should be started in INIT cap.
• Objects name should be started in INIT cap.
• Object should be placed in alphabetical order in the class.
• Measure Objects in any class should be placed after the dimensions/detail objects.
• Always define every object with meaningful description so that it helps user easily understand the purpose of it which avoids going through heavy documentation.
• Measure objects should be created with aggregate functions like sum, max, min etc. This will ensure that only required aggregated data is returned to reports instead of whole set of raw data.
• Create the context with proper business logic names. It will help you to find out what context is used in a particular report.
• Always place any derived tables or isolated tables down in the universe structure pane so that they are easily identifiable.
• Alias’ names should be same as those of the respective base table’s name followed by the (short) name which identifies the purpose of its creation. For Example:- DIM_DT is a date dimension for which, the Aliases, Start Date and End Date may be named “DIM_DT_START_DATE and DIM_DT_END_ DATE respectively.
• Avoid automatic creation of Classes/Objects as this process lacks the analysis of user needs.
• Short Names or Abbreviations of classes/objects should be uniform across the universe (like Number may be replaced with “Nbr” or “Num” but, it should be uniformly practiced).
• Custom Hierarchies may be built wherever necessary to make sure that all reports using drill analysis will fetch consistent results.
• Predefined / prompted condition objects should be placed in a separate class.
• Turn on the LOV only on the required objects.
• Create LOV’s on master tables instead of actual data/fact table.
• Try to resolve all complexities (data relationship, formatting) in universe itself otherwise it may become tedious in reporting side. For instance, take Revenue as a measure that you created in universe without any formatting. It is the biggest trouble for any report developer to format for currency. This would be easy for one report but what if the developer has to do it for some 50 reports that have Revenue measure in it. So try to do all formatting for numbers, currencies from universe side itself. If it is done, then it’s just a drag n drop for the developer
• After developing the complete universe, always have a complete Integrity Check which will ensure that everything in placed in perfect place and will work properly.
• Always import a new copy from the repository and do the development. Anyway, the inbuilt Version Control System of Business Objects is going to warn if you export an older version of the universe when the latest version exists in the repository. But the best practice is to get the latest version from the repository to avoid any kind of discrepancies.
• Hide all the objects from the universe that are not often used for reporting and not going to be used for some time.
• Use contexts and alias table to resolve fan trap and chasm traps in universe.
Above points should be followed with Universe performance tuning guidelines given separately on this blog to get presentable and good performance report.
Good content
ReplyDelete