SAP BI vs. R/3 Reporting

 

Many companies that use core SAP ERP modules never implement a SAP BI solution choosing instead to use R/3 based reporting.  Since R/3 is by nature a transactional OLTP system and was never designed for analytics and reporting and the importance of a unified view of a companies data it is somewhat surprising that more businesses haven't found, and leveraged the power of, SAP Business Intelligence.

Comparisons

R/3 Reporting

R/3 is an OLTP transactional system used for real-time operational data.  Reporting is only available from a single system and is transaction based.  R/3 reports are more likely to be broken as the system is highly changeable based on the needs of the business and will require ongoing maintenance and support costs.  Only limited web reporting is available and most reports are simple and list based.  Many users querying significant data volumes will slow down the system and disrupt the experience of the average user.

SAP BI Reporting

BW is an OLAP reporting system mainly used for summarized data rather, although drill down to line items is possible.  It houses historical data from multiple systems (including non SAP third party sources) and even data that no longer exists in the source systems.  SAP BI offers a wide range of data analysis tools including Excel and web based analysis, scorecards, dashboards  and pixel perfect static printed style reporting capabilities.  Most reports are not real-time but are a day or more old, for small data volumes near-time (<5 minute) reporting is possible.  Users querying the dedicated BI system will not slow down the source system and as the data is stored in a more optimal way the reports are available to the user much quicker. 
In addition to the reporting options it also provides ETL functions, better security, the option to 'broadcast' reports to users in a number of different ways and formats and allows planning based on historical data.

So in summary if you are faced with this decision consider these advantages that BI reporting has over R/3:

• By offloading ad-hoc and long running queries from production R/3 system to BI system, overall system performance should improve on R/3.
• SAP BI is specifically designed for query processing, not data updating and OLTP. Within BI, the data structures are designed differently and are much better suited for reporting than R/3 data structures.
• Better front-end reporting within BI. Although the BI Excel front-end has it's problems, it provides more flexibility and analysis capability than the R/3 reporting screens.
• BI has ability to pull data from other SAP or non-SAP sources into a consolidated cube

For up to the minute operational reporting you should use R/3 but for more historical strategic reporting a dedicated BI solution provides faster performing, fully featured reports with stronger data analysis capabilities. 

Creating a Process Chain

• Create a new Process Chain
• Define the Start Process
• Create a new Process Variant
• Define the Start Process Variant
• Define the start time
• Add an info package
• Select an info package
• Create a link between the Start Process and the info package
• Save and Activate the Process Chain

In SAP BW to create a Process Chain:

              Enter transaction code /nrspc.

1. The Process Chain Maintenance Planning View window opens.
   
   
2. Click the Create icon (or F5).
   The New Process Chain dialog opens.
3. Enter a Process Chain name and a Long Description. Click the Enter icon.
   After you specify the name of the new Process Chain, the Insert Start Process dialog opens. It lets you insert a Start Process for the Process Chain.
   
   
   
4. Define the Start Process. The Start Process must be unique for each Process Chain.
5. Create the Start Process Variant. A variant is a collection of predefined criteria, similar to a group of values used as parameters.
   Variants are attached to various processes that are defined for Process Chains. 
   Click the New icon on the Insert Start Process dialog to create a new Process Variant.
   The Start Process dialog opens.
   
   
   
6. Define the Start Process Variant. When the Maintain Process Variant dialog opens, create a variant for the start process by selecting Direct Scheduling. This allows you to customize the Start Timeoptions. Click Change Selections.
   The Start Time dialog opens.
   
   
   
   
   
           Enter a Start Time value by clicking the Immediate button, which   enables Immediate start. Click the Check button and Save.
7. Select the InfoPackage which is used to load data in Infocube, drag InfoPackage to right panel.Select the Info Package and press 'Continue 
8. Following steps will be added in the process chain 
9. Join 'Start' step with  'Load Step' by selecting 'Start' step and dragging the line to 'Load Step'pcc6
10. Check' the process chain and 'Activate' the process chain
11. Process chain will start executing.Once completed, the status will appear as follows, incase there is any failure, the status will appear as cancelled

General Usage/ Detail about Process Chain

• Process chain (PC) is a sequence of processes linked together.
• Each Process have a type (BW activity, e.g., activate ODS) and a variant (contains parameters).
• Start process describes when the process will start (immediately, scheduled job, metaprocess, API).
• Connector is linking processes; you can choose 1 of 3 options of starting next process: when previous finishes with success (green arrow), failure (red) or always start the next process (black).
• Variant is a set of parameters passed to the process, such as the name of the InfoPackage to use for loading, the name of the InfoObject to perform a change run for.

Selected icon bar buttons:

• Planning view enables to create and modify processes.
• Checking view checks consistency of a process chain selected in plan view.
• Log view shows log of the execution of a process chain selected in plan view.

The picture below shows simple PC (loading transaction data into ODS and than into InfoCube).

What is difference between PSA and ODS?

PSA: This is just an intermediate data container. This is NOT a data target. Main purpose/use is for data quality maintenance. This has the original data (unchanged) data from source system.


ODS: This is a data target. Reporting can be done through ODS. ODS data is overwriteable. For datasources for which delta is not enabled, ODS can be used to upload delta records to Infocube.  


You can do reporting in ODS. In PSA you can't do reporting directly


ODS contains detail -level data , PSA The requested data is saved, unchanged from the source system. Request data is stored in the transfer structure format in transparent, relational database tables in the Business Information Warehouse. The data format remains unchanged, meaning that no summarization or transformations take place
In ODS you have 3 tables Active, New data table, change log, In PSA you don't have

Difference Between PSA, ALE IDoc, ODS

What is difference between PSA and ALE IDoc?  And how data is transferd using each one of them?
The following update types are available in SAP BW:
1. PSA
2. ALE (data IDoc) 


You determine the PSA or IDoc transfer method in the transfer rule maintenance screen. The process for loading the data for both transfer methods is triggered by a request IDoc to the source system. Info IDocs are used in both transfer methods. Info IDocs are transferred exclusively using ALE
A data IDoc consists of a control record, a data record, and a status record The control record contains, for example, administrative information such as the receiver, the sender, and the client. The status record describes the status of the IDoc, for example, "Processed".  If you use the PSA for data extraction, you benefit from increased flexiblity (treatment of incorrect data records). Since you are storing the data temporarily in the PSA before updating it in to the data targets, you can check the data and change it if necessary. Unlike a data request with IDocs, the PSA gives you various options for additional data updates into data targets:


InfoObject/Data Target Only - This option means that the PSA is not used as a temporary store. You choose this update type if you do not want to check the source system data for consistency and accuracy, or you have already checked this yourself and are sure that you no longer require this data since you are not going to change the structure of the data target again.


PSA and InfoObject/Data Target in Parallel (Package by Package) - BW receives the data from the source system, writes the data to the PSA and at the same time starts the update into the relevant data targets.  Therefore, this method has the best performance.


The parallel update is described in detail in the following: A dialog process is started by   data package, in which the data of this package is writtein into the PSA table. If the data is posted successfully into the PSA table, the system releases a second, parallel dialog process that writes the data to the data targets. In this dialog process the transfer rules for the data records of the data package are applied, that data is transferred to the communcation structure, and then written to the data targets. The first dialog process (data posting into the PSA) confirms in the source system that is it completed and the source system sends a new data package to BW while the second dialog process is still updating the data into the data targets.
The parallelism relates to the data packages, that is, the system writes the data packages into the PSA table and into the data targets in parallel.  Caution: The maximum number of processes setin the source system in customizing for the extractors does not restrict the number of processes in BW. Therefore, BW can require many dialog processes for the load process. Ensure that there are enough dialog processes available in the BW system. If there are not enough processes on the system side, errors occur. Therefore, this method is the least recommended. 


PSA and then into InfoObject/Data Targets (Package by Package) - Updates data in series into the PSA table and into the data targets by data package. The system starts one process that writes the data packages into the PSA table. Once the data is posted successfuly into the PSA table, it is then written to the data targets in the same dialog process. Updating in series gives you more control over the overall data flow when compared to parallel data transfer since there is only one process per data package in BW. In the BW system the maximum number of dialog process required for each data request corresponds to the setting that you made in customizing for the extractors in the control parameter maintenance screen. In contrast to the parallel update, the system confirms that the process is completed only after the data has been updated into the PSA and also into the data targets for the first data package.
Only PSA - The data is not posted further from the PSA table immediately. It is useful to transfer the data only into the PSA table if you want to check its accuracy and consistency and, if necessary, modify the data. You then have the following options for updating data from the PSA table:


Automatic update - In order to update the data automatically in the relevant data target after all data packages are in the PSA table and updated successfully there, in the scheduler when you schedule the InfoPackage, choose Update Subsequently in Data Targets on the Processing tab page

AL08 (Tcode)- List of all users

AL08 shows the list of all the users who are logged on to the system globally or for all the instances in the system which are active. It shows all the active instances and number of active users in the system. It contains the following columns.


1) Instance - It shows the Instance into which the user logged in

2) Client - It displays the SAP client into which the user is Logged in

3) User Names - SAP user name

4) Terminal - Terminal at which the user is working

5) T-code - Last executed transaction code

6) Time - Time at which the user last initiated a dialog step by entering data

7) External Sessions - Number of External sessions the user has opened

8) Internal Sessions - Number of Internal sessions the user has opened

The Difference between External and Internal sessions

Internal Session: It is the memory allocated for a program during execution. When we call a program using SUBMIT or Call Transaction then it will be loaded in a new internal Session. To exchange the data between internal sessions we can use ABAP MEMORY.

External Session: It is nothing but a window. Which we can create using SYSTEM -> CREATE SESSION.
We can open up to 6 external sessions (this is set by Basis of course).
We can use SAP Memory to exchange the data between External sessions in a Login.

AP Q&A PART - 2

1. The following transactions are relevant to the data sources in an SAP BW source system. 
a. RSA3
b. RSA4
c. RSA5
d. RSA6 
ANSWER(S): A, C, D 
Transaction RSA3, or extractor checker, is used in the BW source system to check data sources for various extraction modes, including full update, delta update and delta initialization. 
RSA5 is for installing standard business content data sources and RSA6 is for maintaining data sources

2. True or False? A reference characteristic will use the SID table and master data table of the referred characteristic. 
a. True
b. False 
ANSWER(S): A 
If an info object is created as a characteristic with a reference characteristic, it won't have its own sid and master data tables. The info object will always use the tables of the referred characteristic. 

3. The following statements are not true about navigational attributes. 
a. An attribute of an info object cannot be made navigational if the attribute-only flag on the attribute info object has been checked.
b. Navigational attributes can be used to create aggregates.
c. It is possible to make a display attribute to navigational in an info cube data without deleting all the data from the info cube.
d. Once an attribute is made navigational in an info cube, it is possible to change it back to a display attribute if the data has been deleted from the info cube. 
ANSWER(S): D 
All the statements except D are true. It is possible to change a navigational attribute back to a display attribute in an info cube, without deleting all data from the info cube

4. True or False? It is possible to create a key figure without assigning currency or unit. 
a. True
b. False 
ANSWER(S): A 
Yes, it is possible to create a key figure without assigning a unit if the data type is one of these four: Number, Integer, Date or Time. 

5. The following statements are true for compounded info objects. 
a. An info cube needs to contain all info objects of the compounded info object if it has been included in the info cube.
b. An info object cannot be included as a compounding object if it is defined as an attribute only.
c. An info object can be included as an attribute and a compounding object simultaneously.
d. The total length of a compounded info object cannot exceed 60. 
ANSWER(S): A, B, D 
When a compounded info object is included in an info cube, all corresponding info objects are added to the info cube. If an info object is defined as an attribute, it cannot be included as compounding object. The total length of the compounding info objects cannot exceed 60 characters. 


6. The following statements are true for an info cube. 
a. Each characteristic of info cube should be assigned to at least one dimension.
b. One characteristic can be assigned to more than one dimensions.
c. One dimension can have more than one characteristic.
d. More than one characteristic can be assigned to one line item dimension. 
ANSWER(S): A, C 
Any characteristic in the info cube should be assigned to a dimension. One characteristic cannot be assigned to more than one dimension. One dimension can have more than one characteristic, provided it is not defined as a line item dimension.


7. The following statements are true for info cubes and aggregates. 
a. Requests cannot be deleted if info cubes are compressed.
b. A request cannot be deleted from an info cube if that request (is compressed) in the aggregates.
c. Deleting a request from the cube will delete the corresponding request from the aggregate, if the aggregate has not been compressed.
d. All of the above. 
ANSWER(S): A, C 
Once the info cubes are compressed it is not possible to delete data based on the requests. There won't be request IDs anymore. Requests can be deleted even if the requests in aggregates have been compressed. But the aggregates will have to be de-activated. Deleting an uncompressed request from an info cube will automatically delete the corresponding request from aggregate if the aggregate request has not been compressed

8. The following statements are true regarding the ODS request deletion. 
a. It is not possible to delete a request from ODS after the request has been activated.
b. Deleting an (inactive) request will delete all requests that have been loaded into the ODS after this request was loaded.
c. Deleting an active request will delete the request from the change log table.
d. None of the above. 
ANSWER(S): C 
It is possible to delete requests from an ODS, even if the request has been activated. The "before and after image" of the data will be stored in the change log table using which the request will be deleted. 
Deleting a request which has not been activated in ODS will not delete the requests which are loaded after this request. But if the request has been activated then the loaded and activated requests later will get deleted. Also the change log entries will be deleted for that request. 

9. The following statements are true for aggregates. 
a. An aggregate stores data of an info cube redundantly and persistently in a summarized form in the database.
b. An aggregate can be built on characteristics or navigational attributes from the info cube.
c. Aggregates enable queries to access data quickly for reporting.
d. None of the above. 
ANSWER(S): A, B, C 
Aggregates summarize and store data from an info cube. Characteristics and navigational attributes of an info cube can be used to create aggregates. Since aggregates contain summarized data, the amount of data in aggregates will be much less that the cube which makes the queries to run faster when they access aggregates. 

10. True or False? If an info cube has active aggregates built on it, the new requests loaded will not be available for reporting until the rollup has been completed successfully. 
a. True
b. False 
ANSWER(S): A 
Newly-loaded requests in an info cube with aggregates will not be available for reporting until the aggregate rollup has been completed successfully. This is to make sure that the cube and aggregates are consistent while reporting. 

11. What is the primary purpose of having multi-dimensional data models? 
a. To deliver structured information that the business user can easily navigate by using any possible combination of business terms to show the KPIs.
b. To make it easier for developers to build applications, that will be helpful for the business users.
c. To make it easier to store data in the database and avoid redundancy.
d. All of the above. 
ANSWER(S): A 
The primary purpose of multi-dimensional modeling is to present the business users in a way that corresponds their normal understanding of their business. They also provide a basis for easy access of data which is OLAP engine

12. The following statements are true for partitioning. 
a. If a cube has been partitioned, the E table of the info cube will be partitioned on time.
b. The F table of the info cube is partitioned on request.
c. The PSA table is partitioned automatically with several requests on one partition.
d. It is not possible to partition the info cube after data has been loaded, unless all the data is deleted from the cube. 
ANSWER(S): A, B, C, D, F 
BW allows partitioning of the info cubes based on time. If the info cube is partitioned, the e-fact table of the info cube will be partitioned on the time characteristic selected. 
The F fact table is partitioned on request ids automatically during the loads. PSA tables are also partitioned during the loads and can accommodate more than one request. For an info cube to be partitioned, all data needs to be removed from the info cube. 

13. The following statements are true for OLAP CACHE. 
a. Query navigation states and query results are stored in the application server memory.
b. If the same query has been executed by another user the result sets can be used if the global cache is active.
c. Reading query results from OLAP cache is faster than reading from the database.
d. Changing the query will invalidate the OLAP cache for that query. 
ANSWER(S): A, B, C, D 
Query results are stored in the memory of application server, which can be retrieved later by another user running the same query. This will make the query faster since the results are already calculated and stored in the memory. By changing the query, the OLAP Cache gets invalidated

14. The following statements are true about the communication structure. 
a. It contains all the info objects that belong to an info source.
b. All the data is updated into the info cube with this structure.
c. It is dependent on the source system.
d. All of the above. 
ANSWER(S): A, B 
The communication structure contains all info objects in the info source and it is used to update the info cube by temporarily storing the data that needs to be updates to the data target. It doesn't depend on the source system

15. The following statements are untrue about ODSs. 
a. It is possible to create ODSs without any data fields.
b. An ODS can have a maximum of 16 key fields.
c. Characteristics and key figures can be added as key fields in an ODS.
d. After creating and activating, an export data source is created automatically
ANSWER(S): A,C 
An ODS cannot be created without any data fields, and it can have a maximum of only 16 key fields. Key figures cannot be included as a key field in an ODS. The export data source is created after an ODS has been created and activated