abap_programmingin sap bw

SAPtips © 2004 Klee Associates, Inc.

Editor's Note: With all the talkabout NetWeaver and SAP® JavaConnector and other hot tools,you'd think ABAP was a thing ofthe past. But not so, as BWexpert Pat Pesa can attest. Inthis excellent "best of" article,Pat shares the most valuableABAP techniques he has used onBW projects. He starts byaddressing the key questions:What are the uses of ABAP inBW? How is programming inBW different than programmingin R/3? What ABAP tools areavailable in BW? Then, Pat digsinto some technical examples ofABAP-BW in action. This arti-cle provides technical managerswith a handy overview of Pat'sABAP-BW methodology, andgives ABAP programmers atechnical guide they can refer toon their BW initiatives.

This article will focus on theconcepts and strategies that con-stitute best practices regarding theuse of ABAP programming in BW.On each project I have beeninvolved with, the use of ABAPprogramming has had a profoundeffect on our ability to model thecorrect business processes withinBW. During the design and blue-print stage, a core functionalprocess is the determination of thecorresponding business logicfound in R/3 or legacy data sys-tems and how to accomplish thesame logic in BW. FortunatelySAP® has provided several struc-tured paths to follow in order toimplement this business logic. Inthis article, I will lay the ground-work from which we can deter-

mine the what’s, where’s andhow’s of ABAP programming inBW. These "tips" on ABAP andBW are written with BW version3.0 and R/3 4.6C in mind, butmost of them will apply to anyversions of R/3 from 4.x and up,and any versions of BW from 2.0and up.

This article will begin with anoverview of the prospectiveinvolvement of ABAP code, wherewe can find this code, and howbest to include coding for specificareas without impacting otherfunctionality. Our examples forthis article will include R/3 data-source modifications and the cre-ation of generic extractors in R/3for use with BW.

To get the ball rolling, I wouldlike to start off with the followingconsiderations. Remember that inSAP BW, most everything is inter-connected, and we share a greatdeal of data amongst several data

targets. Therefore, we will need tobe specifically aware of how weproceed with our data or recordupdates and where we decide toplace ABAP programming thatwill manage these updates. Hav-ing said that, we can now exam-ine what possibilities exist forusing ABAP to customize our BWenvironment.

What Can We Do WithABAP in BW?

As with anything, in SAP thewords and phrase "ABAP pro-gramming" routinely surface astopics and questions duringimplementation. However,between SAP R/3 and BW, thereare distinct differences betweenhow we can use ABAP program-ming in these environments andwhat we can expect as an outcomeof development. In order tounderstand how ABAP is used inBW, we should have a generalunderstanding of the infrastruc-ture of BW. Generally speaking, inBW, we are dealing with Objectsthat we connect with some type ofconfiguration, such as the linkingof an ODS with an InfoCube, orthe creation of source system def-initions and datasources. What wewill NOT be doing on a generalbasis in BW is building screensand multiple user exits in ABAPto gain additional functionality.1

This is the distinct difference inBW as it relates to R/3. So if we'renot using ABAP for user exits andscreens, then how will we useABAP? In BW, we will use ABAPto transform our data as require-ments dictate, as well as provideadditional processing duringextraction and updates.

Feb

ruary/M

arc

h 2

004 V

olu

me I

I Is

su

e 1

ww

w.S

AP

tip

s.c

om

SAPtipsSA

Ptips

JournalJ

ourn

al

ABAP Programming In BW By Arthur "Pat" Pesa, arthurpesa, inc.

In order to

understand how

ABAP is used in BW,

we should have a

general understand-

ing of the

infrastructure of BW.

1 One thing to note: we are provided with one user exit in SAP R/3 that will enable the management of data being extracted and one user exit in BW that will enable themanagement of data being queried.


Within the ABAP language arecertain constructs that allow usto get work done within thisenvironment. In SAP, we will beusing the ABAP Workbench tocreate our code. This is true foreach instance we are writingcode, whether it is from within atransfer rule, update rule, orstart routine. It is important tounderstand the fundamentalconcepts of the ABAP workbenchin order to proceed. First, weshould be familiar with the con-structs of programming, such asunderstanding what a sub rou-tine does, how a function moduleworks, etc. Also, we shouldunderstand the different avenueswe may use in order to debug ourcode. This last measure is ofextreme importance, since it willbe necessary to debug code fromtime to time in order to createwhat our requirements dictate.For the purposes of this article,we will assume that the readeralready has a grounding in thesebasic ABAP concepts, includingthe ABAP Workbench.

Our approach to ABAP develop-ment in BW will follow the simpleguidelines found in Figure 1.

Where Are We Able to Cre-ate ABAP Programming inBW?

An often-asked question prior tothe beginning of a BW projectrevolves around how much ABAPprogramming will be necessary.Following the construct of a typi-cal R/3-BW integration, onewould assume that all ABAPwould be done by a team of pro-grammers and that the BW con-sultants would furnish documen-tation around the changes to bemade. However, in BW, the line

between functional and technicalis often much more gray than thedistinction in R/3. To cite oneexample: we can configure objectsin BW, thus gaining a great deal offunctionality, without writing anarray of user exits as found in R/3.

Let’s take a look at where weare able to augment our BWdevelopment with ABAP andwhat that may mean to the sys-tem performance. Generally,when adding code, we canassume some type of run timeoverhead in the form of process-ing time or memory impact.However, when programmed inan expedient and concise man-ner, the overhead may beinsignificant. At this time, weshould familiarize ourselves withwhere BW will permit customer-provided ABAP programming.

Now let's look at the optionsfound within BW that allow theadditional implementation ofABAP programming (see Figure 2).

The list in Figure 2 representsthe areas within BW that mayrequire ABAP expertise during aBW implementation. This list cov-

Feb

ruary/M

arc

h 2

004 V

olu

me I

I Is

su

e 1

ww

w.S

AP

tip

s.c

om

SAPtipsSA

Ptips

JournalJ

ourn

al

• Requirements

o Programming actions in the form of pseudo-code or a high level flow of data

• Design – determining where our data resides and how we would want it transformed.

• Deciding where to place our code: within the transfer logic or update logic, or within the userexit in R/3 or BW.

• Actual ABAP development and programming.

• Unit testing within the ABAP Workbench.

o Make sure the individual code performs what it is meant to do.

o Debugging works well here, using breakpoints.

• Integration testing

o In BW, this is usually accomplished via data extraction and/or loading.

Figure 1: Basic Guidelines for ABAP Programming in BW

Figure 2: BW and R/3 ABAP Programming Options

Technical Area Description

BEx User Exit Allows the creation and population of variables and calculations for keyfigures and variables on a runtime basis. This user exit is called each timeBEx is executed.

R/3 User Exit This user exit is found in R/3 under CMOD and contains additional pro-gramming that is needed to fill field additions to extract structures. We canalso create additional business logic against data prior to its transfer toBW.

BW Transfer rules These rules are invoked as data is transferred from R/3 to BW, or fromwithin BW as export data sources and InfoSources are created.

BW Update Rules These rules are invoked as data is being updated into data targets.Whether ODS Objects or InfoCubes, each update results in the execution ofan Update Rule.

BW Start Routines Start routines in BW Update Rules are used to manage whole subsets ofdata. This is different than a simple update rule in that update rules aredata element specific.


ers 99 percent of theexamples of ABAPdevelopment in BW. Isay that becausethere is always thatone exception inwhich a customiza-tion has been doneoutside this matrix.Now that we havecovered the what’sand where’s of ABAPprogramming in BW,we can have a look atthe how’s.

How Do WeManage OurProgrammingDuring theDevelopmentPhase?

Let’s start at thebeginning. By thebeginning, I meanthe point on our BWproject where we first start look-ing in R/3 and figuring out whatwe can modify prior to or duringextraction. As a rule of thumb,the concept here will be as fol-lows. In R/3, we have access tothe raw transactional data set wewill want to modify. We have sev-eral options here, but primarily,we can either modify an existingdata extractor or create a newcustomized extractor from theground-up. Let’s look at the twooptions in the table in Figure 3.

Option 1This is the most straightforward

modification in ABAP and is com-monly employed to add datarequirements that do not exist inthe standard extractor. We do thisusing the basic concept of appendstructures for our additionalfields. Once we have added ourfields and activated our extractstructure, we will be able to seethese fields in the user exit.

A commonly overlooked stepin adding fields to extract struc-tures and filling them with datais actually making the newlyadded fields visible to the BWtarget system. Once the fields areadded to the extract structureand you have saved and activat-ed both the append structureand the extract structure, youwill need to go to transactioncode RSA6 -> Post ProcessingDatasources and find the data-source you modified. Doubleclick on that datasource andmake sure you uncheck the"hide" check box for the addedfields. Otherwise, these fieldswill not show up in the newlyreplicated datasource in BW.

At this point, we can look athow we can populate thesefields with data in the R/3-to-BW user exit in R/3. To providesome background, I will brieflymention how to navigate to the

user exit we want to use. Usingtransaction code CMOD, go toyour BW project, i.e., "Z_BW".This project will be found with-in the customer namespace.Once you have found the correctproject, choose "display compo-nents" and hit F7. This will dis-play the BW user exit compo-nents. You should find four userexits. The configuration of theseuser exits may differ from sys-tem to system. Figure 4 con-tains the descriptions of thefour user exits found in aCMOD BW Project.

To provide an example, let'sconsider a standard-delivereddata extractor found withinLogistics Cockpit. This extrac-tor is responsible for extractingpurchase order item data foundin R/3. For our example, let’sassume you have added severalfields to the 2LIS_02_ITMextract structure.

Feb

ruary/M

arc

h 2

004 V

olu

me I

I Is

su

e 1

ww

w.S

AP

tip

s.c

om

SAPtipsSA

Ptips

JournalJ

ourn

al

Figure 3: ABAP Programming Options in R/3 for BW

Option 1 • Add fields to append structure for an existing extract structure.

• Add corresponding ABAP logic to fill these fields.

Option 2 • Create a table or view that represents our data set.

• Use Transaction RSO2 to create a generic extractor.

• Add code to function module or user exit to fill fields or modify data instructure during extraction.

Figure 4: R/3 User Exit Examples in BW

User Exit Description

SAPLRSAU_001 Transactional data user exit

SAPLRSAU_002 Master Data User exit

SAPLRSAU_003 Optional

SAPLRSAU_004 Optional


Feb

ruary/M

arc

h 2

004 V

olu

me I

I Is

su

e 1

ww

w.S

AP

tip

s.c

om

SAPtipsSA

Ptips

You now want to add your pro-gramming logic to fill these fieldsand then re-initialize BW. You willdouble click on SAPLRSAU_001and you will be taken to the cor-rect include file for the top-levelprogram SAPLRSAU_001. Oncethere, you will double click on theinclude ZZRSAU01. This includeis where all your customer logicwill be written. Let’s examine thestructure of this include and lendsome insight into how and whereto add our code within thisinclude. This include, or user exit,is based on case logic, meaning wewill use a case statement to deter-mine where we will land withinthe exit during runtime. Pleaserefer to the structure found in Fig-ure 5 within the include. Note thatyou may have to create the caselogic prior to adding your addi-tional logic.

From this point, you will use"when" statements to controlentry into your logic. An examplewould be Figure 6.

Once you begin extraction andthe extract structure has beenfilled with the initial data fromstandard extracts, you will findyourself within the When logicand ready to begin to append

data to each record. In this userexit, you will loop through eachrecord and append the necessarydata. Then, in the final step

within the loop, you will add allthe new data elements to theactual extract structure andreturn to the next record. Looplike this through each recorduntil you are finished with eachrecord in the initial extract struc-ture. Figure 7 illustrates ABAPwritten to append accountassignment data to a purchaseorder item.

While the code in Figure 7 is notall-inclusive, it clearly illustrateshow to integrate your ABAP pro-gramming into the correct user exit.

Option 2Now let’s look at Option 2 (ref-

erence Figure 3). In Option 2, weare going to create a generic data-

Figure 5: Case Logic Example

INCLUDE ZZRSAU01.

CASE I_datasource.

***User managed code***

ENDCASE.

Figure 6: When Logic Example

INCLUDE ZZRSAU01.

CASE I_datasource.

WHEN ‘2LIS_02_ITM’.

Do Something…..

ENDCASE.

Figure 7: PO Account Assignment Programming Example

case i_datasource.

when '2LIS_02_ITM'.

* begin of code add on 02/25/2003 CLEAR i_mc02m_0itm.LOOP AT c_t_data INTO i_mc02m_0itm.

*06-06-2002 new-begin* select single pspel from aufk into i_mc02m_0itm-zzposid* where aufnr = ekkn-nplnr.*

SELECT SINGLE b~posid INTO i_mc02m_0itm-zzposid FROM aufk AS aINNER JOIN prps AS b ON a~pspel = b~pspnrWHERE a~aufnr = i_mc02m_0itm-zznplnr.

* SELECT SINGLE vornr FROM afvc INTO i_mc02m_0itm-zzvornr* WHERE aufpl = ekkn-aufpl* AND aplzl = ekkn-aplzl.*06-06-2002 new-end

* SELECT SINGLE * FROM prps CLIENT SPECIFIED* WHERE mandt = sy-mandt* AND pspnr = ekkn-ps_psp_pnr.** IF sy-subrc = 0.* i_mc02m_0itm-posid = prps-posid.* ENDIF.

MODIFY c_t_data FROM i_mc02m_0itm.CLEAR i_mc02m_0itm.

ENDIF.

ENDLOOP.

Jou

rnalJournal


source using standard SAP R/3technical components. Much ofthe actual extract code will be cre-ated for our use; we will need onlyto specify several aspects, such asthe extract structure and functionmodule. Or, we can use a view andallow R/3 to generate everythingfor our use. Please keep in mindthat once we complete this step,we can gain the same access asillustrated in option 1 duringextraction. Before we get intoexamples, let’s review our optionsin creating a generic extractorfound in figure 8.

Creating a view in R/3 permitseasy definition of our extractbased on several tables. Here areseveral important considerationsin creating a view in R/3:

1. When using multiple tables,you will have to provide thejoins for the tables based onthe keys found in each table.If you don’t, then the systemwill make each field withinyour view a key for the view.This will impact view per-formance during runtime.

2. You will have to include unitreferences for quantity andprice data elements. Youshould use the same referencefield found within the data ele-ment itself. This reference fieldis simply added to the view.

3. You should consider usingthe top-level tables withinyour view even in the eventyou will not use fields fromthese tables. For example,when creating a view from"Material Plant data",MARD, you should join the"Material Master generaldata", MARA, documentnumber with the MARD doc-

ument number and MANDT"client" to ensure that youwill get only the records youwant and not multiples onthe same record acrossclients.

Now, taking into considerationthese tips on creating a view, wecan build our view so that it con-tains the fields we have identifiedand want in the generic dataextract.

1. Calling transaction SE11 andsetting the radio button toView, we input the Z******name for our view and clickCreate.

2. When prompted for a devel-opment class, input the cor-rect development class andclick save. This will bring usto the initial view definitionscreen.

3. Begin by adding the fieldsyou need, supplying the basetable names as well. You willneed to complete all the stepsrequired to finish the view.

4. Once done and active, checkto see how many records yourview returns and comparethat number to the numberof records found in the basetable(s).

5. Once you have your viewcompletely finished, you cango to transaction RSO2.

6. Input the view name, makingsure the correct options arechecked for using a viewinstead of an extract struc-ture/function module andclick the save button.

7. If you’re successful, you cango to RSA3 and run theextract checker for you newdatasource.

8. You should double check theRSA3 output with the viewdefinition as a unit test. Thiswill give you a preliminaryfitness test for the genericdatasource.

Now let's consider the secondoption in creating a generic data-source. First, you will need todefine a structure that will serveas an extract structure for yourprogram. In creating an extractstructure please refer to the fol-lowing rules:

• Make sure you include unitsfor quantities and price data.

• Make sure you include theappropriate keys for the datayou will be working with,such as document numbersand/or item numbers.

As for the extract functionmodule, you should plan on cre-ating a simple function moduleand following the guidelinesfound in the example functionmodule RSAX_BIW_GET_DATA.

Feb

ruary/M

arc

h 2

004 V

olu

me I

I Is

su

e 1

ww

w.S

AP

tip

s.c

om

SAPtipsSA

Ptips

JournalJ

ourn

al

Figure 8: Generic Extractor Options

• Create a view and use RSO2 to allow the system to create the code.

• Create structure that defines our extract and also create a function module that performsthe extract.


Feb

ruary/M

arc

h 2

004 V

olu

me I

I Is

su

e 1

ww

w.S

AP

tip

s.c

om

SAPtipsSA

Ptips

Following this example willensure compatibility creating thegeneric extractor with the struc-ture/function module combina-tion. In this article, we will notdetail the creation of a functionmodule based onRSAX_BIW_GET_DATA, but Iwill note that it will be relativelysimple to create a datasourceonce the function module is com-plete. The extractor definition iscreated in the same manner as thefirst example using RSO2, but wewill specify our structure name aswell as the function moduleinstead of the view. Once it issaved and active, it is ready. Alsoremember that you may makechanges to the logic in both thefunction module itself or withinthe user exit SAPLRSAU_001.

ConclusionIn the end, creating a cus-

tomized user experience is reallywhat it is all about, and it is up tothe development team to imple-ment the correct changes withinthe environment that make a pos-itive user experience a reality. Theuse of ABAP in the BW environ-ment is widespread and is impos-sible to cover in its entirety withinthis article. However, it is mostcertainly possible to get a solidgrasp of the concepts required tounderstand the what, when, andhow of ABAP programming in BW.

I have attempted to layout, inlogical order, the basic areas inwhich ABAP is used, when it isappropriate to create customizedlogic, and how to go about pro-gramming the environment to getwhat you want out of R/3 and intoBW. Specifically, we covered therelevant aspects of the R/3 envi-ronment, such as the user exitSAPLRSAU_001, and how toimplement basic modifications. Welooked at how the user exit worksand how it is called during run-time. We detailed the basic exam-ples of creating generic extractorsusing base tables in R/3 and inviews or function modules, and welaid out specific tips regarding thesuccessful creation of these compo-nents and how they interact.

Remembering the many thingsthat can be done in BW usingABAP is the key to successfullyaddressing the requirements ofcustomized reporting. We havefurnished you with the basic con-cepts and included examples ofreal situations and logic used inproduction environments. It isnow up to your team to determinehow you may move your environ-ment to the next level.

Arthur "Pat" Pesa, arthurpesa,inc. Pat is a senior independentconsultant specializing in SAPBusiness Warehouse and Applica-tion Link Enabling. He has overnine years of SAP R/3 experience,specializing in ABAP/BAPI devel-opment, Internet based order-pro-cessing systems, and DemandManagement integrations withthird-party Demand Planningsystems. Pat has spent the lastthree years as a Business Ware-house consultant, specializing intechnical leadership roles andsolution design and development.Pat's email address [email protected]. �

In the end, creating a

customized user

experience is really

what it is all about.

Jou

rnalJournal


Feb

ruary/M

arc

h 2

004 V

olu

me I

I Is

su

e 1

ww

w.S

AP

tip

s.c

om

SAPtipsSA

Ptips

JournalJ

ourn

al

The information in our publications and on our Website is the copyrighted work of Klee Associates, Inc. and is owned by Klee Associates, Inc. NO WARRANTY:This documentation is delivered as is, and Klee Associates, Inc. makes no warranty as to its accuracy or use. Any use of this documentation is at the risk of the user.Although we make every good faith effort to ensure accuracy, this document may include technical or other inaccuracies or typographical errors. Klee Associates, Inc.reserves the right to make changes without prior notice. NO AFFILIATION: Klee Associates, Inc. and this publication are not affiliated with or endorsed by SAP AG.SAP AG software referenced on this site is furnished under license agreements between SAP AG and its customers and can be used only within the terms of suchagreements. SAP AG and mySAP are registered trademarks of SAP AG. All other product names used herein are trademarks or registered trademarks of their respective owners.

abap_programmingin sap bw

Documents