Reporting Guidelines

 

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 detail information should be the basis for providing summarized data to reporting InfoCubes.  Utilize the DSO layer for list reporting of a couple hundred transnational records rather than analyzing large amounts of summarized information.

Alternatively, utilize InfoCubes for reporting large amounts of summarized data. In order to use the storage structure for what it is best suited and leverage the drill-down capabilities of the system, the above-mentioned reporting discipline is suggested.

Each object in the data warehouse should be leveraged and utilized appropriately by utilizing drill-down and drill-through capability while maintaining the information standards and summarization levels accordingly in the data warehouse.

1.2. Report Template

1.Build a report template and standards for each reporting tool in order to provide a consistent look-and-feel to the end user.

A template should be created to ensure that all reports have a common look-and-feel including standards on how information is organized. This will make it easier for the business to get to the required information, and for the BW team and power users to build consistent reports.

1.3. Report Elements (SAP Business Explorer Elements)

1.3.1. Restricted Key Figures

The following key points should be considered when utilizing restricted key figures:

  1. Efficiency - Restricted key figures are very efficient for recurring selections on an InfoProvider. Restricted key figures can be saved as reusable objects to maximize their reuse on a given InfoProvider.  In most cases, financial reporting (i.e. financial statements) use similar characteristic restrictions across the company to measure financial performance.
  2. Key Figure vs. Account Based Models – Depending on the data model decided, key figure vs. account models can drive the type of restricted key figures necessary to define. For example, revenue on a financial statement is driven by the revenue accounts; hence a revenue key figure in this type of model would need to be restricted on the account dimension.  However, some data models may be key figure based where sales, tax, and discount fields are all separate key figures.  Based on the needs of the report and the user community, restricted key figures should be defined appropriately to improve efficiency and allow users to understand the data in the underlying data model.

1.3.2. Calculated Key Figure

The following key points should be considered when utilizing calculated key figures:

  1. Efficiency - Calculated key figures are very efficient for recurring formulas on an InfoProvider. Calculated key figures can be saved as reusable objects to maximize their reuse on a given InfoProvider.
  2. Calculations – Calculated key figures utilize standard mathematical functions
  3. Standard vs. Complex Calculations – Calculations and formulas which are standard should be leveraged as calculated key figures to allow reusability. However, complex calculations should be evaluated on a case by case basis to determine the most efficient way to report (Pre-calculate in data load process, utilize calculated key figure, utilize cell exceptions, etc.).  Maintainability, performance, frequency, and complexity are the main considerations to use when determining where to perform a given calculation.
  4. Leverage Restricted and Calculated Key Figures – Calculated and Restricted key figures can be utilized in conjunction with each other. For example, 3 restricted key figures could be utilized in a calculated key figure, and a calculated key figure can be utilized as the basis for a restricted key figure.

1.3.3. Variables (User Entry Parameters)

When a query is developed for particular analyses, the parameters need to be controllable and flexible enough to minimize additional changes later.  In many cases, flexibility can be achieved through the use of variables.

Variables are created globally in BI. When a variable is created in the system, it can be used across multiple queries. Naming conventions should be synonymous with the function of the variable.  Intuitive naming conventions allow themselves to be used by all developers during development.

1.3.4. Structures

Structures are another type of object which provides opportunities for reusability. Structures contain frequently used combinations of data selections or formulas. Structures can be saved globally and re-used across the same InfoProvider.

 

1.4. Reporting Authorizations

Reporting authorizations can have significant impact on the design as well as performance.  Due to the impact, these requirements need to be captured and understood during requirements gathering and blueprint phases.

Reporting authorizations can be grouped as the following:

  • Restrictions based on a specific characteristic/navigational attribute value.
  • Restrictions based on a specific hierarchy node.
  • Restrictions to specific master data attribute.
  • Restrictions to specific key figures such as employee salary.

Each security requirement should be analyzed as it relates to the proposed data model to ensure the required authorization checks do not hinder query performance.

 

1.5. SAP BW Front­End Usage Standards and Guidelines

1.5.1. Chart Designer in Web App Designer

  1. Use the Chart Designer feature to customize the standard chart web item when developing charts within web templates.
  2. Developers should use the Chart Designer to customize the look and feel of the default chart web item within web application designer to accommodate special charting needs for the application and save them in a web application designer library to maintain uniform look and feel.

For example, if a supply chain application uses bar charts and pie charts in its web application, then the developer should create one instance of each chart type with the customization and save it in the web application template library and reuse the library web item instead of recreating the web item individually for each occurrence.

Each application should have its own web application designer template library that contains each type of chart web item used in the application.

1.5.2. Nested Web Templates (Web Template Web Item)

Use the Web Template web item to manage consistent sections of different Web Templates within one main Web Template. The default configuration for any KO web application report developed using Web Application Designer should contain the following number of web templates at the minimum:

  1. One main web template to Host the Report
  2. One content web template to display web items such table, chart, etc.
  3. One common header web template (containing headings or web tool bars)
  4. One common footer web template (can be blank, if not required by application)

Apply naming standards when creating web templates with Web Template web item using Web Application Designer.

1.5.3. Adhoc Query Designer

The ad­hoc query designer web item provides options to SAP BW technically savvy power users over the web to build their own queries directly in production based on info provider data.

Before developing web reports using the ad­hoc query designer web item, work with the security team to build a security model for your InfoProviders and level of data access. You should complete the following tasks:

  1. Design and create groups / roles for power users who will use the ad­hoc query designer (using the S_RS_COMP BEx authorization component).
  2. Arrive at an authorization model to restrict the data that the power users can see using authorization relevant variables.

The ad­hoc query designer should not give power users full access to InfoProviders without using security roles and authorization variables.

1.5.4. Mass Maintenance of Web Templates

Developers should not attempt mass maintenance of web templates using program RS_TEMPLATE_MASS_ALTER. Overwriting web templates can lead to massive, unrecoverable changes.

 

Courtesy: SAP BW Project and help documents

Comments

Post a Comment

Popular posts from this blog

Sample ABAP program for Updating notepad file data to Internal table and Sending it to Application server

 *--Structure type TYPES: BEGIN OF TY_STD, RONO TYPE C LENGTH 4, NAME1 TYPE C LENGTH 20, GEN TYPE C LENGTH 6, FEES TYPE C LENGTH 10. END OF TY_STD. *--Header line and internal table DATA WKA TYPE TY_STD. DATA INT_TAB TYPE TABLE OF TY_STD. *--Application server files are known as "Datasets" *--here "fname" is the Dataset DATA FNAME TYPE C LENGTH 40 VALUE "StudentsInfo.txt". *--Convert notepad file data into internal table CALL FUNCTION 'GUI_UPLOAD' EXPORTING FILENAME = 'C:Documents and SettingsAdministratorDesktopstudents.txt' HAS FIELD_SEPARATOR = 'X' TABLES DATA_TAB = INT_TAB. *--Sending data to Application Server OPEN DATASET FNAME FOR OUTPUT IN TEXT MODE ENCODING DEFAULT. LOOP AT INT_TAB INTO WKA. TRANSFER WKA TO FNAME. ENDLOOP. CLOSE DATASET FNAME.
Read more

OPEN SQL EXAMPLES IN ABAP – PART 2

 ******************************************* **displaying Raw Materials and Finished products **only from MARA table. DATA WA TYPE MARA. * **--WHERE clause is for filtering the records SELECT * FROM MARA INTO WA WHERE MTART = 'ROH' OR MTART = 'FERT'. WRITE: / WA-MATNR, WA-MBRSH, WA-MTART, WA-MEINS. ENDSELECT. * **************************************************
Read more

Domains and Data Elements

  Domains A domain provided Technical attributes (type, length and possible values) for a field. The definition of domain in ABAP is same as that in Mathematics. In the world of Mathematics, a domain is defined as the set of input values that are valid for a given function. The same holds true for domains in ABAP. To understand this, let us first see what is the role of domains in ABAP data dictionary. Domains -> Data Elements -> (Structures, DB tables, program references etc.)
Read more