ABAP REPORTS

ABAP TOPIC WISE COMPLETE COURSE

BDC OOPS ABAP ALE IDOC'S BADI BAPI Syntax Check
Interview Questions ALV Reports with sample code ABAP complete course
ABAP Dictionary SAP Scripts Script Controls Smart Forms
Work Flow Work Flow MM Work Flow SD Communication Interface

Sample SAP BW Report

The first step to access SAP BW reports is to start the BEX Browser. You will be prompted for your user name and password assigned by your SAP BW administrator.

Once SAP BW accepts your user name and password, the BEX Browser displays all reports and analytical applications for which you are authorized. On the left are the channels. Each channel contains one or more reports.

Figure below shows that you are in the General Purpose Channel; the title also shows the channel name. This channel has two clusters. Clusters are used to logically group a set of reports that address a similar subject area. This example uses Customer and Employee channels.

To launch an analytical application from the BEX Browser, simply right-click the report text, Sales Distribution by Employee, as shown in figure below. This action gives you several options, such as Execute, Preview, and Change. Select Execute to open the selected report.

Here you can drill down by product hierarchy as shown below or some other navigational attributes. You can also normalize data in several ways to meet your analytical needs.

Data ware house building statagies

Data ware house building statagies

Data Flow in SAP BW

When the user launches a report from BEX Explorer, it starts a BEX Analyzer session and opens an Excel workbook that contains an embedded BW query.

BEX Analyzer sends a request to the BW application server for relevant data. If this is a new query for a user, no data is found at the application server level. The query is then pushed further down to the database server to fetch a result set from an InfoCube or an aggregate associated with an InfoCube.

The database server fetches data from an InfoCube and hands it over to the application server, where it restructures the table-oriented data to a multidimensional structure, called a query cube, as shown below.

A query cube is the subset of an InfoCube, which is specified by the query. Some characteristics are restricted to specific values, whereas some are not chosen in the query. For this reason, the size of the query cube is much smaller than the actual InfoCube.

A query cube is unique to a user request and, hence, is not shared by other users. If several users start the same query, all will have their own unique query cubes built at the application server.

This is because the result set may vary based on selected dimensions or special filters. Also, each will have full control on how to navigate through the query cube (slicing and dicing) without interfering with analytical work done by others.

As the number of query cubes increases, the application server may run out of memory very quickly. For this reason, the application server for SAP BW requires more memory as compared to traditional SAP R/3 for OLTP instance. Moreover, the SAP BW application server needs more computer power due to data aggregations and computation requirements to satisfy end-user data analysis needs.

Once a query cube completes, a portion of data from the query cube is pushed up to load data in Microsoft Excel worksheets based on the current end user's data view.

Thenthe end user performs typical slice-and-dice and drill-down data analysis using BEX Analyzer functions. If the user needs additional drill-down data that is not presented at a given time, the request is sent to the query cube to send data in the spreadsheet for drill-down analysis.

If that detailed data is not in the query cube, the OLAP processor will refresh the query cube from the InfoCube. This navigational and data refresh process continues until the data requirements are met at each level.

A query cube always relates to only one InfoCube. In other words, you cannot build a query cube that gets data from more than one InfoCube.

SAP Data Warehouse Building Strategies

SAP customers have taken several approaches to building a data warehouse using R/3 technologies.

Database-Centric Data Warehouse:

In the database centric approach we have to make a copy of an R/3 database for users to report against. Conceptually, the idea is simple, but it is an operations keeping R/3 OLTP and R/3 reporting in synch is very difficult.

The benefit of this model is that you will have no performance degradation on your R/3 OLTP environment due to reporting and data analysis activities. We can define special user authorization and profiles for reporting users . This R/3 can also become the data source for intra-application data instead of OLTP R/3.

The problem in this approach is that we you have access to only the data that exists in the OLTP instance that is we have no historical data to report on. Moreover, we will face the same limitations and complexities of R/3 information systems and reporting tools that are not Web enabled. This database-centric approach will be an expensive proposition due to additional hardware and intense operations tasks to keep both instances operational at all times.

ALE-Centric Data Warehouse

In this model we do not copy a full database but rather use ALE to propagate specific changes into the reporting environment-another R/3 instance.

Based on the customer's business model, ALE packages transaction and/or master data in the form of Intermediate Documents (IDOCs). IDOCs are data containers similar to EDI standard documents. The figure below shows an example of how a MNC used this approach to implement an ALE-based reporting environment .

Here four individual R/3 instances were connected via ALE:

R/3 instance to manage master data.
R/3 instance for financial operations.
Instance for logistics operations.
Instance for reporting.

Under this model, special SIS structures and special ledger structures are transferred to reporting instances using ALE, copy management, and some homegrown techniques to synchronize objects across all instances. ALE copied new changes in the reporting instance at 10-minute intervals.

Additional SIS structures were updated within the reporting instance using copy management techniques to build additional tables containing several levels of aggregated data for reporting. This enabled end users to access near real-time data without impacting performance on the R/3 OLTP operations. For corporate central data warehouses, new data was extracted from the reporting instance instead of the R/3 OLTP instance.

The ALE centric reporting environment advantages:

Contains only that data required for reporting and analysis. It is not an identical copy of OLTP R/3 instances.
Can accumulate historical data.
Can import non-R/3 data for reporting.

The disadvantages of this environment are :

Has the same inflexible R/3 reporting tools.
Requires additional application servers to manage ALE traffic for all four instances.
ALE technology is not rich and mature enough to handle large data volumes and user-specific data objects.
Physical database implementation is still R/3-transaction-centric. Has no true multidimensional star data structures.
Is heavy on hardware/software/network resources.

Third-Party-Tool-Centric Data Warehouse:

Third-party data extraction tools work to a point when transaction and associated data volume is small and business rules/configuration behind such data sets is simple. Some data extraction tools extract data at the database level, leaving critical data behind in pool and cluster tables

Often, the ABAP code generated by these tools is not optimized enough to fetch and transport data in the most efficient manner. One of the major problems in implementing a third-party solution is that the OLTP and data warehouse/OLAP teams do not share the same infrastructure.