SAP easy learning

 Navigational attributes are discussed a lot of times in BW. They have an advantage as these attributes can be used for navigation in a query. However there are lot many more advantages of navigational attributes. I will discuss today one such scenario where navigational attributes has saved a week’s time. The Scenario is like this- There are 2 characteristics used in a cube. One characteristic is an attribute of another and both the info objects are included in the cube. Info object           Is Attribute of Country                                Region Region Both country and region are included in the cube as separate characteristics and country is an attribute of Region. Hence the master data of REGION info object will look like below- Region Country North America USA Asia Pacific India Now suppose the fact and dimension tables in the cube store a wrong combination of the region and country value- Customer Region Country Item Revenue Quantity C1 North America USA PC 1000 2 C2 Asia

 The query designer formulas sometimes involve if then else kind of conditions or case statement type of logic. These type of logic can be easily given in the query designer, however the procedure is little tricky as you cannot write simple if statements in the query designer. Scenario – Suppose you have Amount and Net due date characteristics in the cube. The user gives the key date as query input. Based on the difference between the net due date and the key date, the query should return whether the amount is Due (i.e. net due date is in future as compared to key date) or Overdue (i.e. the net due date is passed as compared to key date). The query should also return the bucket information if the amount is overdue. Which means that the query should tell that the overdue amount falls in which bucket (>90, 61-90, 31-60 or 1-30). These buckets are assigned based on the number of days calculated earlier which is the difference between the net due date stored in the cube and the k

 Looking up a table while doing data load is a common scenario in SAP BW. Here the look up table can be active table of some other DSO. You can note a point here that cube cannot be used for look up. This is because, a cube has a fact table which is based on star schema. Hence the primary keys in a fact table will be dimension ids instead of the primary key values. Now coming to our scenario, suppose data is loaded from DSO1 to CUBE1.

 The number of times users have seen the BI reports can be analyzed in BW. All of this information is recorded as BW statistics automatically by the system provided the setting is activated for the targets. The data where the information is stored is the cube 0TCT_C01 [Front-End and OLAP Statistics (Aggregated)]. This cube is SAP standard cube and holds the usage statistics data. This comes under Technical Content info area in BW. The main info objects in the cube and their functions / meanings are summarized below-

  1. Managing Change Control and Transports This blog post addresses standards and guidelines related to changing and transporting objects within the SAP BI landscape.   1.1. General Standards and Guidelines Do not create BW objects and leave them in the $TMP package. If you need to prototype or experiment, you should do so in the Sandbox or Temporary TR created for that purpose. If you cannot use the sandbox, contact your development manager and the BI Platform Health team to discuss options. As you create objects, assign them the proper package (development class) and put them into the correct transport request, based on the standards described below. 1.1.1. Object Grouping and Sequencing Group objects logically, and release transports in the following order to minimize errors:

  1.1.  Querying 1. All queries should be built on multi-providers – even if it is to be built on a single InfoProvider. Multi-providers provide flexibility for the reporting layer.  Additional InfoCubes/DSO’s can be added in the future without much impact to the existing reports built. In cases where data needs to be combined using “joins,” InfoSets can be created. However, multiproviders should still be built on top of InfoSets for reporting. No end user reports should be built directly on InfoCubes, DSO’s or InfoSets. Any reports built directly on InfoCubes/DSO’s should be utilized from an IT perspective for data quality or support inquiries. 2. For reporting, standards will be set as it relates to the information stored within each data warehousing layer. InfoCubes should be used to access summarized information and, DSO’s or additional detailed InfoCubes should be used to access detailed information. Since the data warehousing architecture should include a DSO layer, this det

 This post describes the standard methods and architecture for extracting data from source systems and into the first ­level Data Targets. The preferred extraction method varies depending on the source system technology. The standard extraction methods appear in descending order from most to least desired. Developers must attempt to use the methods at the top of these lists before proceeding down to the less preferred methods.