Business Information Warehouse for SAP (Prima Techs SAP Book Series)

Preparing SAP R/3 for SAP BW

Depending on your SAP R/3 OLTP and SAP BW project time line, you may be able to share one SAP R/3 instance to do development for OLTP and SAP BW. However, I recommend a stand-alone SAP R/3 OLTP production instance as a data source for an SAP BW development project. Do not work with dummy data; instead, make a copy of your SAP R/3 OLTP instance or an SAP R/3 instance that really reflects your current SAP R/3 configuration with a decent amount of reference and transaction data.

The SAP R/3 OLTP preparation for SAP BW begins with the installation of SAP BW objects, such as tables, programs, and data extractors, as described in Chapter 8. Before installing any SAP BW-specific objects on SAP R/3 OLTP, make sure that the BASIS team understands all prerequisites for an SAP R/3 OLTP corresponding to the SAP BW version and check the OSS notes for the latest news on installations. Depending on the version-SAP R/3 OLTP (3.0F-4.5B) and SAP BW (1.2A, 1.2B, 2.0A)-you may need to install hot packages before installing any SAP BW objects on the SAP R/3 OLTP. Note that starting with SAP BW version 2.0x, the BW add-on to SAP R/3 is now called Plugin for SAP BW.

After installing the BW add-on in the SAP R/3 OLTP instance, you need to define the remote logon connection in SAP R/3 OLTP for the SAP BW instance. This is a five-step process for the SAP BW 1.2B add-on, as outlined here:

1. Create an ALE user, transaction SU01, to be used for remote logon to SAP BW from SAP R/3 OLTP. Make sure that this user, usually ALEREMOTE, has sufficient authorizations for the RFC and ALE components, as described in the installation guide. The ALE user must have profile S_BI-WX_RFC. This profile consists of sub-profiles such as B_ALE_ALL, S_APPL_LOG_A, S_IDOC_ALL, and S_RS_ALL.

2. Set up a logical system name for SAP BW. The logical system is used by SAP R/3 to connect the SAP BW instance for data transfer. To set up a logical system name on SAP R/3 OLTP, run transaction SM30 and edit table V_TBDLS. Create a new entry for the SAP BW logical name, such as XDWCLNT100.

3. Assign SAP BW client to the logical system name. Here you associate SAP BW client to a logical name. Using transaction SM30, edit table T000 and add entry.

4. Define an RFC destination for SAP BW. In Steps 1 and 2, you simply defined a logical system name and associated it to an SAP BW client, but you cannot connect to the remote SAP BW instance. This is because you have not defined the network-level information for such communication links. To make this happen, you need to define an RFC destination in SAP R/3 OLTP for SAP BW using transaction SM59, as described in Chapter 7. Here the DEST is your system logical name defined in Step 1, XDWCLNT100, and the connection type is 3; enter the IP address and other user information to log on. Select the Test Connection and Remote Logon options to make sure that you can access the remote BW instance. If the Test Connection option fails, check to make sure that SAP R/3 and SAP BW are on the network, that SAP BW is running, that both have the correct network configuration, and that both servers are visible on the network. Check with your networking support team to resolve these issues.

5. Verify the workflow basic setting. Run transaction SWU3 and create the workflow basic setting. Click the AutoCustomize menu option to verify that the workflow setting for SAP BW components is set properly, as shown in Figure 9-1 on SAP R/3 version 3.1H. Remember that only the Workflow runtime system needs to be confirmed here. Verify that the results show a green check mark or traffic lights for the following items:

   Figure 9-1: SAP R/3 OLTP Verification of the Workflow Runtime Environment for SAP BW.

   • An active plan version exists

   • RFC Destination Workflow

   • Workflow runtime customizing complete

Perform additional installation verification steps as described in the installation guide. Next, you need to analyze data present in SAP R/3 OLTP and prepare data sets to load in SAP BW.

Information Collection Process in the SAP R/3 Data Source

SAP BW 1.2B business content covers a wide range of functional areas; in this book, I discuss the data associated with the Sales and Distribution (SD) module of SAP R/3 and relative SD business content in SAP BW.

Though order processing in SAP R/3 is a complex process and most customers do customize data flows based on their business rules, Figure 9-2 shows a common order processing transaction data flow and how transaction data sets are physically stored. Each drum object in Figure 9-2 represents one or more database tables. Text in each drum shows table names. Solid connecting lines show the relationship among such data set objects. Darker drums represent data sets for InfoCubes in SAP BW. The text in each darker drum shows the LIS table name in SAP R/3 OLTP and its corresponding InfoCube in SAP BW. For example, S260 is an LIS table, and ORDERS is the InfoCube in SAP BW based on S260. Dotted lines show the source tables for specific SAP BW InfoCube data stores in SAP R/3.

Figure 9-2: A Typical Order Processing Transaction Data Flow in SAP R/3 and Associated Data Sets for InfoCubes in SAP BW 1.2B.

You are not limited to SAP standard LIS or SAP BW specific LIS structures; you can use or create custom LIS structures as data sources for custom InfoCubes in SAP BW. For example, S001 is a standard LIS structure in SAP R/3 OLTP, and S260, S261, and others are SAP BW specific LIS structures that are installed as part of an SAP BW add-on.

In this example, to build initial data loads for SAP BW, you need to first populate LIS tables S260, S261, S262, and S263. The process of populating such tables is called the statistical update. The statistical update for individual data sets may take from a few minutes to several hours and sometimes days based on the volume of transaction data in SAP R/3. No transaction activity is advised while statistical updates are in progress to avoid database tables locking and data inconsistencies, which will be further discussed later in the chapter.

When transaction volumes are high or in global SAP R/3 implementations, the business community cannot afford to keep SAP R/3 instances down for several hours to run statistical updates. Under such a scenario, you need to analyze transaction data for logical groupings and run such statistical updates in small segments, as described in the next section.

All data warehouses start with baseline data from their transaction data sources. After loading initial data, only new or changed data is needed in a data warehouse. During the SAP BW add-on process in SAP R/3, several LIS primary and change capture tables are defined and initialized. The change log tables are called DELTA logs. To implement delta change capture in SAP R/3, you will find two tables associated with each LIS table. For example, Figure 9-3 shows two tables, S261BIW1 and S261BIW2, to capture information about new or changed orders for S261. All tables, S261, S261BIW1, and S261BIW2, have the same metadata definitions. The only difference is that table S261 is used to load the initial data set for SAP BW, and S261BIW1 and S261BIW2 are used to capture incremental order changes.

Figure 9-3: Statistical Update to Prepare Initial Data Loads and Process of Incremental Data Capture in SAP R/3 for SAP BW.

Having two delta tables per LIS table is a big advantage in high-volume SAP R/3 implementations. One table actively captures new or changed data, and the other table remains idle. When SAP BW requests data, the active delta table is immediately locked, and the standby table becomes active to collect new changes, as shown in Figure 9-3. When all open transactions in the locked table are completed, data is shipped to SAP BW, and then this table goes in a standby mode.

But how does SAP R/3 or SAP BW know which delta table is currently active and collecting new data? The table TMCBIW in SAP R/3 flags the active LIS table name. When SAP BW issues a delta capture request, it looks in this table to find the active table name, Step 2 in Figure 9-3. Then it empties the standby table (Step 3 in Figure 9-3), locks the currently active table, and sets the flag in the TMCBIW table for standby table as an active table (Step 4 in Figure 9-3). Finally, it sends data to SAP BW from the locked populated standby table. This cycle continues for subsequent data requests from SAP BW.