It is a well-known fact that enterprise data warehouses source data from several corporate transaction systems. This means that an enterprise data warehouse must provide services that enable customers to integrate heterogeneous data sources in a seamless fashion. To make this happen, SAP BW (beginning with release 1.2x) provides a collection of Business Application Programming Interfaces (BAPIs) to facilitate integration of non-SAP R/3 data in SAP BW. Such BAPIs are called Staging BAPIs. The reason for calling such BAPIs Staging BAPIs is that their scope is limited to the Staging engine layer of SAP BW, as shown in Figure 14-1.
Figure 14-1: SAP BW Data Loading and Data Access Interfaces.
Producers of several data warehouse construction tools have implemented Staging BAPIs to extract data from data sources (SAP R/3 or non-SAP R/3) and load directly in SAP BW. At the time of this writing, several vendors have been certified as providers of Staging BAPIs (refer to Table 3-1 in Chapter 3).
Staging BAPIs make SAP BW open to load data from just about any data source. SAP also provides BAPIs and the Microsoft OLE DB for OLAP (ODBO) interface to access data from SAP BW. The data access BAPIs and ODBO are public APIs, and several data access vendors have implemented interfaces to SAP BW that complement SAP BW BEX reporting capabilities. Refer to Table 3-2 in Chapter 3 for a list of vendors that are ODBO certified. Chapter 15, "Integrating Third-Party Data Access Products with SAP BW," focuses on third-party data access tools to access data from SAP BW.
Note | Built-in data loading interfaces in SAP BW, flat files, and Staging BAPIs enable you to load master and transaction data. However, with Staging BAPIs you can also load metadata of incoming data objects and dynamically connect to external applications, eliminating the need for scheduling and preparing flat files. |
Before learning how Staging BAPIs work, first look at SAP BAPI technology. BAPIs were first made available to customers with release 3.1 of SAP R/3. BAPIs expose SAP R/3 business functionality through business objects. The SAP Business Framework provides an open object-oriented component-based architecture that enables software components from SAP and other vendors to interact and integrate with each other. Such objects are called SAP business objects. All SAP business-object types and their methods are defined and described in the Business Object Repository (BOR). SAP business objects are accessed through BAPIs. SAP business objects and their BAPIs provide an object-oriented view of SAP R/3 business functions.
You need a good understanding of object-oriented programming to access SAP business objects using BAPIs. You can use Microsoft Visual Basic, Microsoft C++, Java, or ABAP languages to develop applications using BAPIs. However, to access BAPIs external to SAP R/3 instances, you need to program BAPIs using the Remote Function Call (RFC) protocol. You need a good understanding of distributed application design and RFC programming skills to call BAPIs external to SAP R/3.
Note | To learn more about how to access BAPIs or create new BAPIs, consult the BAPI User Guide and BAPI programming documents that are part of the standard SAP help documents. These documents provide you with all the details, with examples, on how to work with BAPIs. I also recommend an excellent book on the subject, Prlma Tech's Java & BAPI Technology for SAP by Ken Kroes and Anil Thakur. |
To implement a data loader, third-party vendors develop an RFC Server (process) that manages connections between the data warehouse construction tools and SAP BW. It is important that RFC Server developers are extremely experienced with the distributed computing model to implement high-performance data streams between data sources and BW using the RFC protocol.
In SAP BW 1.2B (Patch 12), eight staging business objects are registered in BOR as shown in Table 14-1. However, in BW 2.0A, no new staging business objects are in BOR. Most staging business objects are either modified or enhanced (new methods and/or interfaces) to accommodate new functionality due to changes in metadata, master data structures, and ODS data management.
Object Name in BOR | Business Object Name | Description |
---|---|---|
BUS6101 | SourceSystem | Properties and methods of a source system |
BUS6102 | InfoSourceTrans | Properties of an InfoSource for transaction data |
BUS6103 | InfoSourceMaster | General properties of an InfoSource for master data |
BUS6104 | InfoSourceMasterXfer | Source-system-specific properties of an InfoSource for master data |
BUS6105 | InfoSourceHirchyXfer | Properties for hierarchies of a master data InfoSource |
BUS6106 | InfoSourceTransXfer | Source-system-specific properties of an InfoSource for transaction data |
BUS6107 | DataProvider | Properties and methods of a data request to a source system (removed in BW 2.0A) |
BUS6108 | InfoObject | Properties and methods of an InfoObject |
Note | To list staging business objects in an SAP BW Instance, execute transaction SWO1. Enter BUS6* in the Object/Interface Type field and click the down arrow. This will list all staging business objects in BOR. To list interfaces associated with these business objects, execute transaction SWO1, enter IF*, and click the down arrow. To list methods for business objects, use the BAPI Browser (transaction BAPI). This lists all BAPIs and published methods for individual business objects. To list function modules associated with individual business objects, use transaction SE80. Look in function groups RSAB and RSODS. These function groups contain all function modules associated with staging BAPIs. |
As mentioned earlier, one must have a good understanding of object technologies and good development skills in distributed service-centric software design. Typically, the exchange of data with the source system happens in a two-step process.
The first step is to read metadata of InfoSources defined in SAP BW. The second step is to use this metadata information to extract data from the source system and send it to SAP BW.
Figure 14-2 illustrates the mapping of extracted data against the transfer structure of an InfoSource defined in SAP BW. Note that this applies to transaction data as well as master data attribute InfoSources.
Figure 14-2: SAP BW Metadata Management Process using Staging BAPIs.
The source system calls the GetList method of an InfoSource to get a list of available InfoSources from SAP BW. Depending on how a third-party application is implemented, it may present this list in a dialog box and have the user select an InfoSource to map it to the extract structure of inbound data. This mapping process is based on the transfer structure definition, which can be retrieved from SAP BW by calling the GetDetails method associated with the InfoSource.
Once the metadata and transfer structure are captured in the repository of third-party tools, the next step is to actually extract data from the data sources, perform mapping and transformation, and send extracted data to SAP BW, as shown in Figure 14-3.
Figure 14-3: SAP BW Data Loading Process using Staging BAPIs.
Let's look at the sequence of BAPI methods needed to complete the data loading process. The data request is initiated by the BW scheduler to request a list of parameters, such as user name and password, needed to start the extraction process in the source system. This is achieved by calling the GetParameterDefinition method of the Data Provider business object.
The scheduler then sends a data request by calling the SendRequest method of the Data Provider business object. Part of the request is the values of the requested parameters, selection criteria, and request details such as a unique request ID, name of the corresponding InfoSource, and so on.
It is possible that the InfoSource definition in SAP BW may have changed, but such changes may not have been updated in the third-party metadata repository. To make sure that the extract structure exactly matches the current transfer structure, the source system has to call the GetDetails method of the requested InfoSource to get the current transfer structure.
Extracted data can then be sent to SAP BW by calling the SendData method of the requested InfoSource. The SendData method supports sending any number of records per call with each call defining a data packet. However, it is recommended to send about 10,000 to 100,000 records per call.
Note | At present, the individual record size is limited to 1,000 bytes regardless of whether data is stored in ODS or InfoCubes. |
Team-Fly![]() |