Tuesday, July 28, 2009

How to improve FI_GL_4 data extract

When a Delta InfoPackage for the DataSource 0FI_GL_4 is executed in SAP NetWeaverBI (BI), the extraction process in the ECC source system mainly consists of two activities:- First the FI extractor calls a FI specific function module which reads the new andchanged FI documents since the last delta request from the application tablesand writes them into the Delta Queue.- Secondly, the Service API reads the delta from the Delta Queue and sends the FIdocuments to BI.





The time consuming step is the first part. This step might take a long time to collect allthe delta information, if the FI application tables in the ECC system contain many entriesor when parallel running processes insert changed FI documents frequently.

A solution might be to execute the Delta InfoPackage to BI more frequently to processsmaller sets of delta records. However, this might not be feasible for several reasons:First, it is not recommended to load data with a high frequency using the normalextraction process into BI. Second, the new Real-Time Data Acquisition (RDA)functionality delivered with SAP NetWeaver 7.0 can only be used within the newDataflow. This would make a complete migration of the Dataflow necessary. Third, as ofnow the DataSource 0FI_GL_4 is not officially released for RDA.To be able to process the time consuming first step without executing the deltaInfoPackage the ABAP report attached to this document will execute the first step of theextraction process encapsulated. The ABAP report reads all the new and changeddocuments from the FI tables and writes them into the BI delta queue. This report can bescheduled to run frequently, e.g. every 30 minutes.The Delta InfoPackage can be scheduled independently of this report. Most of the deltainformation will be read from the delta queue then. This will greatly reduce the number ofrecords the time consuming step (First part of the extraction) has to process from the FIapplication as shown in the picture below.






The Step By Step Solution4.
1 Implementation DetailsTo achieve an encapsulated first part of the original process, the attached ABAP report iscreating a faked delta initialization for the logical system 'DUMMY_BW'. (This system can be named anything as long as it does not exist.) This will create two delta queues for the0FI_GL_4 extractor in the SAP ERP ECC system: One for the ‘DUMMY_BW’ and theother for the 'real' BI system.The second part of the report is executing a delta request for the ‘DUMMY_BW’ logicalsystem. This request will read any new or changed records since the previous deltarequest and writes them into the delta queues of all connected BI systems.The reason for the logical BI system ‘DUMMY_BW’ is that the function module used inthe report writes the data into the Delta Queue and marks the delta as already sent tothe ‘DUMMY_BW’ BI system.This is the reason why the data in the delta queue of the ‘DUMMY_BW’ system is notneeded for further processing. The data gets deleted in the last part of the report.The different delta levels for different BI systems are handled by the delta queue and areindependent from the logical system.Thus, the delta is available in the queue of the 'real' BI system, ready to be sent duringthe next Delta InfoPackage execution.This methodology can be applied to any BI extractors that use the delta queuefunctionality.As this report is using standard functionality of the Plug-In component, the handling ofdata request for BI has not changed. If the second part fails, it can be repeated. Thecreation & deletion of delta-initializations is unchanged also.The ABAP and the normal FI extractor activity reads delta sequential. The data is sentto BI parallel.If the report is scheduled to be executed every 30 minutes, it might happen that itcoincides with the BI Delta InfoPackage execution. In that case some records will bewritten to the delta queues twice from both processes.This is not an issue, as further processing in the BI system using a DataStore Object withdelta handling capabilities will automatically filter out the duplicated records during thedata activation. Therefore the parallel execution of this encapsulated report with the BIdelta InfoPackage does not cause any data inconsistencies in BI. (Please refer also toSAP Note 844222.)

4.2 Step by Step Guide1. Create a new Logical System usingthe transaction BD54.This Logical System name is used inthe report as a constant:c_dlogsys TYPE logsys VALUE 'DUMMY_BW'In this example, the name of theLogical System is ‘DUMMY_BW’.The constant in the report needs tobe changed accordingly to thedefined Logical System name in thisStep.

. Implement an executable ABAPreportYBW_FI_GL_4_DELTA_COLLECTin transaction SE38.The code for this ABAP report canbe found it the appendix.

3. Maintain the selection texts of thereport.In the ABAP editorIn the menu, choose Goto 􀃆 TextElements 􀃆 Selection Texts

. Maintain the text symbols of thereport.In the ABAP editorIn the menu, choose Goto 􀃆 TextElements 􀃆 Text Symbols

5. Create a variant for the report. The"Target BW System" has to be anexisting BI system for which a deltainitialization exists.In transaction SE38, click Variants6. Schedule the report via transactionSM36 to be executed every 30minutes, using the variant created instep 5.

Code
This report collects new and changed documents for the 0FI_GL_4 from*& the FI application tables and writes them to the delta queues of all*& connected BW system.*&*& The BW extractor itself therefore needs only to process a small*& amount of records from the application tables to the delta queue,*& before the content of the delta queue is sent to the BW system.


*&---------------------------------------------------------------------*REPORT ybw_fi_gl_4_delta_collect.TYPE-POOLS: sbiw.* Constants* The 'DUMMY_BW' constant is the same as defined in Step 1 of the How to guideCONSTANTS: c_dlogsys TYPE logsys VALUE 'DUMMY_BW',c_oltpsource TYPE roosourcer VALUE '0FI_GL_4'.* Filed symbols.

FIELD-SYMBOLS:

DATA: l_slogsys TYPE logsys,
l_tfstruc TYPE rotfstruc,
l_lines_read TYPE sy-tabix,
l_subrc TYPE sy-subrc
,l_s_rsbasidoc TYPE rsbasidoc,
l_s_roosgen TYPE roosgen,
l_s_parameters TYPE roidocprms,
l_t_fields TYPE TABLE OF rsfieldsel,
l_t_roosprmsc TYPE TABLE OF roosprmsc,
l_t_roosprmsf TYPE TABLE OF roosprmsf.
* Selection parameters

SELECTION-SCREEN: BEGIN OF BLOCK b1 WITH FRAME TITLE text-001.
SELECTION-SCREEN SKIP
1.PARAMETER prlogsys LIKE tbdls-logsys OBLIGATORY.SELECTION-SCREEN:
END OF BLOCK b1.AT SELECTION-SCREEN.

* Check logical systemSELECT COUNT * FROM tbdls BYPASSING BUFFERWHERE logsys = prlogsys.IF sy-subrc <> 0.MESSAGE e454(b1) WITH prlogsys.* The logical system & has not yet been definedENDIF.



* Get own logical systemCALL FUNCTION 'RSAN_LOGSYS_DETERMINE'EXPORTINGi_client = sy-mandtIMPORTINGe_logsys = l_slogsys.* Check if transfer rules exist for this extractor in BWSELECT SINGLE * FROM roosgen INTO l_s_roosgenWHERE oltpsource = c_oltpsourceAND rlogsys = prlogsysAND slogsys = l_slogsys.IF sy-subrc <> 0.

MESSAGE e025(rj) WITH prlogsys.* No transfer rules for target system &ENDIF.* Copy record for dummy BW systeml_s_roosgen-rlogsys = c_dlogsys.MODIFY roosgen FROM l_s_roosgen.IF sy-subrc <> 0.MESSAGE e053(rj) WITH text-002.* Update of table ROOSGEN failedENDIF.


* Assignment of source system to BW systemSELECT SINGLE * FROM rsbasidoc INTO l_s_rsbasidocWHERE slogsys = l_slogsysAND rlogsys = prlogsys.IF sy-subrc <> 0 OR( l_s_rsbasidoc-objstat = sbiw_c_objstat-inactive ).MESSAGE e053(rj) WITH text-003.* Remote destination not validENDIF.


* Copy record for dummy BW systeml_s_rsbasidoc-rlogsys = c_dlogsys.MODIFY rsbasidoc FROM l_s_rsbasidoc.IF sy-subrc <> 0.MESSAGE e053(rj) WITH text-004.* Update of table RSBASIDOC failedENDIF.


* Delta initializationsSELECT * FROM roosprmsc INTO TABLE l_t_roosprmscWHERE oltpsource = c_oltpsourceAND rlogsys = prlogsysAND slogsys = l_slogsys.IF sy-subrc <> 0.MESSAGE e020(rsqu).* Some of the initialization requirements have not been completedENDIF.

LOOP AT l_t_roosprmsc ASSIGNING .IF -initstate = ' '.MESSAGE e020(rsqu).* Some of the initialization requirements have not been completedENDIF.-rlogsys = c_dlogsys.-gottid = ''.-gotvers = '0'.-gettid = ''.-getvers = '0'.ENDLOOP.

* Delete old records for dummy BW systemDELETE FROM roosprmscWHERE oltpsource = c_oltpsourceAND rlogsys = c_dlogsysAND slogsys = l_slogsys.

* Copy records for dummy BW systemMODIFY roosprmsc FROM TABLE l_t_roosprmsc.IF sy-subrc <> 0.MESSAGE e053(rj) WITH text-005.* Update of table ROOSPRMSC failedENDIF.* Filter values for delta initializationsSELECT * FROM roosprmsf INTO TABLE l_t_roosprmsfWHERE oltpsource = c_oltpsourceAND rlogsys = prlogsysAND slogsys = l_slogsys.IF sy-subrc <> 0.MESSAGE e020(rsqu).


* Some of the initialization requirements have not been completedENDIF.LOOP AT l_t_roosprmsf ASSIGNING .-rlogsys = c_dlogsys.ENDLOOP.* Delete old records for dummy BW systemDELETE FROM roosprmsfWHERE oltpsource = c_oltpsourceAND rlogsys = c_dlogsysAND slogsys = l_slogsys.* Copy records for dummy BW systemMODIFY roosprmsf FROM TABLE l_t_roosprmsf.IF sy-subrc <> 0.MESSAGE e053(rj) WITH text-006.* Update of table ROOSPRMSF failedENDIF.


**************************************
COMMIT WORK for changed meta data
**************************************
COMMIT WORK.* Delete RFC queue of dummy BW system* (Just in case entries of other delta requests exist)CALL FUNCTION 'RSC1_TRFC_QUEUE_DELETE_DATA'
EXPORTING
i_osource = c_oltpsource
i_rlogsys =
c_dlogsysi_all = 'X'
EXCEPTIONS
tid_not_executed = 1
tid_not_executed = 1
client_not_found = 3

error_reading_queue = 4

OTHERS = 5.

IF sy-subrc <> 0.
MESSAGE ID sy-msgid TYPE sy-msgty NUMBER sy-msgnoWITH sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4.ENDIF.

********************************************
COMMIT WORK for deletion of delta queue
********************************************
COMMIT WORK.
* Get MAXLINES for data package
CALL FUNCTION 'RSAP_IDOC_DETERMINE_PARAMETERS'
EXPORTINGi_oltpsource = c_oltpsourcei_slogsys = l_slogsysi_rlogsys = prlogsysi_updmode = 'D 'IMPORTINGe_s_parameters = l_s_parameterse_subrc = l_subrc.

.IF l_subrc <> 0.MESSAGE e053(rj) WITH text-007.* Error in function module RSAP_IDOC_DETERMINE_PARAMETERSENDIF.* Transfer structure depends on transfer methodCASE l_s_roosgen-tfmethode.WHEN 'I'.

l_tfstruc = l_s_roosgen-tfstridoc.WHEN 'T'.l_tfstruc = l_s_roosgen-tfstruc.ENDCASE.* Determine transfer structure field listPERFORM fill_field_list(saplrsap) TABLES l_t_fieldsUSING l_tfstruc.* Start the delta extraction for the dummy BW systemCALL FUNCTION 'RSFH_GET_DATA_SIMPLE'

EXPORTINGi_requnr = 'DUMMY'i_osource = c_oltpsourcei_showlist = ' 'i_maxsize = l_s_parameters-maxlinesi_maxfetch = '9999'i_updmode = 'D 'i_rlogsys = c_dlogsysi_read_only = ' 'IMPORTING

e_lines_read = l_lines_readTABLESi_t_field = l_t_fieldsEXCEPTIONSgeneration_error = 1interface_table_error = 2metadata_error = 3error_passed_to_mess_handler = 4no_authority = 5OTHERS = 6.IF sy-subrc <> 0.MESSAGE ID sy-msgid TYPE sy-msgty NUMBER sy-msgnoWITH sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4.ENDIF.

*********************************
COMMIT WORK for delta request
**********************************
COMMIT WORK.
** Delete RFC queue of dummy BW systemCALL FUNCTION 'RSC1_TRFC_QUEUE_DELETE_DATA'EXPORTINGi_osource = c_oltpsourcei_rlogsys = c_dlogsysi_all = 'X'EXCEPTIONStid_not_executed = 1invalid_parameter = 2client_not_found = 3error_reading_queue = 4OTHERS = 5.IF sy-subrc <> 0.MESSAGE ID sy-msgid TYPE sy-msgty NUMBER sy-msgnoWITH sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4.ENDIF.* Data collection for 0FI_GL_4 delta queue successfulMESSAGE s053(rj) WITH text-008.

Publish exceptions

Publish exceptions


1.create query with exceptions
2.use central alert framwork:

.T-code ALRTCATDEF
.create alert category
.create containor element
.create text for alert message



.Then you can enter a text and a URL for a subsequent activity (optionally). E.g. you can add a link to a BI Query which should be checked by the recipient in order to react to the alert.

.In the last step of the alert category configuration you have to assign the alert to the end users. You can enter fixed recipients or roles. If you enter a role, all users that are assigned to that role will get the alert. You can also enter roles, if you press the button "Subscription Authorization". In that case the assigned users will have the option to subscribe for the alert later.

.In the next step you have to call the BEx Broadcaster and create an Information broadcasting setting based on the query, on which the exception has been defined on. As distribution type you have to choose "Distribute according to exceptions". In the details you can either choose the distribution type "Send Email" or "Create Alert", if you want to distribute the alert via the Universal Worklist. As selection criterion you can either choose to distribute all exceptions or you can choose a specific alert level. In our example we only want to distribute alerts, which have the level "Bad 3".

.Then you have to assign the corresponding alert category you have created before to your Information broadcasting setting.

.In the next step you have to do the mapping between the BI parameters of the Query and the alert container elements. These parameters will then be passed over to the alert.

.In the last step you have to save the Information Broadcasting setting. You can execute the setting directly or you can schedule the execution e.g. periodically each week.

.As a result you will see 2 new alerts in the Universal Worklist for all users which have been assigned to the alert corresponding alert category. You can access the Universal Worklist in the Enterprise Portal: Business Intelligence 􀃆Business Explorer 􀃆 Universal Worklist.



about DTP

DTP


.default It is recommended to configure the DTP with upload mode “Delta”. The deletion of the PSA data is necessary before each data load, if a “Full” DTP is used. A Full DTP extracts all Requests from the PSA regardless if the data has been already loaded or not. This means the Delta upload via a DTP from the DataSource (PSA) in the InfoCube is necessary, even if the data is loaded via a Full upload from the Source to the DataSource (PSA) by using an InfoPackage. ( which means load from PSA via DTP will load all data from PSA no matter the data were loaded before or not,so eother PSA should delted after load ,or DTP use delta even laod form Data source to PSA use delta already)
.Only get Delta Once:
.Get Data by Request: get the oldest request
.Get runtime information of a Data Transfer Process (DTP) in a Transformation : I will give detail in another blog .
.Debug a Data Transfer Process (DTP) Request:The debugging expert mode can be started from the execute tab of the DTP. The “Expert Mode” flag appears when the Processing Mode “Serially in the Dialog Process (for Debugging)” is selected.Choose “Simulate” to start the Debugger in expert mode.The debugging for loaded data can be executed from the DTP Monitor directly.Choose “Debugging”.

Thursday, April 30, 2009

SAP Business Warehouse Topics

SAP Business Warehouse Topics

1. Fundamentals: What is NetWeaver? What is BI? What is SAP BW or Business Information Warehouse? What is SAP R3? Decision support in an Enterprise. Decision support v/s Operational Reporting. OLTP v/s OLAP. Fundamentals about working of SAP R3. Fundamentals aboutworking of SAP BW.

2. Functions of BW: Reporting (Decision Support and Operational), Open Hub (Supply Data to External Applications), Planning (Business Planning and Simulation – BPS). SEM–BPS is now BW-BPS. BW as EDW (Enterprise Data Warehouse).

3. Data Modeling: Data modeling concepts. Concepts behind various Data Models used in OLTP and OLAP. Why different Data Models? MDM v/s ERM. Extended Star Schema used in SAP BW.

4. SAP BW Terminology: Communication Structure in SAP R3, Extract Structure, User Exit, Transfer Structure, Datasource, Source System, PSA, Transfer rules, Communication Structure in BW, Update Rules, Infocube, ODS (Operational Data Store), Infoobject, Master Data(Attributes, Texts and Hierarchies), Characteristics and Key Figures, Infoprovider, Datatarget, Infoprovider v/s Datatarget, Infoarea, Application Components, Administrator Work Bench, Multiprovider, Infoset, Bex Query, Infoset Query, Classic Infoset.

5. Data Flow: How the data flows from Source System in to BW? Data Flow Diagram for SAP R3 OLTP System to SAP BW. Types of Updates – Direct v/s Flexible. How the elements described above are used in Data Flow?

6. Infoobject: How to create Infoobject? Types of Infoobjects. Characteristics and Key Figures, Master Data, Special types (Unit/Currency, Date), Data Structures in Infoobject. How to Load Data in to Infoobject? How is the Infoobject used in Reporting? Global Transfer Routine – How to use Global Transfer Routine? Why it is used. Management of overlapping Master Data fromMultiple Sources. Creating Direct Update Infosources Automatically. Infoobject as Infoprovider.

7. Types of Updates: Additive, Overwrite. Where to maintain update type for Datasource? Which objects use these update types (ODS/Infocube?Master Data)?

8. Infocube: How to create an Infocube? Types of Infocubes (Transactional, Basic, Remote/Virtual), Data Structures in an Infocube. Update types for Infocube. How is the data updated in the Infocube? Virtual Key Figures.

9. ODS Object: How to Create ODS Object? Structure of ODS Object. Updste types in ODS Object. Update Mechanism. Data structures in an ODS Object.

10. Infosource: Creating Infosource, Update and Transfer Rules, Update Routine, Transfer Routine, Start Routine, Start up Routine.

11. AWB – Administrator Work Bench: Functions of AWB – Modeling, Monitoring, Reporting Agent, Transport Connection, Documents, Business Content, Translation, Metadata Repository.

12. Transports: How transports work in BW. How to create Transports? Efficient ways to create Transports in Different Scenarios.

13. Business Content: Standard Business Content in R3 and BW. Transferring Datasources and Application Component Hierarchy in R3. Replication of Datasources. Activation of Business Content. How to Activate Business Content – various Scenarios.

14. Data Extraction Using Flat Files: How to generate Transfer Structure from Communication Structure? Loading Data using Flat File.

15. Data Extraction from SAP R3 – Data Collection: Transaction Processing in SAP R3. Update types in SAP R3. How “Delta” is managed? V3 Control. Direct and Queued Delta. Update Mechanism in SAP R3. Manipulation of Data in SAP R3. Transaction User Exits, LIS User Exits.BW User Exits.

16. Data Extraction from SAP R3 –Application Specific: Infrastructure needed for loading data – Datasource, LO-Cockpit Datasources, CO_PA, FI-SL, FI_Line Item Extraction, LIS Extraction.

17. LO-Cockpit Extraction: Demonstrate each step in data extraction by performing transactions in SAP R3.

18. Data Extraction from SAP R3 – Generic: How to Create Generic Datasource? Delta Management. Generic Delta.

19. Data Extraction from SAP R3 – Maintain Datasource: What is - Direct Access, Delta, Inversion, Selection, Field only…, Hide. How to Maintain Datasource?

20. Data Extraction from SAP R3 – Modifying Data: Manipulation of Transaction Data / Master Data / Texts / Hierarchies. How to program in User Exit? Concept of Project. Function Modules used for Data Manipulation.

21. Modify Datasource: Demo the process of modifying Master Data Source by adding additional field and filling it with Data in BW.

22. Data Extraction from XML Source: XML Integration, Creating Flat File Datasource and generating Myself Datasource. Create and Maintain “Delta Queue” in BW System.

23. DB Connect: Concepts.

24. Data Mart Interface: Extraction within BW System. ODS to ODS, ODS to Infocube and Infocube to Infocube Extraction.

25. Open Hub Services: Infospoke, Create and Schedule Infospoke. BW as Open Hub or Data Hub.

26. Performance Management: How to improve performance of Data Load and Query?
Partitioning. Indexes in Infocubes and ODS’s. Aggregates on Infocubes. Compression.

27. Production Support: Monitoring Jobs, Process Chains, Event Chains, Infopackage Groups, Creating and Triggering Events, Common Problems, How to Fix them.

28. BW Presentation – Queries: Bex Analyzer, Query Designer, Queries in standard Excel Front end, Functions, Formulas, Calculated and Restricted Key Figures, Tabular Display. Query Views. Exception Reporting.

29. Web Interface: Launching Queries in Web Front end. Building simple Web site for launching Queries.

30. Web Application Designer: Web Templates. Creating Web Template with Company Logo. Adding more than one Query in a Web Page.

31. Reporting Agent: Demo - Scheduling a Query with exceptions to run at certain time and send e-mail with the result as attachment.

32. Report to Report Interface: Also known as RRI or Query Jump. Jump from Aggregate to Detailed Query with selections from the Aggregate Query.

Comparing/Limitation of SAP R/3 Reporting Systems

Comparing/Limitation of SAP R/3 Reporting Systems

Comparingof SAP R/3 Reporting Systems
Common feature among R/3 reporting systems is that they all collect data in special data tables. This is a preferred method for operational reporting due to real-time data acquisition from linked SAP modules. Several reporting systems derive data based on update rules.

External data can also be imported in the reporting information structures for consolidated information view.

These information systems use a variety of tools for presentation and analysis such as ABAP, ABAP Query, Report Writer/Painter, and LIS.

All information systems require in-depth R/3 configuration knowledge.

This is the most important reason that reporting requirements must be a part of overall OLTP business workflow-business rules.

Using linked SAP modules requires absolute integration with process configuration teams. The process requirements must be stable, because the workflow determines what data is captured based on a variety of states and conditions defined to meet business operations and analysis requirements.

SAP R/3 is primarily designed for a high transaction rate. Information processing in an OLTP and a data warehouse are very different. A few differentiating characteristics between an OLTP and a data warehouse are listed in Table 2-1. Data warehouses require a very different configuration due to large data volume and unpredictable data navigation schemes. It is impossible to configure an OLTP system as a full-featured data warehouse without having an impact on OLTP operations. Therefore, the nature of reporting on OLTP systems must be limited to support real-time operations and not historical reporting. The next section addresses reporting issues associated with R/3 information systems.


Limitation of SAP R/3 Reporting Systems

One of the hardest tasks in developing a reporting environment in R/3 is selecting one data access and analysis tool that satisfies end-user needs. The following are the major shortfalls of native SAP R/3 reporting:

• Information on existing reports is either missing or unclear. Searching a report among thousands of available reports in R/3 is a big problem. The Report Navigator, developed by SAP's Simplification Group, is a good attempt to solve this problem.

• Available reports are designed to meet operational and transactional information needs. Most reports are predefined, list oriented, and provide very limited OLAP functionality.

• Several reporting modules and associated reporting tools make it hard to select a specific tool. Reporting tools are inconsistent, and designing reports is a complex process. Maintenance of thousands of reports for software upgrades is a huge challenge. Knowledge of how often a report is used is not available, such as which reports are frequently used or ever used. As a consequence, all reports need to be maintained regardless of their usage. Recently, SAP has provided utilities to track report-usage statistics that will help identify which reports are to be upgraded or dropped in a release upgrade or support.

• Fragmented reporting menu access requires extensive end-user training to navigate through
several multi-level menus to display a few reports.

• Performance impact on R/3 OLTP operations due to reporting is another major issue. The R/3 systems are configured to provide high OLTP transaction rates. Building a robust reporting and OLAP environment under an OLTP environment requires different configuration parameters that will degrade OLTP operations. See Table 2-1, which lists the common differences between OLTP and Reporting/OLAP environments.

To overcome OLTP and reporting co-existence problems, several customers have attempted to build a separate R/3 environment dedicated to reporting. I discuss a few such models in the next section. But first, I'd like to look at how SAP planned to re-architect R/3 application components in the early '90s.

Application architects at SAP planned to break down the traditional SAP R/3 very tightly integrated application modules into several loosely coupled applications; these applications would still be connected to each other by use of Application Link Enabling (ALE) technology (ALE is SAP's EDI-like middleware. I discuss ALE in much more detail in the next few sections.). This new distributed application concept became what is known as SAP Business Framework Architecture, as shown in Figure 2-4. Due to the mySAP.com initiative, the SAP Business Framework today looks quite different from when it was proposed in the early 1990s, as shown in Figure 2-4.

However, the core concept behind the SAP Business Framework remains the same-loosely coupled business components. The only difference is that today the integration technologies are becoming Internet-centric, replacing pure ALE and new business components to support business to business (B2B), business to customer (B2C), Customer Relationship Management (CRM), and business intelligence, and have taken higher priority than breaking SAP R/3 modules into individual stand-alone applications.

SAP BW Glossary

SAP BW Glossary
Aggregate
An aggregate is a subset of an InfoCube. The objective when using aggregates is to reduce I/O volume. The BW OLAP processor selects an appropriate aggregate during a query run or a navigation step. If no appropriate aggregate exists, the BW OLAP processor retrieves data from the original InfoCube instead.

Aggregate rollup
Aggregate rollup is a procedure to update aggregates with new data loads.

Application component
Application components are used to organize InfoSources. They are similar to the InfoAreas used with InfoCubes. The maximum number of characters allowed for the technical name is 32.

Authorization
An authorization defines what a user can do, and to which SAP objects. For example, a user with an authorization can display and execute, but not change, a query. Authorizations are defined using authorization objects.

Authorization object
An authorization object is used to define user authorizations. It has fields with values to specify authorized activities, such as display and execution, on authorized business objects, such as queries. The maximum number of characters allowed for the technical name is 10.

Authorization profile
An authorization profile is made up of multiple authorizations. The maximum number of characters allowed for the technical name is 10.

Bitmap index
A bitmap index uses maps of bits to locate records in a table. Bitmap indices are very effective for Boolean operations of the WHERE clause of a SELECT statement. When the cardinality of a column is low, a bitmap index size will be small, thereby reducing I/O volume.

Business Content
Business Content is a complete set of BW objects developed by SAP to support the OLAP tasks. It contains roles, workbooks, queries, InfoCubes, key figures, characteristics, update rules, InfoSources, and extractors for SAP R/3, and other mySAP solutions.

BW
BW is a data warehousing solution from SAP.

BW Monitor
BW Monitor displays data loading status and provides assistance in troubleshooting if errors occur.

BW Scheduler
BW Scheduler specifies when to load data. It is based on the same techniques used for scheduling R/3 background jobs.

BW Statistics
BW Statistics is a tool for recording and reporting system activity and performance information.
Change run
Change run is a procedure used to activate characteristic data changes.

Characteristic
Characteristics are descriptions of key figures, such as Customer ID, Material Number, Sales Representative ID, Unit of Measure, and Transaction Date. The maximum number of characters allowed for the technical name is 9.

Client
A client is a subset of data in an SAP system. Data shared by all clients is called client-independent data, as compared with client-dependent data. When logging on to an SAP system, a user must specify which client to use. Once in the system, the user has access to both client-dependent data and client-independent data.

Communication structure
The communication structure is the structure underlying the InfoSource.

Compound attribute
A compound attribute differentiates a characteristic to make the characteristic uniquely identifiable. For example, if the same characteristic data from different source systems mean different things, then we can add the compound attribute 0SOURSYSTEM (source system ID) to the characteristic; 0SOURSYSTEM is provided with the Business Content.

Data packet size
For the same amount of data, the data packet size determines how work processes will be used in data loading. The smaller the data packet size, the more work processes needed.

Data Warehouse
Data Warehouse is a dedicated reporting and analysis environment based on the star schema database design technique and requiring special attention to the data ETTL process.

DataSource
A DataSource is not only a structure in which source system fields are logically grouped together, but also an object that contains ETTL-related information. Four types of DataSources exist:
DataSources for transaction data
DataSources for characteristic attributes
DataSources for characteristic texts
DataSources for characteristic hierarchies
If the source system is R/3, replicating DataSources from a source system will create identical DataSource structures in the BW system. The maximum number of characters allowed for a DataSource's technical name is 32.

Delta update
The Delta update option in the InfoPackage definition requests BW to load only the data that have been accumulated since the last update. Before a delta update occurs, the delta process must be initialized.

Development class
A development class is a group of objects that are logically related.

Display attribute
A display attribute provides supplemental information to a characteristic.

Drill-down
Drill-down is a user navigation step intended to get further detailed information.

ETTL
ETTL, one of the most challenging tasks in building a data warehouse, is the process of extracting, transforming, transferring, and loading data correctly and quickly.

Free characteristic
A free characteristic is a characteristic in a query used for drill-downs. It is not displayed in the initial result of a query run.

Full update
The Full update option in the InfoPackage definition requests BW to load all data that meet the selection criteria specified via the Select data tab.

Generic data extraction
Generic data extraction is a function in Business Content that allows us to create DataSources based on database views or InfoSet queries. InfoSet is similar to a view but allows outer joins between tables.

Granularity
Granularity describes the level of detail in a data warehouse. It is determined by business requirements and technology capabilities.

IDoc
IDoc (Intermediate Document) is used in SAP to transfer data between two systems. It is a specific instance of a data structure called the IDoc Type, whose processing logic is defined in the IDoc Interface.

Index
An index is a technique used to locate needed records in a database table quickly. BW uses two types of indices: B-tree indices for regular database tables and bitmap indices for fact tables and aggregate tables.

InfoArea
InfoAreas are used to organize InfoCubes and InfoObjects. Each InfoCube is assigned to an InfoArea. Through an InfoObject Catalog, each InfoObject is assigned to an InfoArea as well. The maximum number of characters allowed for the technical name is 30.

InfoCube
An InfoCube is a fact table and its associated dimension tables in the star schema. The maximum number of characters allowed for the technical name is 30.

InfoCube compression
InfoCube compression is a procedure used to aggregate multiple data loads at the request level.

InfoObject
In BW, key figures and characteristics are collectively called InfoObjects.

InfoObject Catalog
InfoObject Catalogs organize InfoObjects. Two types of InfoObject Catalogs exist: one for characteristics, and one for key figures. The maximum number of characters allowed for the technical name is 30.

InfoPackage
An InfoPackage specifies when and how to load data from a given source system. BW generates a 30-digit code starting with ZPAK as an InfoPackage's technical name.

InfoSource
An InfoSource is a structure in which InfoObjects are logically grouped together. InfoCubes and characteristics interact with InfoSources to get source system data. The maximum number of characters allowed for the technical name is 32.

Key figure
Key figures are numeric values or quantities, such as Per Unit Sales Price, Quantity Sold, and Sales Revenue. The maximum number of characters allowed for the technical name is 9.

Line item dimension
A line item dimension in a fact table connects directly with the SID table of its sole characteristic.

Logical system
A logical system is the name of a client in an SAP system.

Multi-cube
A multi-cube is a union of basic cubes. The multi-cube itself does not contain any data; rather, data reside in the basic cubes. To a user, the multi-cube is similar to a basic cube. When creating a query, the user can select characteristics and key figures from different basic cubes.

Navigational attribute
A navigational attribute indicates a characteristic-to-characteristic relationship between two characteristics. It provides supplemental information about a characteristic and enables navigation from characteristic to characteristic during a query.

Number range
A number range is a range of numbers that resides in application server memory for quick number assignments.

ODS
ODS is a BW architectural component located between PSA and InfoCubes that allows BEx reporting. It is not based on the star schema and is used primarily for detail reporting, rather than for dimensional analysis. ODS objects do not aggregate data as InfoCubes do. Instead, data are loaded into an ODS object by inserting new records, updating existing records, or deleting old records, as specified by the 0RECORDMODE value.

Parallel query
A parallel query uses multiple database processes, when available, to execute a query.

Partition
A partition is a piece of physical storage for database tables and indices. If the needed data reside in one or a few partitions, then only those partitions will be selected and examined by a SQL statement, thereby significantly reducing I/O volume.

Profile Generator
Profile Generator is a tool used to create authorization profiles.

PSA
PSA is a data staging area in BW. It allows us to check data in an intermediate location, before the data are sent to its destinations in BW.

Query
A BW query is a selection of characteristics and key figures for the analysis of the data in an InfoCube. A query refers to only one InfoCube, and its result is presented in a BEx Excel sheet. The maximum number of characters allowed for the technical name is 30.

Read mode
Read mode for a query determines the size and frequency of data retrievals from database: all data at once, as needed per navigation step, or as needed per hierarchy node.

Reconstruct
Reconstruct is a procedure used to restore load requests from PSA.

Request
A request is a data load request from BW Scheduler. Each time that BW Scheduler loads data into an InfoCube, a unique request ID is created in the data packet dimension table of the InfoCube.

RFC
RFC (Remote Function Call) is a call to a function module in a system different from the caller's—usually another SAP system on the local network.

Role
In Profile Generator, an authorization profile corresponds to a role. A user assigned to that role also has the corresponding authorization profile. A user can be assigned to multiple roles. The maximum number of characters allowed for the technical name is 30.

SID
SID (Surrogate-ID) translates a potentially long key for an InfoObject into a short four-byte integer, which saves I/O and memory during OLAP.

Source system
A source system is a protocol that BW uses to find and extract data. When the source system is a non-SAP system, such as a flat file or a third-party tool, the maximum number of characters allowed for the technical name is 10. When the source system is an SAP system, either R/3 or BW, the technical name matches the logical system name. The maximum number of characters allowed for the technical name is 32.

Star schema
A star schema is a technique used in the data warehouse database design to help data retrieval for online analytical processing.

Statistics
For a SQL statement, many execution plans are possible. The database optimizer generates the most efficient execution plan based on either the heuristic ranking of available execution plans or the cost calculation of available execution plans. Statistics is the information that the cost-based optimizer uses to calculate the cost of available execution plans and select the most appropriate one for execution. BW uses the cost-base optimizer for Oracle databases.

System Administration Assistant
System Administration Assistant is a collection of tools used to monitor and analyze general system operation conditions.
System landscape
The system landscape specifies the role of each system and the paths used in transporting objects among the various systems.
Time-dependent entire hierarchy
A time-dependent entire hierarchy is a time-dependent hierarchy whose nodes and leaves are not time-dependent.
Time-dependent hierarchy structure
A time-dependent hierarchy structure consists of nodes or leaves that are time-dependent, but the hierarchy itself is not time-dependent.
Transfer rule
Transfer rules specify how DataSource fields are mapped to InfoSource InfoObjects.
Transfer structure
A transfer structure maps DataSource fields to InfoSource InfoObjects.

Update rule
An update rule specifies how data will be updated into their targets. The data target can be an InfoCube or an ODS object. If the update rule is applied to data from an InfoSource, the update rule's technical name will match the InfoSource's technical name. If the update rule is applied to data from an ODS object, the update rule's technical name will match the ODS object's technical name prefixed with number 8.

Variable
A variable is a query parameter. It gets its value from user input or takes a default value set by the variable creator.

Workbook
A BW workbook is an Excel file with a BEx query result saved in BDS. BW assigns a 25-digit ID to each workbook. Users need merely name a workbook's title.

Evolution of SAP BW

Evolution of SAP BW
A Quick Look at SAP R/3 Architecture and Technologies
Founded in 1972 in Mannheim, Germany, as Systemanalyse und Programmen-twicklung to produce and market standard software for integrated business solutions, today that company is known as SAP (Systems, Applications and Products in Data Processing), headquartered in Walldorf, Germany. SAP built packaged applications for mainframe computers, called SAP R/2. As the client/server technologies emerged in the early 1980s, SAP launched a major initiative to engineer powerful three-tiered integrated business applications under one framework. The SAP R/3 product is the outcome of that initiative.

Note Often, people ask what R/2 and R/3 mean. The letter R stands for real-time, and 2 and 3 represent two-tiered and three-tiered architectures, respectively. SAP R/2 is for mainframes only, whereas SAP R/3 is three-tiered implementation using client/server technology for a wide range of platforms-hardware and software. When implementing a Web front-end to an SAP R/3 implementation, the three-tiered architecture becomes multi-tiered depending on how the Web
server is configured against the database server or how the Web server Itself distributes the
transaction and presentation logic.

All SAP R/3 business applications use an active dictionary to store all business rules defined to run business. These business and workflow rules keep information flowing among application modules in a controlled and secured fashion. The "ABAP Workbench" is used to develop business programs using the Advanced Business Application Programming (ABAP) language. The Basis technology is responsible for managing R/3 infrastructure such as software installation, operations, and administration.

SAP R/3's multi-tiered architecture enables its customers to deploy R/3 with or without an application server. Common three-tiered architecture consists of the following three layers:
• Data Management
• Application Logic
• Presentation
The Data Management layer manages data storage, the Application layer performs business logic, and the Presentation layer presents information to the end user.

Most often, the Data Management and Application Logic layers are implemented on one machine, whereas workstations are used for presentation functions. This two-tiered application model is suited best for small business applications where transaction volumes are low and business logic is simple.

When the number of users or the volume of transactions increases, separate the application logic from database management functions by configuring one or more application servers against a database server. This three-tiered application model for SAP R/3 keeps operations functioning without performance degradation. Often, additional application servers are configured to process batch jobs or other long and intense resource-consuming tasks. This separation of the application server enables system operations staff to fine-tune individual application servers suited for specific data processing tasks.