In this the discussion about the Report Designer will include comments in terms of dealing with certain issues and limitations. These comments and configuration suggestions are not necessarily final solutions to each of these issues but very good starting points in your analysis. As you know, with all possible solutions additional review and testing are necessary to make sure that they work properly in your environment. In addition we will be looking at functionality that is standard delivered with the Report Designer and that discussion is more consistent with the statement that this configuration will definitely work within your BI environment. To start, the positioning of the Report Designer in the current BI architecture is shown in the following illustration. In this position the Report Designer is normally a component that is used by the BI Power User or Super User but, depending on the delegation of responsibilities in the reporting area, could be used by the technically oriented business user.
The purpose of the Report Designer is to make information that is available more user friendly and easier to review and understand. This includes getting the critical information to the decision maker in a timely manner and in an efficient format, such as with a dashboard. The following illustration shows an example of what a minor change to the information, using the Report Designer, would do to the look and feel of information and what this can mean to the business user. Changing the format from a list of information to a true report can be very important to ensuring the business user interprets the information correctly.
This chapter does not cover the details of all the components used in the Report Designer, such as the Information Broadcaster and printing processes, unless the details are relevant to the discussion of those issues I’ve identified from the different questions posted on Web sites about the Report Designer. Suffice it to say that you should be aware of these components and their use with the Report Designer toolset.
It is also important to be aware of exactly what types of reports you can create with the Report Designer. If you have a query whose report requirements don’t allow for a static format—for example, the query involves variables, and the format of the report must expand or adjust when the variables are entered—you may not be able to use the Report Designer to accomplish the desired results. I’ve seen this happen many times, and it can cause quite a bit of frustration before the designer realizes that either the report requirements can’t be met with the Report Designer or the query that they want to use will not format correctly in the Report Designer. An example of this would be if you have a report that allows a variable to be used for the total number of columns in your formatted report, this is not a suitable query structure for the Report Designer. You would need to alter your report to have a set number of columns so that you can fix the format within the Report Designer. Prior to starting your configuration and formatting process, you should review your requirements and the functionality available in the Report Designer and validate that the final results are possible.
In the overall process of using the Report Designer, we have really two specific approaches for formatting reports. First is the Static and Dynamic sections of the Report Designer report and once the type of sections of the Report Designer is identified the second is the development of the Row Patterns.
1.Static and Dynamic Sections in a Report Designer Report
A report can include both static and dynamic sections. The distinctive feature of static sections is that query fields can be positioned freely. You do not specify the type of section in the Report Designer; rather, the section type is automatically set depending on the type of data provider you are using. In the case of a static section of a query (or a query view), the architecture of the query contains two structures—one structure in the rows and one in the columns. A static section is unique because you can freely position all the fields within the section. This is possible because each field is unique in a static section and each cell of the result is uniquely defined, so the formatting and positioning of information is related directly to an individual cell.
In this case, the type of query we are identifying is unique in that there are structures in both the rows and columns and this format for a query or query view is not common but when using the Report Designer it’s not just about the data but also about the formatting of the data so that the Report Designer can use it appropriately. If the query being used as a source of information to the Report Designer is not consistent with the functionality available, then the resulting formatted report will not work for either you or your business user. Therefore, the initial view in the Report Designer corresponds to the executed query (query view). Each row in the executed query has one row pattern. The following illustration shows an example of this structure.
A static section can also be a report section without a data provider. Such sections include the page header and page footer, as well as the report section (for example, for inserting gaps or your own text and comments), which you can integrate into your report using the Insert menu in the Report Designer. We will use this technique a bit later to help us solve one of the questions about the functionality of the Report Designer.
A query (or query view) forms the basis of a dynamic section that has one or more characteristics in the drilldown. This means that one or more group levels are designed for the initial view in the Report Designer. There is one group level for each characteristic. Within a dynamic section, query fields can only be taken from external group levels into internal ones.
For example, you can move a cell from group level 1 to group level 2, but you cannot move it the other way. The cell repositioning options are limited with a dynamic section because the cells are not all uniquely defined. Therefore, in dynamic sections, the number of rows varies at run time, whereas the number of columns is fixed. For example, in the following illustration, there are three levels and a dynamic section view. Group level 1 and group level 2 are related to the two characteristics: level 1 is related to Country and level 2 is related to Sold-to Party. Group level 0 relates to the header and footer information, and in all Report Designer configuration there will be a group level 0.
If a query (or query view) contains two structures and also one or more characteristics, a dynamic section will be used. The dynamic section generates individual cells for each intersection of the two structures, which means you will be able to reposition these cells freely. You cannot use a query or query view that contains more than one structure in the columns (this is a unique format for a query so we will not run into this issue many times). So, this format is actually a hybrid of the two types and has formatting capabilities that drive it to a dynamic format rather than a static format, but this structure is a bit trickier to work with and can be a bit more complex to align correctly. This discussion leads us directly into the details of row patterns.
A central component of the Enterprise Report Design concept is the concept of the row pattern and is essential to the development of the dynamic sections of a Report Designer report. With reports of this type, the number of characteristic values in the drilldown is not set at the time of report creation. It becomes visible during run time. To understand the row pattern concept, you need to look at the structure of a report with dynamic sections. Below figure shows an example of this structure.
In below figure, you can see that a number of row types can be identified in a report. This means that there is a specifically formatted row that is applied to column headers or a specifically formatted row for results values. Each group level has three row types: header, details, and footer. For each row type, there is a template, called a row pattern, that describes the color, font, height, and width of the rows, and so on.
Groups and row types for Row Patterns
The layout of a query is defined in the drilldown of the structure elements in the columns and rows of the query. Every structure element in the rows of the query corresponds to a group level in the row pattern concept. Thus, the number of possible group levels in a report depends on the drilldown status of the query. Additionally, the detail area itself can also represent a group level (with header and footer and a detail area). This is how group levels can be nested in each other. The innermost group level of a report has detail rows that contain key figures. The Report Designer generates a row pattern for each area of a group level. Row patterns are the smallest units of a BEx report that are not divided by page boundaries. Row patterns comprise cell grids whose cells can have specific properties.
The Report Web item uses the row pattern and data to generate the header, detail, and footer areas of a report. Using the properties of the row pattern, you specify the format of cells and the entire cell grid. These properties are applied when the report is executed. The row pattern concept and its properties enable you to design reports in the Business Explorer. The Report Web item found in the WAD uses these row patterns to display reports. SAP delivers numerous standard row patterns and you can change these according to your needs in the Report Designer. You can also create new row patterns by setting the properties of the cells for a cell grid. The cell grid, and therefore every cell in a row pattern, has the properties detailed in below Table.
In the Report Designer, you can specify or change these properties for each cell in either the Properties window, Format dialog box, or cell itself. A cell can have a corresponding, associated format that has the properties described in Table. The format set can be applied to multiple cells and does not have to be set for each individual cell separately. In the Report Designer, you make these settings in the Properties window. At run time, the row pattern is applied to the relevant rows of the report.
Properties of the Cell in a Row Pattern
In addition to the cell properties listed in Table, you can also use text properties to format the contents of a cell. You also use them to set or change the cell properties in the Report Designer. Table lists and describes these text properties.
You need to be aware of some other basic components for navigation and use of the Report Designer. You can use the drag-and-drop functionality to move report elements from the Field Catalog, Report Structure, and Format Catalog screen areas to the design area of the report. You can also use drag and drop to move cells and fields within the design area. Finally, you can use the context-sensitive menu in the design area, Report Structure, and Format Catalog to access various functions for creating reports.
Text Properties in the Report Designer Patterns
SAP BI Related Interview Questions
|SAP BO Interview Questions||SAP ABAP Interview Questions|
|SAP BW Interview Questions||SAP BPC Interview Questions|
|SAP BODS Interview Questions||SAP BDC Interview Questions|
|SAP BW on HANA Interview Questions||Sap Bapi Interview Questions|
|Sap Business One Interview Questions|
Sap Bi Tutorial
Bex Web Analyzer Reporting Functionality
Getting A Fast Start With Bi Patterns In The Bex Web Template
Basics Of The Web Application Designer
Advanced Configuration Using The Web Application Designer
Advanced Functionality Of The Report Designer
Developing Effective Web Reports
Developing High-impact Dashboards
Migrating 3.x To 7.0 Bex Web Reports And The Wad
Integration Of Sap Businessobjects Components Into The Bi Environment
All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.