Strategies to Build SAP R3-Centric Data Warehouse Environments

Team-Fly

Strategies to Build SAP R/3-Centric Data Warehouse Environments

You now have a good idea about R/3 reporting systems and their capabilities and limitations. When you decide to build a data warehouse within or outside of R/3, think of the following key functions:

  • Separate OLTP/OLAP Environments

  • Optimized Reporting Environment

  • Loaded Daily or More Frequently

  • Historical Information

  • Flexible Software Releases

  • Incorporate Non-SAP Data

  • Open Environment

SAP customers have taken several approaches to building a data warehouse using R/3 technologies. In the next section, you will see common R/3 data warehouse models, and later in this chapter, I will discuss how they meet the key functions listed earlier.

Database-Centric Data Warehouse

The database-centric approach is simple. Make a copy of an R/3 database for users to report against. Conceptually, the idea is simple, but it is an operations nightmare to keep R/3 OLTP and R/3 reporting in synch.

As shown in Figure 2-5, to do a full backup of the OLTP database (Step 1) and restore it for reporting is a very time-consuming task (Steps 2 and 3).

click to expand
Figure 2-5: R/3 Database-Centric Reporting Environment.

Then prepare the copied instance for the reporting environment (Steps 4 through 6). Here you load new users and security profiles needed for reporting. When the newly refreshed database server is ready for production reporting, the old database server is moved back to the staging state for the next OLTP data refresh, as indicated in Step 7, which is repeated to refresh the reporting environment again using another set of hardware gears. This approach may work for small R/3 OLTP instances, but for large databases, it is virtually impossible to rebuild another R/3 database daily. Typically, you need to perform all seven steps, as shown in Figure 2-5, which is very time consuming. This means you also need two sets of database servers for reporting-one for production reporting and another for refreshing-an expensive proposition.

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. You can define special user authorization and profiles for reporting users (Step 5). 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 you have access to only the data that exists in the OLTP instance; you have no historical data to report on. Moreover, you 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

Using the ALE model, you do not copy a full database but rather use ALE to propagate specific changes into the reporting environment-another R/3 instance. Originally, ALE technology was designed to move data from one instance to another based on a workflow model triggered by business events. However, customers have used ALE technology to propagate data programmatically from one R/3 instance to another instead of its being triggered by business events.

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. Figure 2-6 shows an example of how Digital Equipment Corporation used this approach to implement an ALE-based reporting environment in 1997.

click to expand
Figure 2-6: SAP ALE-Centric R/3 Reporting Environment.

Under this distributed R/3 business model, four individual R/3 instances were connected via ALE: one R/3 instance to manage master data; one R/3 instance for financial operations; one instance for logistics operations; and one 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. In this example, ALE could not move all needed data from SAP R/3 OLTP to the reporting SAP R/3 instance. The copy management technique was used to move the data that ALE could not move.

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 has several advantages, such as the following:

  • 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 the following:

  • 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

Almost all customers have implemented data warehouses using technologies provided by third-party vendors. Most SAP customers write custom data extraction programs in R/3 using ABAP. In recent years, several data warehouse tool providers have offered sophisticated data extraction techniques to extract data from R/3 and other ERP data warehouses.

Often, 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 (SAP proprietary database tables from which data is accessed or manipulated through ABAP programs and not directly via SQL statements). 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. You end up managing, training, and supporting two completely different teams (skills, knowledge, and resources). It is expected, however, that such data warehouses will still exist even with all the difficulties described here.

It is clear from data warehouse models and the functionality comparison, as shown in Figure 2-7, that the only benefit of building a reporting environment in the R/3 OLTP environment is that you have access to transaction-level detail. The database-centric model has the same advantage as R/3 OLTP but with one difference: R/3 OLTP and the reporting environment are separate instances. On the other hand, the SAP ALE-centric model does satisfy several requirements but still is limited by R/3 schema and reporting tools functionality. SAP BW is expected to meet all data warehouse and reporting requirements.

click to expand
Figure 2-7: Functionality Comparison of R/3 Data Warehouse Models.


Team-Fly


Business Information Warehouse for SAP
Business Information Warehouse for SAP (Prima Techs SAP Book Series)
ISBN: 0761523359
EAN: 2147483647
Year: 1999
Pages: 174
Authors: Naeem Hashmi

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net