Wood J. Object-Oriented Programming with ABAP Objects

Подождите немного. Документ загружается.

PART III

Case Studies

The SAP Control Framework makes it possible to manage custom desktop

UI controls from an ABAP program running remotely on the SAP

NetWeaver Application Server. These controls greatly enhance the user

experience of working with the classic Dynpro UI by leveraging complex

controls that are already installed on a user's workstation. In this chap-

ter, you will learn how to develop interactive reports using the SAP List

Viewer control and the ALV Object Model.

10 Working with the SAP List Viewer

This chapter begins the first of several case studies that demonstrate how ABAP

Objects classes are used in some common ABAP development tasks. The SAP List

Viewer (commonly known as the ABAP List Viewer or ALV) is a flexible UI control

that can be used to display structured datasets in various formats. In the past, if

you wanted to work with the ALV toolset, you had one of two options:

• Use function modules from the Reuse Library (e.g., REUSE_ALV_GRID_DISPLAY).

• Interact with the grid control directly using the SAP Control Framework (e.g..

via proxy classes CL_GUI_ALV_GRID, etc.).

However, with SAP NetWeaver 2004. SAP has provided a unified API called the

ALV Object Model that is based purely on ABAP Objects classes.

Throughout the course of this chapter, you will see how to design and implement

a simple flight query report using ALV Object Model. Along the way, we will

revisit the concept of ABAP Objects events to see how to respond to events trig-

gered by users interacting with the ALV control on their frontend workstations.

10.1 Overview of the SAP Control Framework

In the early days of screen programming in the SAP R/3 environment, the list of

available screen elements that could be added to a classic Dynpro screen was lim-

ited to simple labels, input fields, buttons, and so on. These elements could be

257

10 | Working with the SAP List Viewer

used to develop screens that were functional, but it was veiy difficult to create

high fidelity screens with a look-and-feel that many users were accustomed to

working with in other popular desktop applications. Recognizing these shortcom-

ings, SAP introduced the SAP Control Framework in Release 4.5 of the Basis ker-

nel (which was the predecessor to the SAP Web AS).

At a high level, the SAP Control Framework makes it possible to manage custom

UI controls on a user's desktop client from an ABAP application running remotely

on the SAP Web AS. These custom controls are implemented using either

Microsoft's ActiveX* or Sun's JavaBeans™ component technologies depending on

the version of the SAP GUI client that is being used. Support for common indus-

try component models such as ActiveX or JavaBeans makes it possible to integrate

many types of complex controls into the classic Web Dynpro UI.

10.1.1 Control Framework Architecture

As you can see in Figure 10.1, the SAP Control Framework architecture exists in

two distributed parts:

• The server part of the framework is based on a scries of ABAP Objects classes

collectively referred to as the ABAP Objects Control Framework. This framework

contains some core classes that define the low-level interfaces between the

application server and the frontcnd, as well as a scries of proxy classes that

encapsulate the functionality of custom controls behind an ABAP Objects inter-

face. These proxy classes inherit from the base control class CL_GUI_C0NTR0L.

• The client side of this framework is managed by a special component inte-

grated into the SAP GUI client called the Automation Controller. The Automa-

tion Controller manages all of the custom control instances being used on the

SAP GUI frontcnd. It is also responsible for managing communication between

the custom controls and the ABAP Objects Control Framework. This RFC-based

communication includes the transfer of data between the ABAP program and

the custom controls as well as the propagation of events triggered on the front-

end to event handler methods registered on the backend. To maximize perfor-

mance, all communication is buffered inside of an Automation Queue on both

the client and the server.

One of the main advantages of working with the control framework is the fact

that much of the functionality in an application can be delegated to the frontcnd

client. For example, the ALV grid control is able to sort and filter the data it dis-

258

Overview of the SAP Control Framework 10.1

plays without requiring an interaction with the server. This reduces the load on

the application server and also makes users happy because they get their results

much sooner than they would if they had to wait on a dialog step.

As you can see in Figure 10.1, the SAP Control Framework also keeps track of the

events that are triggered on the frontend client. These events are dispatched by

the framework to event handler methods defined in a custom ABAP Objects class.

The signature of these event handler methods provides information about the

event as well as a reference to the sender object (i.e., the proxy object for the cus-

tom control). This information allows you to react to the event in some applica-

tion-specific way. You will see an example of this in Section 10.4, Event Handling

with the ALV Object Model.

10.1.2 Survey of Available Controls

Besides the ALV grid control that we have discussed already, there are many

other useful custom controls in the SAP NetWeaver AS that are available out of

the box. Examples of these controls include special container types, a calendar

259

10 | Working with the SAP List Viewer

control, a control for embedding a web browser on a screen, and many others. It

is also possible to use the SAP Control Framework to design your own custom

controls based on ActiveX components, JavaBeans, or even .NET controls.

10.2 Overview of the ALV Object Model

Before we get started with our example report program, it will help to become

familiar with some of the more common elements of the ALV Object Model that

you will be working with. The example in this chapter will be using class

CL_SALV_TABLE

to represent the flight query results. This class is used to render a

simple two-dimensional table in a classical ABAP list, a GUI container on a Web

Dynpro screen, or as a full screen table display. To keep things simple, we will

accept the default full screen table display type as we design our report.

Ifyou look closely at the properties of

class

CL_SALV_TABLE,

you will notice that it

is configured with the private instantiation type. As you will recall from Chapter

4, Object Initialization and Cleanup, private instantiation implies that we cannot

create instances of class

CL_SALV_TABLE

directly using the

CREATE OBJECT

state-

ment. Instead, SAP has provided a special class method called

FACTORY

that can be

used to obtain an instance of the ALV tool. Factory methods are provided to sim-

plify the creation of objects. In the case of class

CL.SALV.TABLE,

the

FACTORY

method takes care of initializing the surrounding GUI environment, populating

data in the grid. and. perhaps most importantly, dynamically deriving the meta-

data the ALV tool needs to render the report. In the past, this metadata had to be

built by hand in a special internal table variable called a Jield catalog.

The ALV table object returned by the

FACTORY

method is fully functional and can

be displayed on the screen using the

01 SPLAY

method. However, you will usually

want to tweak various aspects of the table before you hand it over to the users. In

the ALV Object Model, these settings have been encapsulated into distinct ABAP

Objects classes. These classes mostly contain getter and setter methods that you

can use to configure various settings that affect how the table is displayed or

interacted with. The UML class diagram shown in Figure 10.2 shows some of the

common getter methods provided in class

CL_SALV_TABLE

for accessing instances

of these properly classes. For more information about the details of an individual

property class, consult the SAP online help documentation

(http://help.sap.com).

260

Getting Started with the Flight Query Report

10.3

Figure 10.2 UML Class Diagram for Class CL_SALV_TABLE

10.3 Getting Started with the Flight Query Report

Now thatyou have a basic understanding of the ALV Object Model, we can pro-

ceed with the development of our flight queiy report. The following subsections

show you how to implement various aspects of the report program in detail.

10.3.1 Understanding the Report Requirements

The general requirements for the flight query report are to allow users to display

a set of upcoming airline flights according to some basic selection criteria. The

data for this report will be driven out of the familiar Flight Data Model used in

many of the standard examples provided by SAP. The search results of the flight

queiy will be displayed in an ALV grid control. To demonstrate ABAP Objects

eventing, users will be able to double-click on a particular flight in the search

results to display a pop-up window showing the number of

seats

available on the

selected flight.

10.3.2 Report Design Using the MVC Design Pattern

To maximize reusability, you can isolate the various aspects of the report into sep-

arate layers. One common way of organizing GUI applications is to employ the

popular Model-View-Controller (MVC) design pattern. The MVC design pattern

261

10 | Working with the SAP List Viewer

separates the user interface layer (or view) from the underlying business model

layer so that the two can vaiy independently. The "glue" component between

these two layers is referred to as a controller. Controllers act as traffic cops for the

application, managing the user experience by responding to user events, query-

ing and updating the business model, and selecting the appropriate view.

In keeping with this best practice for UI design, the flight query report will be

separated into the three layers prescribed by the MVC design pattern. However,

for the sake of brevity, we will bend the rules a little bit here and there so that we

can focus in on the aspects of the design that more closely pertain to the topics at

hand in this chapter. Where appropriate, these shortcuts will be identified so that

you will understand the areas of the design that need some additional work for a

report that is being used in a real-world setting.

10.3.3 Developing the Flight AAodel Class

Because the foundation of any application is based on the underlying business

model, it seems appropriate to begin the development of our example report by

first creating a model class to encapsulate our interactions with the SAP flight data

model. Normally, you will prefer to develop your model classes globally so that

they can be more easily reused. However, to keep things simple (and also to prac-

tice our ABAP Objects syntax), we will build a local model class called

lcl_flight_model inside of an include program called ZALVFLIGHT_CLASSES (see

Listing 10.1). The

cl_f

11ght_mode1

class defines a single public instance method

called query_flights that uses the standard BAPI function BAPI_FLIGHT_GETLIST

to query the flight database according to some basic search criteria.

*& *

*& Include ZALVFLIGHT.CLASSES *

*& *

TYPES: ty_f11ght_l1 St TYPE STANDARD TABLE

OF bapisfidat.

ty_date_range TYPE STANDARD TABLE

OF bapisfldra.

CLASS lcl_flight_model DEFINITION.

PUBLIC SECTION.

METHODS:

query_flights

262

Getting Started with the Flight Query Report |

10.3

IMPORTING im_from TYPE s_airport

im_depart_date TYPE s_date

im_to TYPE s_airport

im_return_date TYPE s_date

EXPORTING ex_results TYPE ty_f1ightjist.

ENOCLASS.

CLASS 1c1_f1ight_model IMPLEMENTATION.

METHOO query_flights.

* Method-Local Data Declarations:

OATA: 1s_from_dest TYPE bapisfldst.

1s_to_dest TYPE bapisfldst.

1t_date_range TYPE ty_date_range.

FIELD-SYMBOLS:

<1fs_date_range> LIKE LINE OF 1t_date_range.

* Populate the from/to destination structures:

1s_from_dest-airportid - im_from.

1s_to_dest-airportid - im_to.

* Build the selection date range - as necessary:

IF NOT im_depart_date IS INITIAL.

APPENO INITIAL LINE TO 1t_date_range

ASSIGNING <1fs_date_range>.

<1fs_date_range>-1ow - im_depart_date.

IF NOT im_return_date IS INITIAL.

<1fs_date_range>-sign - 'I'.

<1fs_date_range>-option - 'BT'.

<lfs_date_range>-high - im_return_date.

ELSE.

<1fs_date_range>-sign - "I*.

<lfs_date_range>-option - 'EQ'.

ENDIF.

Use the standard BAPI to perform the flight query:

CALL FUNCTION

BAPI_FLIGHT_GETLI ST'

EXPORTING

destination_from - 1s_from_dest

destination_to - ls_to_dest

TABLES

263

10 | Working with the SAP List Viewer

date_range

flight_11st

1t_date_range

ex_results.

ENDMETHOD.

ENOCLASS. -lcl_flight_model

Listing 10.1 The Flight Data Model Class

Normally, you would want to store the search results inside the model instance so

that you can define additional business methods to work on this data, and so on.

However, class CL_SALV_TABLE requires direct access to the internal table that it

displays so that it can sort the records in place. This requirement is difficult

because we prefer not to expose data attributes in the public interface of class

lcl_fl ight_model. If there was more time, a framework could be developed in

the controller layer that seamlessly bound this data using getter and setter meth-

ods. This technique is used in the MVC framework associated with Business

Server Pages (BSPs) technology, for example. For now, to keep it simple, the

search results are exported in the ex_results parameter of method

query_fl ights so they can be cached locally in the controller class.

10.3.4 Developing the Report Controller Class

Initially, the controller class for our report should be veiy straightforward. The

only event that it needs to respond to is a request to display the report. Listing

10.2 shows our first pass at the controller class definition for our flight query

report. The class 1cl_query_ctrl, which is also part of the include program

ZALVFLIGHT_CLASSES. provides a public instance method called do_display_

report to handle requests to render the report on the screen.

*& *

*& Include ZALVFLIGHT_CLASSES *

CLASS lcl_flight_model IMPLEMENTATION.

ENOCLASS. "lcl_flight_model

CLASS lcl_query_ctrl DEFINITION.

PUBLIC SECTION.

METHODS:

constructor.

do_display_report

264