STEP BY STEP SAP BI

2012-09-22T23:06:00.001-07:00

What is Web Dynpro?

We present the place and role of the Web Dynpro within the SAP NetWeaver platform. So, we start with the layers of the SAP NetWeaver platform, we continue with the importance of the Application Platform layer, and we conclude with the place and role of Web Dynpro (ABAP and Java) within the Application Server ABAP and, respective, Application Server Java.

As we can see, four layers are distinguished in this context: Application Platform, Process Integration, Information Integration and People Integration.

The Application Platform represents the technical basis of almost all the other SAP products. This is the reason why the Application Platform plays a central role in the SAP NetWeaver.

The Application Platform essentially offers two programming interfaces: ABAP and Java (J2EE). ABAP is the programming interface for Application Server (AS) ABAP and Java is the programming interface for AS Java.

To create ABAP and Java applications, we have two independent development environments: ABAP Workbench for ABAP and SAP NetWeaver Developer Studio for Java.

Both development environments offer the possibility to create web based applications built by using declarative programming techniques based on the Model View Controller (MVC) paradigm.

SAP NetWeaver Developer Studio is the SAP’s own development environment used to develop Java-based multilayer business applications. This development environment is based on Eclipse and offers a Web Dynpro Perspective to create Web Dynpro Java applications.

All the tools we need to create Web Dynpro Java applications are found within the SAP NetWeaver Developer Studio.

SAP NetWeaver components (SAP)

SAP NetWeaver Developer Studio–Web Dynpro perspective

ABAP Workbench is the SAP’s own development environment used to develop ABAP-based multilayer business applications. This development environment offers Web Dynpro Explorer to create Web Dynpro ABAP components

ABAP Workbench–Web Dynpro Explorer

The Application Server ABAP has the structure presented.

AS ABAP (SAP)

As we can see, most of the AS ABAP components can be divided into three layers:

Presentation layer
Business layer
Persistence layer

Web Dynpro ABAP is part of the presentation layer and it’s the SAP standard UI technology used for developing web business applications without knowing HTML or JavaScript.

Web Dynpro ABAP offers many advantages, as follows:

Strict separation between the layout and business data
Re-use and better maintainability through reusability.
Automatic input checks.
Automatic data transport, using data binding.
WYSIWYG (What You See Is What You Get) view editor.

Web Dynpro ABAP and Web Dynpro Java mostly offer the same functionalities. But, of course, there are some differences between them, for example:

Web Dynpro Java, unlike the Web Dynpro ABAP, disposes of a ViewSet that allows us to integrate in a Screen more Views, by using certain pre-defined layouts. In this respect, their common part is the View Container UI Element.
Web Dynpro Java offers graphical tools that ease the programming work, as:Navigation Manager and Diagram View, unlike the Web Dynpro ABAP where we dispose only of a tool used to visualize and to define the window structure.

The Web Dynpro ABAP is what the current book is about. More information about Web Dynpro Java can be found in the Book Inside Web Dynpro for Java by Chris Whealy.

2012-09-22T23:05:00.001-07:00

TRANSACTIONS

GENERAL INTRODUCTION TO TRANSACTION

Transaction, in R/3 system is an operation that lets the user make necessary changes to the database. The entire R/3 system is nothing but set of business transaction. The data transfer from old system to SAP R/3 database, or modifying data, or deleting data, which is not required, is done through transaction.

For SAP system, Transaction is nothing but sequence of steps called as dialog steps and for user it is sequence of screens that appears one after the other depending upon the option he selects. The special transaction monitor called the SAP dispatcher handles the sequence of steps that takes place in any transaction. The main task of transaction is to update database table. The database table is not updated until a transaction is completed. All changes can be rolled back if the transaction has not finished.

The transaction contains two steps which are as following:

· Interactive phase: In this step, user enters the data, which needs to be inserted or deleted or modified on to the screen. There can be single screen or multiple screens depending upon the transaction. So this step can consist of single step or multiple steps. In this phase you prepare database record.

· Update phase: This phase processes the database record and updates the database table. Actual updating of database table takes place in this phase.

All the transactions are associated with transaction code. And all these codes are stored in a table TSTC.

Logical Unit of Work (LUW)

The R/3 system is multi user system and many users access the same information at the same time, which is mainly DATA. Consider the case where one user is modifying a record, and second user is trying to delete the same record. If the second user is successful in deleting the record then the first user will face problem for modifying the record that is already deleted. The avoid such situation, R/3 system has provided Logical Unit of Work, which is defined as a locking mechanism to protect transaction integrity. Of course, there are other measures, which ensures data integrity like check table i.e. foreign key relationship. Within SAP system there are three types of transaction and may be distinguished as:

· Database transaction known as LUW. It can be defined as a period in which operation requested must be performed as a unit, i.e. all or nothing operation. At the end of LUW, either of the database changes are committed or rolled back.

· Update transaction or SAP LUW. One SAP LUW can have several databases LUW. So a set of a database is either committed or rolled back. The special ABAP/4 command COMMIT WORK, marks the end of a SAP LUW.

· ABAP/4 transaction. Is made up of a set of related task combined under one transaction code. ABAP/4 transactions are for programming environment, in which ABAP/4 transaction functions like one complete object containing screens, menus and transaction codes.

R/3 system has provided in built locking mechanism, which defines the Logical Unit of Work. Also user can set his own locking mechanism. The LUW starts when a lock entry in the system table is created, and it ends when the lock is released.

To provide the user the facility to communicate with the table in order to modify or delete or insert data, R/3 has provided tool called SCREEN PAINTER. This tool allows you to design screen, process screen through program and update the database table. SAP has provided one and only one way to update the database table, i.e. transaction. Though you can update database table by using open SQL statement through program, SAP usually doesn’t recommend this kind of updating. Many standard transactions are available to update standard table but if the need arises, the developer should be able to develop new transaction, which allows the updating of database tables. This can be achieved by using various components of screen painter.

Following are the few concepts and steps for creating entire new transaction.

Dynpro concept

A dynpro refers to the screen + flow logic. With screen painter you can develop screen and flow logic. The relationship between screen, flow logic, and program can be shown as follows:

Dynpro, as figure indicates consist of screen and flow logic and places exactly one call to module pool program. A transaction consists of many screens and for each screen flow logic is attached. When the transaction is executed, the screen places a call to flow logic and flow logic in turn places a call to module pool program.

· A module program is usual ABAP/4 program that consist of modules and data declaration.

· ABAP/4 is an event driven language. In module pool program too, events get triggered and these events are handled in flow logic. Flow logic editor is subset of ABAP/4 editor. The system automatically displays the two important events for the flow logic.

· Screen is the important component of dynpro and can be created, designed by screen painter.

Screen Painter

A screen painter can be started by

Development workbench à Screen painter

SE51 transaction code.

Using Screen painter

The process of creating a dynpro includes the creation and definition of all the needed screen components.

The steps involved in creating the dynpro are as follows:

· Create screen and attributes by using screen attribute screen.

· Select and place the needed fields within the screen by using dict/program fields.

· Establish the field attributes to which the screen belongs by using field list.

· Define the flow logic respect to the transaction to which it belongs by using flow logic.

Creating a new Screen

Steps involved are as follows:

· Enter the name of program and number of the screen

· Click on Create

· On “screen attribute” screen enter short description

· Enter screen type. Normally, you select NORMAL option for usual R/3 screen. Other options available are SUBSCREEN & MODAL DIALOG BOX. Modal dialog box is used to establish independent and interactive dialog box while subscreen is screen within screen.

· Next attribute to be passed is NEXT SCREEN. Here you need to specify the next screen number, which must be processed after the current one.

Designing of Screen

Screen can be designed by using FULL SCREEN EDITOR. You can go to full screen editor.

From screen attribute screen

By pressing full screen editor pushbutton

From initial screen of screen painter.

There are two modes available with full screen editor.

· Graphical mode. The graphical mode works similarly to typical window application.

· Alphanumeric mode (rarely used).

Elements of screen

· Text – Standard text or field labels.

· Entry - display field.

· Radiobutton – All radiobutton must be associated with one group.

· Checkbox – Normally used for YES/NO operations.

· Pushbutton – Used for activating particular function.

· Boxes – grouping together many screen elements.

· Subscreens – This is a screen area in which you can display another screen.

· Table controls – This area of screen is similar to table but should be treated as a loop.

· Status - Display output fields containing icon.

All these elements are on the control bar of full screen editor and can be placed on the screen work area by clicking and placing them wherever needed.

Selecting Screen fields

Screen field can be either dictionary objects or program fields. Steps involved in the placing of fields on the screen are as follows:

Click the pushbutton Dict/program fields on the full screen editor

Goto à dict/prog fields.

· Enter table name.

· Click Get from dictionary.

· Select fields.

· Click copy pushbutton.

· Position the cursor where you want those fields to be placed.

To adjust various screen elements, you can use drag and drop facility for screen elements.

Attributes of Screen Elements

The entire element of a screen has some attributes, which determines their behavior.

· General – These attributes are directly managed by the screen painter like name of the element, or text of element or column width and various things associated with the screen.

· Dictionary – These attributes are applicable to fields, which are from dictionary. Various components of dictionary can be attached to this element like search help, foreign key.

· Program.

· Display – Behavior of the element with respect to their display feature.

Attribute dialog box can be displayed by

· Clicking on the Attribute push button on the application tool bar.

· Double clicking on the element.

Field List

This list displays a list of all screen elements together with their screen attributes. One important element of Field list is OKCODE. Any pushbutton is associated with function code as in menu item in menu painter. When the user clicks the pushbutton this code is stored in OKCODE. This OKCODE is created by system without a name and is not visible on the screen. In ABAP/4 this field is work field and is nothing but an area wherein system stores the variable and is the last field of the field list and is invisible, hence user needs to give the name OKCODE. It is not mandatory to give the name OKCODE; developer can give any name to this field.

Screen Flow Logic

You can go to this screen either by

Initial screen of screen painter à Flow logic

From Screen attribute screen à Flow logic

When transaction is executed, the screen is displayed, user enters few fields, selects few functions. Later the screen is processed and processing of screen is done by flow logic. The events that are associated with screen are as follows:

· Process before Output (PBO)

· Process after input (PAI)

· Process on value request (POV)

· Process on help request (POH)

The system automatically displays two very important events or modules in flow logic i.e. PAI and PBO

PBO event

This event is triggered before the screen is displayed. The processing of screen before the display of screen is done in this event. For example, filling in default values in the screen fields.

PAI event

This event is responsible for processing of screen after the user enters the data and clicks the pushbutton. The processing of screen can include displaying another screen, or just displaying list or quitting the transaction itself and many more things. Usually it is displaying another screen. These operations can be carried out in the PAI event. OKCODE plays an important role in this operation.

POV event

Process on value request is triggered when the user clicks F4 key. You can handle this event when the user presses F4 key by writing code for the same in module pool program. Normally when the user presses F4, list of possible values is displayed. The standard list produced by system is adequate for applications you develop yourself. However, you can also have the option of setting up your own documentation and lists of possible values that are more detailed.

POH event

Normally when the user places the cursor on the field and presses F1 function key, the system displays its own Help for that particular field. You can add your own functionality to the Help button by writing code for the same in the POH event.

Module Pool Programming

This component though is not attached to the screen painter, plays important role in transaction. Normally, for reports, on line executable programs are written but for transaction, Module Pool Programs are written. The module pool program contains only modules to handle various events associated with screen and data declaration statements.

System divides the module pool program into several include program. These are global field, PBO modules, and PAI modules. It is entirely user’s decision whether to use these modules or write directly into main program.

Creation of Module Pool Program

You can create module pool program either through

Object browser

System automatically creates the module pool program and for these program which are created through object browser, system creates the include modules.

ABAP/4 editor

It is similar to normal program creation. Type of program should be given ‘M’ and is not created by system.

Communication between Dynpro and Module Program

For each screen, the system executes the flow logic, which contains corresponding events. The control is passed to Module Pool Program. Module Pool Program handles the code for these events and again passes back control to the flow logic and finally to screen. Unlike on line program, in this case, the control remains with flow logic. The switching of control between flow logic and module pool program and back is common process when user executes transaction.

Creation of a Complete Transaction

Steps involved to create a complete transaction

· Create module pool program.

· From screen painter create screens.

· Write flow logic for each screen.

· Write code for all the events in module pool program.

· Check for any error in screen and flow logic.

· Generate each and every component of screen i.e. flow logic and screen.

· Single screen can be tested using Screen Painter.

· Create transaction code through object browser.

· Generate the transaction code.

· User can execute the transaction by entering the transaction code in the command field.

Handling Function Code

The function code or OKCODE is the last field of Field list. Function code can be handled as follows:

During the Designing of the screen, a function code is assigned to pushbutton.

· In field list, developer needs to specify OKCODE as last field.

· In module program it is a global field and can be evaluated in the PAI event.

· A function code is treated in the same way, regardless it comes from pushbutton, menu item or any other GUI element.

A complete example for transaction is shown below:

If you have a screen like the one below:

When the user clicks on the Display button, you want to display details of sflight, with corresponding carrid and connid (which is entered by the user).

Module pool program to handle this particular screen is as follows:

Program YVTEST7.

Tables: SFlighT.

data: okcode (4).

Module input1 input,

case okcode.

when ‘disp’.

Select * from sflight

where carrid = sflight – carrid and

connid = sflight – connid.

Endselect.

leave to screen 200.

When ‘exit’. Leave to screen 0.

Endcase.

endmodule. “input1 input

module user_command_0200 input.

case okcode.

when ‘back’. Leave to screen 100.

endcase.

Endmodule. “user_command_0200 input

When the user clicks on display, control is transferred to screen no. 200 on which you display sflight details & on the same screen, when user clicks on BACK button, he comes back to main screen.

Flow logic for screen 100 is as follows:

Process after input.

Module input.

Flow logic for screen 200

PROCESS AFTER INPUT.

User_command_0200.

MODULES: modules are handled in module pool program.

You need to write flow logic for screen 200 and design screen 200.

In case of transaction transfer of data from program to screen is automatic i.e. you need not transfer the data from program to screen explicitly. The fields, which you define in the screen receives the data from program and displays the same.

The Field Checks

As already mentioned Transaction is the only method, which SAP recommends to update the database tables. Data entered in the database table should be valid and correct. Data entered is validated at each and every point. ABAP/4 offers various methods to validate data and those are as follows:

· Automatic field checks

· Checks performed in the flow logic

· Checks performed in the ABAP/4 module pool program

Automatic Field Checks

These checks are based on the field information stored in the dictionary. These checks are performed by the system automatically when the user enters the data for the screen field. System performs these checks before PAI event is triggered. Types of field checks performed by system are as follows:

· Required input

While designing the screen, for particular screen field if you click the Req. Entry checkbox, the field becomes mandatory. When the transaction is executed if user leaves this particular field blank, the system displays error message. User cannot proceed until the user enters some data.

· Proper data Format

Each field has its own data format whether it is table field or screen field. Whenever data is entered, system checks for the proper format of the data. For example date. Each user has its own format for date, which is defined in the user master record. If the date defined in the user master record is in the format DD/MM/YYYY, if the user enters the date, say, in YY/DD/MM, the user displays the error message. System also checks for the value of month or days. For example if month entered is greater than twelve then the error message is displayed.

· Valid Value for the Field

In data dictionary two tables are related by Primary key-Foreign key relationship. Whenever the user enters the data, the system checks for the check table values. Also in Domain, if you have fixed values, then the system checks for these values.

Automatic field checks are repeated each time the user enters the data.

About at Exit – Command

Automatic field checks can be avoided by AT EXIT-COMMAND, which works exactly the same way as Cancel works on application tools bar. In the R/3 screen, if you want to quit the processing of that particular screen without entering the mandatory fields, user can click the Cancel button. Same functionality can be incorporated in the user-defined transaction by using AT EXIT-COMMAND. This module can be called before the system executes the automatic field checks and it goes without saying that before PAI event. Code for AT EXIT-COMMAND in flow logic and in module pool program can be written as follows:

In module pool program.

Module exit.

Case okcode.

When ‘Exit’.

Leave to screen 0.

To achieve this kind of functionality a pushbutton or menu item should be assigned a function type ‘E’. It tells the system to process this particular module before carrying out any field checks.

Flow Logic Validations

Consider the case where you want user to enter only ‘LH’ and ‘SQ’ for sflight-carrid. In this case, you are restricting value of a screen field. This cannot be achieved by automatic field check. Hence there is a need of additional validation. It can be done in flow logic by using following statement:

Field --------------- Values

Syntax

PAi.

Field sflight-carrid values (‘LH’).

For multiple values

PAI.

Field sflight-carrid values (‘LH’ ‘SQ’).

Field sflight-price values (between 1000 and 2000).

In this case when the user enters the value, PAI is triggered and field is checked for that particular value. If the value entered happens to be wrong, that field is enabled for user to enter. If you have multiple Field statements in your flow logic, it is sequential execution.

Consider the following case:

PAI.

Module assign.

Field sflight-carrid values (‘LH’ ‘SQ’).

In ABAP/4

Module assign.

Data: carrid1 like sflight-carrid.

Carrid1 = sflight-carrid.

Endmodule.

In this case, Sflight-carrid is used in the flow logic before the field statement. The system will give invalid value or some previous value as the field sflight-carrid is used in module before it is checked i.e., field statement is after the module in which sflight-carrid is being used. The field is not available to the system unless it executes the field statement. Field statement transfers the values to the program and is done only once. If you don’t have Field statement in your flow logic, transfer of values takes place in PAI event.

Consider one more case where you have multiple field statement.

PAI.

Field Sflight-carrid values (‘LH’).

Field Sflight-connid values (‘0400’ ‘0500’).

In this case if the user enters only carrid wrong, then this particular field is enabled and rest of the fields are disabled for user to input. Many times if the user enters wrong value for one field, then you might want to give option to user to enter all the fields, which is not possible by using Field statement only. This functionality can be achieved by Chain – endchain.

Syntax

Chain.

Field sflight-carrid value (‘LH’).

Field sflight-connid values (between ‘200’ and ‘500’).

Endchain.

Field sflight-price values (‘100’ ‘1000’).

In this case, if the user enters wrong value only for carrid, both the fields i.e. carrid and connid are enabled as they are grouped together in the Chain statement. The field price will be disabled for input. Usually, logically related fields are grouped together with Chain-Endchain statement.

Module Pool Program Validations

Checking fields ABAP/4 program includes

· Field statement in flow logic.

· Module statement in ABAP/4 module pool Program.

Syntax

PAI.

Field sflight-carrid module <name>.

This module can be handled in the main program i.e. module pool program.

In ABAP/4 program

Module Check.

Select single * from sflight where carrid = sflight-carrid.

If sy-subrc ne 0.

Message e001.

Endif.

In this case, field sflight-carrid is checked in the table for its existence.

Dynamically Calling the Screens

About Displaying Next Screen

Transaction is a sequence of screens, which are displayed one after the other. The next screen displayed depends upon the attributes of first screen. In attributes you need to give Next Screen number i.e. if next screen displayed should be 200 screen, then this number should be given in next Screen attributes. These are static attributes of the screen. By default, if nothing is specified in the program, the system branches out to the screen number, which is specified in the attribute screen.

But this doesn’t happen always. If you have many pushbuttons on the screen like the one in the following case:

In this case, if user selects MARA pushbutton, then fields from Mara table are displayed. When the user clicks on the MARD, then the fields from MARD table are displayed. Depending upon users selection, the screen is branched out and this has to be done during runtime. This functionality can be achieved by dynamically calling the screen in module pool program.

The screen can branch out to new screen depending upon user selection. Following command in module pool program can do this:

· Set Screem

· Call Screen

· Leave to screen <number>

All these commands override the specifications given in the attributes. This overriding is temporary. The values stored in the attribute are not changed.

Set Screen

Syntax

Set screen <number>.

In module pool program

Case okcode.

When ‘Disp’.

Set screen 200.

When ‘List’.

Set screen 300.

Endcase.

In this case, the entire processing of current screen takes place and then the system branches out to next screen. If you want to branch out to the next screen without processing the current screen, LEAVE SCREEN should be used along with the set screen.

For Example:

Case okcode..

When ‘Disp’.

Set screen 200.

Leave Screen.

When ‘List’.

Set screen 300.

Leave Screen.

Endcase.

When SET SCREEN is used, control cannot be transferred to the main screen or previous screen, unless you write code for the same.

Call Screen

Usually used for pop up screens. Many times, there is a need for user to enter additional information or secondary information on another screen or pop up screen. Once the user enters the data, he should be able to go back to main screen or to the screen where he started. This is not possible by using SET SCREEN. CALL SCREEN achieves this functionality.

Syntax

Call Screen 200.

Will simply call a screen number 200 from a main screen. Once the screen is displayed the user can enter all the data and return to the main screen by clicking back button.

To call screen as pop up screen the syntax is

Call screen starting at <col.no.> <line no>

Ending at <col no> <line no>.

In this case window will be popped as window and user can close it by using back button.

Leave to screen

To SET a new screen without processing current screen, you need to use the following two statements together:

SET Screen 200.

Leave Screen.

Or a Single statement

Leave to screen 200.

Subscreens

A subscreen is a screen within screen. Consider the following case.

If user clicks on First pushbutton, you want to display details of MARA table and if user clicks on the second pushbutton, you want to display details of mard table. You can do this by calling two different screens. But the information will be displayed on the next screen. Displaying data on the same screen is possible by using Subscreens.

Step to create a subscreen are as follows:

· Create a subscreen area on main screen and name it.

· Create a separate screen of subscreen type.

· Arrange the fields on this screen so that they fit in subscreen area exactly. Only when it is larger, the part of the screen that fits in the main area will be visible.

· Write code for calling subscreen in flow logic.

To call subscreen, from your flow logic, you need to include the statement both in PAI and PBO.

Syntax

PBO.

Call subscreen <area> including <prg name> <’screen no’>.

PAI.

Call subscreen <area>.

Area - is the name of the area on main screen.

Prg. Name - is the name of the module pool program.

Screen number - is subscreen screen number.

Some of the don’ts with subscreen are:

GUI status cannot be set to the subscreen

· OKCODE is not applicable to the subscreen.

· Subscreen cannot call another screen.

· It cannot contain at Exit-Command.

You can call multiple subscreen in the same area (at any given point of time, only one subscreen can be called in the subscreen area) and is done dynamically during runtime by using variable screen number.

Table Controls

A table can be created in transaction. These tables when designed on the screen are called as Screen Tables. These screen tables are of two types viz.

· Table controls

· Step loops

Though these are tables when code is written to handle them, the tables are treated as loops.

Features of Table Controls

· Data is displayed in the form of table when many records match the criteria.

· Table control gives user the feeling of an actual table.

· You can scroll through the table vertically and horizontally.

· You can select rows and columns

· Resize the width of a column

· You can have separator lines in between rows and columns

· Automatic resizing of the table when the user resizes the window.

In general table control includes all the features of an actual table and user gets the feeling that he is actually working with table. You can update information in table control and it can be updated in the database table by writing code for it.

Steps associated for creating complete screen table are as follows:

· Declaration of table control in module pool program.

· Designing of table control on the screen.

· Passing data to table in flow logic.

Declaring of Table Control in the Module Pool Program

Syntax

Controls TCI type Tableview using screen <screen no.>

When you use table control in a screen you must declare the structure in module pool program. Important fields of tableview are as follows:

· Lines – number of displayable rows in a table.

· Top_line – the row of table where the screen displays start.

· Current_line – The row currently being processed inside a loop.

When you process the table control in flow logic depending upon where you want to start display of rows, you need to use these variables.

Designing Table Control on Screen

· To design table control on the screen, you need to click on Table in control bar and place it on the screen. You can adjust the length and width of table control.

· Name the table control. (Here you need to use same name which you have used for declaration of table control in module pool program)

· From dictionary object, select table fields and place them in the table control.

Passing data to table Control

As already mentioned, table controls are tables but are treated like loops. Usually transfer of data from program to screen is automatic. But in case of table control, transfer of data is not automatic. You need to explicitly transfer the data to table control. ABAP/4 provides loop statement, which is associated with flow logic to transfer the data. Because table control is treated like a loop, data from where it is transferred should be a loop. You cannot transfer the data by only select statement; you need to put the data into internal table. ABAP/4 provides the LOOP statement, which is associated with the flow logic and allows you to loop through the table control and internal tables. In between LOOP-ENDLOOP, you can use most of the flow logic keywords like field values. Module etc.

You need to code a LOOP statement in both PBO and PAI event of the screen. With LOOP statement, you can transfer the data from program to table control and vice versa. That is, if user updates the value in the table control, you can update database table with its value. And this can be done in PAI event. So even if you are not updating database table through the table control, you need to put the LOOP statement in the PAI event also.

Syntax

PBO.

Loop at <internal table> with control <table control name> cursor <scroll variable>

PAI.

Loop at itab.

Proper usage of Table Control is as follows:

In flow logic.

PBO.

LOOP at iTAB with control Tc1 cursor tc1-top_line.

Module assign.

Endloop.

Pai.

loop at itab.

endloop.

Considering, we have following fields in table control and the screen looks like this:

In module pool program

Control TC1 type tableview using screen 200.

Module assign.

Sflight – carrid = itab – carrid.

Sflight - connid= itab - connid.

Sflight - fldate= itab – fldate.

Endmodule.

The transfer of the data from program to table control takes place in steps and these steps are as follows:

· With LOOP AT statement the first row is picked up and placed in the header of the internal table.

· Whatever statements you have in between LOOP-ENDLOOP are executed. In this case, you have Module statement. In Module statement, value of internal table is assigned to table control field.

· The row in internal table is transferred to the first line of the table control as stated in the LOOP AT statement.

· The system encounters the ENDLOOP statement and Control is passed to the next line of the internal table.

· In the same way, all the records of the internal table are passed to the table control.

STEP LOOPS

Step Loops are type of screen table as already mentioned. Step loops are repeated blocks of field in a screen. Each block contains one or more fields and these blocks are repeated. Step loops aren’t like actual table. You can scroll vertically but not horizontally. Three steps are associated with creation of step loops:

· Creation of step loops on screen, which includes declaring fields on the screen and then defining the step, loops for these fields.

· Passing data to the step loop is exactly similar to the passing of data to table controls.

· In step loop, you don’t need to define the step loop as such in the module pool program but the cursor needs to be defined in the program.

Types of Step Loops

· Static – Static Step Loop (SSL) have fixed size that cannot be changed during the runtime. If user resizes the window, the size of the static step loop is not changed.

· Dynamic – Dynamic Step Loop (DSL) is variable in size. When the user resizes the window, the system increases or decreases the number of the step loop blocks.

You can have only one dynamic step loop and can have as many static loops in your transaction.

Programming with the Static and dynamic step loop is exactly same. For the system or for the user it doesn’t make any difference whether it is static or dynamic step loop. Only attribute, which you fix during designing of the step loop, is type attribute for step loop F for fixed i.e static and V for variable i.e. dynamic.

Writing code for Step Loop in the flow logic.

PBO.

Loop at itab cursor cl.

Module set.

Endloop.

PAI.

Loop at itab.

Endloop.

* Empty loop is must for both table control and step loop

LOOP AT statement for step loops and Table controls is similar. Loop At statement transfers the data to screen table. You need to have the Module to assign the values for the screen table.

In module pool program you need to define the cursor.

Date: CL TYPE i.

* Cursor parameter tells which line of step loop display should start.

“Module Set” in module pool program assigns the values to step loop fields, which is similar to table controls.

Branching to List Processing

Switching To List Mode

You can display a list within a transaction.

You can produce a list from module pool program by using the command

Leave to List-Processing.

This statement switches the system from dialog mode to list mode. And from this point onwards until you return to dialog mode, you can use all the normal report statement like write, select or any other event.

Returning back from LIST mode

You can return back to dialog mode by clicking the BACK button.

You can have your GUI status and write code for the same. You can include the command LEAVE LIST-PROCESSING. When the system reaches this command, it leaves the list mode and returns to the dialog mode.

Help & Value Request

In any transaction, When the user presses F1 or ? on a field, System provides the help facility for that particular field. In dialog program, when F1 is pressed, help provided by R3 system is sourced from data element documentation. If this documentation is not present for that particular field or if user needs to display additional information for that particular field, then user defined help can be provided through PROCESS ON HELP REQUEST.

In ABVP/4 help can be provided to the user by:

Data element documentation: The F1 help can be enhanced, by adding an additional text for the data element in ABAP/4 dictionary.

It can be done with the help of following steps:

Place cursor on the screen field,

GOTO à DOCUMENTATION à DATA ELEMENT DOCUMENT

You can now extend the existing help.

USING THE PROCESS ON HELP-REQUEST.

If you don’t have this event in a program, then the documentation of the field in the ABAP/4 dictionary is taken into consideration. If this event exits in the program then it is executed.

Process on HELP-REQUEST event

This event is triggered when user presses F1 on a screen field. You need to handle this event in flow-logic by specifying the fields and attaching the module to it.

Syntax

PROCESS ON HELP –REQUEST.

FIELD SFLIGHT-CARRID MODULE HELP-FOR-CARRID.

In module pool program

MODULE HELP.

Write : `This is field is from sflight table’

Write : / ‘It is of four Character’.

ENDMODULE.

When the user presses F1 on this particular field, then this message will be displayed on the screen.

Value Request

Whenever the user presses F4 on the screen field list of possible values, particular fields are displayed. If the standard value-help is inadequate or if you want to display additional fields or with different combination of fields, developer can program this in PROCESS ON VALUE-REQUEST event in the flow-logic and subsequent module in the module pool program. When the user presses F4, list of possible values are displayed either from matchcode objects or check table or help view or domain. Each one of them is explained briefly.

Matchcode objects: Are aggregated dictionary objects and detailed procedure to create these objects is explained in the later part of the material.

Check Table: If a check table is assigned to the table field and if the user presses F4 for that particular field, then all the key fields are displayed.

Domain Values: The values defined in the domain are displayed. These values are set in domain when the domain is created in the dictionary.

Help views: In cases where the check table is not sufficient, you can create a help view with this check table, which gives additional information like explanatory text for the fields of the check table.

PROCESS ON VALUE_REQUEST.

Each time the user presses F4 on the screen field, following algorithm is called internally.

When the user presses F4 on flight number, the following screen is displayed.

Flow-logic code

PROCESS ON VALUE-REQUEST.

FIELD SFLIGHT-CONNID MODULE HELP-FOR-CONNID.

Code for module pool program.

MODULE HELP-FOR-CONNIDINPUT.

DATA: BEGIN OF ITAB OCCURS 0,

CONNID(50),

END OF ITAB.

REFRESH ITAB.

ITAB-CONNIDI= POSSIBLE VALUES FOR CONNECTION ID’.

APPEND ITAB.

SELECT CONNID FROM SFLIGHT INTO TABLE ITAB.

CALL FUNCTION ‘POPUP_WITH_TABLE_DISPLAY’

EXPORTING

ENDPOS_COL = 45

ENDPOS_ROW = 25

STARTPOS_COL = 10

STARTPOS_ROW = 1

TITLETEXT = ‘TEXT’

IMPORTING

CHOISE = Some Integer Variable

TABLES

VALUETAB = ITAB

EXCEPTIONS

BREAK_OFF =1

OTHERS =2.

ENDMODULE. “HELP-FOR-CONNID INPUT

Changing The Screen During Runtime

The attributes are assigned to the screen field when the screen is designed in full screen editor. Such kind of assignment is static, which means that these attributes are fixed. But many times the need to change the attributes of the screen arises. And this has to be done during runtime.

Need To Change Screen

There can be a requirement in the transaction that, certain fields on the screen

Appear only in certain conditions.

Are in Change/display mode according to user inputs

Become mandatory subject to specific inputs.

Changes its format depending upon certain conditions.

Modifying the screen

At the runtime, attributes for each screen field is stored in system defined internal table, with header line, called as SCREEN TABLE. It contains name of field and its attributes. This tab le can be modified during the runtime i.e. through module pool program. Screen table has following fields:

Field Name Length Description

NAME 30 Name of screen field

GROUP1 3 Field belongs to field group1

GROUP2 3 Group 2

GROUP3 3 Group 3

GROUP4 3 Group 4

ACTIVE 1 Hide/Show

REQUIRED 1 Field input is mandatory

INPUT 1 Enable/Disable

OUTPUT 1 Field for display only

INTENSIFIED 1 Field is highlighted.

INVISIBLE 1 Field is suppressed.

LENGTH 1 Field output length is reduced

DISPLAY 3D 1 Field is displayed with 3-D Frame

VALUE_HELP 1 Field is displayed with Value help

E.g., SCREEN-ACTIVE = 0 has the same effect as the following statements.

SCREEN- INPUT = 0.

SCREEN-OUTPUT = 0.

SCREEN-INVISIBLE = 1.

The fields SCREEN-NAME and SCREEN-GROUP 1 through SCREEN-GROUP4 tell you which field and / or field group has the attributes.

You can assign up to 4 groups to a field.

You need to program screen modifications in module, which is processed during the event PROCESS BEFORE OUTPUT.

`SCREEN’ is an internal table and, in order to change the field values, LOOP statement has to be used so that the header-line can be populated with the new values, changing the earlier values, the SCREEN table consisted for the specific screen. Finally the changed record in the header-line is NOT APPENDED, but is MODIFIED to the SCREEN table. That is, we first use `LOOP AT SCREEN’ and then assign the values. And finally PRIOR TO ENDLOPP give `MODIFY SCREEN’.

PROCESS BEFORE OUTPUT.

MODULE MODIFY_SCREEN OUTPUT.

MODULE MODIFY_SCREEN.

LOOP AT SCREEN.

IF SCREEN-NAME = ‘SFLIGHT-CARRID’.

SCREEN-INPUT = 1.

MODIFY SCREEN.

ENDIF.

ENDLOOP.

ENDMODULE.
Working with Matchcode Objects

A Matchcode is an aggregated object and it gives list of possible values for the user. A matchcode is a collection of search terms on which you retrieve a data from the database table.

All matchcode are associated with either selection criteria or parameters. When an input field has a little triangle in the right-hand corner, it indicates that it has an associated matchcode. When you click on drop-down arrow or press F4 button, it gives a list of all possible values. For example Matnr field i.e. material number from MARA table, user might not know all the material number, but they might know other details like material description, type or any other details. You can create matchcode, which has all these search terms i.e. you can create matchcode with description as search term or matchcode with type as search term.

R/3 system includes many predefined matchcode but developers can create new matchcode as is created in following case. Usually, system displays list of possible values for all the primary keys with particular search term. Usually you create matchcode in following cases:

When you use non-primary key of input.

You need different search term for the primary key.

Creating Matchcode object

Entire Matchcode object is created in two steps:

Defining of Matchcode object.

Defining one or more search ids for the object.

Defining Matchcode object

It includes all the tables and fields, which make up the Matchcode, which are used for Matchcode Ids.

Steps for defining Matchcode object are as follows:

From dictionary, enter name (four character).

Select Matchcode radiobutton and click on CREATE.

Define attributes for the object i.e. description.

Select primary table.

Select the fields for the table by clicking on the fields.

Activate the object.

If at all you are selecting secondary table then it is done after selecting primary table.

And steps are as follows:

Tables à Choose secondary table. A dialog box appears, which displays list of possible secondary tales. Select the table by Choose à copy.

To activate the object, Matchcode object -à activate

Creating Matchcode ids.

Once the object is created, you need to define search term for the object and steps are as follows:

Click on the Matchcode ID from maintenance screen.

Enter attributes for the Matchcode Id.

Short text.

Update type - Default is 1 for logical updating. It means that at the moment when you access the Matchcode object, the table is created like view. Unlike logical updating, physical updates are: A,S,P.

System Matchcode: If you click this particular field, it indicates a system matchcode, which is used by SAP software and cannot be changed by the end user.

Autho.checks: If it is checked, the system performs authorization checks for this matchcode Id.

Selecting secondary tables

Position the cursor on the base table of the ID.

Edit à Choose secondary tables

A dialog box appears listing the tables linked to the table by foreign keys

Select table.

Save.

Selecting fields for Matchcode Id

Select fields.

Choose fields.

Once all the fields are selected, click on copy fields.

Fields are transferred to the matchcode Id.

Activation of Id

A corresponding database view is created in the database during activation for the Ids of update type I. During activation, a check is made to see whether the corresponding index to support view selection exists in the database. If it doesn’t, a warning is displayed.

Testing the Matchcode Id.

To test the matchcode Id: Maintain matchcode object.Utilities à display matchcode data.

Using Matchcode

When the user do not know which matchcodes are available for a field, user can find the matchcode by:

Positioning the cursor on a field and clicking on drop arrow or pressing the F4 key.

A dialog box appears with a list of available matchcode

User can select another matchcode by clicking on the NEW selection button.

Double click on a matchcode to use it. If you want to use this as default matchcode, click on standard button. If user does this once, the selected matchcode is proposed automatically the next time.

You can enter the search term and press ENTER. If search term is not specified, the system displays all the records for the specific matchcode.

Lock Objects

In a system where many users can access the same data, it becomes necessary to control the access to the data. In R/3 system this access control is built-in on database tables. Developers can also lock objects over table records.

To lock an object you need to call standard functions, which are automatically generated while defining the lock object in ABAP/4 dictionary. This locking system is independent of the locking mechanism used by the R/3 system. This mechanism also defines LUW i.e. Logical Unit of Work. Whenever an object is locked, either by in built locking mechanism or by function modules, it creates corresponding entry in global system table i.e. table is locked. The system automatically releases the lock at the end of transaction. The LUW starts when a lock entry is created in the system table and ends when the lock is released.

Creating Lock Objects

Lock object is an aggregated dictionary object and can be defined by using the following steps:

From initial data dictionary screen, enter the name for the object, Click Lock object radiobutton and then click on Create. The system displays a dialog box for Maintain Lock Objects screen
Enter short text as usual and the name for primary table.
Save
Select Tables option

From this screen you can:

Select secondary tables, if any, linked by foreign key relationship.

Fields for the lock objects. This option allows you to select fields for objects (R/3 system allows locking up to record level). Lock object argument are not selected by user but are imposed by the system and includes all the primary keys for the table.

Types of locks

You can lock the table or record by using following types of locking:

Exclusive (E) the locked data can only be displayed or modified by single user i.e the owner of the object. Access to other users is denied.

Shared (S) several users can access the same record simultaneously, but only in display mode and except the first one, who has asked for the data in update mode.

Exclusive not cumulating (X) it is similar to exclusive lock. It allows only a single user access. E can be called several times from the same transaction. In contrast, a lock type X can be called only once during the transaction. Any other call for this lock is rejected.

Activation of Lock Object

When you activate the lock object, the functions are automatically generated. And these are ENQUEUE-EZN and DEQUEUE-EZN. EZN is name of the lock object.

While ENQUEUE is used in program to set the code over the selected data depending upon the lock object arguments. DEQUEUE is used to release the lock.

EXERCISES

1. Create a matchcode for MARA-MATNR with one matchcode ID. The fields in the ID should be MARA_MATNR., MARD-WERKS. MARD-LGORT. MAKT-MAKTX.

2. Create a GUI status of type list with the following features and attach it to a report. (Create a simple report with Write statement).

Use the statement SUBMIT REPORT AND RETURN TO CALL A REPORT.

REPORTS SYSTEM HELP

Materials

Vendors

Exit

Application tool bar: 3 push button - Material, vendors, exit.

When material push button or menu option is chosen to display a list a materials with the following fields:

MARA-MATNR, MARD-WERKS,MARD-LGORT,MAKT-SPRAS.

When vendor pushbutton or menu option is chosen, display a list of vendors with the following fields.

LFA1-LIFNR, LFA1-NAME1, LFA1-ORTO1.

Exit to quit the program.

3. Create a transaction with three screens

Screen 1:

Radiobutton : 2 R1,R2.

Pushbutton :2-Next, Exit,

When NEXT button is pressed, display screen 2 or screen 3 on the radio button selected.

i.e., if R1 is selected display screen 2 or if R2 is selected display screen3.

Screen 2:

Entry fields : SPFLI-CARRID, SPFLI-CONNID,SPFLI-CITYFROM, SPFLI-CITYTO.

Pushbutton : First screen, Exit.

Screen 3.

Entry fields : SFLIGHT-CARRID. SFLIGHT-CONNID.SFLIGHT-FLDATE.SFLIGHT-SEATSMAX,SFLIGHT-SEATSOCC.

Pushbuttons: First screen, Exit.

`Firstscreen’ pushbutton is to display screen 1 and exit is to quit the transaction.

***********USE SELECT-SINGLE*************

4. Create a transaction with on screen.

Screen one

Entry fields: MARD-MANTNR,MARD-WERKS,MARD-LGORT

Pushbuttons: Firstrecord Next Record, Previous record, Last Record, Exit.

Select the data from MARD into an internal table and whenever a button is pressed display the corresponding record (i.e. First, Next, Previous, or Last) using the internal table index.

Exit to quit the transaction.

5. Copy above transaction and enhance it with these features. Place another pushbutton ‘List’. When this button is pressed, Display a list with the following fields. MARD-MATNR,MARD-WERKS,MARD-LGORT.

**********Use LEAVE –TO-LIST-PROCESSING***********

6. Create a transaction with two normal screens and two subscreens.

Screen1 : Normal screen.

Entry fields : MARA-MATNR

Radiobuttons: Plant, Description

Push-button :Display, Exit.

Screen2: Normal screen.

Display fields: MARA-MATNR.

Pushbuttons:Back,Exit.

Screen3: Subscreen.

Display fields: MARD-WERKS,MARD-LGORT.

Screen4: Subscreen

Display fields:MAKT-SPRAS,MAKT-MAKTX.

When the display pushbutton is clicked, display Screen2 with proper subscreen attached to it based on the selection of radio button..

i.e. Screen 3 - if plant is selected and Screen 4 - if description is selected.

2012-09-22T23:04:00.005-07:00

SAP Easy Access

Abstract This chapter presents the SAP Easy Access, highlighting some aspects found in our everyday work. So, we show how to change the standard settings, how to add in the Favorites list the frequently used transactions, and how to create a Shortcut on the Desktop.

SAP easy access starts automatically after logging-in into the SAP system. In the left side, we can see the user menu. Here are the functions the user needs to perform his tasks.

SAP easy access

Changing the SAP Easy Access

U.Gellert and A.D.Cristea,Web Dynpro ABAP for Practitioners,

DOI 10.1007/978-3-642-11385-7_2, # Springer-Verlag Berlin Heidelberg 2010

We can change the SAP easy access settings through the menu Extras -> Settings,

by specifying settings as follows:

The place of the Favorites
The presents of the menu
The easy access picture in the right side of the screen – to be present or not
Displays or not the technical names

Settings

Favorites List

The user menu is mostly defined by the administrator, but we can define our own Favorites list. Here, we can create our own list of favorites containing items as transaction, files, web addresses or other objects.

To add new transactions in the Favorite list, we can choose from the menu Favorites ->Insert Transactions

Inserting transaction onto the Favorites list

As a result, the new item appears in our Favorites list

Favorites list

We can find the list of the SAP transaction codes in the transparent table TSTC. Besides the transactions predefined in the system, we can create our own transactions (e.g. with transaction SE93) which are going to be inserted in this table.

Every time we use a transaction, the system verifies in this table whether the transaction exists and if we have the proper authorization to use it.

As support for our daily tasks, we add here some of the transactions we use in this book

Transactions used

To add other objects, we can choose them from the menu Favorites ! Add Other Objects

Adding new objects in Favorites list

We add the web address to open the SDN page

Inserting a web address

We can use Favorites -> Download to PC to save on our computer a list with all the objects we have in the Favorites folder. To upload in a Favorites folder objects from a list saved on our computer, we can use Favorites -> Upload from PC.

Setting a Transaction as Start Transaction

We have the possibility to set a transaction as start transaction:Extras -> Set start transaction .In this way, the desired transaction is automatically started after logging-in into the system (in our case the SE80 transaction), and we don’t see the SAP easy access anymore. saved on our computer, we can use Favorites -> Upload from PC.

Setting the start transaction dialog box

Creating a Shortcut

After installing the SAP GUI, a SAP logon icon appears on our desktop. By using this logon, we can login into the system. Additionally, we can create a SAP logon shortcut to be used to perform the same logon, but we don’t need to fill all the entries in the logon form. A SAP shortcut allows us not only to perform a logon into the system, but to execute other commands, too. So, we can start a SAP transaction, run a report or perform a system command.

To create a SAP Shortcut on our desktop to start the transaction SE80, we can use the Wizard available in the layout menu, by clicking on the respective icon located in the system function bar.

Creating a SAP Shortcut on our Desktop

Another possibility to create a SAP shortcut on our desktop is to select a transaction or another object from the Favorites list, and to use the menu Edit -> Create Shortcut on the Desktop.

2012-09-22T23:04:00.003-07:00

Designing a Web Dynpro Component

Abstract The present chapter is dedicated to the constitutive elements of a Web Dynpro ABAP component. Moreover, we show how to use the ABAP Debugger to execute, by line or by section, a Web Dynpro application, and how to use the new tool offered by ABAP Debugger to reach the context attributes values.

In order to develop a Web Dynpro ABAP component, we have to open the ABAP Workbench of the Application Server ABAP.To work with ABAP Workbench, we need an authorization as a developer or developer key, and for the SAP NetWeaver ABAP trial version we can use BCUSER, automatically registered as a developer.Web Dynpro is available with release SAP NetWeaver 2004s and later. After logging into AS ABAP, we can use the transaction SE80 to call the object navigator.

Object navigator

All the repository objects we develop with the ABAP Workbench tool we build by using the Object Navigator. Here, we develop not only Web Dynpro applications,but also other development objects (e.g.reports,database tables, data elements,classes, function modules, etc).

The development objects we create as customer have the first letter “y” or “z”. Therefore, we created a Web Dynpro component with the name y_wd_component.

We have to assign all the development objects created with ABAP Workbench to a package. We can use the default package “$TMP” to create test programs without transporting, or we can create our own packages. We choose to create our own package, named Y_WEBDYNPRO.

Creating the package Y_WEBDYNPRO

We have chosen the package type “Not a Main Package”, because this package holds development object and not other packages.

After creating the package, we create a Web Dynpro component, as follows:
right-click on the package name and, from the context menu, we select Create -> Web Dynpro -> Web Dynpro component. We have to enter the component name, a short description, the type we want to create, the view name and the window name

Creating a Web Dynpro component

After saving our component, we have to assign it to our package

Assigning the component to a package

As a result, in Object Navigator we can see the Package Y_WEBDYNPRO and our first created Web Dynpro Component.

The content of our package

The name of the development objects marked in blue are not active. After creating the Web Dynpro component, we have to activate it.

WD component activation

View

Each Web Dynpro application has at least one view. Each View has a view Layout, where we can add different UI (User Interface) elements that can be nested one in the other one, to create the screen. The positioning of the UI elements in a view is realized by using the layout and data layout.

Each View has a view controller that is automatically created for this view and each View has several tabs (Properties, Layout, Outbound Plug, Inbound Plug, Attributes, Context, Actions and Methods). This indicates that a View consist of many parts.

View Layout.

The screen content of a view is designed in the Layout tab. The View Layout is divided in three areas:

UI element library
View designer
Context menus, UI elements properties and UI element hierarchy.

View Layout

the UI Elements are grouped in a library to be accessed via the View Layout. We have several ways to add an UI element into the view layout. For example:

By right-clicking on the ROOTUIELEMENTCONTAINER
By dragging & dropping

Adding UI elements into the view

All the UI Elements we enter into a screen are children of the node ROOTUIELEMENTCONTAINER and are represented as a hierarchy where ROOTUIELEMENTCONTAINER is the top of this hierarchy. With “Swap Root Element” we have the possibility to transform ROOTUIELEMENETCONTAINER from a Transparent Container into another UI element (Table, FlashIsland, Group, etc.).

In this way, we can use, for example, the FlashIsland UI element to integrate Adobe Flex into our web Dynpro component. This transformation is possible only if the ROOTUIELEMENTCONTAINER doesn’t have any child UI elements.

Adding UI elements into the view

In our ROOTUIELEMENTCONTAINER, we insert one Group UI element, one InputField UI element, one Label UI element, one TextView UI element and one Button UI element

View Layout

If we select individual UI elements in the layout of a view, their properties are displayed in the Properties area. In this way, we can change the properties of each element. For example, we have changed the property design of the button UI element and the property state of the InputField UI element.

As a result of changing the property state of the InputField UI element from the Normal item to the required one, the label associated to this UI element becomes a red star and the end user knows that this value is mandatory.

For a property, we can create fixed character strings, we can choose from a list, or we can bind properties to context nodes or attributes by using the Binding button. For the text property of an UI element Button, we have created a fixed character string “Save”. For the design property, we have chosen from the list one of the supported designs.

UI element properties

We need to bind the value property of the InputField UI element and the text property of the TextView UI element. To be able to do this, we will create two context attributes

By using “Context Menus” we have the possibility to create, for an application, our own context menus displayed in the Browser when the user presses right click on an UI element. In standard mode, the web Dynpro Framework offers the default context menus with certain functionalities, e.g. hiding an UI element displayed into the Browser. After running the application, we can test this standard mode by rightclicking on the inputField UI element.

Context View

The data are stored in the context and the UI Elements are the only objects the user interacts with. Every View has a Context View where we can create context nodes and attributes. Via data binding, the context of a view controller provides a view with all the required data. For our application, we create two context attributes named NAME and GREETING, of STRING type.

To put the data on the screen and to read data from user, we connect the proper UI Elements properties with attributes or nodes.

In our case, we connect the property value of the InputField UI element with the NAME attribute. To create a greeting for the user and to show it after the user presses the Save button, we connect the property text of the TextView UI element with the GREETING attribute. These connections are known as data binding.

Creating an attribute in context view

Data binding

The effect of the binding is that, at runtime, any data changes are transported in both directions and these changes affect all the properties bound to this element.

Actions

Some of the UI Elements have special events that are linked with the user actions. The UI element Button is one of these UI elements and that’s why we have to create an action that reacts to the user interaction. To do this, we use the Action tab.

Creating an action

As we can see, each action has a corresponding event handler method, automatically generated by the Framework. An event handler method is a special method of a view controller that has the ONACTION prefix followed by the action name. For the SAVE action, the Framework generates the ONACTION event handler. After creating an action, we can assign it to an UI element that has attached an event.

Assigning an action to an UI element

After generation, this method is empty, but we can fill it with source code by using the Methods tab.

Methods

In the Methods tab of a View, we can find some types of methods (e.g. event handler methods, Hook methods, user-defined instance methods).

In our case, in the Methods tab we can find the Hook methods, automatically generated by the Framework, and our event handler method ONACTIONSAVE

Methods tab

With double-click on the method name, we open the ABAP editor.In this way, we can insert the source code.

ABAP editor

The user enters his name that we use to show a greeting message with the help of textView UI element. To create a greeting for the end user, we concatenate his name with the string “WELCOME” and we pass this string value in the GREETING attribute. After this, we reset the inputField UI element. To do this, we pass an empty string into the NAME attribute bound to the corresponding UI element

On action save event handler method

 METHOD onactionsave .
 DATA: lv_name TYPE string,
 lv_greeting TYPE string.
 wd_context->get_attribute(
 EXPORTING
 name = `NAME`
 IMPORTING
 value = lv_name).
 CONCATENATE ‘Welcome’
 lv_name INTO lv_greeting SEPARATED BY space.
 wd_context->set_attribute(name = 'GREETING'
 value = lv_greeting).
 CLEAR lv_name.
 wd_context->set_attribute(name = 'NAME'
 value = lv_name).
 ENDMETHOD.

Properties

In the Properties tab, we can create a description text for our view, we have information about the view and about the person who created and changed this view. In this tab, we can set the view lifetime:

Framework controlled – controlled by Framework
When visible – lifetime limited to its visibility. A view controller is always deleted as soon as the corresponding view is no longer displayed on the user interface. It is used when a view is displayed only once and not repeatedly.

Additionally, Property tab offers the possibility to define the usages .

Properties view

We can define a usage to be able to access the methods of another internal controller or of an interface controller, if the usage has been defined for an external component. To create a new usage in the Used Controller/Components table, we have to choose the Button Create Controller Usage. The table Used Controller/ Components includes a list with all the global controllers of our own component and, in case we define usages, this list includes the external component and its interface controller.

In our case, we don’t use any external components. In the list we have only the global controller COMPONENTCONTROLLER. We have to specify that, for each view controller, the usage of the corresponding component controller is automatically created.

Attributes

Each View controller contains some attributes automatically generated by the Framework

Attributes tab

The attribute WD_COMP_CONTROLLER is a reference variable of IG_ COMPONENTCONTROLLER type that we can use to access all the publicly accessible methods of the component global generated interface of the corresponding component controller.

The attribute WD_THIS is a self-reference to local controller interface. This self-reference works similarly with the self-reference me found in the ABAP Objects. We can use it, for example, to call a user-defined method.

The attribute WD_CONTEXT is a reference to the controller context. The IF_WD_CONTEXT_NODE interface provides several methods that enable us to obtain read and write access to a context node.

Additionally, we can create our own attributes. These attributes are used to store application data that are not relevant for the UI elements and we don’t store in the context. To access these attributes, we use the self-reference: wd_this -> attribute_name

Componentcontroller

By default, every Web Dynpro component has a component controller that acts as the central controller instance within the entire component

Component controller

Data required across different views can be stored in his context. Besides the Context tab, each COMPONENTCONTROLLER disposes of tabs: Properties, Attributes, Events and Methods. Hereunder, in our examples, we will see how we can cross-component access the methods and the attributes defined here.

Window

A Window is an entity into which we embed all the views that will be used to construct the screen for the end user. When the user interacts with a view, theirinteraction will cause a request to the server. In response, one or more views that build the current screen will require to be replaced with other views. This is possiblethrough navigation links among the various views in the window.

Each Web Dynpro component can have several Windows. We have created only one Window, named W_default.

A view or several Views are generally embedded in a Window. The first view created at the WD component creation is directly embedded into the Window. To embed other views in a Window, we can use dragging & dropping or right-clicking on the window name to choose between embedding an empty view or the View we have created. The Empty View is a special type of View, presented in the View- ContainerUIElement example.

In every window, at least one view is marked as default. A default view is the first view displayed when the window is called. The first embedded view is marked as default, but we can change it. To mark as default, after right-clicking on the view we choose Set as default from the contextual menu.

Embed View

By using Inbound plugs and Outbound plugs, we define the navigation between views or windows. For a Window, these plugs can be of Standard, Startup or Resume type. As we can see, the Framework generates for each window an inbound plug of Startup type and an event handler method .By using this event handler method, we can read, for example, the URL parameters from a Web Dynpro application.

Default inbound plug for a window

For a View, we don’t have the possibility to define a specific plug type.

Application

After developing a Web Dynpro component, we need to provide the users with access to its functionality. To do this, we have to create a Web Dynpro Application.

Creating an application

For each application, the Framework generates an URL. We find this URL in the Properties tab.

Application URL

In the same time, we can specify here how the Messages are handled:

l Show Message Component on demand – the Message Component is displayed only when we have a message.
Always Display Message Component – the Message Component is always displayed on the screen, even when we don’t have any messages.

By using the Parameters tab, we can define our own parameters for the application or we can choose from the parameters offered by the Web Dynpro Framework.

Application parameters list

To run the application, we can use the Execute button or we can copy and past the URL into the browser.

Running the application

When the user interacts with the screen, specific adapter techniques are used to convert data and events, as part of the request response cycle, into the browser format as HTML, JavaScript or XML. In Fig., we can see the generated source code for our WD component.

Generated source file

ABAP Debugger

If any errors occur in our Web Dynpro components, we can use the ABAP Debugger to execute our WD component, by line or by section.

To work with the debugger, we can create Breakpoints at the point where the program should pause

Setting a Breakpoint

We run the application and, in the moment when the program flow reached the defined breakpoint, the ABAP Debugger is open

ABAP Debugger

As we can see in the Process Information, the main component of the ABAP Debugger, we debug an HTTP application. The “Exclusive” represents the fact that the application we debug occupies a work process of the application server.

By using the Buttons from the Control Area, we can control the program flow. For Example,We can choose to execute the program line by line-single step or to execute the program up to the next Breakpoint.Continue.

We can use the ABAP Debugger tools to have information about the variable

Tool Component of the ABAP Debugger

By using the New Tool Button,We can open a selection window that offers the possibility to access additional functionalities. In the Special Tools section, we can find the created tool, to be used for a better debugging of the Web Dynpro components.

ABAP Debugger – New tool selection window

As we can see in, we are offered the possibility to have access to all the individual elements of the Web Dynpro component; we can see the view attributes, the view layout, the UI elements and data binding, the context structure and its attributes, etc.

The ABAP debugger – web Dynpro ABAP tool

We are able to see not only the context structure, but also to display the runtime object, by choosing from the contextual menu Display Runtime Object.

Displaying the runtime object

These are only some of the ABAP Debugger capabilities that can be used along with other performance tools (for example, the transactions WD_TRACE_TOOLS, S_MEMORY_INSPECTOR), to help us to develop Web Dynpro applications.

Web Dynpro Logon Page Configuration

As we have seen, a logon page appears when running our application, where we have to provide some values, as follows: Logon Language, Client, User Password, etc.

Example of a webDynpro application log on page

We can change the modality this logon page looks like and the modality we realize the user authentication, by using the SICF transaction (HTTP Service Hierarchy Maintenance). In the webdynpro ! sap hierarchy, each Web Dynpro application disposes of one corresponding entry.

By using this transaction, we search for all the entries that begin with Y_WD_* and are created by our test user Gellert.

Searching for a service with the SICF transaction

We find the entry that corresponds to our created Web Dynpro component.

Entry corresponding to our Web Dynpro component

With double-click, we are allowed to view or/and to change this service. In the lower part of the Error Page tab, we can find the Configuration button for the system logon. Here, we can define our own settings by choosing from the lists, or we can use the global settings.

System logon configuration

As a result of our changes, in the logon page we have to provide only the User and the Password, through a popup window, and we are able to change our logon password.

Logon page

2012-09-22T23:04:00.001-07:00

ABAP Dictionary

Abstract The following section details and describes the ABAP Dictionary.The main purpose of this chapter is to show how to realize all the development objects to be used in the future Web Dynpro applications.Therefore,we present not only the modality to create the various development objects in the ABAP Dictionary, but also the modality to use them in realizing Web Dynpro applications.

We can create development objects in ABAP Dictionary,by using the transaction SE11(ABAP Dictionary Maintenance) or the Object Navigator.

Development object with transaction SE11

ABAP programming language has a number of ten elementary data types that we can use in our programs. When we want to create global data types by using the ABAP Dictionary, we have to use dictionary built-in types. These predefined types are different from the elementary data types. We need them for reasons of compatibility with the external data types.

In this we presented some of the ABAP Dictionary Built-In types and a few corresponding examples of Dictionary built-in data types and ABAPelementary types.

Some of ABAP Dictionary Built-In types and corresponding ABAP elementary types

Data Element

A data element defines an elementary data type and has certain properties. We create a data element YDATEOFBIRTH

Definition of a data element

In the “Data Type” tab we can choose between the elementary type and reference type. The elementary type can be a domain and a build-in type. In this case, we have chosen the build-in type DATS that has a predefined format (YYYYMMDD) and a predefined length 8.

In the tab “Field Label”, we can set a field label that is automatically shown in the label, or caption of an UI Element that is bound to an attribute of this type.

For a data element, we can create documentation F1 Help with Goto -> Documentation -> Change. This documentation is not seen on screen if the Web Dynpro application attribute WDHIDEMOREFIELDHELPASDEFAULT was set as ABAP_TRUE. We create a text that describes the content of our data element.

Creating a F1 help for a data element

Domain

A domain defines a value range.To be able to use it in a Web Dynpro application,in other repository object, as parameter in GUI programming,etc.we have to assign it to a data element

Data elements and domains

We create a domain named Y_COUNTRY_DOMAIN that holds all the names of EU member states, with the proper abbreviation. In “Definition” tab we have to specify properties as data type, number of characters or length of output

Definition of a domain – tab “Definition”

In “Value Range” we have three possibilities:

Single values
Intervals
Value table

We begin with the first possibility, “Single values”. We define the domain fixed values – all the abbreviations of the EU countries, and a short text – the corresponding country names.

Definition of a domain – tab “Value Range”

As we have specified, to be able to use a domain we have to assign it to a data element. To do this, we create a new data element and we choose the elementary type – domain.

Assigning a domain to a data element

When we use this data element in our Web Dynpro application, for example to define a parameter or a context attribute, the user is allowed to choose only the values that range among values we have defined in Domain.

To explain the next possibility (“Intervals”), we take an example where we need to store, in a table column, the ages between 18 and 45. In this case, we can use an interval to limit the values that the user may enter.

Definition of a domain – interval

We use this interval in the database table YPERSON, defined hereinafter. For this, we assign it to a data element Y_DEINTERVAL.

To explain the last possibility (“Value Table”), we use a domain that is defined in the system: WAERS.

Domain WAERS – value table

It is recommendable to use the value table when we have many fixed values. In our case, we have used the system table TCURC. This table holds all the system currency.

We use this value table in the database table YEU_COUNTRIES, defined hereunder. For this, we assign it to a data element Y_CURRENCY.

Structure

Structures consist of any combination of other data types of the ABAP Dictionary.In fig. we present a structure with three components: FIRSTNAME, LASTNAME and DATEOFBIRTH.

Definition of a structure

For each component it is defined a component type, as follows: a data element,other structure, table type, etc.

As a component type for a structure, we can choose a type that is already defined in the ABAP Dictionary, or we can create a new type. For example, the component DATEOFBIRTH has YDATEOFBIRTH data type. This data type has been already defined.

If we want to create a new type for a component, we have to enter its name (for example, YFIRSTNAME) and then, with double-click, we can choose the new type.

Creating a new component type

After we create a structure, we have to maintain the enhancement category: Extras ! Enhancement Category, from the menu. In case we don’t want to further extend the component structure, we choose “Cannot be Enhanced”.

Maintaining enhancement category

We can use the structures defined in ABAP Dictionary to create the context node structure for a Web Dynpro application.

Table

We create two transparent tables, YPERSON and YEU_COUNTRIES. We will use this table later, for our Web Dynpro example.

In the YPERSON table, we want to store the competition candidates. All the candidates should be 18–45 years old and live in an EU country. After creating the table, we have to enter a short description along with the delivery and maintenance

Table maintenance

We set “Data Browser/Table View Main” ! Display/Maintenance Allowed, to be able to populate our table with values, using “Create Entries”, from the menu.

Then, we will define our table structure. To do this, we select the tab “Fields” and enter the table columns For the fields MANDT and ID_PERSON, we have marked the option “Key”, meaning they are the table keys. The field MANDT is the SAP client field, a three-character client ID. The field “ID_PERSON” represents the candidate’s ID, required to uniquely identify each competition candidate.

Table structure

As can be seen, we have used the data elements created hereinbefore: YFIRSTNAME, YLASTNAME, Y_DEINTERVAL, Y_DEFORDOMAIN. When we want to create a new data element, we write its name and, with double-click, we activate the forward navigation. If this data element doesn’t exist, we are asked if we want to create the new data element.

Creating a data element

Before being able to activate this table, we have to maintain the technical settings

How to maintain the technical settings for the table YPERSON

We choose a size category 0, because we don’t require many data records. We have to maintain the enhancement category: Extras -> Enhancement Category, from the Menu. We choose the same “Cannot be Enhanced”, because we shouldn’t further extend the table structure. After this, we can activate our table and create the second table YEU_COUNTRIES.

We hold here all the EU Member states information, as follows: country name, year of EU entry, political system, capital city, currency and the flag image name. The structure of this table is presented.

Table structure

After this, we have to define a foreign key for the field CHECK_CUR. For this purpose, we use the button “Foreign Keys”. We are asked if we want to use the value table TCURC as check table.

How to create foreign key

We need TCUC as a check table, because we want to use its table contents, respectively the Currency Codes.

Currency codes

After we maintain the Technical settings and enhancement category, we can activate the same as for the table YPERSON.

The candidates can live only in an EU country. Therefore, we create a 1 to CN relationship between the tables.

From the table YPERSON field ID_COUNTRY, we create a foreign key.

How to create a foreign key

The system can generate the graphical representation of the relationships we have defined between tables. To show this graph,we use the Button “Graph”.

Foreign key relation ship

We can see our tables YEU_COUNTRIES, YPERSON and the 1:CN relationship.

The table TCUC is the check table for the table YEU_COUNTRIES. To see this relationship also, we have to select the name of YEU_COUNTRIES table and to press the Button “Check Table”.

Foreign key relation ship

We can create contents withUtilities --> Table content --> Create Entries from Menu

Insert – table YEU_COUNTRIES

To display the content: Utilities --> Table content --> Display from Menu.

Select – table YEU_COUNTRIES

We can use the transparent tables defined in the ABAP Dictionary to create the context node structure for a Web Dynpro application.

Search Help

ABAP Dictionary offers the possibility to create simple search help and collective search help. To create a search help, we can use the context menu of our package.

Creating a development object in the ABAP Dictionary by using the Object Navigator

We create a simple search help YSH_ID_PERSON for the column ID_PERSON of the table YPERSON

Creating a simple search help

As can be seen at Data collection ! Selection method, we have used the table name YPERSON. This means that all the data required come from our table YPERSON. A search help can have the following parameters: “import parameters”, “export parameters” or “no import” and “no export”. We have used ID_PERSON as export parameter, because we want its value to be returned to the input template. LPos represents the parameter position in the hit list: FIRSTNAME has the position 1 and it is firstly displayed in the hit list, and LASTNAME has the position 2, being displayed after the FIRSTNAME.

Testing a search help

Afterwards, we want to use this search help in a Web Dynpro application. We create a search option for a competitor. The user has to enter the competitor’s ID into a search mask. The list of IDs is limited to the number of competitors. When the user doesn’t know the competitor’s ID, he uses the search help and can choose the competitor’s name. The content of the ID_PERSON parameter is returned to the search mask as soon as the user has selected a line of the hit list in the input help. In this way, we facilitate the input.

We can use this search help if we link it with the ID_PERSON column of the YPERSON table. To do this, we select the column ID_PERSON and press the button “Srch Help”.

Search Help for the field ID_PERSON

After we enter the search help name, we have to create the search help attachment, and to save and activate the table

How to create search help attachment to the column ID_PERSON

In this way, we have created a simple search help for the column ID_PERSON of the table YPERSON. When we use this column in Web Dynpro, the Framework creates a special icon to be used at the runtime to call the input help. Moreover, we can use the keyboard key F4 to call an input help.

To be able to access a search help from a WD component, the proper Input Help Mode context attribute property has to be set (“Automatic” or “Dictionary Search Help”).

Database View

By using a view, we can combine the data distributed in several tables. For a better understanding, we create a view on the tables YPERSON and YEU_COUNTRIES. When we create a view, we can choose one of the four view types.

View types

We choose to create a database view named YVIEW_CMPETITION. At the beginning of the “view definition”, we have to select the view base table (in ourcase, the table YPERSON.After the base table definition, we link this table by defining the joining conditions. To create this link, we use the button “Relationships”.

Creating a view

Joining conditions

In the next step, we have to select the fields we need in our view. We can enter each field manually or we can use the Button “Table fields”.

View fields

After activation, we can see our view content using the “Contents Button”.

View content

In this way, we have created a database view on the tables YPERSON and YEU_COMPETITION.

View definition on the database

By using this view, we can create the context node structure for our Web Dynpro application and so we simultaneously select the logically connected data, from two tables.

Table Type

We create a table type named YTABLE_TYPE, the line type being our YPERSON table

Creating a table type

For the line type, we can use an existing type (table, structure, view, . . .) or we can enter the data type, length and number of decimals. The typical use of table type is the declaration of an internal table.

Another example of using table type is to populate with values a context node via a supply function. To be able to do this, we create a table type named YTABLE_ TYPE_STRUCTURE with the line type – the structure YSTR_PERSON.

Table type – line type structure

In the next chapter, we show how we can use this table type to populate a context node.

Lock Object

We create a Lock Object for the database table YPERSON. The lock object name has to begin with the prefix E (from “Enqueue”).

Lock object

Our case consists of exactly one table, and the lock argument is the primary key of this table. The lock mode is set to write, but can be overwritten.

After the lock object activation, the ABAP Dictionary generates two Function Modules, named ENQUEUE_ and DEQUEUE_. The Function Modules with enqueue prefix help us to set a lock, and the Function Modules with dequeue prefix help us to release the locks.

With the SE37 transaction we can see the two generated Function Modules: ENQUEUE_EYPERSON and DEQUEUE_EYPERSON. Figure shows the structure of the Function Module required to set a lock.

Function Module for lock setting

SAP offers a lock mechanism required to provide two transactions by simultaneously changing the same data in the database. The lock table represents a table in the memory of the enqueue server and is used to manage all the locks in the system. This lock table is checked every time when the enqueue server receives a lock request. A program sends, to the lock table, the key of the table entries it wants to lock; if no lock is set, the request is accepted and the new lock is written in the lock table. If a lock is set, the request collides with an existing lock and the request is rejected.

2012-09-22T23:03:00.007-07:00

Context Nodes and Attributes at Design Time

This chapter mainly focuses on the context nodes and attributes statically realized at design time. In this respect, we will explain not only the role and modality to create context nodes and attributes, but also the modality to access the values stored in the attributes of the nodes.

An attribute is a context entity that has certain properties and can be directly created in the root node CONTEXT, or as a child for another node. Usually, a node is used to group more attributes that belong together. In Fig. we present a context example created in a view context.

A context node can have attributes or can hold other nodes, but a context attribute cannot have other attributes or nodes. We create a hierarchical arrangement that has, as the start point, the root node CONTEXT. This is automatically created when the controller is initialized and all the nodes and attributes we created are children of this root node.

Example of the structure of a View Context

The data hold in the context nodes and attributes are transient, they exist only for the lifetime of the controller. After this, all the data are lost if we don’t store them in storage media (e.g. database table).

Attributes

To create an attribute, we have to select the node where the attribute should be inserted (in this case, the root context node) and, with right-click, to open its context menu.

Creating an attribute

We have to enter the attribute properties – name and type are required, but the other settings are optional.

Defining the attribute properties

As data type for an attribute, we can use a data type as string, xstring, d,i or we can use the data type defined in the ABAP Dictionary. In our example,the attribute type YDATEOFBIRTH is a data element defined in the ABAP Dictionary. In the system, we find a list with all the data types we can use for an attribute. The coding presented in Listing shows how we can access, in a method, the value of the attribute created in the context node.

Searching for an attribute data type

Access of an attribute from context node

 DATA lv_dateofbirth type ydateofbirth.
 wd_context->get_attribute(EXPORTING name ='DATEOFBIRTH'
 IMPORTING value = lv_dateofbirth).

We have defined a local variable named lv_dateofbirth of YDATEOFBIRTH type, the same type as the attribute. We pass the value of the attribute DATEOFBIRTH in our local variable, by using the method get_attribute of the interface if_wd_context_node. The interface if_wd_context_node has many methods we can use to work with context nodes. We can see all the available methods of this interface by double-clicking on the get_attribute method. To set the value of an attribute, we can use the method set_attribute of the same interface.

As can be seen in Fig, the property Input Help Mode of the attribute is set AUTOMATIC. This means that it is used the search help assigned to the data type of the context attribute in the ABAP Dictionary. In principle, we have a data element of D type. This is the reason why we will have a CALENDAR as input help

Calendar input help

The read-only property set “no” means that the attribute is not write- protected. To put data on the screen and to read data from user, we connect the proper UI Elements properties with the attributes or nodes. The data are stored in the attributes, the UI Elements being the only object the user interacts with. For our example, we have an UI Element InputField where the user enters his date of birth. Web Dynpro Framework transports these data from the UI element to the attribute DATEOFBIRTH when the user presses the SAVE Button, after he enters the value. The attribute keeps the value for further processing. To be able to access the value of this attribute in our methods, we have to pass this value in a local variable (lv_dateofbirth). We can use this value, change it or pass the new value back in the context (Fig) This value is kept in the context for the lifetime of the controller. Then, these data are lost if we don’t store them.

Connection among attribute, ABAP Dictionary, method and UI Element

Nodes

We can directly create a node in the context root node or as child for other node. In Fig. we show how we can create a node.

Creating a node

For each node we create, we have to set some properties, as: cardinality, selection, etc. We can individually create the attributes for a node, or we can use some repository objects from the ABAP Dictionary. For example, when we work with tables, structures or views defined in the ABAP Dictionary, we can use them to define our node, and the attributes will be automatically generated.

Creating a Node that Uses an ABAP Dictionary Repository Object

We create a context node that uses the ABAP Dictionary structure YSTR_PERSON.

Node properties

The Button “Add Attribute from Structure” allows us to add all the structure components or only a part of them.

Selecting components of Structure

Because we need a proper attribute for all these structure components, we select all of them. As result, we have created a node, the attributes being automatically generated according to the structure components we have selected.

Context node STUDENT at design time

The properties of the node we have chosen are: cardinality 0. . .n, singleton – yes and Init. Lead Selection – yes. Web Dynpro Code Wizard,reading a context node or attribute.

The cardinality properties are very important, because they tell us how many elements a context node may have at runtime. We have four possible values:

1. . .1 Exactly one context element is instantiated
0. . .1 Maximum one context element is instantiated
0. . .n Zero or more context elements are instantiated
1. . .n One or more context elements are instantiated

The singleton property can be set YES or NO. When a node is singleton at the runtime, we have only one instance of this node. As usage example, for a nonsingleton node we can specify the context structure required for a Tree UI Element – sequential implementation.The Lead Selection Initialization property determines if the lead selection should be automatically set or manually programmed. In our case, this property is set “YES”, meaning that the lead selection is AUTOMATIC and the first element of this node it automatically selected. More details about lead selection – Table UI element.

For our node, we have defined the supply function named supply_student. Each node may have a supply function defined for it and automatically called by the Web Dynpro Framework. The scope of using a supply function is to populate a context node. In certain cases, we can use the Hook Method wdDoInit instead of a supply function. For more details, see the Hook Methods chapter.

The coding presented in Listing shows how we can use the supply function method to populate the context node STUDENT with three values. We have defined two variables: ls_student and lt_student. Ls_student is of type if_view_name=>element_student, where “view_name” represents the view name and “student” represents the node name. ”if_view_name” represents the programming interface for our view controller. By double-clicking on his name or clicking on the icon Display Controller Interface we can see the coding of this interface. Listing shows a coding part for the context node STUDENT.

Example of supply function Method

 METHOD supply_student .
 DATA ls_student TYPE if_view_name=>element_student.
 DATA lt_student LIKE TABLE OF ls_student.
 ls_student-firstname = 'Ionescu'.
 ls_student-lastname = 'Ana Maria'.
 ls_student-dateofbirth = '19700309'.
 APPEND ls_student TO lt_student.
 ls_student-firstname = 'Marinescu'.
 ls_student-lastname = 'Loredana'.
 ls_student-dateofbirth = '19800523'.
 APPEND ls_student TO lt_student.
 ls_student-firstname = 'Marton'.
 ls_student-lastname = 'Luminita'.
 ls_student-dateofbirth = '19831108'.
 APPEND ls_student TO lt_student.
 node->bind_table(
 new_items = lt_student).
 ENDMETHOD.

Example of view controller programming interface.

  constants:
  wdctx_Student type string value `STUDENT`.
  types:
  Element_Student type YSTR_PERSON,
  Elements_Student type
  standard table of Element_Student
  with default key.
  …..

As can be seen, Element_Student is of YSTR_PERSON type (our ABAP Dictionary structure).But, when we manually create context nodes without dictionary structure,in the view controller programming interface,a new structured type is created (Listing).

Example of view controller programming interface

  …..
  types:
  begin of Element_Faculty,
  FACULTY_NAME type String,
  SPECIALIZATION type String,
  end of Element_Faculty,
  ……

This is why we use the following form to append values: ls_student-firstname = ‘Ionescu’.

The way we append values in an ABAP structure is: structure_name-component_name = value

With the declaration “DATA lt_student LIKE TABLE OF ls_student”,we declare an internal table.We use APPEND statement to add each new line at the end of the last line of the internal table.

At the end,we use the bind_structure method to populate the node with values.Instead of the declaration:

DATA ls_student TYPE if_view_name=>element_student.

we can use:
DATA ls_student TYPE wd_this->element_student.

In this way, we don’t need the view name anymore,because we use the wd_this self-reference.

The runtime structure

The node STUDENT was set Singleton, it has only an instance at runtime and the cardinality was set 0. . .n, meaning that, at runtime, we can have from zero to n elements. Because the lead selection was set “YES”, it was selected the first element of the node. To read, set or append a context node or attribute, we can use the Web Dynpro Code Wizard.

The option “As table operation” can be used in combination with the Read, Set or Append options for a node that allows the usage of this combination. We can read, for example, the entire context node STUDENT in an internal table.

DATA lt_student TYPE wd_this->elements_student. lr_node->get_static_attributes_table( IMPORTING table = lt_student).

Web Dynpro Code Wizard, reading a context node or attribute

In this case, the wizard has generated a variable lt_student of type wd_this -> elements_student. In Listing we saw that, in Interface Controller, besides the definition of a variable, the Element_structure Framework has also defined a variable Elements_Student, with the form:

Elements_Student type standard table of Element_Student with default key.

This is the reason why the Wizard offers the possibility to read all the values from the STUDENT node in lt_student.

As we have mentioned in the last chapter, we can use a table type to populate with data a context node via a supply function. Our node STUDENT has its attributes from the YSTR_PERSON structure. The table type YTABLE_TYPE_STRUCTURE defined in the ABAP Dictionary has the same YSTR_PERSON structure, as line type. Listing shows how we can use a table type to populate with data a context node.

Example of supply function Method

 METHOD supply .
 DATA: lt_student TYPE ytable_type_structure .
 DATA: ls_student TYPE ystr_person.
 ls_student-firstname = 'Ionescu'.
 ls_student-lastname = 'Ana Maria'.
 ls_student-dateofbirth = '19700309'.
 APPEND ls_student TO lt_student.
 ls_student-firstname = 'Marinescu'.
 ls_student-lastname = 'Loredana'.
 ls_student-dateofbirth = '19800523'.
 APPEND ls_student TO lt_student.
 node->bind_table(new_items = lt_student).
 ENDMETHOD.

Working with Child Nodes

We create the context structure presented.

Example of child node

It has a context node FACULTY, cardinality 1. . .1, Singleton with child node ADDRESS, cardinality 1. . .1, Singleton and two attributes FACULTY_NAME type STRING and SPECIALIZATION type STRING.

We read data from the attributes of the node ADDRESS as a child node for FACULTY. Listing shows a possible method to read these attributes.

Reading the attributes values of the child node “ADDRESS”

 DATA: lr_node TYPE REF TO if_wd_context_node,
 lr_subnode TYPE REF TO if_wd_context_node.
 DATA: lv_street TYPE string,
 lv_number TYPE y_char,
 lv_city TYPE string.
 lr_node = wd_context->get_child_node('FACULTY').
 lr_subnode = lr_node->get_child_node('ADDRESS').
 lr_subnode->get_attribute EXPORTING name ='STREET'
 IMPORTING value = lv_street).
 lr_subnode->get_attribute(EXPORTING name ='NUMBER'
 IMPORTING value = lv_number).
 lr_subnode->get_attribute (EXPORTING name ='CITY'
 IMPORTING value = lv_city ).

With the first data definition, we create two variable lr_node and lr_subnode of if_wd_context_node type. With the second data definition, we create three variables with the same data type as the attributes we want to read. Data type Y_CHAR represents a data element defined in the ABAP Dictionary of CHAR type, length 6. Instead of the declaration:

lr_node = wd_context->get_child_node( ’FACULTY’).

we can use the form:

lr_node = wd_context->get_child_node( name = wd_this->wdctx_faculty).

In the first case we have to write with capital letters the node name, and in the second case we use the constant wdctx_faculty of string type, defined by the Framework in Interface Controller, with the form:

constants:

wdctx_faculty type string value ‘FACULTY’.

By using the get_child_node method of if_wd_context_node interface, we successively access the node FACULTY and the node ADDRESS, and by using the method get_attribute, we pass the values of the attributes in our local variable.Another possibility to read the values of the ADDRESS child node attributes is presented in Listing.

Reading the attributes values of the child node “ADDRESS”

 DATA: lr_node TYPE REF TO if_wd_context_node,
 lr_subnode TYPE REF TO if_wd_context_node,
 ls_subnode type wd_this->element_address.
 DATA: lv_street LIKE ls_subnode-street,
 lv_number LIKE ls_subnode-number,
 lv_city LIKE ls_subnode-city.
 lr_node = wd_context->get_child_node('FACULTY').
 lr_subnode = lr_node->get_child_node('ADDRESS').
 lr_subnode->get_static_attributes(IMPORTING
 static_attributes = ls_subnode).
 lv_street = ls_subnode-street.
 lv_number = ls_subnode-number.
 lv_city = ls_subnode-city.

In this case, we have used the get_static_attributes method that supplies a copy of all the static attributes for the ADDRESS child node. After this, we are able to access the attributes values through the local structure “ls_subnode”.Listing shows how we can populate with values the elements of the ADDRESS child node

Populating the attributes of the ADDRESS node

 DATA:lr_node TYPE REF TO if_wd_context_node,
 lr_subnode TYPE REF TO if_wd_context_node,
 ls_subnode TYPE if_view_name=>element_address.
 lr_node = wd_context->get_child_node('FACULTY').
 lr_subnode = lr_node->get_child_node('ADDRESS').
 ls_subnode-street = 'Pforzheimer'.
 ls_subnode-number = '106A'.
 ls_subnode-city = 'Pforzheim'.
 lr_subnode->set_static_attributes(ls_subnode).

2012-09-22T23:03:00.005-07:00

Data Binding, Context Mapping and Interface Methods

This starts with the presentation of the mechanism used to manipulate data between the context attributes and UI elements, mechanism called,in Web Dynpro,“data binding”. We continue with the mechanism of sharing data among the various controllers, which is realized by using different variants of context mapping. Finally, we highlight the importance of the interface methods required to access them “cross-component”.

In the last chapter, we have created context nodes and attributes in the context view.A node or attribute can be created in each context. When we create an attribute in the context view, this value is visible only in this context view. The mechanism for sharing data among different controllers is known as “context mapping”. A context mapping can be internal, when the nodes we map are within the same component, and external, when the mapping is cross-components.

Data Binding

Each UI element has certain properties. With data binding, we define which node or attribute from the context will act as a data source for an UI element property. To exemplify the data binding mechanism, we create a component named Y_DATABINDING with a view named V_BIND and a window W_DEFAULT.

Structure of Y_DATABINDING component

In context view, we create a context node STUDENT with the same dictionary structure YSTR_PERSON.

Structure of STUDENT node

We create a WD component that reads the user inputs in the attributes FIRSTNAME,LASTNAME and DATEOFBIRTH. When the user presses the “SHOW” button, these data are shown by means of TextView UI Elements.

Example of data binding

We have many possibilities to make a data binding. For example, we can:

(a) Create a “Container Form” for a context node
(b) Use the Web Dynpro Wizard
(c) Create data binding for each attribute

(a) To create a “Container Form”, we add a Group UI element and then, by rightclicking,we choose from the contextual menu “Create Container Form”.

Creating container form

After this, we can choose which context node we use for data binding and which type of UI Element is associated to each attribute
As a result, the Framework generates for each context attribute an UI element InputField and a proper label, and makes the data binding between each UI element property (value) and the context attribute.

Data mapping among InputField UI Elements and the context attributes.

To create a “Container Form”, we can use each UI Element of container type.

(b) To create a data binding, we can use the Web Dynpro Wizard button(Fig) In case we use the Form option, the Framework generates a transparentContainer UI element that contains the UI elements that we have to choose inthe same way as we have shown at point (a).

Using wizard to create a form and the proper data binding

(c) To manually define a data binding for each attribute, we have to insert the proper UI Element and create data binding between an UI element property and a context attribute. We insert 3 TextView UI Elements and 3 Labels UI Elements.

Layout structure

We have to create the data binding between each text property of the TextView UI Element and the proper context attribute.

Data binding

We repeat this step until we make data binding among the text property of all the three UI Elements and the proper context attributes. Then,we insert a Button UI Element in the Group GRP_STUDENT_WRITE and add an action.

Inserting a button and adding an action

In this case, we don’t need to enter coding in the generated event handler method onactionshow. After creating an application for our component, we are ready to run it. The result is presented. At runtime, the context attributes are empty. After the user enters values and pushes the SHOW button, the context attributes are populated with these values.At design time, we realised a data binding among the TextView UI Elements and the same context attributes (Firstname, Lastname and Dateofbirth). This is the reason why these UI Elements show the values entered by the user in the Input-Fields UI elements.

Running the application

Context Mapping

So far, we have used only context attributes that were defined in the view context.When we want to share data among different controllers, we have to define a context mapping.

A context mapping can be an internal context mapping or an external context mapping. An internal mapping relationship can be defined between any pair of controllers within the same WD component, whereas the external mapping defines a mapping across the borders of a WD component.

Internal Context Mapping

As mentioned before, the mechanism for sharing data among different controllers within the same WD component is known as internal context mapping.For a better understanding of this mechanism, we create the same example from data binding, but in this case we create the two groups GRP_STUDENT_READ and GRP_STUDENT_WRITE, in different views. At runtime, we display the view V_VIEW1.When the user presses the “SHOW” button, we display the second view V_VIEW2. The WD component structure is presented.

WD component structure

We cannot create the context node in the view context, because we need the values of this attributes not only in the view V_VIEW1, but in the view V_VIEW2 as well.In this case,we create the node STUDENT in the context of component controller.In this way,through context mapping, we can access the context of the component controller via a view controller. Context mapping doesn’t cause the duplication of data.The nodes in the view controllers only hold a reference to the mapping context node from the component controller.

Internal context mapping

We firstly create the context node of the component controller. After this, we make a context mapping between the context of the view V_VIEW1 and the context node of component controller. As a result, the entire context node STUDENT is mapped. In the same way, we proceed to make a context mapping between the context of the view V_VIEW2 and the context of component controller.Consequently,we have to create the view layout for the views V_VIEW1,V_VIEW2 and the data binding.Data stored in the context of the component.

Context mapping

The mapping result

controller can be used within a view if we have firstly made a context mapping.The schematic representation is presented.

Intern context mapping, data binding

The lines between controllers symbolize the context mapping, and the lines between view controllers and the views layout symbolize the data binding. In the view V_VIEW1, we create the group GRP_STUDENT_WRITE and then we can use the view context to create a “Container Form”.Because we want to show both views in the same window,after the user presses the “SHOW” Button we use a ViewContainerUIElement.

View layout for V_VIEW1

We have to embed the view V_VIEW2 in the ViewContainerUIElement.

Embed view V_VIEW2

We have to embed the view V_VIEW2 in the ViewContainerUIElement (Fig.).

Embed view V_VIEW2

After creating an application,we can see the result. At runtime, the User Interface is the same as for the data binding (example – Fig.)The difference is the context mapping. In this case, the context is not defined in the view context, but in the context of the component controller, and can be accessed through context mapping. The data reside in the context node of the component controller context, and the context node of the views controller simply holds a reference to this.

External Context Mapping

External mapping is a cross-component mapping and can be directly mapping or reversely mapping. We can create an external context mapping if we have firstly declared a usage for the component that holds the respective context and the respective context node has been marked as interface.

Direct Mapping

As a briefly description of this kind of mapping, we can say that the external mapping of direct mapping type is a cross-component mapping in which the main component directly access the data (represented through the context structure) of the used component.

For a better understanding of this type of mapping, we create the same example for the internal mapping, but in this case we create two WD components. The component Y_EM_LAYOUT has two Views used to create the user interface.To hold the data entered by the user, we use the context node STUDENT.To be able to access this context node, we have to define a component usage. In WD, the component Y_EM_LAYOUT defines a usage of the component Y_EM_CONTEXT.

WD component structure

In real cases, a faceless component is useful if several components access the same set of data. This type of component can be used to create a model for a multicomponent application. We firstly create the context node in component controller of the component Y_EM_CONTEXT. We keep the same context node STUDENT, but in this case we create an interface node. If this node has not defined the interface type, we cannot access it from another component.

Context node structure

The component Y_EM_LAYOUT has two Views used to create the user interface. To hold the data entered by the user, we use the context node STUDENT. To be able to access this context node, we have to define a component usage. In WD, the component Y_EM_LAYOUT defines a usage of the component Y_EM_CONTEXT

Defining a Usage in a component

After the usage is defined, we have to create a controller usage in the component controller. We need to use the component Y_EM_CONTEXT, the component use (named CONTEXT) and, hence, we need the INTERFACECONTROLLER

Controller usage definition

The next step is to define a mapping. In this case, it is an external mapping, because the node we use to define the mapping is outside the component

Defining an external mapping

As a result, the entire context node is mapped.

The mapping result

In the Methods tab, we have to verify in the wddoinit( ) Hook Method if it is an instance of the used component. The coding from Listing shows how we can verify this and how can be created in case it doesn’t exist.

Checking an instance of the used component

 METHOD wddoinit .
 DATA:lr_cmp_usage TYPE REF TO if_wd_component_usage.
 lr_cmp_usage = wd_this->wd_cpuse_context( ).
 IF lr_cmp_usage->has_active_component( ) IS INITIAL.
 lr_cmp_usage->create_component( component_name =
 'Y_EM_CONTEXT').
 ENDIF.
 ENDMETHOD.

By using the method HAS_ACTIVE_COMPONENT of the IF_WD_COMPONENT_USAGE, we verify if the usage has an active component.If the component has already been initialized, the logic moves on otherwise, we create an instance of the component by using the CREATE_COMPONENT method of the same interface. We must ensure that the external component has been instantiated before the interface controller is accessed.

It is recommendable to create a usage for a component only in the moment we need it.In our little example, we have to create the usage in the wdDoInit Hook method, but,in case we use navigations plugs to navigate to a used component,it is recommendable to create the usage in the method used to fire the respective plug.

Further, we can proceed as in the previous example: we create an internal mapping between the context node of the component controller and the context view of the views V_VIEW1 and V_VIEW2. After this, we can create the data binding.All these are schematically presented. The line between WD components symbolizes the external direct context mapping, the lines between component controller and views controllers symbolize internal mapping, and the lines between view controllers and views layout symbolize the data binding.

Reverse Mapping

As a briefly description of this king of mapping, we can say that the external mapping of the reverse mapping type is a cross-component mapping in which the data (represented through the context structure) are put at our disposal by the main component.

To realise the screen based on them, we use the interface view of the used component.For a better understanding of this type of mapping, we create the same example from direct mapping,where we change only the implementation part. We create two WD components, named Y_EM_CONTEXT_RM and Y_EM_LAYOUT_RM. The WD components structure is presented. We define, in the component Y_EM_CONTEXT_RM, the context node STUDENT.This component has no view, because we embedded here the interface view

Schematic representation of an external direct mapping

WD components structure

of the component Y_EM_LAYOUT_RM.The component Y_EM_LAYOUT_RM implements the user interface, making usage of the component Y_EM_CONTEXT_RM required to have access to the STUDENT node. Schematically, all these are presented. We firstly create the context node in the component controller of the component Y_EM_CONTEXT_RM, by using the same context node STUDENT and interface node.

Schematic representation of an external reverse mapping

Interface node

The component Y_EM_LAYOUT_RM implements the user interface. In component controller, we create a node named STUDENT, with the same structure as the node STUDENT from the component controller of the component Y_EM_CONTEXT_RM.

After creating the node, we make an internal mapping, we create the user interface and make the data binding. Another solution is to copy the component Y_EM_LAYOUT and to make the proper changes. We can copy this component by right-clicking on the component name, and choose “Copy” from the contextual menu. We have to specify a name for the new component and a package where we want to save this component. We define a usage of the component Y_EM_CONTEXT_RM and create an external mapping, reverse mapping.

Interface node, Input element

Context structure after usage and mapping

After entering the coding required to verify if it is an instance of the used component, we can save and activate. For the next step, we go back to the component Y_EM_CONTEXT_RM, where we have to define a usage for the component Y_EM_LAYOUT_RM, required to be able to embed its interface view.

After this, we can embed the interface view of the component for which we have defined only the usage. The Framework generates a corresponding interface view when we create a window. This interface can be embedded by other component,after the usage was defined. To embed the interface view or windows of the Y_EM_LAYOUT_RM component, we proceed in the same way as for embedding the views.

Defining the usage

Y_EM_LAYOUT_RM component, we proceed in the same way as for embedding the views.

Embed operation

After entering the coding required to verify if an instance of the used component exists, we can save, activate and run the application.

Interface Methods

A method of a component controller can be marked as interface. In this way, it is possible to access it cross-component. This option is possible only for the methods applied to the component controllers. The methods that take place in Views orWindows can’t be marked as interface.

For a better understanding of this kind of methods, we expand the previous example. In this example, after the user enters values and presses the “SHOW” button, the context attributes of the node STUDENT of the component Y_EM_CONTEXT_RM are populated with these values. When we want to verify if the user have entered his first name, we have to define an interface method in the component controller of this component, a method that verifies if this attribute has a value or it is empty. For this purpose, we create the interface method named check_firstname().

Marking a component controller method as interface

We create this method in the component Y_EM_CONTEXT_RM, because there is the context node where the values are transferred after the user presses the “SHOW” button.

Method check_firstname implementation

 METHOD check_firstname .
 DATA lr_node TYPE REF TO if_wd_context_node.
 DATA ls_node TYPE if_componentcontroller=>element_student.
 DATA lv_firstname TYPE string.
 DATA lr_api_controller TYPE REF TO if_wd_controller.
 DATA lr_message_manager TYPE REF TO if_wd_message_manager.
 lr_node = wd_context->get_child_node('STUDENT').
 lr_node->get_attribute(EXPORTING name = 'FIRSTNAME'
 IMPORTING value = lv_firstname).
 IF lv_firstname IS INITIAL.
 lr_api_controller ?= wd_this->wd_get_api( ).
 lr_message_manager = lr_api_controller->get_message_manager( ).
 lr_message_manager->report_error_message(
 message_text = 'The Field First Name is empty!').
 ENDIF.
 ENDMETHOD.

We read the value of the FIRSTNAME attribute into the local variable lv_firstname.After this, we verify if this attribute has a value or it is empty. In case this attribute is empty, we want to show a message with the string ‘The Field First name is empty!’.In this case, we have used the method REPORT_ERROR_MESSAGE of interface IF_WD_MESSAGE_MANAGER. To generate a message, we can use the Web Dynpro Code Wizard.

Usage of Web Dynpro Code Wizard

Is not recommended this art of programming, where the language-specific text elements are entered in the source text. In this case, we have used the easy way and not the best one. In the Chap.10, we explain how we can create messages easy to use and translate, without more programming effort.

After this method is implemented, we have to go back to the component Y_EM_LAYOUT_RM. When the user presses the SHOW button, we have to call the method check_firstname from the component use. If a method is marked as interface, we can cross-component access it. This means that we can call it from our onactionshow event handler method after we define a usage at the view level.

Usage definition

The coding from Listing shows the implementation of onactionshow event handler method.

Method call in used controller

 METHOD onactionshow .
 DATA: lr_interfacecontroller TYPE REF TO yiwci__em_context_rm .
 lr_interfacecontroller = wd_this->wd_cpifc_context( ).
 lr_interfacecontroller->check_firstname( ).
 ENDMETHOD.

We can use Web Dynpro Code Wizard to generate this code.

Web Dynpro Code Wizard

Runtime

2012-09-22T23:03:00.003-07:00

View Controller Methods

Abstract As we have seen in the previous chapters, in the Methods tab of a View we find various types of methods generated by the Framework, and we can also create our own methods. The purpose of this chapter is to present the role and the modality to use the various methods generated by the Framework and the modality to realize our own methods.

Each view has exactly one view controller. The view controller can contain
methods for data retrieval or for processing user inputs.

As we have seen, each view has a Methods tab where we can create our own user-defined methods or we can find the methods generated by the Framework. In each Method tab of a View, we can find or create three types of methods:

Event Handler: This kind of methods respond to actions or to events. An example of such a method is generated by the Framework when we define an inbound plug into a View. Another example is a method generated from the Framework when we create an action.
Method: We can use this kind of methods to create User-defined instance methods. Another example is the Hook Methods generated by the Framework.
Supply Function: When we create a node and define a supply function for it, the Framework generates a corresponding supply function method used to populate with data a context node.

Hook Methods

These methods cannot be deleted and represent the interface between the Framework and our application. The Hook Methods are called in a specific sequence according to a phase model. After generation, these methods are empty, but can be filled with source codes in case we want to interfere in a certain step of this phase model.

shows the Hook methods to be found in different controllers.

As we can see, the Hook methods wdDoInit and wdDoExit are common to all the controllers. shows which Hook methods can be found in a view.

Hook methods in a view

wdDoInit

This method can be considered the controller constructor. It is automatically called when the controller is initialized for the first time. We have many examples where we can use this method, for example:setting the initial values of a controller context, dynamically creation of a context node and attributes,filling context nodes.We can use this method instead of the supply function method (to populate with values a context node),only if we know that the context is filled only once and it’s not invalidated afterwards.

We create a WD component that uses the wdDoInit Hook method to populate with values a context node. The component structure and the view layout are presented.

WD component structure, view layout

In the context view, we create a context node named STUDENT, with the same structure as the data binding example –dictionary structure YSTR_PERSON,cardinality 1...1,singleton, without supply function.

Context structure

Using the wdDoInit Hook method,we populate with values this node (Listing). When calling the application for the first time, the wdDoInit Hook method fills the node STUDENT with all the elements set here.

The wdDoInit Hook method

  METHOD wddoinit .
  DATA lr_node TYPE REF TO if_wd_context_node.
  DATA ls_data TYPE if_v_view=>element_student.
  lr_node = wd_context->get_child_node('STUDENT').
  ls_data-firstname = 'Antonia Maria'.
  ls_data-lastname = 'Keller'.
  ls_data-dateofbirth = '19800306'.
  lr_node->set_static_attributes(ls_data).
  ENDMETHOD.

We can use the wdDoInit Hook Method to dynamically create the context nodeSTUDENT and to populate it with values.

Runtime

The wdDoInit Hook method

  METHOD wddoinit .
  DATA: lr_node TYPE REF TO if_wd_context_node,
  lr_node_info TYPE REF TO if_wd_context_node_info,
  lr_child_node_info TYPE REF TO if_wd_context_node_info.
  lr_node_info = wd_context->get_node_info( ).
  lr_child_node_info = lr_node_info->add_new_child_node(
  name = 'STUDENT'
  is_singleton = abap_true
  is_multiple = abap_false
  is_mandatory = abap_true
  static_element_type = 'YSTR_PERSON'
  ).
  lr_node = wd_context->get_child_node('STUDENT').
  DATA ls_data TYPE ystr_person.
  ls_data-firstname = 'Antonia Maria'.
  ls_data-lastname = 'Keller'.
  ls_data-dateofbirth = '19800306'.
  lr_node->bind_structure(EXPORTING new_item = ls_data).
  ENDMETHOD.

To dynamically create the context node “STUDENT”, we have used the method ADD_NEW_CHILD_NODE of the IF_WD_CONTEXT_NODE_INFO interface that creates an Info Object and adds it as a Lower-Level Node for the CONTEXT root node. The method CREATE_NODEINFO_FROM_STRUCT of the CL_ WD_DYNAMIC_TOOL class is obsolete and that’s why it is recommendable to use the if_wd_context_node_info->add_new_child_node.

ADD_NEW_CHILD_NODE have many import parameters of which,for the scope of our example, we have used:

NAME of STRING type – the name of the generated context node
IS_SINGLETON of ABAP_BOOL type,default value ABAP_FALSE – sets the property node SYNGLETON.In our example,the node STUDENT has to be singleton,and that’s why we have set this value ABAP_TRUE
IS_MULTIPLE of ABAP_BOOL type, default value ABAP_TRUE – sets the property node CARDINALITY.In our example,the node STUDENT has the cardinality 1...1,and that’s why we have set this value ABAP_FALSE
IS_MANDATORYf ABAP_BOOL type,default value ABAP_FALSE - sets the same property node CARDINALITY.We need the ABAP_TRUE value because the context node must have exactly one context element at runtime
STATIC_ELEMENT_TYPE of STRING type – we can use it to define the DICTIONARY_STRUCTURE property for our context node. Same as the case when this node is created at the design time, we can use the name of the development objects created in the ABAP Dictionary as Structure or Views

wdDoExit

This method can be considered the controller destructor. It is automatically called when exiting the controller, and can be used for executing closing statements.

In the ABAP Dictionary, we have defined a lock for the database table YPERSON. We can use wdDoExit Hook method to release a lock that has been set for this table to synchronize the access of several WD applications to the same data. To do this, we have to use the generated DEQUEUE_EYPERSON Function Module (Listing).

The wdDoExit Hook method

 METHOD wddoexit .
 DATA lv_id_candidate TYPE yperson-id_person.
 DATA lr_node TYPE REF TO if_wd_context_node.
 DATA ls_data TYPE wd_this->element_candidate.
 lr_node = wd_context->get_child_node('CANDIDATE').
 lr_node->get_attribute( EXPORTING name = 'ID_PERSON'
 IMPORTING value = lv_id_candidate).
 CALL FUNCTION 'DEQUEUE_EYPERSON'
 EXPORTING
 id_person = lv_id_candidate.
 ENDMETHOD.

Here we have called the Function Module directly from our WD method, but we can create a method in a class used as model for theWDcomponent. If we don’t call the corresponding DEQUEUE_EYPERSON Function Module to release the database record that was locked with the EQUEUE_EYPERSON Function Module, this lock is generally removed at the end of the transaction.

wd Do Modify View

This method is mostly used in the dynamic programming, it is a method used for modifying the view before rendering. For the dynamically programming of the UI elements, we have many classes and methods that help us as application developer to dynamically modify a view. To show this, we create an example, aWDcomponent, where we use this Hook method to dynamically create an InputField, a Label, a TextView and a LinkToAction UIelement. The WD component structure and the context node are presented.

WD component structure and context node

For the scope of this example, we import in the MIMEs (Multipurpose Internet Mail Extensions) folder an image: next.JPG that we use for the linkToAction UI element. To import a file in this folder, we right-click on the WD component name and, from the contextual menu, we chooseCreate -> Mime Object -> Import.

The context node PERSON has the Cardinality 1. . .1, Singleton. Its attributes are NAME and GREETING, of string type. We can almost use the same example as for our first exercise. In this case, we create at design time only the UI element Group, the other UI elements being dynamically created by using the wdDoModify- View Hook method.The view layout is presented.

View layout

Listing shows the content of the wdDoModifyView Hook method By using the FIRST_TIME parameter of WDY_BOOLEAN type, we check if wdDoModifyView is called for the first time. In case this parameter is ABAP_TRUE (first time), we create a label UI Element:

 lr_label = cl_wd_label=>new_label(
 id = ‘NAME_LBL’
 label_for = ‘NAME’
 text = ‘NAME’).

To do this, we use the method new_label of the cl_wd_label class interface

The WdDoModifyView Hook method

 METHOD wddomodifyview .
 DATA lv_bind_name TYPE string.
 DATA lv_bind_greeting TYPE string.
 DATA lr_link_to_action TYPE REF TO cl_wd_link_to_action.
 DATA lr_container TYPE REF TO cl_wd_group.
 DATA lr_flow_data TYPE REF TO cl_wd_flow_data.
 DATA lr_input_field TYPE REF TO cl_wd_input_field.
 DATA lr_text_view TYPE REF TO cl_wd_text_view.
 DATA lr_label TYPE REF TO cl_wd_label.
 IF first_time EQ abap_true.
 lr_label = cl_wd_label=>new_label(
 id = 'NAME_LBL'
 label_for = 'NAME'
 text = 'NAME').
 lr_flow_data = cl_wd_flow_data=>new_flow_data(element =
 lr_label).
 lr_container ?= view->get_element('GRP').
 lr_container->add_child(lr_label).
 lv_bind_name = 'PERSON.NAME'.
 lr_input_field = cl_wd_input_field=>new_input_field(
  id = 'NAME'
 bind_value = lv_bind_name).
 lr_flow_data = cl_wd_flow_data=>new_flow_data(
 element = lr_input_field).
 lr_container->add_child( lr_input_field).
 lr_link_to_action = cl_wd_link_to_action=>new_link_to_action(
 id = 'LTA_LINKTOACTION'
 on_action = 'NEXT'
 image_source = 'NEXT.JPG').
 lr_flow_data = cl_wd_flow_data=>new_flow_data( element =
 lr_link_to_action).
 lr_container->add_child(lr_link_to_actio ).
 lv_bind_greeting = 'PERSON.GREETING'.
 lr_text_view = cl_wd_text_view=>new_text_view(
 id = 'TXV_NAME'
 bind_text = lv_bind_greeting).
 lr_flow_data = cl_wd_flow_data=>new_flow_data(element =
 lr_text_view).
 lr_container->add_child(lr_text_view).
 ENDIF.
 ENDMETHOD.

The new_label method has many mandatory and optional parameters. We have used label_for, text and ID to set the main properties of the Label UI element. The text parameter helps us to set the label text. The Label_for parameter specifies the UI element for which this label is.

To embedding the UI elements into the layout, we need to specify the arrangement of these elements. For this, we have used the FlowLayout layout:

lr_flow_data = cl_wd_flow_data=>new_flow_data( element = lr_label).

Class interface CL_WD_LABEL

Parameters for the new_label method

After creating the UI element and setting the layout, we have to attach them to the ROOTCONTAINERUIELEMENT or to another container.In our case, we have attached our new created label to the UI element Group with the GRP ID.

lr_container ?= view->get_element(‘GRP’).
lr_container->add_child(lr_label).

We have used the method add_child( ) that enabled us to do this.After this,we create an InputField UI element:

 lr_input_field = cl_wd_input_field=>new_input_field(
 id = ’NAME’
 bind_value = lv_bind_name).

We use the new_input_field method from the cl_wd_input_field class interface.The bind_value parameter represents the value property for the UI element property.In this case, we dynamically create a data binding for this property to the context node PERSON, attribute NAME. Until now, we have seen how we can create a data binding at the design time. In this case, we can’t create a data binding at design time, because this UI element doesn’t exist at the design time; it is dynamically created at runtime.

To dynamically create a data binding of the property bind_value with the NAME attribute, we have to specify the absolute path of this attribute. lv_bind_name = ‘PERSON.NAME’.

In the next step, we dynamically create a LinkToAction UI element:

  lr_link_to_action = cl_wd_link_to_action=>new_link_to_action(
  id = ‘LTA_LINKTOACTION’
  on_action = ‘NEXT’
  image_source = ‘NEXT.JPG’
  ).

We use the method new_link_to_action of the cl_wd_link_to_action class interface. This UI element has an event associated. We have used the parameter on_action to define the action that the Framework triggers when the user interacts with this UI element.

For a linkToAction UI element, we can define a hypertext link or we can use an image instead a text.In our case, we have used the parameter image_source to specify the name of the image we want to use. Then, we specify the layout and we attach it to our UI element Group with the same GRP ID.

At the end, we dynamically create a TextView UI element by using the new_text_view method of the cl_wd_text_view class interface

  lr_text_view = cl_wd_text_view=>new_text_view(id = ’TXV_NAME’bind_text = lv_bind_greeting).

The data binding to the context attribute GREETING is dynamically created.After creating the UI element, we specify the layout and we attach it to our UI element Group with the same GRP ID.

When the user presses the linkToAction UI element, the Framework triggers the event handler method onactionnext(Listing ).

Action Next

The onactionnext event handler method

 METHOD onactionnext .
  DATA: lv_name TYPE string,
  lv_greeting TYPE string.
  DATA lr_node TYPE REF TO if_wd_context_node.
  DATA ls_data TYPE wd_this->element_person.
  lr_node = wd_context->get_child_node( 'PERSON').
  lr_node->get_attribute(EXPORTING name = 'NAME'
  IMPORTING value = lv_name).
  CONCATENATE
  'Welcome' lv_name INTO lv_greeting SEPARATED BY space.
  ls_data-greeting = lv_greeting.
  lr_node->set_static_attributes(ls_data).
  ENDMETHOD.

Runtime

In case we want to set “required” the state property of the Input UI element, we need only an extra line code:

  lr_input_field = cl_wd_input_field=>new_input_field(
  id = ‘NAME’
  state = cl_wd_input_field=>e_state-required
  bind_value = lv_bind_name).

We use the state parameter to dynamically set the property with the same name of the InputField UI element.If we don’t use this optional parameter, the default value is set: CL_WD_INPUT_FIELD=>E_STATE-NORMAL.

wd Do Before Action

We can use this method to perform our own validation before an action is triggered.To exemplify this,we create a Web Dynpro component named Y_WDDOBEFOREACTION with a view named V_VIEW and a window W_DEFAULT.

In the context view, we create the well-known context node named STUDENT,with the same dictionary structure YSTR_PERSON, cardinality 1...1, singleton,without supply function. Our scope is to check if the user enters values in all the in put Fields UI elements bound to the attributes of the context node STUDENT. TheView layout is presented.

The View layout

In the wd Do Before Action Hook method, we use the static method CHECK_MANDATORY_ATTR_ON_VIEW of the CL_WD_DYNAMIC_TOOL class to check if the user had entered values in all the mandatory fields (the state property of the inputField UI elements is set required).

The wdDoBeforeAction Hook method

  METHOD wddobeforeaction .
  DATA lr_api_controller TYPE REF TO if_wd_view_controller.
  DATA lr_action TYPE REF TO if_wd_action.
  lr_api_controller = wd_this->wd_get_api( ).
  lr_action = lr_api_controller->get_current_action( ).
  IF lr_action IS BOUND.
  CASE lr_action->name.
  WHEN ‘SAVE’.
  cl_wd_dynamic_tool=>check_mandatory_attr_on_view(
  view_controller = lr_api_controller).
  ENDCASE.
  ENDIF.
  ENDMETHOD.

When the user presses the Save button, the Web Dynpro Framework firstly checks,by using the wdDoBeforeAction Hook method, if all the required fields are filled.In case the user doesn’t enter values in all these fields, all the operations that had to take place after pressing the Save button are finished and the user is informed about this,through error messages and by highlighting the UI elements that generated these messages. In this way, we don’t have to manually check each mandatory field.

Runtime

wd Do On Context Menu

We can use this method to provide hierarchical context menus in web Dynpro Views.In our first example, we have already seen the default context menu displayed by the Web Dynpro Framework when the user presses right-click on an UI element.

We can create a context menu at design time,by using the CONTEXT_MENUS root,or dynamically, by coding the wd Do On Context Menu Hook method.To exemplify how we can use this method to dynamically create context menus, we use the example from the wdDoBeforeAction Hook method. In this case,we offer to the user the possibility to personalize the field he wants to be mandatory. He will be able to choose between his first name as mandatory field and his last name as mandatory field.

When he chooses the first name as mandatory,we will mark the corresponding field with a red star, and when he chooses the last name, we will mark the corresponding field with a red star. In the default mode, the first name is set as mandatory.

To create this example, we have to perform some modifications into the last application.In this case,we have to set dynamic the state properties of the two inputField UI elements,corresponding to first name and last name. To be able to do this, we have to create, in the context view,two extra context attributes of WDUI_STATE type,to bind these attributes with the corresponding properties. In this way, at design time, the two inputField UI elements are not marked as mandatory,anyway. To set in the default mode the first name as mandatory,we use the wdDoInit Hook method we have just learnt about.

Context structure and data binding

Setting the initial values for our node DYNAMIC

  METHOD wddoinit .
  DATA lr_node TYPE REF TO if_wd_context_node.
  DATA ls_data TYPE wd_this->element_dynamic.
  lr_node = wd_context->get_child_node('DYNAMIC').
  ls_data-first_name = cl_wd_input_field=>e_state-required.
  ls_data-last_name = cl_wd_input_field=>e_state-normal.
  lr_node->set_static_attributes(ls_data).
  ENDMETHOD.

To offer to the end user the capability to dynamically choose what value he wants to be mandatory from the two optional values, we have to code the wd Do On-ContextMenu Hook method.

With the first data statement, we create a local reference to the CL_WD_MENU class and two local references to the CL_WD_MENU_ACTION_ITEM, required to dynamically create our menu,and two menu options of menuActionItem type. We need the two menu options to offer to the user the possibility to choose between options:set first name as mandatory or set last name as mandatory.

With the second data statement, we create two local variables required to read from the context attributes the status properties corresponding to the two input-Fields UI elements(firstname, lastname)and a local reference required to access our context node. Firstly,we create a context menu by using the static method new_menu of the cl_wd_menu class.

By using the static method new_menu_action_item of the cl_wd_menu_action_item class, we create the two menu options we need.Fromthe parameters of this class,we have used:

id: To set the ID of the view element
on_action: To associate the action that will be triggered when the user presses the respective option
text: The text that will be displayed for the respective menu option

The wd Do On Context Menu example

  METHOD wddooncontextmenu .
  DATA: lr_menu TYPE REF TO cl_wd_menu,
  lr_menu_item1 TYPE REF TO cl_wd_menu_action_item,
  lr_menu_item2 TYPE REF TO cl_wd_menu_action_item.
  DATA: lr_node TYPE REF TO if_wd_context_node,
  lv_first_name TYPE wdui_state,
  lv_last_name TYPE wdui_state.
  lr_node = wd_context->get_child_node('DYNAMIC').
  lr_node->get_attribute(EXPORTING name = 'FIRST_NAME'
  IMPORTING value = lv_first_name).
  lr_node->get_attribute(EXPORTING name = 'LAST_NAME'
  IMPORTING value = lv_last_name).
  lr_menu = cl_wd_menu=>new_menu(id = 'CONTEXT_MENU').
  IF lv_first_name = 01 AND lv_last_name = 00.
  lr_menu_item1 = cl_wd_menu_action_item=>new_menu_action_item
  id = 'LAST_NAME'
  on_action = 'LN_MANDATORY'
  text = 'Set last name as mandatory').
  lr_menu_item2 = cl_wd_menu_action_item=>new_menu_action_item
  id = 'FIRST_NAME'
  on_action = 'FN_MANDATORY'
  text = 'set first name as mandatory'
  enabled = abap_false).
  ELSEIF lv_first_name = 00 AND lv_last_name = 01.
  lr_menu_item2 = cl_wd_menu_action_item=>new_menu_action_item
  id = 'FIRST_NAME'
  on_action = 'FN_MANDATORY'
  text = 'set first name as mandatory').
  lr_menu_item1 = cl_wd_menu_action_item=>new_menu_action_item
  id = 'LAST_NAME'
  on_action = 'LN_MANDATORY'
  text = 'Set last name as mandatory'
  enabled = abap_false).
  ENDIF.
  lr_menu->add_item(the_item = lr_menu_item1).
  lr_menu->add_item(the_item = lr_menu_item2).
  menu = lr_menu.
  ENDMETHOD.

enabled: To set if this option is active or inactive. In the default mode,this parameter is set ABAP_TRUE,respective enabled

The local variables used to pass the values of the two attributes (firstname and lastname) are of the same type as the attributes: WDUI_STATE.By doubleclicking on the TYPE,the forward navigation is open and we can see a data element with a Domain as an elementary type.This domain has two fixed values:00 for Normal item and 01 for required.

Before we effectively create the two menu options, we have to check which one of the two state proprieties is set required and which one is set normal.In case the firstname is required and lastname is normal,we create the two menu options with “Set last name as mandatory” active and “Set first name as mandatory” inactive.In case the firstname is normal and the lastname is required,we create the two menu options with “Set last name as mandatory” inactive and “Set first name as mandatory”active.

Then, we add the two created menu options of menuActionItem type to our context menu and display the respective menu by using the wdDoOnContextMenu Hook method, returning the parameter named menu. we have already seen that, for our InputFields UI elements, we have set the properties:

context Menu Behaviour: Provides, not inherits from the container

context Menu Id: Set with the IDs of our context menu options

Runtime

All we have to do now is to create the respective actions: FN_MANDATORY and LN_MANDATORY,actions that the Framework triggers when the user presses our menu action items. The onactionln_mandatory event handler method is presented.

Event handler method triggered for the menu option with LAST_NAME ID

  method ONACTIONLN_MANDATORY .
  DATA lr_node TYPE REF TO if_wd_context_node.
  DATA ls_data TYPE wd_this->element_dynamic.
  lr_node = wd_context->get_child_node('DYNAMIC').
  ls_data-first_name = cl_wd_input_field=>e_state-normal.
  ls_data-last_name = cl_wd_input_field=>e_state-required.
  lr_node->set_static_attributes(ls_data).
  endmethod.

In case the user chooses the last name as mandatory, we have to set required the property state of the corresponding UI element and normal the property state of the UI element corresponding to the first name.

The onactionfn_mandatory event handler method is presented in Listing In case the user chooses the first name as mandatory, we have to set required the property state of the corresponding UI element and to set normal the property state of the UI element corresponding to the last name.

Event handler method triggered for the menu option with FIRST_NAME ID

  method ONACTIONFN_MANDATORY .
  DATA lr_node TYPE REF TO if_wd_context_node.
  DATA ls_data TYPE wd_this->element_dynamic.
  lr_node = wd_context->get_child_node('DYNAMIC').
  ls_data-first_name = cl_wd_input_field=>e_state-required.
  ls_data-last_name = cl_wd_input_field=>e_state-normal.
  lr_node->set_static_attributes(ls_data).
  endmethod.

Runtime

Supply Function Methods

We have used this type of methods every time we have assigned a supply function to a context node, every time we have populated the context attributes of the context nodes with initial values via supply function. When a controller is called, these methods are called first. We have seen that a supply function can be assigned to each context node of a Controller.

Context node and supply function

The Framework generates a corresponding supply function method.An alternative for the supply function methods can be the wdDoInit Hook method, if we know that the context is filled only once at initialization and it is not invalidated afterwards.

Supply function

User-Defined Instance Methods

In the Methods tab, we can create our own user-defined methods with or without parameters. After creating a user-defined method, we can call it in the same controller, by using the wd_this self reference.

In this case, we copy our example from the wdDoModifyView Hook method and we create two extra user-defined methods:

A method named GREETING that has two import parameters
A method named PERFORM_VALLIDATION that has one import parameter

In the ONACTIONNEXT event handler method, we check whether the attribute NAME is initial, respective if the user didn’t enter his first name. In case of initial attribute, we call our own defined PERFORM_VALIDATION method. By using this method, we show an error message. In case this attribute is not empty, we call our own defined GREETING method to create a greeting for the end user.

The user-defined GREETING method. As we can see, this method has defined an importing parameter named P_NAME of STRING type and an importing parameter named P_NODE of ref to if_wd_context_node type. The P_NAME parameter holds the value of the NAME attribute.

The user-defined PERFORM_VALIDATION method. As we can see, this method has an importing parameter named P_ELEMENT, referable to the interface IF_WD_CONTEXT_ELEMENT.

In this case, we have used the method REPORT_ATTRIBUTE_ERROR_MESSAGE of the interface IF_WD_MESSAGE_MANAGER to report a Web Dynpro error message to a context attribute.

The ONACTIONNEXT event handler method. As we can see, the local variable lv_name holds the value of the NAME attribute. If this attribute is empty, we have to show an error message. To do this, we use our own defined PERFORM_VALIDATION method.

User-defined GREETING method

User-defined PERFORM_VALIDATION method

wd_this->perform_validation(EXPORTING p_element = lr_element). If this attribute is not initial, we use its value as exporting parameter for our own defined method GREETING.

The onactionnext event handler method

 METHOD onactionnext .
 DATA lr_node TYPE REF TO if_wd_context_node.
 DATA ls_data TYPE wd_this->element_person.
 DATA lv_name TYPE string.
 DATA lr_element TYPE REF TO if_wd_context_element.
 lr_node = wd_context->get_child_node('PERSON').
 lr_element = lr_node->get_element( ).
 lr_node->get_attribute(EXPORTING name = 'NAME'
 IMPORTING value = lv_name).
 IF lv_name IS INITIAL.
 wd_this->perform_validation(EXPORTING p_element = lr_element).
 ELSE.
 wd_this->greeting(EXPORTING p_name = lv_name
 p_node = lr_node).
 ENDIF.
 ENDMETHOD.

Runtime

Fire Methods

A Fire method is a special kind of method generated by the Framework when we define an outbound plug.We need inbound plugs and outbound plugs to define the navigation between two views.These plugs are the entry and the exit point for each view. We create an example,a WD component that has two Views. The WD component structure is presented.

WD component structure

In this case, we want to navigate from the view V_VIEW1 to the view V_VIEW2, when the Framework triggers an event handler method, respective when the user presses a button. In the COMPONENTCONTROLLER,we create a context node PERSON, Cardinality 1...1,Singleton and one attribute NAME of string type.

Context structure

The data stored in the context of the component controller are used within the two views V_VIEW1 and V_VIEW2, through context mapping.

View V_VIEW1 layout

View V_VIEW2 layout

When the user presses the Next button,we want to navigate from the view V_VIEW1 to the view V_VIEW2.The view V_VIEW1 will be replaced with the view V_VIEW2. This navigation is possible through a navigation link between the views, in the window.

Plugs and navigation

To set up navigation between our views, we must create an inbound plug for the view V_VIEW2 and an outbound plug for the V_VIEW1. In the Outbound Plug tab of the view V_VIEW1, we create an outbound plug named OP_TO_V_VIEW2.

Out bound plug

In the Inbound plug tab of the view V_VIEW2,we create an inbound plug named IP_V_VIEW2.

In bound plug

When the user presses the Next button,the Framework triggers the event handler method onactionnext.Every time we create an outbound plug for a view,a special method is added to its interface. This method has the statement FIRE_<NAME_OUTBOUND_PLUG>_PLG. To fire this method, we can use the Web Dynpro CodeWizard or select an outbound plug when creating an Action.

The event handler method has the following statement:

 METHOD onactionnext .
 wd_this->fire_op_to_v_view2_plg( ).
 ENDMETHOD.

Creating an action

We use the self-reference WD_THIS of the view controller to fire the method FIRE_OP_TO_V_VIEW2_PLG that was added to this interface when we have created the outbound plug.

All the views within a window can be connected to each other by using navigation links.To be able to create the navigation,we embed the views in the window and then we drag & drop the outbound plug to the inbound plug. We can also create navigation by right-clicking on the output plug name.

Creating navigation link

At runtime, when the user interacts with the view V_VIEW1, his interaction will cause a request to the server.In response, the view V_VIEW1 will be replaced with the view V_VIEW2. This is possible through the navigation link defined between these views.

Event Handler Methods

An event handler method responds to actions or to events. We have used this type of methods every time we have assigned an action to an UI element.This kind of methods are special methods of a view controller that has the prefix ONACTION followed by the action name. As we have seen,the action is defined in the Action tab and the corresponding event handler method is generated by the Framework.

Action and event handler method

We can assign an action to an UI element that has an event, indifferent if this UI element is created dynamically or at the design time.

Action and UI element

Let’s create an example where we use an event handler method implemented to respond to events of inbound plugs!

We have seen that the outbound plugs are the starting point of navigation, called in any method of the view controller by using the statement:

wd_this->FIRE_<NAME_OUTBOUND>_PLG( ).

This method allows also parameter transfer

wd_this->FIRE_<NAME_OUTBOUND>_PLG(PARAMETER = ‘value’).

In this case, the PARAMETER has to be entered in the parameter table of the view controller. For a better understanding,we create the same example as for the fire methods, but in this case we show an error message when the user doesn’t enter a value in the inputField UI element.We will pass a reference to Message Manager from a view to another view, via an outbound parameter. In the View_1 we add in the parameter table,on the Outbound plug,a parameter named P_MM.

Defining the parameter for an Outbound Plug

When the user presses the Next button, the Framework triggers the event handler method onactionnext.

Event handler method

 METHOD onactionnext .
 DATA: lr_api_controller TYPE REF TO if_wd_controller,
 lr_api_manager TYPE REF TO if_wd_message_manager.
 lr_api_controller ?= wd_this->wd_get_api( ).
 lr_message_manager = lr_api_controller->get_message_manager( ).
 wd_this->fire_op_to_v_view2_plg( p_mm = lr_message_manager).
 ENDMETHOD.

Inbound plug

We don’t have the possibility to create a parameter for an Inbound Plug.In this case, we use the event handler method HANDLEIP_V_VIEW2 to read the value of the P_MM parameter.

When an inbound plug is called, the handler method that is uniquely assigned to this inbound plug is called. This method is automatically generated in the view controller when the inbound plug is created.We find this method in the Methods tab of the view V_VIEW2.

Event handler method

The value of the parameter P_MM is passed by the outbound plug OP_TO_V_VIEW2. To be able to read the value of this parameter, we have to add the parameter P_MM to the signature of the event handler method assigned to the inbound plug,i.e.the HANDLEIP_V_VIEW2 event handler method.

Event handler method. Implementation

In this way, the value of the P_MM parameter is known by the event handler method and can be used to send a message in case the user doesn’t enter a value in the InputField UI element.

2012-09-22T23:03:00.001-07:00

Layout UI Elements

The following section details and describes the Layout of the UI elements. Here, we are going to present the various types of existent Layouts and the modality to use them, either in static or in dynamic variant. The layout helps us to manage the arrangement of the UI elements within their parent container.

All the UI elements within a view are hierarchy arranged. The node ROOTUIELEMENTCONTAINER is the root of this hierarchy and all the UI elements. within a view are children of this root container. It is of TransparentContainer type and has initially assigned to it the FlowLayout layout. In our first example, we have seen that we have the possibility to change it from ransparentContainer into another UI element, in case this one doesn’t have any children. Table shows the layout UI elements that are available for arranging the UI elements in a view, and the corresponding LayoutData. The layout is the abstract base class of all the layout UI elements within Web Dynpro and has the runtime class CL_WD_LAYOUT.

Layout and LayoutData UI element

The layout data of an UI element are used to specify the position within a container and have the runtime class CL_WD_LAYOUT_DATA.

Flow Layout

If we use the FlowLayout layout, all the UI elements are displayed in a line. Byusing the property WRAPPING of the container into which the UI elements are going to be integrated, we can manipulate the modality of putting these UI elements on screen. In case this property is ABAP_TRUE, the UI elements that don’t enter in the first line are arranged bellow, in another line, to automatically adapt to the client window. In case of ABAP_FALSE, the UI elements are not automatically adapted to the client window.

For a better understanding, we create a Registration Form with three fields: first name, last name and date of birth. The WD component structure and the view layout are presented.

WD component structure and view layout

In View context, we create the same well-known STUDENT contextnode with the dictionary structure YSTR_PERSON.

ROOTUIELEMENTCONTAINER and Group UI element are both UI elements of container type, which have the FlowLayout layout in the default mode. Each UI element reference to a LayoutData object and every UI element inserted within a container must have the data layout that matches the respective container.

Layout and layout data

Runtime: wrapping ABAP_TRUE

As we can see, the UI elements are arranged in a line. Because the attributes of STUDENT context node are empty, the InputField’s UI elements bound to these attributes are not shown. After the user presses the Save Button, we show all the data that the user has entered in the InputField UI elements. In this case, all the UI elements don’t enter in a line anymore, because the client window is too small for that. The elements that don’t enter in the first line are arranged below in another line, to automatically adapt to the client window.

We can see that, for the layout data, we can set two properties: cellDesign that specifies the distance between rows and vGutter that specifies the additional distance to the left edge. The default of these values is cellDesign – padless (there is no distance between the row and the edges) and vGutter – none (no additional distance). In case the wrapping property is ABAP_FALSE, the UI elements that don’t enter in the first line are not arranged below in another line, they are not visible anymore.

Runtime: wrapping ABAP_FALSE

For a dynamic manipulation, we can use the runtime class CL_WD_FLOW_DATA to embedding the UI elements into the container that has a FlowLayout layout.An example of using this class we have seen in the wdDoModifyView example.

GridLayout

f we use the GridLayout layout, all the UI elements are arranged in container in a tabular grid with a fixed number of columns. We can specify the number of columns in the grid by usingthe property colCount. The number of rows depends on the number of the UI elements added to the container.We create the same example, but in this case we use GridLayout layout for the Group container.

Group container: GridLayout

We arrange all the UI elements from the GRP Group UI element in two columns.In this case, at runtime we have: As we can see,the number of columns is two and the number of rows is five.We want the Save button to remain alone in its row. To do this, we have to use an InvisibleElement.

Runtime

This UI element is an invisible element on the screen and can be used to fill an empty cell in the GridLayout.

InvisibleElement and GridLayout

For a dynamic manipulation, we can use the runtime class CL_WD_GRID_ DATA to embedding the UI elements into the GRP container that has a GridLayout layout.

UI elements into the GRP container that has a GridLayout layout

 METHOD wddomodifyview.
 DATA lv_bind_attribute TYPE string.
 DATA lr_input_field TYPE REF TO cl_wd_input_field.
 DATA lr_container TYPE REF TO cl_wd_group.
 DATA lr_label TYPE REF TO cl_wd_label.
 DATA lr_grid_data TYPE REF TO cl_wd_grid_data.
 IF first_time EQ abap_true.
 lr_label = cl_wd_label=>new_label(id ='FIRSTNAME_LABEL' label_for ='FIRSTNAME' ).
 lr_grid_data = cl_wd_grid_data=>new_grid_data(element = lr_label).
 lr_container ?= view->get_element('GRP').
 lr_container->add_child(index = 1 the_child = lr_label).
 lv_bind_attribute = 'STUDENT.FIRSTNAME'.
 lr_input_field = cl_wd_input_field=>new_input_field(
id ='FIRSTNAME' bind_value = lv_bind_attribute).
 lr_grid_data = cl_wd_grid_data=>new_grid_data(element = lr_input_field).
 lr_container ?= view->get_element('GRP').
 lr_container->add_child(index = 2 the_child = lr_input_field ).
 ENDIF.
  ENDMETHOD.

In this example,we dynamically created the first two UI elements: InputField for the user first name and the corresponding label. To embed these UI elements into the GRP container (GridLayout),we use the proper GridData layout.

MatrixLayout

If we use the MatrixLayout, all the UI elements from a container are arranged in columns. With MatrixLayout, we can produce a grid with a variable number of columns per row. Each UI element inserted in a container that has the MatrixLayout layout will contain either a MatrixData object or a MatrixHeadData object.

Layout and layout data

An UI element that has MatrixHeadData data layout starts a new row and the UI elements that have MatrixData data layout are shown in the same row, until an UI element is set MatrixHeadData and a new row is created.

UI elements arranged in a container by using a MatrixLayout layout

For a dynamic manipulation, we can use the runtime class CL_WD_MATRIX_ HEAD_DATA and CL_WD_MATRIX_DATA to embed the UI elements into the GRP container that has a MatrixLayout layout .

GRP container that has a MatrixLayout layout

 METHOD wddomodifyview.
 DATA lv_bind_attribute TYPE string.
 DATA lr_input_field TYPE REF TO cl_wd_input_field.
 DATA lr_container TYPE REF TO cl_wd_group.
 DATA lr_label TYPE REF TO cl_wd_label.
 DATA lr_matrix_head_data TYPE REF TO cl_wd_matrix_head_data.
 DATA lr_matrix_data TYPE REF TO cl_wd_matrix_data.
 IF first_time EQ abap_true.
 lr_label = cl_wd_label=>new_label(id ='FIRSTNAME_LABEL'
 label_for ='FIRSTNAME').
 lr_matrix_head_data =
 cl_wd_matrix_head_data=>new_matrix_head_data(element = lr_label).
 lr_container ?= view->get_element('GRP').
 lr_container->add_child(index = 1 the_child = lr_label).
 lv_bind_attribute ='STUDENT.FIRSTNAME'.
 lr_input_field = cl_wd_input_field=>new_input_field(id ='FIRSTNAME'
 bind_value = lv_bind_attribute).
 lr_matrix_data = cl_wd_matrix_data=>new_matrix_data(element =
 lr_input_field).
 lr_container ?= view->get_element('GRP').
 lr_container->add_child(index = 2 the_child = lr_input_field).
 ENDIF.
 ENDMETHOD.

RowLayout

If we use RowLayout, all the UI elements from a container are arranged into horizontal rows. Each UI element inserted in a container that has the RowLayout layout will contain either a RowData object or a RowHeadData object.

Layout and layout data

This kind of layout is helpful when we want to arrange our UI elements into horizontal rows,but where we don’t need a vertical alignment between the resulting columns..

UI elements arranged in a container by using a RowLayout layout

For a dynamic manipulation, we can use the runtime class CL_WD_ROW_ HEAD_DATA and CL_WD_ROW_DATA to embed the UI elements into the GRP container that has a RowLayout layout..

GRP container that has a RowLayout layout

 METHOD wddomodifyview.
 DATA lv_bind_attribute TYPE string.
 DATA lr_input_field TYPE REF TO cl_wd_input_field.
 DATA lr_container TYPE REF TO cl_wd_group.
 DATA lr_label TYPE REF TO cl_wd_label.
 DATA lr_row_head_data TYPE REF TO cl_wd_row_head_data.
 DATA lr_row_data TYPE REF TO cl_wd_row_data.
 IF first_time EQ abap_true.
 lr_label = cl_wd_label=>new_label(id ='FIRSTNAME_LABEL'
 label_for = 'FIRSTNAME').
 lr_row_head_data = cl_wd_row_head_data = >new_row_head_data(element = lr_label).
 lr_container ?= view->get_element('GRP').
 lr_container->add_child(index = 1
 the_child = lr_label).
 lv_bind_attribute ='STUDENT.FIRSTNAME'.
 lr_input_field = cl_wd_input_field= new_input_field(id ='FIRSTNAME'
 bind_value = lv_bind_attribute).
 lr_row_data = cl_wd_row_data=>new_row_data(element =lr_input_field).
 lr_container ?= view->get_element('GRP').
 lr_container->add_child(index = 2 the_child = lr_input_field).
 ENDIF.
 ENDMETHOD.

2012-09-22T23:02:00.009-07:00

User Interface Elements (UI elements) Static and Dynamic Programming-part 1

The UI elements we can use in the Web Dynpro ABAP are divided in various categories.In this chapter, we are going to present some of the UI elements, included in the categories:action, selection,layout, complex, graphic and integration. Each UI element will be illustrated by an example,showing the modality of using it either in static or in dynamic variant.

A UI element is a User Interface element we use to create a screen for the end user. The UI Elements are grouped in categories we can access via the View Layout,and each UI Element has some properties, as follows

Common with other UI elements,inherited from superclasses
Specific only for an UI element
For example, the following properties are inherited:
Tooltip: Shows a quick info text when the user passes the mouse pointer over the UI element
Visible: Determined if an UI element is visible in the screen or not
Enabled: Specified if the UI element is active or inactive

By using the Class Builder transaction SE24, we can see different classes along with their inheritances and attributes. For example, the class CL_WD_UIELEMENT is the super class of all the UI elements we use in Web Dynpro ABAP. Being super class, this class has CL_WD_VIEW_ELEMENT. presents the tooltip,visible and enable properties for an InputField UI element.

Most of the UI elements properties can be bound to different context nodes or attributes.In this way, we can manipulate the UI elements via the data held in the context. Each bindable property of a UI element has a certain type. For example,the enabled property can be bound to an attribute of WDY_BOOLEAN type.

when this attribute is set ABAP_TRUE, the respective UI element is active.When this attribute is set ABAP_FALSE, the respective UI element is inactive.

The UI elements, along with the aggregations, determine the appearance and behaviour of the UI elements on the screen. The Web Dynpro UI elements are divided in categories. Hereunder, we present some of these categories.

Graphic

This category contains UI elements that help us to work with graphics maps,etc. Hereunder,we present some of the UI Elements included in this category.

Image

This UI element enables us to integrate graphics in our WD application. Same as other UI elements, it has some properties. Hereunder,we show a table with some of the Image UI element properties that can be bound,and the attribute type in case the property is bindable.

Some of the Image UI element properties

We create a WD Component, where we can choose among three images and we can manipulate the current image via the data held in the context.The WD component structure is presented.

WD component structure

We import three images in JPG format.As we have mentioned,to import an image into a MIME folder,we have to choose Create Mime Object Import from the contextual menu,shown by right-clicking on the WD component name.

The context node DYNAMIC is Singleton, cardinality 1...1. The attributes WIDTH and HEIGH are STRING type and the attribute BORDER is I type. We use these attributes to manipulate the properties of the Image UI element. For the attributes WIDTH,BORDER and HEIGH, it is defined the data binding to the properties (with the same names) of the UI element Image.

Context structure and data binding

The context node DROPDOWNBYINDEX has the dictionary structure SHSVALSTR2,cardinality 0...n,Singleton.We have defined a data binding between the attribute KEY and the property texts of the dropDownByIndex UI element. The attribute VALUE is used to manipulate the property source of the Image UI element.This property defines the name of the image file shown on the screen.

View Layout structure

To populate with values the context attributes of the context node DROPDOWNBYINDEX, we use the supply function method shown in the Listing.

Supply function method

 METHOD supply_dropdownbyindex.
 DATA:
 ls_image TYPE wd_this->element_drop down by index,lt_image LIKE TABLE OF ls_image.
 ls_image-key ='Germany'.
 ls_image-value ='deutschland.jpg'.
 APPEND ls_image TO lt_image.
 ls_image-key = 'France'.
 ls_image-value ='france.jpg'.
 APPEND ls_image TO lt_image.
 ls_image-key ='Italy'.
 ls_image-value ='italia.jpg'.
 APPEND ls_image TO lt_image.
 node->bind_table(
 new_items =lt_image
 set_initial_elements = abap_true).
 ENDMETHOD.

Runtime

Dynamic Programming

RUNTIME CLASS: CL_WD_IMAGE

Hereunder,we present a table showing the correspondence between the view designer name and the runtime name, with the proper types,in case of dynamic programming of an Image UI element.

The implementation of a dynamic Image UI element contains the following statements:

Dynamic creation of an Image UI element

 data lr_image type ref to cl_wd_image.
 data lr_image type ref to cl_wd_image.
 Ir_image = cl_wd_image=>new_image( id =‘IMG_IMAGE’
 bind_width =‘DYNAMIC.WIDTH’
 bind_height =‘DYNAMIC.HEIGHT’
 bind_border =‘DYNAMIC.BORDER’
 bind_source =‘DROPDOWNBYINDEX.VALUE’).

BusinessGraphics

This UI element enables us to use several chart types in our WD application.The Internet Graphics Service (IGS) helps us to work with this UI element,being able to show graphics in a browser.

The chart engine is a C++ library that supports chart types, from simple charts (e.g. bars or pie) to complex charts(e.g. gantt).We create a WD Component with the structure presented in Fig. By using the BusinessGraphics UI element,we show the graphical illustration of the data stored in our database table YPERSON.

WD component structure

Context structure

The node person has the dictionary structure YPERSON, cardinality 1...n, Singleton. From this structure,we choose only LASTNAME and AGE. We have used a chart of columns type,to graphically display the data contained by the columns of our database table.

View Layout

By using the supply function, we populate the node PERSON with data from the database table YPERSON. We select all the data from the two columns LASTNAME and AGE.

Runtime

To perform customizing settings for business graphics, we have to use the SAP Chart Designer. We access this tool by double-clicking on the chart picture, in the view layout. Now,the SAP Chart Designer is open and we can customise our chart.

Chart designer

We save the settings we made; the Framework generates a MIME file in XML format and sets the property customizing of the BusinessGraphics UI element.

Saving the customizing in a XML file

Runtime result

Dynamic Programming

RUNTIME CLASS: CL_WD_BUSINESS_GRAPHICS

Hereunder,we present a table showing the correspondence between the view designer name and the runtime name, with the proper types,in case of dynamic programming of a BusinessGraphics UI element (Table). For a BusinessGra . The Category object has the CL_WD_CATEGORY runtime class.The Series can be Series,runtime
CL_WD_SERIES or SimpleSeries,runtime class CL_WD_SIMPLE_SERIES

The implementation of a dynamic BusinessGraphics UI element(with a SimpleSeries and a Category)contains the following statements.

Dynamic creation of a BusinessGraphics UI element

 METHOD wddomodifyview.
  DATA lr_flow_data TYPE REF TO cl_wd_flow_data.
 DATA lr_container TYPE REF TO cl_wd_uielement_container.
 DATA lr_businessgraphics TYPE REF TO cl_wd_business_graphics.
 DATA lr_category TYPE REF TO cl_wd_category.
 DATA lr_simpleseries TYPE REF TO cl_wd_simple_series.
 IF first_time EQ abap_true.
 lr_container ?= view->get_element('ROOTUIELEMENTCONTAINER').
 lr_businessgraphics = cl_wd_business_graphics=>new_business_graphics(id = 'BGR'
 chart_type = cl_wd_business_graphics=> e_
 chart_type-columns
 dimension = cl_wd_business_graphics=>e_dimension-two
 height = 300
 width = 300
 bind_series_source = 'PERSON'
 customizing = 'D57PJD6VB3MQAZR78XQHWTMIT.xml'
 ).
 lr_flow_data = cl_wd_flow_data=>
 new_flow_data(element = lr_businessgraphics).
 lr_container->add_child(lr_businessgraphics).
 lr_category ?= cl_wd_category=>new_category(id = 'CATEGORY'
 bind_description = 'PERSON.LASTNAME'
 tooltip ='Candidates last name'
 ).
 lr_simpleseries ?=  cl_wd_simple_series=>
 new_simple_series(id ='SIMPLESERIES'
 label ='Candidate Age'
 bind_value ='PERSON.AGE'
 tooltip ='Candidate Age'
 ).
 lr_businessgraphics->set_category(the_category = lr_category).
 lr_businessgraphics->add_series(the_series = lr_simpleseries).
 ENDIF.
 ENDMETHOD.

Action

The UI elements that contain an action are included in this category.Some of these UI elements we have already used (Button, LinkToAction).

Timed Trigger

This UI element triggers automatically and periodically an event.To specify the periodicity,we have to use its delay property. As we have mentioned above, most of the UI element properties can be bound. Hereunder, we show a table with some of the TimedTrigger properties that can be bound and the attribute type in case the property is bindable

Some of TimedTrigger UI element properties

WD component

At every 5 s, we trigger an event that uses a Function Module to generate a random number under 1,000.In context view, we create a node named COUNTER,cardinality 1...1,Singleton that has an attribute COUNTER_TT of i type.

View layout

We have used an action named TRIGGER to specify the action to be triggered after the specified delay 5.

 METHOD onactiontrigger.
 DATA lr_node TYPE REF TO if_wd_context_node.
 DATA ls_data TYPE wd_this-&gt;element_counter.
 DATA lv_step TYPE i.
 lr_node = wd_context-&gt;get_child_node('COUNTER').
 CALL FUNCTION 'GENERAL_GET_RANDOM_INT'
 EXPORTING
 range = 1000
 IMPORTING
 random = lv_step.
 ls_data-counter_tt = lv_step.
 lr_node-&gt;set_static_attributes(ls_data).
 ENDMETHOD.

The Function Module GENERAL_GET_RANDOM_INT has an import parameter named RANGE of i type and an exporting parameter named RANDOM of i type. This function returns the random value with 0(RANDOM)(RANGE) At runtime.

runtime fig

Dynamic Programming

RUNTIME CLASS: CL_WD_TIMED_TRIGGER

As we have seen,by using the wdDoModifyView( )Hook method we can dynamically create an UI element. The same properties, events and aggregations as in the View Designer are available. Hereunder,we present a table showing the correspondence between the view designer name and the runtime name, with the proper types,in case of dynamic programming of a TimedTrigger UI element .

Dynamic programming

The implementation of a dynamic TimedTrigger UI element contains the following statements.

 DATA lr_timed_trigger TYPE REF TO cl_wd_timed_trigger.
  lr_timed_trigger = cl_wd_timed_trigger=>
 new_timed_trigger(id ='TIMED_TRIGGER'delay = 5 on_action ='TRIGGER').

ButtonChoice

We can use this UI element to choose among the various options offered by the menu. Hereunder, we present a list with some of the ButtonChoice properties that can be bound, and the attribute type in case the property is bindable.

Some of the ButtonChoice UI element properties

We create aWDapplication, where we use the ButtonChoice UI element to offer to the end user a menu list with two options: power and divide. To realise these calculations, we have used the methods of the class CL_FOEV_BUILTINS.As we can see in Fig.this class has many calculation methods,from the PLUS method (that performs a simple addition) to functions,in order to obtain the Integer Part or Hyperbola Sinus.

Class CL_FOEV_BUILTINS

The structure of the POWER method

This method has two importing parameters, named IM_ARG1 and IM_ARG2, and an exporting parameter, named EX_RESULT, of float type. The method DIVIDE has the same parameters.

For this scope, we create our context node named CALCULATE, with the context attributes ARG1 of f type, ARG2 of f type and RESULT of f type, required to perform the calculations and to holdthe result.The WD component structure and the view context structure are presented.

WD component structure and view context structure

The View layout

In the ButtonChoice UI element, we insert two options: menuactionitem1 and menuactionitem2.For the two created options, we set actions(divide and power), and we use the hotkey property to offer to the end user the capability to press the respective key combination to trigger the associated event handler method.

When the user interacts the first time with the ButtonChoice UI element,an action can be selected,and the Framework triggers the proper event handler method. The last selected action remains on the ButtonChoice UI element after the action has been executed. This behaviour is possible through the property repeat SelectedAction.

Some of the ButtonChoice UI element properties

The Framework triggers the event handler method onactiondivide when the user clicks the respective choice option button or he presses the CTRL_D key combination. Listing shows the coding of this method.

 METHOD onactiondivide.
 DATA lr_oref TYPE REF TO cx_foev_error_in_function.
 DATA ls_calculate TYPE wd_this->element_calculate.
 DATA lv_arg1 LIKE ls_calculate-arg1.
 DATA lv_arg2 LIKE ls_calculate-arg2.
 DATA lv_result LIKE ls_calculate-result.
 wd_this->attribute_get(IMPORTING p_arg1 = lv_arg1
 p_arg2 = lv_arg2).
 TRY.
 cl_foev_builtins=>divide(EXPORTING im_arg1 = lv_arg1
 im_arg2 = lv_arg2
 IMPORTING ex_result = lv_result).
 CATCH cx_foev_error_in_function INTO lr_oref.
 ENDTRY.
 wd_this->attribute_set(EXPORTING p_result = lv_result).
 ENDMETHOD.

As we can see, to read the context attributes ATR1 and ATR2, we use the user defined method named ATTRIBUTE_GET that has two exporting parameters.

To pass the result of the division calculation into the context attribute RESULT, we have used the user defined method ATTRIBUTE_SET that has an importing parameter

User defined method required to read the context attributes

User defined method required to populate the RESULT attribute

Runtime for the Divide operation

To rise to power a number (number1 risen to number2), the Framework triggers the event handler method onactionpower (Listing).

 METHOD onactionpower.
 …………..
 TRY.
 cl_foev_builtins=power(EXPORTING im_arg1 =
 lv_arg1 im_arg2 = lv_arg2   IMPORTING ex_result = lv_result).
 CATCH cx_foev_error_in_function INTO lr_oref.
 ENDTRY.
 ENDMETHOD.

We have used the static method POWER, of the calculation class CL_FOEV_BUILTINS, to perform the number1 risen to number2 operation.To read the context attributes ATR1 and ATR2, we call the same user defined method ATTRIBUTE_ GET; to pass the calculation result, we call the method ATTRIBUTE_SET. In this example, we have caught errors that can occur, but we didn’t display their message to the user. The way we can use try. . . endtry, the way we can raise, catch and display exceptions will be detailed described.

Dynamic Programming

RUNTIME CLASS: CL_WD_BUTTON_CHOICE

Hereunder,we present a table showing the correspondence between the view designer name and the runtime name, with the proper types,in case of dynamic programming of a ButtonChoice UI element.

Dynamic programming

The implementation of a dynamic ButtonChoice UI element with one mean action item, named DIVIDE, contains the following statements:

 METHOD wddomodifyview.
 DATA lr_button_choice TYPE REF TO cl_wd_button_choice.
 DATA lr_flow_data TYPE REF TO cl_wd_flow_data.
 DATA lr_container TYPE REF TO cl_wd_uielement_container.
 DATA lr_menu_action TYPE REF TO cl_wd_menu_action_item.
 IF first_time EQ abap_true.
 lr_container ?= view->get_element('ROOTUIELEMENTCONTAINER').
 lr_button_choice = cl_wd_button_choice=>
 new_button_choice( id = 'BTN_CHOICE'
 text = 'Choose'
 repeat_selected_action = abap_false
 ).
 lr_flow_data = cl_wd_flow_data=>new_flow_data(element =
 lr_button_choice).
 lr_container->add_child(lr_button_choice).
 lr_menu_action = cl_wd_menu_action_item=>new_menu_action_item
(id ='MENUACTIONITEM1'
 text = 'Divide'
 on_action = 'DIVIDE'
 hotkey = cl_wd_menu_action_item=>e_hotkey-ctrl_p
 ).
 lr_button_choice->add_choice(the_choice = lr_menu_action).
 ENDIF.
 ENDMETHOD.

Selection

This category contains UI elements that have selection options. Hereunder,we present some of the UI Elements included in this category.

Drop Down By Key

This UI element provides the end user with a dropdown list from where he can choose only one entry. We create a WD Component named Y_UI_DROPDOWNBYKEY with a view named V_VIEW and a window.

We have many possibilities to populate with values the dropdown list.For example,we can use a Domain defined in the ABAP Dictionary, we can use the wdDoInit Hook method or a supply function method. For our example, we use Y_COUNTRY_DOMAIN, domain that holds all the names of EU member states.

The View layout is presented in fig

As we have mentioned above, most of the UI element properties can be bound. Hereunder, we present a table with some of the DropDownByKey properties that can be bound, and the attribute type in case the property is bindable.

Some of the DropDownByKey UI element properties

The property selectedKey is mandatory; this means we have to realise data binding at this attribute. The context structure is presented.

Context structure

We have a context node with the cardinality 1. . .1 Singleton that has two attributes. The KEY attribute is of Y_DEFORDOMAIN type,defined in the ABAP Dictionary, and the RESULT attribute is of string type. We define a data binding between the KEY attribute and the selectedKey property of the DropDownByKey.

Data binding

If the selectedKey property of the DropDownByKey UI Element is bound to this attribute,the values stored in the attribute KEY are displayed in the selection list.

We use the attribute RESULT to show, in the textView UI Element,the capital of the first two EU countries,from the dropdown list. After the user chooses a value,the Framework triggers the event handler method onactionselect_country.

the event handler method

 METHOD onactionselect_country.
 DATA lr_node TYPE REF TO if_wd_context_node.
 DATA ls_data TYPE wd_this-element_dropdownbykey.
 DATA lv_value TYPE string.
 lr_node = wd_context-get_child_node('DROPDOWNBYKEY').
 lr_node-get_attribute(EXPORTING name ='KEY'IMPORTING value = lv_value).
 CASE lv_value.
 WHEN 'AT'.
 ls_data-result ='Vienna'.
 WHEN 'BE'.
 ls_data-result ='Brussels'.
 WHEN OTHERS.
 ls_data-result ='Unknown'.
 ENDCASE.
 lr_node-set_static_attributes(ls_data).
 ENDMETHOD.

Runtime

Dynamic Programming

RUNTIME CLASS: CL_WD_DROPDOWN_BY_KEY

Hereunder,we present a table showing the correspondence between the view designer name and the runtime name, with the proper types,in case of dynamic programming of a DropDownByKey UI element.

Dynamic programming

The implementation of a dynamic DropDownByKey UI element contains the following statements.

Dynamic creation of a Drop Down By Key UI element

 DATA lr_dropdown_by_key TYPE REF TO cl_wd_dropdown_by_key.
 DATA lv_bind_attribute TYPE string.
 lv_bind_attribute = 'DROPDOWNBYKEY.KEY'.
 lr_dropdown_by_key =cl_wd_dropdown_by_key=
 new_dropdown_by_key(id ='DDK'bind_selected_key =
 lv_bind_attribute text_direction = 
cl_wd_dropdown_by_key=e_text_direction-ltr on_select = 'SELECT_COUNTRY').

Drop Down By Index

This UI element provides the end user with a dropdown list from where he can choose only one entry. This UI element doesn’t differ from the DropDownByKey when displayed on the screen, the implementation being the only difference. We create the same WD Component; in this case, we use a dropDownByIndex UI element instead of the dropDownByKey.In Fig. we show the context structure.In this case, we use a context node with the dictionary structure SHSVALSTR2, cardinality 0...n, Singleton.

Context structure

View Layout

Here under,we present a table with some of the DropDownByIndex properties that can be bound,and the attribute type in case the property is bindable.

Some of DropDownByIndex UI element properties

As we can see,the texts property is mandatory. If this property of the drop- DownByIndex UI Element is bound to the VALUE attribute, the values stored in this attribute are displayed in the selection list. Listing shows how we can populate the dropdown list with values via a supply function method.

Supply function method

 METHOD supply_dropdownbyindex.
 DATA:
 ls_country TYPE if_v_view=element_dropdownbyindex,
 lt_country LIKE TABLE OF ls_country.
 ls_country-value ='Austria'.
 ls_country-key ='Vienna'.
 APPEND ls_country TO lt_country.
 ls_country-value ='Belgium'.
 ls_country-key ='Brussels'.
 APPEND ls_country TO lt_country.
 node-bind_table(new_items = lt_country set_initial_elements = abap_true).
 ENDMETHOD.

Runtime

Dynamic Programming

RUNTIME CLASS: CL_WD_DROPDOWN_BY_IDX

Hereunder,we present a table showing the correspondence between the view designer name and the runtime name,with the proper types,in case of dynamic programming of a DropDownByIndex UI element.

Dynamic programming

The implementation of a dynamic DropDownByIndex UI element

 DATA lr_dropdown_by_index TYPE REF TO cl_wd_dropdown_by_idx.
 DATA lv_bind_attribute TYPE string.
 lv_bind_attribute ='DROPDOWNBYINDEX.VALUE'.
 lr_dropdown_by_index = cl_wd_dropdown_by_idx=new_dropdown_by_idx
(id = 'DDI'bind_texts = lv_bind_attribute text_direction = cl_wd.

Radio Button Group By Index

This UI Element includes some RadioButtons,allowing the user to select only one value. Similar to the DropDown lists,we have here RadioButtons grouped by key and by index. Indifferent of the type,they don’t differ when they are displayed on the screen,but only in the implementation part.

We create the same WD Component as for the DropDownByIndex UI element;in this case,we change the DropDownByIndex UI element withthe RadioButton- GroupByIndex.The view context has the same structure. We create a context node named RADIOBUTTONGROUP_I with the dictionary structure SHSVALSTR2, cardinality 0. . .n, Singleton.

Hereunder, we present a table with some of the RadioButtonGroupByIndex properties that can be bound, and the attribute type in case the property is bindable.

Some of the RadioButtonGroupByIndex UI element properties

View Layout

We define the same data binding between the VALUE attribute and the texts property of the RadioButtonGroupByIndex. If this property of the RadioButton- GroupByIndex UI Element is bound to the VALUE attribute, the values stored in this attribute are displayed in columns and rows.

To specify the number of columns in which the RadioButtonGroup elements are grouped, we can use the property colCount. In our case, we have set “2”.This property can be personalised by an administrator.Listing shows how we can populate the RadioButtons with values via a supply function method (the same method as for the DropDownByIndex lists).

Supply function method

 METHOD supply_radiobutton_i.
 DATA:
 ls_country TYPE wd_this-element_radiobuttongroup_i,
 lt_country LIKE TABLE OF ls_country.
 ls_country-value = 'Austria'.
 ls_country-key = 'Vienna'.
 APPEND ls_country TO lt_country.
 ls_country-value = 'Belgium'.
 ls_country-key = 'Brussels'.
 APPEND ls_country TO lt_country.
 node-bind_table( new_items = lt_country set_initial_elements = abap_true).
 ENDMETHOD.

Runtime

For the RadioButtonGroupByKey UI element, we have the same concept as described for the DropDownByKey.

Dynamic Programming

RUNTIME CLASS: CL_WD_RADIOBUTTON_GROUP_BY_IDX

Hereunder, we present a table showing the correspondence between the view designer name and the runtime name, with the proper types,in case of dynamic programming of a RadioButtonGroupByIndex UI element.

Dynamic programming

The implementation of a dynamic RadioButtonGroupByIndex UI element contains the following statements:

Dynamic creation of a RadioButtonGroupByIndex UI element

 DATA lr_radiobutton_group_by_index TYPE REF TO
 cl_wd_radiobutton_group_by_idx.
 DATA lv_bind_attribute TYPE string.
 lv_bind_attribute ='RADIOBUTTONGROUP_I.VALUE'.
 lr_radiobutton_group_by_index =
 cl_wd_radiobutton_group_by_idx=>new_radiobutton_group_by_idx(
 id = 'RDB_INDEX'
 bind_texts = lv_bind_attribute
 col_count = 2
 on_select = 'SHOW’).

Layout

This category has UI elements we use to form the layout. Hereunder,we present some of the UI Elements included in this category.

ViewContainerUIElement

This UI element is an area within a view that contains another view. It doesn’t have its own properties,but inherits properties from the abstract base class UIElement. We create a WD Component,a registration form with three views.In the view V_VIEW,we insert two ViewContainerUIElement’s (VCU_1 and VCU_2) required to embed the V_STEP1 and V_STEP2 views. The context node is created in COMPONENTCONTROLLER because we have to share data among different view controllers: V_STEP1, V_STEP2, V_VIEW.

WD component structure

Context structure

The node INFO has the cardinality 0...1, Singleton. The attributes NAME, EMAIL, CITY are of STRING type, and the attribute COUNTRY is of Y_DEFORDOMAIN type defined in the ABAP Dictionary, domain that holds all the EU member states.

At runtime, the view V_VIEW is the default view (e.g. the view that is first displayed when the window is called).

View V_VIEW layout

Because we want to display more views in the same time and in the same window,we are going to use ViewContainerUIElement. At runtime,when the screen is displayed for the first time, we want only the fields from V_VIEW view to be visible until the user presses the LinkToAction UI Element. This is the reason why we embed as default in VCU_1 and VCU_2 EMPTYVIEWs.An EMPTYVIEW is a special type of view, automatically generated, that can be used to hide another view.

Window structure

Runtime

As we can see, only the UI Elements from the default view V_VIEW are displayed, because the VCU_1 and VCU_2 have EMPTYVIEWs as default.

Embedding Views in Window

After the user presses the LinkToAction UI element, we want to show in the VCU_1 the view V_STEP1. To be able to do this, we define an outbound plug in the V_VIEW view.

Definition of an outbound plug in the view V_VIEW

V_STEP1 view layout

To be able to show the view V_STEP1 content when the user presses the LinkToAction UI Element, we have to define an inbound plug in the view V_STEP1.

Definition of an Inbound Plug in the view V_STEP1

Now,we embed the view V_STEP1 in the ViewContainerUIElement VCU_1 and we create the navigation link.

Window structure

When the user presses the LinkToAction UI element, the Framework triggers the event handler method onactionlta1. When we create an outbound plug for a view,a fire method is added to its interface. A fire method of our outbound plug op_to_v_ step1 is called with the statement:

wd_this!fire_op_to_v_step1_plg( ).

We have created a navigation link from OP_TO_V_STEP1 to IP_V_STEP1. When this method is fired, the view V_STEP1 is displayed. To integrate the fire method, we can use the Web Dynpro Code Wizard.

Calling the web Dynpro code wizard

2012-09-22T23:02:00.007-07:00

User Interface Elements (UI elements) Static and Dynamic Programming-part 2

Calling the web Dynpro code wizard

Runtime

Hereunder,we have to display the view V_STEP2 when the user presses the LinkToAction UI element (ID = LTA_NEXT2). To do this, we define an outbound plug named OP_TO_V_STEP2 in the view V_STEP1,and we fire the generated method.

Outbound plug, event handler method

V_STEP2 view layout

After this, we have to define an inbound plug named IP_V_STEP2, we embed the view V_STEP2 into the ViewContainerUIElement VCU_2 and we create the corresponding navigation link.

Window structure

Dynamic Programming

RUNTIME CLASS: CL_WD_VIEW_CONTAINER_UIELEMENT

The implementation of a dynamic ViewContainerUIElement contains the following statements (Listing):

data lr_vcu type ref to cl_wd_view_container_uielement.
lr_vcu = cl_wd_view_container_uielement=>new_view_container_uielement (id = 'VCU').

In this case, after dynamically creating the View ContainerUI Element,we have to dynamically create the view embedding and the navigation links.

tabStrip

This UI element allows us to display some tabs, and the user can toggle from a tab page to another. We create a WD Component.

WD component structure

We create a TabStrip UI element and add two Tabs. To add tabs, we right-click on the tabStrip name and, from the contextual menu, we choose Insert Tab.When the user presses the Next button, we navigate to the next tab and we show the data entered by the user in the registration form of the first tab.

View layout

Hereunder, we present a table with some of the tabStrip UI element properties that can be bound,and the attribute type in case the property is bindable.

Some of TabStrip UI element properties

The property selectedTab of string type can be used to navigate from a tab to other one. This property set the name of the selected tab. We define a data binding between the selectedTab property and the attribute with the same name (string) defined in the node DYNAMIC in the view context.The node STUDENT has the dictionary structure YSTR_PERSON,cardinality 0...1,Singleton.

Context structure

By using the wdDoInit Hook method, we populate the attribute SELECTEDTAB of the node DYNAMIC with the ID of the tab we want to be active at runtime–TAB_1 (Listing ).

Listing The wddoinit Hook method

 METHOD wddoinit.
 DATA lr_node TYPE REF TO if_wd_context_node.
 DATA ls_data TYPE wd_this->element_dynamic.
 lr_node = wd_context-get_child_node('DYNAMIC').
 ls_data-selectedtab = 'TAB_1'.
 lr_node-set_static_attributes(ls_data).
 ENDMETHOD.

When the user presses the Next Button,the Framework triggers the event handler method onactionnext (Listing).We set the selectedtab property with the value TAB_2,by selecting in this mode the TAB_2.

Listing Event handler methodMETHOD onactionnext.

 DATA lr_node TYPE REF TO if_wd_context_node.
 DATA ls_data TYPE wd_this-element_dynamic.
 lr_node = wd_context-get_child_node('DYNAMIC').
 ls_data-selectedtab = 'TAB_2'.
 lr_node-set_static_attributes(ls_data).
 ENDMETHOD.

Runtime

Dynamic Programming

RUNTIME CLASS: CL_WD_TABSTRIP

Hereunder,we present a table showing the correspondence between the view designer name and the runtime name,with the proper types,in case of dynamic programming of a TabStrip UI element.For the tabStrip UI element we have, as aggregation, the Tab element.Its runtime class is CL_WD_TAB.

Dynamic programming

The implementation of a dynamic TabStrip UI element, with two Tabs,contains the following statements (Listing):

Dynamic programming of a TabStrip UI element

 METHOD wddomodifyview.
 DATAlr_pageheader TYPE REF TO cl_wd_page_header.
 DATAlr_flow_data TYPE REF TO cl_wd_flow_data.
 DATAlr_container TYPE REF TO cl_wd_uielement_container.
 DATAlr_area TYPE REF TO cl_wd_page_header_area.
 IF first_time EQ abap_true.
 lr_container ?= view->get_element('ROOTUIELEMENTCONTAINER').
 lr_pageheader = cl_wd_page_header=>new_page_header(id = 'PH_PAGEHEADER'
 text_direction = cl_wd_page_header=>e_text_direction-ltr ).
 lr_pageheader->set_title('DYNAMIC PAGEHEADER').
 lr_flow_data = cl_wd_flow_data=>new_flow_data(element =
 lr_pageheader). 
  lr_container->add_child(lr_pageheader). 
 lr_area = cl_wd_page_header_area=>new_page_header_area(id ='PAGEHEADAREA'
 design = cl_wd_page_header_area=>e_design-emphasized).
  DATA lr_textview TYPE REF TO cl_wd_text_view.
 lr_textview = cl_wd_text_view=>new_text_view(id = 'TXT'
 text ='PageHeaderArea'
 ).
 lr_area->set_content(the_content = lr_textview ).
 lr_pageheader->add_area(the_area = lr_area ).
 ENDIF.
 ENDMETHOD.
PageHeader

This UI element offers the possibility to create a header for a page.In the title content and the PageHeader Area, we can insert other UI elements. We create a WD component with the structure presented in Fig.

WD component structure

We use the view V_VIEW as Master View. Here, we insert a PageHeader UI element that contains two LinkToAction UI elements, and in the PageHeader Area we insert a ViewContainerUIElement. When the user interacts with the LinkToAction UI elements,we show in the ViewContainerUIElement one of the two slave views V_COUNTRYor V_CANDIDATE.

Application structure

After the PageHeader UI element is inserted into the V_VIEW view,we can insert a PageHeader Title Content and one or more PageHeader Area(s).

Inserting the title content and PageHeader area

In a PageHeaderArea, we can insert how many other UI elements we want.Here, we have chosen to insert only one UI element (ViewContainerUIELement).As design options,it has: Standard, Emphasized and transparent.For our example,we have the default design: Standard. To see on screen the other Page Header Area designs,we can choose values from the list, one by one, and see the result in the view designer, or we can run again the application and see the different changes.In the system,we can find two WD components where we can see the UI elements and the effect of changing certain properties on these UI elements. These components are WDR_TEST_EVENTS and WDR_TEST_UI_ELEMENTS.

V_VIEW view layout

Each view (V_CANDIDATE and V_COUNTRY) has a Table UI element where we show the data stored in our database table YPERSON and YEU_COUNTRIES.

Runtime

Dynamic Programming

RUNTIME CLASS: CL_WD_PAGE_HEADER

Hereunder,we present a table showing the correspondence between the view designer name and the runtime name, with the proper types,in case of dynamic programming of a PageHeader UI element.

Dynamic programming

For the PageHeader UI element we have, as aggregation, the Area and the TitleContent elements. The Area runtime class is CL_WD_PAGE_HEADER_ AREA.

The implementation of a dynamic PageHeader UI element (with pageHeader title) and a PageHeaderArea (with a textView UI element) contains the following statements (Listing):

Dynamic programming of a PageHeader UI element

 METHOD wddomodifyview.
 DATA lr_pageheader TYPE REF TO cl_wd_page_header.
 DATA lr_flow_data TYPE REF TO cl_wd_flow_data.
 DATA lr_container TYPE REF TO cl_wd_uielement_container.
 DATA lr_area TYPE REF TO cl_wd_page_header_area.
 IF first_time EQ abap_true.
 lr_container ?= view->get_element('ROOTUIELEMENTCONTAINER').
 lr_pageheader = cl_wd_page_header=>new_page_header(
 id = 'PH_PAGEHEADER'
 text_direction = cl_wd_page_header=>e_text_direction-ltr
 ).
 lr_pageheader->set_title('DYNAMIC PAGEHEADER').
 lr_flow_data = cl_wd_flow_data=>new_flow_data(element =
 lr_pageheader).
 lr_container->add_child(lr_pageheader).
 lr_area = cl_wd_page_header_area=>new_page_header_area(
 id = 'PAGEHEADAREA'
 design = cl_wd_page_header_area=>e_design-emphasized
 ).
 DATA lr_textview TYPE REF TO cl_wd_text_view.
 lr_textview = cl_wd_text_view=>new_text_view(
 id = 'TXT'
 text = 'PageHeaderArea'
 ).
 lr_area->set_content(the_content = lr_textview).
 lr_pageheader->add_area(the_area = lr_area).
 ENDIF.
 ENDMETHOD.

ContextualPanel

This UI element offers navigation functions. Its navigation list can have many levels.We create the same example as for the PageHeader,but, in this case,we use the two LinkTo Action UIElements to create the content for a ContextualPanel UI element.

In a contextualPanel UI element, we can insert three types of elements: Free- ContextualArea,NavigationList and ViewSwitch. In our example,we have used two FreeContextualArea elements.

In a FreeContextualArea, we can insert a Content and a Header. We can set the header to be expandable or no. The Content is a zone where we can insert other UI elements we want to be displayed within the FreeContextualArea.

FreeContexualArea

V_VIEW view Layout

Dynamic Programming

RUNTIME CLASS: CL_WD_CONTEXTUAL_PANEL

For the ContextualPanel UI element, we have, as aggregation, the items: Free- ContextualArea,
ViewSwitch and NavigationList elements.
The FreeContextual- Area runtime class is
CL_WD_FREE_CONTEXTUAL_AREA.

The implementation of a dynamic contextualPanel UI element,with a Free- ContextualArea element that has a Content(linkToAction UI element)and a Header(expandableTitle element),contains the following statements (Listing ):

Dynamic programming of a contextualPanel UI element

 METHOD wddomodifyview.
 DATA lr_flow_data TYPE REF TO cl_wd_flow_data.
 DATA lr_container TYPE REF TO cl_wd_uielement_container.
 DATA lr_contextualpanel TYPE REF TO cl_wd_contextual_panel.
 DATA lr_freecontextualarea TYPE REF TO cl_wd_free_contextual_area.
 DATA lr_linktoaction TYPE REF TO cl_wd_link_to_action.
 DATA lr_header TYPE REF TO cl_wd_expandable_title.
 IF first_time EQ abap_true.
 lr_container ?= view->get_element('ROOTUIELEMENTCONTAINER').
 lr_contextualpanel = cl_wd_contextual_panel=&g new_contextual_panel(
 id = 'CP_CONTEXTUALPANEL'
 ).
 lr_freecontextualarea = cl_wd_free_contextual_area=>new_free_contextual_ar
 ea(
 id = 'FREECONTEXTUALAREA_1'
 ).
 lr_flow_data = cl_wd_flow_data=>new_flow_data(element =
 lr_contextualpanel).
 lr_container->add_child(lr_contextualpanel).
 lr_linktoaction = cl_wd_link_to_action=>new_link_to_action(
 id = 'CONTENT_1'
 on_action ='SHOW_COUNTRIES'
 text ='Show EU countries'
 ).
 lr_freecontextualarea->set_content(the_content = lr_linktoaction).
 lr_header = cl_wd_expandable_title=>new_expandable_title(
 id ='EXPANDABLETITLE_1'
 expandable = abap_true
 expanded = abap_true
 title ='COUNTRY'
 ).
 lr_freecontextualarea->set_header(the_header = lr_header).
 lr_contextualpanel->add_item(the_item = lr_freecontextualarea).
 ENDIF.

Tray UI Element

As all the containers, this UI element includes a set of other UI Elements,but also provides additional functions. We create a WD Component with the structure presented.

WD component structure

In the View Layout,we insert two Tray UI elements. The first element is used to show the candidate information, and the second Tray is used to show some details about the selected candidate. These details are: the country flag and the capital.In the MIMEs folder we import three pictures with the flags we have to display when the user chooses a competitor from that country.

After the Tray UI element is inserted in the View Layout, we can insert a Menu and, in each menu, we can insert a menu option.

Tray menu

The menu options are: Menu, MenuActionItem,MenuCheckBox, MenuRadio- Button and MenuSeparator. In our case,we have chosen the option MenuAction- Item.

Creating a menu element

View layout structure

The first Tray has two menu options, used to show the second Tray UI element or to hide it. As we have mentioned above, most of the UI element properties can be bound. Hereunder, we show a list with some of the Tray UI elements properties that can be bound, and the attribute type in case the property is bindable.

Some of the tray UI element properties

We want to manipulate the UI element via the data held in the context. Therefore, we create a context node named DYNAMIC, with three attributes: two attributes of WDY_BOOLEAN type (ENABLED_OPTION1,ENABLED_OPTION2) and one attribute named VISIBLE, of WDUI_VISIBILITY type.To show the concurrent information and the corresponding details, we have created a context node with the dictionary structure YVIEW_CMPETITION, a database view defined in the ABAP Dictionary.

Context structure.

The context node DETAIL is populated via the supply function method SUPPLY_COMPETITION (Listing).

Supply function method

 METHOD supply_competition.
 DATA: lt_content TYPE TABLE OF yview_cmpetition.
 SELECT * FROM yview_cmpetition INTO TABLE lt_content.
 IF sy-subrc = 0.
 node->bind_table(new_items = lt_content).
 ENDIF.
 ENDMETHOD.

To be able to manipulate the enabled properties of the menu options created in the first Tray UI elements, we define the following data binding:

Data binding

To be able to manipulate the visible property of the second Tray with the ID “TRAY_DETAIL”,we define a data binding between these properties and the context attribute VISIBLE:

At initialisation, we want the second Tray to be hidden, the MENU_OPTION1 to be enabled and the MENU_OPTION2 to be not enabled. To realise this,we encode the wdDoInit Hook method (Listing).

The wddoinit Hook method

 METHOD wddoinit.
 DATA lr_node TYPE REF TO if_wd_context_node.
 DATA ls_data TYPE wd_this-element_dynamic.
 lr_node = wd_context-get_child_node('DYNAMIC').
 ls_data-enabled_option1 = abap_true.
 ls_data-enabled_option2 = abap_false.
 ls_data-visible = cl_wd_tray=e_visible-none.
 lr_node-set_static_attributes( ls_data ).
 ENDMETHOD.

When the user selects the first menu option “MENU_OPTION1”,the Framework triggers the event handler method onactionshow (Listing ).

The onactionshow event handler method

 METHOD onactionshow.
 DATA lr_node TYPE REF TO if_wd_context_node.
 DATA ls_data TYPE wd_this-element_dynamic.
 lr_node = wd_context-get_child_node('DYNAMIC').
 ls_data-enabled_option1 = abap_false.
 ls_data-enabled_option2 = abap_true.
 ls_data-visible = cl_wd_tray=e_visible-visible.
 lr_node-set_static_attributes(ls_data).
 ENDMETHOD.

When the user selects the second menu option MENListingU_OPTION2,the Framework triggers the event handler method onactionhide (Listing).

The onactionhide event handler method

 METHOD onactionhide.
 DATA lr_node TYPE REF TO if_wd_context_node.
 DATA ls_data TYPE wd_this-element_dynamic.
 lr_node = wd_context->get_child_node('DYNAMIC').
 ls_data-enabled_option1 = abap_true.
 ls_data-enabled_option2 = abap_false.
 ls_data-visible = cl_wd_tray=e_visible-none.
 lr_node->set_static_attributes(ls_data).
 ENDMETHOD.

At runtime,we can choose to show or to hide the details about the competitor

Runtime.

Message Area

This UI element represents the placeholder of the messages; it helps us to specify where they appear in the view. As we have seen, the messages are displayed by default in the upper part of the screen. The message location can be moved by adding a MessageArea UI element. We need only a MessageArea UI element per View layout.

We create an example to filter an input from the end user. In case the user enters a combination of small and capital letters from A to Z or spaces,we show a message with the text “Your input is string” If not, we show a message “Your input is not string”. To show these messages,we use a MessageArea UI element.

There are small programs used to test the regexes, which offer the possibility to test the regexes created before using them. Such a program is demo_ regex_toy. By using the transaction SA38 or SE38, we can run this program (Fig.) By using regexes,we can filter the values that the user enters in a Web Dynpro screen.

Regex toy screen

View Layout

As we can see, in this case we have entered a MessageArea UI element in the Group container.This is the place where all the messages will be displayed. When the user presses the button with the id “BTN”,the Framework triggers the event handler method onactioncheck (Listing ).

Checking the data entered by the user methode

 METHOD onactioncheck.
 DATA: lv_firstname TYPE string,
 lv_pattern TYPE string.
 wd_context->get_attribute(EXPORTING name ='FIRSTNAME'
 IMPORTING value = lv_firstname).
 v_pattern ='[a-zA-Zs]*'.
 CHECK lv_firstname IS NOT INITIAL.
 DATA: lr_api_controller TYPE REF TO if_wd_controller,
 lr_message_manager TYPE REF TO if_wd_message_manager.
 lr_api_controller ?= wd_this->wd_get_api( ).
 lr_message_manager = lr_api_controller->get_message_manager( ).
 DATA: lt_message_parameters TYPE wdr_name_value_list,
 ls_message_parameter LIKE LINE OF lt_message_parameters.
 ls_message_parameter-name = 'first_name'.
 ls_message_parameter-value = lv_firstname.
 APPEND ls_message_parameter TO lt_message_parameters.
 F cl_abap_matcher=>matches(pattern = lv_pattern
 text = lv_firstname) = abap_true.
 lr_message_manager->
 report_message(message_text ='Your input &first_name is string'
 message_type = 0
 params = lt_message_parameters).
 ELSE.
 lr_message_manager->
 report_message(message_text ='Your input &first_name is not string!'
 message_type = 2
 params = lt_message_parameters).
 endif.
 ENDMETHOD.

By using the static method MATCHES of the CL_ABAP_MATCHER class,we check the value that the user enters in the inputField UI element.In case this value matches our condition specified in the local variable lv_pattern,we use the methode REPORT_MESSAGE to display a message of information type. Otherwise,we use the same method to display an error message. Because we want to show to the user whether the value he entered in the input field is a string or not,we use a parameter required to integrate,in the string that he sees on the screen,the value he has just entered.For this purpose, we have used for the method report_message a parameter named “params”.By double-clicking on name of the method report_message,we navigate forward and we can see all the parameters that this method has and the typethat the parameters should be. For the “parms” parameter, we need a variable owdr_name_value_list type that is actually a table type with a structure of line type.From this structure, we have used the name(the parameter name,in our case “first_name”)and the value (the value with what we want to replace,at runtime,the parameter name “lv_firstname”).In Chap. 10, we will see more abou the message manager and parameters, along with the modality we can display a message into a window, or the modality we can use the ABAP classesto create messages and exceptions. In Fig.the messages are displayed by using the MesageArea UI element.

Runtime with MessageArea UI element

Dynamic Programming

RUNTIME CLASS: CL_WD_MESSAGE_AREA

Hereunder,we present a table showing the correspondence between the view designer name and the runtime name,with the proper types,in case of dynamic programming of a MessageArea UI element (Table).

The implementation of a dynamic MessageArea UI element contains the following statements (Listing ):

Dynamic programming

The dynamic programming of a MessageArea UI element

 data lr_messagearea type ref to cl_wd_message_area.
 lr_messagearea = cl_wd_message_area=>new_message_area(
 id ='MESSAGE_AREA'
 HISTORY_VISIBLE = abap_true).

Complex

This category contains complex UI elements as regards their structure and content.Hereunder,we present some of the UI Elements included in this category.

Table

By using this UI element, we can display data arranged in rows and columns.Table shows some of the Table properties that can be bound,and the attribute type in case the property is bindable.

Some of the Table UI element properties

In this exercise,we want to take data from an end user and to insert them into a table UI element,after the latest record. To do this,we create a WD component named Y_UI_TABLE that has a View named V_VIEW and a default window.In the context view,we need two context nodes: a context node required to hold the new record from the end user and a context node required to hold all the records.

Context structure

The context node REGISTRATION has the cardinality 1. . .1, Singleton.Its attributes are: NAME of STRING type,DATE OF BIRTH of YDATEOFBIRTH type,COUNTRY of Y_DEFORDOMAIN type and NO of I type. We use the attributes of this context node to hold every new record.

The context node TABLE has the cardinality 0...n,Singleton, selection 0...1, supply function SUPPLY_PERSON and initialization lead selection is not automatically set. In this case,we want to manually set the lead selection. The context node attributes have the same name and data type as the context node REGISTRATION.We use the attributes of this context node to hold all the registrations.

In the next step,we have to create the view layout.To insert a Table into our view layout,we can use two options: we can manually insert the table or we can use the Web Dynpro Wizard. In the beginning, we explain the first option. After inserting a Table UI element into our view,we have to create a data binding.When a table is bound to a context node by using a wizard,we don’tneed to individually create each table column. We have only to select the context node and the Framework provides the available attributes.In this way,the value of the property DataSource (mandatory) of the Table UI element is bound to the context node TABLE.

Table UI element – Creating the binding

The Cell Editors of the Table Column describe the UI element used to display or edit the column content.As we can see,our columns are created by using textView UI elements. Each attribute represents a column in our table, and for each column we can choose an UI element. After this, the standard property to be bound depends on the chosen UI element.For example, for the TextView UI element, the property is text, and for the DropDownByKey, the name of the property to be bound is selectedKey.

Cell Editor of Table Column – Name of Property to be bound

The view layout is presented in Fig. For each attribute for which the bind option is marked, the Framework generates a proper column. For example, for the attribute “NO”,the Framework has generated the column TBL_EXAMPLE_NO, for the attribute NAME, the Framework has generated the column TBL_EXAPLE_NAME,etc.The Table UI element offers the possibility to display as many rows as we need by using the property visibleRowCount (in our case, five). In the default mode,the property displayEmptyRows is set as ABAP_TRUE. In case we set this property as ABAP_FALSE, the rows that are empty in our table will not be on screen anymore.

The second option to insert a Table UI element into our View Layout is to use the Web Dynpro Wizard (Fig). In this case,the Wizard generates the Table UI element and we use the same procedure presented hereunder to create the data binding. After the user enters the new values (Name, Date of Birth and Country),we have to add these values at the end of the other records, in the table UI element. To be able to do this, we need an action. Fig Cell Editor of Table Column – Name of Property to be bounding.

After the user enters the new values (Name, Date of Birth and Country),we have to add these values at the end of the other records,in the table UI element. To be able to do this, we need an action.

View layout

Web Dynpro wizard to insert a Table UI element into the view layout

For a table UI element, we can insert a Toolbar. We need a toolbar to be able to insert a ToolBarButton in this area. We populate the node TABLE with two values, via the supply function method.

The local variable lv_counter is used to create the record ID. After the node population, we use the SET_LEAD_SELECTION_INDEX method to set lead selection via index. As we can see, the index is set with the value of the lv_counter. In this way,it is selected the last value of the table.

Inserting a ToolBarButton

Supply function method

 METHOD supply_person.
 DATA:
 ls_table TYPE wd_this-element_table,
 lt_table LIKE TABLE OF ls_table,
 lv_counter TYPE i VALUE 1.
 ls_table-no = lv_counter.
 ls_table-name = 'Antonia Maria Crist'.
 ls_table-dateofbirth = '19800305'.
 ls_table-country = 'DE'.
 lv_counter = lv_counter + 1.
 APPEND ls_table TO lt_table.
 ls_table-no = lv_counter.
 ls_table-name = 'Albu Alina'.
 ls_table-dateofbirth = '19800908'.
 ls_table-country = 'IT'.
 APPEND ls_table TO lt_table.
 node->bind_table(new_items=lt_table set_initial_elements = abap_true).
 node-set_lead_selection_index(index=lv_counter).
 ENDMETHOD.

As we have mentioned above, if the “Initialization lead selection” for a node is “YES”, it is always selected the first element of this node. In this case, our context node has this property selected “NO”; we influence the selected element by using the set_lead_selection_index.

To influence the lead selection, we have some methods, as following

Set_lead_selectio
Move_first
Move_previous
Move_

For our TABLE context node, we have set the selection cardinality 0...1 meaning that maximum one row can be selected if the node elements are displayed as a table. When the user presses the “Add record” button,the Framework triggers the event handler method onactionadd.

Event handler method

 METHOD onactionadd.
 DATA: lr_node TYPE REF TO if_wd_context_node,
 lr_node1 TYPE REF TO if_wd_context_node,
 lr_element TYPE REF TO if_wd_context_element,
 lv_counter TYPE i,
 lv_dateofbirth TYPE ydateofbirth,
 lv_country TYPE y_defordomain,
 lv_name TYPE string,
 ls_registration TYPE wd_this->element_registration.
 lr_node = wd_context->get_child_node('REGISTRATION').
 lr_node->get_attribute(EXPORTING name ='DATEOFBIRTH'
 IMPORTING value = lv_dateofbirth).
 lr_node->get_attribute(EXPORTING name ='NAME'
 IMPORTING value = lv_name).
 lr_node->get_attribute(EXPORTING name ='COUNTRY'
 IMPORTING value = lv_country).
 lr_node1 = wd_context->get_child_node('TABLE').
 lr_node1->get_attribute(EXPORTING name ='NO'
 IMPORTING value = lv_counter).
 lv_counter = lv_counter + 1.
 ls_registration-no = lv_counter.
 ls_registration-dateofbirth = lv_dateofbirth.
 ls_registration-name = lv_name.
 ls_registration-country = lv_country.
 lr_node->set_static_attributes(ls_registration).
 lr_element = lr_node->get_lead_selection( ).
 lr_element->
 get_static_attributes( IMPORTING static_attributes = ls_registration ).
 lr_node1 = wd_context->get_child_node('TABLE').
 lr_node1->bind_structure( EXPORTING new_item = ls_registration
 set_initial_elements = abap_false).
 lr_node1->set_lead_selection_index(index = lv_counter).
 ENDMETHOD.

We pass the value of the attribute NO of the TABLE context node in the local variable lv_counter. As we have mentioned above,we use this local variable to create the record ID.After each new record,we increase this value with 1.The user enters the values Name,Date of Birth and Country and we create his corresponding ID.The runtime structure is presented.

Runtime

Additionally,we can add a reset Button on the table toolbar. After the user adds the records, he can reset the fields Name, Date of birth and Country, to be able to add a new record. The “Reset” Toolbar Button,of the same ToolBarButton type, has associated an action named RESET. The Listing shows the onactionreset event handler method.

The onactionreset event handler method

 METHOD onactionreset.
 DATA: lr_node TYPE REF TO if_wd_context_node,
 ls_registration TYPE wd_this-element_registration.
 lr_node = wd_context-get_child_node('REGISTRATION').
 lr_node->bind_structure(EXPORTING new_item = ls_registration).
 ENDMETHOD.

Runtime

Dynamic Programming

RUNTIME CLASS: CL_WD_TABLE

Hereunder,we present a table showing the correspondence between the view designer name and the runtime name, with the proper types,in case of dynamic programming of a Table UI element.

Dynamic programming

For the Table UI element,we have, as aggregation, the Table Column,Group Column, Header,Legend Popin, MasterColumn and Toolbar. The TableColumn element represents a column of a table, and has the CL_WD_TABLE_COLUMN runtime class. The table title is implemented by using a Caption element and has the CL_WD_CAPTION runtime class.

The implementation of a dynamic Table UI element with table header,design alternating, three visible rows and a column, that has a TextView UI element as cell editor,contains the following statements.

Dynamic programming of a Table UI element

 METHOD wddomodifyview.
 DATA lr_table TYPE REF TO cl_wd_table.
 DATA lr_flow_data TYPE REF TO cl_wd_flow_data.
 DATA lr_container TYPE REF TO cl_wd_uielement_container.
 DATA lr_column_name TYPE REF TO cl_wd_table_column.
 DATA lr_text_view TYPE REF TO cl_wd_text_view.
 DATA lr_table_header TYPE REF TO cl_wd_caption.
 DATA lr_column_name_header TYPE REF TO cl_wd_caption.
 IF first_time EQ abap_true.
 lr_container ?= view->get_element('ROOTUIELEMENTCONTAINER').
 lr_table = cl_wd_table=>new_table(
 id ='TBL_TABLE'
 bind_data_source ='TABLE'
 design = cl_wd_table=>e_design-alternating
 visible_row_count = 3
 ).
 lr_flow_data = cl_wd_flow_data=>new_flow_data(element =
 lr_table ).
 lr_container->add_child(lr_table).
 lr_column_name = cl_wd_table_column=>new_table_column(
 id = 'TBL_EXAMPLE_NAME'
 ).
 lr_table_header ?= cl_wd_caption=>new_caption(text ='Table UI elem
 ent - example').
 lr_table->add_column(the_column = lr_column_name).
 lr_table->set_header(lr_table_header).
 lr_text_view = cl_wd_text_view=>new_text_view(
 id ='TXV_NAME'
 bind_text ='TABLE.NAME'
 ).
 lr_column_name_header ?= cl_wd_caption=>new_caption(text = 'Nam
 e').
 lr_column_name->
 set_table_cell_editor(the_table_cell_editor = lr_text_view
 ).
 lr_column_name->set_header(lr_column_name_header).
 ENDIF.
 ENDMETHOD.

2012-09-22T23:02:00.005-07:00

User Interface Elements (UI elements) Static and Dynamic Programming-part-3

RoadMap

By using this UI element, we can display the steps required to complete a certain task. Hereunder,we show some of the roadMap properties that can be bound,and the attribute type in case the property is bindable.

For the RoadMap example,we use the exercise from the ViewContainerUIElement,a little bit re-arranged. The WD component structure is presented.

WD component structure

In this case,we replace the LinkToAction UI elements with two Buttons: Next and Back. These Buttons are inserted into the view V_VIEW, and the user can navigate from the first step to the end one, via the RoadMap. In this case, we used only a ViewContainerUIElement,and for each step we have a view. In the view V_VIEW, we insert a RoadMap UI element with three steps. To insert a step into a RoadMap UI Element, we right-click on the element and, from the contextual menu, we choose Insert Step.

RoadMap steps

V_VIEW view layout

T0 be able to manipulate the RoadMap UI element and the Button via the data held in the context, we create, in the V_VIEW, a context node named DYNAMIC. This node has three attributes:

SELECTEDSTEP, of STRING type, used to dynamically set the ID of the selected step
ENABLED_NEXT, of WDY_BOOLEAN type, used to manipulate the enabled property of the NEXT button
ENABLED_BACK,of WDY_BOOLEAN type,used to manipulate the enabled property of the BACK button (Fig – right)

To hold and show the data entered by the user, we have created, in the COM PONENTCONTROLLER context, a node named INFO (Fig. – left).This context node has the same structure as presented in the ViewContainerUIElement example. The attributes are: NAME, EMAIL & CITY (of STRING type) and COUNTRY (of Y_DEFORDOMAIN type). We create a context mapping among this context node and the context views V_STEP1, V_STEP2 and V_STEP3.

Context structure

V_STEP1 view layout

V_STEP2 view layout

V_STEP3 view layout

The view “V_VIEW” is the default view – the firstly displayed one.In the ViewContainerUIElement,we embed all the three views V_STEP1,V_STEP2 and V_STEP3. The view V_STEP1 is, in this case, the default view. To be able to navigate among the views, we have to create inbound and outbound plugs. In the view V_VIEW, we create three outbound plugs:

OP_TO_V_STEP1 required to navigate to the view V_STEP1
OP_TO_V_STEP2 required to navigate to the view V_STEP2
OP_TO_V_STEP3 required to navigate to the view V_STEP3

The view V_STEP1 has an inbound plug named IP_V_STEP1,the view V_STEP2 has an inbound plug named IP_V_STEP2 and the view V_STEP3 has an inbound plug named IP_V_STEP3.

Window structure

In the wdDoInit Hook method (V_VIEW),we dynamically set the attributes values for SELECTEDSTEP, ENABLED_NEXT and ENABLED_BACK.

The wdDoInit Hook method

 METHOD wddoinit.
 DATA lr_node TYPE REF TO if_wd_context_node.
 DATA ls_data TYPE wd_this->element_dynamic.
 lr_node = wd_context-get_child_node('DYNAMIC').
 ls_data-enabled_next = abap_true.
 ls_data-enabled_back = abap_false.
 ls_data-selectedstep ='STEP1'.
 lr_node->set_static_attributes(ls_data).
 ENDMETHOD.

First time when the screen is rendered, we want the BACK Button to be not enabled,the NEXT Button to be enabled, and the STEP1 to be the active RoadMap step.

Runtime

When the user presses the NEXT button, the Framework triggers the event handler method onactionnext.

The onactionnext event handler method

 METHOD onactionnext.
 DATA lr_node TYPE REF TO if_wd_context_node.
 DATA ls_data TYPE wd_this-element_dynamic.
 DATA lv_selectedstep TYPE string.
 lr_node = wd_context-get_child_node('DYNAMIC').
 lr_node-get_attribute
 (EXPORTING name ='SELECTED STEP'IMPORTING value = lv_selectedstep ).
 ASE lv_selectedstep.
 WHEN ‘STEP1’.
 ls_data-selectedstep = ‘STEP2’.
 ls_data-enabled_next = abap_true.
 ls_data-enabled_back = abap_true.
 wd_this-fire_op_to_v_step2_plg( ).
 WHEN ‘STEP2’.
 ls_data-selectedstep = ‘STEP3’.
 ls_data-enabled_next = abap_false.
 ls_data-enabled_back = abap_true.
 wd_this-fire_op_to_v_step3_plg( ).
 WHEN OTHERS.
 ls_data-enabled_next = abap_false.
 ls_data-enabled_back = abap_true.
 ENDCASE.
 lr_node-set_static_attributes(ls_data).
 ENDMETHOD.

As we can see, we make active the STEP2: ls_data-selectedstep = ‘STEP2’,we fire the method that helps us to navigate to the nextview V_STEP2

wd_thisfire_op_to_v_step2_plg( )
and we enable both buttons
ls_data-enabled_next = abap_true.
ls_data-enabled_back = abap_true.

Runtime

When the user presses again the NEXT button,we deactivate the NEXT button ls_data-enabled_next = abap_false we make active STEP3 ls_data-selectedstep = ‘STEP3’and fire the method that helps us to navigate to the view V_STEP3 wd_this!fire_op_to_v_step3_plg( ),

Runtime

When the user presses the BACK button, the Framework triggers the event handler method onactionback.

The onactionback event handler method

 METHOD onactionback.
 DATA lr_node TYPE REF TO if_wd_context_node.
 DATA ls_data TYPE wd_this-element_dynamic.
 DATA lv_selectedstep TYPE string.
 lr_node = wd_context-get_child_node(‘DYNAMIC’).
 lr_node-get_attribute
( EXPORTING name =‘SELECTEDSTEP’IMPORTING value = lv_selectedstep).
 CASE lv_selectedstep.
 WHEN ‘STEP3’.
 ls_data-selectedstep = ‘STEP2’.
 ls_data-enabled_next = abap_true.
 ls_data-enabled_back = abap_true.
 wd_this-fire_op_to_v_step2_plg( ).
 WHEN ‘STEP2’.
 ls_data-selectedstep = ‘STEP1’.
 ls_data-enabled_next = abap_true.
 ls_data-enabled_back = abap_false.
 wd_this->fire_op_to_v_step1_plg( ).
 WHEN OTHERS.
 ls_data-enabled_next = abap_true.
 ls_data-enabled_back = abap_false.
 NDCASE.
 r_node-set_static_attributes(ls_data ).
  ENDMETHOD.

As we can see(Fig.)when the user presses the BACK button,we navigate back to the view V_STEP2

wd_this!fire_op_to_v_step2_plg( ).
we activate both buttons ls_data-enabled_next = abap_true.
ls_data-enabled_back = abap_true.
we make active the step STEP2 ls_data-selectedstep = ‘STEP2’.
wd_this!fire_op_to_v_step2_plg( ).

Runtime

When the user presses again the BACK Button (Fig.),we navigate back to the view V_STEP1

wd_this!fire_op_to_v_step1_plg( ).
we deactivate the BACK button ls_data-enabled_back = abap_false.
and make active the step STEP1 ls_data-selectedstep = ‘STEP1’.

Runtime

Dynamic Programming

RUNTIME CLASS: CL_WD_ROAD_MAP

Hereunder,we present a table showing the correspondence between the view designer name and the runtime name, with the proper types,in case of dynamic programming of a RoadMap UI element.

Dynamic programming

For the RoadMap UI element,we have, as aggregation, the Step: Road Map Step or MultipleRoadMapStep.The RoadMapStep element represents a step in a Road- Map,and has the CL_WD_ROAD_MAP_STEP runtime class.

The implementation of a dynamic RoadMap UI element with two Steps contains the following statements:

Dynamic programming of a RoadMap UI element

 METHOD wddomodifyview.
 DATA lr_container TYPE REF TO cl_wd_uielement_container.
 DATA lr_roadmap TYPE REF TO cl_wd_road_map.
 DATA lr_step1 TYPE REF TO cl_wd_road_map_step.
 DATA lr_step2 TYPE REF TO cl_wd_road_map_step.
 DATA lr_flow_data TYPE REF TO cl_wd_flow_data.
 IF first_time EQ abap_true.
 lr_container ?= view->get_element('ROOTUIELEMENTCONTAINER').
 lr_roadmap = cl_wd_road_map=>new_road_map(
 id = 'RM_ROADMAP'
 bind_selected_step ='DYNAMIC.SELECTEDSTEP'
 start_point_design = cl_wd_road_map=>e_start_point_design-selected
 ).
 lr_flow_data = cl_wd_flow_data=>new_flow_data(element =
 lr_roadmap).
 lr_container->add_child(lr_roadmap).
lr_step1 = cl_wd_road_map_step=>new_road_map_step(
 id = 'STEP1'
 description ='STEP 1'
 name ='1'
 ).
 lr_roadmap->add_step(the_step = lr_step1).
 lr_step2 = cl_wd_road_map_step=>new_road_map_st
 id = 'STEP2'
 description ='STEP 2'
 name ='2'
 ).
 lr_roadmap->add_step(he_step = lr_step2).
 ENDIF.
 ENDMETHOD.

PhaseIndicator

Similar to the Road Map UI element, we can display then the steps in a wizard,by using the PhaseIndicator. Hereunder,we show some of the PhaseIndicator properties that can be bound, and the attribute type in case the property is bindable.

Some of the PhaseIndicator UI element properties

A Phase is a step into a PhaseIndicator that has bindable properties as,for example,enable and status. Table presents some of these properties and how we can use the status property for a dynamic manipulation.

Some of the phase properties and the dynamic manipulation of the status

We create the same example as for the RoadMap, but,in this case,we use a PhaseIndicator UI element with three phases.The WD component structure is presented.

WD component structure

In this case,we have renamed the views V_STEP1, V_STEP2 and V_STEP3 as V_PHASE1,V_PHASE2 and V_PHASE3. The content of these views is the same.We can rename a view by right-clicking on the view name and, from the contextual menu,we choose rename. To insert a phase into a PhaseIndicator UI Element, we right-clickon the element and,from the contextual menu, we choose Insert Phase.

Inserting Phase into a PhaseIndicator

For the first Phase,we have set the status property: completed. For the other two Phases(Phase2 and Phase3),we have dynamically set the status property,by using the two attributes named STATUS2 and STATUS3 of WDUI_PHASE_STATUS type.To manipulate the enabled property of the NEXT button, we use the same attribute ENABLED_NEXT of WDY_BOOLEAN type, and to manipulate the selected phase, we use the attribute SELECTEDPHASE of string type (Fig right).

The node INFO is defined in the COMPONENTCONTROLLER and has the same structure as showed in the previous example. We create context mapping among this context node and the context views V_PHASE1,V_PHASE2 and V_PHASE3.

Context structure

The V_VIEW layout

This view has two outbound plugs defined: OP_TO_V_PHASE2 and OP_TO_V_PHASE3.The view V_PHASE1 has no inbound plug, the view V_PHASE2 has an inbound plug named IP_V_PHASE2 and the view PHASE_3 has an inbound plug named IP_V_PHASE3. The window structure is presented.

Window structure

The view V_PHASE1 is shown in the ViewControllerUIElement first time when the screen is rendered, this view being defined as default view.We have to dynamically set the attributes values for SELECTEDPHASE,STATS2,STATUS3 and ENABLED_NEXT. To do this, we use the wdDoInit Hook method.

The wdDoInit Hook method

 METHOD wddoinit.
 DATA lr_node TYPE REF TO if_wd_context_node.
 DATA ls_data TYPE if_v_view=element_dynamic.
 lr_node = wd_context-get_child_node('DYNAMIC').
 ls_data-enabled_next = abap_true.
 ls_data-status2 = CL_WD_PHASE=E_STATUS-WARNING.
 ls_data-status3 = CL_WD_PHASE=E_STATUS-WARNING.
 ls_data-selectedphase = 'PHASE1'.
 lr_node-set_static_attributes(ls_data).
ENDMETHOD.

As we can see,we selected the first phase: ls_data-selectedphase = ‘PHASE1’and we set the Phase2 and Phase3 with the Warning status ls_data-status2 = cl_wd_phase) e_status-warning.
ls_data-status3 = cl_wd_phase) e_status-warning.

Runtime

When the user presses the button, the Framework triggers the event handler method onactionnext.

The onactionnext event handler method

 METHOD onactionnext.
 DATA lr_node TYPE REF TO if_wd_context_node.
 DATA ls_data TYPE if_v_view=element_dynamic.
 DATA lv_phase TYPE string.
 lr_node = wd_context->get_child_node('DYNAMIC').
 lr_node-get_attribute
(EXPORTING name ='SELECTEDPHASE'IMPORTING value = lv_phase).
 CASE lv_phase.
 WHEN 'PHASE1'.
 ls_data-selected phase ='PHASE2'.
 ls_data-enabled_next = abap_true.
 ls_data-status2 = cl_wd_phase=e_status-completed.
 ls_data-status3 = cl_wd_phase=e_status-warning.
 wd_this-fire_op_to_v_phase2_plg( ).
 WHEN 'PHASE2'.
 ls_data-selectedphase = 'PHASE3'.
 ls_data-enabled_next = abap_false.
 ls_data-status2 = cl_wd_phase=e_status-completed.
 ls_data-status3 = cl_wd_phase=e_status-completed.
 wd_this-fire_op_to_v_phase3_plg( ).
 WHEN OTHERS.
 ls_data-enabled_next = abap_false.
 ENDCASE.
 lr_node-set_static_attributes(ls_data).
 ENDMETHOD.

As we can see, we make active the Phase2 ls_data-selectedphase ¼ ‘PHASE2’ we set the Phase2 with completed status and Phase3 with warning status ls_data-status2 cl_wd_phase )
e_status-completed.ls_data-status3 = cl_wd_phase)e_status-warning.

For the next press of the NEXT button,we set the Phase2 and Phase3 with completed status

ls_data-status2 cl_wd_phase)e_status-completed.
ls_data-status3 cl_wd_phase)e_status-completed.we make active the last Phase, ls_data-selectedphase = ‘PHASE3’.

Runtime

Dynamic Programming

RUNTIME CLASS: CL_WD_PHASE_INDICATOR

Hereunder,we present a table showing the correspondence between the view designer name and the runtime name, with the proper types,in case of dynamic programming of a PhaseIndicator UI element

Dynamic programming

For the PhaseIndicator UI element,we have,as aggregation, the Phase element. It has the CL_WD_PHASE runtime class.
The implementation of a dynamic PhaseIndicator UI element with two Phases contains the following statements:

Dynamic programming of a PhaseIndicator UI element

 METHOD wddomodifyview.
 DATA lr_container TYPE REF TO cl_wd_uielement_container.
 DATA lr_flow_data TYPE REF TO cl_wd_flow_data.
 DATA lr_phaseindicator TYPE REF TO cl_wd_phase_indicator.
 DATA lr_phase1 TYPE REF TO cl_wd_phase.
 DATA lr_phase2 TYPE REF TO cl_wd_phase.
 IF first_time EQ abap_true.
 lr_container ?= view->get_element('ROOTUIELEMENTCONTAINER').
 lr_phaseindicator = cl_wd_phase_indicator=>new_phase_indicator(
 id = 'PI_PHASEINDICATOR'
 bind_selected_phase ='DYNAMIC.SELECTEDPHASE'
 irst_visible_phase ='PHASE1'
 background_design = cl_wd_phase_indicator=>
 e_background_designtransparent
 ).
 lr_flow_data = cl_wd_flow_data=>new_flow_data(element =
 lr_phaseindicator).
 lr_container->add_child(lr_phaseindicator).
 lr_phase1 = cl_wd_phase=>new_phase(
 id ='PHASE1'
 description ='PHASE 1'
 status = cl_wd_phase=>e_status-completed
 ).
 lr_phaseindicator->add_phase(the_phase = lr_phase1).
 lr_phase2 = cl_wd_phase=>new_phase(
 ld ='PHASE2'
 description ='PHASE 2'
 bind_status ='DYNAMIC.STATUS2'
 ).
 lr_phaseindicator->add_phase(the_phase = lr_phase2).
 ENDIF.
 ENDMETHOD.

Tree - Sequential Implementation

With this UI element,we can visualise the hierarchy defined in the context. For this UI element,we can use:

A sequential implementation with a non-recursive node in case the number of levels can be specified at design time
A recursive implementation with a recursive node in case the number of levels is not known at design time

WD component

In this case(sequential implementation,we don’t need a recursive node. A context node TREE is created in the context node of the view controller. It has the cardinality 1...1 and is Singleton.Under this context node,we create another context node TREE_NODE with two attributes. Under this context node,we create another context node TREE_LEAF with an attribute.

Context structure

The attributes STUDENTNAME, VALUE and STUDENTINFO are of STRING type.The context node TREE_LEAF is not Singleton,because we need to create an instance of this node for each element of the TREE_NODE context node.In the STUDENTNAME attribute, we hold the name of each student; for each student we have proper information held in the attribute STUDENTINFO. In a Tree UI element, we can insert Node Types of type TreeItemType and TreeNodeType,to specify which subnodes and which context attributes are going to be displayed.

Inserting Node Type

View layout

Binding of the Context to the Tree elements

The context node TREE_NODE is populated via the supply function method.

TREE_NODE context node

 METHOD supply_tree_node.
 DATA:
 ls_studentTYPE if_v_view
 =element_tree_node,lt_student LIKE TABLE OF ls_student.
 ls_student-studentname = 'Ionescu Ana Maria'.
 ls_student-value = 'A'.
 APPEND ls_student TO lt_student.
 ls_student-studentname = 'Marinescu Loredana'.
 ls_student-value = 'B'.
 APPEND ls_student TO lt_student.
 ls_student-studentname = 'Marton Luminita'.
 ls_student-value = 'C'.
 APPEND ls_student TO lt_student.
 node-bind_table(lt_student ).
 ENDMETHOD.

The values for the child node TREE_LEAF are set in the same way via a supply function method.

Populating the attributes of the TREE_LEAF context node

 METHOD supply_tree_leaf.
 DATA:
 ls_studentTYPE if_v_view=>
 element_tree_leaf,lt_student LIKE TABLE OF ls_student.
 DATA: lv_value TYPE string.
 parent_element->get_attribute
 (EXPORTING name = 'VALUE'IMPORTING value = lv_value ).
 CASE lv_value.
 WHEN 'A'.
 ls_student-student info ='Article - YES'.
 APPEND ls_student TO lt_student.
 ls_student-studentinfo = 'Exam - 5'.
 APPEND ls_student TO lt_student.
 ls_student-studentinfo = 'Academic year -II'.
 APPEND ls_student TO lt_student.
 WHEN 'B'.
 ls_student-studentinfo ='Article - NO'.
 APPEND ls_student TO lt_student.
 ls_student-studentinfo ='Academic year -I'.
 APPEND ls_student TO lt_student.
 WHEN OTHERS.
 ls_student-studentinfo ='Article - YES'.
 APPEND ls_student TO lt_student.
 ls_student-studentinfo ='Exam - 3'.
 APPEND ls_student TO lt_student.
 ls_student-studentinfo ='Academic year -IV'.
 APPEND ls_student TO lt_student.
 ENDCASE.
 node-bind_table(lt_student).
 ENDMETHOD.

Runtime

Dynamic Programming

RUNTIME CLASS: CL_WD_TREE

Hereunder,we present a table showing the correspondence between the view designer name and the runtime name,with the proper types,in case of dynamic programming of a Tree UI element.

Dynamic programming

For the Tree UI element, we have, as aggregation, the Node Types: TreeItem-Type and TreeNodeType. The TreeItemType element has the CL_WD_TREE_ ITEM_TYPE runtime class and the TreeNodeType element has the CL_WD_TREE_NODE_TYPE runtime class.

The implementation of a dynamic Tree UI element with two node types (Tree- NodeType and TreeItemType)contains the following statements:

Dynamic programming

 METHOD wddomodifyview.
 DATA lr_container TYPE REF TO cl_wd_uielement_container.
 DATA lr_flow_data TYPE REF TO cl_wd_flow_data.
 DATA lr_tree TYPE REF TO cl_wd_tree.
 DATA lr_treenode TYPE REF TO cl_wd_tree_node_type.
 DATA lr_treeitem TYPE REF TO cl_wd_tree_item_type.
 IF first_time EQ abap_true.
 lr_container ?= view->get_element('ROOTUIELEMENTCONTAINER').
 lr_tree = cl_wd_tree=>new_tree(
 id = 'TRE_SEQUENTIAL'
 bind_data_source = 'TREE'
 title = 'Student info'
 default_node_icon_source = '~Icon/CheckedOk'
 ).
 lr_flow_data = cl_wd_flow_data=>new_flow_data(element =
 lr_tree).
 lr_container->add_child(lr_tree).
 lr_treenode = cl_wd_tree_node_type=>new_tree_node_type(
 id ='TREE_NT'
 bind_data_source ='TREE.TREE_NODE'
 bind_text ='TREE.TREE_NODE.STUDENTNAME'
 ).
 lr_treeitem = cl_wd_tree_item_type=>new_tree_item_type(
 id ='TREE_IT'
 bind_data_source ='TREE.TREE_NODE.TREE_LEAF'
 bind_text ='TREE.TREE_NODE.TREE_LEAF.STUDENTINFO'
 ).
 lr_tree->add_node_type(index = 1
 the_node_type = lr_treenode).
 lr_tree->add_node_type(index = 2
 the_node_type = lr_treeitem).
 ENDIF.
 ENDMETHOD.

DateNavigator

This UI element offers the possibilities to display and navigate in a calendar and to enter dates, by choosing a year, a month,a day or a range of dates,from the showed calendar.

Hereunder,we present a table with some of the DataNavigator properties that can be bound, and the attribute type in case the property is bindable.

Some of the DataNavigator UI element properties

We create a WD Component named Y_UI_DATENAVIGATOR. In the context view,we create three attributes: MONTH, WEEK and DAY of STRING type,and two context nodes:

LEGEND,Cardinality 0. . .n, supply function named SUPPLY_LEGEND,attributes:
CATEGORY of WDY_MD_DATE_MARKING_CATEGORY type and TEXT of STRING type
MARKING,Cardinality 0...n,supply function named SUPPLY_MARKING, attributes: CATEGORY of WDY_MD_DATE_MARKING_CATEGORY type and DATE of D type.

In the view layout,we insert a DateNavigator UI element with a DateNavigator- Legend and DateNavigatorMarking. By using the DateNavigatorLegend element,we can add a legend for the DateNavigator, and with the DateNavigator- Marking element,we can highlight entries of a specific category within the Date- Navigator UI element.

Context view and DateNavigatorLegend, DateNavigatorMarking properties

The most important properties of the DateNavigatorLegend element are:

“Category”,which allows us to create the legend categories (in format one,two,three and four).It shall be bound to a context attribute that stores these categories.
“Text”, which stores the texts, describing each category.
“DataSource”,which shall be bound to a context node,which stores the categories and the texts of the legend entries. The most important properties of the DateNavigatorMarking element are:
“Category”,which shall be bound to a context attribute that stores the category of the highlighted data.
“DataSource”,which shall be bound to a context node which stores the categories,data and tooltip of the highlighted data.
“Tooltip” is not necessarily bindable. In our case,we have not created an attribute for the tooltip,because we don’t want to display a quick info text when the user passes the mouse pointer over the highlighted data of the Date- Navigator UI element.
“Data” shall be bound to a context attribute that stores the date of the highlighted data.

View layout

The DateNavigator UI element has many properties and events. In our case,we have changed the properties:

In this way,we have chosen Sunday as the first day of the week in our calendar.

In this way,we show 3 months in our calendar.

We have chosen from the list the range option,because we want to offer the possibility to select the range of dates.

We have set the starting date of our calendar.

To be able to show,in the TextView UI elements,the week,the day or the month that the end-user selects in our calendar,we have used the events:onDaySelect,on Month Select and on Week Select.

Events of the DataNavigator UI element

First of all,we have to populate our nodes with values. The Listing shows the SUPPLY_LEGEND supply function method.

The SUPPLY_LEGEND supply function method

 METHOD supply_legend.
 DATA: 
 ls_legend TYPE wd_this-element_legend,lt_legend LIKE TABLE OF ls_legend.
 ls_legend-category = cl_wd_date_nav_legend=e_category-one.
 ls_legend-text = 'Doors open day'.
 APPEND ls_legend TO lt_legend.
 ls_legend-category = cl_wd_date_nav_legend=>e_category-two.
 ls_legend-text = 'Operating teams trip'.
 APPEND ls_legend TO lt_legend.
 ls_legend-category = cl_wd_date_nav_legend=>e_category-three.
 ls_legend-text = 'Happy hour'.
 INSERT ls_legend INTO TABLE lt_legend.
 node-bind_table( lt_legend ).
 ENDMETHOD.

The Listing shows the SUPPLY_MARKING supply function method required to populate with values the MARKING node.

The SUPPLY_MARKING supply function method

 METHOD supply_legend.
 DATA:
 ls_legend TYPE wd_this-element_legend,lt_legend LIKE TABLE OF ls_legend.
 ls_legend-category = cl_wd_date_nav_legend=e_category-one.
 ls_legend-text = 'Doors open day'.
 APPEND ls_legend TO lt_legend.
 ls_legend-category = cl_wd_date_nav_legend=e_category-two.
 ls_legend-text = 'Operating teams trip'.
 APPEND ls_legend TO lt_legend.
 ls_legend-category = cl_wd_date_nav_legend=e_category-three.
 ls_legend-text = 'Happy hour'.
 INSERT ls_legend INTO TABLE lt_legend.
 node-bind_table( lt_legend ).
 ENDMETHOD.

In this way we mark (highlight),for the first category,the day 11.08.2009,for the second category,the day 21.08.2009,and for the third category,the day 24.08.2009. When the user selects a day in our calendar,the Framework triggers the event handler method onactionon_day_select.

The onactionon_day_select event handler method

As import parameter, for our event handler method, we have the parameter named DAY of D type that holds the selected day. We pass this value in our DAY attribute created in the context view.

When the user selects a Week in our calendar, the Framework triggers the event handler method onactionon_week_select.

The onactionon_week_select event handler method

When the user selects a Month in our calendar,the Framework triggers the event handler method onactionon_month_select. The onactionon_month_select event handler method. As import parameters,for our event handler method,we have: MONTH of I type that holds the selected month and YEAR of I type that holds the corresponding of the selected month. We pass these values in our MONTH attribute created in context view.

Runtime

Dynamic Programming

RUNTIME CLASS: CL_WD_DATE_NAVIGATOR

Hereunder,we present a table showing the correspondence between the view designer name and the runtime name, with the proper types,in case of dynamic programming of a DateNavigation UI element.

Dynamic programming

The implementation of a dynamic DateNavigator UI element with elements: DateNavigatorLegent and DateNavigatorMarking, contains the following statements:

Dynamic programming of a DataNavigator UI element

 METHOD wddomodifyview.
 DATA lr_date_navigator TYPE REF TO cl_wd_date_navigator.
 DATA lr_flow_data TYPE REF TO cl_wd_flow_data.
 DATA lr_container TYPE REF TO cl_wd_uielement_container.
 DATA lr_datenav_legend TYPE REF TO cl_wd_date_nav_legend.
 DATA lr_datenav_marking TYPE REF TO cl_wd_date_nav_marking.
 IF first_time EQ abap_true.
 lr_container ?= view->get_element('ROOTUIELEMENTCONTAINER').
 lr_date_navigator = cl_wd_date_navigator=>new_date_navigator(
 id ='DATENAVIGATOR'
 first_day_of_week = cl_wd_date_navigator=>e_first_day_of_week-sunday
 months_per_column = 1
 months_per_row = 3
 selection_mode = cl_wd_date_navigator=>e_selection_mode-range
 starts_with ='20090801'
 on_day_select ='ON_DAY_SELECT'
 on_month_select ='ON_MONTH_SELECT'
 on_week_select ='ON_WEEK_SELECT'
 ).
 lr_flow_data = cl_wd_flow_data=>new_flow_data(element =
 lr_date_navigator).
 lr_container->add_child(lr_date_navigator).
 lr_datenav_legend = cl_wd_date_nav_legend=>new_date_nav_legend(
 id ='DATENAVIGATORLEGEND'
 bind_category ='LEGEND.CATEGORY'
 bind_data_source ='LEGEND'
 bind_text ='LEGEND.TEXT'
 ).
 lr_date_navigator->set_legend(the_legend = lr_datenav_legend).
 lr_datenav_marking = cl_wd_date_nav_marking=>new_date_nav_marking(
 id = 'DATENAVIGATORMARKING'
 bind_category = MARKING.CATEGORY'
 bind_data_source ='MARKING'
 bind_date ='MARKING.DATE'
 ).
 lr_date_navigator->set_marking(the_marking=lr_datenav_marking) 
 ENDIF.
 ENDMETHOD.

Integration

This category contains complex UI elements as regards their structure and content.Hereunder,we present some of the UI Elements included in this category.

Table

By using this UI element, we can display data arranged in rows and columns.Table shows some of the Table properties that can be bound,and the attribute type in case the property is bindable.

Some of the Table UI element properties

Context structure

Table UI element – Creating the binding

Cell Editor of Table Column – Name of Property to be bound

After the user enters the new values (Name, Date of Birth and Country),we have to add these values at the end of the other records,in the table UI element. To be able to do this, we need an action.

View layout

Web Dynpro wizard to insert a Table UI element into the view layout

For a table UI element, we can insert a Toolbar. We need a toolbar to be able to insert a ToolBarButton in this area. We populate the node TABLE with two values, via the supply function method.

Inserting a ToolBarButton

Supply function method

 METHOD supply_person.
 DATA:
 ls_table TYPE wd_this-element_table,
 lt_table LIKE TABLE OF ls_table,
 lv_counter TYPE i VALUE 1.
 ls_table-no = lv_counter.
 ls_table-name = 'Antonia Maria Crist'.
 ls_table-dateofbirth = '19800305'.
 ls_table-country = 'DE'.
 lv_counter = lv_counter + 1.
 APPEND ls_table TO lt_table.
 ls_table-no = lv_counter.
 ls_table-name = 'Albu Alina'.
 ls_table-dateofbirth = '19800908'.
 ls_table-country = 'IT'.
 APPEND ls_table TO lt_table.
 node->bind_table(new_items=lt_table set_initial_elements = abap_true).
 node-set_lead_selection_index(index=lv_counter).
 ENDMETHOD.

To influence the lead selection, we have some methods, as following

Set_lead_selectio
Move_first
Move_previous
Move_

For our TABLE context node, we have set the selection cardinality 0...1 meaning that maximum one row can be selected if the node elements are displayed as a table.

When the user presses the “Add record” button,the Framework triggers the event handler method onactionadd.

Event handler method

 METHOD onactionadd.
 DATA: lr_node TYPE REF TO if_wd_context_node,
 lr_node1 TYPE REF TO if_wd_context_node,
 lr_element TYPE REF TO if_wd_context_element,
 lv_counter TYPE i,
 lv_dateofbirth TYPE ydateofbirth,
 lv_country TYPE y_defordomain,
 lv_name TYPE string,
 ls_registration TYPE wd_this->element_registration.
 lr_node = wd_context->get_child_node('REGISTRATION').
 lr_node->get_attribute(EXPORTING name ='DATEOFBIRTH'
 IMPORTING value = lv_dateofbirth).
 lr_node->get_attribute(EXPORTING name ='NAME'
 IMPORTING value = lv_name).
 lr_node->get_attribute(EXPORTING name ='COUNTRY'
 IMPORTING value = lv_country).
 lr_node1 = wd_context->get_child_node('TABLE').
 lr_node1->get_attribute(EXPORTING name ='NO'
 IMPORTING value = lv_counter).
 lv_counter = lv_counter + 1.
 ls_registration-no = lv_counter.
 ls_registration-dateofbirth = lv_dateofbirth.
 ls_registration-name = lv_name.
 ls_registration-country = lv_country.
 lr_node->set_static_attributes(ls_registration).
 lr_element = lr_node->get_lead_selection( ).
 lr_element->
 get_static_attributes( IMPORTING static_attributes = ls_registration ).
 lr_node1 = wd_context->get_child_node('TABLE').
 lr_node1->bind_structure( EXPORTING new_item = ls_registration
 set_initial_elements = abap_false).
 lr_node1->set_lead_selection_index(index = lv_counter).
 ENDMETHOD.

Runtime

The onactionreset event handler method

 METHOD onactionreset.
 DATA: lr_node TYPE REF TO if_wd_context_node,
 ls_registration TYPE wd_this-element_registration.
 lr_node = wd_context-get_child_node('REGISTRATION').
 lr_node->bind_structure(EXPORTING new_item = ls_registration).
 ENDMETHOD.

Runtime

Dynamic Programming

RUNTIME CLASS: CL_WD_TABLE

Hereunder,we present a table showing the correspondence between the view designer name and the runtime name, with the proper types,in case of dynamic programming of a Table UI element.

Dynamic programming

Dynamic programming of a Table UI element

 METHOD wddomodifyview.
 DATA lr_table TYPE REF TO cl_wd_table.
 DATA lr_flow_data TYPE REF TO cl_wd_flow_data.
 DATA lr_container TYPE REF TO cl_wd_uielement_container.
 DATA lr_column_name TYPE REF TO cl_wd_table_column.
 DATA lr_text_view TYPE REF TO cl_wd_text_view.
 DATA lr_table_header TYPE REF TO cl_wd_caption.
 DATA lr_column_name_header TYPE REF TO cl_wd_caption.
 IF first_time EQ abap_true.
 lr_container ?= view->get_element('ROOTUIELEMENTCONTAINER').
 lr_table = cl_wd_table=>new_table(
 id ='TBL_TABLE'
 bind_data_source ='TABLE'
 design = cl_wd_table=>e_design-alternating
 visible_row_count = 3
 ).
 lr_flow_data = cl_wd_flow_data=>new_flow_data(element =
 lr_table ).
 lr_container->add_child(lr_table).
 lr_column_name = cl_wd_table_column=>new_table_column(
 id = 'TBL_EXAMPLE_NAME'
 ).
 lr_table_header ?= cl_wd_caption=>new_caption(text ='Table UI elem
 ent - example').
 lr_table->add_column(the_column = lr_column_name).
 lr_table->set_header(lr_table_header).
 lr_text_view = cl_wd_text_view=>new_text_view(
 id ='TXV_NAME'
 bind_text ='TABLE.NAME'
 ).
 lr_column_name_header ?= cl_wd_caption=>new_caption(text = 'Nam
 e').
 lr_column_name->
 set_table_cell_editor(the_table_cell_editor = lr_text_view
 ).
 lr_column_name->set_header(lr_column_name_header).
 ENDIF.
 ENDMETHOD.

RoadMap

Some of the Table UI element properties

For the RoadMap example,we use the exercise from the ViewContainerUIElement,a little bit re-arranged. The WD component structure is presented.

WD component structure

In this case,we replace the LinkToAction UI elements with two Buttons: Next and Back. These Buttons are inserted into the view V_VIEW, and the user can navigate from the first step to the end one, via the RoadMap. In this case, we used only a View ContainerUIElement,and for each step we have a view. In the view V_VIEW, we insert a RoadMap UI element with three steps. To insert a step into a RoadMap UI Element, we right-click on the element and, from the contextual menu, we choose Insert Step.

RoadMap steps

V_VIEW view layout

T0 be able to manipulate the RoadMap UI element and the Button via the data held in the context, we create, in the V_VIEW, a context node named DYNAMIC. This node has three attributes:

SELECTEDSTEP, of STRING type, used to dynamically set the ID of the selected step
ENABLED_NEXT, of WDY_BOOLEAN type, used to manipulate the enabled property of the NEXT button
ENABLED_BACK,of WDY_BOOLEAN type,used to manipulate the enabled property of the BACK button (Fig – right)

Context structure

V_STEP1 view layout

V_STEP2 view layout

V_STEP3 view layout

To be able to navigate among the views, we have to create inbound and outbound plugs. In the view V_VIEW, we create three outbound plugs:

OP_TO_V_STEP1 required to navigate to the view V_STEP1
OP_TO_V_STEP2 required to navigate to the view V_STEP2
OP_TO_V_STEP3 required to navigate to the view V_STEP3

The view V_STEP1 has an inbound plug named IP_V_STEP1,the view V_STEP2 has an inbound plug named IP_V_STEP2 and the view V_STEP3 has an inbound plug named IP_V_STEP3.

Window structure

In the wdDoInit Hook method (V_VIEW),we dynamically set the attributes values for SELECTEDSTEP, ENABLED_NEXT and ENABLED_BACK.

The wdDoInit Hook method

 METHOD wddoinit.
 DATA lr_node TYPE REF TO if_wd_context_node.
 DATA ls_data TYPE wd_this->element_dynamic.
 lr_node = wd_context-get_child_node('DYNAMIC').
 ls_data-enabled_next = abap_true.
 ls_data-enabled_back = abap_false.
 ls_data-selectedstep ='STEP1'.
 lr_node->set_static_attributes(ls_data).
 ENDMETHOD.

First time when the screen is rendered, we want the BACK Button to be not enabled,the NEXT Button to be enabled, and the STEP1 to be the active RoadMap step.

Runtime

When the user presses the NEXT button, the Framework triggers the event handler method onactionnext.

The onactionnext event handler method

 METHOD onactionnext.
 DATA lr_node TYPE REF TO if_wd_context_node.
 DATA ls_data TYPE wd_this-element_dynamic.
 DATA lv_selectedstep TYPE string.
 lr_node = wd_context-get_child_node('DYNAMIC').
 lr_node-get_attribute(EXPORTING name =
'SELECTED STEP'IMPORTING value = lv_selectedstep ).
 ASE lv_selectedstep.
 WHEN ‘STEP1’.
 ls_data-selectedstep = ‘STEP2’.
 ls_data-enabled_next = abap_true.
 ls_data-enabled_back = abap_true.
 wd_this-fire_op_to_v_step2_plg( ).
 WHEN ‘STEP2’.
 ls_data-selectedstep = ‘STEP3’.
 ls_data-enabled_next = abap_false.
 ls_data-enabled_back = abap_true.
 wd_this-fire_op_to_v_step3_plg( ).
 WHEN OTHERS.
 ls_data-enabled_next = abap_false.
 ls_data-enabled_back = abap_true.
 ENDCASE.
 lr_node-set_static_attributes(ls_data).
 ENDMETHOD.

As we can see, we make active the STEP2: ls_data-selectedstep = ‘STEP2’,we fire the method that helps us to navigate to the nextview V_STEP2

wd_thisfire_op_to_v_step2_plg( )
and we enable both buttons
ls_data-enabled_next = abap_true.
ls_data-enabled_back = abap_true.

Runtime

When the user presses the BACK button, the Framework triggers the event handler method onactionback.

The onactionback event handler method

 METHOD onactionback.
 DATA lr_node TYPE REF TO if_wd_context_node.
 DATA ls_data TYPE wd_this-element_dynamic.
 DATA lv_selectedstep TYPE string.
 lr_node = wd_context-get_child_node(‘DYNAMIC’).
 lr_node-get_attribute( EXPORTING name =
‘SELECTEDSTEP’IMPORTING value = lv_selectedstep).
 CASE lv_selectedstep.
 WHEN ‘STEP3’.
 ls_data-selectedstep = ‘STEP2’.
 ls_data-enabled_next = abap_true.
 ls_data-enabled_back = abap_true.
 wd_this-fire_op_to_v_step2_plg( ).
 WHEN ‘STEP2’.
 ls_data-selectedstep = ‘STEP1’.
 ls_data-enabled_next = abap_true.
 ls_data-enabled_back = abap_false.
 wd_this->fire_op_to_v_step1_plg( ).
 WHEN OTHERS.
 ls_data-enabled_next = abap_true.
 ls_data-enabled_back = abap_false.
 NDCASE.
 r_node-set_static_attributes(ls_data ).
  ENDMETHOD.

As we can see(Fig.)when the user presses the BACK button,we navigate back to the view V_STEP2

Runtime

When the user presses again the BACK Button (Fig.),we navigate back to the view V_STEP1

wd_this!fire_op_to_v_step1_plg( ).
we deactivate the BACK button ls_data-enabled_back = abap_false.
and make active the step STEP1 ls_data-selectedstep = ‘STEP1’.

Runtime

Dynamic Programming

RUNTIME CLASS: CL_WD_ROAD_MAP

Hereunder,we present a table showing the correspondence between the view designer name and the runtime name, with the proper types,in case of dynamic programming of a RoadMap UI element.

Dynamic programming

The implementation of a dynamic RoadMap UI element with two Steps contains the following statements:

Dynamic programming of a RoadMap UI element

 METHOD wddomodifyview.
 DATA lr_container TYPE REF TO cl_wd_uielement_container.
 DATA lr_roadmap TYPE REF TO cl_wd_road_map.
 DATA lr_step1 TYPE REF TO cl_wd_road_map_step.
 DATA lr_step2 TYPE REF TO cl_wd_road_map_step.
 DATA lr_flow_data TYPE REF TO cl_wd_flow_data.
 IF first_time EQ abap_true.
 lr_container ?= view->get_element('ROOTUIELEMENTCONTAINER').
 lr_roadmap = cl_wd_road_map=>new_road_map(
 id = 'RM_ROADMAP'
 bind_selected_step ='DYNAMIC.SELECTEDSTEP'
 start_point_design = cl_wd_road_map=>e_start_point_design-selected
 ).
 lr_flow_data = cl_wd_flow_data=>new_flow_data(element =
 lr_roadmap).
 lr_container->add_child(lr_roadmap).
 lr_step1 = cl_wd_road_map_step=>new_road_map_step(
 id = 'STEP1'
 description ='STEP 1'
 name ='1'
 ).
 lr_roadmap->add_step(the_step = lr_step1).
 lr_step2 = cl_wd_road_map_step=>new_road_map_st
 id = 'STEP2'
 description ='STEP 2'
 name ='2'
 ).
 lr_roadmap->add_step(he_step = lr_step2).
 ENDIF.
 ENDMETHOD.

PhaseIndicator

Some of the PhaseIndicator UI element properties

Some of the phase properties and the dynamic manipulation of the status

We create the same example as for the RoadMap, but,in this case,we use a PhaseIndicator UI element with three phases.The WD component structure is presented.

WD component structure

Inserting Phase into a PhaseIndicator

Context structure

The V_VIEW layout

Window structure

The wdDoInit Hook method

 METHOD wddoinit.
 DATA lr_node TYPE REF TO if_wd_context_node.
 DATA ls_data TYPE if_v_view=element_dynamic.
 lr_node = wd_context-get_child_node('DYNAMIC').
 ls_data-enabled_next = abap_true.
 ls_data-status2 = CL_WD_PHASE=E_STATUS-WARNING.
 ls_data-status3 = CL_WD_PHASE=E_STATUS-WARNING.
 ls_data-selectedphase = 'PHASE1'.
 lr_node-set_static_attributes(ls_data).
 ENDMETHOD.

Runtime

When the user presses the button, the Framework triggers the event handler method onactionnext (Listing).

The onactionnext event handler method

 METHOD onactionnext.
 DATA lr_node TYPE REF TO if_wd_context_node.
 DATA ls_data TYPE if_v_view=element_dynamic.
 DATA lv_phase TYPE string.
 lr_node = wd_context->get_child_node('DYNAMIC').
 lr_node-get_attribute
(EXPORTING name ='SELECTEDPHASE'IMPORTING value = lv_phase).
 CASE lv_phase.
 WHEN 'PHASE1'.
 ls_data-selected phase ='PHASE2'.
 ls_data-enabled_next = abap_true.
 ls_data-status2 = cl_wd_phase=e_status-completed.
 ls_data-status3 = cl_wd_phase=e_status-warning.
 wd_this-fire_op_to_v_phase2_plg( ).
 WHEN 'PHASE2'.
 ls_data-selectedphase = 'PHASE3'.
 ls_data-enabled_next = abap_false.
 ls_data-status2 = cl_wd_phase=e_status-completed.
 ls_data-status3 = cl_wd_phase=e_status-completed.
 wd_this-fire_op_to_v_phase3_plg( ).
 WHEN OTHERS.
 ls_data-enabled_next = abap_false.
 ENDCASE.
 lr_node-set_static_attributes(ls_data).
 ENDMETHOD.

For the next press of the NEXT button,we set the Phase2 and Phase3 with completed status

ls_data-status2 cl_wd_phase)e_status-completed.
ls_data-status3 cl_wd_phase)e_status-completed.we make active the last Phase, ls_data-selectedphase = ‘PHASE3’.

Runtime

Dynamic Programming

RUNTIME CLASS: CL_WD_PHASE_INDICATOR

Hereunder,we present a table showing the correspondence between the view designer name and the runtime name, with the proper types,in case of dynamic programming of a PhaseIndicator UI element

Dynamic programming

Dynamic programming of a PhaseIndicator UI element

 METHOD wddomodifyview.
 DATA lr_container TYPE REF TO cl_wd_uielement_container.
 DATA lr_flow_data TYPE REF TO cl_wd_flow_data.
 DATA lr_phaseindicator TYPE REF TO cl_wd_phase_indicator.
 DATA lr_phase1 TYPE REF TO cl_wd_phase.
 DATA lr_phase2 TYPE REF TO cl_wd_phase.
 IF first_time EQ abap_true.
 lr_container ?= view->get_element('ROOTUIELEMENTCONTAINER').
 lr_phaseindicator = cl_wd_phase_indicator=>new_phase_indicator(
 id = 'PI_PHASEINDICATOR'
 bind_selected_phase ='DYNAMIC.SELECTEDPHASE'
 irst_visible_phase ='PHASE1'
 background_design = cl_wd_phase_indicator=>e_background_designtransparent
 ).
 lr_flow_data = cl_wd_flow_data=>new_flow_data(element =
 lr_phaseindicator).
 lr_container->add_child(lr_phaseindicator).
 lr_phase1 = cl_wd_phase=>new_phase(
 id ='PHASE1'
 description ='PHASE 1'
 status = cl_wd_phase=>e_status-completed
 ).
 lr_phaseindicator->add_phase(the_phase = lr_phase1).
 lr_phase2 = cl_wd_phase=>new_phase(
 ld ='PHASE2'
 description ='PHASE 2'
 bind_status ='DYNAMIC.STATUS2'
 ).
 lr_phaseindicator->add_phase(the_phase = lr_phase2).
 ENDIF.
 ENDMETHOD.

Tree - Sequential Implementation

With this UI element,we can visualise the hierarchy defined in the context. For this UI element,we can use:

A sequential implementation with a non-recursive node in case the number of levels can be specified at design time
A recursive implementation with a recursive node in case the number of levels is not known at design time

WD component

Context structure

Inserting Node Type

View layout

Binding of the Context to the Tree elements

The context node TREE_NODE is populated via the supply function method.

TREE_NODE context node

 METHOD supply_tree_node.
 DATA:
 ls_studentTYPE 
if_v_view=element_tree_node,lt_student LIKE TABLE OF ls_student.
 ls_student-studentname = 'Ionescu Ana Maria'.
 ls_student-value = 'A'.
 APPEND ls_student TO lt_student.
 ls_student-studentname = 'Marinescu Loredana'.
 ls_student-value = 'B'.
 APPEND ls_student TO lt_student.
 ls_student-studentname = 'Marton Luminita'.
 ls_student-value = 'C'.
 APPEND ls_student TO lt_student.
 node-bind_table(lt_student ).
 ENDMETHOD.

The values for the child node TREE_LEAF are set in the same way via a supply function method.

Populating the attributes of the TREE_LEAF context node

 METHOD supply_tree_leaf.
 DATA:
 ls_studentTYPE if_v_view=>
 element_tree_leaf,lt_student LIKE TABLE OF ls_student.
 DATA: lv_value TYPE string.
 parent_element->get_attribute
(EXPORTING name = 'VALUE'IMPORTING value = lv_value ).
 CASE lv_value.
 WHEN 'A'.
 ls_student-student info ='Article - YES'.
 APPEND ls_student TO lt_student.
 ls_student-studentinfo = 'Exam - 5'.
 APPEND ls_student TO lt_student.
 ls_student-studentinfo = 'Academic year -II'.
 APPEND ls_student TO lt_student.
 WHEN 'B'.
 ls_student-studentinfo ='Article - NO'.
 APPEND ls_student TO lt_student.
 ls_student-studentinfo ='Academic year -I'.
 APPEND ls_student TO lt_student.
 WHEN OTHERS.
 ls_student-studentinfo ='Article - YES'.
 APPEND ls_student TO lt_student.
 ls_student-studentinfo ='Exam - 3'.
 APPEND ls_student TO lt_student.
 ls_student-studentinfo ='Academic year -IV'.
 APPEND ls_student TO lt_student.
 ENDCASE.
 node-bind_table(lt_student).
 ENDMETHOD.

Runtime

Dynamic Programming

RUNTIME CLASS: CL_WD_TREE

Hereunder,we present a table showing the correspondence between the view designer name and the runtime name,with the proper types,in case of dynamic programming of a Tree UI element.

Dynamic programming

The implementation of a dynamic Tree UI element with two node types (Tree- NodeType and TreeItemType)contains the following statements:

Dynamic programming

 METHOD wddomodifyview.
 DATA lr_container TYPE REF TO cl_wd_uielement_container.
 DATA lr_flow_data TYPE REF TO cl_wd_flow_data.
 DATA lr_tree TYPE REF TO cl_wd_tree.
 DATA lr_treenode TYPE REF TO cl_wd_tree_node_type.
 DATA lr_treeitem TYPE REF TO cl_wd_tree_item_type.
 IF first_time EQ abap_true.
 lr_container ?= view->get_element('ROOTUIELEMENTCONTAINER').
 lr_tree = cl_wd_tree=>new_tree(
 id = 'TRE_SEQUENTIAL'
 bind_data_source = 'TREE'
 title = 'Student info'
 default_node_icon_source = '~Icon/CheckedOk'
 ).
 lr_flow_data = cl_wd_flow_data=>new_flow_data(element =
 lr_tree).
 lr_container->add_child(lr_tree).
 lr_treenode = cl_wd_tree_node_type=>new_tree_node_type(
 id ='TREE_NT'
 bind_data_source ='TREE.TREE_NODE'
 bind_text ='TREE.TREE_NODE.STUDENTNAME'
 ).
 lr_treeitem = cl_wd_tree_item_type=>new_tree_item_type(
 id ='TREE_IT'
 bind_data_source ='TREE.TREE_NODE.TREE_LEAF'
 bind_text ='TREE.TREE_NODE.TREE_LEAF.STUDENTINFO'
 ).
 lr_tree->add_node_type(index = 1
 the_node_type = lr_treenode).
 lr_tree->add_node_type(index = 2
 the_node_type = lr_treeitem).
 ENDIF.
 ENDMETHOD.

DateNavigator

This UI element offers the possibilities to display and navigate in a calendar and to enter dates, by choosing a year, a month,a day or a range of dates,from the showed calendar.

Hereunder,we present a table with some of the DataNavigator properties that can be bound, and the attribute type in case the property is bindable.

Some of the DataNavigator UI element properties

We create a WD Component named Y_UI_DATENAVIGATOR. In the context view,we create three attributes: MONTH, WEEK and DAY of STRING type,and two context nodes:

LEGEND,Cardinality 0. . .n,
supply function named SUPPLY_LEGEND,attributes:
CATEGORY of WDY_MD_DATE_MARKING_CATEGORY type and TEXT of STRING type
MARKING,Cardinality 0...n,supply function named SUPPLY_MARKING, attributes: CATEGORY of WDY_MD_DATE_MARKING_CATEGORY type and DATE of D type.

Context view and DateNavigatorLegend, DateNavigatorMarking properties

The most important properties of the DateNavigatorLegend element are:

“Category”,which allows us to create the legend categories (in format one,two,three and four).It shall be bound to a context attribute that stores these categories.
“Text”, which stores the texts, describing each category.
“DataSource”,which shall be bound to a context node,which stores the categories and the texts of the legend entries. The most important properties of the DateNavigatorMarking element are:
“Category”,which shall be bound to a context attribute that stores the category of the highlighted data.
“DataSource”,which shall be bound to a context node which stores the categories,data and tooltip of the highlighted data.
“Tooltip” is not necessarily bindable. In our case,we have not created an attribute for the tooltip,because we don’t want to display a quick info text when the user passes the mouse pointer over the highlighted data of the Date- Navigator UI element.
“Data” shall be bound to a context attribute that stores the date of the highlighted data.

View layout

The DateNavigator UI element has many properties and events. In our case,we have changed the properties:

In this way,we have chosen Sunday as the first day of the week in our calendar.

In this way,we show 3 months in our calendar.

We have chosen from the list the range option,because we want to offer the possibility to select the range of dates.

We have set the starting date of our calendar. To be able to show,in the TextView UI elements,the week,the day or the month that the end-user selects in our calendar,we have used the events:onDaySelect,on Month Select and on Week Select.

Events of the DataNavigator UI element

First of all,we have to populate our nodes with values. The Listing shows the SUPPLY_LEGEND supply function method.

The SUPPLY_LEGEND supply function method

 METHOD supply_legend.
 DATA: ls_legend TYPE wd_this-element_legend,lt_legend LIKE TABLE OF ls_legend.
 ls_legend-category = cl_wd_date_nav_legend=e_category-one.
 ls_legend-text = 'Doors open day'.
 APPEND ls_legend TO lt_legend.
 ls_legend-category = cl_wd_date_nav_legend=>e_category-two.
 ls_legend-text = 'Operating teams trip'.
 APPEND ls_legend TO lt_legend.
 ls_legend-category = cl_wd_date_nav_legend=>e_category-three.
 ls_legend-text = 'Happy hour'.
 INSERT ls_legend INTO TABLE lt_legend.
 node-bind_table( lt_legend ).
 ENDMETHOD.

We create three legend categories(one, two and three),with the texts:“Doors open day” for the first category, “Operating teams trip”for the second category and “Happy hour” for the third category. The Listing shows the SUPPLY_MARKING supply function method required to populate with values the MARKING node.

The SUPPLY_MARKING supply function method

 METHOD supply_legend.
 DATA: ls_legend TYPE wd_this-element_legend,lt_legend LIKE TABLE OF ls_legend.
 ls_legend-category = cl_wd_date_nav_legend=e_category-one.
 ls_legend-text = 'Doors open day'.
 APPEND ls_legend TO lt_legend.
 ls_legend-category = cl_wd_date_nav_legend=e_category-two.
 ls_legend-text = 'Operating teams trip'.
 APPEND ls_legend TO lt_legend.
 ls_legend-category = cl_wd_date_nav_legend=e_category-three.
 ls_legend-text = 'Happy hour'.
 INSERT ls_legend INTO TABLE lt_legend.
 node-bind_table( lt_legend ).
 ENDMETHOD.

The onactionon_day_select event handler method

As import parameter, for our event handler method, we have the parameter named DAY of D type that holds the selected day. We pass this value in our DAY attribute created in the context view. When the user selects a Week in our calendar, the Framework triggers the event handler method onactionon_week_select.

The onactionon_week_select event handler method

As import parameter,for our event handler method,we have the parameters: WEEK of I type that holds the selected week and YEAR of I type that holds the corresponding year of the selected week. We pass these values in our WEEK attribute created in the context view. When the user selects a Month in our calendar,the Framework triggers the event handler method onactionon_month_select.

The onactionon_month_select event handler method, As import parameters,for our event handler method,we have: MONTH of I type that holds the selected month and YEAR of I type that holds the corresponding of the selected month. We pass these values in our MONTH attribute created in context view.

Runtime

Dynamic Programming

RUNTIME CLASS: CL_WD_DATE_NAVIGATOR

Hereunder,we present a table showing the correspondence between the view designer name and the runtime name, with the proper types,in case of dynamic programming of a DateNavigation UI element.

Dynamic programming

The implementation of a dynamic DateNavigator UI element with elements: DateNavigatorLegent and DateNavigatorMarking, contains the following statements:

Dynamic programming of a DataNavigator UI element

 METHOD wddomodifyview.
 DATA lr_date_navigator TYPE REF TO cl_wd_date_navigator.
 DATA lr_flow_data TYPE REF TO cl_wd_flow_data.
 DATA lr_container TYPE REF TO cl_wd_uielement_container.
 DATA lr_datenav_legend TYPE REF TO cl_wd_date_nav_legend.
 DATA lr_datenav_marking TYPE REF TO cl_wd_date_nav_marking.
 IF first_time EQ abap_true.
 lr_container ?= view->get_element('ROOTUIELEMENTCONTAINER').
 lr_date_navigator = cl_wd_date_navigator=>new_date_navigator(
 id ='DATENAVIGATOR'
 first_day_of_week = cl_wd_date_navigator=>e_first_day_of_week-sunday
 months_per_column = 1
 months_per_row = 3
 selection_mode = cl_wd_date_navigator=>e_selection_mode-range
 starts_with ='20090801'
 on_day_select ='ON_DAY_SELECT'
 on_month_select ='ON_MONTH_SELECT'
 on_week_select ='ON_WEEK_SELECT'
 ).
 lr_flow_data = cl_wd_flow_data=>new_flow_data(element =
 lr_date_navigator).
 lr_container->add_child(lr_date_navigator).
 lr_datenav_legend = cl_wd_date_nav_legend=>new_date_nav_legend(
 id ='DATENAVIGATORLEGEND'
 bind_category ='LEGEND.CATEGORY'
 bind_data_source ='LEGEND'
 bind_text ='LEGEND.TEXT'
 ).
 lr_date_navigator->set_legend(the_legend = lr_datenav_legend).
 lr_datenav_marking = cl_wd_date_nav_marking=>new_date_nav_marking(
 id = 'DATENAVIGATORMARKING'
 bind_category = MARKING.CATEGORY'
 bind_data_source ='MARKING'
 bind_date ='MARKING.DATE'
 ).
 lr_date_navigator->set_marking(the_marking=lr_datenav_marking) 
 ENDIF.
 ENDMETHOD.

2012-09-22T23:02:00.003-07:00

Messages, Exceptions and Web Dynpro ABAP

This chapter shows how to work with exceptions and messages within the Web Dynpro ABAP applications. For each of the two variants (messages and exceptions),we present two possible implementation scenarios. Therefore, we start with the modality to create the texts of messages and exceptions,and we conclude with the modality of using them for the created applications.

A good user interface catches exceptions, describes the errors that occur and displays messages that contain information for the application end user.

As we have already seen,Web Dynpro offers the interface, through the IF_WD_MESSAGE_MANAGER, as a manager for messages.This interface has many methods we can choose to create messages.For example:

REPORT_T100_MESSAGE–reports a message by using a T100 input
REPORT_ERROR_MESSAGE–reports a Web Dynpro message with optional parameters
REPORT_ATTRIBUTE_T100_MESSAGE–reports a Web Dynpro exception for a Context Attribute
REPORT_ATTRIBUTE_ERROR_MESSAGE – reports a Web Dynpro exception for a Context Attribute
REPORT_SUCCESS–reports a success message
REPORT_WARNING–reports a warning message
REPORT_EXCEPTION–reports a Web Dynpro exception

The methods with REPORT_ATTRIBUTE_XXX or REPORT_ELEMENT_ XXX can be used to connect the message with the UI element that has generated that message.

Until now,we have created only simple messages that contained text introduced in coding.This art of programming isn’t recommended for many reasons,e.g.the message text inserted in coding cannot be translated without re-coding.In this chapter,we will create messages by using assistance class,T100 table,exception class and message class.

Message Handling

The messages that we display in Web Dynpro applications can be created in many ways.For example,we can create messages:

As dynamic texts stored in the text pool of the assistance class
As texts from database table T100

Itis not recommendable to enter specific language text in coding.

Dynamic Texts Stored in the Text Pool of the Assistance Class

One of the most important functions of the ssistance classes is the management of the dynamic texts.
In the Web Dynpro ABAP'the CL_WD_COMPONENT_ASSISTANCE class provides central functions through which a WD component can access text symbols of the assistance class.

We create a WD component,a registration form for a user.

WD component structure

The user has to fill a registration form with two mandatory fields:name and date of birth.If the user fills the form with the requested data,we show an information message to inform him that the data are saved.If the user doesn’t fill a mandatory field,we show an error message.The layout and the context node are presented.

To be able to work with dynamic texts stored in the text pool of the assistance class,we have to firstly create an assistance class. We can use class builder, Transaction SE24,to create a usual ABAP class.An Assistance class is ausual ABAP class that inherits from the super-class CL_WD_COMPONENT_ASSISTANCE. This super-class provides to our YCL_ASSISTANCECLASS class two additional methods.

The Layout and the context node

Creation of an assistance class

To maintain text symbols in the assistance class,we choose from the Assistance Class Maintenance menu Goto->Text Elements .Each new text symbol has an identification symbol(a three-digit ID)and a corresponding text.

Text symbols

To be able to have access to the text symbols of the assistance class by using the instance attribute WD_ASSIST,we have to assign the assistance class to our component.For each Web Dynpro component,we can create only a uniquely assigned assistance class.

Assistance class assigned to a WD component

When the user presses the REGISTRATION button,the Framework triggers the event handler method onactionregistration.

Coding of event handler method

 METHOD onactionregistration.
 DATA: text_success TYPE string,
 text_error TYPE string.
 text_error = wd_assist->if_wd_component_assistance~get_text( key =
 '001').
 text_success = wd_assist->if_wd_component_assistance~get_text( key =
 '002').
 DATA: lr_node TYPE REF TO if_wd_context_node,
 lv_name TYPE string,
 lv_dateofbirth TYPE ydateofbirth.
 lr_node = wd_context->get_child_node('PERSON').
 lr_node->get_attribute(EXPORTING name ='NAME'
 IMPORTING value = lv_name).
 lr_node->get_attribute(EXPORTING name ='DATEOFBIRTH'
 IMPORTING value = lv_dateofbirth).
 DATA lr_api_controller TYPE REF TO if_wd_controller.
 DATA lr_message_manager TYPE REF TO if_wd_message_manager.
 lr_api_controller ?= wd_this->wd_get_api( ).
 lr_message_manager = lr_api_controller->get_message_manager( ).
 IF lv_name IS INITIAL OR lv_dateofbirth IS INITIAL.
 lr_message_manager->report_error_message(message_text = text_error).
 ELSE.
 lr_message_manager->report_success(message_text =text_success).
 ENDIF.
 ENDMETHOD.

To have access to the text symbols of the assistance class,we have to create a local variable of STRING type(text_success TYPE string).At runtime,when the method if_wd_component_assistance get_text is called,the ID is passed to the KEY parameter,and the corresponding text symbol is stored into the local variable of STRING type. DATA:text_success TYPE string. text_success = wd_assist->if_wd_component_assistance get_text(key =‘002').To access the text from an assistance class,we can use the Web Dynpro Code Wizard.

Web Dynpro code wizard

If the attributes name or dateofbirth are empty,we show an error message by using the report_error_message method.If not,we show an information message by using the report_success method.

Application result

Text from Database Table T100

We can create messages by using message maintenance –transaction SE91.

Message class YCL_T100_MESSAGE

The Messages created here are stored in the database table T100.This table has the following columns: message number MSGNR, short text TEXT,language key SPRSL and message classARBGB.

The structure of the T100 table

We can search in this table to find all the messages with number 000,language English and all the texts that begin with the word “The”.After this search,we find also our message,too.

Searching for a message in T100 table

We create the same WD component, but in this case we use messages with text from the database table T100.

When the user presses the REGISTRATION button,the Framework triggers the event handler method onactionregistration. If the attributes NAME or DATEFOFBIRTH are empty,we show an error message by using the report_t100_message method.Msgty represents the message type E–error,msgid represents the name of the message class and msgno represents the message ID(a three-digit number).

Coding of event handler method

 METHOD onactionregistration.
 DATA: lr_node TYPE REF TO if_wd_context_node,
 lv_name TYPE string,
 lv_dateofbirth TYPE ydateofbirth.
 lr_node = wd_context->get_child_node('PERSON').
 lr_node->get_attribute(EXPORTING name ='NAME'
 IMPORTING value = lv_name).
 lr_node->get_attribute(EXPORTING name ='DATEOFBIRTH'
 IMPORTING value = lv_dateofbirth).
 DATA lr_api_controller TYPE REF TO if_wd_controller.
 DATA lr_message_manager TYPE REF TO if_wd_message_manager.
 lr_api_controller ?= wd_this->wd_get_api( ).
 lr_message_manager = lr_api_controller->get_message_manager( ).
 IF lv_name IS INITIAL OR lv_dateofbirth IS INITIAL.
 lr_message_manager->report_t100_message(
 msgid ='YCL_T100_MESSAGE'
 msgno ='000'
 msgty ='E').
 ELSE.
 lr_message_manager->report_t100_message(
 msgid ='YCL_T100_MESSAGE'
 msgno ='001'
 msgty ='I').
 ENDIF.
 ENDMETHOD.

If the attributes name or dateofbirth are not empty,we show an information message type I.At runtime,the User Interface is the same as for the latest example.The only difference is the way we have created these messages.

Exception Handling

Exceptions can be raised by the ABAP runtime environment,or explicitly in coding. Exception situations have many causes(e.g. cardinality violation for a context node).The exceptions are treatable or untreatable;all the unhandled exceptions cause a runtime error,a so-called short dump.

We can find all the short dumps from the system with transaction ST22,ABAPrun time error. We can find the runtime error from today and yesterday by using the two buttons“Today” and “Yesterday”,or we can search for a specific runtime error by using our selected parameters.

ABAP runtime error

Web Dynpro ABAP offers support to work with the exception classes through the methods of the Message Manager.Each exception has an explanatory text assigned to it that describes the exception.It can be an Online Text Repository OTR or a text from a message class.

We can create our own exception classes as global classes by using Class Builder or the local classes in our programms. Class-based exception handling is based on the exception classes; we have a notation specification for an exception class: its name has to begin with cx,zcx or ycx. As basic exception classes,we have CX_STATIC_CHECK,CX_DYNAMIC_ CHECK and CX_NO_CHECK.This classes are derived from the superclass CX_ROOT.

Exception Class with OTR Text

We create a WD component with the structure presented.

WD component structure

By using the view V_VIEW,we implement a search mask.The user enters the concurrent ID and receives more information about him.All the data about candidates are stored inthe database table YPERSON we have created in the ABAP Dictionary.When we don’t find in the database a concurrent with the searched ID,we raise an exception and we show a proper message.The view layout is presented.

View layout

Context structure

We have defined a node Search(Singleton,Cardinality 1...1)that holds the child node PERSON and the attribute ID_PERSON. The attribute ID_PERSON has the type yperson-id_person,Input help mode Automatic.For this table field,we have assigned in the ABAP Dictionary the search help YSH_ID_PERSON.We use this attribute to hold the concurrent ID entered by the user in the search mask.

The child node PERSON (Singleton,Cardinality 0...1)has the dictionary structure YPERSON,and as attributes we have quickly almost the entire table fields(without id_person).We use this context node to hold all the concurrent data with the searched ID.To show the result information,we have created a data binding between this node and the Table UI Element.

The user enters an ID and presses the button SEARCH.If the concurrent with this ID exists in the database table YPERSON,we show in the UI Element table the proper information,otherwise we raise an exception and the corresponding error message is shown.Before working with exception messages,we have to create an exception class.

Creating an exception class

As can be seen,we create an exception class without message class.In this case,the OTR is used as a central storage area for the exception texts.In the Text tab,we create an exception text The candidate with ID:&id_candidate& doesn’t exist,with the ID:YCX_NO_CANDIDATE.

Defining exception texts

Each exception text we create in the Texts tab consists of an ID and a corresponding text.The placeholder &id_candidate&is replaced at runtime by the content of the attribute with the same name defined in the Attributes tab.

Defining attributes

When the user presses the SEARCH button,the Framework triggers the event handler method onactionsearch.

Coding of event handler method

 METHOD onactionsearch .
 DATA obj TYPE REF TO ycx_exception_otr_txt.
 DATA: lt_candidate TYPE TABLE OF yperson,
 lr_node TYPE REF TO if_wd_context_node,
 ls_data TYPE if_v_view=>element_search,
 lv_id_person TYPE yperson-id_person.
 lr_node = wd_context->get_child_node('SEARCH').
 lr_node->get_attribute(EXPORTING name ='ID_PERSON'
 IMPORTING value = lv_id_person).
 TRY.
 SELECT * FROM yperson INTO TABLE lt_candidate
 WHERE id_person = lv_id_person.
 IF sy-subrc = 0.
 DATA lr_subnode TYPE REF TO if_wd_context_node.
 lr_subnode = lr_node->get_child_node('PERSON').
 lr_subnode->bind_table( new_items = lt_candidate).
 ELSE.
 RAISE EXCEPTION TYPE ycx_exception_otr_txt
 EXPORTING
 textid = ycx_exception_otr_txt=>ycx_no_candidate
 id_candidate = lv_id_person.
 ENDIF.
 CATCH ycx_exception_otr_txt INTO obj.
 DATA lr_api_controller TYPE REF TO if_wd_controller.
 DATA lr_message_manager TYPE REF TO if_wd_message_manager.
 lr_api_controller ?= wd_this->wd_get_api( ).
 lr_message_manager = lr_api_controller->get_message_manager( ).
 lr_message_manager->report_exception(message_object = obj).
 ENDTRY.
 ENDMETHOD.

After defining the data,we pass the value of the attribute id_person in the local variable lv_id_person.By using the TRY ENDTRY control structure,we handle a possible exception that can occur.We use open SQL to select all the data from the database table YPERSON into the internal table lt_candidate,where the field id_person is the same with our searched ID.

If we find this record in our database table,we populate the child node PERSON,because no exception occurs in the TRY block andthe system continues the processing after ENDTRY. Otherwise,a class-based exception occurs in the TRY block and the system searches for an exception handler.With RAISE EXCEPTION,we can raise an exception explicitly from our WD method.

RAISE EXCEPTION TYPE ycx_exception_otr_txt
EXPORTING textid = ycx_exception_otr_txt=>ycx_no_candidate id_candidate = lv_id_person.

This exception is caught in the CATCH block of the same TRY control structure:CATCH ycx_exception_otr_txt INTO obj.Because the additional INTO is specified,a reference to the exception object is stored in obj,where obj is the object reference variable.

After this,we use the method REPORT_EXCEPTION of the
IF_WD_MESSAGE_MANAGER interface to report a WD exception.
We present the execution result.The first picture represents the runtime where the exception occurs in the TRY-ENDTRY control structure,and the second picture represents the case when no exception occurs.In the second scenario,we can show,in the same time,the result of the Search help created in the ABAP Dictionary and attached to the id_person field of our database table YPERSON.

Application result

Exception Class with Text from a Message Class

We create the same WD component, but in this case we use an exception class with text from a message class. In this case,the interface IF_T100_MESSAGE is automatically included in the class definition. Figure shows the creation of an exception class by using Message Class.

Creating an exception class

Message class

In the “Properties”tab of the exception class,we have to enter the name of the message class we use.

Message class assignment

Class attributes

Each exception ID can be mapped to a message class and message ID.To do this,we have to use the Button Message Text. We assign the exception class attribute ID_CANDIDATE to the message class YCL_T100_MSG,message number 000.The placeholder and is replaced at runtime by the content of the ID_CANDIDATE attribute.

After activation,we can use this exception class in our WD component.Exception texts based on message classes are basically used in the same way as the exception texts thatuse OTR texts. When the user presses the SEARCH button,the Framework triggers the event handler method onactionsearch that has the same structureas the Listing.The only modification we have to do is to change the name of the exception class raised when an exception occurs.

Assigning attributes of an exception class to a message

Listing Exception handling

 DATA obj TYPE REF TO ycx_exception_t100_txt.
 ………….
 RAISE EXCEPTION TYPE ycx_exception_t100_txt EXPORTING
 textid = ycx_exception_t100_txt=>ycx_no_candidate
 id_candidate = lv_id_person.
 ……….
 CATCH ycx_exception_t100_txt INTO obj.
 ………

2012-09-22T23:02:00.001-07:00

Writing Multilanguage Applications

This chapter mainly focuses on the creation of Multilanguage applications.So,
the applications we realize are going to be easilyinternationalized without being necessary to recode them,butonlyto translate some centralized strings.For this,we haveto respect some rules,as follows: using the tools offered by the ABAP Workbench,establishing an initial language for our project,and avoiding to enter language specific texts in the codification of the business logic.
Internationalization(I18N)is a need for the global business software.In this chapter,we will see some of the tools offered by the ABAP Workbench to create Multilanguage User Interface and the tools we can use to make Multilanguage records in the database.
When the user logs onto the SAP System,he should enter a log-on language.If he doesn’t enter a language,then it is used the default log-on language from the user account.

Transaction SU01
Log-on language

This is the language in which the Web Dynpro application(and all others development objects)is originally written and the language that the System uses after logging-on.
A list with all the languages installed in the system we can find by using the transaction SMLT–Language Management.
Transaction language management

In our case,we can use English,German or Russian as original log-on language,and we can translate our application from the original language into another one.

ABAP Workbench offers many tools that simplify the process of creating internationalized applications.So,we create WD applications that support multiple languages without re-designing or modifying.
As mentioned above,an internationalized application doesn’t contain languagespecific text elements in the source text.As language-specific texts,we can mention:

Texts used,for example,to label UI elements or required for the dynamic programming,etc.
Texts defined when creating development objects in the ABAP Dictionary
Messages

Creating Multilanguage User Interfaces

We create a simple WD component,where we use some of the above-mentioned tools to offer support for English and German without making any code changes.All we have to do is to translate certain centralised strings and,after changing the log-on language(in our case,from“en”to“de”),the data will be automatically shown in the respective language.The WD component structure is presented.
WD component structure

In the context view,we create a context node named PERSON, Cardinality 1...1,Singleton,dictionary structure YPERSON and a context attribute named TEXT_I18N of STRING type.The context view and the view layout are presented.
Context node and view layout

We didnt insert any static strings for the“text”property of the UI elements Label and Button,or for the Caption view element.The strings shown as labels for the InputField UI elements represent the texts from the label field of the elementary data elements created in the ABAP Dictionary.For example,the label with the ID “FIRSTNAME_LBL” represents the label for the InputField bound to the attribute FIRSTNAME.The data element for this attribute is YPERSON-FIRSTNAME.If we look in our table definition,we can see that the elementary data type is YFIRSTNAME.. it can be seenthat“text”property of the label FIRSTNAME_LBL doesn’t contain anystatic values.To establish this string, we use the text with thelength Medium,defined in the YFIRSTNAME data element,i.e.“First Name”.
Text property and elementary data elements

Internationalization of Data Elements Defined in ABAP Dictionary
To internationalized data element defined in ABAP Dictionary, we have to translate the corresponding texts.The way we can perform this translations.
Translating the texts from a data element

After this,a pop-up window asks the language in which we want to translate the texts.We choose German and we enter the texts to be translated,for the strings.We repeat the same steps,until all the strings for the corresponding elementary data elements are translated.
Translating the strings

Internationalization of Domains Defined in ABAP Dictionary
Similarly,we translate the texts stored in our Domain Y_COUNTRY_DOMAIN.
English–German translation for a domain

Translating the domain fixed values

Internationalization of Text from OTR
In our example,we have to enter a value in the text property of the UI element Button.To do this,we choose the OTR text that exists in the SOTR_VOCABULARY_BASIC package.
The OTR text from the SOTR_VOCABULARY_BASIC package

To create our own OTR text,we can use the menu Goto Online Text Repository Browser or the transaction SOTR_EDIT Editor for OTR texts. Figure shows how we can create an OTR text by using the Online Text Repository Browser.
Creating OTR texts

The basic vocabulary stored in the SOTR_VOCABULARY_BASIC package can be used for all the packages,but the created OTR textsare stored only once per each package.
Our own-defined OTR text

To translate an OTR text,we can use the transaction SE63 Translation: Original Screen.After translating it,we can use our own defined OTR text in the same way as the OTR texts defined by SAP in the SOTR_VOCABULARY_BASIC package.Then,we have to create a Multilanguage text for the text property of the Caption element.
Internationalization of Text from Assistance Class
In the previous chapter,we have seen how we can use an Assistant Class to work with messages. In this case,we use the texts stored in the text pool of the assistance class to make Multilanguage our text required by the Caption view element. We create an assistance class named YCL_I18N.We define here the text to be made Multilanguage.
Texts from assistance class

In the field mLen,we have to specify the maximum length of the text string of a text symbol.As we have already seen,this value should be greater than or equal to the defined length(dLen).It is better to use a higher value,because,at design time,we don’t knowfor how many languages we offer support.In English,forexample,the length is 36,but when we translate this string in another language,it might be greater.In this case,we could not be able to enter the entire translation text.This length is saved in the text pool. To translate this text from English into German,we use the menu Goto->Translation.
Translating texts from the assistance class

After this,we realise a data binding between the attribute TEXT_I18N and the property text of the Caption element.We dynamically access the string we have just defined and translated.
wdDoInit( )Hook method

 METHOD wddoinit.
 DATA:lv_text TYPE string.
 lv_text = wd_assist->if_wd_component_assistance~get_text('001').
 wd_context->set_attribute(name ='TEXT_I18N'
 value=lv_text).
 ENDMETHOD

As we have mentioned above,to be able to have access to the text symbols of the assistance class by using the instance attribute WD_ASSIST,we have to assign the assistance class to our component.After this,we run our application.
Runtime. Default language: English

Internationalization of Messages
We create a Message class named YCL_I18N_MSG,where we define a message with the ID“000”and the short text “First Name is nrequired!”We want to show this message when the user presses the Update button.
Runtime – German

To translate this message,we choose from MENU Goto -->translation.
Translating a short text in the message class

When the user presses the Upload button,the Framework triggers the even handler method onactionsave. We run our application in the original language English and in German.
The onactionsave event handler method

 METHOD onactionsave.
 DATA: lr_api_controller TYPE REF TO if_wd_controller,
 lr_message_manager TYPE REF TO if_wd_message_manager.
 lr_api_controller?=wd_this->wd_get_api( ).
 lr_message_manager=lr_api_controller->get_message_manager( ).
 lr_message_manager-report_t100_message(msgid ='YCL_I18N_MSG'
 msgno='000'msgty ='E'.
 ENDMETHOD.

Multilanguage messages

Multilanguage Records in the Database In this case,we make Multilanguage the records we store in a database table.We create a very simple example to show how we can store data in a database table,not only in the log-on language,and then we create the User Interface in Web Dynpro to see how we can process these data.
We copy the table YEU_COUNTRIES and rename it YEU_I18N. Our target is to be able to store the political system for each EU Country not only in English,but in German,too.
Study an Example Created in the System
Before creating our own example,we shall briefly explain the table structure we are going to build.In this respect,we study a simple example presented in the system,starting with the search of a text table.A text table usually has the suffix T and contains an explanatory text in several languages,for each key. With the transaction SE11 ,we display all the tables that end in “_T”.
Searching to find a text table

From the list that appears,we choose to see the structure of the text table for Text Table for Release/Lock object Handling. As we can see,we have a Field named SPRAS of SPRAS type that represents the Language Key and two fields BEZ(description)and KURZBEZ(short description) that contain an explanatory text in several languages,for each FSOBJANL key.In this case,we have support for German and English, so we have the translation in two languages(E – English,D –German) for each key. Let’s look at the foreign key relationship:As we can see, this table is a text table for the table /BEV3/CHCTFSOS The structure of this table is presented. The table /BEV3/CHCFSOS_T is a text table for /BEV3/CHCTFSOS.If we study both tables,we see that the text table additionally contains a language key.
Text table structure

The content of a text table

Foreign key relationship

Table /BEV3/CHCFSOS

field and two extra Fields that contain an explanatory text in English and in German,for each key entry of /BEV3/CHCTFSOS.Let’s look at the structure of the table /BEV3/CHCFSOBJS.
Structure of the table /BEV3/CHCFSOBJS

For our purpose,in this case it is interesting the Field FSOBJANL.As we can see,this field has an foreign key defined to /BEV3/CHCTFSOS.
Creating Table Structures and Internationalization of the Records
For our example,we create the same structure as the one presented above,but with only one explanatory text for the political system per each EU Country. The table YEU_I18N has the structure presented.
YEU_I18N table

The Field POLITICALSYSTEM has defined an foreign key to the table YKEY that holds only the ID of the politicalsystem.
Key table

Text table

To link the politicalsystem key with the descriptions included in the text table, we have to link the table YKEY_T with the tableYKEY by using a foreign key.
Foreign key

Now,we have to maintain the data that refer to an object and are technically distributed between the tables YKEY and YKEY_T.
Maintaining data in the tables YKEY and YKEY_T

To realize this,we create a Maintenance View.Call transaction SE11,enter the name of the new maintenance view in the field VIEW and press CREATE.At the next popup window choose the kind of view we want to create.In our case “Maintenance View”. Enter the tablenames as shown below and pres button“Relationships”.In our case we can accept the suggestion. The View Fields are presented. After this,we choose from the menu Utilities --> Table Maintenance Generator ,to generate table maintenance.
Maintenance view

View fields

Generating maintenance view

We go back to the Maintenance View and we choose from the menu Utilities --> Contents.
Insert content

New entries

We insert three political systems and then we translate them in German.To do this,we select the entry we want to translate and we choose from the menu Goto --> Translation.
Translating records

Using the Internationalized Records in WebDynpro
Through a Web Dynpro application,we create a mini-administration User Interface for our table YEU_I18N.The view layout and the context node are presented.

View layout and context node

The context node has the dictionary structure YEU_I18N. The runtime result is presented.
Internationalization – database records

To select the values from the database according to the log-on language,we create a database view in the ABAP Dictionary and perform a selection,where spras sy-langu: SELECT * FROM y_i18nv INTO TABLE lt_i18nv WHERE spras = sy-langu.
We create a context node named I18NSELECT that has,as dictionary structure the view “Y_I18NV”that we have created in the ABAP Dictionary.
Database view and context node

Runtime

2012-09-22T23:00:00.003-07:00

WebDynproModel

This chapter presents the role of a model in a multicomponentWeb Dynpro application, showing not only themodality to use such a model, but also to create it. We are going to focus on three types of models: Assistance class, BAPI and Web Service.

So far,we have created only small applications used to access the data contained in a table,through the SQL statements introduced in the methods defined in the views. This art of programming is not in concordance with the MVC design pattern.

According to the Model View Controller MVC paradigm,the application data and their user interface are separated. The Model represents the business logic, the View represents the user interface and the controller has certain responsibilities, as the communication between the model and the view,or data processing at runtime.

In this way,it is possible to change the user interface without changing the business logic,or it is possible to change the business logic without having to change the user interface.In the same time,we can reuse the same business logic for more user interfaces.

In the Web Dynpro ABAP, the model can be implemented by the:

Assistance class
BAPI
WebService
Faceless Component,etc.

A Web Service can be compared with a “black box” that offers certain functionalities.These functionalities can be integrated in a client application (in our case,Web dynpro ABAP)that consumes the respective web service. In this respect,a Web Servicemay require certain inputs fromthe client application and delivers it the proper answer.Usually, Web Services are used to communicate between different platforms.

As mentioned before,an assistance class is a normal ABAP class that inherits from the CL_WD_COMPONENT_ASSISTANCE.Each Web Dynpro component can have a uniquely assigned assistance class that offers certain benefits,as follows:

It works with text symbols
It’s more advantageous to call its methods than to call the methods defined in a Web Dynpro controller.

The Business Application Program Interfaces (BAPI)are specific methods for business object types that offer the possibility to access external data and processes.

The Faceless Component is a Web Dynpro Component that doesn’t have any View or Window;in conclusion, it’s a Component that doesn’t have any User Interface,but it encapsulates functionality and can be used to build a Model.

Assistance Class as a Model for a Multicomponent Application

Essentially,each ABAP class can be used as a model. The particularity of an assistance classes is that we can assign it to a Web Dynpro component and it is automatically instantiated when the proper component is called.

We create an assistance class named YCL_AC_MODEL.

Assistance class

In this assistance class,we create three methods named SEARCH_CANDIDAT,SELECT_CANDIDATE and INSERT_CANDIDATE. Here, we store the coding required within the WD components to look for a candidate,to select all the candidates and to insert information about a candidate into or from the database table YPERSON.

Methods for the assistance class

Before implementing our methods,we created the lowest level of coding that abstracts the data access.In this case,we choose to implement the simplest data access method by using the classical ABAP tools,respective through the Function Modules,but we can also use other tools,e.g.the Persistent Object Classes,required to benefit of the object oriented programming(OOP).In case we want to use Persistent Objects to access the data from the database table in the Object Oriented mode,we can use for our Web Dynpro project the same structure (by taking the Assistance class as a model). But,in this case,we have to replace the Function Modules with Persistent Classes.table One of the created Function Modules will be used later,as the end point for a BAPI.It will be also used to create a Web Service.

A Function Module (FM)is a procedure with public interface, which can be created within a Function Group. To create a Function Group, we select Create--> Function Group from the context menu of our package name. We create a Function Group named YFG_DBACCESS.Here,we implement three FMs,named.

YFM_SEARCH_ CANDIDATE,
YFM_SELECT_CANDIDATE and YFM_ INSERT_CANDIDATE.

Listing shows the implementation of YFM_SEARCH_CANDIDATE.

The exception class YCX_EXCEPTION_T100_TXT was defined hereinbefore,when we have seen how we can work with the exception classes in WD.

Shows the implementation of YFM_SEARCH_CANDIDATE

 FUNCTION YFM_SEARCH_CANDIDATE .
 *"--------------------------------------------------------------------
 *"*"Local Interface:
 *" IMPORTING
 *" VALUE(ID_CANDIDATE)TYPE YPERSON-ID_PERSON
 *" EXPORTING
 *" VALUE(ITAB)TYPE YTABLE_TYPE
 *" RAISING
 *" YCX_EXCEPTION_T100_TXT
 *"----------------------------------------------------------------------
 TRY.
 SELECT *
 FROM yperson
 INTO TABLE itab WHERE id_person = id_candidate.
 IF sy-subrc <> 0.
 RAISE EXCEPTION TYPE ycx_exception_t100_txt
 EXPORTING
 textid = ycx_exception_t100_txt=>ycx_no_candidate
 id_candidate = id_candidate.
 ENDIF.
 ENDTRY.
 ENDFUNCTION.

Listing Implementation of YFM_SELECT_CANDIDATE

 FUNCTION YFM_SELECT_CANDIDATE.
 *"------------------------------------------------
 *"*"Local Interface:
 *" EXPORTING
 *" VALUE(ITAB) TYPE YTABLE_TYPE
 *" RAISING
 *" YCX_EXCEPTION_T100_TXT
 *"-------------------------------------------------
 TRY.
 SELECT *
 FROM yperson
 INTO TABLE itab.
 IF sy-subrc <> 0.
 RAISE EXCEPTION TYPE ycx_exception_t100_txt
 EXPORTING
 textid = ycx_exception_t100_txt=>ycx_select_no_posible.
 ENDIF.
 ENDTRY.
 ENDFUNCTION.

This FM selects the information about all the candidates. In this case,we create a new message ID–001“Data cannot be selected!”and a new exception ID YCX_ SELECT_NO_POSSIBLE with the text from the message class – message ID 001

Listing shows the implementation of YFM_INSERT_CANDIDATE

 FUNCTION YFM_INSERT_CANDIDATE .
 *"------------------------------------------
 *"*"Local Interface:
 *" IMPORTING
 *" VALUE(ID_CANDIDATE)TYPE YPERSON-ID_PERSON
 *" VALUE(FIRSTNAME)TYPE YPERSON-FIRSTNAME
 *" VALUE(LASTNAME)TYPE YPERSON-LASTNAME
 *" VALUE(AGE) TYPE YPERSON-AGE
 *" VALUE(TELEPHONE)TYPE YPERSON-TELEPHONE
 *" VALUE(ID_COUNTRY)TYPE YPERSON-ID_COUNTRY
 *" RAISING
 *" YCX_EXCEPTION_T100_TXT
 *"------------------------------------------
 DATA wa_person TYPE yperson.
 wa_person-mandt = sy-mandt.
 wa_person-id_person =id_candidate.
 wa_person-firstname =firstname.
 wa_person-lastname =lastname.
 wa_person-age = age.
 wa_person-telephone =telephone.
 wa_person-id_country =id_country.
 TRY.
 INSERT into yperson values wa_person.
 IF sy-subrc <> 0.
 RAISE EXCEPTION TYPE ycx_exception_t100_txt
 EXPORTING textid = ycx_exception_t100_txt=>ycx_insert_no_possible.
 ENDIF.
 ENDTRY.
 ENDFUNCTION.

This FM inserts in the database table YPERSON the information about a candidate.In this case,we create a new message ID–002 “Candidate insert cannot be done!”and a new exception ID YCX_INSERT_NO_POSSIBLE with the text from the message class – message ID 002.

A FM can be tested by using the Test/Execute Button .In this way,we can check if our created FM works correctly.Then,we implement our first method from the assistance class.

Implementation of the SEARCH_CANDIDATE method

Pattern

Implementation of the SELECT_CANDIDATE method

Implementation of the INSERT_CANDIDATE method

The Class Builder provides a test environment for classes.We can test our class by using the same test/execute Button.

Testing the assistance class

In this way,we have autonomous units that can be independently tested before we integrate them into bigger applications. If we look backwards to the example that refers to the Exception class with OTR text,we can see that the entire coding was integrated in a method of the view controller.So,we didn’t separate the application layer from the business layer and from the presentation layer.

We create the presentation layer through a WD application. We create a main component named Y_MAIN,in which we will use three secondary elements:

Y_SEARCH,Y_SELECT and Y_INSERT.

WD component’s structure

All the components defined the same assistance class,the YCL_AC_MODEL.Any changes made to the model class in the Framework are available for any other component that has this model class defined as assistance class.In this way,we can share data among components.

As we have mentioned above,each ABAP class can be used as a model class,but the services offered by the Web Dynpro Framework in this respect are available only for an assistance class that inherits the abstract class CL_WD_COMPONENT_ASSISTANCE.

The Y_MAIN component represented the start point of this application;it is the only component that has a Web Dynpro application defined.We assign our assistance class YCL_AC_MODEL for our components.

Assistance class assigned to our components

The V_MAIN layout

By using the ViewContainerUIElement,we show one of the views:
V_SELECT,V_INSERT or V_SEARCH.

To be able to navigate among the three used Views,we have to define three outbound plugs.Figure shows the defined outbound plugs and the window structure.

Outbound plugs

Before being able to create the instance of the used components,e have to create usages at the V_MAIN View level.

When the user presses the linkToAction UI element–Insert–the Framework triggers the event handler method onactioninsert.

Event handler method

 METHOD onactioninsert .
 DATA: lr_cmp_usage TYPE REF TO if_wd_component_usage.
 lr_cmp_usage = wd_this->wd_cpuse_insert( ).
 IF lr_cmp_usage->has_active_component( ) IS INITIAL.
 lr_cmp_usage->create_component(assistance_class = me->wd_assist).
 ENDIF.
 Wd_this-fire_op_to_v_insert_plg( ).
 ENDMETHOD.

As we can see,through the statement
lr_cmp_usage--> create_component (assistance_class = me >wd_assist), the existing instance for the assistance class that belongs to the main component is assigned to the used component instance.In this way,we ensure that both components access the same instance of the assistance class.

The event handler methods onactionselect and onactionsearch have the same structure,excepting the outbound plug NAME that is fired when the user presses the respective linkToAction UI elements.

Listing Event handler methods

 METHOD onactionsearch .
 ….…….
 wd_this->fire_op_to_v_search_plg( ).
 ENDMETHOD.
 METHOD onactionselect.
 ……………
 wd_this->fire_op_to_v_select_plg( ).
 ENDMETHOD.

In this way,we create the instance of the used component and we specify the reference to the active instance of the assistance class.

The V_SELECT view layout and the context structure are presented.

View layout and context

Here,we show all the records from our YPERSON database table. The node “CANDIDATE” has the dictionary structure YPERSON, cardinality 1...n, Singleton,supply function SUPPLY_CANDIDATE. Listing Supply function method

METHOD supply_candidate.
wd_this->populate_node( ).
ENDMETHOD

As we can see,we call the user defined method POPULATE_NODE to populate the context node with values. We have chosen to create this method in order to populate with data the context node and to update its contained data every time the user presses the Refresh button.

When the component Y_SELECT is called,the assistance class is automatically instantiated. Then,this instance is available through the attribute WD_ASSIST:
lt_person = wd_assist!select_candidate( ).

The POPULATE_NODE method

 METHOD populate_node.
 DATA lr_node TYPE REF TO if_wd_context_node.
 DATA ls_data TYPE wd_this->element_candidate.
 DATA lr_oref TYPE REF TO ycx_exception_t100_txt.
 DATA lt_person TYPE STANDARD TABLE OF yperson.
 lr_node = wd_context->get_child_node('CANDIDATE').
 TRY.
 lt_person = wd_assist->select_candidate( ).
 lr_node->bind_table(new_items = lt_person).
 CATCH ycx_exception_t100_txt INTO lr_oref.
 DATA lr_api_controller TYPE REF TO if_wd_controller.
 DATA lr_message_manager TYPE REF TO if_wd_message_manager.
 lr_api_controller ?= wd_this->wd_get_api( ).
 lr_message_manager = lr_api_controller->get_message_manager( ).
 lr_message_manager->report_exception(message_object =lr_oref).
 ENDTRY.
 ENDMETHOD.

In this way,we call the method select_candidate from the assistance class and we pass the result in the lt_person internal table.

When the user presses the Refresh button, the Framework triggers the event handler method onactionrefresh.

Listing The ONACTIONREFRESH event handler method

 METHOD onactionrefresh.
 wd_this->populate_node( ).
 ENDMETHOD.

View layout and the view context

The CANDIDATE node has the dictionary structure YPERSON, cardinality 1...1,Singleton.By using this component,we insert records in our database table YPERSON.

When the user presses the Save Button,the Framework triggers the event handler method onactionsave.

The onactionsave event handler method

 METHOD onactionsave.
 DATA lr_oref TYPE REF TO ycx_exception_t100_txt.
 DATA lr_node TYPE REF TO if_wd_context_node.
 DATA lr_element TYPE REF TO if_wd_context_element.
 DATA ls_data TYPE wd_this->element_candidate.
 DATA: lv_firstname LIKE ls_data-firstname,
 lv_lastname LIKE ls_data-lastname,
 lv_age LIKE ls_data-age,
 lv_telephone LIKE ls_data-telephone,
 lv_id_country LIKE ls_data-id_country.
 lr_node = wd_context->get_child_node('CANDIDATE').
 lr_element = lr_node->get_element( ).
 lr_element->get_static_attributes(
 IMPORTING static_attributes = ls_data).
 lv_firstname =ls_data-firstname.
 lv_lastname =ls_data-lastname.
 lv_age = ls_data-age.
 lv_telephone = ls_data-telephone.
 lv_id_country = ls_data-id_country.
 TRY.
 wd_assist->insert_candidate(firstname = lv_firstname
 lastname = lv_lastname age = lv_age telephone = lv_telephone
 id_country = lv_id_country ).
 DATA: lv_success_text TYPE string.
 lv_success_text = wd_assist->if_wd_component_assistance~get_text('M01').
 wd_this->atr_mm->report_success(message_text = lv_success_text).
 CATCH ycx_exception_t100_txt INTO lr_oref.
 wd_this->atr_mm->report_exception(message_object = lr_oref) .
 ENDTRY.
 ENDMETHOD.

We have to firstly verify if the end user has inserted values in all the mandatory fields.To perform this check,we use the wdDoBeforeReaction Hook method that has the structure presented inthe“view controller methods”chapter.

If the user has inserted values in all the fields,we call the method insert_candidate from the model class and we pass the inserted values in the method parameters.

wd_assist!insert_candidate(firstname = lv_firstname lastname = lv_lastname age = lv_age telephone = lv_telephone id_country = lv_id_country).

In case the data were successfully saved,we informthe end user about this,through a message defined in our assistance class with the identification symbol - M01.

When an exception occurs,we show to the end user this message through the report_exception method.

“Atr_mm” represents an attribute created in the attribute tag of the current view.

This is declared of ref to if_wd_message_manager type.By using the wdDoInit Hook method,we pass in the atr_mm attribute the reference to the Message Manager:method,we pass in the atr_mm attribute the reference to the Message Manager:
DATA lr_api_controller TYPE REF TO if_wd_controller.lr_api_controller ?= wd_this-->;wd_get_api( ).
wd_this!atr_mm = lr_api_controller-->get_message_ manager( ).

View layout and context structure

The context structure is the same as for the context realized to exemplify the exception class with OTR text. When the user presses the Search Button,the Framework triggers the onactionsearch event handler method.

Event handler method

 METHOD onactionsearch.
 DATA lr_oref TYPE REF TO ycx_exception_t100_txt.
 DATA: lt_candidate TYPE STANDARD TABLE OF yperson,lr_node TYPE REF
 TO if_wd_context_node,lv_id_candidate TYPE yperson-id_person.
 lr_node = wd_context->get_child_node('SEARCH').
 lr_node->get_attribute(EXPORTING name ='ID_PERSON'IMPORTING value = 
 lv_id_candidate).
 TRY.
 lt_candidate =
 wd_assist->search_candidate(id_candidate = lv_id_candidate).
 DATA lr_subnode TYPE REF TO if_wd_context_node.
 lr_subnode = lr_node->get_child_node('PERSON').
 lr_subnode->bind_table(new_items = lt_candidate).
 CATCH ycx_exception_t100_txt INTO lr_oref.
 wd_this->atr_mm->report_exception(message_object = lr_oref ).
 ENDTRY.
 ENDMETHOD.

When the component Y_SEARCH is called,the assistance class is automatically instantiated.Then,this instance is available through the attribute WD_ASSIST:

lt_candidate = wd_assist!search_candidate(id_candidate = lv_id_candidate). In this way,we call the method search_candidate from the assistance class and we pass the result in the lt_candidate internal table. When an exception occurs, we show the message to the end user,through the report_exception method.

run time

We can extend our application by adding the possibility to change a candidate record.For the database table YPERSON, we have defined in the ABAP Dictionary a Lock Object. We can use it to synchronize the access to the same data in our database table YPERSON with more that one WD application.

Locking objects

To set a lock and to release a lock, we can define,in our assistance class,two additional methods that use the generated Function Modules ENQUEUE_YPERSON and DEQUEUE_YPERSON. After this,we call our defined methods from our WD methods every time we want to lock one or more data records or to release the locked data records.

In case we need to perform a search in a database table to find all the records that contain a certain searched pattern, we can use the ABAP classes CL_ABAP_ REGEX and CL_ABAP_MATCHER. In our case,we search the database table YPERSON, column “firstname”,to find all the records that contain the string we are looking for.This value will be found in the local variable lv_firstname.

Search with CL_ABAP_MATCHER

 TYPES: BEGIN OF st_person,
 mandt TYPE yperson-mandt,
 id_person TYPE yperson-id_person,
 firstname TYPE yperson-firstname,
 lastname TYPE yperson-lastname,
 telephone TYPE yperson-telephone,
 age TYPE yperson-age,
 id_country TYPE yperson-id_country,
 END OF st_person.
 DATA: it_person TYPE TABLE OF st_person,
 lv_firstname TYPE yperson-firstname.
 FIELD-SYMBOLS <fs_person> LIKE LINE OF it_person.
 SELECT * FROM yperson INTO TABLE it_person.
 LOOP AT it_person ASSIGNING <fs_person>.
 IF cl_abap_matcher=>contains(pattern = lv_firstname text =
 <fs_person>-firstname)= abap_true.
 INSERT <fs_person>INTO TABLE itab.
 ENDIF.
 ENDLOOP.

As can be seen,we used the static method CONTAINS of the class
CL_ABAP_MATCHER,where “pattern” represents the searched pattern and “text” represents the text we search to find this pattern.

The result will be “abap_true” if the search was successfully finalized:

cl_abap_matcher => contains (pattern = lv_firstnametext = < fs_person > firstname )= abap_true.

After each successful search,we insert the respective records in the internal table itab.Then,we populate with these values the node bound at the table where the results are displayed.

BAPI as a Model

BAPI as a Model
BAPI are standard SAP interfaces, defined as methods for the business object types that can be used in the business data exchange among the SAP components, and among the SAP and the non SAP components. In our example, we use the YFM_SEARCH_CANDIDATE Function Module to create a simple BAPI example that we use as a model in a WD component. To be able to do this, we should firstly make some changes at the Function Module level.

Creating a BAPI
We create a new Function Group, where we copy the YFM_SEARCH_CANDIDATE and rename it YBAPI_YCANDIDATE_SEARCH. For a BAPI, we have a name convention BAPI_<name_object_type>_<method_name>. In case of asearch( ) BAPI, which reads the details for the object type YCANDIDATE, the name of the associated Function Module is YBAPI_YCANDIDATE_SEARCH. In the Attributes tab of the Function Module, we have to activate the option Remote-Enabled Module.

The remoteenabled module option – RFC

After this, we create a structure in the ABAP Dictionary with the same components as our YPERSON table.

Structure YBAPI_YPERSON
We use this structure to define our parameters id_candidate type YBAPI_ YPERSON-ID_PERSON and itab LIKE YBAPI_YPERSON. Now, we have to make another change, because we cannot use exceptions anymore.
RAISE EXCEPTION TYPE ycx_exception_t100_txt EXPORTING
textid = ycx_exception_t100_txt=>ycx_no_candidate
id_candidate = id_candidate.
In order to return a message in case no records exist in the database table YPERSON with the specified ID, we use an export Return parameter for returning the exception messages to the calling application. With this Return parameter, based on the reference structure BAPIRET2, we are able to record and classify all the possible errors that may occur. The structure BAPIRET2 has the structure presented.

The BAPIRET2 structure

We can fill this structure via the Function Module BALW_BAPIRETURN_GET2 .

 CALL FUNCTION 'BALW_BAPIRETURN_GET2'
  EXPORTING
  type =
  cl =
  number =
  * PAR1 = ' '
  * PAR2 = ' '
  * PAR3 = ' '
  * PAR4 = ' '
  * LOG_NO = ' '
  * LOG_MSG_NO = ' '
  * PARAMETER = ' '
  * ROW = 0
  * FIELD = ' '
  * IMPORTING
  * RETURN

Pattern for BALV_BAPIRETURN_ GET2
The Listing shows the Function Module structure. Function module

FUNCTION ybapi_ycandidate_search .
  *"----------------------------------------------------------------------
  *"*"Global Interface:
  *" IMPORTING
  *" VALUE(ID_CANDIDATE) TYPE YBAPI_YPERSON-ID_PERSON
  *" TABLES
  *" ITAB STRUCTURE YBAPI_YPERSON OPTIONAL
  *" RETURN STRUCTURE BAPIRET2 OPTIONAL
  *"----------------------------------------------------------------------
  DATA msg_id_candidate LIKE sy-msgv1.
  CLEAR msg_id_candidate.
  REFRESH: return, itab.
  SELECT *
  FROM yperson
  INTO TABLE itab
  WHERE id_person = id_candidate.
  IF sy-subrc <> 0.
  msg_id_candidate = id_candidate.
  CALL FUNCTION 'BALW_BAPIRETURN_GET2'
  EXPORTING
  type = 'E'
  cl = 'YCL_T100_MSG'
  number = '000'
  par1 = msg_id_candidate
  IMPORTING
  return = return.
  APPEND return.
  ELSE.
  APPEND return.
  ENDIF.
  ENDFUNCTION.

As we can see, instead of raising an exception in case we don’t find any records with the specified ID, we use the BALW_BAPIRETURN_GET2 Function Module to fill the structure BAPIRET2. We have used the defined YCL_T00_MSG message class number 000, and we have replaced the parameter placeholder with the value inserted by the user as a candidate ID. After saving and activating, we can release our Function Module: Function Module ! Release ! Release. As result of our RELEASE action, we’ll get a message of YBAPI_YCANDIDATE_SEARCH type. By using the SWO1 (Business Object Builder) transaction, we create an object named YCANDIDATE.

Creating the object candidate

We add a Method named SEARCH: Utilities ! API Methods ! Add Method.

Creating the API method

We have to release our object. We choose from the menu Edit ! Change Release Status ! Object Type ! To model. We make the same steps for To implement and To release, and the same steps for Object Type Component. After releasing the object, we can test it.

Testing the BAPI

Using the Created BAPI as a Model We create a WD component named Y_BAPI, where we use the created BAPI as a model to obtain the data required from the database table YPERSON.

WD component structure

By right-clicking on the WD component name, we choose from the contextual menu Create ! Service call. The Web Dynpro Wizard is open, creating an appropriate context structure and generating a method that contains the required coding for the service call.
The Wizard steps are:
l Start
l Select controller – we use the existing controller

Selecting the controller
l Select Service Type – we select the Function Module.

Selecting the service type

l Select Service – we specify only the name of the YBAPI_YCANDIDATE_ SEARCH Function Module; the Destination box remains unfilled (blank). In this way, the Function Module will be locally called

Selecting the service

l Adapt Context – here, we can choose which object type we want to use to represent the service function parameters in the WD controller: as a parameter, as a controller attribute or as a context node or context attribute.

Adapting the context

l Specify Method Name – we have to specify the name of the generated method that shall execute the service.

Specifying the method name

l Generate Controller
After the last step, we press the COMPLETED button and the wizard ends. I generates the COMPONENTCONTROLLER context and the proper method EXECUTE_ YBAPI_YCANDIDATE_SEARC that shall execute the service

The generated context and method

The node IMPORTING contains the ID_CANDIDATE attribute in which is stored the value of the ID we are looking for. The node CHANGING contains the two nodes ITAB and RETURN. The node ITAB holds the information about the candidate with the searched ID. The node RETURN has the structure BAPIRET2; we need to use its message attribute to display the return messages on the screen for the end user. The View layout has the structure presented.

View layout and view context

When the user presses the button to look for a candidate, the Framework triggers the event handler method onactionsearch.

METHOD onactionsearch.
  wd_comp_controller->execute_ybapi_ycandidate_searc( ).
  DATA: lr_bapi_node TYPE REF TO if_wd_context_node,
  lr_changing TYPE REF TO if_wd_context_node,
  lr_return TYPE REF TO if_wd_context_node.
  DATA lv_bapi_message TYPE bapi_msg.
  lr_bapi_node = wd_context->get_child_node( `YBAPI_YCANDIDATE_SEA` ).
  lr_changing = lr_bapi_node->get_child_node( `CHANGING` ).
  lr_return = lr_changing->get_child_node( `RETURN` ).
  lr_return->get_attribute( EXPORTING name = 'MESSAGE'
  IMPORTING value = lv_bapi_message ).
  IF lv_bapi_message IS NOT INITIAL.
  DATA:lr_api_controller TYPE REF TO if_wd_controller,
  lr_message_manager TYPE REF TO if_wd_message_manager.
  lr_api_controller ?= wd_this->wd_get_api( ).
  lr_message_manager = lr_api_controller->get_message_manager( ).
  lr_message_manager->report_error_message(
  message_text = lv_bapi_message ).
  ENDIF.
  ENDMETHOD.

The mode of calling the BAPI is encapsulated in the method generated by the wizard in COMPONENTCONTROLLER. All we have to do is to call this method: wd_comp_controller!execute_ybapi_ycandidate_searc( ). When the searched ID doesn’t exist in the database table YPERSON, we show the proper error message stored in the attribute message of the RETURN node. Figure shows the runtime result.

Runtime

Web Service

The Application Server ABAP can be a Web Service provider and a Web Service required. The basic architecture of the Web Service Framework of AS ABAP.

Basic web service framework architecture

The Web Service provider creates the WS and its definition. After this,it can publish the WSDL document to a Universal Description Discovery and Integration (UDDI) service directory, or it can create a direct exchange of WSDL document with the WS client.The Web Service Description Language(WSDL)is a special form of XML that contains all the information required by a client to connect with the Web Service provider and all the required information to programmatically work with the respective service (e.g.number of parameters passed to the service,structure of the returned result,type of the used parameters).

We can store the released Web Services in an UDDI registry. There are many organizations that offer web services we can use for free.Such free Web Services we can find. The web address of the public UDDI service directory for SAP we can find.

With the ABAP Workbench,we have many options to create a Web Service (inside-out type).We can use, for example, a BAPI, a Function Module,a Function Group or an Interface message.

In our case,we want to provide the same search option for our YPERSON database table.A Function Module implementation will be used as a Web Service endpoint.After Function Module implementation,we create the Web Service definition with only a few mouse clicks,we test it and we consume it in the Web Dynpro ABAP,as a model for our WD component.In our case,we don’t focus on the WS security,but we only create a small example required to exemplify how we can consume a Web Service in the Web Dynpro ABAP.

Creating the Web Service

First,we copy the Function Module used to search for a candidate and we slightly modify it(Listing ).To be possible to further transform it into a RFC-enabled Module,in the Attributes tab of the Function Module,we have to activate the option Remote-Enabled Module.

As we have mentioned before, no exception classes can be used in the RFCenabled FunctionModule.This is the reason why,for the purpose of this example, we have chosen to create a non class exception:NO_ID.To manage the exceptions that may occur,we can use the BAPIRET2 structure similar to the latter example.

Listing Implementation of YFM_SEARCH_PERSON

 FUNCTION YFM_SEARCH_PERSON.
 *"------------------------------------------------------------------
 *"*"Local Interface:
 *" IMPORTING
 *" VALUE(ID_CANDIDATE)TYPE YPERSON-ID_PERSON
 *" EXPORTING
 *" VALUE(FIRSTNAME)TYPE YPERSON-FIRSTNAME
 *" VALUE(LASTNAME)TYPE YPERSON-LASTNAME
 *" VALUE(TELEPHONE)TYPE YPERSON-TELEPHONE
 *" VALUE(AGE)TYPE YPERSON-AGE
 *" VALUE(ID_COUNTRY)TYPE YPERSON-ID_COUNTRY
 *" EXCEPTIONS
 *" NO_ID
 *"----------------------------------------------------------------------
 DATA wa_person TYPE yperson.
 SELECT SINGLE firstname lastname telephone age id_country
 INTO CORRESPONDING FIELDS OF wa_person
 FROM yperson
 WHERE id_person EQ id_candidate.
 if sy-subrc <> 0.
 raise no_id.
 endif.
 firstname = wa_person-firstname.
 lastname = wa_person-lastname.
 telephone = wa_person-telephone.
 age = wa_person-age.
 id_country = wa_person-id_country.
 ENDFUNCTION.

Then,we transform our RFC into a Web Service.We have many possibilities to do this,as follows:

Right click on the FM name and,from the contextual menu,we choose Create --> Web Service.
From Function Builder (Transaction SE37), we choose from the menu Utilities --> More Utilities --> Create Web Services.

The Wizard steps are:

Object Type – we can choose the object type; in our case,the Web Service is a service provider.

Object type wizard step

Service Provider - we create a service provider for an existing ABAP Object (Inside Out).

Service provider wizard step

Object type - here,we enter a name and a short description for our Web Service,and we can choose the type of the Endpoint use.

Object type wizard step

Choose Endpoint - here,we can enter the name of the Function Module that we want to use as endpoint for our Web Service.

Choosing the endpoint wizard step

Configure Service - here,we choose an Authorization profile.As we have mentioned above,for the purpose of this example we choose the profile PRF_DT_IF_SEC_NO.

Configuring the service wizard step

Enter Package/Request - here, we have to enter the name of the package Y_WEBDYNPRO and the Transport Request.

Completeit’s the last step in the wizard,where we are informed that the Web Service with the desired name will be generated after pressing the “Complete” button.

The generated service definition

Web Service Configuration

To perform the necessary configuration tasks,we use the SOA Manager,accessible through the SOAMANAGER transaction.By using “Single Service Administration”,we can search for our created WS and configure it(Fig).We can find this option in the tab: “Application and Scenario Communication”.

Searching for our web service

By pressing the“Apply Selection” button,we can see the Details of our Service Definition.Using the“Configurations”tab,we can create a Service and a Service- Endpoint for our Service Definition YWEB_SERVICE.

Details of service definition configurations

Each Service Definition may have more than one Service and,for each Service, we can create more than one Endpoint.Each Service-Endpoint can configure a service in a different way.

Testing the Web Service

After configuring our endpoint, we save it and go into the “Overview”tab.

Details of service definition overview

From here,we choose the link “Open WSDL document for selected binding”and we copy the URL address from the window that appears. By selecting the link “Open Web Service navigator for selected binding”,the Web Service test page opens and we can test our new created Web Service after pressing the “Test” button.

Web service navigator

In case an error occurs,we have to configure the J2EE server access information (the host name and a port number),because the Web Service test page (Web Service Navigator) runs on Java stack. To do this,we can use the same SOAMANAGER transaction --> the tabTechnical Configuration --> the option System Global Settings.

Testing our web service request/response

Consuming the Web Service in Web Dynpro

To be able to consume the created Web Service into the Web Dynpro application, we have to firstly create a Proxy.To create it, we can use the same Wizard as for the Web Service creation.

In this case, the Wizard steps are:
Object type Service Consumer.

Wizard object type step

Select Source offers the possibility to select the source of the WSDL document.

Wizard selected source step

Select Source here,we enter our Web Service’s URL.We can use copy and paste to take this URL from the SOAMANAGER transaction.

Wizard selected source step

Enter Package/Request we have to enter the package name, the prefix and the Workbench Request.Because,in the same time with the generation of the proxy class,there are also generated other development objects (e.g.Dictionary objects,classes and interfaces),it is recommended to generate these objects in a separate package (in our case, the Y_PROXY package).

Wizard enter package/request step

Complete after the last step,theWizard generates the consumer proxy.

The consumer proxy

Generated development objects

Before pressing the RUN button to test our Consumer Proxy, we have to create a logical port by using the SOAMANAGER transaction or the old LPCONFIG transaction.

In the SOAMANAGER transaction,in the same window where we searched for the Web Service,we can search now for a consumer proxy with the external name: “yweb_service”.

Searching for a consumer proxy

By pressing the “Apply Selection” button, we open the field where we can create the Proxy Definition.Into the “Configurations” tab,we can create the Logical Port.In the next step,we have to create the Web Dynpro component to use the created Client Proxy.We create a Web Dynpro component named Y_WS_CONSUMER with a view named V_VIEW and a default window.

By using the Service Call(similar to the “BAPI” example),we can integrate our Client Proxy into our WD application. In this case,we have to use the “Web Service Proxy” option as service type.Then,we have to enter the proxy class name,the public method and the logical port.

Because in the latter example we showed how to use this Wizard, now we are going to show,through this example,how to use the proxy without the Wizard’s help.In case we have more complex structures, it happens that Wizard generates only one attribute instead of a node with attributes.In this case,we have to make manually the adequate modifications.

The V_VIEW view context and the layout are presented. The ID_PERSON attribute is of the YPERSON-ID_PERSON type and shall be used to maintain the ID of the searched competitor. The Person child node has the YPERSON dictionary structure,so here we are going to find the data about the searched competitor: his first name,last name,telephone,age and his country id.In the View Layout,we have inserted the UI elements: Group, InputField,Label and Table.

View context und view layout

When the user presses the Search button,the Framework triggers the event handler method onactionsearch.

The onactionsearch event handler method

 METHOD onactionsearch .
 DATA: lr_node TYPE REF TO if_wd_context_node,
 lr_subnode TYPE REF TO if_wd_context_node,
 ls_subnode TYPE wd_this->element_person,
 lv_id_person TYPE yperson-id_person.
 DATA: obj1 TYPE REF TO ysco_yweb_service,
 obj2 TYPE REF TO cx_ai_system_fault,
 ls_input TYPE ysyfm_search_person,
 ls_output TYPE ysyfm_search_personresponse.
 lr_node = wd_context->get_child_node('SEARCH_PERSON').
 lr_subnode = lr_node->get_child_node('PERSON').
 lr_node->get_attribute( EXPORTING name = 'ID_PERSON'
 IMPORTING value = lv_id_person).
 TRY.
 CREATE OBJECT obj1.
 CATCH cx_ai_system_fault INTO obj2.
 ENDTRY.
 ls_input-id_candidate = lv_id_person.
 TRY.
 CALL METHOD obj1->yfm_search_person
 EXPORTING
 input = ls_input
 IMPORTING
 output = ls_output.
 CATCH cx_ai_system_fault INTO obj2.
 CATCH cx_ai_application_fault .
 ENDTRY.
 IF ls_output IS INITIAL.
 DATA lr_api_controller TYPE REF TO if_wd_controller.
 DATA lr_message_manager TYPE REF TO if_wd_message_manager.
 lr_api_controller ?= wd_this->wd_get_api( ).
 lr_message_manager = lr_api_controller->get_message_manager( ).
 lr_message_manager->report_exception(message_object = obj2).
 ELSE.
 ls_subnode-firstname = ls_output-firstname.
 ls_subnode-lastname = ls_output-lastname.
 ls_subnode-telephone = ls_output-telephone.
 ls_subnode-age = ls_output-age.
 ls_subnode-id_country = ls_output-id_country.
 lr_subnode->set_static_attributes(ls_subnode).
 ENDIF.
 ENDMETHOD.

When we use proxy objects in methods or programs we can use drag and drop to ease the code generation.

Drag and drop for code generation

As we can see,we have declared a reference variable for proxy (obj1 TYPE REF TO ysco_yweb_service) and two local structures to set the input parameter (ls_input TYPE ysyfm_search_person) and to get the response (ls_output TYPE ysyfm_search_personresponse).

After creating the proxy,we call it and pass the response values in the corresponding child node “PERSON”.At runtime,we have.

Runtime

2012-09-22T23:00:00.001-07:00

ALV and Select Options

The following section details and describes the modality to use the standard components ALV and SO as assistance,in creating our own Web Dynpro applications.We start from a simple example,where ALV is used to display the data in a table,and we end by using both components for advanced search and display the searched data, disposing of the extra functionalities offered by ALV (e.g. exporting data in Excel).

SAP List Viewer(ALV) is a tool we c.an use to display data in a two-dimensional table,in a hierarchical-sequential list or in a tree structure.It allows us to use it in a large range of applications,from the classical Dynpros to the Web Dynpro.

In our examples,we use inWeb Dynpro the ALV component SALV_WD_TABLE to display data in a two-dimensional table.

Through “Select Options”,we can benefit of complex searching possibilities.For example,we use the WDR_SELECT_OPTIONS component to create a selection option screen that offers,
in the same time, four standard buttons:Cancel,Reset, Done and Check.

SAP List Viewer

In this subchapter,through some examples, we will meet the SALV_WD_TABLE standard component and its advantages.

Simple ALV Example

We create a WD component that displays all the information about candidates by using the SALV_WD_TABLE,ALV component. To be able to use this component, we have to firstly define a usage. Figure shows the WD component structure and the usage definition

WD component structure

In the COMPONENTCONTROLLER,we create a node PERSON with thedictionary structure YPERSON, Singleton, Cardinality 0...n and supply function SUPPLY_PERSON.

Context node and supply function

View layout

In this case,we have chosen to use a ViewContainerUIElement to embed the Table view of the SALV_WD_TABLE component,but we can embed a view or an interface view directly in a Window if we don’t need additional UI elements.The table view is the central view of an ALV component and represents the container in which the ALV output is displayed.Figure shows the Window structure and the selected Interface View.

Window structure and interface views of the ALV

To be able to create a reverse mapping, we firstly create an interface controller usage.

Interface controller usage

Then,we need to provide the DATA context node with the values from the PERSON context node.

Context mapping

DATA context node must contain the structure and data of the ALV output.The runtime result is presented.

Runtime result

As we have mentioned above,the ALV component offers new capabilities,as follows:

Exporting the data displayed into Microsoft Excel,by using the Export button
Printing a version in PDF format,by using the Print Version button
Simple data filter, by using the Filter option
Complex settings, by using the Settings option

The settings option offers the capability to hide some columns, to create complex searches and complex filters,to change the display mode and to create a print version. We can save the changes we made and assign them to the current user as an initial view.

Settings option

ALV settings

ALV Configuration Model

To configure an ALV output,we can use: table settings, column settings,field settings,standard function settings or application-specific function settings.

By using the transaction SE24,
we can see the structure of the CL_SALV_WD_CONFIG_TABLE. Here, we find the interfaces and their methods to be used to manipulate the ALV output.

CL_SALV_WD_CONFIG_TABLE

Manipulating the ALV Output:Deleting Rows, Hiding Columns,Table Designing,Sorting

We want to manipulate the ALV output to show only five rows, to use the Table Design Alternating to sort table ascending by the id_country field and to hide the first two columns, Client and ID. We use the below example, where we make some changes. We define a usage at the V_VIEW level.

Defining the usage at the View level

The wdDoInit Hook method

  METHOD wddoinit .
  DATA: lr_cmp_usage TYPE REF TO if_wd_component_usage,
  lr_salv_wd_table TYPE REF TO iwci_salv_wd_table,
  lr_table TYPE REF TO cl_salv_wd_config_table,
  lr_field TYPE REF TO cl_salv_wd_field.
  lr_cmp_usage = wd_this->wd_cpuse_alv_usage( ).
  IF lr_cmp_usage->has_active_component( ) IS INITIAL.
  lr_cmp_usage->create_component( ).
  ENDIF.
  lr_salv_wd_table = wd_this->wd_cpifc_alv_usage( ).
  lr_table = lr_salv_wd_table->get_model( ).
  lr_table->if_salv_wd_column_settings~delete_column('MANDT' ).
  lr_table->if_salv_wd_column_settings~delete_column('ID_PERSON').
  lr_table->if_salv_wd_table_settings~set_design(cl_wd_table=>e_designalternating
  ).
  lr_table->if_salv_wd_table_settings~set_visible_row_count(5 ).
  lr_field =
  lr_table->if_salv_wd_field_settings~get_field('ID_COUNTRY').
  lr_field->if_salv_wd_sort~create_sort_rule( ).
  ENDMETHOD.

As we can see,we have used the method GET_MODEL from the interface IWCI_SALV_WD_TABLE.This method has no importing parameters and returns a complete Configuration Model (CL_SALV_WD_CONFIG_TABLE).

The ALV component is partly based on the Table UI element.To set the Table design and the number of visible rows,we use the methods set_design and,respectively, set_visible_row_count from the interface IF_SALV_WD_TABLE_SETTINGS.

If we look at the dynamic programming of a Table UI element, we can see that the property for the Table design alternating is cl_wd_table) e_designalternating, and the property VISIBLE_ROW_COUNT is an integer number(in our case, 5).

To delete the two columns, we use the method delete_column from IF_SALV_WD_COLUMN_SETTINGS interface, and to create asort rule we use the method create_sort_rule from the IF_SALV_WD_INTERFACE interface.
The default sorting rule is:

sort_order = if_salv_wd_c_sort => sort_order_asscending

Runtime

Changing the Cell Editor

As we know,the content of a cell to be displayed is specified by the table cell editor of the column. In the default mode,the table cells are created by using the TextView UI element.

We change the cell editor for the EU Countries column.In this case,we use a linkToURL UI element that opens the web page where we can find all the information about the EU countries. To do this,we need to add some coding at the below example.We need to dynamically create a linkToURL UI element. The Listing shows the additional coding in the wdDoInit Hook method.

Changing the cell edito

  DATA:lr_column TYPE REF TO cl_salv_wd_column,
  lr_link_to_url TYPE REF TO cl_salv_wd_uie_link_to_url.
  lr_column = lr_table->if_salv_wd_column_settings~get_column(
  'ID_COUNTRY').
  CREATE OBJECT lr_link_to_url.
  lr_link_to_url->set_text_fieldname('ID_COUNTRY').
  lr_link_to_url->set_reference(
  lr_column->set_cell_editor(lr_link_to_url).

Runtime

Adding a Header for the ALV Table

For an ALV table,we can add a header,too.To do this,we have to use the method CREATE_HEADER of the IF_SALV_WD_TABLE_SETTINGS interface.

Header for ALV tabl

  DATA:lr_settings_alv_table TYPE REF TO if_salv_wd_table_settings.
  DATA: lr_alv_header TYPE REF TO cl_salv_wd_header.
  lr_settings_alv_table ?= lr_table.
  lr_alv_header = lr_settings_alv_table->get_header( ).
  lr_alv_header->set_text('ALV Header').

Header for ALV table

Setting the Top of List and the End of List for the ALV Output

For an ALV output,we can create a top of list (header text) and an end of list (footer text).As we have seen, the ALV component we have used provides two context nodes,named TOP_OF_LIST and END_OF_LIST.These context nodes hold the data for header and footer. Each context node contains an attribute named CONTENT of CL_SALV_FORM_ELEMENT type.

To be able to access these context nodes from our view V_VIEW, we have to create a context mapping.

Context mapping

Then,we have to define the basic layout and to create the elements. In our case,we have chosen to use the Row type layout,
class CL_SALV_FORM_LAYOUT_ FLOW. We create a text element for the header and a text element for the footer.

Header and footer for an ALV table

  DATA lr_node_top_of_list TYPE REF TO if_wd_context_node.
  DATA lr_node_end_of_list TYPE REF TO if_wd_context_node.
  DATA lr_flow_top TYPE REF TO cl_salv_form_layout_flow.
  DATA lr_flow_end TYPE REF TO cl_salv_form_layout_flow.
  DATA lr_text_top TYPE REF TO cl_salv_form_text.
  DATA lr_text_end TYPE REF TO cl_salv_form_text.
  CREATE OBJECT lr_flow_top.
  lr_text_top = lr_flow_top->create_text(
  position = 1
  text = 'Header Text'
  tooltip = 'Top of list'
  ).
  CREATE OBJECT lr_flow_end.
  lr_text_end = lr_flow_end->create_text(
  position = 1
  text = 'Footer Text'
  tooltip = 'End of list'
  ).
  lr_node_top_of_list = wd_context->get_child_node( 'TOP_OF_LIST').
  lr_node_top_of_list->set_attribute(value = lr_flow_top
  name = 'CONTENT').
  lr_node_end_of_list = wd_context->get_child_node( 'END_OF_LIST ').
  lr_node_end_of_list->set_attribute(value = lr_flow_end
  name = 'CONTENT').
  lr_table->
  if_salv_wd_table_settings~set_top_of_list_visible(value = abap_true).
  lr_table->
  if_salv_wd_table_settings~set_end_of_list_visible value = abap_true).

Runtime

Adding a Self-Defined UI Element to the ALV Toolbar

On the ALV toolbar,we can add our own UI elements. We add a linkToAction UI element.

Adding a linkToAction UI element to the ALV toolbar

  DATA lr_linktoaction TYPE REF TO cl_salv_wd_fe_link_to_action.
   CREATE OBJECT lr_linktoaction.
   lr_linktoaction->set_text('Our self-defined linkToAction').
   DATA linktoaction TYPE REF TO cl_salv_wd_function.
   linktoaction = lr_table->
  if_salv_wd_function_settings~create_function(id ='LTA').
  linktoaction->set_editor(lr_linktoaction).

Runtime

To transform our linkToAction into another UI element,we have to change the editor type from the linkToAction (CL_SALV_WD_FE_LINK_TO_ACTION) into another allowed type.For example,to have a button editor,we have to changee only the class name: CL_SALV_FE_BUTTON.

When the user presses this link,we have to trigger an event handler method.As we can see,we have not defined an action for this link. To know the UI element that was pressed,we use the ON_FUNCTION event.

We create an event handler method named LINKTOACTION_ACTION and we choose the event ON_FUNCTION.

Event handler method for our self-defined linkToAction

If our link with the ID = “LTA” is pressed,a statement block is executed.

Event handler method

Select Options

We create a WD component that offers complex possibilities to search for a candidate.To be able to use these complex search possibilities,we have used the WDR_SELECT_OPTIONS component.

Figure shows the WD component structure and the usage definition.

The WD component structure

We create,in Context view,the node PERSON with the same structure (Cardinality 0...n, dictionary structure YPERSON, Singleton, without supply function).
In View Layout,we have to insert a View Container UIElement required to integrate the interface view WND_SELECTION_SCREEN of the Select Option component.Besides this UI element, we need a Button and a Table UI element.

Context view and view layout

How to define the usage

We create two attributes: M_HANDLER type ref to IF_WD_SELECT_ OPTIONS and M_WD_SELECT_OPTIONS type ref to IWCI_WDR_SELECT_ OPTIONS.

Attributes

We use the wdDoInit Hook method to instantiate the used component WDR_SELECT_OPTIONS, in order to dynamically create a range table and to add a selection screen Field.

The wdDoInit Hook method

 METHOD wddoinit .
 DATA:
 rt_range_table TYPE REF TO data,
 lv_tooltip TYPE string VALUE'Search for id',
 lv_abap_bool TYPE boolean VALUE abap_true,
 lr_componentcontroller TYPE REF TO ig_componentcontroller,
 lr_cmp_usage TYPE REF TO if_wd_component_usage.
 lr_cmp_usage = wd_this->wd_cpuse_select_options( ).
 IF lr_cmp_usage->has_active_component( ) IS INITIAL.
 lr_cmp_usage->create_component( ).
 ENDIF.
 wd_this->m_wd_select_options =
 wd_this->wd_cpifc_select_options( ).
 wd_this->m_handler =
 wd_this->m_wd_select_options->init_selection_screen( ).
 rt_range_table =
 wd_this->m_handler->create_range_table(
 i_typename = 'YIDI').
 wd_this->m_handler->add_selection_field(
 i_id = 'ID_PERSON'
 i_obligatory = lv_abap_bool
 it_result = rt_range_table
 i_tooltip = lv_tooltip
 i_value_help_type = if_wd_value_help_handler=>co_prefix_searchhelp
 i_value_help_id ='YSH_ID_PERSON'
  ).
 ENDMETHOD.

By using the method INIT_SELECTION_SCREEN of the IWCI_WDR_SELECT_OPTIONS interface,we initialize the selection screen.After this, we use the method CREATE_RANGE_TABLE of the IF_WD_SELECT_OPTIONS

interface to dynamically create a Range Table. This method has three importing parameters: I_TYPENAME type STRING,I_LENGTH type I,I_DECIMALS type I and a returning parameter RT_RANGE_TABLE type ref to data.The I_TYPENAME is not optional;we use it to specify the data element for the LOW and HIGH component. The ID_PERSON has the data type YIDI.

Database table YPERSON

A Range Table has four components: SIGN,OPTION,LOW and SCREEN. It can be also created in the ABAP Dictionary,as special type of table types.

The method ADD_SELECTION_FIELD of the IF_WD_SELECT_OPTIONS interface adds an additional Field to the Selection Screen. This method has many parameters, but only one is mandatory – I_ID.We have used the:

i_id parameter,of STRING type,to define the ID of the Selection Field
i_obligatory parameter,of ABAP_BOOL type,to set the mandatory field
it_result parameter,type ref to data, for reference to the Range table
i_tooltip,of STRING type, to create a quick info in a tooltip form
i_value_help_type, of type:IF_WD_VALUE_HELP_HANDLER)CO_PREFIX_NONE
to specify the type of the search help that we want to use
i_value_help_id of WDY_VALUE_HELP_ID type,to specify the name of the search help that we use, or the name of the OVS (Object Value Selector) field ID_PERSON has associated the search helpwith the name YSH_ID_PERSON

When the user presses the Search button,the Framework triggers the event handler method onactionsearch.

The onactionsearch event handler method

  METHOD onactionsearch .
  DATA: l_node TYPE REF TO if_wd_context_node.
  DATA: rt_range_table TYPE REF TO data.
  DATA: it_yperson TYPE TABLE OF yperson.
  FIELD-SYMBOLS: <fs_id_person> TYPE ANY TABLE.
  rt_range_table = wd_this->m_handler->get_range_table_of_sel_field
  i_id = 'ID_PERSON' ).
  ASSIGN rt_range_table->* TO <fs_id_person>.
  CLEAR it_yperson.
  REFRESH it_yperson.
  SELECT * INTO CORRESPONDING FIELDS OF TABLE it_yperson
  FROM yperson
  WHERE id_person IN <fs_id_person>.
  l_node = wd_context->get_child_node(name =`PERSON`).
  l_node->bind_elements(it_yperson).
  ENDMETHOD.

The method GET_RANGE_TABLE_OF_SEL_FIELD of the IF_WD_ SELECT_OPTIONS interface has an importing parameter I_ID, of STRING type,and returns the range table for the Selection Field – rt_range_table generic type data. We define a field symbol typified as ANY TABLE and we generically dereference the data reference variable typed with data into our field symbol,through the dereferencing operator“->*”.

After this, we select all the records that correspond to our search and pass these values in the corresponding attributes of the context node PERSON. We have to embed the interface view WND_SELECTION_SCREEN into the ViewContainerUIElement.Now we are ready to run our application.

Embedding the view interface WND_SELECTION_SCREEN

Runtime

In default mode,Select Option is the interval between two values,but we can also use other Select options.

Selecting options

As we have seen,the component WND_SELECTION_SCREEN offers four buttons to provide four functions:

Cancel
Check
Reset
Execute

We can hide one of these buttons by using the method SET_GLOBAL_OPTIONS of the IF_WD_SELECT_OPTIONS interface.

This method has four mandatory parameters of ABAP_BOOL type.

The SET_GLOBAL_OPTIONS parameters

We want to extend our example,by hiding the buttons CANCEL, RESET,COPY and using the CHECK button to trigger the event handler method on_check.In this case,we don’t use our Search button.We implement the code in the on_check event handler method.

First, we must use,in the wdDoInit Hook method,the SET_GLOBAL_OPTIONS.

The wdDoInit Hook method

  METHOD wddoinit .
  ……………….
  wd_this->m_handler =
  wd_this->m_wd_select_options->init_selection_screen( ).
  wd_this->m_handler->set_global_options(
  i_display_btn_cancel = abap_false
  i_display_btn_check = abap_true
  i_display_btn_reset = abap_false
  i_display_btn_execute = abap_false).
  ……………………
  ENDMETHOD

After this,we create an event handler method named on_check and we register to the ON_CHECK event in the WDR_SELECT_OPTION component.This event is triggered when the user clicks the CHECK button.

Registering to the ON_CHECK event

We copy the entire coding from the onactionsearch event handler method in the on_check event handler method, and then we can run our application.

Runtime

To create more than one selection screens Field,we have to create,into the wdDoInit Hook Method,as many range tables as many screen Fields we need,and then we have to extend the event handler method to be able to select the desired data.

ALV and Select Options

In this case,we use both components: WDR_SELECT_OPTIONS for Select option and SALV_WD_TABLE for ALV .

Used components

We copy the preceding WD component and rename it:Y_ALV_AND_SO.
Here we made only some changes:

Create the context node in the COMPONENTCONTROLLER
Delete the Table UI element and insert a new View Container UI Element required to embed the Table interface view
Define the required usages;
Define the required context mappings;
Check if the instance of the used component ALV_USAGE is made. If it doesn’t exist,we have to create one

View Layout

Window structure

ALV and SO

2012-09-22T22:59:00.006-07:00

Integrating a Web Dynpro Application into the SAP NetWeaver Portal

The present chapter is mainly dedicated to the presentation of the modality to integrate the Web Dynpro applications in the portal,by using the SAP NetWeaver Portal.In the same time, we show how we can communicate between two applications by using the portal eventing (event sender and event receiver).

SAP NetWeaver Portal offers many possibilities to create its content,from Wizards and templates,to applications developed in Web Dynpro ABAP or Web Dynpro Java. Our scope is to integrate into the portal a created Web Dynpro ABAP application named y_ui_contextualpanel. After this, we create a Web Dynpro component that can send a portal event,a Web Dynpro component that can react to a portal event and,finally, we integrate the created applications in the Portal.

To access the portal,we have to navigate to the portal home page, and to use its initial screen to login.

After a successful log-in (with a portal user that has the proper authorizations), we have to connect to the back-end ABAP system, because our Web Dynpro applications are developed in the ABAP system. For the first example, we create an iView required to integrate our application, we create a portal Role and we assign it to the user that needs to access the Web Dynpro application. In order to process the portal events,after we develop the Web Dynpro components and integrate the applications into the two iViews, we create a portal Page, we assign the iViews to our page, the page to a role and the role to the user.

In order to communicate between two applications, even if these applications don’t use the same technologies or run on different systems,we can use the Portal Eventing (event sender and event receiver), with one condition: the applications to be integrated in two portal iViews.

To realize the actual applications,we used a portal user that owns all the required authorizations,including the authorization to create roles and to assign by the created roles.In practice, such authorizations combined for one single user are used only for the testing systems;in the real systems,
the attributions of the administrators(e.g. user administrator,content administrator, system administrator) are very well defined (separated).In the same time,a user that doesn’t own administrative roles can access only those functionalities that have been assigned to him by the administrator.

Creating a Folder

We begin our exercise with the creation of a folder to be used to hold all the subsequently created portal objects. Into the Portal Catalogue,we create a folder named Book.To perform this operation,we have to open the contextual menu (by right-clicking on the folder where we want to create our folder)and to choose New --> Folder.A wizard is open and we can create it.

Creating a new folder

As we can see,we have to enter some information, as follows:

Folder Name – the name of the new created folder
Folder ID – unique identifier for the new created folder
Master Language – the original language for all the portal objects sub sequently created in this folder
Description – brief description of the newly created folder

After saving the information,the Framework generates the created book folder into the Portal Catalogue.In order to set other properties for it,we can use the available wizard.We have to mention that the book folder inherits the permissions from its parent folder.

Connecting to the Back-End ABAP System

In the next step,we connect to the back-end ABAP system. To do this,we create a new System: System Administration --> System Configuration --> System Landscape that opens the System Landscape Editor. Here, we navigate to our book folder and open the contextual menu,by right-clicking. By using New --> System (from template), a Wizard is open and offers the possibility to define a new system through some easy steps.

Creating a new system

In the first wizard step,we have to choose a template.
In the next step, we have to enter general properties, as follows: System Name, System ID, Master Language, Description.

Template selection

General properties

After this,we can open the object editor and configure our system.We start with the Property Category named Web Application Server(Web AS).

Web application server property category

For the next configuration,we navigate to the Connector Property Category required to realize the configuration:

In the next configuration,we go to User Management Property Category required to set the mode the users log-on to our ABAP backend system

User management property category

As Logon Methods,we have used the SAPLOGONTICKET. Each system must have at least one system alias, a name defined by the system administrator,required to refer the specified system.By using the System Aliases tool,we set an alias name for our ABAP backend system.

Creating an alias name for our ABAP system

Now,we are able to test our system configuration by using the Connection test tool.

Testing the connection to the ABAP system

In case a system configuration for the ABAP back-end already exists,we don’t need to create another one.

Creating an iView

An iView (integrated View) represents the smallest element we can create into the SAP NetWeaver Portal.In our case,we use an iView to integrate our Web Dynpro application.To create a new iView into our book folder,we have to navigate to the Content Administration --> Portal Content and,by right-clicking on the folder name, we open the contextual menu (Fig).The Portal Content Studio represents the central environment we can use to create the portal content.

Creating an iView into our book folder

Through a Wizard,we have the possibility to create a new iView, by using:

iView template;
Portal content;
Web Dynpro Java application.

We choose the first option – iView template, because our scope is to integrate the Web Dynpro ABAP application into the portal

In the next Wizard step,we can choose a template from the available template list.Here, we find many templates,e.g.URL iView (used to integrate a Website into the portal),SAP Transaction (iView used to show a SAP transaction into the portal), SAP Web Dynpro iView (required to integrate a Web Dynpro ABAP or Java application)

Selecting a template from the existing template list

In the next step,we have the possibility to provide the iView General Properties,as follows:

iView Name – the iView name displayed in Portal Catalogue, etc.;
iView ID – unique identifier for the created iView;
Master Language – the original language the properties are generated in;
Description – optional description.

iView general properties

In the next Wizard step, we can choose between the integration of a Web Dynpro ABAP application or a Web Dynpro Java application.

Web Dynpro for ABAP iView

In the last step,we enter the parameters of our Web Dynpro ABAP application. When we press the Finish button,the Framework starts to process the provided information and generates the proper iView. We can test our Web Dynpro application by choosing Preview from the contextual menu.

Web Dynpro parameters

Testing the iView

Creating a Role and Role Assignment

By using a role,we can specify which services can be accessed by a user or a group of users,and we can define which content can be seen in the portal by the respective user or user group.In this example, we create a portal role. In the next chapter,we’ll see how we can create a role in the ABAP back-end system to grant delete capability for the database table YPERSON through a Web Dynpro application. In the book folder, we create the role by using the contextual menu New --> Role.

Creating a role

As a result,the Wizard generates a newly created role:

By using the Delta Link concept, we can assign the iView to our new role.

Assigning iView to role, by using the Delta Link concept

As a result, we can see the created assignment:

Then,we assign the created portal role to our test user Gellert.In order to realize this assignation, we access

User Administration --> Identity Management and search for our test user.

Searching for a user

We select the user and, as a result, in the lower part of the screen we can see the details of the selected user.By using the Modify button, we can add the newly created role to the respective user.

Assigning a portal role to the Gellert user

By using the Add button,we attach the role(after selection)to the list of roles assigned to this user.

Running the Application into the Portal

In order to see the top-level navigation and the page defined in the assigned role,we save our changes,we logoff and then we login again.After logging-in,we can see it the upper part of the screen,on the main navigation bar,the new item named CONTEXTUALMENU UI element, corresponding to our newly attached role.

Web Dynpro running application into the portal

Triggering a Portal Event

Web Dynpro through the Portal – Manager offers some methods to be used to trigger events and to react to portal events. To do this, we can use the methods of the IF_WD_PORTAL_INTEGRATION interface,as follows:

FIRE – Trigger portal event;
SUBSCRIBE_EVENT – Register portal event;
UNSUBSCRIBE_EVENT – Delete portal event registration.

For the scope of this example,we re-create our firstly created component; but,in this case, we enter the name in the Web Dynpro component that triggers the portal event and we display the greeting in the second Web Dynpro component that reacts to the portal event.

The Portal Eventing concept is appropriate for communication between applications created by using different technologies.But, through this example, we will create the application that triggers the portal eventing and the application that react to the portal event by using the same technology,

Web Dynpro ABAP.Our purpose is to present the both cases and, depending on the requirements, to choose one of the variants (trigger or receiver)in combination with an application developed into another technology(Web Dynpro Java, Visual Composer, etc.).

Processing portal events

We start with the creation of the Web Dynpro component able to trigger a portal event by using the FIRE method. The structure of this component and the view layout are presented.

Web Dynpro component structure and view layout

In the context view,we have created an attribute named “NAME”, of STRING type.When the user presses the “Event trigger” button, we use the FIRE method to trigger a portal event that will be subsequently passed by the portal to the second iView that has been registered for this event,respective to the second Web Dynpro ABAP application. In this way,the events can be transported between the iViews (Web Dynpro applications or applications that use other technologies).

Listing shows the coding of the onactionevent_trigger event handler method. As we can see,after passing the value of the context attribute into the local variable LV_NAME,we use the FIRE method of the IF_WD_PORTAL_INTEGRATI

onactionevent_trigger event handler method

  METHOD onactionevent_trigger .
  DATA lv_name TYPE string.
  wd_context->get_attribute(EXPORTING
  name = `NAME`
  IMPORTING
  value = lv_name).
  DATA: lr_api_component TYPE REF TO if_wd_component,
  lr_portal_manager TYPE REF TO if_wd_portal_integration.
  lr_api_component = wd_comp_controller->wd_get_api( ).
  lr_portal_manager = lr_api_component->get_portal_manager( ).
  lr_portal_manager->fire(portal_event_namespace = 'sap.example
  portal_event_name = 'person_name'
  portal_event_parameter = lv_name).
  ENDMETHOD.

interface to fire the portal event with the name “person_name”. This method has three importing parameters of STRING type:

PORTAL_EVENT_NAMESPACE – namespace in which the event is stored;
PORTAL_EVENT_NAME – name of the event;
PORTAL_EVENT_PARAMETER – parameter.

These values have to match with the event receiver application. Web Dynpro Wizard offers the required support to work with portal events.

Web Dynpro Wizard and portal manager

Reacting to a Portal Event

Now, we are creating the Web Dynpro application able to react to the event triggered in the first iView in the portal.The structure of this component,the view layout and the context view are presented.

Web Dynpro component structure,view layout and context view

In the context view,we need only the attribute “NAME”, where we pass the parameter value concatenate with a WELCOME string. To be capable to register our Web Dynpro application for a portal event, we have to use the SUBSCRIBE_EVENT method of the same IF_WD_PORTAL_INTEGRATION interface. This method shall be used into the wdDoInit Hook Method.

The wdDoInit Hook method

  METHOD wddoinit .
  DATA lr_api_component TYPE REF TO if_wd_component.
  DATA lr_portal_manager TYPE REF TO if_wd_portal_integration.
  lr_api_component = wd_comp_controller->wd_get_api( ).
  lr_portal_manager = lr_api_component->get_portal_manager( ).
  DATA lr_api_controller TYPE REF TO if_wd_view_controller.
  lr_api_controller ?= wd_this->wd_get_api( ).
  lr_portal_manager->subscribe_event(
  portal_event_namespace = 'sap.example'
  portal_event_name = 'person_name'
  view = lr_api_controller
  action = ‘EVENT_RECEIVER’
  ).
  ENDMETHOD.

The SUBSCRIBE_EVENT method has three parameters of STRING type and one parameter type ref to IF_WD_VIEW_CONTROLLER. As we can see, this method needs to specify not only the namespace,the name of the event and the view, but also the name of the action to be called when the event occurs. We have created an action named “EVENT_RECEIVER”. The event handler method is presented.

The onactionevent_receiver event handler method

  METHOD onactionevent_receiver .
  DATA lv_event_name TYPE string.
  DATA lv_event_parameter TYPE string.
  lv_event_name = wdevent->get_string(name = 'PORTAL_EVENT_NAME').
  IF lv_event_name = 'person_name'.
  lv_event_parameter = wdevent-
  >get_string(name = 'PORTAL_EVENT_PARAMETER').
  CONCATENATE 'WELCOME' lv_event_parameter INTO lv_event_parameter
  SEPARATED BY space.
  wd_context->set_attribute(name = 'NAME'
  value = lv_event_parameter).
  ENDIF.
  ENDMETHOD.

By using the method GET_STRING (parameter: PORTAL_EVENT_NAME), we pass the value of the portal event name into the local variable lv_event_name.Then, in case this local variable has the value “person_name”(our defined even tname),we have to obtain the value of the parameter.

By using the method GET_STRING (parameter: PORTAL_EVENT_PARAMETER), we can pass the parameter of the portal event to the action parameter WDEVENT and to our local variable lv_event_parameter In the last step, we create the greeting and we pass this value in the context attribute.

Creating a Page

In this case,we need the two iViews to appear in the same screen.This is the reason why we use a Page.Into a portal Page,we can insert iViews or other portal Pages and we can set a proper layout.

To create a Page into our book folder, we right-click on the folder name and, from the contextual menu, we choose New --> Page. A Wizard guides us through the required steps to create our first portal Page.In the first step,we have to enter the Page properties .

Page properties Wizard step

In the next step,we have to choose the page template on which to ground the new portal page (here we have chosen “Default Page Template”)and in the last step, before OVERVIEW and SAVE,we choose the layout to be assigned to the page.This layout shows how the content will be arranged.

Page layouts Wizard step

In our book folder,we create two iViews required to integrate our two created Web Dynpro applications.The structure of the book folder.

Book folder structure

After creating iViews Page, all we have to do is to assign the two iViews: Event sender and Event receiver to our portal Page named “Portal event”.To perform this operation,we use the delta link concept firstly applied when we have assigned the iView to the Role. Now we are able to see the Page Content.

Page content

Running the Application that Processes Portal Events

All we have to do is to assign the portal Page to our role (through the delta link concept) and to perform a logoff and a new login into the portal.Figure shows the runtime result.

Runtime

In case we want to differently arrange the display of the two iViews into the Page,we can use the Page Layout.We can also change the layouts by dragging &dropping and rearrange the iViews that define the content.

Page Layout

2012-09-22T22:59:00.003-07:00

Web Dynpro and Authorization

Based on the RBAC (Role Based Access Control) pattern,we are going to present the SAP R/3 role based authorization mode. According to it, a user can dispose of a number of roles,which grants to him/her the authorization to access certain resources from the system. In this respect,we will create the development objects required to grant to the user the possibility to access the records from a database, and we will use,in Web Dynpro ABAP, the declaration AUTHORITYCHECK to verify the current user’s authorization.

For standalone Web Dynpro applications, being not integrated in the portal,the security shall be programmed into the application. For the applications that run into the Portal,we can use the Portal security to authenticate and authorize the access to the application.

The way we can do this depends on specific situations.For example,we can define in the portal the authorization for the content we offer to the user,but we cannot define the authorization for the backend application itself.

This kind of authorization shall be done in back-end, through development objects
as authorization fields,authorization object,etc.To check which functions can be executed by the user or which objects can be accessed by him,in backend,through a Web Dynpro application, we can use statements as AUTHORITY-CHECK.These statements are implemented at the program level in our application or into the model used for our application.

Now,we create a very simple example to show how we can use an Authorization Object into a Web Dynpro component to check the authorization of the current user and to grant access to the Open SQL delete action for our database table YPERSON.

We use a user administrator and a profile administrator to create the object class,the authorization object and the role,and to assign the created role to our test user Gellert.By using our test user, we create the Web Dynpro component and we check his right to perform the desired delete action.

The relationship user – roles – permissions, for our example

An Authorization Object is used to check a user authorization for special activities.Usually,the authorizations are combined into authorization profiles,and these profiles are assigned with a role.Then, a role (single or composite) can be assigned to users, and all the authorization changes affect all the users that have assigned the respective role.

The scope of the present chapter is to offer to the reader a general idea about the authorization concept SAP R/3 and about the modality of using this concept to create secure Web Dynpro applications.This is the reason why we chose an example where we could create all the required development elements, even if in practice this requirement appears only occasionally

SAP offers a large range of authorization objects and templates that we can use and customize according to our requirements.In most cases,to grant access to the tables, we use authorization groups(extended authorization for particular objects)and authorization objects, as: S_TABU_DIS,S_TABU_LINE.
We have already used an authorization group in Chap.11, where we have created table maintenance. In that example, we chose from the authorization group list “&NC&”(no security) and we saw that the authorization object has been predefined as S_TABU_DIS.

We can assign an authorization object,through the menu Utilities --> Assign Authorization Group,to a view and to a transparent table created in the ABAP Dictionary.

Because in our case we offer the capability to delete certain records from the YPERSON table by only one user, the usage of the authorization group has no meaning. Another reason for using the authorization groups in the example was to put forward the basic elements, without entering in the private objects field and,in the same time, to present the authorization field ACTVT we shall meet often during.

working with Web Dynpro applications,when we check the authorization for different activities,with tables.

Role Based Access Control Pattern - RBAC

The Pattern that stays at the basis of the presented concept is the Role Based Access Control pattern,an access control model currently used to develop secure systems.

This pattern was firstly formalised by Ferraiolo and Kuhn, in 1992 (the 15th National Computer Security Conference,1992, Baltimore MD, pages 554–563), in a form that allows the users to access the resources by using roles and permissions, and where the roles can inherit permissions from other roles.

Various forms of Role Based Access Control have been created and implemented in a variety of commercial systems. Hereunder,we present a extended form of the RBAC pattern.

Pattern Name: Role based access control.

Context:Any environment where we need to control the access to resources based on the user’s roles.

Problem: How we can assign rights to users in concordance with their roles,so that each user to have only the authorization required to carry out his responsibilities?

Solution: It is presented a classmodel for the Role Based Access Control

The role based access control pattern Schumacher et al.(2006)

We will explain this concept as regards to the Application Server ABAP. The Class User represents the user that attempts to access the protected object (transactions, programs, services),and the Role class represents the user roles.A role can be a single role or a composite role. The composite role can contain only single roles, and the single role can contain,for example,the logon menu for the user and authorization objects.SAP offers a large number of single roles to be used, but we can also create our own ones. Class Right describes the access type(delete, write, etc.).

Each user can be member of a group or more.Through the Session class,it is implemented the principle of “least privilege”, according to which a user gets,through every session, only the privileges required to perform his responsibilities.

In our example presented in Fig.the profile administrator creates a single role ZTEST_ROLE,assigns to it the authorization object ZTEST_AUTH,maintains the fields and generates the authorization profile. Our test user, Gellert, tries to perform a delete operation in the YPERSON database,but he doesn’t have assigned the ZTEST_ROLE yet.

That’s why he doesn’t have the authorization to perform this operation.Only after the user administrator assigns him the role, he can perform the delete operation for the database records found in the range 004–100. So,we have the separation between the role administrator and the right administrator. Besides this basic division, there are other different scenarios that can be used.

Applications: J2EE, SAP NetWeaver, Oracle, etc.

Authorization Object Class

One or more Authorization Objects shall be assigned to a Class. To create a new class,we can use,from the screen “Maintain Authorization Objects”(transaction SU21),the CREATE button.

Creating an object class

Authorization Object

After creating the class, we can create an Authorization Object directly in the created class or we can firstly create an Authorization Object and then assigning the Object to the created class.

Creating an authorization object

Assigning an Authorization Object to a class

Authorization Fields

An Authorization Object can contain maximum ten authorization fields.These fields can be chosen from the list of the existent ones(activities,actions, etc.) or we can create our own authorization fields.The structure of the Authorization Object named ZTEST_AUTH.

Defining the authorization field

We have chosen to add a field named ACTVT, because we need to check an activity.The possible activities that can be protected are stored in the table TACT that has a 1:CN key relation with the table TACTZ and a txt relationship with the table TACTT.In the table TACTT,there are stored the activities descriptions,and in the table TACTZ there are stored the valid activities for each authorization object.

TACT and some of its related tables

Table TACT

Actions from the TACT table

From the “Create authorization Object” screen,we can use the button “Field Maintenance” or we can use the SU20 transaction to navigate to the list of the authorization fields.

List of authorization fields

Authorization field

Then,we save the new created Field and go back to our Authorization Object. Here,we insert the ZAF_PERSON and,by using the “Permitted activities” from the end of the screen, we select the Delete activity from the activity list.In case we want to re-use this authorization object in the future,we can tick more activities, and we use for our request only the delete activity

Defining the activities

Creating a Single Role and Changing its Authorization Data

After creating the Authorization Object, we create a new single role by using the transaction PFCG.

Creating a new role

After this,we change the authorization data for the new created role.To realize it, we use the “Authorizations” tab,the “Maintain Authorization Data and Generate Profiles” area,and the “Change Authorization Data” button. By using the “Menu” tab,we can define fragments from the user menu that can be seen in SAP Easy Access. Because our authorization doesn’t require new transactions or other objects, we don’t use this tab. By using the “User” tab, we can assign users to the role. We will not use this option,but we will add later the new created role to our test user.

Changing authorization data for a role

In this case, we don’t want to use a Template to generate an authorization profile.This is the reason why we choose, from the pup-up window,the button “Do not select templates”.

Choosing the template window

For the scope of our example,we manually select our authorization object.We use the “Manually” Button and enter the name of the Authorization Object we have just created.

Manual selection of the authorization

After this,we choose the activity found in our list –“DELETE”

Choosing the DELETE activity

Then,we choose the range of IDs where the specified DELETE action is enabled to be performed.

Full authorization for IDs

We generate the authorization profile by using the Generate button .As a result, we can see our profile that offers the authorization to delete data from the database table YPERSON – records from 004 to 100.Creating

Generating the profile

Creating the Web Dynpro Component

Then, we create a WD component named Y_AUTHORIZATION.The component structure is presented.

WD component structure

By using this WD component, we can search for a record in the database table YPERSON and we can delete a record in case the authorization enabled us to perform the desired activity. The view layout and view context structure are presented.

Checking the Authorization of the Current User

When the user presses the Delete button, the Framework triggers the event handler method onactiondelete.

Context structure and view layout

The onactiondelete event handler method

  METHOD onactiondelete.
  DATA: lt_candidate TYPE TABLE OF yperson,
  lr_node TYPE REF TO if_wd_context_node,
  lv_id_person TYPE yidi.
  DATA lr_api_controller TYPE REF TO if_wd_controller.
  DATA lr_message_manager TYPE REF TO if_wd_message_manager.
  lr_api_controller ?= wd_this->wd_get_api( ).
  lr_message_manager = lr_api_controller->get_message_manager( ).
  lr_node = wd_context->get_child_node('DELETE').
  lr_node->get_attribute(EXPORTING name = 'ID_PERSON'
  IMPORTING value = lv_id_person).
  AUTHORITY-CHECK OBJECT 'ZTEST_AUTH'
  ID'ACTVT' FIELD '06'
  ID'ZAF_PERSON' FIELD lv_id_person.
  IF sy-subrc EQ 0.
  DELETE FROM yperson WHERE id_person = lv_id_person.
  IF sy-subrc EQ 0.
  lr_message_manager->report_t100_message(
  msgid = 'YCL_T100_MSG'
  msgno = '004'
  msgty = 'S').
  ENDIF.
  ELSE.
  lr_message_manager->report_t100_message(
  msgid ='YCL_T100_MSG'
  msgno ='003'
  msgty ='E'
  ).
  ENDIF.
  ENDMETHOD.

As we can see,we have implemented an authorization check before performing the delete action.

AUTHORITY-CHECK OBJECT ’ZTEST_AUTH’
ID ‘ACTVT’ FIELD ‘06’
ID ‘ZAF_PERSON’ FIELD lv_id_person. In this way, we check the authorization of the current user.

We can have minimum one and maximum ten authorization fields with specified IDs. In this case,we have the ACTVT and our own created authorization field ZAF_PERSON. For each authorization field, we can specify a value to be checked or we can use the additional DUMMY to avoid checking the respective field.

The check is successful only if all the conditions are fulfilled: the field ACTVT (Activity) with the permissible value 06 (Delete) AND the field “ZAF_PERSON” whose permissible value is one of the IDs from 004 to 100.If the check is successful,the sy-subrc = 0;otherwise, it is set to a value not equal with 0:

4 – Authorization check not successful.
12 – No authorization was found for the authorization object.
24 – Incorrect authorization fields or an incorrect number of authorization fields was found.

In the Message Class YCL_T100_MSG, we have defined two messages with the IDs 003 and 004,required to show the success message,or the error message in case the action is not allowed. We have created a role ZTEST_ROLE, but we haven’t assigned it to our user.

This is the reason why, at runtime, we are not allowed to delete the record with the ID “004”. Figure shows the User Interface at runtime.

Runtime

In case we don’t have a certain authorization, as developer for fulfilling the required tasks,we can use the transaction SU53 to find what authorization is missing and to inform the administrator about it.After receiving an exception message caused by a failed authorization,we have to use the specified transaction and to make a screenshot for the administrator.For example,if we try to use the transaction SE11 and we don’t have the proper authorization, in the transaction SU53 we will see the object class, the authorization object and the authorization field we need.The transaction ST01 offers the possibility to create a system trace to find the missing authorization objects.

The missing authorization check

Assigning the User-Role and Running the Application

To be able to perform the delete action, we have to assign the created role to the user that needs to perform this action (In our case, the test user Gellert). By using thetransaction SU01, we have the possibility to change user master records (e.g. change,lock or unlock,change this password),to delete user master records or to create a new user (directly or by copying an existing one).

User maintenance

In the tab “Roles”, we can assign our created role ZTEST_ROLE to the test user.

Assigning the role “ZTEST_ROLE” to our test user

We run again our Web Dynpro application.The authorization rights become effective and our test user can perform the delete action for the records 004–100 from the database table YPERSON.

The user is allowed to delete data

In case we are trying to delete a record not included in the range 004–100,we get the same “Not Authorized” message.In this case, the authorization check is performed and the system compares the values entered by the administrator in the authorization profile with the values required by the program.As a result,the check is not successful and he is not allowed to perform this task.

Deleting a record not included in the range 004–100

Other authorization objects, which we often check,are:
S_TCODE – to check the authorization to run a transaction
S_PROGRAM – to check the authorization to run a program
S_RFC – to check the authorization to run a RFC
S_TABU_DIS – for table maintenance

2012-09-22T22:59:00.001-07:00

Web Dynpro Mind Map

The main focus of this chapter is the presentation of the Mind Map created on the basis of the elements described in this book. It can be of a real help in summarizing the knowledge,facilitating the learning of the Web Dynpro.

Tony Buzan is considered the parent of Mind Map. A Mind Map is a diagram used to structure ideas that assist people in many activity fields.

The Mind Maps are mostly used to take notes during meetings or at school,as a good method to summarize the knowledge or to prepare a presentation. More details about the advantages of using Mind Map to learn Web Dynpro can be found in the article: “The Advantages of using Mind Map for learning Web Dynpro” (Cristea et al).

Creating a Mind Map

To create a Mind Map, we start from a central point, in our case the Web Dynpro ABAP.This is the main subject of the Mind Map, and all the subtopics connected through lines with this one represent the key-words or, respectively,the main ideas.

In this case, we have created a Mind Map based on the subjects presented in this book.from the UI elements to the Hook Methods and component re-use, this wellstructured Mind Map helps us to learn faster the Web Dynpro ABAP and,in the same time,to imprint in mind the main elements required to learn this technology. In Fig is presented the Mind Map created to facilitate the learning of Web Dynpro ABAP.

For each topic or subtopic,we can attach one or more files containing details regarding the respective subject,examples, images,links,etc.

For example,if we look at the UI elements, we can easily see that the UI elements to be used with Web Dynpro are divided in certain categories.In this book, we present the following categories: Layout, Action, Selection, Complex, Graphic and Integration. Each of these categories has some corresponding UI elements.In our case,we introduced only those IU elements we used in this book, but,as mentioned above, they could very easily be extended.

To create Mind Maps, we find a large range of software on the market. iMindMap is considered the World’s Official Mind Mapping software endorsed by Tony Buzan. To create this Mind Map,we used Mindjet MindManager that can be downloaded (and tested, as a trial version gratuity).

Web Dynpro ABAP Mind Map

2012-09-22T22:54:00.004-07:00

ABAP BASICS PART-1

Some Facts about SAP

After the Internet, SAP R/3 is one of the hottest topics in the computer industry and the company that developed it. It is targeted to most industries, manufacturing, retail, oil & gas, pharmaceutical, banking, insurance, telecommunication, Transport, chemical and so on. All major hardware Vendors were fully engaged to partner with SAP: AT&T, BULL, Compaq, IBM, Sun have supported and certified R/3 platform.

SAP has list of major consultants all over the world like Anderson Consulting, Price Waterhouse – Cooper & Lybrand, Ernst & Young, KPMG and many more.

The company behind R/3 is SAP AG, founded by four former IBM employees in 1972. The company’s headquarters are in Walldorf, a small German town. The company name, SAP stands for SYSTEMS, APPLICATIONS and PRODUCTS in data processing. In 1992 R/3 was introduced and in 1995 SAP AG was ranked fifth among independent software vendors. One of the reasons for SAP’s success is that since it is a standard package, it can be configured in multiple areas and adapted to specific need of a company. Today, more than 21,600 customers in over 120 countries run more than 69,700 installations of SAP® software. With subsidiaries in more than 50 countries, the company is listed on several exchanges, including the Frankfurt stock exchange and NYSE under the symbol “SAP”.

SAP has two main products in the business software market, Mainframe system R/2 and Client-server R/3. Both are targeted to business application solutions. Here R indicates REAL TIME.

R/2 is SAP AG mainframe software that runs on IBM, Siemens and other compatible equipment. This type of solution cannot be open, but with ALE technology, R/2 can be linked with R/3 system and share data. This system is mainly targeted at enterprises with data-intensive and centralized industries.

R/3 is the product that has really placed SAP AG as the leader in the country. This complex Client/server system is core of our course. The global acceptance of R/3 is not only because it caters all complex needs of business but also this international acceptance is because of R/3’s international applicability. For SAP this does not mean having software available in different languages, but also covering currency, taxes, Legal practice concerning HR, Import/export regulations. SAP also values its customers and it is shown by the comprehensive set of quality services put by SAP to help customers during the process of implementing and supporting the R/3 systems. These services include product information; training, installation and upgrade service like:

OSS: Online Service System is one of the primary sources of service and support provided by SAP. With OSS, customers can search the SAP information database and find solutions for errors and problems with R/3 systems. You can also submit your problems to SAP.

Consulting Service: with remote consulting service customer receives immediate and updated technical support and answers to their questions.

Maintenance service: This is the basic and most common type of support for customers in technical support and answers to their questions.

Information Service: These are the various information sources for receiving detailed information about the R/3 system, marketing brochures, system documentation, training information and many more things.

Preventive services: The primary one is the Early Watch Service, which ensures successful and efficient installation of the R/3 system in all phases. This service makes regular/performance checks and analyzes the system to identify potential problems, help system managers and SAP administrators to tune the system. Soon after the Early Watch session, SAP sends the customer a report with the result of the analysis and recommendations for avoiding potential problems such as database becoming full.

So overall SAP R/3 is an open client/server software system, designed to manage business information needs of an entire enterprise. The whole dataflow of SAP R/3 works in an integrated way, which means the data needs to be entered just once and the system automatically updates other logically related data.

WORKING WITH R/3 system

The SAP R/3 presentation interface behaves very similarly to any other typical window application and is also known as SAPGUI. The first screen that you come across in R/3 system is SAP logon screen.

SAP R/3 logon Screen

This is the first screen that appears when you use SAP logon utility. It has four fields: the client, the user, the password and the language.

Client: Here you enter the client number. The client is group of users who has similar rights. It can be group of users in a business entity or a whole business entity or a whole company.

¨ User: The name of the SAP user identification. Users of the SAP system are client-specific, which means that user belonging to one client is valid to only the particular client.

¨ Password: It is the password that has been assigned by the system administrator.

¨ Language: SAP R/3 system supports multinational language on the same system at the same time, which is very useful for multinational companies with different branches in several countries and possibly using different languages.

After entering all the fields press ENTER key and system will take you to MAIN MENU screen.

User might get different screens when he logs on, depending upon default settings of the user master record i.e., if user is DEVELOPER then the screen which he often works on is editor screen and he can go directly to this screen, if system administrator sets this screen for the user.

Main features of any R/3 window are as follows:

¨ R/3 standard window elements behave exactly the same, as any other standard window application would, like minimizing a screen, setting the active window etc.

¨ From TOP to BOTTOM, R/3 window can contain typical elements such as check boxes, push buttons, input fields and following elements:

¨ Menu bar is the first element of the every R/3 window. It contains the menu item corresponding to the particular R/3 application. The two menu options SYSTEM and HELP are always present in every R/3 window. SYSTEM menu option contains all utilities and functions, and is available to user at all the times. The HELP menu contains all the available options for the different types and methods of obtaining online help in the system.

¨ Standard tool bar. The second R/3 window element is present in every R/3 window. It is nothing but a collection of icons, which perform common functions like saving the object, exit etc. The various icons on std. Tool bar are as follows (from left to right):

¨ Application tool bar: The next part of the screen contains icons most commonly used in that particular task or transaction.

¨ Status bar is the bottom line of the screen and usually shows errors or information messages to the user. It also includes other information such as system id, session number, client, server name and the response time.

In between application tool bar and status bar you have working area, which is different for different screens.

Logging Off

User can log off the R/3 system from any screen. There are three ways of logging off the R/3 system, which are as follows:

¨ From the Menu bar choose SYSTEM ® LOG OFF. In this case, you get the log off dialog box, which informs the user that any data not saved will be lost if continuing with the log off procedure.

¨ Use/NEX transaction code in the command field. This is dangerous, since it does not ask if you want to save the data.

¨ Clicking on the EXIT button on the R/3 initial screen.

Using Transaction Code

The R/3 system provides an alternative and efficient way of selecting menu options for moving around the tasks and functions of the SAP system by using transaction code directly in the command field.

When moving with transaction, you can go to any part of the system by merely typing a transaction code in the command field, provided you have authorization for that. That transaction code is the four-character code associated with any task. By typing the transaction code and pressing ENTER key, the system takes you directly to the initial screen for transaction. Whenever any transaction code is entered in the command field, it gets stored in the buffer memory. If you click on drop down arrow, system displays list of transaction code already entered and you can select from this list or enter new one. There are almost twelve thousand and ninety four transactions in SAP. For every task, transaction code is associated and it can be found by

¨ SYSTEM ® STATUS

Status window is popped up which contains the transaction code in the trans field.

¨ Through DYNAMIC MENU. It gives the list of tasks. If you click on the top line of the application areas and pressing the search and search next button will give you the transaction code. /N will take you to initial screen of R/3

Important transaction codes, which you will be using often, are:

Editors

SE37 Function Builder
SE38 ABAP/4 Editor
SE41 Menu Painter
SE51 Screen Painter
SE71 Form Painter

Dictionary

SE11 Initial ABAP/4 dictionary maintain screen.

Browsers

· SE80 Object browser.

SE16 Data browser.

Testing Tools

SE30 Runtime Analysis
ST05 SQL Trace

Getting help in the R/3 system

R/3 includes many possibilities to get online help for almost every element of the system, users can get help for entire application, for specific function, for definitions of various terms used in SAP, i.e., Glossary, messages, screens, fields etc.

You obtain HELP by using any of the following options:

¨ Help function from the R/3 window, which is compulsory menu item of every R/3 window.

¨ ? Icon of standard tool bar.

¨ F1 function key.

The SAP system provides help on most fields that appear on the R/3 system. To get help on particular field, position the cursor over it and press help button or F1 function key.

Another way in which R/3 system provides help is when system displays error messages in the status bar. Double clicking on the status bar shows additional information about the message.

Working with R/3 user sessions

A very important feature provided by SAP. In R/3 system you can work with more than one task at any given point of time, by means of opening sessions. You can call sessions as independent R/3 window where you can perform other tasks.

By default, a user can open NINE sessions simultaneously and can work or move around with all sessions at the same time. Sessions can be closed at any time, without having to log off the system.

User can create new sessions from anywhere as CREATE SESSION comes under SYSTEM menu which is available in every R/3 window.

SYSTEM ® CREATE SESSION Or /O in command field

This will open a new session or window and will place it in front of all other windows.

To move among sessions

¨ Just mouse click on any part of the R/3 window to make that session active.

¨ Combination of ALT + TAB key.

R/3 Architecture

The overall R/3 system includes the following components:

The UPPER layer, the functional layer contains the different business application. The integration of all application depends upon basis system. Applications are developed in ABAP/4 Lang. (Advanced Business Application – the 4^th generation language)

The R/3 basis software is the set of programs and tools, which interfaces with the operating, system, the underlying database, protocols and the presentation interface. This layer enables all the application to work exactly the same way no matter what operating system or database, the system is installed on. It is an independent layer and ensures the integration of all modules. Besides all these specific jobs, BASIS system also contains following components and thus provides more additional features.

¨ ABAP/4 development workbench, which in turn includes many features like repository, data dictionary, workbench organizer, which will be discussed in later part of the topics.

¨ ABAP/4 language, system administrative tools, all these components are used to control, tune the R/3 system.

¨ Spool system manages the formatting of data for printing and passing it to the host spool system.

¨ Mail system you can send and receive mail from the outside world (Internet).

¨ Communication interface to external system from R/3 system: Manages communication at the OS level (TCP/IP), at the database level & between applications too. (RFC, EDI, and ALE)

¨ Database interface – This component supports different Relational databases from different vendors. The main task of database interface is to convert the SQL request from the SAP development environment to the database’s own SQL environment.

¨ Background processing with this facility you can submit your program for background execution.

BASIS system contains the layered components that facilitate the development of client/server architecture.

Client / Server architecture

Client/Server architecture is mainly a software concept that includes a set of service providers and service requesters. The set of computers acts as service providers and is called as server. The sets of software component, which act as service requester, are called as client.

In the client/server architecture, the database acts like a library clerk retrieving books from the shelf. The user programs have to request database for the data instead of searching for the data themselves. This way there is no risk of the users putting the data out of order. If the desired data is in use, the database makes the user wait until it is free.

The major advantage of the client/server architecture is that the server is available for a number of clients and there is distribution of work between the clients and the server. The user directs the request to the client; the client in turn understands the user’s request and redirects the request to the server. The server retrieves the data, gives it to client.

You can have client and server on the same machine or on different machines. Each client has a corresponding process inside the server.

One of the most used client/server configurations with the R/3 system is the 3 tiered architecture, which separates a system’s computer into 3 functional groups:

Three tier architecture of R/3

Database Server

Application Server

Presentation Server

(Unlike normal Client/server architecture where you have only two layers i.e., client and server.)

Communication among the 3 tiers is accomplished by standard protocol services like TCP/IP or CPIC (Common Programming Interface Communication).

In above case database server stores the data centrally. Basically contains database engine and associated processes. The database layers contain the database system used by all servers.

Application server contains software components to run the program. It contains a SAP kernel, which can run ABAP/4 program.

The presentation server is your client through which you send your request to application server. It is also called as SAP graphical user interfaces known as SAPGUI and is available in windows 3.1, Windows NT, Windows 95, and Macintosh. They all look similar whatever underlying system they are running on.

The SAPGUI includes all graphical capabilities of window interface with menu bars, tool bars, focus property, and the entire mouse clicking operations.

The R/3 system is open system in the sense that it can run on any operating system or any database and any communication technology. It means that:

¨ R/3 system can run on any operating system platform such as UNIX, NT, 95, AS/400.

¨ It supports various RDBMS such as SQL server, Oracle, Informix, DB2.

¨ Standard GUIs supported by R/3 are Windows 95, NT, Windows 3.1, and Macintosh.

¨ SAP can use standard communication protocols TCP/IP, CPIC, OSF/DCE/DME for network.

ABAP/4 Development Workbench

The development environment of SAP R/3 system is fully integrated set of various development tools, data dictionary, and programming language. Full integration of all components means that changes in any part have a direct and immediate effect on all application using those components.

The screen of ABAP/4 development workbench looks like

Tools of ABAP/4 workbench

For programming:

¨ ABAP/4 dictionary Defining, maintaining and storing the data dictionary of the SAP R/3 system stores all the dictionary objects including tables relationship and Help information. Transaction code for this is SE11.

¨ ABAP/4 editor Creating and maintaining the ABAP/4 program, editing function modules, logical database, and screens. Transaction code is SE38.

¨ Function library Defining and maintaining the ABAP/4 function modules. Transaction code is SE37.

¨ Screen painter Designing and maintaining the screens in transaction. Transaction Code is SE51.

¨ Menu painter Designing and maintaining the means for graphical user interface. Transaction code SE41.

For Navigating:

¨ Object browser Managing and organizing the development object in a hierarchical form. Transaction code is SE80.

¨ ABAP/4 repository information Navigating and searching for the dictionary Objects, development objects and relationship objects. Transaction code SE84.

¨ Data browser Navigating in the data tables of the database. Transaction code is SE 16.

For Debugging:

¨ SOL trace tracking the database calls from the system transaction and programs. Transaction code is ST05.

¨ Debugger Stopping the program and analyzing the results of the execution of every program statement.

¨ Runtime Analysis Analyzing the performance the system calls Transaction code is SE30

For Organizing:

¨ Workbench organizer controlling and keeping track of development work and team related development projects and managing versions of development objects. Transaction code is SE09.

¨ Transport system performing and managing the transport of development object across different system. Transaction code is SE01

Data Dictionary

The ABAP/4dictionary is central workbench repository utility providing the data definition and the information relationship that are later used in all the business application within R/3

The ABAP/4 dictionary can be seen as a logical representation or a superior layer over the physical underlying database. This database must support the relational data model. This model is strictly followed by data dictionary.

About Data Dictionary

A Data dictionary in computing terms is the source of information in which system data is defined. The data dictionary is the centralized and structured source of information for business applications. You can say that it is core of a well-structured development environment.

The elements that make up a dictionary are known as metadata. Metadata is the term for the data whose function is to describe other data. Data in dictionary is not the actual data like emp. name or emp. address but rather a type of data whose function is to define the properties of the data such as type, length, and relationship.

Advantages

Advantage of using data dictionary is avoiding inconsistencies when defining data type that will later be used in different applications. This avoids redundancies.

When a type is defined in the dictionary, it is available to any program in the application. A change in the definition of a type of data in the dictionary automatically affects any other data or program, which has this data.

Again, data dictionary is a fast and efficient way to answer questions such as which entries exist in a table of the database, what the structure of table is.

Activation of dictionary objects

For a dictionary object to be effective at runtime, that is, for a dictionary object to be available for use within a program, transaction, and so on, it must be in active status. For objects to become active, R/3 includes the ACTIVATION function.

When a table or aggregated object is activated, it is placed at the disposal of the system as a runtime object in a way that makes it available quickly for the application program to access relevant information of new activated objects.

When a dictionary object is modified, that means that the object previously existed and activated. You need to reactivate the object after modification.

When mass activation is performed massively, it might take a quite a long time. Then it should be in the background system. This type of activation is known as background activation.

The ABAP/4 Data dictionary is the central component of ABAP/4 repository. A Data dictionary is centralized and structured source of information for business application. The ABAP/4 dictionary is the core of the R/3 development system. It is the source of every definition, within R/3, from the very basic domain to the company data model. It is totally integrated with other tools of the development environment like screen painter, menu painter, and editor.

Some of the main available functions in the ABAP/4 dictionary are as follows:

¨ Add, delete, modify, and manage the definition of the dictionary data.

¨ Preserve the data integrity.

¨ Be the central source of information e.g. from the dictionary you get the information about the defined relationship between two tables or even the directory tells whether table is active or empty.

¨ It also permits documentation of system data.

In the R/3 system instead of working with original objects, you work with internal representation of objects. With this type of operation the system performance is enhanced and has the advantage that the development tools, screen interpreters always access current data.

When any of the data dictionary objects are used in other parts of the development workbench for example, in program, programmer only has to enter a table name or field name. The system automatically knows all the properties and information of the field.

To call ABAP/4 dictionary, from the main menu, Tools ® ABAP/4 workbench ® data dictionary or enter transaction SE11.

Data dictionary objects:

¨ Table: is a 2D data matrix containing rows and columns. Rows contain data while column indicates fields. Table can contain 0 or multiple rows.

¨ Structure: is a skeletal view of a table. It contains the definition of columns and don’t have any contents. Structure is generally a template based on which a table is created. The basic difference between structure and table is that the structure does not exist at the underlying database system level. Structure exists as definition in the dictionary.

¨ Views: A view is an imaginary table. It contains data, which is really stored in other tables. The contents for the view are dynamically generated when called from program.

¨ Data element: is definition of the properties and type for a table field. It is an intermediate object between the object type domain and the table field. A field in R/3 system is always associated with a data element, which at the same time is related to domain.

¨ Domain: is formal definition of the data type from a technical point of view. It sets the attributes such as data type, length, possible value range and so on.

¨ Lock objects: These types of objects are used for locking the access to database records in table. This mechanism is used to enforce data integrity that is two users cannot update the same data at the same time. With lock objects you can lock table-field or whole table.

¨ Search Help Objects: , which gives list of possible values for either primary keys or non-primary keys.

Tables in ABAP/4 dictionary

Tables are the basic objects in R/3 application. There are almost 8000 tables in R/3 system. Following types of tables are available

Transparent tables
Pool tables
Cluster tables

From user point of view, all tables are used to store data whatever be the type of table. There is no difference in the behavior or operation of these tables. All of them can be managed by using standard OPEN SQL. However from an administrator point of view transparent table do exists with the same structure both in the dictionary as well as in the database, exactly with the same data and fields. While other two are not transparent in the sense that they are not manageable directly using database system tools. You can access these tables in R/3 environment from the ABAP/4 dictionary. You cannot use native SQL on these tables. Pool or cluster tables are logical tables, which are arranged as records of transparent table.

A table is made up of rows and columns. When the table is created, its columns are named; data type is supplied for each column. There can be only one data value in each column of each row in a table. Record or as it is called in different RDBMS is nothing but group of fields. While a column is a field of a table, a table is an indexed file. The main index is called as primary key, which can be a single field or combination of keys or fields. A primary key can be defined as a field, which indefinites a single unique record of the table. A table cannot have record with duplicate primary key.

In any RDBMS, tables are related to each other. But to relate table to each other it is necessary that one of the tables contain some information of other table. Mostly tables are related to each other through primary keys. The primary key of one table, if it exists in other table then it is called foreign key. This type of database management system means that there is some redundancy of data. But using normalization procedures available can minimize it. One of the most important functions of foreign key is to ensure data integrity. For example say you have EMP table, which has fields: emp. no., emp.name, dept.code, salary and you have DEPT tables, which has dept.code and dept.desc. Then in DEPT table dept.code is primary key while dept.code in EMP table is foreign key. If you enter dept.code for particular employee in EMP table the dept.code should exist in DEPT table. System will check the value for dept.code in DEPT table, and if does not exist then will flash error. In this case DEPT is called check table while EMP is foreign key table.

Creation of table

Steps to create a table

¨ Create domain

¨ Create data element

¨ Create actual table

Creating Domain

Domain as already explained defines the technical properties of a field such as type and value range. A domain can be created from initial screen of data dictionary by clicking on create and clicking domain Radiobutton. Parameters to be passed are:

Data type: Where you need to enter the data type available in SAP.

Field length: Field length is the number of valid position.

Value table: Name of a table to be entered. The fields referring to this domain may only assume values contained in the value table.

Once the domain is created, save and activate it, so that it can be used for further objects (basic rule of dictionary).

Creating Data Element

The second step of table creation is to create data element. It assigns a certain meaning to the table field, which are defined using that data element. A Data element always needs to be defined over a domain and field is always defined over a data element. This allows all fields with same technical properties to use the same data element.

Parameters to be passed when creating a data element:

Short text: Mandatory field.

Domain: A mandatory field. If the domain does not exist, SAP can take you directly to domain definition screen.

Text element: You can enter description is short or long text for the field. This text is used when

entering data for these fields.

Save and activate.

Creation of actual table

Parameters to be passed for creation of table:

Short description: Mandatory field.

Delivery class: As per User Requirement

Table fields: Specify whether primary key. In this case it is mandatory to enter data element.

Data class: Establishes the physical area of the database.

Size category: Allows you to specify estimated space requirement for the table.

Further down under buffering square box, the system allows specifying whether table is going to be buffered. When a table is buffered, it is loaded into the table buffer from the application server memory and it will remain there until you switch off or reboot system.

If the table is to be buffered, you need to specify the type of buffering. Full is for entire table while partial is for only those records which are being accessed.

Once the table is created, it has to be generated or activated to be able to access by other objects like programs.

General Introduction to ABAP/4

SAP originally developed the programming language ABAP/4 (Advanced Business Application Programming) for internal use to provide best working conditions for developers. SAP constantly improves the language to adapt to the increasing requirements of the business applications. At present, ABAP/4 is the only tool for developing applications at SAP.

SAP customers use ABAP/4 for their own developments. The ABAP/4 Development Workbench contains all tools you need to create and maintain ABAP/4 programs. ABAP/4 programs are not complied but generated. During generation, the system creates a so-called runtime object from the source code and the program attributes. When you start the program, the system executes the runtime object.

ABAP/4, a fourth generation language, contains all usual control structures and modularizing concepts for structured programming. The three parts of the ABAP/4 language are:

Structure and execution of ABAP/4 programs

Basic language elements

Programming reports

Programming dialogs

Structure and execution of ABAP/4 programs are essentially different from entirely sequential programming languages such as FORTRAN, PASCAL, or C. ABAP/4 instead shares certain similarities with modular, event-orient programming languages such as Visual Basic or JAVA.

The two most important statements concerning structure and execution are:

An ABAP/4 program has a modular structure.

For execution, you need a special runtime environment.

This means, that ABAP/4 source texts always consist of a collection of program modules (one single module in the easiest case) or the sequential set of statements. The individual program modules consist of sequential elements. The set of statements of a program module is also called processing block.

The runtime environment is responsible for calling the individual program modules one after the other. The runtime environment is the ABAP/4 processor, which can communicate with the list processor or the dialog processor, depending on the program type.

Program flow within the individual processing blocks is sequential, as you know it from other sequential programming languages (for example, FORTRAN, PASCAL and C). Within the processing blocks, you can use the general control statements for the program flow, such as IF, DOES, WHILE, ABAP/4 does not contain GOTO elements.

We mainly use programs that consist of a single processing block only and, therefore, behave most likely like programs of other sequential programming languages. For programming applications, the entirely sequential concept is not sufficient. SAP distinguishes between two general types of application programs:

Reports: You use reports to read databases and represent the results in lists. Reports are collections of processing blocks that the system calls depending on events.

Dialog programs: You can dialog programs to execute transactions, which usually read and change databases. Dialog programs are collections of processing blocks (so-called module pools) that are called by a screen flow logic. The third part of the User’s Guide describes dialog programming in detail.

Reports can call dialog programs and vice versa.

In its easiest version, an ABAP/4 program contains one single sequential piece of coding and, thus, one single processing block.

Characteristics of the ABAP/4 programming languages

¨ Declarative elements for declaring data of different type and structures.

¨ Operational elements for manipulating data.

¨ Control elements to control processing flow.

¨ ABAP/4 is multi-lingual. Text elements such as titles, headings, and text body are stored separately, independent of the program codes. Thus, you can change, translate, and maintain text elements without having no adapt the coding.

¨ ABAP/4 supports business-related data types and operations. You can execute calculations using special data and time fields. The system automatically executes all necessary type conversions.

¨ ABAP/4 provides a number of functions for processing character strings.

¨ ABAP/4 allows you to define and call subroutines. You can even call subroutines of other programs. There are different ways of how to pass parameters to and from the Subroutines.

¨ ABAP/4 contains a special type of subroutine, called function module. Function modules are stored and maintained in a central library. They have clearly defined data interfaces to the calling program. You can test function modules in a stand-alone mode independent of the calling program.

¨ ABAP/4 contains an SQL subset called OPEN SQL. OPEN SQL allows you to read and change database tables independent of the underlying database system.

¨ ABAP/4 allows you to define and process internal tables that exist only for the execution period of the program. Internal tables efficiently support the usage of database tables and allow you to implement complex data structures in a program.

¨ ABAP/4 allows you to store data not only in databases but also as sequential files on application and presentation servers.

REPORTS

¨ Reports are ABAP/4 programs.

¨ You use reports to evaluation data from database tables. The results of such an evaluation can be displayed on the screen or printed form.

¨ Reports are stand-alone programs.

¨ The user can execute reports directly via the program name, for example, by choosing System ® Utilities ® Reporting.

¨ A report program contains a collection of processing blocks for different events that are always triggered externally. In a report, you can react on events by programming the corresponding processing blocks or ignore the events by not writing the corresponding processing blocks. A report itself never creates events.

¨ Reports can use logical databases or select statements defined by developer.

¨ For each application, SAP supplies logical databases. Or you can easily create logical database yourself.

¨ Event control of a report corresponds to a certain scheme:

When a report is executed, the ABAP/4 processor creates together with the logical database used (if any) a sequence of certain events for which you can program processing blocks. The chronology of the events is (more or less)

Steps involved in creating a Report:

Processing the selection screen

After starting a report, the selection screen allows the user to enter limits or control values for further report processing. The report can contain several processing blocks for events during selection screen processing, for example, for checking the input values.

Reading the database

After selection screen processing come the events for reading the database. Either the report reads data from relational databases it using the corresponding ABAP/4 statements (open SQL) or leaves this task to a logical database. In the latter case, the logical database creates a sequence of events to allow the report to copy the data.

Evaluating data and creating lists

During or after reading the database the report creates the output list. During list creation, several events allow you to layout the output list (for example, layout the page header).

Outputting a list

The last part of the processing sequence controlled by the ABAP/4 processor is the list output on the screen or printer. When displaying the list on the screen, user can trigger other reports, that are interactive and are event driven. For example, by clicking the mouse. By programming processing blocks for these events, you change a normal report to a so-called Interactive report. If a report does not contain event keywords, the entire coding of the report belongs to a single processing block, which is called by a standard event. This standard event is triggered directly after processing the selection screen.

DIALOG PROGRAMS

¨ You use dialog programs to execute transactions. The users of dialog programs in dialog sessions read and change database tables. Apart from the actual data processing (Open SQL), update and enqueue concepts are of great importance when programming dialogs.

¨ Dialog programs are not stand- alone

¨ To execute dialog programs, they must be linked to at least one screen that itself is linked to a transaction code. The transaction code determines the initial screen with which the dialog session starts.

¨ Dialog programs are controlled by screen flow logic

¨ The actual ABAP/4 dialog program is a so-called module pool. A module pool contains a collection of dialog modules that are called by the screen flow logic.

¨ To each module pool, at least one, but usually several screens are allocated. Each screen has flow logic. The flow logic consists of PBO (process Before output) and PAI (process After Input) blocks. This flow logic does not use the ABAP/4 programming language and the ABAP/4 Editor tool, but a special statement set and the Screen Painter tool, which you also use to layout screens. The flow logic mainly contains the chronologically ordered calls of the modules in the corresponding module pool.

¨ The collection of PBO flow logic, screen, and PAI flow logic is called Dynamic program (Dynpro). A module pool must have at least one dynpro. Each screen of a dialog session thus is the visible part of a dynpro, to which also the flow logic belongs. The processing logic of a dialog session is stored in the corresponding module pool in the form of ABAP/4 modules.

¨ The ABAP/4 modules in the module pool are separated into PBO and PAI modules. The PBO or PAI blocks of the flow logic of each dynpro of a module pool can call each PBO or PAI module of this module pool.

¨ You can use ABAP/4 statements in the processing logic of the module pool to control the chronology of the different dynpros. After starting a dialog session via the transaction code, which is firmly connected to a dynpro of the module pool, the screen flow logic passes user entries to the processing logic in the ABAP/4 module pool. The processing logic processes the user entries (database accesses) and, if required, defines the appropriate subsequent screens.

Data Types and Data Objects

Data types and data objects are essential components of the ABAP/4 type concepts. Both can be declared and maintained by user. Unlike other programming languages in ABAP/4 you can create DATA TYPES independently.

Data Types

¨ Are pure descriptions

¨ No memory is associated with data types.

¨ Describes the technical properties of data objects.

Structure and definition classify data types. Can be of:

1. Elementary or structured

2. Predefined or user defined

	Predefined	User-defined

ELEMENTARY	C, D, F, I, N, P, T, X	Based upon elementary Data types.

	You can use directly	E.g., TYPES: number types I. Can’t allocate memory to types.

STRUCTURED	Predefined types are TABLES	User defined structured types are Field String and internal tables.

Data Objects

¨ Data objects are units created during runtime.

¨ Data object cannot exist without data type.

¨ Occupies memory space.

Kinds of Data Objects

1. INTERNAL DATA OBJECTS

¨ Literal

A literal has a fixed value.

Ex WRITE: “WORK HARD”

¨ Variables

DATA statement is used to create variables

Ex DATA: NUM TYPE I

NUM is a variable declared by DATA statement. Any variable, which you use in program, need to be declared before you use it and can be done by DATA statement.

Here variable is declared by referring to existing data type.

Variable can also be declared by referring existing data object.

Ex. We have already declared NUM by DATA statement.

DATA: PRICE LIKE NUM.

Here variable is declared by using LIKE parameter, which tells system that price has all the attributes of data object NUM i.e., PRICE is also of type I.

The main difference between TYPE and LIKE parameter when defining or declaring the object is that TYPE is used to refer existing DATA TYPE (elementary or structured or user defined) while LIKE is used to declare data objects with reference to existing DATA OBJECTS.

¨ Constant

Constant is a data object, which contains fixed value through out the program. Constant can be declared in program by using CONSTANT statement.

Ex. CONSTANT: INT TYPE I VALUE 15.

In program value of INT cannot be changed. If you give a statement like INT = 20.

In this case system will give error.

2. EXTERNAL DATA OBJECTS

Are defined in tables i.e., in ABAP/4 dictionary. You can access this data from table.

TABLES: SFLIGHT

DATA: SEATS LIKE SFLIGHT-SEATSMAX.

3. SYSTEM-DEFINED DATA OBJECTS

SPACE & SYSTEM VARIABLES like sy-uname, sy-datum, & sy-repid.

4. SPECIAL DATA OBJECTS

PARAMETERS: are variable, which can accept value from user.

SELECTIONS CRITERIA: are special internal tables to accept value range from user.

Need for Data types:

Consider the following example.

DATA: fname(20),

mname(20),

lname(20),

add1(20),

add2(20),

add3(20).

If you have DATA statement like above, and if you need to change the length of all the fields say from 20 to 25, then you need to change all the fields i.e., going through each and every statement.

But consider the following case where TYPES has been used.

TYPES:str(20)

DATA:fname type str,

Mname type str,

Lname type str,

Add1 type str,

Add2 type str,

Add3 type str.

In this case if you need to change the length of all fields from 20 to 25. Then just change the length of STR and change will be reflected for all the fields.

If you define all the types in TYPE-POOL i.e., global definition of all the types, you can use these types anywhere and in any program.

Parameters

Parameter statement is used to accept input from user. PARAMETER statement is used when you want user to enter data and depending upon what he enters you need to take action. The parameter statement declares the variable and also allows system to accept data into that variable.

Syntax.

Parameters: num type I.

Here parameter statement declares the variable and creates the selection screen on which user enters the data i.e., in this case num is declared of type I and user can enter any number. Entered value is stored in the same variable and can be used in program.

Data: m type I

Parameters: num type I

M = num – 5

Write: / ‘The number is’, m.

You can define default values with parameter statement for example

Parameter: num type I default 12.

In this case when selection screen is displayed the default value is displayed. User can either use same value or overwrite the value.

Parameter of type character and length = 1, can be displayed as Checkbox and Radiobutton.

Parameter: C1 as Checkbox,

C2 as Checkbox.

Parameter: R1 Radiobutton group g1,

R2 Radiobutton group g1.

When parameter is defined as Radiobutton, it needs to be attached to one group. Only one Radiobutton of one group can be clicked.

Every parameter can be associated with language dependent text that is displayed on the selection screen. This can be done with the help of text elements.

WRITE Statement

The basic APAB/4 statement for outputting data on the screen is WRITE.

Syntax:

WRITE <field> <option>.

This statement outputs the field <f> to the current list in its standard output format.

By default, the list is displayed on the screen.

The field <field>can be any variable or table field or just literal.

PROGRAM ZDEMO

WRITE: /‘HELLO’.

When you start this program, the system leaves the current screen i.e., your editor screen and branches to the output screen, which is also called as list screen:

The list screen has the same name as the title of the program specified in the program attributes. First line on the screen contains the list header. By default, the list header is the same as the title of the program. The current page number (1) appears on the right. The list header is followed by one line and then the output is displayed.

Write : ‘HELLO’.

Write : ‘WORK HARD’

On the screen, the output is normally left justified. But in above case, because we have used two WRITE statements, the output fields are displayed one after the other, each separated by one column (i.e., one blank). If there is not enough space for an output field on the current line, a new line is started.

Almost all system-defined fields are right justified except FLOAT, INTEGER, and PACKED i.e., number field. The numeric data types F, P, and I are right justified and padded with blanks on the left. If there is sufficient space, thousands of separators are also output. If a type P field contains decimal places, the default output length is increased by one.

With the data type D, the internal format of a date differs from its output format. When you use the WRITE statement for outputting data, the system automatically outputs dates of type D in the format specified in the user’s master record (e.g. DD/MM/YYYY or MM/DD/YYYY).

Formatting output

You can position the output of a WRITE statement on the screen by making a format specification before the field name as follows:

Syntax:

WRITE AT [/][<pos>][(<len>)] <f>,

Where

‘the slash’/‘ denotes a new line,
<pos> is a number or variable denoting the position on the screen,
<len> is a number or variable long denoting the output length.

For variables you need to mention the AT, for direct values it is not necessary.

DATA: LEN TYPE I VALUE 10,

POS TYPE I VALUE 11,

TEXT (10) VALUE ‘1234567890’

WRITE AT POS (LEN) TEXT.

This produces the following output on the screen;

The text – 1234567890 – appears in the text.

If the output length <len> is too short, fewer characters are displayed. Numeric fields are truncated on the left and prefixed with an asterisk (*). All other fields are truncated on the right, but no indication is given that the field is shorter.

DATA: NUMBER TYPE I VALUE 1234567890,

TEXT (10) VALUE ‘abcdefghij’.

WRITE: (5) NUMBER, /(5) TEXT.

This produces the following output:

7890

abcde

In the default setting, you cannot create empty lines with the WRITE statement.

WRITE: ‘One’,

/‘ ’,

/ ‘Two’

The output looks as follows:

One

Two

The system suppresses lines that contain nothing but empty spaces.

You can use various formatting options with the WRITE statement.

Syntax

WRITE………… <field> <option>

Formatting options for all data types

*Option*	*Purpose*
LEFT-JUSTIFIED	Output is left justified.
CENTERED	Output is centered.
RIGHT-JUSTIFIED	Output is right justified.
NO-GAP	The blank after the field <f> is omitted.
NO-ZERO	If a field contains only zeros, these are replaced by blanks. For type C and N fields, leading zeros are replaced automatically.

Formatting options for numeric fields

Option	Purpose
NO-SIGN	The leading sign is not output.
DECIMALS <d>	<d> defines the number of digits after the decimal point.
EXPONENT <e>	In type F fields, the exponent is defined in <e>
ROUND <r>	Type P fields are multiplied by 10**(-r) and then rounded
CURRENCY <c>	Format according to currency <c> in table TCURX.
UNIT <u>	The number of decimal places is fixed according to the unit <u> specified in table T006 for type P fields.

Horizontal lines

You can generate horizontal lines on the output screen by using the following syntax:

Syntax

ULINE

Will draw a horizontal line.

ULINE (10)

Will start drawing horizontal line from 10^th column position.

WRITE at 10(40) SY-ULINE

This statement draws a horizontal line from 10^th position.

Vertical lines

You generate vertical lines one the output screen by using the following syntax:

Syntax

WRITE [AT [/] [<pos>]] SY-VLINE.

Blank lines

You can generate blank lines on the screen by using the following syntax :

Syntax

SKIP [<number>]

Starting on the current line, this statement generates <number> blank lines on the output screen. If no value is specified for <number>, one blank line is output. In the standard setting, you cannot create empty lines with the WRITE statement alone.

To position the output on a specific line on the screen use:

Syntax

SKIP TO LINE <number>

This statement allows you to move the output position upwards or downwards.

Branches

Like other higher programming languages, ABAP/4 provides standard keywords to control the flow of a program.

Usually ABAP/4 programs get executed statement by statement. Many times you need to skip few statements depending upon certain conditions i.e., you change the flow of program. This can be done by:

¨ branching (IF, CASE)

¨ looping (DO, WHILE)

However, unlike other language where you have only internal control, ABAP/4 has internal control and external control of the program flow.

¨ The internal control is steered by standard keywords as mentioned above. You define this in your program code.

¨ The external control is stored by events. Events are generated either from other ABAP/4 programs or from interactive user input (like, for example, using the mouse to click on the screen). The system does not necessarily process the statements in the same sequence as they are listed in an ABAP/4 program. This makes ABAP/4 an event-driven programming language. The external control plays an important role mainly for report programs.

Branching with IF statement

The IF statement allows you to divert the program flow to a particular statement block, depending on a condition. This statement block consists of all the commands which occur between an IF statement and the next ELSEIF, ELSE, or ENDIF statement.

Syntax

IF<condition1>

ELSE

ENDIF

If the first condition is true, the system executes all the statements up to the end of the first statement block and then continues processing after the ENDIF statement.

To introduce alternative conditions, you can use ELSEIF statements. If the first condition is false, the system processes the following ELSEIF statement in the same way as the IF statement. ELSE begins a statement block which is processed if none of the IF and ELSEIF conditions is true. The end of the last statement block must always be concluded with ENDIF.

IF <condition1>.

ELSEIF <condition2>.

ELSEIF <condition3>.

ELSE.

ENDIF.

ABAP/4 allows unlimited nesting of IF – ENDIF statement blocks, but they must terminate within the same processing block. In other words, an IF – ENDIF block cannot contain an event keyword.

Branching with CASE statement

To execute different statement blocks depending on the contents of particular data fields, you can either use IF statement or the CASE statement as follows:

Syntax

CASE <f>.

WHEN <f1>.

WHEN <f2>.

WHEN <f3>.

WHEN OTHERS.

ENDCASE.

The system executes the statement block after the WHEN statement if the contents of <f> equals the contents of <fi>, and continues processing after the ENDCASE statement. The statement block after the optional WHEN OTHERS statement is executed if the contents of <f> do not equal any of the <fi> contents. The last statement block must be concluded with ENDCASE.

The conditional branching using CASE is a shorter and simpler form of similar processing with IF. When you have many conditions IF becomes more complicated in such cases CASE is used.

LOOPING

Looping with DO statement

If you want to write your name say for 10 times, you need to write WRITE statement for 10 times.

When you want to process a statement more than once, you can write this statement within a loop with the DO statement as follows:

Syntax

DO 5 times.

Write : / name.

ENDDO.

The system continues processing the statement block for 5 times introduced by DO and concluded by ENDDO.

The system field SY-INDEX contains the number of times the loop has been processed so in this case when the loop is over value of sy-index will be 5.

In this case you know that, you want to perform WRITE statement for 5 times. But that is not the case always. Many times you need to terminate the loop depending upon certain conditions. This can be done, by using EXIT or STOP statement.

The important point to remember when you don’t you use TIMES option, is to avoid endless loops when working with the DO statement. If you do not use the TIMES option, include at least one EXIT, STOP statement so that the system can leave the loop.

EXIT and STOP takes you out of that loop.

Looping with WHILE Statement

If you want to process a statement block more than once as long as a condition is true, you can program a loop with the WHILE statement as follows:

Syntax

DATA: M TYPE I VALUE 0.

WHILE M < 10.

WRITE: / M.

M = M + 1.

ENDWHILE.

The system continues processing the statement block introduced by WHILE and concluded by ENDWHILE statements as long as M is less than 10 or until the system finds an EXIT, STOP.

The system field SY-INDEX contains the number of times the loop has been processed.

You can nest WHILE loops any number of times and also combine them with other loops.

Difference between DO loop and WHILE is that in WHILE, condition is checked first and if condition is true then loop is executed while in DO loop, the loop gets executed first if you don’t have TIMES option and then the condition is checked (if you have any).

You can have nested DO and WHILE or DO and IF or IF and IF or any possible situation.

String Operations

ABAP/4 provides several keywords for processing data objects of type C, also known as character strings.

Shift command

To shift the contents of a field, by one position or one character you can use the SHIFT statement. Using SHIFT allows you to shift field contents, byte-by-byte or character-by- character.

With the SHIFT statement, you can execute the following:

String = ‘HELLO’.

String 1 = ‘ALL OF YOU’.

String 2 = ‘WORK HARD’.

Shift string

Shift string1 by 2 places.

Shift string2 right.

Shift string1 by 2 places circular.

The output will be

ELLO – By default if nothing is specified then string is shifted by one position.

L OF YOU – Here the string is shifted by 2 places.

_WORK HARD – In this case the string is shifted to right by one place (with leading blanks)

K HARDWOR – In this case the string is shifted to the left so that 3 characters on the left appear on the right.

Replace command

You use the REPLACE statement.

Syntax

REPLACE<strl>WITH<str2>INTO<c>[LENGTH<1>].

ABAP/4 searches the field <c> for the first occurrence of the first, <1> positions of the pattern <str1>. If no length is specified, it searches for the pattern <str1> in its full length.

Then, the statement replaces the first occurrence of the pattern <str1> in field <c>with the string <str2>. If a length <l> was specified, only the relevant part of the pattern is replaced.

REPLACE STR1 WITH STR2 INTO STRING.

Here whole string is searched for string1 and is replaces with str2.

REPLACE ‘&’ WITH ‘M’

Here the system searches string for & and replaces it with ‘M’.

TRANSLATE command

Syntax

TRANSLATE<c> TO UPPER CASE.

TRANSLATE<c> TO LOWER CASE.

These statements convert all lower case letters in the field <c> to upper case or vice versa.

You can use TRANSLATE to substitute the characters in a string like replace. But the main difference between Translate and Replace is that Replace statement replaces only one occurrence of particular character while Translate replaces all the occurrences of the character.

When using substitution rules, use the following syntax:

Syntax

TRANSLATE <c> USING <r>.

STRLEN command

To determine the length of a character string up to the last character other than SPACE, use the built-in function STRLEN as follows:

Syntax

N = STRLEN ( STR ).

Here N is defined in DATA statement as type i.

STRLEN processes any operand <c> as a character data type, regardless of its real type. No conversions are performed.

CONDENSE command

To delete superfluous blanks in character fields, use the CONDENSE statement:

Syntax

CONDENSE <c> [NO-GAPS].

This statement removes any leading blanks in the field <c> and replaces other sequences of blanks by exactly one blank. The result is a left-justified sequence of words, each separated by one blank. If the addition NO-GAPS is specified, all blanks are removed.

CONCATENATE command

To concatenate separate character strings into one, use the CONCATENATE statement:

Syntax

CONCATENATE <c1> …<cn> INTO <c> [SEPARATED BY <s>].

This statement concatenates the character fields <c1> to <cn> and assigns the result to <c>.

Trailing blanks are ignored during this operation.

CONCATENATE STR ‘:’ STR2 INTO STRING.

Here str, str2 and ‘:’ is concatenated and result is stored in string.

SPLIT command

To split a character string into two or more smaller strings, use the SPLIT statement:

Syntax

SPLIT <c> AT <del> INTO <cl>….<cn>.

This statement searches the character field <c> for delimiter strings <del> and the parts before and after the delimiters are placed in the target fields <c1>….<cn>.

To place all fragments in different target fields, you must specify enough target fields. Otherwise, the last target field is filled with the rest of the field <c> and still contains delimiters.

SPLIT STRING AT ‘,’ INTO P1 P2 P3 P4.

Here the string is split at ‘,’ and is put into strings p1, p2, p3, p4.

¨ In ABAP/4, you can specify offset values for elementary data objects in all statements, which process these data objects.

To do so, specify the name of a data object in a statement as follows:

Syntax

<f>[+<o>][(<l>)]

The operation of the statement is performed for the part of the field <f> that begins at position <o>+1 and has a length of <l>.

If the length <l> is not specified, the field is processed for all positions between <o> and the end of the field.

String = string1+3(4).

Assuming that string1 = ‘abcdefgjk’.

Here string will contain ‘defg’.

OPEN SQL

In the R/3 System, long-life data is stored in relational database tables. Structured Query Language (SQL) was created for accessing relational Database. SQL has two statement types: Data Definition Language (DDL) statements and Data Manipulation Language (DML) statements.

TO include SQL statements in an ABAP/4 program, use Native SQL. To avoid incompatibilities between different database tables and also to make ABAP/4 program independent of the database system in use, SAP has created a set of separate SQL statements called Open SQL. Open SQL contains a subset of standard SQL statements as well as some enhancements, which are specific to SAP. Using Open SQL enables you to access any database tables available to the SAP system regardless of the manufacturer be it Oracle, Informix etc.

The difference between Open SQL and Native SQL is as follows:

A database interface translates SAP’s Open SQL statements into SQL commands specific to the database in use. Native SQL statements access the database directly.

Open SQL keywords

Keywords Used for

SELECT: Reading Data from Database Tables
INSERT: Adding Lines to Database Tables
UPDATE: Changing Lines in Database Tables
MODIFY: Adding or Changing Lines
DELETE: Deleting Lines from Database Tables

When using Open SQL statements in an ABAP/4 program, you must ensure the following:

1) The database system being addressed must be supported by SAP.

2) The database tables being addressed must be defined in the ABAP/4 Dictionary.

Select statement

The following system fields play an important role in Open SQL operations:

SY-SUBRC

As with other ABAP/4 statements, the return code value in the system field SY-SUBRC indicates after each Open SQL operation whether or not the operation was successful. If an operation is successful, SY-SUBRC = 0. If an operation is unsuccessful – SY-SUBRC <> 0

SY-DBCNT

The value in the SY-DBCNT field indicates how many lines were affected by the operation or how many lines have already been processed.

To read data from a database table, use the SELECT command.

Syntax

SELECT<what> FROM <table name> [INTO <variable, another table>] [WHERE <condition>].

This statement has several basic clauses. Each clause is described in the following table.

SELECT<what> FROM <table name> INTO <variables or another table> WHERE <condition>

The SELECT clause defines whether the result of the selection is a single line or a whole table, or few columns.

FROM <table name>

The FROM clause specifies the database table or view <source> from which the data is to be selected.

INTO <variable, another table>

The INTO clause determines the target area <target> into which the selected data is to be read. It can also be placed before the FROM clause. If you do not specify an INTO clause, the system uses the table work area. The table work area is a header line, which is automatically created by the TABLES statement.

WHERE <condition>

The WHERE clause specifies which lines are to be read by specifying conditions for the selection. Choosing the Lines to be Read.

For Selecting All data from table:

i.e., read all columns and all the rows from database table

Syntax

SELECT * FROM <table>.

(Here you are not specifying WHERE condition)

Selecting All Data from a Single Line

To read all columns of a single line from a database table, use the SELECT statement as follows :

Syntax

SELECT SINGLE * FROM <table> …… WHERE <condition> ……

The result of this statement is a single line. To make sure you retrieve desired unique single record, you must link all the fields which form the primary key of the database table by AND in the WHERE condition.

Prerequisite for SELECT SINGLE

1. Use all primary keys in WHERE condition.

2. Always check for SY-SUBRC.

3. Clear work-area for table.

Aggregate Expressions

By using aggregate expressions, you can extract characteristic data from a column <a> of the database table.

.MAX: returns the maximum value of the column

.MIN: returns the minimum value of the column

.AVG: returns the average value of the column

.SUM: returns the sum value of the column

.COUNT: counts values or lines as follows:

-COUNT( * ) returns the total number of lines in the selection.

You must include spaces between the parentheses and the arguments. The arithmetic operators AVG and SUM can only work with numeric fields.

Sometimes you retrieve few columns form database table i.e. you have list in the SELECT Clause and INTO Clause.

If there is a list in the SELECT clause, you must use the INTO clause with the SELECT statement. You can use either a work area <wa> or an internal table <itab> or list of variables as an argument,

Syntax

TABLES: SFLIGHT.

DATA : CARRIDI LIKE SFLIGHT -CARRID,

CONNID LIKE SFLIGHT –CONNID.

SELECT CARRID CONNID FROM SFLIGHT INTO (CARRID1, CONNID1). WRITE: / CARRIDl,CONNID1.

ENDSELECT.

Many times you retrieve related data from two or more tables. In such cases you use nested selects by linking tables with common primary keys. But as far as possible avoid using nested selects as time required to access nested table is very high.

Syntax

TABLES: SFLIGHT, SBOOK.

SELECT * FROM SFLIGHT WHERE CARRID = 'LH'.

SELECT * FROM SBOOK WHERE CARRID = SFLIGHT -CARRID AND

CONNID = SFLIGHT -CONNIID.

WRITE: / SFLSIGHT-CARRID,SFLIGHT-CONNID,SBOOK-BOOKID,

ENDSELECT.

Some performance hints for Open SQL statements

¨ Keep the selected dataset small

Keep the number of selected data as small as possible to avoid unnecessary network transports. Use the respective Open SQL statements always with the WHERE clause. Avoid complex WHERE clauses. The system must split up those into single statements for the database system.

Do not use the logical NOT in WHERE clauses but inverted operators instead.

The logical NOT is supported by the database indexes.

¨ Keep the transferred data small

¨ Transfer only those columns of a database table that you really need. Avoid SELECT* if you do not want to read all columns of a database. Use a list in the SELECT clause instead. Use aggregate expressions in the SELECT clause to perform calculations instead transporting great amounts of data and calculating thereafter.

¨ Keep the number of database accesses small

¨ Use operations on packages of data instead of operations on single data if you want to analyze selected data more than once. To do so, transfer the data in a single operation between tables and internal tables.

¨ Avoid nested SELECT loops. Instead, work with internal tables and SELECT statements using the FOR ALL ENTRIES addition.

Insert statement

INSERT statement inserts a single record into the database table.

Syntax

Tables: sflight.

Sflight-carrid = ‘LH’.

Sflight-connid = ‘234’.

Insert sflight.

Table sflight is inserted with the record. The SY_SUBRC is returned for this statement. If the entry already exists then the SY_SUBRC is set to non-zero value and you can do processing for existing record by giving some error message.

Update statement

To update database table UPDATE statement is used. This allows you to change either a single record or several records.

You can use UPDATE when you know which record you want to change. But if you do not know whether the primary key of the line you want to insert already exists or not, you can use the MODIFY statement. The MODIFY statement changes existing lines and inserts lines which do not exist.

Sflight-carrid = ‘MN’.

Sflight-connid = ‘454’.

UPDATE SFLIGHT where CARRID = ‘LH’.

TABLES SFLIGHT.

UPDATE SFLIGHT SET PRICE = 1100

WHERE CARRID = ‘LH’.

Here price of sflight will get updated with new price 1100.

Delete statement

To delete records from a database table, you use the DELETE statement.

DELETE FROM SFLIGHT WHERE CARRID = ‘LH’ AND CONNID = ‘454’.

Will delete the single record where conditions are met from SFLIGHT.

You can delete the multiple records from database table by putting all the records, which you want to delete in internal table. For example

DELETE SFLIGHT FROM TABLE ITAB.

In this case whatever you have in internal table will be deleted from SFLIHT.

Note: append internal table with all the entries, which you want to delete.

EXERCISES

SIMPLE WRITE STATEMENTS

1 Write a program, which generates the model list as shown

Use these system fields in your program.

SY-DATUM, SY-UZEIT, SY-UNAME

Maintain the list headings

12/12/97 FIRST PROGRAM

______________________________________________________

This list is generated

on: 12/12/1997

at: 13:40:35

by: ABAP 1

______________________________________________________

2 Create a list as shown

---------------------------------------------------------------------------------------------------

XYZ Co. Pvt. Ltd.

Date: Today’s date Page No. 1

---------------------------------------------------------------------------------------------------

Program name: ZDEMO

SYMBOLS, ICONS AND FORMATTING

1 Write a program to show the following using system variables

(hint: use include <symbol> and include <icon>

Symbols: Icons:

Telephone Checked; okay,

Fax machine Delete,

Hand pointing left, Print

Hand pointing right,

Caution,

Eg : Write sym_phone as symbol, ‘telephone’.

2 Write a program to show a string with different background colours.

eg.

write ‘HEADER’ color col_heading.

(col_heading is abap/4 name for grayish blue colour. Other colours are

col_key for bluish green, col_normal for bright gray, col_background for

gray, col_positive for green, col_negative for red, col_group for violet and

col_total for yellow)

3 Use Format intensified – format intensified off.

Format color <color_name> - format color off.

Format inverse – Format inverse off

4 Show current time and today’s date.

5 Show a value ‘123456’ as 12:34:56 using ‘using edit mask’.

6 Take a number as ‘0000011’. Suppress all leading zeros.

7 Suppress a sign before a number.

GENERAL PROBLEMS

1 Create an adding machine for numbers.

The two values to be added must be entered on the selection screen as

parameters. Output the result.

2 Create the dividing machine for numbers.

The two values must be entered on the selection screen as parameters.

Output the result.

3 Create your output as shown below.

. .

. . .

. . . .

. . . . .

4 Write a program to accept the two numbers from the user and swap the values.

5 Declare a string ‘echo’ and design your output

ech

echo

ech

DO-ENDDO, IF-ELSEIF-ELSE-ENDIF, CASE-ENDCASE

1 Write a program with Do – Enddo loop.

Display squares of numbers 1 to 10

1 1

2 4

3 9

2 Write a program to accept a number (say 2) from user and create a multiplication table.

2 x 1 = 2

2 x 2 = 4

…………

2 x 10 = 20

3 Accept a number from user and find Factorial of the same. If the number is negative then display some message.

4 Write a program with Do – Enddo loop for first 20 numbers.

- Output should contain only Even number

- Odd numbers should not be displayed

5 Accept numbers and choice ‘EVEN’ or ‘ODD’ from the user and display the numbers in that range according to user’s choice.

6 Write a program with Do – Enddo loop for first 20 numbers.

- Odd numbers & Even numbers should be displayed with alternate intensities. (Use Format intensified – on – off)

7 Create a calculator, which performs the four basic types of calculations on two whole numbers. The two values and the option are to be entered on the selection screen as parameters. Output the result with 2 decimal places.

8 Write separate programs using ‘CONTINUE’ and ‘EXIT’ statements in DO-LOOP.

STRING OPERATIONS

1 Accept a string and determine its length

2 Accept a string & number. Write the string that many number of times.

3 Accept two strings and swap their contents.

4 Accept two strings and concatenate into one string.

5 Accept one string with delimiter ( , or ; ) and split it into two strings.

6 Accept a string ‘abcdef’ and use shift <string>, shift <string> right, shift <string> up to ‘def’.

7 Accept a string eg. Apple. Change first occurrence of ‘p’ to ‘b’.

(use ‘replace’ command)

8 Accept a string eg. Apple. Change all occurrences of ‘p’ to ‘b’.

(use ‘translate’ command)

9 Accept two strings and compare the two strings using ‘co’, ‘ca’, ‘cs’

‘cp’ (out put shall be ‘true’ or ‘false’ for each comparison.)

10 Accept a string ‘ABCDEF’. Output only ‘DEF’ using offset command.

11 Accept first name, last name and middle name

eg. Nandamuri Taraka Ramarao

display as N.T.Ramarao

12 Accept a string. Change all occurrences of a to b.

13 Accept a number and swap first and last digit of the same.

14 Accept a string and display the string in reverse order

15 Accept a string and check for palindrome

DATE PROBLEMS

1 Accept a date earlier to today’s date and find the difference in number of days.

2 Accept a date from user and display first day of the month and last day of the previous month.

3 Accept a date from user and add six months to the date.

4 Accept a date from user and convert month part to ‘jan’, ‘feb’ etc., and display this date.

5 Write a program to accept month. Display number of days in total month.

Make use of

- Text element for your selection screen box.

- Selection text

6 Accept birth date from user and output age in years, months and days.

CHECK BOXES AND RADIO BUTTONS

1 Write a program with

- Parameter as checkboxes

- If checkbox 1 is clicked write c.b 1 clicked else c.b 1 not clicked.

- If checkbox 2 is clicked write c.b 2 clicked else c.b 2 not clicked.

- If checkboxes 1 & 2 are clicked write c.b 1 & c.b. 2 are clicked.

- If checkboxes 1 & 2 are not clicked write c.b 1 & c.b. 2 are not clicked.

2 Write a program with

- Parameters as two groups of Radiobuttons (two Radiobuttons in each group).

- Give detailed coding as above, to show the Radiobuttons and groups

- selected

3 Write a program with

- Parameter as checkbox.

- If you click the checkbox then display first day of the next year.

- If the checkbox is not clicked then display last day of the current year.

4. Write a program with

- Parameter as group of 3 radio buttons

- If first radio button is clicked, display last day of the current month.

- If second radio button, display first day of the next month

- If third radio button, display date after six months.

SELECT STATEMENTS

1 List all the rows from the table VBAK.

2 List single row from the table BKPF.

3 List up to 5 rows from the table BSIS.

4 List all ERDATs. For better readability create a column heading in the list

5 Display total amount for carrid ‘LH’. (Tables: SFLIGHT)

6 List all the flights for which booking date is greater than ’01.06.1995’.

7 List all the flights for which payments currency is ‘DEM’.

8 List all the flights where carrid is between ‘LH’ and ‘SQ’.

9 Select a single record where carrid = ‘LH’, flight-no = ‘0400’ and

fldate = ’28.02.1998’.

10 Display carrid, connid, fldate and luggage weight multiplied by 2

11 List the maximum capacity, occupied seats and total of current bookings for each flight in the following format.

Carrier id

Max. capacity

Occupied seats

Total of current bookings

12 From the given from-city and to-city, list all the available on this route:

From: <from-city> To: <to-city> (say from Frankfurt to Madras)

(Tables: SPFL1)

Carrier id

Departure Time

Start Airport

Destination Airport

OPEN SQL

1 Accept document no. from user and display particulars of Sales document. (Default document no. ‘0010000031’)

(Table: VBAP)

Created on: xxxxx

Created by: xxxxx

Time: xxxxx

2 Accept Sales Document number from user and display corresponding material

no, description of that material and item category (Table : VBAP)

3 Accept material no. & item category by default PP100 and KMN respectively

Display corresponding details of sales document (Table: VBAP)

4 Display fields from BKPF.

Document type = ‘AB’ and

Document date = ’05.02.1998’.

Also display number of records selected.

5 Display Co. code, doc.no., acc.type, tax code.

Make use of select-options to give range of document type.

Display title of your program at the end of program

6 Accept doc. no from user.

Display doc.no., doc.status, date of doc., doc.type.

7 Display single record for document where date = ’05.02.1998’, type ‘= ‘AB and document

no. = ‘0100000006’.

8 Accept plant from user eg. PLTP.

Display document details for that plant like doc.no., doc.status, date of document etc.,

2012-09-22T22:54:00.002-07:00

DEBUGGING

Many times an error free program doesn’t give desired output. Behavior of program is different in different situations, with different values of variable. Such program needs additional testing, by which you can test the program by stopping at each point where you feel program is behaving abnormally.

The ABAP/4 debugger is the development workbench tool, which allows you to stop a program during its execution when a particular condition is met. When the program is stopped, you can use the debugger to display the contents of the table and variable being used by the program. It allows you to execute the program step by step, reviewing exactly the real flow of the program execution.

There are many occasions during normal system operation during which the ABAP/4 debugger can be started. When executing program, the ABAP/4 debugger is automatically started when the system encounters a breakpoint.

Starting the ABAP/4 debugger

There are many ways to start debugger

· By clicking the Execute button and selecting the debugging mode.

· From the ABAP/4 editor, by executing a program choosing Program ® Execute ® Debugging from the menu.

· Setting breakpoint in the program

Components of ABAP/4 debugger

The debugger shows the program information using six different views.

· Fields: Displays the field contents.

· Table: Allows modifying the contents of internal table.

· Breakpoints: Displays list of Breakpoint in the Program.

· Watchpoints: Allows dealing with Watchpoints.

· Calls: System call status like Event, Form etc.,

· Overview: Presents the program structure, events, subroutines, and modules.

· Settings: Displays the calling sequence within a particular event, up to the current breakpoint.

All these options are shown in the following screen.

Arrow indicates the breakpoint of the program i.e., where user has stopped the program.

Breakpoints

A breakpoint is the signal, which is specified in the program, tells the system to stop the program execution and to start the debugger. Following types of breakpoint are available with ABAP/4:

¨ Static are set up with the BREAKPOINT keyword inside the program, which you can directly display with the ABAP/4 source code editor. To set the breakpoint in the program enters the keyboard BREAKPOINT.

¨ Dynamic this breakpoint is not visible in the code. Position the cursor over the source code line to have the breakpoint and then select utilities - ® breakpoint - ® set. You can delete them or display them from breakpoint list. Or you can execute the program in the ABAP/4 debugger i.e., in debugging mode.

¨ Watchpoints are field specific. The program is stopped when the field reaches the value specified in the watchpoint. Execute the program in debugging mode. Position the cursor over the needed field. Press the F button to get the view of field. Select the checkbox for the needed watchpoint. Click on the continue button.

¨ Keywords/events The program stops just before executing a specific event or keyword. To set breakpoint at particular event, from initial screen of debugger, select Breakpoint ® Breakpoint at ® at event/at keyword. Enter the name of the keyword or event. Click on OK.

Navigating through the breakpoint

Following buttons are used to navigate through the program and debugger.

¨ Single step: Executes a single program command.

¨ Execute: Similar to the single step, but when a program calls a subroutine, it executes the whole subroutine unlike single step.

¨ Continue: Executes the program until it is finished or until it finds next breakpoint.

¨ Return: Allows for executing the program instruction up to the end of a routine and stops in the line of code where the subroutine gives back control to the main program.

¨ Tables: Switches the debugger to the table view.

Displaying and modifying values

Every time the program is stopped within a debugger, you can display and modify the contents of table field and fields.

To display the fields, click on V and you can view the contents of system field, program field, ABAP/4 dictionary fields, and external program fields.

Displaying and modifying internal tables

When you click on the Table button from the initial ABAP/4 debugger screen, the system will display the table debugger view. Here you need to enter the name of the internal table to be displayed. You can modify or delete or add i.e., insert the internal table Contents. These changes are applicable only for the debugging and do not affect the structure of internal table in the program.

Setting WATCHPOINTS

¨ Execute a program in debugging mode.

¨ Position the cursor over the needed field.

¨ Press the F button to get a view of the fields.

¨ Select the checkbox for the needed watchpoint.

¨ Click on the CONTINUE button.

¨ To display the active watchpoint select Goto - ® Breakpoint

INTERNALTABLES

Consider the following cases:

¨ You want to reorganize the contents of table.

¨ You want to modify few details of table and then display the contents of table to user.

¨ You want to perform table calculations on subset of database table.

In above cases you need to recognize or change the database table contents.

In ABAP/4 you work mainly with tables. Long life data is stored in database tables. You cannot afford to lose data from database table. In such cases where you can not work directly with database table (where you are modifying contents of table or reorganizing the contents of table or any other case where you are altering contents of table and then displaying output to the user) hence need of intermediate table where you put in all the data from database table and work with this data thus avoiding accidental loss of data.

These intermediate tables are called INTERNAL TABLES in ABAP/4 and are created only during runtime i.e., no memory is reserved for internal tables.

When you use Internal Table in a program, three steps are associated with it.

1. Declaration of Internal Table

2. Populating Internal Table

3. Processing Internal Table

Declaration of Internal Table

Depending on how you create, internal tables are of two types.

¨ Internal tables with header line.

When you create internal tables with header line, and then default workarea or header is created. And you can work with this header.

¨ Internal Table without header line.

In this case you need to create output explicit workarea to work with table. Only advantage of internal tables without header line is that you can nest them i.e., you can have table within table, which is not possible on internal tables with header line.

Internal table can be declared in the following way:

¨ Data	:	Itab like sflight occurs 0 with header line
		Here you are declaring internal table, which is similar to sflight i.e., itab like sflight i.e., you are referring to existing table (like). (By default internal table created with this declaration is without header line).

¨ Data	:	Begin of itab occurs 0. Include structure sflight
Data	:	End of itab
		(Internal Table created with this type of declaration is similar to declaration done in ‘a’ type the only difference is by default internal table created by this type is with header line)

¨ Data	:	Begin of itab occurs 0 carrid like sflight-carrid, connid like sflight-connid, fldate like sflight-f1date End of itab.
		By default internal table created by this type of declaration is with header line. In this type of declaration, you are using only those fields from database table, which you require for processing.

¨ Data	:	Begin of itab occurs 0 carrid like sflight-carrid, connid like sflight-connid, bookid like sbook-bookid id like scustom-id, End of itab.
		Here you are combining fields from three different tables in one internal table.

¨ Data	:	Begin of itab occurs 0 Carrid1 like sflight-carrid, End of itab. Here you are specifying different field names.

Populating Internal Table

¨ Itab-name = ‘ABCD’.

Append Itab.

(In this case itab is filled with one name i.e., ‘ABCD’.)

¨ Do 5 times.

Itab-number = sy-index.

Append itab.

Enddo.

(In this case itab is filled with sy-index for 5 times)

¨ Select * from sflight into itab.

Append itab.

Endselect.

¨ Select * from sflight into table itab.

Note: Addition of Table in INTO clause, you omit append itab and Endselect

¨ Select * from sflight

Move-corresponding sflight to itab.

Append itab.

Endselect.

Note: While using Move-corresponding, field names of DB table & Int’ table should be same.

¨ Select * from sflight.

Move sflight to itab.

Append itab.

Endselect.

Note: In this case structure of sflight and itab should be similar

¨ Select carrid1 connid1 from sflight into (itab-carr1, itab-connid1)

Append itab.

Clear itab.

Endselect.

Processing Internal Table

Processing of internal table includes:

¨ Writing: write : / itab carrid. (will write only one field)

Loop at itab. (Will write whole internal table)

Write itab

Endloop.

¨ Reading: You can read internal table by:

Read table itab with key carrid = ‘LH’ (Here you are reading table with key)

Or Read table itab with index 3. (Here you read table with index 3)

(Note: Reading of internal table can be done inside the loop or outside the loop)

Modifying: You can modify contents of internal table by specifying key or index.

Itab-carrid = ‘LM’

Modify table itab index 3.

¨ Delete: delete table itab index 3.

(Will delete record with index 3)

Commands associated with clearing of internal tables are as follows:

¨ Clear itab	:	Will clear header of internal table
¨ Clear itab [ ]	:	Will clear body of table.
¨ Refresh itab	:	Will remove contents of internal table.
¨ Fee itab	:	Will de-allocate memory associated with internal table.

Sorting of Internal Tables

To sort contents of internal table you can use

SORT ITAB

This command will sort internal table on all non-numeric primary keys in ascending order.

To specify internal table for given key the syntax is,

SORT ITAB BY CARRID ASCENDING.

In this case the table itab is sorted with carrid key in ascending order.

You can sort table in either ASCENDING or DESCENDING order. The default order is ASCENDING.

You can sort table with multiple keys also. The number of SORT key fields is restricted to 250. If you specify more than one field then the system sorts the record first by f1 then by f2 and so on (Here f1, f2 are fields).

Control Break Statements

Control break statements are used to create statement blocks which process only specific table lines the LOOP – ENDLOOP block.

You open such a statement block with the control level statement AT and close it with the control level statement ENDAT. The syntax is as follows:

Table should be sorted when you use control-break statements

You can break the sequential access of internal tables by using these statements.

Syntax:

At first.

Endat.

This is the first statement to get executed inside the loop (remember control break statements are applicable only inside the loop)

So in this block you can write or process those statements which you want to get executed when the loop starts.

At New carrid.

Write:/ carrid.

Endat.

In this case whenever the new carrid is reached, carrid will be written.

At End of carrid.

Uline.

Endat.

In this case whenever the end of carrid is reached, a line will be drawn.

At Last.

Write:/ ‘Last Record is reached’.

Endat.

Processing of statements within this block is done when entire processing of entire internal table is over. Usually used to display grand totals.

You can use either all or one of the above control break statements with in the loop for processing internal table.

At end of carrid.

Sum.

Endat.

In above case the statement SUM (applicable only within AT-ENDAT) will sum up all the numeric fields in internal table and result is stored in same internal table variable.

SUBROUTINES

The process of breaking down a large program into smaller modules is supported by ABAP/4 through subroutine, also called forms.

Subroutines are programs modules, which can be called from ABAP/4 programs. Frequently used parts of program can be put into subroutines and these subroutines can be called explicitly from the program. You use subroutines mainly to modularize and structure your program.

Defining Subroutines

A subroutine is block of code introduced by FORM and concluded by ENDFORM. Following syntax is used to define a form or subroutine:

FORM <name> <parameters>

. . …..

…

ENDFORM.

Here parameters is optional. You can have plain subroutine without the parameters for example.

FORM SUB1.

… . .

… .

ENDFORM.

Calling Subroutines

You can call subroutines from program by following statement:

PERFORM <subr> [<para>].

Parameters are optional. i.e., you can call subroutine without passing any parameter

Perform SUB1.

Passing Data to Subroutines

When you work with global data in subroutines, you can put a copy of the global data on a local data stack and use it to avoid accidental loss of data (In this way you protect global data.)

You can pass data between calling program and subroutines by using parameters.

¨ Parameters, which are defined during definition of a subroutine with FORM statement are called ‘formal parameter’.

¨ Parameters which are specified during the call of a subroutine with the PERFORM statement are called ‘actual parameter’.

Parameters are passed to the FORM either:

¨ By value

¨ By Reference

¨ By value and return.

By Value

Data : a type I value 20.

Perform sub1 using a.

Write a.

FORM sub1 using value (p_a)

P – a = 15

ENDORM.

In this case during subroutine call, the formal parameter are created as copies of actual parameter.

The formal parameters have the memory of their own. Changes made to formal parameter have no effect on the actual parameter.

Like in this case, though value of p_a is changed to 15, it has no effect on ‘a’ which remains as 20.

By Reference

Data: a type I value 20.

Perform sub1 using a.

Write a.

FORM sub1 using value (p_a)

P – a = 15.

ENDORM.

By default system calls all the forms by reference.

In this case, only the address of the actual parameter is transferred to the formal parameters. The formal parameter has no memory of its own. If you change the formal parameter, change is visible in actual parameter also.

By Value and Return

Data : a type I value 20.

Perform sub1 changing a.

FORM sub1 changing value (p_a)

P – a = 15.

ENDORM.

In this case if you change formal parameter, then the value of actual parameter is changed when the control is transferred back to the main program.

Assuming A is declared by DATA statement and has value 20 and subroutine SUB1 is called by passing A.

CALLING FORM	VALUE OF A IN PROGRAM	VALUE OF A IN FORM (p_a = 15)
	BEFORE CALLING FORM	A = 20
	A = 20	P_A = 100
BY VALUE (USING)	AFTER RETURNING FROM FORM A = 20	(changing value of p_a) A = 20.
	BEFORE CALLING FORM	A = 20
	A = 20	P_A = 100
BY REFERENCE (USING)	AFTER RETURNING FROM FORM A = 20	(changing value of p_a) A = 100
BE VALUE AND RETURN	BEFORE CALLING FORM	A = 20
	A = 20	P_A = 100
(CHANGING)	AFTER RETURNING FROM FORM A = 100	(changing value of p_a) A = 100.

Passing Table to a Subroutine

You can pass internal tables as parameters USING or CHANGING in the FORM and PERFORM statements. If you want to access the components of the internal table, you must specify the type of the corresponding formal parameter.

You also must distinguish between internal tables with or without header lines. For internal tables with header lies, you must specify the table body by using square brackets [ ], after the table name to distinguish it from the header line.

With internal subroutines, you can use TYPE or LIKE to refer to the internal table you want to pass directly.

You can pass all internal tables as parameters in the list after TABLES in the FORM and PERFORM statements. Internal tables passed with TABLES are always called by reference.

If you pass all internal table with a header line, the table body and the table work area are passed to the subroutine. If you pass an internal table without a header line, a header line is created automatically as a local data object in the subroutine.

PROGRAM ZDEMO

DATA: Begin of itab occurs 0,

Number type I,

end of itab

PERFORM SUB1 TABLES ITAB.

LOOP AT ITAB.

WRITE: / itab-number.

ENDLOOP.

FORM SUB1 TABLES F_ITAB LIKE ITAB [ ].

DO 3 TIMES.

F_itab-number = SY-INDEX.

APPEND F_ITAB.

ENDDO.

ENDFORM.

After starting ZDEMO the output appears as follows:

In this example, an internal table ITAB is declared with a header line. ITAB is passed to the subroutine SUB1, where it is filled using the table work area F_ITAB. And itab is written in main program.

FUNCTIONS

Function modules are special external subroutines stored in a central library. The R/3 system provides numerous predefined function modules that you can call from your ABAP/4 programs, and plus you can create your own function modules.

The main difference between a function module and a normal ABAP/4 subroutine is as follows:

Function is stored in central library and has global presence while subroutines are confined to a particular program. Subroutine cannot return values while functions can return values. Unlike functions, subroutine cannot handle exceptions. And last but not least, the difference in the way the parameters are passed to functions.

Declaring data as common parts is not possible for function modules. The calling program and the called function module have separate work in ABAP/4 Dictionary tables.

You use the ABAP/4 Workbench to call, create, and maintain function modules.

You can combine several function modules to form a function group in the function library. Since you can define global data that can be accessed from all function modules of one function group, it is reasonable to include function modules that operate with the same data, for example internal table for sales module can be grouped, in one function group.

Via the ABAP/4 Development Workbench screen, choose Development ® Function Library or select Function Library in the application toolbar or use se37 transaction code.

The Function Library:

The function library maintains Function Modules, the screen displays following components:

All function names should start with Z_ or Y_ followed by any name.

¨ Source code

¨ Documentation

¨ Administrative info

¨ Import-export parameters

¨ Table parameters and exception interface

¨ Global data

¨ Main program

(Not necessarily in the same order)

Documentation

The documentation describes the purpose of the function module, lists the parameters for passing data to and from the module, and the exceptions. The parameters of the parameter type I are import parameters, which are used to pass data to the function module. Parameters of the parameter type E are export parameters, which are used to pass data from, the function module to the calling program. Exceptions describe error scenarios, which can occur in function modules.

Import-export parameters

Import parameters correspond to the formal input parameter of subroutines. They pass data from the calling program to the function module.

Export parameters correspond to the formal output parameters of subroutines. They pass data from the function module back to the calling program (which his not possible in subroutines)

Table parameters

Table parameters are internal tables. Internal tables are treated like changing parameters and are always passed by reference.

Exceptions

Exceptions are used to handle error scenarios, which can occur in function modules. The function module checks for any type of error and raise exception and returns SY-SUBRC to the calling program. Main program checks this SY-SUBRC for any errors that have occurred and then takes action accordingly.

Source Code

The ABAP/4 Edit screen displays the ABAP/4 source code of the function module. You can work with the source code in the same way as you would work with normal ABAP/4 programs.

Import parameters, changing parameters, and table parameters can be Optional. This means that you can omit the corresponding actual parameter when you call the function in the calling program. If the parameter is optional and the actual parameter is not specified, you can specify a default value for use in the function module. Export parameters are always optional.

As with subroutines, you can specify the data types of the formal parameters in the field Reference type. In the field Ref. structure, you can specify ABAP/4 Dictionary reference structures or fields. Then, the system checks the current parameter against the structure or field at runtime.

Testing of function module

You can test a function module without calling it from an ABAP/4 program via the Function Library: Maintain Function Modules screen by choosing Single test. You can assign values to the import parameters on the Test Function Modules screen.

Calling Function Modules

To call a function module from an ABAP/4 program, use the CALL statement as follows:

Syntax:

CALL FUNCTION <module>

[EXPORTING

f1 = s1

f2 = s2

fn = sn (parameters which you pass from program to function are

s1, s2, sn)]

[IMPORTING

f1 = r1

f2 = r2

fn = rn (parameters which program receives you pass from function in

r1, r2, rn)]

[TABLES f1 = a1 … fn = an]

EXCEPTIONS notvalid = 1

not correct = 2

OTHERS = 5].

You can specify the name of the function module <module> as a literal or as a variable. Parameters are passed to and from the function module by exactly assigning the actual parameters to the formal parameters in the lists after the EXPORTING, IMPORTING, TABLES.

If in your function if you have raised exception not valid then this exception can be handled in main program. Functions return different sy-subrc for different exceptions.

REPORTS

About reports

Reports, in the R/3 system are online programs whose function is to retrieve data from database and display it or print it for the user. An end user often needs some information to look up, depending upon which various management decisions are taken, or to just see business results or simply to continue work. As R/3 is collection of all business applications, it has provided a very powerful feature to satisfy this crucial business need i.e., reports are involved at each and every step of business. This type of extracting, collecting and formatting data that is stored in database is done by REPORT program.

The program that is written to retrieve and display data is REPORT program and the data that is displayed on the screen when you execute the program is called as LIST (output of the report).

SAP has provided thousands of preprogrammed reports. User just selects a menu option or just one click here and there, displays the report. Often user is unaware that by clicking one button he is executing a complicated report program, which is actually accessing database and then displaying the result. An end user might not feel the necessity of writing a REPORT program but a developer has to develop a report manually using the functions and facilities provided by the R/3 system. How to develop a report using these facilities, is the purpose of this section.

When you display data, you need to display the data, user needs. For example, user wants to see the all the employee, who has joined after 12^th December 1997. In this case user has to pass this information, to the system, that he needs only those employee records where joining data is greater than 12^th December 1997. For user, it is passing information to the system but for the system it is input from the user. System takes input from the user before it retrieves the data from the database. This is very common requirement of any report as the need of any business is to display data, which is required by user.

Selection criteria

System accepts inputs from user through SELECTION CRITERIA.

Selection criteria are nothing but input fields which allows the user to restrict information given to program for processing further data. If you don’t specify any criteria for selection, your report program produces a long list of data, which might not be needed by the user. Basically, selection criteria are the fields where user enters some value for which he needs information. Through selection criteria user can enter discrete value or ranges. For example, user wants to see all the records of the employees, who have joined between 12^th December 1997 and 12^th May 1998. This range can be entered in selection criteria. As the user becomes more specific for mentioning the criteria, the list will be smaller and more specific.

Syntax:

SELECT-OPTIONS <field> for <table field>.

Field is the variable, which you declare for accepting input from the user.

Table field is reference field.

SELECT-OPTIONS: fld1 for sflight-fldate,

carrid1 for sflight-carrid.

Maximum length of the name Select-Options variable is 8.

When system executes this statement, the selection screen is displayed and is like this.

When you enter the desired information and click on execute button, rest of the program is executed, that is retrieval of data from database, which matches this information and the list is displayed.

Behavior of SELECT-OPTIONS

When the Select-Options statement is executed the system creates the internal table with the same variable name (in this case it will be carrid1). This table is also called as selection table. The main purpose of selection table is to store selection criteria. The table has four standard fields, which are as follows:

¨ SIGN is a variable, which denotes the system whether the result should be included with those particular criteria. It can contain either I or E. I denotes Inclusion. The criteria are included.

E denotes Exclusion. The criteria are excluded from the result.

¨ LOW the data type of LOW is the same as the field type of the database table, for which you are using selection criteria. This acts as lower limit of the selection.

¨ HIGH the data type of HIGH is the same field type of the database table, for which you are using the selection criteria. This acts as higher limit. If you don’t enter HIGH value then the LOW value defines a single value selection.

¨ OPTION is two-character field, which contains operators like EQ, GT, LT, GE, and LE.

When the user enters both the values i.e., high and low then this field acts as BT (between). If you don’t enter high value then all other operators can be Applicable.

For each Select-Options statement system creates internal table.

Default values for select-options

If you want to display default values for the selection criteria before your screen is displayed, give default values for the selection table fields i.e., low or high.

SELECT-OPTIONS: CARRID1 FOR SFLIGHT-CARRID DEFAULT CARRID1-LOW = ‘LH’ AND CARRID1-HIGH = ‘SQ’.

In this case selection screen is displayed with default values ‘LH’ for lower range and ‘SQ’ for higher range. User can use same values or overwrite these values with new values, whichever he needs.

Standard report

The normal format of any report is as follows:

HEADING FOR THE LIST i.e., header area

LIST HEADERS

Detailed data

At the end of page you can have sub total of page number i.e., footer area

Usually any report has some page headings at the top of page and then data is displayed with column headings, followed by data and at the end of page may be some grand total or page number. Any such report can be displayed by using report program. Such report is called as

Classical Report.

Usually a standard report produced by system is one continuous page of 65k lines. The standard report can be declared as follows;

REPORT ZDEMO

By default the report produced by system is standard report. But when you need to have your report divided into pages of say 20 lines and you want to reserve some area for footer than you need to use following format of report statement:

REPORT ZDEMO line-count 20(3)

Line-size 75.

In this case the line count for one page is 20 lines, in which 3 lines are reserved for footer. You can display your data only in 17 lines. The width of page will be 75 characters.

As all of us know ABAP/4 is event driven language, the ABAP/4 processor controls the execution of events. For example in above report at the end of the page, you want to write the page number, reaching end of page is an event. Or whenever at the top of a page you want to write list headers, then in this event you can write the code for displaying the list headers. Report program is nothing but a set of events either controlled externally or internally. All above events are external events as the top portion of your page is reached on your screen or on your printer and is no way connected to your program. Internal events are those events, which are controlled inside the program i.e., either by if – endif statement or any other decision-making statement.

A sample report program without any events is as follows:

Report zdemo1.

Tables: sflight.

Select-options carrid1 for sflight-carrid.

* For accepting input from user.

Write: ‘This is my first report program’.

Write: / 10 ‘carrier id’, 20 ‘connection id’ 30 ‘flight date’.

* These two write statements are for writing heading and column headings.

Select * from sflight where carrid in carrid1.

Write: / 10 sflight-carrid, 20 sflight-connid, 30 sflight-fldate.

Endselect.

Write: / ‘page number:‘, sy-pagno.

In this case we are writing list headings for report. But these list headings are applicable only for the first page. If your list is spilling over multiple pages, then these list headings are not applicable to other pages. Again in this program, we write page number after all the data is displayed. This is fine as long as you have one page, but the moment your list spills over multiple pages, the page number will be displayed only after all the records are displayed. So in order to have some data like company name or list headings or page number or total of some number field on each page, you need to make use of events.

CLASSICAL REPORTS

Events in Classical report

Events associated with classical report are as follows and each one will be discussed in detail.

¨ INITIALIZATION

¨ AT SELECTION-SCREEN

¨ AT SELECTION-SCREEN ON <field>

¨ START-OF-SELECTION

¨ TOP-OF-PAGE

¨ END-OF-PAGE

¨ END-OF-SELECTION

In this case first three events are associated with selection screen. Rest of the events are associated with your list.

¨ INITIALIZATION

We have already seen how to fill default values for the selection criteria. But in many cases you need to calculate the value and then put it in selection criteria. For example, say, you are accepting date from user and you need to fill in the default value for lower range as sy-datum – 30 days and sy-datum for higher range. In this case you are calculating lower range and then filling the criteria. This can be done in INITIALIZATION event. Piece of code to do the above task would look like the following:

Tables: Sflight.

Select-options: fldate1 for sflight-fldate.

INITIALIZATION.

Data: date1 like SY-DATUM.

Date1 = sy-datum – 30.

Fldate1-low = date1.

Fldate1-high = sy-datum.

Append fldate1.

* Here appending is required because fldate1 is int’ table

This event is triggered when you execute your program for the first time i.e., before selection screen is displayed.

¨ AT SELECTION-SCREEN

When user enters the values in the fields of selection screen and clicks on execute button, this event gets triggered. This event is basically for checking the values entered by the user for the fields of the selection screen i.e., data validity checking. This event is for entire selection screen. For example:

You are accepting carrid, connid, fldate from user and you don’t want to proceed if user enters no value for carrid and fldate. Using AT SELECTION-SCREEN can do this.

Select-options: carrid1 for sflight-carrid,

Connid1 for sflight-connid,

F1date1 for sflight-f1date.

AT SELECTION-SCREEN.

If carrid1-low ne ‘ ’ and fldate1-low = ‘ ’.

Error message.

Endif.

In this case, if both the fields are entered blank, then the user gets error message.

Basically, this event is for many fields on selection screen. Usually, it is for the fields which are logically related.

¨ AT SELECTION-SCREEN ON <field>

When you want to check for specific value of a field. For example, carrid should be in the range of ‘LH’ and ‘SQ’. This can be done in this event. Basically, this event is for checking individual fields. You can have many AT selection-screen events in your program (i.e., for each field specified in the Select-Options).

Select-Options carrid1 for sflight-carrid.

AT SELECTION-SCREEN.

If carrid1-low ne ‘LH’ and carrid1-high ne ‘SQ’.

Error message.

Endif.

Here the system will not proceed on entering wrong values.

¨ START-OF-SELECTION

This is the first event for your list. Once all the events are triggered for selection screen, the data is retrieved from database. Data declaration, select statements are done in this event. Consider the following example:

START-OF-SELECTION.

Data: mtype i.

Tables: sflight.

Select * from sflight where carrid = ‘LH’.

Write: / sflight-carrid,sflight-connid.

Endselect.

¨ TOP-OF-PAGE

This event is triggered with first WRITE statement or whenever new page is triggered. Advantage of using this event is that, whatever you write under this event, is applicable to all the pages. If you don’t have any write statement before TOP-OF-PAGE or in START-OF-SELECTION, this event is not triggered at all. For example, if you want the name of company and column headers for all the pages, it can be written in this event.

TOP-OF-PAGE

Write: / ‘INTELLIGROUP ASIA PVT. LTD.’

Write : / 10 ‘carrid’, 20 ‘connid’, 30 ‘fldate’.

¨ END-OF-PAGE

This event is triggered at the end of page.

End-of-page.

Write : / ‘page number’, sy-pagno.

In this case page number will be written on every page.

Conditional triggering of EOP

Consider the following case.

REPORT ZDEMO1 line-count 15(3).

Top-of-page.

Write: ‘this line is written by top-of-page event’.

Start-of-selection.

Write: ‘this line is written by start-of-selection event’.

End-of-page.

Write : ‘this line is written by end-of-page event’.

In this case EOP will never be triggered, as end of page is never reached. The total Line-count defined for page = 15 in which 3 lines are for footer area. The output of the above code will be

This line is written by top of page event.

This line is written by start of selection event.

In output screen, only two lines are written and cursor remains still on 3^rd line, the end-of-page event is not triggered. To trigger end of page event, cursor should reach at the last position, in this case on 11^th line.

Such cases are quite common, and could be overcome by conditional triggering of end of page.

Sy-linct is the system variable, which gives total line count of a list.

Sy-linno is the system variable, which gives the current line number where the cursor is placed on the list.

Consider the following case:

Report zdemo1 line count 20(1).

Start-of-selection.

Data: m type i.

Write: / ‘this is first line’.

Do 5 times.

Write: / ‘the number is’, sy-index.

Enddo.

M = sy-linct, sy-linno – 1.

Skip x.

End-of-page.

Write: / ‘page end’.

The output of above example is as follows :

This is first line.

The number is 1

The number is 2

The number is 3

The number is 4

The number is 5

After skipping 10 lines

Page end

In this case, with all write statement, you don’t reach to the end of page. After all write statement, m is calculated in this case:

M = 20 – 8 – 1, So m is 12. And 11 lines are skipped after write statement and end of page is reached. (In this case you have 6 write statement so 6 lines + 1 line for page number and 1 horizontal line which is displayed for any list. So cursor is on 8^th line and is subtracted from total line count i.e, 20.)

Common errors that user commits

Stating of another event denotes the end of any event. If you forget to mention the next event then everything is included in the same event. Consider the following case:

AT SELECTION-SCREEN.

If carrid1-low ne ‘ ‘.

Err. or message.

Endif.

Write: / ‘INTELLIGROUP ASIA P. LTD.’

WRITE: / 10 ‘CARRID’, 20 ‘CONNID’, 30 ‘FLDATE’.

START-OF-SELECTION.

….

In this case all the write statement are included in the `at selection screen’ as top-of-page is not specified. The end of `at selection-screen’ is denoted by the starting of start-of-selection.

Though the sequence of events in program is immaterial, it is a good programming practice to write all the events in the order specified above.

Using Variants with selection criteria

In many cases you need report to execute report at regular interval for certain fixed values of selection criteria. That means each times you execute the report you need to enter its values again and again. ABAP/4 provides the facility by which you can define the values for selection screen and store it. Using VARIANTS can do this. It can be defined as group of values used for selection criteria while executing report. For a particular report, you create a variant which means variant created for particular report cannot be used for another report. The group of values for the selection criteria is saved and assigned a variant name. So every time you call a report, you need not specify the values for selection criteria but instead call the variant thus avoiding extra typing. User can have many variants for a single report. Each of them can be used as different type of information. For example, if a manager wants to see how an employee in personnel department or admin department has performed. He need not enter the department, one has to just execute the report with variant. In case he doesn’t know about the variant, which is available, he can display list of variants attached to the report and values assigned to each variant.

Creating variant

¨ Execute the report program. The selection screen is displayed.

¨ Enter the values for selection screen and click on saves.

- System displays the variant screen

¨ Enter the variant name and description for it.

¨ Save it.

Usually the variants are useful when you need to execute the report in background, which will be discussed in background processing.

.INTERACTIVE REPORTS

About interactive report

A classical report consists of one program that creates a single list. This means that when the list is displayed, it has to contain all the requested data, regardless of the number of details the user want to see. This procedure may result in extensive and cluttered lists from which the user has to pick the relevant data. The desired selections must be made before hand and the report must provide detailed information.

This is not possible using the classical report and for this ABAP/4 has provided reporting feature called INTERACTIVE REPORT. The list produced by classical report doesn’t allow user to interact with the system but the list produced by interactive report allows the user to interact with the system i.e., user can tell the system, that he needs further information. Depending upon what the user tells the system, the action is taken. Interactive reporting thus reduces information retrieval to the data actually required.

Interactive reporting allows the user to participate in retrieving and presenting data at each level during the session. Instead of presenting one extensive and detailed list with cluttered information, with interactive reporting you can create a condensed basic list from which the user can call detailed information by positioning the cursor and entering commands.

Detailed information is presented in secondary lists. A secondary list may either overlay the basic list completely or appear in an additional dialog window on the same screen. The secondary list can itself be interactive again. The basic list is not deleted when secondary list is created.

User can interact with the system by:

¨ Double clicking or pressing F2

¨ Selecting menu option

Like classical report, the interactive report is also event driven. Both the action mentioned above trigger events and code is written to handle these events. The events triggered by this action are as follows:

¨ At line-selection

¨ At user-command

¨ Top-of-Page During Line-Selection for Secondary Page Header info

Interactive report consists of one BASIC list and 20 secondary list. Basic list is produced by START-OF-SELECTION event. When the user double clicks on the basic list or chooses the menu option, the secondary list is produced. All the events associated with classical report except end-of-page are applicable only to basic list.

AT LINE-SELECTION event

Double clicking is the way most users navigate through programs. Double clicking on basic list or any secondary list triggers the event AT LINE-SELECTION. SY-LSIND denotes the index of the list currently created. For BASIC list it is always 0. Following piece of code shows how to handle the event.

Start-of-selection.

Write: / ‘this is basic list’.

At line-selection.

Write : ‘this is first secondary list’.

In this case the output will be displayed on basic list i.e.

This is basic list.

When user double clicks on this line, the event at line-selection gets triggered and secondary list is produced, i.e.

This is first secondary list.

You can go back to basic list by clicking on F3 or back icon on the standard tool bar. For this list, the value of sy-lsind will be 1.

HIDE technique

In this case thins are much simpler. Consider the case, wherein you display fields from table sflight in basic list. When user double clicks on any sflight-carrid, you are displaying the detailed information related to that particular carrid on secondary list. Hence there is a need to store the clicked carrid in some variable. So that you can access this carrid for next list. ABAP/4 has facility; a statement called HIDE, which provides the above functionality.

HIDE command temporarily stores the content of clicked field in system area.

Syntax:

HIDE <FIELDS>.

This statement stores the contents of variable <f> in relation to the current output line (system field SY-LINNO) internally in the so-called HIDE area. The variable <f> must not necessarily appear on the current line.

You have to place the HIDE statement always directly after the output statement i.e., WRITE for the variable <f>. As when you hide the variable, control is passed to next record. While writing, WRITE statement takes that record from header and writes it on to the list, but when writing onto your interactive list you will miss out 1^st record.

To hide several variables, use chain HIDE statement.

As soon as the user selects a line for which you stored HIDE fields, the system fills the variables in the program with the values stored. A line can be selected.

¨ By an interactive event.

For each interactive event, the HIDE fields of the line on which the cursor is positioned during the event are filled with the stored values.

The HIDE area is a table, in which the system stores the names and values of all HIDE fields for each list and line number. As soon as they are needed, the system reads the values from the table. (Please try to find the name of this table.)

Sy-lsind indicates the index of the list and can be used to handle all the secondary lists. When the user double clicks on the line or presses F2, sy-lsind is increased by one and this new sy-lsind can be handled. For example:

Write: / ‘this is basic list’.

· Will create a basic list.

If sy-lsind = 1.

Write: / ‘this is first secondary list’.

Elseif sy-lsind = 2.

Write: / ‘This is second secondary list’.

Endif.

When this code is executed,

· Basic list is produced.

· When the user clicks on the basic list, sy-lsind becomes one.

· AT LINE-SELECTION event is triggered.

· Whatever is written under IF Sy-lsind = 1, gets executed.

· Secondary list is produced.

· Again if user clicks on this list, sy-lsind becomes two.

· AT LINE-SELECTION gets triggered.

· Code written under IF Sy-lsind = 2, gets executed.

A sample program for AT LINE-SELECTION.

User interface

An interactive report starts with basic list where condensed information is stored on basic list and detailed information is stored on secondary list. To implement this kind of reporting, you need to provide the user with things like menu, icons, function keys. You also need to write code, which must react, to the user’s action.

For this, you need to create the interface, which interacts with the user.

The user interface is independent of the program or list or screen. However both interface and list can be associated by means of GUI status. A GUI status groups together the interface components.

¨ Menu bar

¨ Application tool bar

¨ Function keys

¨ Title bar

The last element of the user interface is independent of the GUI status i.e., titlebar.

To assign status to your list the statement SET PR-STATUS.

Some facts about GUI status are:

¨ A program can have multiple GUI status and titles for different lists.

¨ Multiple lists can be assigned to same GUI status.

¨ Normally both GUI status and title go together.

Function code

An important concept, when working with user interface. Function is a four character alphanumeric code, which the system stores in the system variable called SY-UCOMM for each function key, push button, or menu option. Whenever any push button is clicked or menu option is selected, the code attached to that, is stored in SY-UCOMM and can be handled in your program.

Menu painter

Menu painter is the ABAP/4 workbench tool for creating and maintaining user interface.

Starting Menu Painter

ABAP/4 development workbench ® menu painter

Transaction SE41 in the command field.

Through program SET PF-STATUS <var>

If you double click on the variable, the system takes you to the menu painter screen.

Creating Menu bar

Steps involved are as follows:

¨ Enter the name in the first field. It is just a name given to the menu and is not displayed anywhere in the output.

¨ Enter the name of each menu item. You can create up to six menus (total eight menu items are available, out of which system and help are mandatory).

¨ Enter name of the menu items and function code. You can have fifteen menu items under one menu.

If you leave function blank, the system assumes that this particular menu item will have submenu. You can create the sub menu items under this menu item. User can go up to three levels.

Creating Application Tool Bar

Assign Function Keys

In Application tool bar you can include icon assigned for function keys.

Procedure:

¨ Select function key.

¨ From the menu, more utilities - ® change text type. The system displays a dialog box, click on icon and presses ENTER.

¨ Select icon from list of icons displayed

Creating GUI title

From your program, you can set title for your list and SET TITLEBAR is used.

Syntax:

SET TITLEBAR <var>.

Here var can be any three-character name. When developer double clicks on the var, system displays the dialog box in which you enter the title number, the description, and the actual text for title.

Similar to dictionary objects, the GUI status must be generated to be accessible by program.

AT USER-COMMAND

When the user selects the menu item or presses any function key, the event that is triggered is AT USER-COMMAND, and can be handled in the program by writing code for the same. The system variable SY-UCOMM stores the function code for the clicked menu item or for the function key and the same can be checked in the program. Sample code would look like

AT USER-COMMAND.

Case sy-ucomm.

When ‘DISP’.

Select * from sflight.

Write sflight-carrid, sflight-connid.

Endselect.

When ‘EXIT’.

LEAVE.

If GUI status, suppose you have set menu bar for two items and the function code is ‘DISP’ and ‘EXIT’ respectively. If the user clicks the menu item ‘DISPLAY’, then function code ‘DISP’ is stored in the sy-ucomm and whatever is written under the when ‘DISP’, gets executed. This is applicable for EXIT as well.

Sy-lsind for the screen increases when the user clicks the menu item.

Usually you have combination of all the three navigations in your user interface, i.e., you have to create menu bar, assign function code for the function keys and write code to handle all this in addition to handling double clicking.

Things to remember while using all the combinations:

¨ Sy-lsind increases even if you select menu-item.

¨ When the user double clicks on particular line, value of sy-ucomm is ‘PICK.

¨ If you set sy-lsind = 2 for your 4^th secondary list, when control is transferred to the 2^nd secondary list, all the other lists after 2^nd are lost or memory allocated to them is lost.

¨ Sy-lisel also gives you the value of clicked line but in this case you cannot differentiate between field. To retrieve the exact field, you have to know the field length of each field.

¨ If you use statement SY-LSIND = 1.

The system reacts to a manipulation of SY-LSIND only at the end of an event, directly before displaying the secondary list. So, if within the processing block, you use statements whose INDEX options access the list with the index SY-LSIND, make sure that you manipulate the SY-LSIND field only after processing these statements. The best way is to have it always at the `as the last statement’ of the processing block.

Important system fields for reports

Sy-linct - Gives total line numbers for a page.

Sy-linno - Gives current line number on the list

Sy-lsind - Index of the lists created in interactive report

Sy-listi - Index of the list from where event was triggered, usually previous list

Sy-lilli - Line number of a list from where event was triggered

Sy-lisel - Contents of a line from where event was triggered

Sy-ucomm - Holds the function code of clicked menu item or function key

EXERCISES

INTERNAL TABLES and REPORTS

1 Create an internal table taking all the fields from BKPF and display fields Company code, Document number, Document type and date of document.

2 Create an internal table taking fields’ Company code, Document number, Account type and Tax code from table BSEG and display the same with column headings.

3 Create an internal table with following fields:

Sales Document and Material from table VBAP.

Date, Name of the user and sales document type from table VBAK and

Price group and customer group from table VBKD.

Sort the table according to Material number and display the contents.

4 Create an internal table called T_BSIS having a similar structure as table BSIS. Explore all possible methods to create the internal table with header line / without header line. (use data types, data … begin of ….end of, data …. data …. Include structure … etc.)

Also create a field string F_BSIS. Populate the internal code and display contents of BSIS. Sort the table according to company code and display contents.

5 Determine for each material type (MTART) the 5 table entries with the highest gross weight (as a ranked list).

To do this, read the table MARA and store the material type (MTART), material number (MATNR), unit of measure (MEINS) and gross weight (BRGEW) into an internal table.

Allow the user to specify the Material type as a parameter on the selection screen.

6 Create a list of the maximum number of available seats for each carrier. To do this, read the table SFLIGHT and store the airline carrier id (CARRID) and maximum number of seats (SEATSMAX) in an internal table. Determine the total number of seats for each airline carrier when filing the int’ table.

7 Read the table SFLIGHT into an internal table and then output the internal table with the fields CARRID, FLDATE and PRICE.

Delete all the internal table entries where the airline carrier (CARRID) is not equal to LH. Read the internal table with entry with the key CARRID = LH and CONNID = 0400, multiply the price by 3 and write the modified entry back to the internal table. Then Output the internal table.

8 Read table TABNA into internal table and output the fields Country, Id, Name1, and Sales. Sort the table with Country.

Delete all internal table lines with sales lower than 50,000.

Read internal table with key ‘GB’ and ‘00000003’ and multiply the sales by 3 and change table entry.

Insert any one record of your choice.

Find out how many lines are there in the internal table.

Remove all the contents of the table.

De-allocate the memory associated with table.

9 Use tables LFA1, LFB1 and LFM1.

Define an internal table with the following:

Lifnr like Lfa1-lifnr,

Bukrs like Lfb1-bukrs,

Ekorg like Lfm1-ekorg.

Add data from these table into the internal tables.

Sort the internal table Lifnr.

Read the internal table with Lifnr = ‘A5’ and change name to trainee.

Put back the record into the table.

Delete first three records of internal table.

Clear header for internal table each time you access a record.

10 Create a report, which will give the existing stock for a material. The report should have subtotal of the stock for each storage location and Grand total of the stock at the end of the plant.

Plant data should start at new page.

Input: Selection screen which will allow one to select a range of materials.

Materials:

Output Report format as follows:

Plant	Storage location	Material number	Description	Stock (unrestricted)


		Grand total		* * * * * *

Tables and fields:

Material Number MARA-MATNR

Description MAKT-MAKTX

Plant MARC-WERKS

Storage location MARD-LGORT

Stock MARD-LABST

Use Standard Formatting colors.

Exception handling:

Error message “ Material not found “ – if Material not present.

11 Generate a report to list the following details from the tables LFA1 & LFB1 vendor no., vendor name, city, state, telephone no., fax no., company code and terms of payment. User shall have options to select the vendor number range for which the report is generated.

Report title: Vendor Master Listing 2

Vendor Name: _____________ Vendor no. : _____________

Address: __________________

Telephone no. _______________ Fax no : ______________

Company code Terms of payments

_____________ _________________

All text used in the report shall be generated using text elements only.

The output list shall have a footer showing page no., date and Intelligroup’(left corner)

12 Generate a report for displaying material description, plant & storage data.

Input: Material number (MARA-MATNR)

Data to be displayed for the following three materials only.

1. BP770M15

2. FP56790031

3. FP28652011

Output format:

11/11/1998 Report to analyze material stocks

Material No. Description

FP96412101 Meditech Patterned Weld Rod

Oatmeal 60’

Plant Storage Loc. Unrestricted stock

xxxx xxxxxxxxxxx xxxxxxxxxxxxxxx

All texts are to be generated using Text Elements only.

Use tables: MARA, MAKT, MARC and MARD.

SUBROUTINES

1. Read a number between 0 and 100 and another digit between 0 and 9. Write a subroutine that will calculate the sum of all numbers (below the limit) that end with the digit. The parameters to be passed are limit and digit both by value and sum by reference.

Ex. If limit = 67 and digit = 4 then sum should be the sum of 4,14,24,34, ..64.

2. Write a subroutine CENTRE-STRING, which will output a string on the center of a line. The subroutine will accept parameters STRING pass by value.

3. Write a program extensively using subroutines to print the equivalent number in words.

For example: if the number is 66, the output should be SIXTY SIX.

Limit the number range from 0 – 99.

Accept the input number as a parameter.

4. Accept a date from the user.

Write a date as dd-mm-yyyy where mm is month written as JAN/FEB/Mar…etc.

Make use of subroutines.

2012-09-22T22:53:00.005-07:00

BATCH DATACOMMUNICATIONS/BATCH INPUT/INBOUND-OUTBOUND

ABOUT DATA TRANSFER

Implementing a new software system takes major effort. New implementation requires moving data from the present system i.e., legacy system into the R3 system. The product, components, customers and vendors have to be available in the new system. Initial data transfer is the process of populating your R3 database with data from your legacy system.

To prepare for the data transfer there are certain tasks you need to perform.

¨ First, understand your SAP system to know which data needs to be transferred, e.g., you would not transfer any sales order if you do not use the Sales and distribution module.

¨ Second, you need to know the contents of existing data in your legacy system.

Data transfer program, an effective and efficient way of transferring large amount of data into your new system, saves time and resources. But more importantly it ensures that accurate data is transferred into R/3.

Two steps involved in data transfer are CONVERSION and SAP DATA TRANSFER.

¨ CONVERSION, data is converted from your legacy system into the required flat file format.

¨ SAP DATA TRANSFER, data is automatically entered into the SAP system. A SAP data transfer program reads the prepared data from the flat file and moves it into R/3.

Steps for any data transfer

Preparation for legacy database

This is the first step of transfer though not associated with SAP, plays very important role in data transfer.

Before data is extracted, delete obsolete data in the legacy system and fix inconsistencies. It is easier this way, than doing it during conversion.

The two steps involved in this are:

Data purging: Before transferring data from legacy system, delete all the old and obsolete data, e.g.: To save conversion time and disk space, you may delete all one-time customers, vendors and all unused materials.

Data cleansing: This process corrects data inconsistencies and ensures the integrity of the existing data during the transfer process. Mistakes must be fixed before the transfer.

Converting legacy data to the flat file

For this second step, SAP provides no specific tools.

¨ In the ABAP/4 development workbench, write an ABAP/4 program to convert a file from your legacy system into the required flat file structure.

¨ Use other programming language to write conversion program. For C, COBOL, you can easily download the table definition for specific flat file structure.

¨ Use third party tools, such as format editors and code generators, which support mapping and conversion between different file formats.

¨ For other RDBMS like oracle, Sybase, MS access, you have EXPORT utility. By which, you can directly export data to flat file.

Files will be discussed in detail in later part of the topic.

Getting the data into R/3

This step actually transfers data to SAP database. After converting the data into the flat file you are ready to begin the third step of the data transfer.

Data transfer is an interactive process. You may often feel like you are taking two steps forward and one step back.

For example, short steps involved in whole process are as follows:

¨ Convert the data from the legacy system into the flat file format.

¨ Run the data transfer program.

¨ Check data for error.

¨ Is the transfer working as it was designed?

¨ If not, adjust the data/conversion program and start with step 1. Go back to step one, if you don’t get the desired result.

You have three different options to enter your data into R/3.

¨ Automatically, with SAP standard data transfer programs.

¨ Automatically, by creating your own branch input programs

¨ Manually, by entering the data via the corresponding online transaction.

Automatic transfer with a standard data transfer program

This can be done if:

¨ A standard program exists for the data transfer of a business object in R/3.

¨ The data is available in electronic form.

¨ There is a significant number of records you want to transfer.

¨ The cost of converting the legacy data into the required flat file format is acceptable.

Manually transferring business objects

You should manually transfer data, if:

¨ You have no legacy system.

¨ There is only small number of records to enter.

¨ Translating legacy data into the R/3 structure is more an effort than manually entering the data.

Using customer specific batch input to transfer business objects

Create batch input program to transfer data if:

¨ No standard program exists to transfer the business object in R/3.

¨ The data is available in electronic form.

¨ There is a significant number of records you want to transfer.

¨ Translating your legacy data into the structure required by your custom program is easier than manually entering data.

Batch input is a standard procedure for transferring large amount of data into the R/3 system. It simulates manual data entry. Data consistency is ensured because batch input uses all the checks conducted on the normal screen. Using batch input is like entering the data online. Another advantage to batch input is that you do not have to check the data in advance.

Batch input is a two-step procedure. It involves a program that creates the batch input session. This session is the data file that includes everything to begin the transaction and the data to be entered on the appropriate screens. The data is not yet in the database tables of R/3 application. The second step is to process the session, which then actually transfers the data to database table. You can transfer data directly to database table by using CALL TRANSACTION method also. Another method - Direct Input, is done for high volume of data for the standard application. All these methods are discussed in detail in later part of the topic.

Basically there are two steps involved in any transfer of data from legacy system to SAP system.

- Creation of file and transferring file into SAP system

- Transferring data to database file

Whenever, you create flat file following points should be considered:

- Provide the data in an ASCII/Text file format.

- Know how each line of the file is structured.

- Know how the required flat file for the business object must be structured.

- Once your flat file is ready, the data should be transferred into SAP system.

FILE HANDLING IN SAP

Introduction

¨ Files on application server are sequential files.

¨ Files on presentation server / workstation are local files.

¨ A sequential file is also called a dataset.

Handling of Sequentialfile

Three steps are involved in sequential file handling

¨ OPEN

¨ PROCESS

¨ CLOSE

Here processing of file can be READING a file or WRITING on to a file.

OPEN FILE

Before data can be processed, a file needs to be opened.

After processing file is closed.

Syntax:

OPEN DATASET <file name> FOR {OUTPUT/INPUT/APPENDING}

IN {TEXT/BINARY} MODE

This statement returns SY_SUBRC as 0 for successful opening of file or 8, if unsuccessful.

OUTPUT: Opens the file for writing. If the dataset already exists, this will place the cursor at the start of the dataset, the old contents get deleted at the end of the program or when the CLOSE DATASET is encountered.

INPUT: Opens a file for READ and places the cursor at the beginning of the file.

FOR APPENDING: Opens the file for writing and places the cursor at the end of file. If the file does not exist, it is generated.

BINARY MODE: The READ or TRANSFER will be character wise. Each time ‘n’’ characters are READ or transferred. The next READ or TRANSFER will start from the next character position and not on the next line.

IN TEXT MODE: The READ or TRANSFER will start at the beginning of a new line each time. If for READ, the destination is shorter than the source, it gets truncated. If destination is longer, then it is padded with spaces.

Defaults: If nothing is mentioned, then defaults are FOR INPUT and in BINARY MODE.

PROCESS FILE:

Processing a file involves READing the file or Writing on to file TRANSFER.

TRANSFER Statement

Syntax:

TRANSFER <field> TO <file name>.

<Field> can also be a field string / work area / DDIC structure.

Each transfer statement writes a statement to the dataset. In binary mode, it writes the length of the field to the dataset. In text mode, it writes one line to the dataset.

If the file is not already open, TRANSFER tries to OPEN file FOR OUTPUT (IN BINARY MODE) or using the last OPEN DATASET statement for this file.

IF FILE HANDLING, TRANSFER IS THE ONLY STATEMENT WHICH DOES NOT RETURN SY-SUBRC

READ Statement

Syntax:

READ DATASET <file name> INTO <field>.

<Field> can also be a field string / work area / DDIC structure.

Each READ will get one record from the dataset. In binary mode it reads the length of the field and in text mode it reads each line.

CLOSE FILE:

The program will close all sequential files, which are open at the end of the program. However, it is a good programming practice to explicitly close all the datasets that were opened.

Syntax:

CLOSE DATASET <file name>.

SY-SUBRC will be set to 0 or 8 depending on whether the CLOSE is successful or not.

DELETE FILE:

A dataset can be deleted.

Syntax:

DELETE DATASET <file name>.

SY-SUBRC will be set to 0 or 8 depending on whether the DELETE is successful or not.

Pseudo logic for processing the sequential files:

For reading:

Open dataset for input in a particular mode.

Start DO loop.

Read dataset into a field.

If READ is not successful.

Exit the loop.

Endif.

Do relevant processing for that record.

End the do loop.

Close the dataset.

For writing:

Open dataset for output / Appending in a particular mode.

Populate the field that is to be transferred.

TRANSFER the filed to a dataset.

Close the dataset.

Handling of local files

Introduction

Files on presentation server / workstation are LOCAL FILES.

Local files are processed using UPLOAD and DOWNLOAD functions. The local files are brought into ABAP/4 memory using these functions. Unlike dataset, all the records of the file are UPLOADED into an internal table in one shot. Similarly, all records are DOWNLOADED in one shot from an internal table to a local file.

DOWNLOAD function:

Important EXPORTING parameters for this function are:

Filename = name of the local file to which the internal table is to be downloaded.

Filetype = file type, default values are ASC, DAT, BIN

Mode = Write mode, overwrite (‘ ‘) or append (‘A’)

Important IMPORTING parameters are:

Filename = actual file name entered

Tables to be passed to the function:

Data_tab = the internal table that is to be downloaded.

Similar function called WS_DOWNLOAD is used to download the information from internal table to local file. The only difference between DOWNLOAD and WS_DOWNLOAD is that, DOWNLOAD does not require the ‘FILENAME’ and ‘FILETYPE’ to be exported to the function; instead it will ask for the same at runtime. However, for WS_DOWNLOAD, these two parameters need to be passed.

UPLOAD function

Upload function is used to upload the local file to internal table into SAP system.

Parameters passed are similar to DOWNLOAD function.

For uploading, you have similar function called WS_UPLOAD.

Files with multiple record types

Many times the input files will have records with different structures. In all such cases each record will have a field, (usually the first) which identifies the record (e.g., ‘H’ for header, ‘D’ for detail or ‘1’ & ‘2’ etc).

Text tile with multiple record types would be as mentioned below:

Hxxxxyyyyyyyynnnnnnnnn

Daaaaaaaaaabbbbbbbbbcccccccc

Daaaaaaaaaabbbbbbbbbbcccccccc

Hxxxxyyyyyyynnnnnnnnnnn

Daaaaaaaaaabbbbbbbbbbcccccccc

Processing Text file with multiple record types:

To process such files, it is necessary to first read the record into a character field that is a minimum of the lengths of the different structure in the file. If ‘H’ type record is 30 char long (including the record identifier) and ‘D’ type is 40 long (including the record identifier), then this character field should be at least 40 char long.

Pseudo logic for processing the sequential files with multiple record types (text mode):

Open dataset.

Do.,

Read dataset into character field.

If sy-subrc ne 0.

Exit.

Endif.

If record id of the char field (or the first of field) is ‘H’

Do processing for ‘H’ type of records.

Else.

Do processing for d type of records.

Endif.

Enddo.

Pseudo logic for processing the local files with multiple record types:

WS_UPLOAD into itab.

Loop at itab.

If itab-recid is ‘H’.

Do processing for ‘H’ type record.

Else.

Do processing for ‘D’ type record.

Endif.

Endloop.

BATCH DATA COMMUNICATION

About Data Transfer In R/3 System

When a company decides to implement the SAP R/3 to manage business-critical data, it usually does not start from a no-data situation. Normally, a SAP R/3 project comes into replace or complement existing application.

In the process of replacing current applications and transferring application data, two situations might occur:

¨ The first is when application data to be replaced is transferred at once, and only once.

¨ The second situation is to transfer data periodically from external systems to SAP and vice versa.

¨ There is a period of time when information has to be transferred from existing application, to SAP R/3, and often this process will be repetitive.

The SAP system offers two primary methods for transferring data into SAP systems. From non-SAP systems or legacy system. These two methods are collectively called “batch input” or “batch data communication”.

1. SESSION METHOD

2. CALL TRANSACTION

3. DIRECT INPUT

Advantages offered by BATCH INPUT method:

1. Can process large data volumes in batch.

2. Can be planned and submitted in the background.

3. No manual interaction is required when data is transferred.

4. Data integrity is maintained as whatever data is transferred to the table is through transaction. Hence batch input data is submitted to all the checks and validations.

To implement one of the supported data transfers, you must often write the program that exports the data from your non-SAP system. This program, known as a “data transfer” program must map the data from the external system into the data structure required by the SAP batch input program.

The batch input program must build all of the input to execute the SAP transaction.

Two main steps are required:

¨ To build an internal table containing every screen and every field to be filled in during the execution of an SAP transaction.

¨ To pass the table to SAP for processing.

Prerequisite for Data Transfer Program

Writing a Data Transfer Program involves following prerequisites:

Analyzingdata from local file

Analyzing transaction

Analyzing transaction involves following steps:

¨ The transaction code, if you do not already know it.

¨ Which fields require input i.e., mandatory.

¨ Which fields can you allow to default to standard values.

¨ The names, types, and lengths of the fields that are used by a transaction.

¨ Screen number and Name of module pool program behind a particular transaction.

To analyze a transaction::

¨ Start the transaction by menu or by entering the transaction code in the command box.

(You can determine the transaction name by choosing System – Status.)

¨ Step through the transaction, entering the data will be required for processing your batch input data.

¨ On each screen, note the program name and screen (dynpro) number.

(dynpro = dyn + pro. Dyn = screen, pro = number)

¨ Display these by choosing System – Status. The relevant fields are Program (dynpro) and Dynpro number. If pop-up windows occur during execution, you can get the program name and screen number by pressing F1 on any field or button on the screen.

The technical info pop-up shows not only the field information but also the program and screen.

¨ For each field, check box, and radio button on each screen, press F1 (help) and then choose Technical Info.

Note the following information:

- The field name for batch input, which you’ll find in its own box.

- The length and data type of the field. You can display this information by double clicking on the Data Element field.

¨ Find out the identification code for each function (button or menu) that you must execute to process the batch-input data (or to go to new screen).

Place the cursor on the button or menu entry while holding down the left mouse button. Then press F1.

In the pop-up window that follows, choose Technical info and note the code that is shown in the Function field.

You can also run any function that is assigned to a function key by way of the function key number. To display the list of available function keys, click on the right mouse button. Note the key number that is assigned to the functions you want to run.

Once you have program name, screen number, field name (screen field name), you can start writing.

DATA TRANSFER program.

Declaring internal table

First Integral Table similar to structure like local file.

Declaring internal table like BDCDATA

The data from internal table is not transferred directly to database table, it has to go through transaction. You need to pass data to particular screen and to particular screen-field. Data is passed to transaction in particular format, hence there is a need for batch input structure.

The batch input structure stores the data that is to be entered into SAP system and the actions that are necessary to process the data. The batch input structure is used by all of the batch input methods. You can use the same structure for all types of batch input, regardless of whether you are creating a session in the batch input queue or using CALL TRANSACTION.

This structure is BDCDATA, which can contain the batch input data for only a single run of a transaction. The typical processing loop in a program is as follows:

¨ Create a BDCDATA structure

¨ Write the structure out to a session or process it with CALL TRANSACTION USING; and then

¨ Create a BDCDATA structure for the next transaction that is to be processed.

Within a BDCDATA structure, organize the data of screens in a transaction. Each screen that is processed in the course of a transaction must be identified with a BDCDATA record. This record uses the Program, Dynpro, and Dynbegin fields of the structure.

The screen identifier record is followed by a separate BDCDATA record for each value, to be entered into a field. These records use the FNAM and FVAL fields of the BDCDATA structure. Values to be entered in a field can be any of the following:

¨ Data that is entered into screen fields.

¨ Function codes that are entered into the command field. Such function codes execute functions in a transaction, such as Save or Enter.

The BDCDATA structure contains the following fields:

¨ PROGRAM: Name of module pool program associated with the screen. Set this field only for the first record for the screen.

¨ DYNPRO: Screen Number. Set this field only in the first record for the screen.

¨ DYNBEGIN: Indicates the first record for the screen. Set this field to X, only for the first record for the screen. (Reset to ‘ ‘ (blank) for all other records.)

¨ FNAM: Field Name. The FNAM field is not case-sensitive.

¨ FVAL: Value for the field named in FNAM. The FVAL field is case-sensitive. Values assigned to this field are always padded on the right, if they are less than 132 characters. Values must be in character format.

Transferring data from local file to internal table

Data is uploaded to internal table by UPLOAD of WS_UPLOAD function.

Population of BDCDATA

For each record of internal table, you need to populate Internal table, which is similar to BDCDATA structure.

All these five initial steps are necessary for any type of BDC interface.

DATA TRANSFER program can call SESSION METHOD or CALL TRANSACTION. The initial steps for both the methods are same.

First step for both the methods is to upload the data to internal table. From Internal Table, the data is transferred to database table by two ways i.e., Session method and Call transaction.

SESSION METHOD

About Session method

In this method you transfer data from internal table to database table through sessions.

In this method, an ABAP/4 program reads the external data that is to be entered in the SAP System and stores the data in session. A session stores the actions that are required to enter your data using normal SAP transaction i.e., Data is transferred to session which in turn transfers data to database table.

Session is intermediate step between internal table and database table. Data along with its action is stored in session i.e., data for screen fields, to which screen it is passed, the program name behind it, and how the next screen is processed.

When the program has finished generating the session, you can run the session to execute the SAP transactions in it. You can either explicitly start and monitor a session or have the session run in the background processing system.

Unless session is processed, the data is not transferred to database table.

BDC_OPEN_GROUP

You create the session through program by BDC_OPEN_GROUP function.

Parameters to this function are:

¨ User Name: User name

¨ Group: Name of the session

¨ Lock Date: The date on which you want to process the session.

¨ Keep: This parameter is passed as ‘X’ when you want to retain session after

processing it or ‘ ‘ to delete it after processing.

BDC_INSERT

This function creates the session & data is transferred to Session.

Parameters to this function are:

¨ Tcode: Transaction Name

¨ Dynprotab: BDC Data

BDC_CLOSE_GROUP

This function closes the BDC Group. No Parameters.

Some additional information for session processing

When the session is generated using the KEEP option within the BDC_OPEN_GROUP, the system always keeps the sessions in the queue, whether it has been processed successfully or not.

However, if the session is processed, you have to delete it manually. When session processing is completed successfully while KEEP option was not set, it will be removed automatically from the session queue. Log is not removed for that session.

If the batch-input session is terminated with errors, then it appears in the list of INCORRECT session and it can be processed again. To correct incorrect session, you can analyze the session. The Analysis function allows to determine which screen and value has produced the error. If you find small errors in data, you can correct them interactively, otherwise you need to modify batch input program, which has generated the session or many times even the data file.

CALL TRANSACTION

About CALL TRANSACTION

A technique similar to SESSION method, while batch input is a two-step procedure, Call Transaction does both steps online, one after the other. In this method, you call a transaction from your program by

Call transaction <tcode> using <BDCTAB>

Mode <A/N/E>

Update <S/A>

Messages into <MSGTAB>.

Parameter – 1 is transaction code.

Parameter – 2 is name of BDCTAB table.

Parameter – 3 here you are specifying mode in which you execute transaction

A is all screen mode. All the screen of transaction are displayed.

N is no screen mode. No screen is displayed when you execute the transaction.

E is error screen. Only those screens are displayed wherein you have error record.

Parameter – 4 here you are specifying update type by which database table is updated.

S is for Synchronous update in which if you change data of one table then all the related Tables gets updated. And sy-subrc is returned i.e., sy-subrc is returned for once and all.

A is for Asynchronous update. When you change data of one table, the sy-subrc is returned. And then updating of other affected tables takes place. So if system fails to update other tables, still sy-subrc returned is 0 (i.e., when first table gets updated).

Parameter – 5 when you update database table, operation is either successful or unsuccessful or operation is successful with some warning. These messages are stored in internal table, which you specify along with MESSAGE statement. This internal table should be declared like BDCMSGCOLL, a structure available in ABAP/4. It contains the following fields:

1. Tcode: Transaction code

2. Dyname: Batch point module name

3. Dynumb: Batch input Dyn number

4. Msgtyp: Batch input message type (A/E/W/I/S)

5. Msgspra: Batch input Lang, id of message

6. Msgid: Message id

7. MsgvN: Message variables (N = 1 - 4)

For each entry, which is updated in database, table message is available in BDCMSGCOLL. As BDCMSGCOLL is structure, you need to declare a internal table which can contain multiple records (unlike structure).

Steps for CALL TRANSACTION method

1.	Internal table for the data (structure similar to your local file)
2.	BDCTAB like BDCDATA
3.	UPLOAD or WS_UPLOAD function to upload the data from local file to itab. (Considering file is local file)
4.	Loop at itab. Populate BDCTAB table. Call transaction <tcode> using <BDCTAB> Mode <A/N/E> Update <S/A>. Refresh BDCTAB. Endloop. (To populate BDCTAB, You need to transfer each and every field)

The major differences between Session method and Call transaction are as follows:

	SESSION METHOD	CALL TRANSACTION
1.	Data is not updated in database table unless Session is processed.	Immediate updation in database table.
2.	No sy-subrc is returned.	Sy-subrc is returned.
3.	Error log is created for error records.	Errors need to be handled explicitly
4.	Updation in database table is always synchronous	Updation in database table can be synchronous Or Asynchronous.

Error Handling in CALL TRANSACTION

When Session Method updates the records in database table, error records are stored in the log file. In Call transaction there is no such log file available and error record is lost unless handled. Usually you need to give report of all the error records i.e., records which are not inserted or updated in the database table. This can be done by the following method:

Steps for the error handling in CALL TRANSACTION

1.	Internal table for the data (structure similar to your local file)
2.	BDCTAB like BDCDATA
3.	Internal table BDCMSG like BDCMSGCOLL
4.	Internal table similar to Ist internal table
	(Third and fourth steps are for error handling)
5.	UPLOAD or WS_UPLOAD function to upload the data from the local file to itab. (Considering file is local file)
6.	Loop at itab. Populate BDCTAB table. Call transaction <tr.code> using <Bdctab> Mode <A/N/E> Update <S/A> Messages <BDCMSG>. Perform check. Refresh BDCTAB. Endloop.
7	Form check. IF sy-subrc <> 0. (Call transaction returns the sy-subrc if updating is not successful). Call function Format_message. (This function is called to store the message given by system and to display it along with record) Append itab2. Display the record and message.

DIRECT INPUT

About Direct Input

In contrast to batch input, this technique does not create sessions, but stores the data directly. It does not simulate the online transaction. To enter the data into the corresponding database tables directly, the system calls a number of function modules that execute any necessary checks. In case of errors, the direct input technique provides a restart mechanism. However, to be able to activate the restart mechanism, direct input programs must be executed in the background only. Direct input checks the data thoroughly and then updates the database directly.

You can start a Direct Input program in two ways;

Start the program directly

This is the quickest way to see if the program works with your flat file. This option is possible with all direct input programs. If the program ends abnormally, you will not have any logs telling you what has or has not been posted. To minimize the chance of this happening, always use the check file option for the first run with your flat file. This allows you to detect format errors before transfer.

Starting the program via the DI administration transaction

This transaction restarts the processing, if the data transfer program aborts. Since DI document are immediately posted into the SAP D/B, the restart option prevents the duplicate document posting that occurs during a program restart (i.e., without adjusting your flat file).

Direct input is usually done for standard data like material master, FI accounting document, SD sales order and Classification for which SAP has provided standard programs.

First time you work with the Direct Input administration program, you will need to do some preparation before you can transfer data:

- Create variant

- Define job

- Start job

- Restart job

Common batch input errors

- The batch input BDCDATA structure tries to assign values to fields which do not exist in the current transaction screen.

- The screen in the BDCDATA structure does not match the right sequence, or an intermediate screen is missing.

- On exceptional occasions, the logic flow of batch input session does not exactly match that of manual online processing. Testing the sessions online can discover by this.

- The BDCDATA structure contains fields, which are longer than the actual definition.

- Authorization problems.

RECORDING A BATCH INPUT

A B recording allows you to record a R/3 transaction and generate a program that contains all screens and field information in the required BDC-DATA format.

You can either use SHDB transaction for recording or

SYSTEM ® SERVICES ® BATCH INPUT ® EDIT

And from here click recording.

Enter name for the recording.

(Dates are optional)

Click recording.

Enter transaction code.

Enter.

Click Save button.

You finally come to a screen where, you have all the information for each screen including BDC_OKCODE.

¨ Click Get Transaction.

¨ Return to BI.

¨ Click overview.

¨ Position the cursor on the just recorded entry and click generate program.

¨ Enter program name.

¨ Click enter

The program is generated for the particular transaction.

BACKGROUND PROCESSING

Need for Background processing

When a large volume of data is involved, usually all batch inputs are done in background.

The R/3 system includes functions that allow users to work non-interactively or offline. The background processing systems handle these functions.

Non-interactively means that instead of executing the ABAP/4 programs and waiting for an answer, user can submit those programs for execution at a more convenient planned time.

There are several reasons to submit programs for background execution.

¨ The maximum time allowed for online execution should not exceed 300 seconds. User gets TIMEOUT error and an aborted transaction, if time for execution exceeds 300 seconds. To avoid these types of error, you can submit jobs for background processing.

¨ You can use the system while your program is executing.

This does not mean that interactive or online work is not useful. Both type of processing have their own purposes. Online work is the most common one entering business data, displaying information, printing small reports, managing the system and so on. Background jobs are mainly used for the following tasks; to process large amount of data, to execute periodic jobs without human intervention, to run program at a more convenient, planned time other than during normal working hours i.e., Nights or weekends.

The transaction for background processing is SM36.

Tools ® Administration ® Jobs ® Define jobs

System ® services ® Jobs

Components of the background jobs

A job in Background processing is a series of steps that can be scheduled and step is a program for background processing.

¨ Job name. Define the name of assigned to the job. It identifies the job. You can specify up to 32 characters for the name.

¨ Job class. Indicates the type of background processing priority assigned to the job.

The job class determines the priority of a job. The background system admits three types of job classes: A B & C, which correspond to job priority.

¨ Job steps. Parameters to be passed for this screen are as follows:

Program name.

Variant if it is report program

Start criteria for the job: Option available for this are as follows:

Immediate - allows you to start a job immediately.

Date/Time - allows you to start a job at a specific name.

After job - you can start a job after a particular job.

After event - allows you to start a job after a particular event.

At operation mode - allows you to start a job when the system switches to a particular operation mode.

Defining Background jobs

It is two step process: Firstly, you define the job and then release it.

When users define a job and save it, they are actually scheduling the report i.e., specifying the job components, the steps, the start time.

When users schedule program for background processing, they are instructing the system to execute an ABAP/4 report or an external program in the background. Scheduled jobs are not executed until they are released. When jobs are released, they are sent for execution to the background processing system at the specified start time. Both scheduling and releasing of jobs require authorizations.

HANDLING OF POP UP SCREEN IN BDC

Many times in transaction pop up screen appears and for this screen you don’t pass any record but some indication to system telling it to proceed further. For example: The following screen

To handle such screen, system has provided a variable called BDC_CURSOR. You pass this variable to BDCDATA and process the screen.

Usually such screen appears in many transactions, in this case you are just passing information, that YES you want to save the information, that means YES should be clicked. So you are transferring this information to BDCDATA i.e., field name of YES which is usually SPOT_OPTION. Instead of BDC_OKCODE, you are passing BDC_CURSOR.

BDC_CURSOR is also used to place cursor on particular field.

AN EXAMPLE WITH SESSION METHOD

Following program demonstrates how data is passed from flat file to SAP transaction and further to database table by using SESSION method.

The transaction is TFBA (to change customer).

A simple transaction where you are entering customer number on first screen and on next screen data is displayed for the particular customer number. Field, which we are changing here, are name and city. When you click on save, the changed record gets saved.

Prerequisite to write this BDC interface as indicated earlier is:

1. To find screen number

2. To find screen field names, type of the field and length of the field.

3. To find BDC_OKCODE for each screen

4. Create flat file.

Flat file can be created in your hard disk as follows:

1 Vinod Krishna Hyderabad

2 Kavitha Secunderabad

3 Kishore Hyderabad

(Where 1^st character field is Customer number, 2^nd field is Customer name and 3^rd field is City.)

To transfer this data to database table SCUSTOM following interface can be used.

REPORT DEMO1.

* Following internal table is to upload flat file.

DATA: BEGIN OF ITAB OCCURS 0,

ID(10),

NAME(25),

CITY(25),

END OF ITAB.

*Following internal table BDCDATA is to pass date from internal table to session.

DATA: BDCTAB LIKE BDCDATA OCCURS 0 WITH HEADER LINE.

* Variables

DATA: DATE1 LIKE SY-DATUM. DATE1 = SY-DATUM - 1. “ This is for Hold Date

* To upload flat file to internal table.

CALL FUNCTION UPLOAD

EXPORTING

FILE NAME = ‘C:\FF.TXT’

FILE TYPE = ‘ASC”

TABLES

DATA_TAB = ITAB

EXCEPTIONS

CONVERSION_ERROR = 1

INVALID_TABLE_WIDTH = 2

INVALID_TYPE = 3

NO_BATCH = 4

UNKNOWN_ERROR = 5

OTHERS = 6.

If sy-subrc = 0.

* Calling Function to Create a Session

CALL FUNCTION ‘BDC_OPEN_GROUP’

EXPORTING

CLIENT = SY-MANDT

GROUP = ‘POTHURI’

HOLDDATE = DATE1

KEEP = ‘X’

USER = SY-UNAME

EXCEPTIONS

CLIENT_INVALID = 1

DESTINATION_INVALID = 2

GROUP_INVALID = 3

GROUP_IS_LOCKED = 4

HOLDDATE_INVALID = 5

INTERNAL_ERROR = 6

QUEUE_ERROR = 7

RUNNING = 8

SYSTEM_LOCK_ERROR = 9

USER_INVALID = 10

OTHERS = 11.

If sy-subrc = 0.

*-------------------------- MAIN Logic------------------------------

LOOP AT ITAB

PERFORM GENERATE_DATA. “ Populating BDCDATA Table

CALL FUNCTION ‘BDC_INSERT’

EXPORTING

TCODE = ‘TFBA’

TABLES

DYNPROTAB = BDCTAB

EXCEPTIONS

INTERNAL_ERROR = 1

NOT_OPEN = 2

QUEUE_ERROR = 3

TCODE_INVALID = 4

PRINTING_INVALID = 5

POSTING_INVALID = 6

OTHERS = 7.

REFRESH BDCTAB

ENDLOOP.

* Calling function to close the session

CALL FUNCTION ‘BDC_CLOSE_GROUP’

EXCEPTIONS

NOT_OPEN = 1

QUEUE_ERROR = 2

OTHERS = 3.

Endif.

*&--------------------------------------------------------------------*

*& Form GENERATE_DATA

*&--------------------------------------------------------------------*

* Create BDC Data

*&--------------------------------------------------------------------*

FORM GENERATE_DATA

* Passing information for 1st screen on BDCDATA

BDCTAB-PROGRAM = ‘SAPMTFBA’.

BDCTAX-DYNPRO = 100.

BDCTAP-DYNBEGIN = ‘X’.

APPEND BCDTAB.CLEAR BDCTAB.

* Passing field information to BDCDATA

BDCTAB-FNAM = ‘SCUSTOM-ID’

BDCTAB-FVAL = ITAB-ID.

APPEND BDCTAB.CLEAR BDCTAB.

* Passing BDC_OKCODE to BDCDATA

BDCTAB-FNAM = ‘BDC_OKCODE’.

BDCTAB-FVAL = ‘/5’.

APPEND BDCTAB.CLEAR BDCTAB.

* Passing screen information for next screen to BDCDATA

BDCTAB-PROGRAM = ‘SAPMTFBA’.

BDCTAB-DYNPRO = 200.

BDCTAB-DYNBEGIN = ‘X’.

APPEND BDCTAB.CLEAR BDCTAB.

* Passing screen information to BDCDATA

BDCTAB-FNAM = ‘SCUSTOM-NAME’.

BDCTAB-FVAL = ITAB-NAME.

APPEND BDCTAB.CLEAR BDCTAB.

* Passing screen information to BDCDATA

BDCTAB-FNAM = ‘SCUSTOM-CITY’.

BDCTAB-FVAL = ITAB-CITY.

APPEND BDCTAB.CLEAR BDCTAB.

* Passing BDC_OKCODE to BDCDATA

BDCTAB-FNAM = ‘BDC_OKCODE’.

BDCTAB-FVAL = ‘SAVE’.

APPEND BDCTAB.CLEAR BDCTAB.

ENDFORM. “GENERATE_DATA

AN EXAMPLE WITH CALL TRANSACTION

Same steps to be repeated for CALL TRANSACTION

The only difference between the two types of interface is in Session method, you create session and store information about screen and data into session. When session is processed the data is transferred to database. While in CALL TRANSACTION, data is transferred directly to database table.

REPORT DEMO1.

* Follow above Code till MAIN Logic. Even the Subroutine should be copied

LOOP AT ITAB

PERFORM GENERATE_DATA, “Populating BDCDATA Table

Call transaction ‘TFBA’ using BCDDATA Mode ‘A’ Update ‘S’.

REFRESH BDCTAB

ENDLOOP.

2012-09-22T22:53:00.002-07:00

SAP Scripts/LayoutSets/Forms

Sap Scripts

If the user wants to print documents such as invoices, purchase order, all such documents are printed with the use of forms. SAP allows the user to define these forms by using layout sets. SAP script is the tool used to create the layout set.

In order to print the document, the SAP system runs a program that collects the data for the document and feeds it into the layout set. This is called as Print Program.

SAP Provides a standard layout set for every printable document and usually there is no need to create layout sets as such. User just modifies the existing layout sets as per requirement of client. Following are some standard layout sets provided by SAP:

RVORDER 01 Sales order confirmation
RVDELNOTE Picking List
RVPICKSIN Picking List
RVINVOICE 01 Invoice
MEDRUCK Purchase Order
F110_PRENUM_CHCK Pre-numbered check

Usually you don’t create layout sets, instead, you copy the existing layout sets with some modification to the existing layout sets. SAP doesn’t allow you to modify the layout sets. You need to copy the existing layout set to your own layout set and then do all the modification.

Procedure to copy the existing layout sets.

Tools à Word processing à Layout sets.

Utilities à Copy from client

Enter the name of the layout set in layout name.
Enter target layout set name
Click execute

The SAP standard layout set uses D German as the original language. In order to modify the copied layout set, the original language of the set must be changed to the language in which you are working.

To convert language:

Utilities – Convert original language

Click OK.

Layout Set

Layout set is used to design the document. Layout set on its own does not contain any data. The selection of data for the document is done through the print program i.e. the print program selects the data from database table and feeds it to the layout set. The document is printed after the print program gets executed.

A layouts set consist of following components:

Header
Paragraph
Character String
Windows
Pages
Page Window

Header: The header consists administrative information for the layout sets and default settings for the various other components of the layout sets like page, paragraph. You give all the administrative information for the header when you create the layout set, while all default settings are specified when all the components are created.

Paragraphs: A Paragraph contains all the information needed to format a paragraph of text and font. Tabs are important for paragraphs. Specifying the list of tabs is the way to create columns for outputting line items of a document.

Character string: is used to override paragraph settings for specific words in a paragraph. For example you might want to use Bold for a single word but not the entire paragraph. The only important thing that is defined with the character string is the font.

Windows: A window mainly contains the SAP scripts text and the variable to be printed. There is one special window, MAIN, which contains the output of the line item of a document and is created by the system. The window can be of type VAR or CONST except for the MAIN. But in the present version, SAP system does not distinguish between these two types. The content of variable window is regenerated on every page. The content of a constant window is generated once at the beginning and later printed on every page.

Printing a company logo

There are two ways to print a company logo:

1. The logo can be included in the layout set.

2. It can be a macro on PCL – 5 printers.

Including a logo in the layout sets

· Create logo with a graphics program and save it as tiff file.

· From editor run the program RSTXLDMC.

Parameters to be passed are

· File name

· File type

· BMON – For a black and white image.

· BCOL – For a color image.

· Text name – The standard text in layout set

This text can be included in a layout set by including <text name>. Using PCL – 5 printers, can also print the logo. In R3, the printer types are IIPLJIIID, IIPLJ4, LX4039 and SM120XXS.

Control Commands

About control commands:

All script control commands are entered in the SAP Script editor.

· All commands are indicated by /: in the tag column

· Only one control command is allowed per line

· Lines with control commands are not affected by the editor formatting

· If control command is unknown or incorrect, command line is treated as comment line

ADDRESS: This command formats and address according to the postal standards of the country.

Syntax:

/: Address

/: Title ‘Company’

/: Name ‘Intelligroup’

/: Street ‘115’

/: P.O. BOX ` `

/: Postcode

/: City

/: Region

/: Country

/: End Address

BOTTOM-ENDBOTTOM: For the Main window you can determine lines, which are always output automatically at the bottom of that window. This is called footer text.

Syntax:

/: Bottom

/: endbottom

BOX, POSITION, & SIZE: These commands are used for drawing boxes and are used only during creating output.

Syntax:

/: box [Xpos] [Ypos] [Width] [Height] [Frame] [Intensive]

X & Y – Upper left corner of the box.

Width – Width of the box

Ht – Height of the box

Frame – Thickness of the box (Default is full black)

Units used for Width, Height and Thickness are TW, PT, IN, CM, CH, LN.

Ex., /: BOX WIDTH ‘20’ CM HEIGHT 1 IN

FRAME 10 TW INTENSIFY 15.

POSITION

Syntax:

/: Position [X Origin] [Y Origin] [Window] [Page]

X & Y - Sets the origin for x 7 y parameters for the box command.

Window - Sets the default values for the left and upper edges.

Pages - Sets the values for the left and upper edges of the current page.

Basically used to set default setting for the box command.

/: Position x Origin ‘1.5’ cm y origin ‘1’ cm

SIZE

Syntax:

/: Size [Width] [Height] [Window] [pAGE]

Sets width and height parameters for the box command.

CASE: It is similar to ABAP/4 editor command ‘CASE’ only symbol can be queried.

Syntax:

/: CASE SYMBOL

/: WHEN 1

/: WHEN 2

/: WHEN OTHERS

/: ENDCASE

DEFINE: Values can be assigned to text symbol by DEFINE keyword. The assigned value may have a maximum 60 characters. It can also contain further symbols.

Syntax:

/: define & symbol & = ‘xxxx’

IF: With IF command you can define the lines that are output only under certain conditions.

Syntax:

/: IF &var& = ‘char val’

/: ENDIF

INCLUDE: Contents of another text can be included in text by INCLUDE command. The contents are copied only at the time of the output formatting. You can also specify language and the paragraph irrespective of the language in which the calling text is created. The language which is used in include test is used for output.

Syntax:

/: INCLUDE MYTEXT

NEW–PAGE: SAP Script automatically carries out a page break if window MAIN of one page is filled with NEW-PAGE command. You can face page break at any point. The current page is completed and the text in the following line is written on new page. If no name is defined, then, the next page attributes from page setup is taken.

Syntax:

/: NEW – PAGE [PAGE-NAME]

NEW–WINDOW: You can have 99 MAIN windows on one page. If MAIN window is filled, then the next MAIN window is accessed automatically. With NEW-WINDOW command, you can call next main window even if the current MAIN window is not yet completely filled.

PROTECT: You can determine that a paragraph must not be separated by a page break. The lines in this command are printed together on one page. If the space is enough on current page, then all the lines are printed on current page. If, however the space is not sufficient the PROTECT command works as a ‘NEW-PAGE’.

Syntax:

/: PROTECT

/: ENDPROTECT

SET COUNTRY: Some field types are formatted country – specifically. E.G. date. Normally the display types are defined in the user master record with the control command set country, an alternative to that in the user master record can be chosen.

Syntax:

/: SET COUNTRY <COUNTRY KEY>

SET DATE MASK: Standard display of date can be changed

Syntax:

e.g. SET DATE MASK = ‘MM DDDD (Day in full) yyyy’

You can switch back to default display of date by

/: SET DATE MASK = ‘ ‘

SET TIME MASK: Standard display of time can be changed

Syntax:

/: SET TIME MASK = ‘HH:MM’.

TOP-ENDTOP: For main window, you can determine lines, which are always O/P automatically at the top of the window.

2012-09-22T22:52:00.002-07:00

TRANSACTIONS

GENERAL INTRODUCTION TO TRANSACTION

The transaction contains two steps which are as following:

· Update phase: This phase processes the database record and updates the database table. Actual updating of database table takes place in this phase.

All the transactions are associated with transaction code. And all these codes are stored in a table TSTC.

Logical Unit of Work (LUW)

Following are the few concepts and steps for creating entire new transaction.

Dynpro concept

A dynpro refers to the screen + flow logic. With screen painter you can develop screen and flow logic. The relationship between screen, flow logic, and program can be shown as follows:

· A module program is usual ABAP/4 program that consist of modules and data declaration.

· Screen is the important component of dynpro and can be created, designed by screen painter.

Screen Painter

A screen painter can be started by

Development workbench à Screen painter

SE51 transaction code.

Using Screen painter

The process of creating a dynpro includes the creation and definition of all the needed screen components.

The steps involved in creating the dynpro are as follows:

· Create screen and attributes by using screen attribute screen.

· Select and place the needed fields within the screen by using dict/program fields.

· Establish the field attributes to which the screen belongs by using field list.

· Define the flow logic respect to the transaction to which it belongs by using flow logic.

Creating a new Screen

Steps involved are as follows:

· Enter the name of program and number of the screen

· Click on Create

· On “screen attribute” screen enter short description

· Next attribute to be passed is NEXT SCREEN. Here you need to specify the next screen number, which must be processed after the current one.

Designing of Screen

Screen can be designed by using FULL SCREEN EDITOR. You can go to full screen editor.

From screen attribute screen

By pressing full screen editor pushbutton

From initial screen of screen painter.

There are two modes available with full screen editor.

· Graphical mode. The graphical mode works similarly to typical window application.

· Alphanumeric mode (rarely used).

Elements of screen

· Text – Standard text or field labels.

· Entry - display field.

· Radiobutton – All radiobutton must be associated with one group.

· Checkbox – Normally used for YES/NO operations.

· Pushbutton – Used for activating particular function.

· Boxes – grouping together many screen elements.

· Subscreens – This is a screen area in which you can display another screen.

· Table controls – This area of screen is similar to table but should be treated as a loop.

· Status - Display output fields containing icon.

All these elements are on the control bar of full screen editor and can be placed on the screen work area by clicking and placing them wherever needed.

Selecting Screen fields

Screen field can be either dictionary objects or program fields. Steps involved in the placing of fields on the screen are as follows:

Click the pushbutton Dict/program fields on the full screen editor

Goto à dict/prog fields.

· Enter table name.

· Click Get from dictionary.

· Select fields.

· Click copy pushbutton.

· Position the cursor where you want those fields to be placed.

To adjust various screen elements, you can use drag and drop facility for screen elements.

Attributes of Screen Elements

The entire element of a screen has some attributes, which determines their behavior.

· General – These attributes are directly managed by the screen painter like name of the element, or text of element or column width and various things associated with the screen.

· Dictionary – These attributes are applicable to fields, which are from dictionary. Various components of dictionary can be attached to this element like search help, foreign key.

· Program.

· Display – Behavior of the element with respect to their display feature.

Attribute dialog box can be displayed by

· Clicking on the Attribute push button on the application tool bar.

· Double clicking on the element.

Field List

Screen Flow Logic

You can go to this screen either by

Initial screen of screen painter à Flow logic

From Screen attribute screen à Flow logic

· Process before Output (PBO)

· Process after input (PAI)

· Process on value request (POV)

· Process on help request (POH)

The system automatically displays two very important events or modules in flow logic i.e. PAI and PBO

PBO event

This event is triggered before the screen is displayed. The processing of screen before the display of screen is done in this event. For example, filling in default values in the screen fields.

PAI event

POV event

POH event

Module Pool Programming

Creation of Module Pool Program

You can create module pool program either through

Object browser

System automatically creates the module pool program and for these program which are created through object browser, system creates the include modules.

ABAP/4 editor

It is similar to normal program creation. Type of program should be given ‘M’ and is not created by system.

Communication between Dynpro and Module Program

Creation of a Complete Transaction

Steps involved to create a complete transaction

· Create module pool program.

· From screen painter create screens.

· Write flow logic for each screen.

· Write code for all the events in module pool program.

· Check for any error in screen and flow logic.

· Generate each and every component of screen i.e. flow logic and screen.

· Single screen can be tested using Screen Painter.

· Create transaction code through object browser.

· Generate the transaction code.

· User can execute the transaction by entering the transaction code in the command field.

Handling Function Code

The function code or OKCODE is the last field of Field list. Function code can be handled as follows:

During the Designing of the screen, a function code is assigned to pushbutton.

· In field list, developer needs to specify OKCODE as last field.

· In module program it is a global field and can be evaluated in the PAI event.

· A function code is treated in the same way, regardless it comes from pushbutton, menu item or any other GUI element.

A complete example for transaction is shown below:

If you have a screen like the one below:

When the user clicks on the Display button, you want to display details of sflight, with corresponding carrid and connid (which is entered by the user).

Module pool program to handle this particular screen is as follows:

Program YVTEST7.

Tables: SFlighT.

data: okcode (4).

Module input1 input,

case okcode.

when ‘disp’.

Select * from sflight

where carrid = sflight – carrid and

connid = sflight – connid.

Endselect.

leave to screen 200.

When ‘exit’. Leave to screen 0.

Endcase.

endmodule. “input1 input

module user_command_0200 input.

case okcode.

when ‘back’. Leave to screen 100.

endcase.

Endmodule. “user_command_0200 input

When the user clicks on display, control is transferred to screen no. 200 on which you display sflight details & on the same screen, when user clicks on BACK button, he comes back to main screen.

Flow logic for screen 100 is as follows:

Process after input.

Module input.

Flow logic for screen 200

PROCESS AFTER INPUT.

User_command_0200.

MODULES: modules are handled in module pool program.

You need to write flow logic for screen 200 and design screen 200.

The Field Checks

· Automatic field checks

· Checks performed in the flow logic

· Checks performed in the ABAP/4 module pool program

Automatic Field Checks

· Required input

· Proper data Format

· Valid Value for the Field

Automatic field checks are repeated each time the user enters the data.

About at Exit – Command

In module pool program.

Module exit.

Case okcode.

When ‘Exit’.

Leave to screen 0.

To achieve this kind of functionality a pushbutton or menu item should be assigned a function type ‘E’. It tells the system to process this particular module before carrying out any field checks.

Flow Logic Validations

Field --------------- Values

Syntax

PAi.

Field sflight-carrid values (‘LH’).

For multiple values

PAI.

Field sflight-carrid values (‘LH’ ‘SQ’).

Field sflight-price values (between 1000 and 2000).

Consider the following case:

PAI.

Module assign.

Field sflight-carrid values (‘LH’ ‘SQ’).

In ABAP/4

Module assign.

Data: carrid1 like sflight-carrid.

Carrid1 = sflight-carrid.

Endmodule.

Consider one more case where you have multiple field statement.

PAI.

Field Sflight-carrid values (‘LH’).

Field Sflight-connid values (‘0400’ ‘0500’).

Syntax

Chain.

Field sflight-carrid value (‘LH’).

Field sflight-connid values (between ‘200’ and ‘500’).

Endchain.

Field sflight-price values (‘100’ ‘1000’).

Module Pool Program Validations

Checking fields ABAP/4 program includes

· Field statement in flow logic.

· Module statement in ABAP/4 module pool Program.

Syntax

PAI.

Field sflight-carrid module <name>.

This module can be handled in the main program i.e. module pool program.

In ABAP/4 program

Module Check.

Select single * from sflight where carrid = sflight-carrid.

If sy-subrc ne 0.

Message e001.

Endif.

In this case, field sflight-carrid is checked in the table for its existence.

Dynamically Calling the Screens

About Displaying Next Screen

But this doesn’t happen always. If you have many pushbuttons on the screen like the one in the following case:

The screen can branch out to new screen depending upon user selection. Following command in module pool program can do this:

· Set Screem

· Call Screen

· Leave to screen <number>

All these commands override the specifications given in the attributes. This overriding is temporary. The values stored in the attribute are not changed.

Set Screen

Syntax

Set screen <number>.

In module pool program

Case okcode.

When ‘Disp’.

Set screen 200.

When ‘List’.

Set screen 300.

Endcase.

For Example:

Case okcode..

When ‘Disp’.

Set screen 200.

Leave Screen.

When ‘List’.

Set screen 300.

Leave Screen.

Endcase.

When SET SCREEN is used, control cannot be transferred to the main screen or previous screen, unless you write code for the same.

Call Screen

Syntax

Call Screen 200.

Will simply call a screen number 200 from a main screen. Once the screen is displayed the user can enter all the data and return to the main screen by clicking back button.

To call screen as pop up screen the syntax is

Call screen starting at <col.no.> <line no>

Ending at <col no> <line no>.

In this case window will be popped as window and user can close it by using back button.

Leave to screen

To SET a new screen without processing current screen, you need to use the following two statements together:

SET Screen 200.

Leave Screen.

Or a Single statement

Leave to screen 200.

Subscreens

A subscreen is a screen within screen. Consider the following case.

Step to create a subscreen are as follows:

· Create a subscreen area on main screen and name it.

· Create a separate screen of subscreen type.

· Arrange the fields on this screen so that they fit in subscreen area exactly. Only when it is larger, the part of the screen that fits in the main area will be visible.

· Write code for calling subscreen in flow logic.

To call subscreen, from your flow logic, you need to include the statement both in PAI and PBO.

Syntax

PBO.

Call subscreen <area> including <prg name> <’screen no’>.

PAI.

Call subscreen <area>.

Area - is the name of the area on main screen.

Prg. Name - is the name of the module pool program.

Screen number - is subscreen screen number.

Some of the don’ts with subscreen are:

GUI status cannot be set to the subscreen

· OKCODE is not applicable to the subscreen.

· Subscreen cannot call another screen.

· It cannot contain at Exit-Command.

Table Controls

A table can be created in transaction. These tables when designed on the screen are called as Screen Tables. These screen tables are of two types viz.

· Table controls

· Step loops

Though these are tables when code is written to handle them, the tables are treated as loops.

Features of Table Controls

· Data is displayed in the form of table when many records match the criteria.

· Table control gives user the feeling of an actual table.

· You can scroll through the table vertically and horizontally.

· You can select rows and columns

· Resize the width of a column

· You can have separator lines in between rows and columns

· Automatic resizing of the table when the user resizes the window.

Steps associated for creating complete screen table are as follows:

· Declaration of table control in module pool program.

· Designing of table control on the screen.

· Passing data to table in flow logic.

Declaring of Table Control in the Module Pool Program

Syntax

Controls TCI type Tableview using screen <screen no.>

When you use table control in a screen you must declare the structure in module pool program. Important fields of tableview are as follows:

· Lines – number of displayable rows in a table.

· Top_line – the row of table where the screen displays start.

· Current_line – The row currently being processed inside a loop.

When you process the table control in flow logic depending upon where you want to start display of rows, you need to use these variables.

Designing Table Control on Screen

· To design table control on the screen, you need to click on Table in control bar and place it on the screen. You can adjust the length and width of table control.

· Name the table control. (Here you need to use same name which you have used for declaration of table control in module pool program)

· From dictionary object, select table fields and place them in the table control.

Passing data to table Control

Syntax

PBO.

Loop at <internal table> with control <table control name> cursor <scroll variable>

PAI.

Loop at itab.

Proper usage of Table Control is as follows:

In flow logic.

PBO.

LOOP at iTAB with control Tc1 cursor tc1-top_line.

Module assign.

Endloop.

Pai.

loop at itab.

endloop.

Considering, we have following fields in table control and the screen looks like this:

In module pool program

Control TC1 type tableview using screen 200.

Module assign.

Sflight – carrid = itab – carrid.

Sflight - connid= itab - connid.

Sflight - fldate= itab – fldate.

Endmodule.

The transfer of the data from program to table control takes place in steps and these steps are as follows:

· With LOOP AT statement the first row is picked up and placed in the header of the internal table.

· Whatever statements you have in between LOOP-ENDLOOP are executed. In this case, you have Module statement. In Module statement, value of internal table is assigned to table control field.

· The row in internal table is transferred to the first line of the table control as stated in the LOOP AT statement.

· The system encounters the ENDLOOP statement and Control is passed to the next line of the internal table.

· In the same way, all the records of the internal table are passed to the table control.

STEP LOOPS

· Creation of step loops on screen, which includes declaring fields on the screen and then defining the step, loops for these fields.

· Passing data to the step loop is exactly similar to the passing of data to table controls.

· In step loop, you don’t need to define the step loop as such in the module pool program but the cursor needs to be defined in the program.

Types of Step Loops

· Static – Static Step Loop (SSL) have fixed size that cannot be changed during the runtime. If user resizes the window, the size of the static step loop is not changed.

· Dynamic – Dynamic Step Loop (DSL) is variable in size. When the user resizes the window, the system increases or decreases the number of the step loop blocks.

You can have only one dynamic step loop and can have as many static loops in your transaction.

Writing code for Step Loop in the flow logic.

PBO.

Loop at itab cursor cl.

Module set.

Endloop.

PAI.

Loop at itab.

Endloop.

* Empty loop is must for both table control and step loop

LOOP AT statement for step loops and Table controls is similar. Loop At statement transfers the data to screen table. You need to have the Module to assign the values for the screen table.

In module pool program you need to define the cursor.

Date: CL TYPE i.

* Cursor parameter tells which line of step loop display should start.

“Module Set” in module pool program assigns the values to step loop fields, which is similar to table controls.

Branching to List Processing

Switching To List Mode

You can display a list within a transaction.

You can produce a list from module pool program by using the command

Leave to List-Processing.

Returning back from LIST mode

You can return back to dialog mode by clicking the BACK button.

Help & Value Request

In ABVP/4 help can be provided to the user by:

Data element documentation: The F1 help can be enhanced, by adding an additional text for the data element in ABAP/4 dictionary.

It can be done with the help of following steps:

Place cursor on the screen field,

GOTO à DOCUMENTATION à DATA ELEMENT DOCUMENT

You can now extend the existing help.

USING THE PROCESS ON HELP-REQUEST.

If you don’t have this event in a program, then the documentation of the field in the ABAP/4 dictionary is taken into consideration. If this event exits in the program then it is executed.

Process on HELP-REQUEST event

This event is triggered when user presses F1 on a screen field. You need to handle this event in flow-logic by specifying the fields and attaching the module to it.

Syntax

PROCESS ON HELP –REQUEST.

FIELD SFLIGHT-CARRID MODULE HELP-FOR-CARRID.

In module pool program

MODULE HELP.

Write : `This is field is from sflight table’

Write : / ‘It is of four Character’.

ENDMODULE.

When the user presses F1 on this particular field, then this message will be displayed on the screen.

Value Request

Matchcode objects: Are aggregated dictionary objects and detailed procedure to create these objects is explained in the later part of the material.

Check Table: If a check table is assigned to the table field and if the user presses F4 for that particular field, then all the key fields are displayed.

Domain Values: The values defined in the domain are displayed. These values are set in domain when the domain is created in the dictionary.

PROCESS ON VALUE_REQUEST.

Each time the user presses F4 on the screen field, following algorithm is called internally.

When the user presses F4 on flight number, the following screen is displayed.

Flow-logic code

PROCESS ON VALUE-REQUEST.

FIELD SFLIGHT-CONNID MODULE HELP-FOR-CONNID.

Code for module pool program.

MODULE HELP-FOR-CONNIDINPUT.

DATA: BEGIN OF ITAB OCCURS 0,

CONNID(50),

END OF ITAB.

REFRESH ITAB.

ITAB-CONNIDI= POSSIBLE VALUES FOR CONNECTION ID’.

APPEND ITAB.

SELECT CONNID FROM SFLIGHT INTO TABLE ITAB.

CALL FUNCTION ‘POPUP_WITH_TABLE_DISPLAY’

EXPORTING

ENDPOS_COL = 45

ENDPOS_ROW = 25

STARTPOS_COL = 10

STARTPOS_ROW = 1

TITLETEXT = ‘TEXT’

IMPORTING

CHOISE = Some Integer Variable

TABLES

VALUETAB = ITAB

EXCEPTIONS

BREAK_OFF =1

OTHERS =2.

ENDMODULE. “HELP-FOR-CONNID INPUT

Changing The Screen During Runtime

Need To Change Screen

There can be a requirement in the transaction that, certain fields on the screen

Appear only in certain conditions.

Are in Change/display mode according to user inputs

Become mandatory subject to specific inputs.

Changes its format depending upon certain conditions.

Modifying the screen

Field Name Length Description

NAME 30 Name of screen field

GROUP1 3 Field belongs to field group1

GROUP2 3 Group 2

GROUP3 3 Group 3

GROUP4 3 Group 4

ACTIVE 1 Hide/Show

REQUIRED 1 Field input is mandatory

INPUT 1 Enable/Disable

OUTPUT 1 Field for display only

INTENSIFIED 1 Field is highlighted.

INVISIBLE 1 Field is suppressed.

LENGTH 1 Field output length is reduced

DISPLAY 3D 1 Field is displayed with 3-D Frame

VALUE_HELP 1 Field is displayed with Value help

E.g., SCREEN-ACTIVE = 0 has the same effect as the following statements.

SCREEN- INPUT = 0.

SCREEN-OUTPUT = 0.

SCREEN-INVISIBLE = 1.

The fields SCREEN-NAME and SCREEN-GROUP 1 through SCREEN-GROUP4 tell you which field and / or field group has the attributes.

You can assign up to 4 groups to a field.

You need to program screen modifications in module, which is processed during the event PROCESS BEFORE OUTPUT.

PROCESS BEFORE OUTPUT.

MODULE MODIFY_SCREEN OUTPUT.

MODULE MODIFY_SCREEN.

LOOP AT SCREEN.

IF SCREEN-NAME = ‘SFLIGHT-CARRID’.

SCREEN-INPUT = 1.

MODIFY SCREEN.

ENDIF.

ENDLOOP.

ENDMODULE.
Working with Matchcode Objects

A Matchcode is an aggregated object and it gives list of possible values for the user. A matchcode is a collection of search terms on which you retrieve a data from the database table.

When you use non-primary key of input.

You need different search term for the primary key.

Creating Matchcode object

Entire Matchcode object is created in two steps:

Defining of Matchcode object.

Defining one or more search ids for the object.

Defining Matchcode object

It includes all the tables and fields, which make up the Matchcode, which are used for Matchcode Ids.

Steps for defining Matchcode object are as follows:

From dictionary, enter name (four character).

Select Matchcode radiobutton and click on CREATE.

Define attributes for the object i.e. description.

Select primary table.

Select the fields for the table by clicking on the fields.

Activate the object.

If at all you are selecting secondary table then it is done after selecting primary table.

And steps are as follows:

Tables à Choose secondary table. A dialog box appears, which displays list of possible secondary tales. Select the table by Choose à copy.

To activate the object, Matchcode object -à activate

Creating Matchcode ids.

Once the object is created, you need to define search term for the object and steps are as follows:

Click on the Matchcode ID from maintenance screen.

Enter attributes for the Matchcode Id.

Short text.

System Matchcode: If you click this particular field, it indicates a system matchcode, which is used by SAP software and cannot be changed by the end user.

Autho.checks: If it is checked, the system performs authorization checks for this matchcode Id.

Selecting secondary tables

Position the cursor on the base table of the ID.

Edit à Choose secondary tables

A dialog box appears listing the tables linked to the table by foreign keys

Select table.

Save.

Selecting fields for Matchcode Id

Select fields.

Choose fields.

Once all the fields are selected, click on copy fields.

Fields are transferred to the matchcode Id.

Activation of Id

Testing the Matchcode Id.

To test the matchcode Id: Maintain matchcode object.Utilities à display matchcode data.

Using Matchcode

When the user do not know which matchcodes are available for a field, user can find the matchcode by:

Positioning the cursor on a field and clicking on drop arrow or pressing the F4 key.

A dialog box appears with a list of available matchcode

User can select another matchcode by clicking on the NEW selection button.

Double click on a matchcode to use it. If you want to use this as default matchcode, click on standard button. If user does this once, the selected matchcode is proposed automatically the next time.

You can enter the search term and press ENTER. If search term is not specified, the system displays all the records for the specific matchcode.

Lock Objects

Creating Lock Objects

Lock object is an aggregated dictionary object and can be defined by using the following steps:

From initial data dictionary screen, enter the name for the object, Click Lock object radiobutton and then click on Create. The system displays a dialog box for Maintain Lock Objects screen
Enter short text as usual and the name for primary table.
Save
Select Tables option

From this screen you can:

Select secondary tables, if any, linked by foreign key relationship.

Types of locks

You can lock the table or record by using following types of locking:

Exclusive (E) the locked data can only be displayed or modified by single user i.e the owner of the object. Access to other users is denied.

Shared (S) several users can access the same record simultaneously, but only in display mode and except the first one, who has asked for the data in update mode.

Activation of Lock Object

When you activate the lock object, the functions are automatically generated. And these are ENQUEUE-EZN and DEQUEUE-EZN. EZN is name of the lock object.

While ENQUEUE is used in program to set the code over the selected data depending upon the lock object arguments. DEQUEUE is used to release the lock.

EXERCISES

1. Create a matchcode for MARA-MATNR with one matchcode ID. The fields in the ID should be MARA_MATNR., MARD-WERKS. MARD-LGORT. MAKT-MAKTX.

2. Create a GUI status of type list with the following features and attach it to a report. (Create a simple report with Write statement).

Use the statement SUBMIT REPORT AND RETURN TO CALL A REPORT.

REPORTS SYSTEM HELP

Materials

Vendors

Exit

Application tool bar: 3 push button - Material, vendors, exit.

When material push button or menu option is chosen to display a list a materials with the following fields:

MARA-MATNR, MARD-WERKS,MARD-LGORT,MAKT-SPRAS.

When vendor pushbutton or menu option is chosen, display a list of vendors with the following fields.

LFA1-LIFNR, LFA1-NAME1, LFA1-ORTO1.

Exit to quit the program.

3. Create a transaction with three screens

Screen 1:

Radiobutton : 2 R1,R2.

Pushbutton :2-Next, Exit,

When NEXT button is pressed, display screen 2 or screen 3 on the radio button selected.

i.e., if R1 is selected display screen 2 or if R2 is selected display screen3.

Screen 2:

Entry fields : SPFLI-CARRID, SPFLI-CONNID,SPFLI-CITYFROM, SPFLI-CITYTO.

Pushbutton : First screen, Exit.

Screen 3.

Entry fields : SFLIGHT-CARRID. SFLIGHT-CONNID.SFLIGHT-FLDATE.SFLIGHT-SEATSMAX,SFLIGHT-SEATSOCC.

Pushbuttons: First screen, Exit.

`Firstscreen’ pushbutton is to display screen 1 and exit is to quit the transaction.

***********USE SELECT-SINGLE*************

4. Create a transaction with on screen.

Screen one

Entry fields: MARD-MANTNR,MARD-WERKS,MARD-LGORT

Pushbuttons: Firstrecord Next Record, Previous record, Last Record, Exit.

Select the data from MARD into an internal table and whenever a button is pressed display the corresponding record (i.e. First, Next, Previous, or Last) using the internal table index.

Exit to quit the transaction.

**********Use LEAVE –TO-LIST-PROCESSING***********

6. Create a transaction with two normal screens and two subscreens.

Screen1 : Normal screen.

Entry fields : MARA-MATNR

Radiobuttons: Plant, Description

Push-button :Display, Exit.

Screen2: Normal screen.

Display fields: MARA-MATNR.

Pushbuttons:Back,Exit.

Screen3: Subscreen.

Display fields: MARD-WERKS,MARD-LGORT.

Screen4: Subscreen

Display fields:MAKT-SPRAS,MAKT-MAKTX.

When the display pushbutton is clicked, display Screen2 with proper subscreen attached to it based on the selection of radio button..

i.e. Screen 3 - if plant is selected and Screen 4 - if description is selected.

2012-08-31T05:21:00.007-07:00

SDN Articles - BW Administration

List Of Articles:

The Documents in this section answers most of the questions related to Administration in SAP BW/BI.

i) Aggregates:

The below documents will give overview about when to create aggregates and how to create also how the performance improvement will happen due to aggregates.

Illustrated Step-By-Step Guide to Performance Optimization using Aggregates in SAP BI

Backend Performance Improvement Measures in BI

ii) Authorizations:

This section tells about how the Analysis Authorizations works and how to create them. How the analysis authorizations works at report level.

Analysis Authorization Using Variable Exits

BI 7.0 Reporting Authorization based on Characteristic Value Level

SAP BI Analysis Authorization (Customer Exit Variables)

iii) Attribute Change Run (ACR):

What is Attribute Change Run, Advantages of it. Back end operations of Attribute Change Run. How to run the Attribute Change Run.

Attribute Change Run (ACR) Performance Optimization and Forceful Completion

SAP BW Hierarchy Attribute Change run Management

iv) DSO Administration:

This section explains about the different parameters in DSO Administration. How to check the DSO Activation job log. This also gives information about step by step procedure of selective deletion in DSO.

Database Statistics During ODS Activation

DSO Job Log and Activation Parameters

Step By Step: the Process of Selective Deletion from a DSO

v) Info Cube Administration:

This section provides information about different operations we perform on info cube like

i) Compression ii) Roll Up and how to do LISTCUBE. This also explains about indexes in Info Cube.

All about Compression

Downloading InfoProvider Metadata to Excel

Dynamic Selective Deletion from Infocubes

SAP BI – Compression Status for Infocubes

SAP BW – Infoprovider Data Display (LISTCUBE) - Improvised

Understanding the Bit-Map