Many business requirements demand business rules in BW. For instance, your business may need to assign a profit center to sales data coming from a non-SAP source system or apply CO-PA derivation rules to sales data. With the technique we describe here, you can bring IMG data to BW and apply IMG business rules to transaction data. You can also use that data as a characteristic in an InfoCube to catch the historical values, or use it as a navigational attribute to see the most up-to-date values.

Some of IMG data is stored in SAP database tables and some is interpreted by ABAP routines. IMG rules allow the use of conditions — less than, not equaling, etc. — but no BW object type can store this kind of information. A generic custom extractor is a tool to bring business rules from R/3 to BW – it can upload SAP database tables/views into BW as well as base extraction on a program. The details of importing information stored in IMG tables are outside the scope of this article. Instead, we will concentrate on extracting the information that’s interpreted by ABAP programs.

We will show you the easiest way to process business rules in BW: by converting those rules into all possible combinations and bring these combinations into BW in the form of master data. If you load this master data every time before transaction data, you can apply the most current business rules to BW transaction data.

There is a crucial step that all extractors must accomplish before importing this kind of data into BW: Locate which function in R/3 interprets the business rule you’re dealing with. There are many ways to do this, and since it isn’t a BW task, you can assign it to somebody with ABAP knowledge. Let’s assume for our example that we already know the function that interprets the rule in question.

Methods to Import Business Rules

There are many options to consider when importing business rules. One is to copy your function to BW, then call it in with transfer or update rules during the transaction data load. The main benefit of this approach is that it is simpler than other methods. There is one major drawback to this approach, however: It is high maintenance. You must copy the whole function group from R/3 to BW and identify all tables that this function group calls. Then you have to create InfoObjects for each table from which this function group retrieves data and create generic extractors for those InfoObjects. Finally, you must replace all SELECT statements in the function group to retrieve data from those new InfoObjects instead of R/3 tables. Each time the business rule on the R/3 side changes, even though it usually doesn’t happen very often, you have to adjust the BW rule. We recommend this option as a last resort.

A second option is to use a Remote Function Call (RFC). You can use an RFC in at least two places to interpret the business rule. One is the extraction, transformation, and load (ETL) process, where you can call the previously identified R/3 function in transfer or update routines. Usually the R/3 function is not RFC enabled, so you’ll have to create an RFC-enabled wrapper function that makes the call. You generally can call this new function from your transfer routine providing InfoObject values as parameters.

You can also use RFCs in user exits for virtual characteristics. You have to create an enhancement project and assign enhancement RSR00002 to it. Then in include ZXRSRU02 of function EXIT_SAPMRSRU_001, you populate names of InfoObjects that will be parameters of the previously identified R/3 function. Finally in include ZXRSRZZZ, you remotely call the R/3 function. This option is best for rarely used characteristics, because it slows the data load and query run processes.

The third approach is to use master data to import business rules. This technique assumes that the function that interprets the business rule has few parameters that may change and each of these parameters has a limited number of different values. One example is a business rule that includes the parameters sales org, product hierarchy or division, and sales order type. If you go through all the combinations of those parameters’ values, they usually generate fewer than a couple thousand lines of values. This means that the whole ETL process takes only a couple minutes (depending of the hardware used). We recommend this approach and will describe it in more detail.

Master Data

Let’s consider a business scenario. Transaction data from a non-SAP source system contains data for sales org, material, calendar month, and amount ordered. Your business wants to see sales numbers by profit centers that are not maintained in that source system, but are in R/3 IMG profit center substitution rules. The IMG menu path where these rules are usually defined is Controlling>Profit Center Accounting>Assignments to Profit Centers>Sales Orders>Sales Order Substitutions>Define Substitution Rules.

The business rule for this substitution relies on two items: sales org and product hierarchy. It has four steps, depending on sales org (domestic or foreign) and product hierarchy (tangible or non-tangible), as shown in Figure 1.

Figure 1

Substitutions for business rules

Using ABAP Trace (transaction ST05), we found that function G_VSR_SUBSTITUTION_CALL interprets the profit center substitution rule. This function has the following parameters: rule name, sales org, and product hierarchy (which is uniquely identified by material.) Usually there are no more than a couple hundred sales orgs and less than a hundred product hierarchies, so we can estimate that the number of records in the profit center substitution InfoObject won’t exceed a couple thousand items.

Create a BW InfoObject

To see sales numbers by profit centers in R/3 IMG profit center substitution rules, you must create a profit center substitution InfoObject in BW. Update rules can use this profit center substitution InfoObject to populate a profit center based on sales org and product hierarchy data. Transfer routines can also use this InfoObject to look up a profit center using sales org and product hierarchy data.

To set up the InfoObject shown in Figure 2, use transaction RSD1. Enter ZPROFITCR in the Characteristic field. Also enter the short and long descriptions in the fields provided. Add 0PROD_HIER in the Compounding tab.

Figure 2

Create a profit center substitution InfoObject

Add InfoObjects 0CO_AREA and 0PROFIT_CTR in the Attributes tab. 0CO_AREA is required here because 0PROFIT_CTR is delivered with 0CO_AREA.

Create a DataSource in R/3

Next, you have to create a DataSource for generic master data on the R/3 side. Base this DataSource on a query or on a function because there no table or view that contains this data. The benefits of a function-based data source include the ability to send data to BW in data packages. Alternately, DataSources based on queries send all the data at once. Function-based DataSources can be delta enabled and selection conditions can be processed much easier.

For this example, despite the aforementioned benefits, we will build a DataSource for IMG based on a query. The reason is that we can’t use any of the described benefits. There will not be so much data that we want to break it into packages. There is no way to delta-enable it and no selection conditions are expected. If you decide to implement your DataSource as a function-based extraction, it shouldn’t take much effort to change this program into a function.

Step 1. Create a structure definition on the R/3 side. This structure is needed to define the DataSource and the InfoSet structures. To create this structure, use transaction SE11 or follow menu path Tools>ABAP Workbench>Development>ABAP Dictionary (Figure 3). Enter ZPROFITCTR in the Structure field and populate the Short Description field. Type in ZPROFIT_CTR, ZSALES_ORG, and ZPROD_HIER in the Component column of the Components tab and enter PRCTR, VKORG, and PRODH_D in the Component type column.

Figure 3

Create a structure definition in R/3

Step 2. Define an InfoSet based on the structure created in Step 1. This InfoSet is shown in Figure 4. To define the InfoSet, follow menu path Tools>ABAP Workbench>Utilities>SAP Query> InfoSets or use transaction SQ02. Enter Profit Center Substitution Extractor in the Name field. Enter ZPROFITCTR in the Data structure field and click on the Data retrieval by program button on the next screen.

Figure 4

Define an InfoSet based on ZPROFITCTR

This program populates the InfoSet. This program has nested loops on sales org and product hierarchy tables. Inside those loops is a function call. This is the function we previously discussed with two parameters that change with each call – sales org and product hierarchy. The program populates the structure on which the InfoSet is based. In this way, the DataSource provides data to BW. The code for this program is available by clicking this link.

Step 3. Create a DataSource based on the InfoSet created in Step 2. Figure 5 shows the screen where you define this DataSource. Follow the menu path in BW IMG (transaction SBIW): Business Information Warehouse>Generic DataSources>Maintain Generic DataSources, or use transaction RSO2 directly. Type ZPROFIT_CENTER_SUBST in the DataSource field. Type CO-IO in the Application Component field or select it from the drop-down menu. We assigned the CO-IO application component because it belongs to Controlling Master Data.

In the Extraction from SAP Query section, enter ZPROFIT_CTR_SUBSTIT in the InfoSet field. This is the InfoSet we created in Step 1. You could also select this InfoSet from the drop-down list there. When you export this DataSource to BW, it appears under the CO application hierarchy node in Administrator Workbench (Figure 5).

Figure 5

BW DataSources shown in Administrator Workbench

Create an InfoSource in BW

To create an InfoSource based on this DataSource, follow the menu path Business Information Warehouse>BW Administration>Administrator Workbench (Figure 5). Select Source Systems from the left pane. The list of source systems attached to your BW system appears on the right side. Select the source system in which you created the DataSource. Right-click and choose DataSource Overview from the context menu or double-click on the source system name. Navigate to the application component where our DataSource was assigned, e.g., Controlling>Master Data.

The new DataSource is not there. To retrieve it, we have to replicate it from the source system by right-clicking and selecting Replicate DataSources from the context menu of the master data component. Refresh the screen to display the DataSource.

The red minus sign next to the DataSource means that no InfoSource is assigned to that DataSource. To assign an existing InfoSource or to create a new one, click on the minus sign and a new window pops up. In that window you see a box labeled Others where you can select or type in the previously created InfoObject.

The system then displays the transfer rules of that InfoSource. Map fields of the DataSource to components of the InfoObject as shown in Figure 6. Select one pair at a time: one element on the left side and one element on the right side. Next, click on the blue arrow in between the two columns to transfer in transfer rules. After you map all InfoObjects, activate the mapping.

Figure 6

Map fields of the DataSource to components of the InfoObject

Go back to the InfoSource screen by selecting InfoSource in the left pane and create an InfoPackage for this InfoSource. You can see the data as soon as it’s loaded (Figure 7).

Figure 7

InfoSource listing

InfoObject Usage

You can use this information in BW in two ways. If you are looking for what profit center a particular combination belonged to when a transaction occurred (historical view), use the profit center attribute of the InfoObject as a characteristic of an InfoCube.

To see to what profit center the combination belongs to now (current view), then make the profit center attribute of the InfoObject navigational in the InfoCube. These two views aren’t mutually exclusive, so we’ll show how to use them both. This is useful if you want to compare the historical view to the current view.

Once you populate this InfoObject, you can use it in an InfoCube that has sales org and product hierarchy, for instance the 0SD_CD04 – Delivery Service InfoCube. Select InfoProviders in the right pane of the Administrator Workbench (transaction RSA1) and navigate to the sales org and product hierarchy InfoCube. Right-click and select Change from the context menu or double-click on the InfoCube name. Locate InfoObject ZPRFCNTR in the right pane and move it to the left one, as shown in Figure 8.

Figure 8

Move InfoObject ZPRFCNTR from the right pane to the left pane

Select the Nav. attributes… button and put a check mark next to 0PROFIT_CTR. This makes profit center values available for navigation when reporting on this InfoCube.

To populate the characteristic 0PROFIT_CTR with a historical view, you have to make changes to the update rules. Right-click and select Change from the context menu for the update rules or double-click on the update rules. Go to the Characteristics tab and select 0PROFIT_CTR. Click on the Method button for 0PROFIT_CTR and select the Master Data Attrib. of button. InfoObject ZPRFTCTR is in the drop-down box next to it. Select it to display the screen in Figure 9.

Figure 9

Populate characteristic ZPRFTCTR with a historical view