Web Application Builder for BSPs

Published on January 2017 | Categories: Documents | Downloads: 54 | Comments: 0 | Views: 335
of 58
Download PDF   Embed   Report

Comments

Content


Web Application Builder for BSPs
PDF download from SAP Help Portal:
http://help.sap.com/saphelp_snc70/helpdata/en/1f/30f839e7290433e10000000a11402f/frameset.htm
Created on July 03, 2014
The documentation may have changed since you downloaded the PDF. You can always find the latest information on SAP Help Portal.
Note
This PDF document contains the selected topic and its subtopics (max. 150) in the selected structure. Subtopics from other structures are not included.
© 2014 SAP AG or an SAP affiliate company. All rights reserved. No part of this publication may be reproduced or transmitted in any form or for any purpose
without the express permission of SAP AG. The information contained herein may be changed without prior notice. Some software products marketed by SAP AG
and its distributors contain proprietary software components of other software vendors. National product specifications may vary. These materials are provided by
SAP AG and its affiliated companies ("SAP Group") for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be
liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the express
warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty. SAP and other
SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and other
countries. Please see www.sap.com/corporate-en/legal/copyright/index.epx#trademark for additional trademark information and notices.
Table of content
PUBLIC
© 2014 SAP AG or an SAP affiliate company. All rights reserved.
Page 1 of 58
Table of content
1 Web Application Builder for BSPs
1.1 Introduction
1.1.1 Structure of a BSP Application
1.1.2 Event Handler
1.1.3 Page Attributes
1.1.4 Global Objects
1.2 Basic Functions
1.2.1 Creating BSP Applications
1.2.2 Creating Pages
1.2.3 Creating a Controller
1.2.4 Creating Error Pages
1.2.5 Determining the Page Flow
1.2.6 Creating References to MIMEs
1.2.7 Activating BSP Applications
1.2.8 Executing BSP Applications
1.3 Model View Controller (MVC)
1.3.1 MVC Design Pattern
1.3.2 Using MVC for BSP
1.3.2.1 Creating a Controller
1.3.2.2 Creating a View
1.3.2.3 Testing Controllers
1.3.2.4 Calling (Sub) Controllers
1.3.2.5 Calling a View
1.3.2.6 Creating Error Pages
1.3.3 From Pages to Controllers
1.3.4 Call Options of BSP Components
1.3.5 Navigation
1.3.6 Lifetime
1.3.7 Data Binding
1.3.7.1 Calling the Model Class by the Controller
1.3.8 Components
1.3.8.1 Process Flow
1.3.8.2 Creating Your Own Components
1.3.8.2.1 Creating the Top-Level Controller
1.3.8.2.2 Creating Components
1.3.8.2.3 Calling Components
1.3.8.2.4 Determining Input Processing
1.3.9 Class CL_BSP_CONTROLLER2
1.3.10 Examples of Architecture
1.3.10.1 BSP Application with Controllers and Views
1.3.10.2 BSP Application with Several Views per Controller
1.3.10.3 Combination of the Previous Examples
1.3.10.4 Calling Controllers of Other Applications
1.3.10.5 Calling Several Controllers from a View
1.3.11 Model View Controller Tutorial
1.3.11.1 Creating a Controller
1.3.11.2 Creating a View
1.3.11.3 Calling a Controller
1.4 Defining Your Own BSP Extension
1.4.1 BSP Extension Framework
1.4.2 Creating BSP Extensions
1.4.3 Defining BSP Elements
1.4.3.1 Defining the Element Content
1.4.3.2 User-Defined Validation
1.4.3.3 Iteration Through Element Content
1.4.3.4 Manipulation of the Element Content
1.4.3.5 Pass by Reference for Attributes
1.4.4 Activating the BSP Extension
1.4.5 Implementing Element Handler Classes
1.4.5.1 Generated Classes and Class Hierarchy
PUBLIC
© 2014 SAP AG or an SAP affiliate company. All rights reserved.
Page 2 of 58
1.4.5.2 Basis Class CL_BSP_ELEMENT
1.4.6 Entering Documentation
1.4.7 Using BSP Elements
1.4.7.1 Example: Using Extensions in BSP Pages
1.5 Implementing External Tools with WebDAV
1.5.1 Implementing the Page Layout Using External Tools
1.5.2 Mass Import for MIMEs Using WebDAV
1.6 Tips & Tricks
1.6.1 Copying Page Attributes
1.6.2 Mass Import for MIMEs Using WebDAV
PUBLIC
© 2014 SAP AG or an SAP affiliate company. All rights reserved.
Page 3 of 58
1 Web Application Builder for BSPs
As of SAP Web Application Server 6.10, the Web Application Builder is delivered as an integrated platform for the development of Web applications.
The Web Application Builder is fully integrated into the Object Navigator (SE80) and allows you to develop a new kind of Web application called BSP
applications. The core parts of these applications are the Business Server Pages (BSPs) and MIME objects.
The following documentation describes how you can most effectively use the functions of the Web Application Builder and the integrated tools and utilities for your
own Web applications.
Topics of this Documentation
· Introduction
· Basic Functions
· The Model View Controller Concept
· Defining Your Own BSP Extension
· MIME Repository
· Implementing External Tools Using WebDAV
· Tips & Tricks
Other Topics
BSP Directives
DDIC Services for BSP Applications
SAP Web Application Server
See also:
Business Server Pages

1.1 Introduction
Features of the Web Application Builder
· Creating BSP applications and their pages (BSPs)
· Editing the layout of BSPs using HTML and the scripting languages ABAP and JavaScript
· Declaring page parameters for page-based data storage
· Implementing event handlers using ABAP
· Defining the page flow using navigation requests
· Integration of the MIME Repository for storing MIME objects
· Creating and defining themes for adjusting the layout
· Provision of an interface for using external tools for layout implementation using the WebDAV protocol
Prerequisites
§ Any external Web development environments that you want to use for implementing the page layout must support the WebDAV protocol.
External HTML editors function as the WebDAV client, while the mySAP.com application server is the WebDAV server. WebDAV is an
extension of the HTTP protocol and provides an infrastructure for editing documents across distributed Web development environments. To be able
to function as the WebDAV server, the mySAP.com application server includes a WebDAV service.
See also:
Structure of a BSP Application
Event Handlers
Page Attributes
Global Objects

1.1.1 Structure of a BSP Application
A Business Server Page (BSP) application is an independent development project that is created and edited in the SAP development environment (transaction
SE80). External design tools, such as Adobe GoLive, Dreamweaver, or Microsoft FrontPage 2000 can be used to design the BSP application, as well as BSP
extensions.
PUBLIC
© 2014 SAP AG or an SAP affiliate company. All rights reserved.
Page 4 of 58
Analog to a classic transaction, a BSP application consists of a user interface and business logic that is assigned to a logical unit, in this case the BSP
application.
The user interface of a BSP applications includes:
· Static Web sites
· Dynamically generated Web sites, which are BSPs or templates that contain server-side scripting that is executed dynamically at runtime to generate a static
Web site BSPs can either be pages with flow logic or views.
There can also be controllers if the MVC design pattern is used
· Various MIME objects, such as pictures, icons, sound files, style sheets, and so on, that are parts of a typical Web application
All of these objects are integrated in the Change and Transport Organizer as parts of the BSP application and are handled as a logical unit. This allows all objects
that are part of a BSP application to be fully and consistently transported between all the systems in an SAP system landscape.
The business logic can be accessed from the BSP application using the typical methods, such as BAPIs, function modules, or class libraries. In addition, the
BSP programming model provides a structuring tool, the BSP-Application class , that can be used to encapsulate the business logic functionality in the BSP
application.
A BSP application consists of the following components:
· Controller
Controllers contain business logic and application data. Controllers assess the data of an incoming request based on a model and then select a suitable
view for rendering the response to the user, see also Model View Controller (MVC).
· Business Server Pages (BSPs)
BSPs are the Web sites that are displayed in the browser when the application is in use. BSPs can contain static HTML code and dynamic scripting code
(ABAP or JavaScript). The scripting code is interpreted on the server. The exact structure of a BSP is described in Building an BSP.
A page can have the following versions:
¡ Page with flow logic
These are simple pages with event handlers, but without much application logic or visualization elements. It is possible to build a BSP application
exclusively out of pages with flow logic and event handlers.
¡ View
Views are used to visualize data, see also Model View Controller (MVC).
¡ Page fragment
These are created in the same way as normal BSPs, but are then marked as page fragments. Other BSPs can also include these fragments using the
PUBLIC
© 2014 SAP AG or an SAP affiliate company. All rights reserved.
Page 5 of 58
includedirective (see Include Directive).
· Navigation structures
The navigation structure determines which navigation request is used to direct the navigation process from which page to which subsequent page.
· Application class
The business logic of a BSP application is encapsulated in an application class. This class is realized by means of a global ABAP class which implements
the access to business data using BAPI calls, for example. Every page of a BSP application can directly reference the components of this class (attributes,
methods, and so on) using the predefined Object application.
You can also assign several BSP applications to an application class.
For more information, see Applications Class of a BSP Application.
· MIME objects
In the SAP system, all MIMEs, such as graphics, style sheets (used to define formatting properties of individual HTML tags), audio files, video files, and so
on, are stored and administered in a central repository, the MIME repository.
For every new BSP application, a directory of the same name is created in the MIME repository. This directory is used as a storage location for all
application-specific MIMEs.
See also:
Accessing a BSP Application
Starting and Ending a BSP Application
Building a BSP


1.1.2 Event Handler
Event handlers allow the separation of static and dynamic code in a page. The layout processing deals with the static data, while the event handlers deal with the
dynamic data.
The following predefined event handlers are available in the SAP system:
Event Handler Description
OnCreate OnCreate
is called once when the page is first created (stateful mode), and performs a once-off data
initialization or object creation.
OnRequest OnRequest
is called whenever a request is made for a particular page and is used to restore the
internal data structures from the request. This is important when working in stateless
mode.
OnInitialization This event handler is mainly used for data retrieval. For example, it allows data
required for displaying the BSP to be read from the database. It can also
execute any program.
OnInputProcessing This event handler checks and processes user input. It can also define
navigation, that is, whether the user should be taken to the same page or
another when the BSP is called.
OnManipulation You can use this event handler to manipulate the HTTP data stream later.
OnDestroy This event handler is available for special functions.
The ABAP syntax checks that apply in the context of ABAP Objects also apply to event handlers.
Read and modify access to page attributes is available in all handlers. Global objects are also available.
Global objects and their signatures for individual event handlers are displayed if you choose in the Web Application Builder.
The use of the individual event handlers is explained in more detail in the individual sections of the documentation.
See also:
Control Flow of BSPs


1.1.3 Page Attributes
Page attributes are parameters that are declared explicitly for one page. You can access page attributes from the layout and from all event handlers. You use
page attributes to store data that is determined in the event handler OnInitialization , and you can use the page attributes to make the data accessible to layout
processing and the remaining event handlers.
Access to the contents of the page attribute is not, however, given automatically at any time. If, for example, you fill an internal table in OnIntialization that you
have defined as a page attribute, although this definition is known in OnInputProcessing , the table contents is not known if you are working in stateless mode.
Additional information is described below.
There are two types of page attributes:
Automatic page attributes
Non-automatic page attributes
PUBLIC
© 2014 SAP AG or an SAP affiliate company. All rights reserved.
Page 6 of 58
Automatic Page Attributes
If you mark a page attribute as ‘automatic’ ( auto in the system), the attribute automatically gets its values via the calling URL or via the navigation process from
other pages. This kind of attribute only has to be declared for one page. It is identified by its name equivalence. If another page uses a parameter with the same
name, at runtime that parameter automatically gets the same values as the attribute.

navigation -> set_parameter(name = 'FLIGHT' value = 'LH' )
Let us assume that you have defined
FLIGHT as an automatic page attribute and assigned it a value from the navigation process.
If you then use a parameter of the same name on another page, this parameter will automatically get the value ' LH' (Lufthansa) at runtime.
Possible Types for Automatic Page Attributes
Before SAP Web Application Server 6.10, auto page attributes could only have the type
STRING.
Now, other types are available:
Elementary types except for
XSTRING
Structures
Tables

If
firstname is a field in a structure called myaddress of the type address, and myaddresses is a table of addresses, you can access firstname in the layout
as follows:
<input type=text name="myaddress.firstname">
myadresses[i].firstname
allows you to specify the first name in question in the line of the table represented by ‘i’, that is, if i=6, the first name used in line 6 of the table is being referred to.
Non-automatic page attributes
If you flag a page attribute as non-automatic, the attribute gets its values from the class attribute.
Transferring Parameters Between Pages: Visibility of Page Attributes
The visibility of page attributes when parameters are transferred between BSP pages depends on whether the navigation is explicit or implicit.
Explicit navigation
For example, if
navigation->goto_page(page.htm) is called, this is explicit navigation. It does not matter if the navigation takes you to the same page from which you came.
In explicit navigation, the page object is always reinstantiated. When the page object is being reinstantiated, in both stateful and stateless mode, the attributes
with
navigation->set_parameter must be transferred to auto page attributes of the same name, so that the values that were set are not lost.
Implicit navigation
User input triggers the sending of a request. Because no explicit navigation has been provided, the same page is run again.
With implicit navigation, the page attributes are transferred automatically from OnInputProcessing to OnInitialization , both in stateful and stateless
mode.
The auto page attributes are refilled by the request, both in stateful and stateless mode.
The difference is that, in stateful mode, any non- auto page attributes that may have changed retain the changed value, whereas in stateless
mode, the values are reset to the original values. This is because the page instance stays ‘alive’ in stateful mode, but is reinstantiated in stateless
mode.
Lifetime of Page Attributes
When you navigate between pages, there are the following cases of different lifetimes for automatic and non-automatic page attributes:
Lifetime of attributes remaining on the same page
Lifetime of attributes with navigation to the same page
Lifetime of attributes with navigation to a different page
Lifetime of attributes remaining on the same page
No navigation takes place.
Attribute Type Value in Request (Example
Value)
Value in
OnInputProcessing
Explicit Transfer Value in OnInitialization
automatic SAP SAP No SAP
automatic SAP SAP Yes SAP
Non-automatic SAP No SAP
Non-automatic SAP Yes SAP
PUBLIC
© 2014 SAP AG or an SAP affiliate company. All rights reserved.
Page 7 of 58

Lifetime of attributes with navigation to the same page
The navigation object is used (
navigation->goto_page(samepage.htm)) to navigate to the same page.
Attribute Type Value in Request (Example
Value)
Value in
OnInputProcessing
Explicit Transfer Value in OnInitialization
automatic SAP SAP No
automatic SAP SAP Yes SAP
Non-automatic SAP No
Non-automatic SAP Yes

Lifetime of attributes with navigation to a different page
The navigation object is used (
navigation->goto_page(otherpage.htm)) to navigate to a different page.
Attribute Type Value in Request (Example
Value)
Value in
OnInputProcessing
Explicit Transfer Value in OnInitialization
automatic SAP SAP No
automatic SAP SAP Yes SAP
Non-automatic SAP No
Non-automatic SAP Yes


1.1.4 Global Objects
Certain global objects can be accessed from all parts of a BSP (initialization, layout, input processing). For example, the request and response object, the
application object (if an application class was defined for the BSP application), the navigation object, and the runtime object, can be accessed.
The following global objects are available:
Object application
Object navigation
Object messages
Object runtime
Object request
Object response
Object page
Object page context
This is described in more detail below.
The objects and their signatures for the individual
event handlers are displayed if you choose in the Web Application Builder.
Example:


PUBLIC
© 2014 SAP AG or an SAP affiliate company. All rights reserved.
Page 8 of 58
1.2 Basic Functions
Creating BSP Applications
Creating Pages
Creating the Controller
Creating Error Pages
Determining the Page Flow
Activating BSP Applications
Executing BSP Applications


1.2.1 Creating BSP Applications
You can create BSP applications only with the Web Application Builder but not with external Web development environments.
Prerequisites
If you wish to create the BSP application in another namespace that differs from the standard namespace, you may only use the values provided by the system
as namespace identifiers.
Procedure
Like all Repository objects, a BSP application can be created by copying it. Note that the corresponding MIMEs are not copied to the target object
when you copy BSP applications. For each new BSP application, the system creates an identically named directory in the MIME Repository, but
it is empty.
To create a new BSP application:
1. Open the Object Navigator (SE80).
2. Choose the BSP Application category from the object list selection and enter the name of the application you want to create.
If you wish to assign the new BSP application to a valid namespace XYZ that differs from the standard namespace, you must place the namespace as a
prefix in front of the actual name of the BSP application. The complete name must then be written in this form: /XYZ/BSPApplication.
3. Click or choose ENTER to confirm your entry.
The system checks to see whether or not a BSP application with that name already exists in the SAP System. If it does not exist already, the Create Object
dialog box appears.
4. Choose Yes to create the BSP application.
The dialog box Web Application Builder: Create BSP Application is displayed.
5. Enter a meaningful Short Description .
6. Choose Create .
The system then displays the Create Object Catalog Entry dialog box.
8. Assign a package to the service.
The system displays the BSP application you have created in the object list tree structure.
Result
The BSP application has been created in the Repository as a development object.
With the new BSP application, a service node with the same name is automatically generated in the HTTP service maintenance (transaction
SICF). As a rule, no such entry exists for BSP applications that were created in earlier releases. In such cases, you must create this node
manually in the service maintenance transaction. You call up the corresponding display through the menu function Goto → HTTP Service
Maintenance . Execute the steps as they are described in the section Creating an ICF Service.
Afterwards, you can assign further attributes for the BSP applications at this point:
Property Description
Initial BSP Here you enter the name of a page that is to be used to start the BSP application. This
entry is important whenever you test the BSP application from within the workbench.

Application class If you enter the name of an ABAP class as the application class in this field, then this
class can be directly referenced in the BSP application using the predefined object
application. You do not need to create an instance of the application class and you can
directly access its components (methods, attributes, and events) from any BSP page.
An application class is used to transfer the business logic to a global class that, in turn, is
used to access business data using BAPI calls, for example.
You can assign application classes to more than one BSP application. (All these
PUBLIC
© 2014 SAP AG or an SAP affiliate company. All rights reserved.
Page 9 of 58
applications use the same business logic.)
Note that the application class must exist in the same system and cannot be addressed
through RFC.

Stateful

Activate this checkbox whenever the BSP application should be implemented as stateful.
For an explanation of this, refer to the section Stateful BSP Applications.
See also:
Creating Pages
Creating a Controller


1.2.2 Creating Pages
Use
You can implement the layout for each page (often called BSP) using the script languages ABAP and JavaScript.
BSPs can have different attributes: Therefore, when you create a page, we distinguish formally between 3 page types:
You can implement a page with flow logic or a view (or even a controller) as an error page. See also: Creating Error Page
Prerequisites
You have already created the BSP application.
Procedure
To create a page for your BSP application from within the object list (SE80):
1. Right-click the BSP application.
2. From the context menu, choose Create → Page .
The system displays the Create Page dialog box.
3. Provide further specifications on the page by enter the name of the page and a short page description . Afterwards, select the required option for the page
type ( view / page with flow logic / page fragment ).
4. Choose Enter to confirm your entries.
The system displays the layout editor for the new page in the tool area.
5. Choose Save to save your page.
Result
The created page is assigned as subobject to the BSP application and stored in the Repository. Besides the basic HTML structure, the page directive is pre-
generated:
<%@ page language="abap" %> bzw. <%@ page language="javascript" %>
The page directive determines the script language. The script languages supported are currently ABAP and JavaScript.
If you have chosen the page type View , both tab pages Event handler and Type definitions are suppressed – in contrast to a page with flow
logic .
If you have chosen Page fragment as the page type, the tab pages Event handler , Page attributes , and Type definitions are suppressed.
See also
Page with flow logic A page defined this way can implement the entire flow logic itself (event handler-based model). The page can have event handler and page parameters (including automatic attributes) in addition to the layout.
Such a page is executable and can be addressed through a URL or through navigation from other pages.
View Views are used solely for displaying application data. They have page parameters in addition to the layout section. In contrast to the page with flow logic, views have neither event handlers nor automatic page attributes.
A controller class is generally assigned to a view. This class controls the view calls and is responsible for communication with the model.
Views are based on the MVC Programming Model and allow you to clearly separate the application logic from the presentation logic in BSP applications.
Page fragment Page fragments are special parts. You cannot use them as stand-alone pages in an application.
<%@ include file=' /fragment.htm' %>.
A page fragment cannot define event handlers or parameters.

PUBLIC
© 2014 SAP AG or an SAP affiliate company. All rights reserved.
Page 10 of 58
Determining the Page Flow
Creating the Controller
BSP Directives


1.3.11.1 Creating a Controller
Use
You create a controller to use a
Model View Controller design pattern in your BSP application. You can use a controller for the initial access (see also Testing Controllers).
Prerequisites
You are in a system from SAP Web AS 6.20.
Procedure
Use the Web Application Builder in the ABAP Workbench (Transaction
SE80) to create a controller object as a sub-object of your BSP application.
In doing so, you determine the controller name and the class name of the controller. The URL is automatically inserted from the name of the BSP application and
the controller name.
In the Class Builder (Transaction
SE24), create the class that is derived from CL_BSP_CONTROLLER2.
If you create your class directly from the Web Application Builder by double-clicking on the class names, then the inheritance of
CL_BSP_CONTROLLER2 has already been configured.
Overwrite some of the methods of your class, especially
DO_REQUEST.
You can find additional information about these methods in
CL_BSP_CONTROLLER2 and Process Flow.
4. Save and activate your class and your controller.
Example
You can find examples of controllers in BSP application
ITMVC2.


1.3.2.6 Creating Error Pages
Use
In case that on a page that contains flow logic, a view, or a controller, a runtime error occurs, you can assign an error page to it. When a runtime error occurs
during execution of this (other) page or this controller, the system automatically processes the assigned error page and sends it to the browser. If no error page is
assigned to a page/a controller, in case of a runtime error, the system displays a standard page. If runtime errors occur in a called controller or view and there is
no error page, this section remains empty.
If different types of exception occur, you can use the ERROR_OBJECT error object from class CX_ROOT in your error page. You can implement this object
using dynamic ABAP and use GET_TEXT or GET_LONGTEXT methods to output an appropriate error text for your application (message short or long text).
Use the functionality in the HTTP service tree (Transaction SICF) to create error pages if short dumps occur. See also Error Pages.
Prerequisites
· You created the page (the controller) you want to use as error page. See also: Creating Pages or Creating Controllers.
· You cannot assign an error page to a page or a controller that itself is marked as error page.
· With views you must not assign a controller class, because an error page is always called implicitly by the BSP runtime.
PUBLIC
© 2014 SAP AG or an SAP affiliate company. All rights reserved.
Page 11 of 58
Procedure
To identify a page / a controller as an error page:
1. Go to the properties display and switch to Change mode if necessary.
2. In section Error Handling , mark the checkbox Is Error Page .
3. Save your entries and activate the page or controller.
Result
You can now assign this page or controller as Assigned Error Page to another page or another controller.
Example
The BSP application BSP_MODEL in the system contains an example of how to implement and use an error page.


1.2.5 Determining the Page Flow
Use
After creating the pages of your BSP application, you can determine the page flow, that is the transitions between the pages. To do this, you assign a navigation
request to each page transition. Assigning the pages using a navigation request provides you with a purely formal ("static") description of the navigation scheme
within the BSP application. The exact point at which a page is exited is defined through the navigation object:
navigation -> next_page('<Navigation request>')
However, this is not the only way to trigger a navigation step. For example, you do not need a navigation request if you determine the page transitions by
specifying the URL.
Procedure
To determine the page transitions, select the respective BSP application and enter the First Page , the Target Page and the Navigation Request manually on
the Navigation tab.


1.2.6 Creating References to MIMEs
To create a reference to MIME Repositorys objects on a page of your BSP application, you insert the object URL directly from the browser using Drag and Drop.
Depending on the MIME type, you can then use the URL as the source in the appropriate HTML tag.

It is recommended that you create a reference to MIMEs from the application-specific folder or from the /SAP/BC/BSP/[namespace]/PUBLIC
folder of the MIME Repository only. References to other MIMEs not specific to the application should be avoided since these objects may be
moved or even deleted at any time. You cannot create a where-used list for MIMEs.
Prerequisites
The editor displays the source code of the BSP layout in change mode.
Procedure
1. Start the browser of the MIME Repository.
2. Select the MIME object you want to insert in the tree display and drag it to the position in the editor where you want to insert the URL.
Result
The object URL is inserted at the mouse position indicated. Insert a corresponding HTML tag depending on the MIME type and usage.


PUBLIC
© 2014 SAP AG or an SAP affiliate company. All rights reserved.
Page 12 of 58
1.2.7 Activating BSP Applications
You can either activate single pages or the entire BSP application.
Prerequisites
A page or an application can only be activated successfully, if the syntax is correct and the check run does not return errors. This is why you should first perform
a syntax check for the pages concerned.
Procedure
To activate your entire BSP application, proceed as follows:
1. Double-click the BSP application.
2. Choose Activate from the context menu of the Object Navigator, or click the corresponding pushbutton in the toolbar.
The system displays a list of all inactive objects. This list includes all inactive subobjects of the BSP application.
3. Confirm the selection by clicking .
If you receive an error message, remove the errors first and then retry to activate the pages.
If activation was successful, the message Object(s) activated appears in the status bar.
Result
You have generated the runtime version both for the BSP application and for the individual BSPs and can now test your application.
See also
Executing BSP Applications


1.2.8 Executing BSP Applications
Prerequisites
You have successfully activated the BSP application and the BSPs to be tested.
Procedure
Double-click the respective BSP application in the object list.
Click the pushbutton in the toolbar.
Select the page you want to execute.
The system starts the Web browser and, if necessary, displays a logon dialog box.
Log on to the system if required.
Result
The selected page is started through the following HTTP address:

http://<Application Server:Port>/<Service>/<BSP Application>/<Page.htm>
If you do not specify a service under Utilities → Settings → Business Server Pages , the system uses a standard service for executing your
application.
See also
Activating BSP Applications


1.3 Model View Controller (MVC)
Use
SAP Web Application Server 6.20 has implemented the Model View Controller (MVC) design pattern. This is widely used in the user interface programming field
and which has established itself as an enhancement of the previous BSP implementation model. Its controller-based approach ensures an even clearer
PUBLIC
© 2014 SAP AG or an SAP affiliate company. All rights reserved.
Page 13 of 58
distinction between application logic and presentation logic in BSP applications. You can structure graphical user interfaces clearly and organize them in logical
units, even with complex applications.
Using the MVC design pattern has the following benefits:
● Simplified structuring of BSP applications, since the view is cleanly separated from the controller and the model. This facilitates modification of BSP
applications and makes them considerably easier to maintain.
● You have the option of generating program-driven layout. The HTML/XML output is therefore created by program code instead of a page with scripting.
● Navigation using the <bsp:goto> element and call using the <bsp:call> element. The advantage of using <bsp:goto> navigation over redirect is that there
is no additional network traffic. Moreover, you remain in the same work process, which can be beneficial when creating objects and memory space. Calling
using the <bsp:call> element is more variable than insertion using the INCLUDE directives, since it is triggered at runtime.
With the call option using <bsp:call>elements, you can also distribute the user interface into components.
● Optimized performance due to fewer redirects.
● Intuitive and easy-to-use interface for application development.
Previous BSP applications, which did not have MVC, can still run without any changes being made. MVC does, however, have various
advantages with more complex applications. See Using MVC for BSP.
Integration
The MVC design pattern is integrated in the BSP programming model and the Web Application Builder of the ABAP development environment (Transaction
SE80) from SAP Web Application Server 6.20.
Features
A BSP application can consist of one or more controllers and Business Server Pages, as well as known elements such application classes, MIME objects and
themes. A BSP can have different characteristics. It is either a page with flow logic (as before), or a view or a page fragment:
Within a BSP application, there can be several controllers, several views and several pages with flow logic.
Controller
A controller is the instance of a central controller class. In the BSP-MVC environment, each controller is directly or indirectly derived from the same base class
CL_BSP_CONTROLLER2, where the central method is DO_REQUEST.
There is a URL for every controller that can be addressed externally, such as using a browser. A controller can therefore be used as the initial point of entry to a
BSP application. The mapping of the URL to the controller class is determined in the BSP application.
A controller is the controlling instance in the MVC design pattern, where it also acts as the controlling mechanism. It carries out the following tasks:
● It provides the data
● It is responsible for selecting the correct layout
● It triggers data initialization
● It executes input processing
● It creates and calls a view instance
Layout selection
A controller will usually call a view instance for creating the HTML / XML output. The controller can call a view that is created using a factory method. The theme or
the browser variant, for example, can be used here as the selection criteria. If a controller passes the control to a view, it can – and should – set attributes to the
view. These attributes may just be data, or a reference to one (or, in extreme cases, several) model(s). A reference to the controller is automatically transferred.
A controller has access only to views in its own application.
A controller can, however, delegate processing to another controller, and this controller can be located in a different application.
A controller should not work with too many views, since all of these requests are processed centrally. On the other hand, the controller should jump to all views that
have the same or very similar input processing.
Data provision
Although a controller does not have any pre-defined attributes, they can be set and read using generic methods. However, a controller should provide a method
init_attributes, which is responsible for filling the attributes. There is a service method that facilitates filling the attributes.
Event handling
PUBLIC
© 2014 SAP AG or an SAP affiliate company. All rights reserved.
Page 14 of 58
The controller also takes care of event handling. It therefore takes on all the tasks that were performed by the event handlers in the previous BSP program model.
It performs the request processing, manages the data transfer and is responsible for controlling the view and the view lifecycle.
Redirects from the controller or page to the controller or page can be easily implemented. See Navigation
If it is not possible to decide which page should follow until input processing, we recommend that you let the controller branch to different views (for
example, if it is checked internally whether the user has registered as a customer, the corresponding data is then queried).
A controller can also be used to delegate control over screens to the sub-controller. A controller can delegate the control for a whole screen or a screen section to
one or more different sub-controllers. This makes it possible to depict a complex tree structure of controllers, including components (consisting of both cascading
controllers as well as their corresponding views).
You can find information about the life cycle of controllers in Lifetime.
View
Views are only responsible for the layout; they visualize the application data. Views are very much like pages, although they do not have event handlers, auto-
page attributes, or their own URL. Unlike auto-page attributes, normal page attributes can be used that are then filled by the controller. Controllers should control
calling views and communicate with a model.
If the type of controller class is known for a view (see the Properties tab for the view), the view can also access the attributes of the controller class.
You can find information about the life cycle of views in Lifetime.
Model
The model is used to obtain all necessary application data from the database. It represents the internal data structures and corresponds to the application class
used in the remaining BSP programming model. The model is responsible for carrying out the central actions of reading, modifying, blocking and saving data.
When used with controllers, this controller can create a reference to a class that is used as a model. Class CL_BSP_MODEL is available for this (see also Data
Connection).
MVC in BSP Applications
For more information, see:
Using MVC for BSP
Class CL_BSP_CONTROLLER2
Navigation
Lifetime
Call Options of BSP Components
Components
Activities
Create Controller
Create View
Call Controller
Call View
Create Error Pages
A simple Tutorial is provided to guide you through your first steps with the MVC design pattern.
Example
PUBLIC
© 2014 SAP AG or an SAP affiliate company. All rights reserved.
Page 15 of 58
You can find an example of MVC in the system in BSP application BSP_MODEL.
Basic information is also provided about the following Architecture Examples:
BSP Application with Controllers and Views
BSP Application with Several Views per Controller
Combination of the Previous Examples
Calling Controllers from Other Applications
Calling Several Controllers from a View


1.3.1 MVC Design Pattern
The Model View Controller (MVC) design pattern contains a clear distinction between processing control, data model and displaying the data in the interface.
These three areas are formally distinguished from each other by three objects: model, view and controller. As a result, you can easily split Web applications
into logical units.
The model is used as an application object of the application data administration. It responds to information requests about its status, which usually come from
the view, as well as to statements for status changes, which are usually sent by the controller. In this way, only the model is used to process data internally,
without making reference to the application and its user interface.
There can be different views for a model, which can be implemented using different view pages.
The view handles the graphical and textual output at the interface and therefore represents the input and output data in each interface element, such as
pushbuttons, menus, dialog boxes and so on. The view takes of visualization. To visualize the status, the view queries the model, or the model informs the view
about possible status changes.
The controller interprets and monitors the data that is input by the user using the mouse and the keyboard, causing the model or the view later to change if
necessary. Input data is forwarded and changes to the model data are initiated. The controller uses the model methods to change the internal status and then
informs the view about this. This is how the controller determines reactions to the user input and controls processing.
The view and the controller together form the user interface.
Since the model does not recognize either views or the controller, internal data processing is detached from the user interface. As a result, changes to the user
interface have no effect on internal data processing and the data structure. You also have the option, however, of displaying the data in different formats; you can
display election results as a table, a bar chart or as a pie chart.
You can find additional information about the MVC design pattern on the Internet and in current specialist literature.


1.3.2 Using MVC for BSP
Uses
All BSP applications that you created with SAP Web AS 6.10 can also be executed without MVC. In general, you do not need to change anything.
The previous BSP implementation model gives you the option of controlling event handling and navigation using redirects.
The MVC design pattern provides you with various advantages, so that you can consider converting to MVC in the following cases:
If your pages are dynamically composed of several parts (components)
A controller can assemble a page from several views. As a result, the layout is
componentized.
If input processing is so complex that it should be subdivided into different methods
A controller offers great flexibility, especially during input processing, since you can create and call new methods.
If the system cannot decide which page comes next until input processing, we recommend that you let the controller branch to different views.
If redirects using navigation can lead to performance problems (such as slow diversion)
If visualization logic is fairly important, since you can use MVC to separate the logic from the layout
If the layout from a different person is being processed as the visualization logic
If parts of the layout should be created by the program, such as by a generating program or an XSLT processor
Combination of MVC with BSP
You can combine the technology of the previous implementation model for BSPs with the new MVC design pattern.
In an application, there may be pages with flow logic as well as controllers and views
The views can only be called by the controllers.
Redirects from pages to controllers and back can take place with the help of redirect using the navigation methods.
In the page layouts you can use the
<bsp:call> element or the <bsp:goto> element to call a controller. You cannot use these elements to call pages.
Process
Use the top controller as a point of entry to your BSP application and its process flow. First create a controller (see
Creating Controllers).
PUBLIC
© 2014 SAP AG or an SAP affiliate company. All rights reserved.
Page 16 of 58
Then a call a view from this top controller. Next create a corresponding view (see
Creating Views).
Now
test your controller.
Then call the controller or the sub-controller (see
Calling Controllers), and then the view (see Calling Views).
If necessary, you can also create
error pages.


1.3.11.1 Creating a Controller
Use
You create a controller to use a
Model View Controller design pattern in your BSP application. You can use a controller for the initial access (see also Testing Controllers).
Prerequisites
You are in a system from SAP Web AS 6.20.
Procedure
Use the Web Application Builder in the ABAP Workbench (Transaction
SE80) to create a controller object as a sub-object of your BSP application.
In doing so, you determine the controller name and the class name of the controller. The URL is automatically inserted from the name of the BSP application and
the controller name.
In the Class Builder (Transaction
SE24), create the class that is derived from CL_BSP_CONTROLLER2.
If you create your class directly from the Web Application Builder by double-clicking on the class names, then the inheritance of
CL_BSP_CONTROLLER2 has already been configured.
Overwrite some of the methods of your class, especially
DO_REQUEST.
You can find additional information about these methods in
CL_BSP_CONTROLLER2 and Process Flow.
4. Save and activate your class and your controller.
Example
You can find examples of controllers in BSP application
ITMVC2.


1.3.11.2 Creating a View
Use
You create views to use the view of the
Model View Controller design pattern in your BSP application.
Prerequisites
You are in a system from SAP Web AS 6.20.
Procedure
Use the Web Application Builder in the ABAP Workbench (Transaction
SE80) to create a page with the page type View as a sub-object of your BSP application.
Specify the layout and any attributes that may be required.
Save and activate your view.
PUBLIC
© 2014 SAP AG or an SAP affiliate company. All rights reserved.
Page 17 of 58
Example
You can find examples of views in BSP application
ITMVC2.


1.3.2.3 Testing Controllers
Use
You can use a controller as an initial point of entry to your BSP application. In the BSP programming model without MVC, you have always used a central page
as the initial page that you called
start.htm, for example. Use the main controller instead in connection with the MVC design pattern.
Prerequisites
You are in a system from SAP Web AS 6.20.
You have successfully activated your BSP application and the controllers and views to be tested.
Procedure
Place your cursor on the top controller in your BSP application.
Click on ( Test/Execute ) in the application toolbar.
The browser starts and a logon screen may be displayed.
Log on to the system if this is necessary.
Result
The selected controller is started in the browser.
1.3.2.4 Calling (Sub) Controllers
Use
Sub-controllers can be instantiated and called by a subordinate controller (main controller) or by a view or a page.
We recommend that a subordinate controller in method
DO_INIT creates a sub-controller, sets the parameters accordingly and then calls the sub-controller from the appropriate view.
Prerequisites
You are in a system from SAP Web AS 6.20.
You have crated at least one
controller for your BSP application, or at least a main and a sub-controller.
Calling a Controller
Create the controller instance. You have the following options:
data: l_ctrl type ref to cl_bsp_controller.
l_ctrl = create_controller( key = navigation_key ).
or
l_ctrl = create_controller( application_namespace = 'fred'
application_name = 'hugo' controller_name = 'do_something.do' ).
application_namespace
and application_name are optional. Unless you specify otherwise, the system uses the current values.
You can also specify each of the controller IDs.
1. If necessary, set the request parameters:
l_ctrl->do_initattributes( ).
PUBLIC
© 2014 SAP AG or an SAP affiliate company. All rights reserved.
Page 18 of 58
Set additional attributes:
l_ctrl->set_attribute( name = name value = value ).
Call the request:
call_controller( l_ctrl ).
Calling (Sub) Controllers
Instantiate your sub-controller.
Create your sub-controller in method
DO_INIT:
subcontroller = create_controller (controller_name = ‚name.do‘
controller_id = 'id' ).
Example:
flightdetails ?= create_controller( controller_name = 'flightdetails.do'
controller_id = 'fld' ).
Ensure that the controller_id is specified.
Call your sub-controller.
1. You can execute the call from the controller.
This makes sense in particular if the calling controller does not control a layout. There are two call options here:
data: l_ctrl type ref to cl_bsp_controller.
l_ctrl = create_controller( key = navigation_key ).
or
l_ctrl = create_controller( application_namespace = 'fred'
application_name = 'hugo' controller_name = 'do_something.do'
).
application_namespace and application_name are optional. Unless you specify otherwise, the system uses the current values.
1. You can execute the call from the view. There are three call options here, which are all implemented using the
<bsp:call> BSP element. The comp_id used here corresponds to the controller_id from create_controller.
<bsp:call comp_id = "…"/>
Note that the instantiation using the controller_id must have already taken place.
<bsp:call url = "…" comp_id = "…"/>
A controller instance is generated if no controller is created under the comp_id.
<bsp:call key = "…" comp_id = "…"/>
A controller instance is generated if no controller is created under the comp_id. The key is taken from the navigation table.
1. Determine the parameter transfer.
1. You can execute the parameter transfer from the controller.
sub_controller -> set_attribute (name value)
To do this, use any public method of the sub-controller if you know its class. Of course, you can also set the sub-controller’s public attributes directly.
1. You can execute the parameter transfer from the view.
<bsp:call>
<bsp:parameter name = "…" value = "…" />
</bsp:call>


1.3.2.5 Calling a View
Prerequisites
You are in a system from SAP Web AS 6.20.
You have created at least one
view for your BSP application.
Procedure
Create the view instance.
data: l_view type ref to if_bsp_page.
l_view = create_view( key = navigation_key ).
PUBLIC
© 2014 SAP AG or an SAP affiliate company. All rights reserved.
Page 19 of 58
or
l_view = create_view( view_name = 'next.htm' ).
Note that you can call views only from your own application.
Set the attributes of the view:
l_view->set_attribute( name = 'model' value = my_model_instance ).
or
l_view->set_attribute( name = 'hugo' value = 'Hugo-Text' ).
Call the view layout:
call_view( l_view ).


1.3.2.6 Creating Error Pages
Use
In case that on a page that contains flow logic, a view, or a controller, a runtime error occurs, you can assign an error page to it. When a runtime error occurs
during execution of this (other) page or this controller, the system automatically processes the assigned error page and sends it to the browser. If no error page is
assigned to a page/a controller, in case of a runtime error, the system displays a standard page. If runtime errors occur in a called controller or view and there is
no error page, this section remains empty.
If different types of exception occur, you can use the ERROR_OBJECT error object from class CX_ROOT in your error page. You can implement this object
using dynamic ABAP and use GET_TEXT or GET_LONGTEXT methods to output an appropriate error text for your application (message short or long text).
Use the functionality in the HTTP service tree (Transaction SICF) to create error pages if short dumps occur. See also Error Pages.
Prerequisites
· You created the page (the controller) you want to use as error page. See also: Creating Pages or Creating Controllers.
· You cannot assign an error page to a page or a controller that itself is marked as error page.
· With views you must not assign a controller class, because an error page is always called implicitly by the BSP runtime.
Procedure
To identify a page / a controller as an error page:
1. Go to the properties display and switch to Change mode if necessary.
2. In section Error Handling , mark the checkbox Is Error Page .
3. Save your entries and activate the page or controller.
Result
You can now assign this page or controller as Assigned Error Page to another page or another controller.
Example
The BSP application BSP_MODEL in the system contains an example of how to implement and use an error page.


1.3.3 From Pages to Controllers
With a "normal" page, the presentation is determined by the layout, whilst in the MVC design pattern, views specify the presentation. With normal BSPs,
predefined event handlers are available to process events. With MVC on the other hand, events are handled by controllers.
Normal pages are different from controllers especially with regard to event handling and programming. The events of the pages can be matched with the controller
methods:
Page events and main controller methods
Page events and sub-controller methods
Page events and main controller methods
PUBLIC
© 2014 SAP AG or an SAP affiliate company. All rights reserved.
Page 20 of 58
A main controller handles both input and output processing, where it uses the central method
DO_REQUEST to call the methods specializing in input processing: DO_HANDLE_DATA, DO_HANDLE_EVENT and DO_FINISH_INPUT. In method
DO_REQUEST, input processing must be triggered using DISPATCH_INPUT. This corresponds to the processing steps in the purely page-based BSP
programming model that are executed using events OnRequest, OnInputProcessing, OnManipulation and Layout.
Page events and sub-controller methods
From method
DO_REQUEST, the three following methods required for input processing are called:
DO_HANDLE_DATA
DO_HANDLE_EVENT
DO_FINISH_INPUT


1.3.4 Call Options of BSP Components
In general, views can only be called from controllers. The only exceptions are error pages.
Controllers can be called from controllers, or from the layout methods of pages and views.
The calls can be considered as "forwarding a request" or as "adding a page fragment".
Calls that are made from a controller are identical. Only the environment is different, particularly depending on whether or not data was already written in the HTTP
response, and whether additional data is subsequently added in the HTTP response.

The calls are different from views or pages. You can use the following elements of BSP extension
bsp to branch from a view or a page to a controller:
<bsp:goto>
Forward
<bsp:call>
Insert
These two elements are based on the same technology as when a controller is called by a controller. As inner elements, both can only have elements of type
<bsp:parameter>. You hereby determine the parameters that are passed to the controller.


PUBLIC
© 2014 SAP AG or an SAP affiliate company. All rights reserved.
Page 21 of 58
1.3.5 Navigation
There are two options for navigating to a different URL:
navigation->goto_page
for a page or a controller
<bsp:goto>
element for a controller.
navigation->goto_page
With goto_page, there is a redirect to the specified page (or to the controller), that is, the browser is informed that it may request a different page. There is then a
new browser request to the destination page.
This has the following effect:
The browser recognizes the URL for the destination page, since it requested it itself. In the page does not run in a frame, its URL is displayed in the address
line of the browser.
An additional browser request is required, which leads to increased network load. Even if the amount of data is extremely small, this may slow down
performance with very slow networks (such as via satellite).
In a stateless case, all temporary data from previous processing is lost.
<bsp:goto> Element
With the <
bsp:goto> element, the new controller or view is called to provide the content for the current request.
This means that:
The browser does not recognize the URL for the destination page, but tries to communicate with the existing page.
No additional browser request is required.
If no
target has been entered in the form of the target page, the request that results from sending the form (or also from a refresh) is sent to the requesting page. As
a result, the target page only has the task of creating the HTML (view) and does not usually have to worry about input. The calling page is responsible for this and
thereby takes over the controller functionality.
The work process does not change, that is, the context remains the same even in a stateless application and you can therefore access the data and objects
that have already been created.
The controller must be able to use the input to decide on its current "status" if it should display several views after each other. It should not store this status
on the server, otherwise the "Back" processing would not function correctly. With different URLs, this is easier using redirects.
When you use different views, the URL does not change. As a result, you cannot use bookmarks on these pages.
What does page_name point to?
runtime->page_name
always points to the externally addressed page or the controller. You get the name and URL using page->get_page_name() or page->get_page_url().
Lifetime of the View that is Called
The lifetime of the view that is called is limited to the call only. For more information, see
Lifetime and Note 545847.


1.3.6 Lifetime
Controllers
You determine the lifetime of components or their controllers in the usual way using the Properties tab page of the controller. You can specify the lifetime as one
of the following three options in Status :
To page change
For the duration of the request
For the duration of the session
The setting is usually To page change .
By default, the lifetime of controller instances is limited to the one call. If the controller instance is passed with
id, then its lifetime is the same as that specified in the controller’s properties ( Properties tab). The id can be specified as follows:
From a page or a view:
<bsp:call/goto comp_id = "id">
From a controller or a page event:
create_controller(…controller_id=‘id‘)
The
controller_id or the comp_id of the <bsp:call> element must not contain an underscore (‘_ ‘).
The underscore is reserved as a separator between controllers.
The lifetime of the top-level controller ranges from the first
CREATE_CONTROLLER for a sub-controller to DELETE_CONTROLLER for the sub-controller.
If sub-controllers should occasionally be hidden, so that they are not involved in event handling for a while, then use method
CONTROLLER_SET_ACTIVE. A controller that is set to inactive in this way will not be called for input processing.
PUBLIC
© 2014 SAP AG or an SAP affiliate company. All rights reserved.
Page 22 of 58
The controller is only hidden; the controller instance is not deleted.
Views
This section concerning the lifetime of views concerns the use of MVC in SAP Web AS 6.20 up to and including Support Package 9.
Unlike controllers or pages, views have only a very short lifetime. Their life cycle looks as follows:
1. They are created.
2. They are supplied with parameters.
3. They are called.
4. They are now no longer required and therefore expire, since views cannot be reused.
Views therefore only exist for the duration of the call, that is, they are destroyed after they have been called.
As a developer of BSP applications with MVC, you must explicitly recreate the view, since you cannot reuse it in a controller. The following provides an example
of correct and incorrect coding:
Use: Do not
use:
DATA: view TYPE REF TO if_bsp_page.
view = create_view( view_name = 'main.htm' ).
DATA: view TYPE REF TO if_bsp_page.
IF view IS NOT BOUND. " or IS NOT INITIAL.
view = create_view( view_name = 'main.htm' ).
ENDIF.
In any case, the view must be explicitly recreated before it is used.
DATA: view TYPE REF TO if_bsp_page.
view = create_view( view_name = 'main.htm' ).
" ... set attributes ....
call_view( page ).
CLEAR view.


Data Binding

To make programming easier for you with the MVC design, the framework for the model of an application provides you with basic class CL_BSP_MODEL, which
you can use in your own model class as a class that passes on its properties. The model class represents the data context of your application and, as a result,
receives a copy of the data (or references to the data) that are relevant for the view from the database model.
The model class provides:
· The data that are used for the views, with the corresponding type and data Dictionary information.
· Input conversions
· Information about input errors that occurred for which data
A controller can instantiate a model class or even several model classes (see also Calling the Model Class Using the Controller). The controller has a list of all
model instances, analogous to the list of sub-controllers.
The controller assigns unique IDs to each model instance.
If you are using the MVC Design Pattern, you do not need to use the Application Class. Instead of the usual application class with purely page-
based BSP applications, you should use controllers and model classes in the MVC environment.
Data binding is particularly important with HTMLBextension elements inputField and label (see also the documentation for these elements in the system). It is
also implemented for HTMLB elements dropdownListBox, radioButtonGroup, checkbox, textEdit and tableView.
A model class can either be designed quite simply or it can be used with more complex application cases.
Simple Model Class
Data binding is important for transmitting values for output data. Add the data that is required by the view to your model class as attributes. These attributes are all
from the visibility range public and can be as follows:
· Simple variables
· Structures
· Tables
In the most simple case, the model class has these attributes only and so can easily be used for data binding as part of a BSP application.
This type of simple model class provides the following functionality:
· The controller can create a model instance and initialize the attributes, since they are public attributes.
· The controller transmits a reference to the model instance to the view.
· The data binding to the model is specified in the view for each view element using a path expression (//...).
PUBLIC
© 2014 SAP AG or an SAP affiliate company. All rights reserved.
Page 23 of 58
Example:
A BSP application contains an input field that is implemented using HTMLB, in which users can write data.
model is defined as a page attribute. For the input field you can then write:
<htmlb inputField … value=”//model/<Attribut>”
This ensures that the content of value is bound to the corresponding attribute of the model class.
The process flow is now as follows:
i. The content of the attribute is assigned to the input field value using the above statement.
ii. This generates the ID from the model.
iii. Additional attributes are also generated, for example, one that determines whether fixed values exist.
iv. User input is transferred to the model class at the next request.
v. Data conversions including connection to the Dictionary (conversion exists, for example) are automatically executed by the base model class.
In the default case, if a conversion exit for a field exists in the ABAP Dictionary, this conversion exit is called. All data contained in the ABAP
Dictionary structure for the field are available. If, however, separate setter/getter methods (see the following section) are written, the conversion exit
can be switched off.
If necessary you can also add your own methods to your model class for further processing attributes.
Complex Model Class
It is possible that simple model classes are not sufficient for your requirements. This may be the case, for example, if you are working with generic data or if you
need special methods for setting (SET) and getting (GET) attributes. You can therefore use these methods to determine your own implementations that are
important for your specific application.
In these types of applications, the base class contains copy templates for the setter and getter methods: _SET_<attribute>and _GET_<attribute> . All of these
templates begin with _. The naming conventions for the actual methods are as follows:
Naming convention for setter methods:
SET_<attribute> for a field
SET_S_<attribute> for a structure
SET_T_<attribute> for a table

Naming convention for getter methods:
GET_<attribute> for a field
GET_S_<attribute> for a structure
GET_T_<attribute> for a table
An example of implementing a getter method for structure fields/structure attributes:
method GET_S_FLIGHT .
field-symbols: <l_comp> type any.
assign component of structure flight to <l_comp>.
value = <l_comp>.
if component eq 'CARRID'.
translate value to lower case.
endif.
if component eq 'CONNID'.
shift value left deleting leading '0'.
endif.
endmethod.
The ABAP keyword assign component assigns the structure component component for the structured field flight (with reference type sflight)
to the field symbol <l_comp>. The value of <l_comp> is output as follows: If the structure component component points to an airline (CARRID),
the name of the airline is translated in lowercase. If the structure component component points to a single flight connection (CONNID), then some
of the introductory zeros may be deleted.
As soon as a setter or a getter method is set, it is used automatically.
Data binding is automatically available because the name is the same. In method DO_HANDLE_DATA (see also Process Flow) of class
CL_BSP_CONTROLLER2 all controllers automatically fill the form fields with data.
The path specifications for the model data have the following syntax:
· Simple field attribute
value=”//<field name>”
· Structure attribute
value=”//<structure name>.<field name>”
· Table attribute
value=”//<table name>[<line index].<field name>”



1.3.7.1 Calling the Model Class by the Controller
Uses
A model class is called or managed by a controller, that is, a controller can hold one or several model classes (or instances). The controller class provides
PUBLIC
© 2014 SAP AG or an SAP affiliate company. All rights reserved.
Page 24 of 58
methods for creating, getting, setting and deleting this type of model class. There are also methods for passing incoming data on to the correct model instance,
which is identified by the
model_id.


1.3.8 Components
Use
Complex BSP applications that are based on the MVC Design Pattern have many extensive components. Each individual part, consisting of a complex BSP
application, contains precise application logic and well thought out presentation logic. It makes sense to create the individual BSP components as reusable
modules. These reusable modules are:
· Controllers
· One or more views
· A Model
Together they form a component.
Components are only available for stateful BSP applications.
Integration
The use of components is integrated in the MVC design pattern.
Prerequisites
You are in SAP Web AS 6.20.
Functions
A component consists of a controller, whose class is derived from CL_BSP_CONTROLLER2, as well as one or more views, which can result in regular nesting.
This is outlines in the following graphic:

Central features of components are:
· With components, there are complex call sequences during an HTTP request.
· The individual parts, of which a page in the browser consists, are dynamically assembled during runtime.
· One component can call a different component. It should therefore be placed in a view. This is done using the <bsp:call> element.
· Initialization can be called by the controller using method create_controller. This method is available for all controller classes. It creates a controller or finds an
existing one.
· The parent controller contains a list of the individual sub-controllers and forwards all input to the relevant controller. This is done by prefixing all IDs with the
path of the controller IDs.
· The controller has a hierarchical tree. Every controller controls its view or views, its model as well as the list of sub-controllers.
· Basis class CL_BSP_CONTROLLER2 controls the sub-controllers. The controller developer is responsible for controlling the view and the model.
If you want to use data binding functionality, you can add a model class to your component. For more information see Data Binding.
PUBLIC
© 2014 SAP AG or an SAP affiliate company. All rights reserved.
Page 25 of 58
Activities
1. Creating the top-level controller
2. Creating a Component
3. Calling the Component
4. Determing the Input Processing




1.3.8.1 Process Flow
Uses
The methods of class Class CL_BSP_CONTROLLER2 are used to create Components as part of the Model View Controller design pattern.
The whole hierarchy level is processed with every request.
The hierarchy itself is defined at output.
Process
1. First call DO_INIT.
1. Then call DO_INITATTRIBUTES.
2. Then call DO_REQUEST.
With a main controller, DO_REQUEST takes care of both input and output processing.
a. Input processing
The browser request is sent directly to the top-level controller. This dispatches the input to the sub-controllers. Service function DISPATCH_INPUT is
available for this.
DISPATCH_INPUT reads the form fields from the request and dispatches them to the sub-controller. Prefixes are added to the form fields.
The prefixes are written automatically for BSP elements, for example, by BSP extension HTMLB.
If, however, you have pure HTML or HTML tags, then you must add the name of the controller as a prefix to your input data. In this case, service function
GET_ID is available for adding prefixes.
All data that do not belong to one of the sub-components must be processed using method DISPATCH_INPUT in the main controller. The following
methods are called:
- DO_HANDLE_DATA
- DO_HANDLE_EVENT
- DO_FINISH_INPUT
These three methods are called by the parent controller only with the form fields for the current controller.
b. Output processing
Determining output processes contains the output for the next page. A view is created and displayed. Depending on the status of the top-level controller,
you can also set a sub-controller to inactive or create new controllers.
The process flow of the output is displayed in the following graphic:
Page Output
At output, DO_REQUEST carries out the following tasks:
i. DO_REQUEST determines whether data must be fetched from the model or from the global attributes.
ii. DO_REQUEST fetches the table with the object keys from the top-level controller.
iii. DO_REQUEST requests a view.
iv. DO_REQUEST sets the correct attributes for the view.
v. DO_REQUEST calls the view.
PUBLIC
© 2014 SAP AG or an SAP affiliate company. All rights reserved.
Page 26 of 58
Handling events
If a component contains events, DISPATCH_INPUT calls the HTMLB manager. The HTMBL manager collects the relevant information, including the ID, that is,
the ID of the object that triggered the event.
DISPATCH_INPUT then calls method DO_HANDLE_DATA. DO_HANDLE_DATA is called by all controllers (that is, for all active components), that is, by the
top-level controller as well as by all sub-controllers. The model class is filled with DO_HANDLE_DATA (see also Data Binding): The system transfers form fields
and messages for the global messages object (see below).
If your model class is based on CL_BSP_MODEL and you have defined your setter and getter methods accordingly, the form fields are filled
automatically.
The process flow with DO_HANDLE_DATA is displayed in the following graphic:
Page Input (DO_HANDLE_DATA)
Once DO_HANDLE_DATA has filled all data, method DO_HANDLE_EVENT is called for the controller that is responsible for the input event. This also states the
event ID and the event is dispatched to the controller. DO_HANDLE_EVENT also outputs parameter GLOBAL_EVENT (a string). If the event is an HTMLB
event, object HTMLB_EVENT is filled accordingly.
Events are only dispatched to the relevant controller if the element ID was assigned to the HTMLB element (attribute id).
DO_HANDLE_EVENT also has access to the global messages object and can carry out additional steps if necessary. For example in the case of an error, this
method can have data displayed again.
The process flow with DO_HANDLE_DATA is displayed in the following graphic:
Page Input (DO_HANDLE_EVENT)
Note that only a sub-controller is called here.
Method DO_FINISH_INPUT is always called (for every controller, that is, for all active components). You can use it to react to events in a component that occur in
a different component. To do this, use parameter GLOBAL_EVENT, which is set in method DO_HANDLE_EVENT. Using this global event, at the end of input
processing each component should know exactly which events are present and how to react to them.
The process flow with DO_FINISH_INPUT is displayed in the following graphic:
Page Input (DO_FINISH_INPUT)
PUBLIC
© 2014 SAP AG or an SAP affiliate company. All rights reserved.
Page 27 of 58
Global Messages
Parameter GLOBAL_MESSAGES is shared by all components. Use this parameter to handle incorrect user input, for example to display that an error occurred,
or that the end date entered by the user is before the start date, and so on.
The main controller creates the global messages and forwards them to all sub-controllers. On the other hand, the messages object is local. If the local messages
object is now filled in a controller, then you can forward this information to the global messages object and react to it using any component you like.
Controllers and Their IDs
Usually there is a main controller, a top-level view as well as different sub-controllers and additional views.
A main controller first calls CREATE_VIEW, then SET_ATTRIBUTE for the view, and then CALL_VIEW. The top level controller can also create sub-controllers.
This is done using the <bsp:call> element, which has the attributes PAGE and COMP_ID. Furthermore, the embedded element <bsp:parameter> can also
specify parameters for name and value.
The attribute output takes place either in the view or in the top-level controller.
COMPONENT_ID always identifies the controller. The COMPONENT_ID has a reference to the controllers concerned.
In method CREATE_CONTROLLER this reference is parameter COMPONENT_ID, and in the <bsp:call> element it is attribute COMP_ID:
When a controller is created, a reference is sent to the parent controller, which has a list of all the sub-controllers that belong to it. Every sub-
controller can query its parent controller for the COMP_ID of each additional sub-controller.




1.3.8.2 Creating Your Own Components
Uses
You create components to use them independently as well as together with other components for BSP applications. You can create a component for a search in
an online shop, for example, and create an additional one for the detail display of the article that was found.
When you develop components, you can also form teams, so that one team is responsible for developing controllers, a different team is responsible for the views,
PUBLIC
© 2014 SAP AG or an SAP affiliate company. All rights reserved.
Page 28 of 58
and a third team is responsible for developing the models.
Process
Create the top-level controller
Create a component
Call the component
Determine the input processing


1.3.8.2.1 Creating the Top-Level Controller
Procedure
Create a BSP application and declare it as stateful.
You can find the checkbox for stateful on the Properties tab page as the ID Stateful .
2. Save your BSP application.
3. Create a controller within this BSP application.
1. Enter a unique class name for the controller.
2. Set the lifetime in the Status field to Session .
4. Save your controller.
5. Double-click on the controller class name.
6. The following dialog box asks if you want to create the class. Answer it with Yes .
You branch to the Class Builder.
7. Save your class.
8. On the Properties tab page, check that your class inherits properties from
CL_BSP_CONTROLLER2. If this is not the case, for example if your class inherits properties from CL_BSP_CONTROLLER, then change the data for the class
that passes on the properties.
Branch to the Methods tab page.
1. In change mode, overwrite method
DO_REQUEST using the icon (Redefine):
method DO_REQUEST .
data: main_view type ref to if_bsp_page.
* if input is available, dispatch this input to subcomponent.
* this call is only necessary for top-level controllers.
* ( if this is not a top-level controller or no input is present,
* this call returns without any action)
dispatch_input( ).
* if any of the controllers has requested a navigation,
* do not try to display, but leave current processing
if is_navigation_requested( ) is not initial.
return.
endif.
* output current view
main_view = create_view( view_name = 'main.htm' ).
call_view( main_view ).
endmethod.
If necessary, overwrite method
DO_INIT.
In order to react to user input, overwrite methods
DO_HANDLE_DATA and DO_HANDLE_EVENT.
10. Activate your class.
11. Create a view within your BSP application.
1. In the following example, the view is called
main.htm.
Fill the view layout with HTML coding or HTMLB coding.
Save the view.
12. Activate and test your finished BSP application.

Continue by
Creating Components.


PUBLIC
© 2014 SAP AG or an SAP affiliate company. All rights reserved.
Page 29 of 58
1.3.8.2.2 Creating Components
Procedure
Create a controller (including classes) in a BSP application.
This controller may belong to an already existing BSP application or it can be located in its own BSP application.
Note that the basic class of this controller and the top-level controller is class
CL_BSP_CONTROLLER2 (see also Creating Top-Level Controllers and Views).
If this controller should always be used as the component controller, then change method
DO_REQUEST so that only views can be displayed. If not, DO_REQUEST would look exactly the same as the DO_REQUEST from the top-level controller.
1. Overwrite methods
DO_HANDLE_DATA, DO_HANDLE_EVENT and/or DO_FINISH_INPUT.
These methods are called by the parent controller only with the form fields for the current controller. All components share parameter GLOBAL_MESSAGES.
GLOBAL_MESSAGES is used to handle incorrect input.
Parameter GLOBAL_EVENT is set by method DO_HANDLE_EVENT and is used in DO_FINISH_INPUT. The component developers should device how these
values should be set.
Methods DO_HANDLE_DATA and DO_FINISH_INPUT are called for all active components. DO_HANDLE_EVENT is only called by the controller that is
responsible for the input event.
For every attribute that should be passed to this controller, create a public attribute or a method.
1. Create one or several views.
2. Activate the views.

Continue by
Calling the Components.
1.3.8.2.3 Calling Components
Use
You can call a main controller, sub-controller in two ways:
1. By creating the sub-controller in a method of the main controller
2. By creating the sub-controller from a view
Option A is more flexible than Option B, especially if the sub-controller should be initialized once only in method
DO_INIT.
Procedure
Option A
In method
DO_INIT or DO_REQUEST, for example, add the following coding:
...
data: addresscontroller type ref to CL_C_MYPROJ_ADDRESS.
* create the controller
addresscontroller ?= create_controller(
controller_name = 'address.do'
component_id = 'ad'
).
* set some attributes with a self defined method
addresscontroller->Init_data( ... ).
...

or
...
data: subcontroller type ref to CL_BSP_CONTROLLER2.
* create the controller
subcontroller ?= create_controller(
controller_name = 'address.do'
controller_id = 'ad'
).
* set some attributes with standard method
subcontroller->set_attributes( name = 'address'
value = ship_address ).
PUBLIC
© 2014 SAP AG or an SAP affiliate company. All rights reserved.
Page 30 of 58
...

Call the controller in the view.
Two components are called in the above example: the address component (
address.do) and the flight component (flights.do).
COMPONENT_ID
identifies the controller. In method CREATE_CONTROLLER this is the parameter COMPONENT_ID, and in <bsp:call>-element this is the attribute COMP_ID:
<%@page language="abap"%>
<%@extension name="htmlb" prefix="htmlb"%>
<%@extension name="bsp" prefix="bsp"%>
<htmlb:content id="ComponentTest" >
<htmlb:page title = "Component Test">
<H1>Component Test</H1>
<htmlb:form id="myFormId" method="post">
<htmlb:tray id = "tray1"
title = "Address"
design = "form"
width = "350"
isCollapsed = "false" >
<bsp:call url="address.do" comp_id="ad">
</bsp:call>
</htmlb:tray>
<htmlb:tray id = "tray2"
title = "Flights"
design = "form"
width = "350"
isCollapsed = "false" >
<bsp:call url="flights.do" comp_id="fl">
</bsp:call>
</htmlb:tray>
<p>
<htmlb:button id="SAVE" text="SAVE DATA" onClick="SAVE" />
<htmlb:button id="CANCEL" text="CANCEL" onClick="CANCEL" />
</htmlb:form>
</htmlb:page>
</htmlb:content>

Option B
In this option, you do not need to create the sub-controller in the coding of the main controller. Instead you should only add the parameters to the view call, which
then creates and calls the controller. In the following example,
ship_address is an attribute of the view and is set by the controller:
<%@page language="abap"%>
<%@extension name="htmlb" prefix="htmlb"%>
<%@extension name="bsp" prefix="bsp"%>
<htmlb:content id="ComponentTest" >
<htmlb:page title = "Component Test">
<H1>Component Test</H1>
<htmlb:form id="myFormId" method="post">
<htmlb:tray id = "tray1"
title = "Address"
design = "form"
width = "350"
isCollapsed = "false" >
<bsp:call url="address.do" comp_id="ad">
<bsp:parameter name="address" value="<%=ship_address%>"/>
</bsp:call>
</htmlb:tray>
<htmlb:tray id = "tray2"
title = "Flights"
design = "form"
width = "350"
isCollapsed = "false" >
<bsp:call url="flights.do" comp_id="fl">
</bsp:call>
</htmlb:tray>
<p>
<htmlb:button id="SAVE" text="SAVE DATA" onClick="SAVE" />
<htmlb:button id="CANCEL" text="CANCEL" onClick="CANCEL" />
</htmlb:form>
</htmlb:page>
</htmlb:content>

PUBLIC
© 2014 SAP AG or an SAP affiliate company. All rights reserved.
Page 31 of 58
Continue by
Determining Input Processing.
1.3.8.2.4 Determining Input Processing
Use
The browser sends its request to the top-level controller. This main controller dispatches the input to the appropriate sub-controller. This is why it is necessary to
call method
DISPATCH_INPUT in the top-level controller.
Procedure
Input processing consists of three steps:
1. Filling data
For every controller, method
DO_HANDLE_DATA is called with a list of form fields that should be handled by this method.
If an error occurs during the data conversion, then this method can also pass one or more messages to the global error object (global_messages).
Handle event
Method
DO_HANDLE_EVENT is called for exactly one controller. The event is passed on and object htmlb_event is filled if it is an HTMLB-event. Method
DO_HANDLE_EVENT has access to object global_messages, in order to determine the additional steps that are necessary, depending on the error. For
example, in the case of an error, you can specify that you want to display the data again. You can also set a global_event using method DO_HANDLE_EVENT.
Finish input processing
For every controller, method
DO_FINISH_INPUT is called with a global event, which is set by the event handler method. The closing input processing is carried out here.


1.3.9 Class CL_BSP_CONTROLLER2
Overview
Class CL_BSP_CONTROLLER2 is used to create controllers and Components. Every controller class automatically inherits all methods and attributes from this
central basic class.
If the basic class of your controller class displays CL_BSP_CONTROLLER instead of CL_BSP_CONTROLLER2, change the inheritance
hierarchy accordingly.
Class CL_BSP_CONTROLLER2 enables you to:
· Retain a list of sub-controllers
· Create unique IDs for the sub-controllers, where the sub-controller is assigned the controller ID prefix
· Use models
· Forward data to the correct controller as well as fill model classes (if they exist)
Methods
Below you can find an overview of all methods in a controller class. Process Flow provides details on the most important methods.
The individual methods can be separated into different categories:
Functions where overwriting is required
DO_REQUEST is the central method in a controller class.
You must overwrite this method.
In DO_REQUEST you specify the request processing, that is, this method is called for every request. This method does the “main work”; in particular it should
branch to the correct view.
DO_REQUEST can be used in two different areas:
· If it is the top-level controller of a component, then this method handles both input and output processing.
· If it is a sub-controller of a component, then this method only handles output processing.
Functions where overwriting is recommended
You should overwrite these methods in order to determine input processing.
Method Description
PUBLIC
© 2014 SAP AG or an SAP affiliate company. All rights reserved.
Page 32 of 58
DO_HANDLE_DATA Reacts to user input.
Processes data input for this component.
DO_HANDLE_EVENT Reacts to user input.
Processes events if the component contains them.
Exactly one view controller is called to handle the event, which contains an event such
as a save button, for example.
DO_FINISH_INPUT Ends the input processing.

Functions where overwriting is possible
You can overwrite these methods in order to determine input processing.
Method Description
DO_INIT This method is called once at the start and is used for initialization.
This method behaves like a constructor method.
DO_INITATTRIBUTES This method is called with every request and is used to initialize the attributes. The
parameters are read from the request. In this method, you can also execute initializations
that are required for each request.
You can also use this method to set additional attributes. This method is not absolutely
necessary, since you can use DO_REQUEST to solve everything that you can
(theoretically) handle here.
Service functions
You can call these methods:
Method Description
CREATE_VIEW Creates or fetches a view instance
Use either the name of the view, or the object navigation.
A view must always belong to the same BSP application as its controller.
CALL_VIEW Calls the request handler of the view instance.
CREATE_CONTROLLER Creates or fetches a controller instance
CALL_CONTROLLER Calls the request handler (method DO-REQUEST) of the controller instance.
GET_ATTRIBUTE Returns the specified page attributes.
Generic method for reading an attribute value.
GET_LIFETIME Returns the lifetime of this page (only for the top-level controller)
GET_PAGE_URL Returns the URL of the page or the current controller
SET_ATTRIBUTE Sets the specified page attributes.
Generic method for setting an attribute value.
SET_LIFETIME Changes the lifetime of this page (only for the top-level controller)
TO_STRING Creates a formatted string
WRITE Writes a formatted string in the output
GET_OUT Fetches the current output writer
SET_MIME_TYPE Changes the MIME type of the page or the content type of the header field
INSTANTIATE_PARAMETER Instantiates the parameter from the request using the request data
SET_CACHING Changes the caching values
There are two types of caching:
· Browser cache
· Server cache
See also Caching BSPs.
You can only use limited caching here.
Note that the server cache is not user-specific.
If you change the page, you should reset the cache that may be set.
DISPATCH_INPUT Dispatches the input processing (only for the top-level controller).
For each input, DISPATCH_INPUT calls the correct methods in the correct sequence.
This method fetches data from the request.
This method does not have any attributes.
GET_ID Calculates the ID from the specified ID and the component ID
SET_MODEL Creates and registers a model instance
CREATE_MODEL Creates and registers a model instance
GET_CONTROLLER Fetches a sub-controller
CONTROLLER_SET_ACTIVE Sets a controller to active/inactive.
PUBLIC
© 2014 SAP AG or an SAP affiliate company. All rights reserved.
Page 33 of 58
This is relevant with input processing, since you can use it to hide a controller.
See also Lifetime
DELETE_MODEL Deletes a model instance
FILL_MODEL_DATA Fills the model data
DELETE_CONTROLLER Deletes a sub-controller
GET_MODEL Fetches a model instance
IS_TOPLEVEL Is this controller a top (main) controller (0: no, 1: yes)?
IS_NAVIGATION_REQUESTED Has a controller requested a navigation (0: no, 1: yes)?

Framework functions
These methods are provided as part of the framework and are only included here for the sake of completeness. They are not usually relevant for application
development.
Method Description
IF_BSP_DISPATCHER~REGISTER Registers a sub-components
IF_BSP_CONTROLLER~FINISH_INPUT_PROCESSING Processes or dispatches: end of input processing.
IF_BSP_CONTROLLER~FILL_VALUES Processes or dispatches: handling values
IF_BSP_CONTROLLER~HANDLE_EVENT Processes or dispatches: Handle event
GET_FIELD_COMPONENT Finds components for a field name
GET_FIELD_MODEL Finds model for a field name

Methods DO_DESTROY and SUBSCRIBE are not relevant.





1.3.10 Examples of Architecture
Previous BSP Application
With SAP Web AS 6.10, normal BSP applications usually consisted of an application class and several BSPs. Navigation between the pages was controlled
using redirects.
This is how it looks with SAP Web AS 6.20:
BSP Application with Controllers and Views


1.3.10.1 BSP Application with Controllers and Views
PUBLIC
© 2014 SAP AG or an SAP affiliate company. All rights reserved.
Page 34 of 58
From SAP Web AS 6.20, you can combine controllers and views in a BSP application. You navigate between the controllers and any pages that exist using
redirect. Each controller can have one (or several) model(s).
You can use redirect to navigate between the controllers. You call the views using a call.
With several views for a controller, the whole thing looks as follows:
BSP Application with Several Views per Controller
BSP Application with Several Views per Controller
With a BSP application with controllers and viewssapurl_link_0003_0001_0003, an individual controller can also call several views – either sequentially after
each other or alternately. With this example, you always access it using a controller.
What does a combination of these two examples look like (this one here and BSP application with controllers and views)? Like this.


1.3.10.3 Combination of the Previous Examples
You can combine the examples of a
BSP application with several views per controller with a BSP application with controllers and views so that each view is controlled by exactly one controller.
Central distribution is carried out by a superior controller.
PUBLIC
© 2014 SAP AG or an SAP affiliate company. All rights reserved.
Page 35 of 58
Does this also work with several BSP applications?
Of course!
1.3.10.4 Calling Controllers of Other Applications
You can also call controllers of other BSP applications:


1.3.10.5 Calling Several Controllers from a View
With this example, several controllers are called from a view using a BSP element.
There can also be a page in place of the calling controller and view (in the graphic on the left-hand side). There cannot be a page, however,
at the level of the called areas (in the graphic on the right-hand side).
With help from the views that are allocated, these controllers provide the contents for a sub-area of the main views. A reference to the model can also be specified
with the call.
PUBLIC
© 2014 SAP AG or an SAP affiliate company. All rights reserved.
Page 36 of 58


1.3.11 Model View Controller Tutorial
Purpose
In this tutorial, you can use a simple example to run through the first steps with the Model View Controller design pattern for BSP.
Prerequisites
● You are in an SAP Web AS 6.20 system
● You know how to use MVC for BSPs.
Features
Create Controller
Create View
Call Controller



1.3.11.1 Creating a Controller
Prerequisites
You have created an empty BSP application for this tutorial.
Procedure
Create a controller within your BSP application.
To do this, choose Create → Controller.
PUBLIC
© 2014 SAP AG or an SAP affiliate company. All rights reserved.
Page 37 of 58
On the following dialog box, give the controller a name and add a short description.
Choose .
On the following screen, assign a class name to the controller.
The class does not have to exist yet.
You navigate to the Class Builder by double-clicking on the controller class.
If the class does not already exist, the system asks you if you want to create it. Choose Yes so that you create a class with the specified name that is derived
from
CL_BSP_CONTROLLER2.
Each controller class must be derived directly or indirectly from
CL_BSP_CONTROLLER2.
Choose the symbol to branch to the change mode in your class.
Select method
DO_REQUEST and choose symbol to overwrite the methods.

Generate the required output.
In this example, it is simple HTML:
method DO_REQUEST .
write( '<html><body><H1>' ).
write( 'This is my very first controller' ).
write( '</H1></body></html>' ).
endmethod.
Activate your class and your BSP application.
Before you can test the controller, in Transaction
SICF you must also activate the new entry that was automatically created for your BSP application (see also Activating and Deactivating an ICF Service).
In Transaction
SICF, select the entry for your BSP application and choose Service/Virt.Host → Activate.
PUBLIC
© 2014 SAP AG or an SAP affiliate company. All rights reserved.
Page 38 of 58
Confirm the following confirmation prompts.
You can now test the new controller page that you have created.
Result
Continue by
creating a view.


1.3.11.2 Creating a View
Use
If you do not always want to use the write function to create the HTML page content (as described in Creating a Controller), and you want to create it as pure
HTMLO layout instead, then create a view that you can call from the controller.
Procedure
1. Begin as if you are creating a normal page with flow logic in your BSP application.
To do this, choose Create → Page.
2. In the following dialog box, enter a name and short description of the view and select View as the page type:
PUBLIC
© 2014 SAP AG or an SAP affiliate company. All rights reserved.
Page 39 of 58
3. Choose .
4. Create the attributes for the variable parts of the view.
You cannot define auto-page attributes, since views cannot be called directly from the browser.
Create the following attribute:
5. Define the layout as usual:
<%@ page language="abap" %>
<html>
<head>
<link rel="stylesheet" href="../../sap/public/bc/bsp/styles/sapbsp.css">
<title> Layout for Controller </title>
</head>
<body class="bspBody1">
<H1>View Example</H1>
<H3>Hello, user <%= name%></H3>
</body>
</html>
6. Activate the view.
7. Finally, adjust the DO_REQUEST method to the controller class.
Here, the schema is always the same. First you create the view, then you set the attributes, and then you call the view. (For the time being you can ignore
the warning concerning exception CX_STATIC_CHECK, or you can set a try-catch block around the calls):
method DO_REQUEST .
data: myview type ref to if_bsp_page.
myview = create_view( view_name = ' view_test.htm' ).
myview->set_attribute( name = ' name' value = sy-uname ).
call_view( myview ).
endmethod.
8. Activate your class and test your controller.
Result
You have created your own view for the layout.
Continue by Calling the Controller.



1.3.11.3 Calling a Controller
PUBLIC
© 2014 SAP AG or an SAP affiliate company. All rights reserved.
Page 40 of 58
Use
You can call a controller from a page with flow logic, or from a view.
Procedure
Create a page within your BSP application.
Ensure that you select Page with Flow Logic as the page type.
In the Tag Browser, select BSP extension
bsp and drag it to the second line of your BSP’s layout under the page directive.
Now drag the
<bsp:goto> directive of BSP extension bsp to the body of the HTML layout and add the URL parameter.
The source now looks as follows:
<%@page language="abap"%>
<%@ extension name="bsp" prefix="bsp" %>
<html>
<head>
<link rel="stylesheet" href="../../sap/public/bc/bsp/styles/sapbsp.css">
<title> Initial page </title>
</head>
<body class="bspBody1">
<bsp:goto url="example.do"></bsp:goto>
</body>
</html>
You can now activate and test the page.
The page looks as follows:
Ensure that the page you have tested looks exactly the same as when you tested the controller. The URL is different, however. You can use View Source in the
browser to see that nothing remains of the HTML text from the BSP, but that only the content of the view is displayed:
<html>
<head>
<link rel="stylesheet" href="../../sap/public/bc/bsp/styles/sapbsp.css">
<title> Layout for Controller </title>
</head>
<body class="bspBody1">
</head>
<body class="bspBody1">
<H1>View Example</H1>
<H3>Hello, User GREBEL</H3>
</body>
</html>
You can now try out the difference between the
PUBLIC
© 2014 SAP AG or an SAP affiliate company. All rights reserved.
Page 41 of 58
<bsp:goto> element and the <bsp:call> element.
If you use the
<bsp:call> element instead of the <bsp:goto> element, the calling page text remains the same. In the view that is inserted, you should therefore delete the
HTML text available on the outline page, otherwise these texts will be transferred twice.
You can add another attribute to the controller. This is a public class attribute.
It is set using the
<bsp:parameter> element. You can use it for example to control which view is called, or this value can be passed to the view.


1.4 Defining Your Own BSP Extension
BSP Extensions and BSP Elements
With the BSP extension concept, you can develop your own tags for dynamic pages of BSP applications.
A BSP extension is represented by means of a special development object in the workbench. This object includes a record of related BSP elements with the
corresponding attributes, and it also covers references to the appropriate element handler classes. Each BSP element has an element handler class assigned to
it that implements its specific functions.
The
figure below explains these connections with a relatively simple example.
Advantages for Using BSP Elements
Reduces the complexity of the BSP pages.
The encapsulation of the functions into BSP elements can contribute greatly to reducing the script part in BSP pages.
Reuse
Generally speaking, a BSP element can be used by each BSP page.
Clear-cut role distribution
As a developer, you define the BSP extensions and implement the respective element handler classes; as a designer, on the other hand, you use
the BSP elements in the page layout of BSP applications.
Tool support within the workbench by the BSP extension editor
Tool Support
In addition to the usual infrastructure (transport, where-used list, and so on), the workbench provides the following functions in order to ensure efficient processing of
BSP extensions:
Creating and editing BSP extensions
In the Object Navigator (SE80), you first create a BSP extension as a new development object. Then you create one or several BSP elements and
declare the individual element attributes.
Generating the element handler class
For each BSP element, you can generate a corresponding element handler class and its basis class in the Class Builder.
Integration in the Tag Browser
Through activation, each new BSP extension is copied, without additional effort, as an entry into the Tag Browser in SE80. On the BSP application
pages, you can then place the corresponding tags and their attributes wherever you want them in the editor using Drag&Drop. See also:
Using BSP Extensions.
Process Flow
Complete implementation of a BSP extension takes place in the following steps:
1.
Creating a BSP Extension
Defining the Corresponding BSP Elements
Implementing the Element Handler Class
Activating the BSP Extension
Entering Documentation
PUBLIC
© 2014 SAP AG or an SAP affiliate company. All rights reserved.
Page 42 of 58





1.4.1 BSP Extension Framework
In the following example, a BSP page uses the elements of the BSP extension myExtension . All the BSP elements in this extension are identified, in this case,
by the prefix ext .
The BSP elements are defined within the Workbench using the BSP extension editor. Here, the BSP extension was created as a container for the corresponding
elements. In addition, specific attributes can be assigned to each element.
The specific functions of a BSP element are implemented with the help of a global element handler class myElementClass in the Class Builder.


1.4.2 Creating BSP Extensions
Use
Whenever you wish to define and implement your individual tags for Business Server Pages, you first need a BSP extension as a separate workbench. This
object then serves as a container for several BSP elements, as a rule.
Procedure
To create a new BSP extension:
1. Open the Object Navigator (transaction: SE80).
Alternatively (to steps 1-4), you can create a new BSP extension by selecting the Create function from the context menu of a BSP extension that already
exists within an object list.
2. Choose the BSP Extension category from the object list selection and enter a name for the BSP extension you want to create.
3. Click the button or press ENTER.
The system checks whether a BSP extension with the specified name already exists in the SAP System. If there is none, the Create Object dialog box
appears.
4. Choose Yes to create the BSP extension.
The system displays the Create BSP Extension dialog box.
5. Enter the default prefix without blanks or other special characters and also a meaningful description for the BSP extension as a short text.
The default prefix is a prefix that is entered into the BSP page in the standard version during Drag&Drop of the extension or one of your BSP elements from
PUBLIC
© 2014 SAP AG or an SAP affiliate company. All rights reserved.
Page 43 of 58
the Tag Browser into the BSP page Within a particular page, the prefix references the corresponding BSP extension that is assigned through the extension
directive.
The predefined default prefix can be overwritten on the page of the BSP application by renaming the prefix attribute for the extension directive.
6. Choose Continue to confirm your entries.
The system displays the Object Directory Entry dialog box.
7. Assign a package.
The new BSP extension is copied into the object list of the package.
Result
With the new BSP extension, you create a separate development object in the Repository that appears in inactive status in your worklist.
You can now create one or several BSP elements for this BSP extension and declare the appropriate element attributes.


1.4.3 Defining BSP Elements
Use
You create individual elements for a BSP extension and these are inserted later on as tags in BSP pages. Each BSP element has a handler class assigned to it
that implements its specific functions. Also, you can create and declare attributes for each BSP element.
Prerequisites
The BSP extension already exists.
Procedure
Creating BSP Elements
Choose the required BSP extension from the object list.
2. Choose the function Create → BSP Element from the context menu.
The system displays the Create BSP Element dialog box.
3. Enter the name of the BSP element, a valid name for the Element Handler Class , and a meaningful description for the BSP extension as a short text .
You can specify an existing, valid ABAP class as the element handler class. A valid class must support the interface
IF_BSP_ELEMENT.
We recommend that you derive this class from the automatically-
generated basis class(Z)CLG_<name of BSP extension>_<name of BSP elements>. This basis class already contains a standard implementation of the
interface methods and is automatically updated whenever changes are made to the element data.
As a rule, you enter the name of a non-existing class as the element handler class into the respective input field. Then you have this generated, together with the
corresponding basis class.
Choose Continue to confirm your entries.
The properties of the created BSP element are displayed in the editor.
Defining Attributes of the BSP Element
You can enhance the definition of a BSP element with a series of attributes. On the one hand, you can change the element content from the standard value. On
the other hand, it is possible to access the element content through Further Options for the element and change it, thus influencing the flow logic.
For more details, refer to the section:
Defining Element Content.
Furthermore, you have the following options available to you:
User-Defined Validation
Iteration Through Element Content
Manipulation of the Element Content
Declaring Attributes for a BSP Element
To create attributes for a BSP element, choose the Attributes tab in the element view and, if necessary, switch to change mode.
To create and declare an attribute, make the following specifications:
Attribute X In this column, enter a name that uniquely identifies
the attribute.
After you have
activated the BSP extension , the system
generates a public attribute with the same name in
the basis class (CLG_* or ZCLG_*).
Required
By setting this flag, you define that the attribute
PUBLIC
© 2014 SAP AG or an SAP affiliate company. All rights reserved.
Page 44 of 58
must be defined whenever the BSP element is
used in a BSP page.
Dynamic value allowed
By setting this flag, you define that the value of the
attribute in a BSP page may also be specified
dynamically through a BSP expression (<%=
...%>). Otherwise, only static values are possible
in the form of a string.
Pass by reference
By setting this flag, you define that the attribute is
passed to the event handler class as a reference.
Otherwise, no value is passed.
For more information, refer to the section
Pass by Reference for Attributes.
Kind of typing X You have at your disposal the two types TYPE and
TYPE REF TO, depending on whether you have
data or object references.
Note that the selection TYPE REF TO is only
appropriate in combination with the active option
Dynamic Value Allowed . The reason for this is
that object references in BSP pages can only be
passed with the help of BSP expressions, not
statically in the form of a string.
Reference type X As reference type, you can use the elementary
ABAP types (however, no generic types) or object
types (classes and interfaces). Generic types
such as C, N, X, P, and so on are not allowed
because generically-typed attributes are not
allowed in ABAP classes either. There is a 1:1
relationship between the attributes of the BSP
element and the class attributes.
Default value
Here you always enter a value if the attribute is to
be predefined with a value. This value is copied
from the Tag Browser into the BSP page when you
insert the attribute or the entire BSP element.
Description
Here you enter an explanatory attribute description.
The specifications marked with X are absolutely mandatory for each attribute.
Result
The new BSP element is assigned as a subobject to the BSP extension and copied inactive into the object list.
With the new BSP element, the basis class (Z)
CLG_<name of BSP extension>_<name of BSP elements> is automatically created itself, and possibly also the specified element handler class, provided
this does not yet exist.
Also, you have specified the BSP element behavior at runtime through further properties, and have also declared the corresponding attributes. In the next
workstep, you can
activate the BSP extension
1.4.3.1 Defining the Element Content
In general, BSP elements have a particular content. This means that the resulting tags consist of a start and an end tag, and between these two there are either
further (embedded) tags, script elements, or even simply just text. By selecting the option for the Element Content in the attribute display of the BSP element,
you can define whether content should be embedded in the element or not, and – if so – which content.
The display options comprise the following:
Empty
You select this option if the BSP element is not to have any content.
Example:
Input field from the BSP extension HTMLB
<ui:inputField id="myID" value="" />
or
<ui:inputField id="myID" value="" > </ui:inputField >
Solely BSP Elements
By selecting this option, you define that the BSP element is only to contain
further BSP elements. Any existing HTML part will be ignored by the runtime
environment. This reduction enables you to achieve performance optimization
during runtime.
Example:
Tree element from HTMLB
<ui:tree id="myTREE">

PUBLIC
© 2014 SAP AG or an SAP affiliate company. All rights reserved.
Page 45 of 58
<ui:treeNode id="ROOT" text="Root node">

<ui:treeNode id="N1" text="Node 1"/>

<ui:treeNode id="N2" text="Node 2"/>

</ui:treeNode>
</ui:tree>
BSP Elements and Static HTML
This element can include both further BSP elements as well as any HTML part.
Example:
Form element from HTMLB
<ui:form id="myFormID" method="POST">

<ui:inputField id="myID" value="" size="24"/>

<br> <br>

Some Text ...

<a HREF="" ...> ...</a>
</ui:form>
Element Interprets the Content Itself
With this selection, you define that the content of the element is to be passed on
unchanged, without previous parsing, to the element handler class. This is
appropriate whenever an interpretation of the element content is not required by
the runtime environment.
Example:
The BSP element executes an SQL statement that must be specified in the
element content.
<sql:selectStatement>

SELECT * from SFLIGHT into table myFlights
</sql:selectStatement >



1.4.3.2 User-Defined Validation
Use
Activate this option in the Attributes display for the BSP element if you wish to execute a user-defined validation of the element call. This can be the case, for
example, if you wish to check the correct type of attribute values. Generally speaking, validation can take place both at compile time and at runtime. Runtime
validation is particularly appropriate if attributes for BSP elements are assigned through BSP expressions (<%=...%>) only at runtime, or for attributes whose
values are transformed into another data type (String -> I) at runtime. Validation at compile time, on the other hand, is done by the BSP compiler and takes place
whenever values are passed using static attributes.
Activities
In addition to activating the option User-Defined Validation , you need to redefine the methods
COMPILE_TIME_IS_VALID (for validation at compile time) and/or RUNTIME_IS_VALID (for validation at runtime) in the element handler class.
You must set the return parameter
valid within the method COMPILE_TIME_IS_VALID. When determining this value, you use the predefined attributes and utilities belonging to the validation object
validator. This object has corresponding conversion methods that identify attributes at compile time through the attribute name (see first example). The validation
object validator is already contained in the interface for COMPILE_TIME_IS_VALID as an input parameter.
The R
UNTIME_IS_VALID method, on the other hand, does not define any return parameter. The runtime validation triggers an appropriate runtime exception if there is
an error. The validation object m_validator.is an important part of the method implementation. This object is already defined as an attribute of the element handler
class and also has conversion methods that identify the attributes through their names and also through their value (see second example). The attributes to be
checked (runtime attributes) are supplied as argument for calling the method RUNTIME_IS_VALID. This argument consists of a string in which the names of the
attributes to be checked are listed, separated by ‘ / ‘.
It can happen that the string with the runtime attributes to be checked exceeds the maximum length of 200 characters when <Elementname>->
RUNTIME_IS_VALID(attr_1/attr_2/ .../attr_n) is called – that is, if there is a large number of attributes. In such cases, you should pass the string ‘/ * / ‘ instead of
the attribute name in order to avoid termination during activation.
PUBLIC
© 2014 SAP AG or an SAP affiliate company. All rights reserved.
Page 46 of 58
the attribute name in order to avoid termination during activation.
Example: Validation at Compile Time
In the example below, the system is to check at compile time whether the value of the attribute
required is a correct Boolean value and whether the two attributes size and maxlength contain integer values.
For this purpose, the interface method
COMPILE_TIME_IS_VALID is overwritten. The corresponding methods of the object validator for the attributes concerned are called for the conversion of the string
value from the HTML data stream into Boolean and integer values. If all the checked attribute values are valid, the return value valid is filled accordingly with
m_all_values_valid.
method IF_BSP_ELEMENT~COMPILE_TIME_IS_VALID .
validator->to_boolean( name = 'required' ).
validator->to_integer( name = 'size' ).
validator->to_integer( name = 'maxlength' ).
valid = validator->m_all_values_valid.
endmethod.

Example: Validation at Runtime
In the example below, the system is to check at runtime whether the value of the attribute
visible is a correct Boolean value and whether the two attributes axisMinVal and axisMaxVal contain values of the type Float .
In this case, the interface method
RUNTIME_IS_VALID is overwritten. The parameter list m_visible, m_axisMinVal, m_axisMaxVal is passed to this method. The corresponding result of the
attribute check is written into this list. The attributes are identified using the methods of the validation object m_validator. The method RUNTIME_IS_VALID does
not return any return value. If one of the checked attribute values is invalid, a corresponding exception is triggered at runtime.
method IF_BSP_ELEMENT~RUNTIME_IS_VALID .
m_visible = m_validator->to_boolean( name = 'visible'
value = me->visible ).
m_axisMinVal = m_validator->to_float( name = 'axisMinVal'
value = me->axisMinVal ).
m_axisMaxVal = m_validator->to_float( name = 'axisMaxVal'
value = me->axisMaxVal ).
endmethod.



1.4.3.3 Iteration Through Element Content
Use
Activate this option in the Attributes display for the BSP element if this element is to run through its own content repeatedly, that is, it should implement a loop.
Activities
In addition to activating this option, you must also redefine the interface method
DO_AT_ITERATION of the element handler class.
This method is called each time at the end of an iteration. Using the return parameter , you control whether the loop is ended
(RC=CO_ELEMENT_DONE) or run through once again (RC=CO_ELEMENT_CONTINUE).
Example
Let us assume that you wish to have a repeated text call with a simple <do>-Element. The number of iterations is set through the corresponding attribute
howOften.
Example:
<loops:do howOften = "10">
Hello World !
</loops:do>
The value of the attribute
howOften is used at the beginning of the element call in the method DO_AT_BEGINNING in order to initialize the loop counter count:
method IF_BSP_ELEMENT~DO_AT_BEGINNING .

if howOften > 0.
PUBLIC
© 2014 SAP AG or an SAP affiliate company. All rights reserved.
Page 47 of 58

count = howOften - 1.

rc = CO_ELEMENT_CONTINUE.

else.

rc = CO_ELEMENT_DONE.
endmethod.
The method
DO_AT_BEGINNING should have already checked whether the element content is to be evaluated at all. If this not the case, DO_AT_ITERATION is skipped
and afterwards the method DO_AT_END is called.
The implementation of
DO_AT_ITERATION could look like this:
method IF_BSP_ELEMENT~DO_AT_ITERATION .

if count <> 0.

count = count - 1.

rc = CO_ELEMENT_CONTINUE.

else.

rc = CO_ELEMENT_DONE.

endif.
endmethod.
Note that the method
DO_AT_ITERATION is only called if the operation Iteration Through Element Content has been explicitly assigned as element attribute. See also Defining BSP
Elements.
DO_AT_ITERATION
is called as soon as the element content has been processed. The method DO_AT_END, on the other hand, is called whatever the case, but only once; in this
case, the call takes place after the iteration has closed



1.4.3.4 Manipulation of the Element Content
Use
Activate this option in the Attributes display for the BSP element if it is necessary that this element can manipulate its own content.
Activities
After activation of this option, a so-called BodyWriter becomes available in the interface attribute
M_OUT for the element handler class. This manages the content of the BSP element. Using the BodyWriter methods, you can manipulate the content accordingly.
To change the element content, you must also redefine the interface method
DO_AT_END for the element handler class as well as activate the option Manipulation of the Element Content .
This method is accessed in any case at the end of the element call. You can use them especially for manipulating the content in order to explicitly pass the
BodyWriter content to the BodyWriter of a surrounding BSP element. If no pass takes place in this case, the element content is discarded.
Example
In the following example, a BSP element is to convert its entire text content into upper-case letters. The method DO_AT_END is overwritten as follows:
First, the element content from the current BodyWriter
m_out is written to the local variable content. A new content is then assigned to this variable. Afterwards, the method call me->get_previous_out() returns the
BodyWriter of the surrounding element previous_out. The new content, however, is not automatically copied to this BodyWriter. The assignment of the new content
finally takes place with the method print_string().
method IF_BSP_ELEMENT~DO_AT_END.
data: content type string.

content = m_out->get_content( ).
PUBLIC
© 2014 SAP AG or an SAP affiliate company. All rights reserved.
Page 48 of 58
translate content to upper case.
data: previous_out type ref to IF_BSP_WRITER.

previous_out = me->get_previous_out().

previous_out-> print_string( content ).

rc = CO_PAGE_CONTINUE.
endmethod.





1.4.3.5 Pass by Reference for Attributes
Passing by reference is always appropriate if the BSP element is to have access to larger data quantities in the BSP page and passing "by value" would be too
costly. This is the case if you have access to internal tables.
In addition, the pass by reference is used whenever the BSP element is to change the content of a variable defined in the BSP page.
Note that in this case you must also select the typing kind
TYPE REF TO for the corresponding attribute.
Example
The BSP element is to increase the content of a passed variable by 1. The attribute
value is required for passing the value. Calling this increment element into the BSP page could then take place as follows:
<xyz:increment value = "<%=my_var%>"/>
The variable
my_var is declared in the BSP application as a page attribute of the type I.
For the
value attribute, the indicator Dynamic Value Allowed was activated and TYPE REF TO was selected as Typing Kind in the attribute display.
To execute this pass by reference at the beginning of the element call, you need to overwrite the method DO_AT_BEGINNING:
method IF_BSP_ELEMENT~DO_AT_BEGINNING .

...

add 1 to value->*.

rc = CO_ELEMENT_DONE.
endmethod.
Note that there is a reference to data in this example within a BSP element. To access data, the reference operator
->* must be used in ABAP in this case.


1.4.4 Activating the BSP Extension
Use
You use this standard function of the Workbench in order to put the entire BSP extension, including its elements, into the active version. If necessary, the system
will generate the basis class (CLG_* or ZCLG_*) again upon activation. This renewed generation always tales place during activation in the following cases:
If generation-relevant element data has been changed because, for example, element attributes have been created, deleted, or changed.
If a basis class for a particular element does not exist at all because, for example, it was deleted manually, or was not transported by mistake.
Prerequisites
You have either created a BSP extension or processed one that already exists.
Activation does not take place for the individual BSP elements alone, but is always done for the entire extension.
PUBLIC
© 2014 SAP AG or an SAP affiliate company. All rights reserved.
Page 49 of 58
Procedure
Choose the required BSP extension from the object list.
Select the Activate function from the context menu or through the respective icon in the application toolbar.
The system displays a list of all inactive objects. The selected BSP extension is marked.
Confirm the selection by clicking Continue .
Result
When you activate, you create a runtime version of the BSP extension. If necessary, the system will also regenerate the element handler classes and your basis
classes. Newly-created classes are automatically written to the same transport request as the BSP extension.
Now the active version of the BSP extension appears in the
Tag Browser under the entry BSP Extensions . There it is assigned to the selection Transportable or Local , depending on the object catalog entry.
Note that activating the extension can invalidate all the BSP pages that use this extension. Calling the respective BSP pages again means
they will be regenerated if changes have been made.



1.4.5 Implementing Element Handler Classes
Use
The element handler class is the central class of a BSP element. It implements the specific functions of an element and thus influences the flow logic of the BSP
page that uses this element. Through the type of implementation of certain methods belonging to this class, you can control whether data is updated in the HTML
data stream and whether the content of a BSP element is processed or discarded.
Element handler classes are instantiated during the processing of a BSP page and called at defined points in time using certain class methods.
Prerequisites
A valid element handler class must implement the interface IF_BSP_ELEMENT. We therefore recommend that you derive this class from the
generated superclass (Z)CLG_<EXTENSION>_<ELEMENT> because it already contains the standard implementations for the interface methods.
Process Flow
The flow during implementation of the specific functions of a BSP element is divided up into the following three steps:
1. Creating the attributes for the BSP element See also Defining BSP Elements.
In this way, you make sure that the new attributes are added as attributes of the element handler classes after activation of the BSP extension.
2. Overwriting certain
interface methods of the element handler class
Creating further methods or attributes that enhance the element functions





1.4.5.1 Generated Classes and Class Hierarchy
The following figure shows the position of the element handler class within the inheritance hierarchy of the classes involved:
PUBLIC
© 2014 SAP AG or an SAP affiliate company. All rights reserved.
Page 50 of 58
Extension Framework
IF_BSP_ELEMENT Basic interface that each valid element handler class must implement. The
methods and attributes of this interface already define the actual extension
framework for BSP applications.
CL_BSP_ELEMENT Basis class with a standard implementation of the
IF_BSP_ELEMENT methods for all BSP elements.
See also:
Basis Class CL_BSP_ELEMENT
Element-specific classes
(Z)CLG_<EXTENSION>_<ELEMENT> This class is automatically generated by the development environment for each
new BSP element and is provided as a basis class for the element handler
class.
It has a 1:1 relationship to a BSP element and already contains a standard
implementation for the corresponding element.
In contrast to its superclass
CL_BSP_ELEMENT, it contains public attributes that correspond to element
attributes and, additionally, the standard implementation for the constructor (and,
if necessary, for the class constructor as well).
CL_<EXTENSION>_<ELEMENT> The element class, too, has a 1:1 relationship to a BSP element and
implements its specific functions. As a rule, it is derived from the CLG class.
This is recommended, but not compulsory.
Compared to its basis class, the element handler class can be enhanced to
include specific methods. In addition, special interface methods can be
redefined, depending on the element attributes.


1.4.5.2 Basis Class CL_BSP_ELEMENT
Definition
The CL_BSP_ELEMENT class supplies a standard implementation of the interface IF_BSP_ELEMENT. This basis interface basically provides a series of
methods and attributes that are used as a framework for the implementation of individual elements in BSP extensions.
Use
The standard implementation of the class CL_BSP_ELEMENT provides the common basic functions for all element handler classes. To implement specific
functions of a BSP element, you must overwrite certain interface methods in the element handler class and possibly also create new ones there.
Refer also to the section:
Implementing Element Handler Classes.
PUBLIC
© 2014 SAP AG or an SAP affiliate company. All rights reserved.
Page 51 of 58
Methods
Interface Methods for Validation
COMPILE_TIME_IS_VALID Determines at compile time whether correct values have been assigned to
element attributes. The validation result is written to the return parameter valid.
The possible values for valid are: ‚X' or ' ' (blank).
For information on how you can overwrite this method in the element handler
class, refer to the example given for
user-defined validation.
RUNTIME_IS_VALID Determines at runtime whether correct values have been assigned to the
element attributes. For more information, refer also to the example for
user-defined validation.
By calling the runtime method <Elementname>->RUNTIME_IS_VALID with the
special argument ‘/*/‘, you can prevent termination from happening at activation
if the string with runtime attributes (arg_1/arg_2/...) becomes too long (maximum
length is 200 characters) and thus overflows.
Interface Methods to Influence Element Flow and Element Content
DO_AT_BEGINNING This method is always accessed at the beginning of the element call when the
BSP page is processed.
Using the return parameter RC you can control whether the content of the current
BSP element is to be evaluated or not. The possible values of the return
parameter RC are therefore:
CO_ELEMENT_CONTINUE and CO_ELEMENT_DONE.
For an example of a special implementation of this method, refer to the section
Pass by Reference for Attributes.
DO_AT_ITERATION This method is accessed after evaluation of the element content when the BSP
page is processed. The prerequisite for calling this method at all is that the
corresponding option Iteration Through Element Content has been explicitly set
for the element.
This method returns the return parameter RC.
The possible values of the return parameter RC here, too, include the following:
CO_ELEMENT_CONTINUE and CO_ELEMENT_DONE.
For an example of the implementation, refer to the section
Iteration Through Element Content.
DO_AT_END This method is accessed, whatever the case, at the end of the element call.
Since the entire element content is available at this point, this method can be
used for
Manipulation of the Element Content.
Using the return parameter RC, you can control whether the entire BSP page is
to be evaluated further or not. The possible values are therefore:
CO_PAGE_CONTINUE and CO_PAGE_DONE.
Interface Methods for Accessing Parent Nodes
GET_CLASS_NAMED_PARENT Returns an arbitrary parent element that is identified by the element handler
class.
GET_ELEMENT_NAMED_PARENT Returns an arbitrary parent element that is identified by the name of the
extension and the name of the element.
GET_DIRECT_PARENT Returns the direct parent element.
Interface Method For Error Handling
RAISE_ERROR Triggers an exception of the class CX_BSP_ELEMENT_EXCEPTION.
Interface Method for Accessing the Content of the BodyWriter
GET_PREVIOUS_OUT Returns the reference to the BodyWriter of the surrounding element.

Attributes
General Interface Attributes
ID BSP element ID
M_NAME BSP element name
M_EXTENSION BSP extension name
M_CLASS_NAME Name of element handler class
M_PARENT Reference to a parent element
M_PAGE_CONTEXT Reference to the page context (IF_BSP_PAGE_CONTEXT)
Predefined Interface Constants
CO_PAGE_DONE This constant defines that the BSP page is not to be evaluated further.
CO_PAGE_CONTINUE This constant defines that the BSP page is to be evaluated further.
CO_ELEMENT_DONE This constant defines that the BSP element is not to be evaluated further.
CO_ELEMENT_CONTINUE This constant defines that the BSP element is to be evaluated (once more).
PUBLIC
© 2014 SAP AG or an SAP affiliate company. All rights reserved.
Page 52 of 58
Interface Attribute for the BodyWriter
M_OUT Reference to the BodyWriter that manages the element content.
Interface Attribute for Validation
M_VALIDATOR Static validator (for all class instances) that is used for runtime validation.
Instances of this object are created only if the option Iteration Through Element
Content has been explicitly set for the element.



1.4.6 Entering Documentation
Use
You can create a long text documentation both for a BSP extension as well as for each BSP element in the system that is contained in this extension. This
document is of particular importance for the productive usage of the extension in BSP pages because you can include special aspects of the individual BSP
elements here.
If you store the documentation in the system, it is then available to users through the context menu in the Tag Browser and also through insertion of the tag into a
BSP page – also by pressing F1 in the layout editor.
Prerequisites
The BSP extension and the elements to be documented have already been created.
There are two different templates available for the BSP extension and the BSP elements. The procedure for creating the documentation is the same,
however.
Procedure
To create documentation for a BSP element in SE80:
1. Select the BSP extension in the Repository Browser.
2. Double-click the required BSP element in the object list.
The system displays the element editor.
3. Go to Change mode.
4. Click the Documentation pushbutton in the toolbar.
The SAPScript Editor is called up and displays an empty template with predefined paragraphs.
5. Write your text into the predefined paragraphs.
6. Save the SAPScript document as a raw version first.
7. Test the documentation and make whatever corrections are necessary.
8. Save the document as active version .
Result
You have created a SAPScript document for the long text documentation of a BSP element and have assigned a transport request to it.
If you have saved the document as an active version as well, this will be transported to the translation worklist.
Example
The documentation for all BSP elements is available for the BSP extension
HTMLB.


1.4.7 Using BSP Elements
Use
All delivered or newly created BSP extensions are available in the
Tag Browser of the Object Navigator. You can use these in BSP application pages in order to create flexible Web user interfaces.
You enter the individual BSP elements and their attributes as tags or tag attributes from the Tag Browser into the layout source text of the BSP pages.
Prerequisites
The switch button Tab Browser is available in the navigation area of the Object Navigator. If this is not the case, change the corresponding user settings.
PUBLIC
© 2014 SAP AG or an SAP affiliate company. All rights reserved.
Page 53 of 58
So that the BSP extension is displayed with the required elements in the Tab Browser, the extension must already be activated.
Procedure
To insert BSP elements or their attributes into a BSP page, proceed as follows:
1. Choose the Layout view for the required BSP page.
2. Switch to Change mode.
3. Click the switch button Tag Browser in the navigation area of the Object Navigator.
4. Under BSP Extensions , choose the appropriate extension.
5. Expand the tree display and click the required BSP element.
6. Double-click the selected entry in order to display the documentation for the BSP element.
7. Using Drag and Drop , drag the selected element or element attribute to the appropriate position in the layout editor.
Multiple selection within the tree display is currently not supported.
Result
When you select an element in the tree display, the corresponding start tag and end tag, including all the obligatory element attributes, are inserted at the selected
cursor position in the BSP page. If you enter an element attribute, the system takes the predefined standard value.
With the first element of a BSP extension, the extension directive for the page is automatically created. The system adopts as prefix the default prefix that was
specified when you
created the BSP extension. By typing over the prefix value in the extension directive, however, you can rename the prefix. This means that all tags entered
subsequently from the Tag Browser already contain the new prefix.
If
documentation was created for a BSP element, you can call this by pressing F1 in the layout editor of the BSP page.
Example
The following example demonstrates the usage of the BSP extension HTMLB in a BSP application.



1.4.7.1 Example: Using Extensions in BSP Pages
The following example shows the realization of a simple Web user interface for a BSP application using the HTMLB library
HTMLB. This library is available in each SAP Web Application Server System and can be imported within the workbench from the Tag Browser into any BSP
page.
This example contains a label, input, and pushbutton element – in addition to the content, page, and form elements - for simple selection of flight data. The flight
data is displayed using a TableView element.

<%@page language="abap"%>
<%@ extension name="htmlb" prefix="ui" %>
<ui:content>
<ui:page>
<ui:form>
<ui:label id = "myLabel"
for = "carrier"
text = "Airline"
design = "LABEL"
width = "65" />
<ui:inputField id = "carrier"
type = "String"
value = "<%=carrier%>"
size = "3"
design = "standard" />
<ui:button id = "myButton"
text = "Find Flights"
onClick = "FIND"
design = "STANDARD" />
<br><br>
<ui:tableView id = "myTable"
table = "<%=flights%>"
headerVisible = "true"
footerVisible = "true"
fillUpEmptyRows= "true"
selectionMode = "MULTISELECT"
design = "ALTERNATING" />
</ui:form>
PUBLIC
© 2014 SAP AG or an SAP affiliate company. All rights reserved.
Page 54 of 58
</ui:page>
</ui:content>
Note on the prefix:
The BSP extension HTMLB is imported into the BSP page through the extension directive (2
nd
line). A prefix serves as a unique identification of this
extension within the page. This directive is automatically crated after you have inserted the first BSP element for the page. In the standard version, the
default prefix is taken. However, you can rename the prefix by overwriting the corresponding value in the extension directive (in our example: ui).


1.5 Implementing External Tools with WebDAV
Prerequisites
You can use external tools, that is, all standard Web development and design environments, to implement the page layout of your BSP application.
This requires, however, that the external tools support the WebDAV protocol and are able to function as a WebDAV client.
WebDAV is an extension of the HTTP protocol and generally provides an infrastructure for editing documents (such as HTML pages) across distributed Web
development environments.
In this connection, the mySAP.com application server plays the role of a WebDAV server. It is equipped with an appropriate WebDAV service.
A WebDAV service is a special HTTP request handler that establishes a remote connection based on the WebDAV protocol. The WebDAV service is
implemented through a global ABAP class.
Usage Scenarios
Implementing the Page Layout Using External Tools
Mass Import of MIMEs Using WebDAV.
1.5.1 Implementing the Page Layout Using External Tools
You create the basic structure of a BSP application in the Web Application Builder (SE80).
Afterwards, you can edit the pages of that application using external tools. This is made possible by a check-out/check-in mechanism. You use external tools
primarily for implementing the page layout. It is not possible to edit page parameters and event handlers.
You can use a WebDAV client to perform the following tasks:
Implement the page layout
Import MIMEs
Create new pages
Check in the pages

PUBLIC
© 2014 SAP AG or an SAP affiliate company. All rights reserved.
Page 55 of 58
Process Flow (See Also Figure Above)
Creating the basic structure of the BSP application in transaction SE80.
For each new BSP application, the system creates an identically named directory in the MIME Repository.
Checking out the pages using WebDAV.
The pages can then be edited in the WebDAV client.
Importing the required MIMEs from the file directory of the hard disk into the application directory in the MIME Repository.
All imported MIMEs are part of the MIME Repository. By default, these MIMEs are assigned the package of the BSP application.
Implementing the page layout.
Creating and implementing additionally required HTML pages.
Checking in the pages.
All new pages are imported as static pages into the MIME Repository. By default, these MIMEs are assigned the package of the BSP application.
Converting the static pages in the MIME Repository into BSPs, if required.
Once you have completed these steps, you implement the event handlers, declare the page parameters, and activate and test your BSP application in
transaction SE80.


1.6.2 Mass Import for MIMEs Using WebDAV
As an alternative to the import function of the MIME Repository, you can perform a mass transfer of MIMEs by using the WebDAV interface.
In this scenario, you do not need to check out your pages. You merely establish a connection to the application server through WebDAV and transfer the MIME
objects from the file directory of your hard disk to the desired directory in the MIME Repository.
Process Flow
1. Logging on to the application server through WebDAV (for example, using Web folders or My Network Places in Windows environments).
To do this, you must specify the address of the SAP application server and the WebDAV service in the following form:
HTTP://<Application server>:<Port>/<Namespace>/<WebDAV service>
Example:
HTTP://xyzmain.wdf.sap-ag.de:1080/sap/bc/bsp_dev

To find out the namespace (in the above example: sap/bc/) and the name of the WebDAV services (in the above example: bsp_dev), call
up the transaction SICF. All services are listed as ICF objects in Maintenance of Services .

The address named above is valid for system standard clients only. If you want to access MIME objects via WebDAV using a different
client, you have to expand the address appropriately. Call the BSP page encode.htm from the decode_url BSP application to create an
appropriate address.

PUBLIC
© 2014 SAP AG or an SAP affiliate company. All rights reserved.
Page 56 of 58
This completes the input of logon data for your logon to the SAP System.
2. Selecting the target directory in the MIME Repository.
3. Importing MIMEs from the file directory of the hard disk into the selected directory of the MIME Repository (using Drag and Drop, for example).
All MIMEs imported are then part of the MIME Repository. By default, they are assigned to the package of the BSP application.
See also
Importing and Deleting MIMEs


Tips & Tricks

How to Copy Page Attributes
How to Implement a Mass Import for MIMEs to the MIME Repository



1.6.1 Copying Page Attributes
Use
You might need the same set of page attributes on several pages of your BSP application. This is the case if you want to pass data from one page to the following
pages using automatic page attributes. You need not edit page parameters having the same name for each page; you can simply copy the page attributes.
Prerequisites
You are on the Page Attributes screen of the BSP from which you want to copy a selection of page attributes.
Procedure
To copy the page attributes:
1. Select the rows for the selected page attributes using the selection column.
2. Click on the icon in the toolbar to copy the selected rows.
3. Go to the Page Attributes display for the target page and switch to Change mode if necessary.
4. Place the cursor on an empty row within the Attribute column.
5. Click on the icon in the toolbar to insert the rows with the page attributes.
The selected page attributes are included in the target page with the same names.



1.6.2 Mass Import for MIMEs Using WebDAV
As an alternative to the import function of the MIME Repository, you can perform a mass transfer of MIMEs by using the WebDAV interface.
In this scenario, you do not need to check out your pages. You merely establish a connection to the application server through WebDAV and transfer the MIME
objects from the file directory of your hard disk to the desired directory in the MIME Repository.
Process Flow
1. Logging on to the application server through WebDAV (for example, using Web folders or My Network Places in Windows environments).
To do this, you must specify the address of the SAP application server and the WebDAV service in the following form:
HTTP://<Application server>:<Port>/<Namespace>/<WebDAV service>
Example:
HTTP://xyzmain.wdf.sap-ag.de:1080/sap/bc/bsp_dev

To find out the namespace (in the above example: sap/bc/) and the name of the WebDAV services (in the above example: bsp_dev), call
up the transaction SICF. All services are listed as ICF objects in Maintenance of Services .

The address named above is valid for system standard clients only. If you want to access MIME objects via WebDAV using a different
client, you have to expand the address appropriately. Call the BSP page encode.htm from the decode_url BSP application to create an
appropriate address.
PUBLIC
© 2014 SAP AG or an SAP affiliate company. All rights reserved.
Page 57 of 58

This completes the input of logon data for your logon to the SAP System.
2. Selecting the target directory in the MIME Repository.
3. Importing MIMEs from the file directory of the hard disk into the selected directory of the MIME Repository (using Drag and Drop, for example).
All MIMEs imported are then part of the MIME Repository. By default, they are assigned to the package of the BSP application.
See also
Importing and Deleting MIMEs


PUBLIC
© 2014 SAP AG or an SAP affiliate company. All rights reserved.
Page 58 of 58

Sponsor Documents

Or use your account on DocShare.tips

Hide

Forgot your password?

Or register your new account on DocShare.tips

Hide

Lost your password? Please enter your email address. You will receive a link to create a new password.

Back to log-in

Close