Programming Model

The following documentation describes the BSP programming model: BSP Applications BSPs BSP Directives Central Classes and Interfaces Important Global Objects BSP Extensions Model View Controller (MVC) Stateful and Stateless Control Flow and Lifetime Caching Page Design Accessibility
For SAP Web AS 6.20, the BSP programming model was enhanced with the MVC design pattern as well as the paradigm of the BSP extensions.

What is a BSP Application?

Overview
A Business Server Page (BSP) application is a complete functional application, like a classic SAP transaction. However, this application is executed in a Web browser rather than in the SAPGUI. HTTP or HTTPS is the protocol used to access the application across the network, thus allowing the use of standard products like firewalls and proxy servers. The Business Server Pages programming model is similar to the server page technology. The focus of the BSP programming model are points that ensure optimum structure in interfaces and business logic. For more information about BSP applications, see:
The components of a BSP application and how they interact, see Structure of a BSP Application. How to call an existing BSP application from a Web browser, see Accessing a BSP Application. How to open and close a BSP application, see Starting and Ending a BSP Application. How a BSP application is processed, see Processing a BSP Application How to create a BSP application, see Creating a BSP Application. The URL parameters you can use to access the BSP runtime environment and BSP applications, see System-Specific URL Parameters. The concept of an application class for encapsulating the business logic of a BSP application, see Application Class of a BSP Application

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.

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 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

Accessing a BSP Application

As explained previously, you access BSP applications using the HTTP or HTTPS (Secure HTTP) protocol. The BSP runtime environment uses the HTTP framework of the SAP Web Application Server (compare Interaction Model). In the Internet Communication Framework (ICF), for a BSP application to function smoothly you need a node, that is, a service in the service tree (see also Creating a BSP Application). Ensure that after a SAP Web AS has been installed, that all services are inactive and that they must be activated accordingly. You can find further information about activation under Activating and Deactivating an ICF Service and in Business Server Pages Administration. The node is activated in the service tree only with BSP applications that were newly created for SAP Web AS 6.20 as part of automatically creating the corresponding node. A BSP application is addressed and executed through HTTP using a Uniform Resource Locator (URL). The URL of a BSP application has the following structure (default configuration): <Prot>://<Host>.<domain>.<extension>:<Port>/sap/bc/bsp/<namespace>/<application name> Protocol Prot is httpor https (if configured). Host is the name of the application server that should execute the application. The domainwith the extension

encompasses several hosts under a common name. These can either be part of an individual host or a network. The Port number can be omitted if the default port 80 (http) or 443 (https) is used. For SAP Web Application Server, the default port number is 1080 (HTTP) or 1443 (HTTPS). The namespace is the namespace ID of the BSP application. SAP applications are delivered in the sap namespace. If you create your BSP application in a separate namespace, it must be used in the URL. The application name is the name of the BSP application as defined in the development environment.
Here is an example of a URL for BSP test application IT00: http://myServer.sap-ag.de:1080/sap/bc/bsp/sap/it00

The full name of the server is specified, including the network domain (here: sapag.de). If this is not done, the BSP runtime environment returns an error. The full domain must be entered, as there may otherwise be problems with HTTP cookies (such as Single Sign On). If the BSP that you start by calling Transaction SE80 contains a shortened URL (excluding the host name), proceed as described in Note 434918.

When this URL is started in the Web browser, the BSP application is started, and the initial page is displayed (by default this is default.htm). To determine the URL of a BSP or BSP application in the SAP development environment, select the Properties tab to the right of the SAP GUI screen.
Example of page default.htm of BSP application IT00:

For more information: Starting and Closing a BSP Application Cache Key

Starting and Ending a BSP Application

Use
URL parameters can be used to inform the BSP runtime environment to start or end a BSP application (corresponds to the OK code /n in SAP GUI) To do this, the Query String parameter sap-sessioncmd is added to the URL and the HTTP request is sent to the server.
To be compatible with SAP Internet Transaction Server (ITS) and the SAP Enterprise Portal (SAP EP), you can also use ~SAPSessionCmd.

For a list of all system-specific URL parameters that have a special use in the BSP application environment, see System-Specific URL Parameters.

Procedure
The following commands are supported:
open: Restarts a BSP application that is running. The application is started up if it is not currently running.
http://myServer.sap.corp:1080/sap/bc/bsp/sap/it00?sap-sessioncmd=open

close: Ends a running BSP application and either tells the system to display a blank page or go to a specific Web site (exit URL). The exit URL is specified using an additional URL parameter,This parameter is calledsap-exiturl,and must contain a full HTTP URL. To be compatible with SAP Internet Transaction Server (ITS) and the SAP Enterprise Portal (SAP EP), you can also use ~exitURL.

Example
1. Restart of BSP test application IT00:
http://myServer.sap.corp:1080/sap/bc/bsp/sap/it00?sap sessioncmd=open

1.

Ending the application externally:

http://myServer.sap.corp:1080/sap/bc/bsp/sap/it00?sap sessioncmd=close&sapexiturl=http%3a%2f%2fwww.sap.com Pay attention to the spelling of the URL - all URI parameters, that is everything following the ?, must be URL-encoded.

System-Specific URL Parameters

To control the BSP runtime environment and the BSP application, you can use the following URL query string parameters in a request URL. URL Parameter Value Description

sap-sessioncmd

open: close:

Restarts the BSP application named in the URL Ends the BSP application named in the URL and sends the browser, if specified, to the Web site defined by sapexiturl. If you want the user to be able to end the application, this option should be available in a BSP application as part of the user interface (as a pushbutton or hyperlink). Specifies the URL to which the browser is directed when the BSP application ends (for example, http://www.sap.com) Overrides the theme for a BSP application to use other MIME objects, such as pictures and Stylesheets for visualization. Used to handle paths to other locations from where stylesheets are taken. See also: Changing Stylesheets for HTMLB and XHTMLB This parameter is available from SAP Web AS 6.20 Support Package 7.

sap-exiturl

sap-theme

sap-themeRoot

sap-client

Specifies the client for a logon to the SAP Web Application Server; can be used in the URL or in HTML forms to override the default client. Specifies the user for a logon to the SAP Web Application Server; can be used in the URL or in HTML for forms. Specifies the password for logon; can be used in HTML forms. Do not enter this directly in the URL as Web browser URLs are stored in a History list and the password would be visible in plain text, even after the browser is closed.

sap-user sap-password

* *

sap-language

Specifies the language (ISO language ID, such as EN or DE) for a logon to the SAP Web Application Server; can be used in the URL or in HTML forms to override the default logon language. Dynamic switching of the different default design variants, without using the attribute design of <htmlb: content>. Possible values are CLASSIC, DESIGN2002 and DESIGN2003. For SAP Enterprise Portal 5, DESIGN2002 is supported.

sap-htmlbdesign

For SAP Enterprise Portal 6, both DESIGN2002 and DESIGN2003 are supported. sapdomainRelax off | min | max Maximum domain relaxing, see also Domain Relaxing

sap-accessibility X |

Specification for the accessibility See also Configuration Settings To activate this indicator, an activated checkbox is placed on the logon screen for input help. Details of the RTL support The family of <HTMLB> libraries supports RTL (right-toleft) rendering for design2003. You can activate RTL rendering using the URL parameter sap-rtl=true (but only for the first call before the BSP URL finds out about the URL mangling). Use attribute rtlAutoSwitch from <htmlb:content> to activate the RTL mode automatically, depending on the currently active language (SY-LANGU). The decision about activating RTL is delegated to the function module NLS_RTL_DISPLAY.

sap-rtl

True | False

Parameter names and parameter values are not case sensitive (exception: sapexiturl is case-sensitive, if the link is to a case-sensitive server). You can combine several parameters in one URL.
Here is an example of how to restart a BSP application in client 800 with logon language English. http://myServer.sap.com:1080/bc/bsp/sap/it00?sapsessioncmd=open&sap-language=en&sap-client=800

Processing a BSP Application

Uses
When a BSP application is being processed, the individual BSPs and their components are run, and the corresponding processing steps are executed according to the code.

Process
If an HTTP request is sent to a BSP, that is, if a page (in stateless case: for the first time) is called, the page in instantiated in OnCreate. Next, OnRequest is called. The handler is then run that is most appropriate for the request, that is, OnInitialization for URL input, OnInputProcessing for HTML input, or another individual event handler if controls are used.

If it hasnt already, OnInitialization is run, so that the initialization phase data is assessed. Data in the SAP system, such as table contents or BAPIs, can be accessed in this phase. Then, the layout part (the hidden part of the event handler OnLayout) is processed, which determines the design and presentation logic of a page. This code consist of static parts (for example, HTML) and scripting code. To ensure clean programming, no business logic or data retrieval is carried out in the layout part. The manipulation part becomes important if the HTTP data stream should be modified later. The manipulation code should likewise contain no business logic or statements for data retrieval functionality. If there are no subsequent changes, the manipulation part is not required. On the basis of all this data, the first page is built and sent to the user. Next comes the user interaction phase, in which the user inputs data. The user input is sent back to the BSP. This input triggers an additional HTTP request. You can specify for every page whether stateful or stateless mode is required. This is done in the input processing part. For example, incorrect input can be checked, data can be read from the database, and the succeeding page can be determined. The subsequent page for the navigation request is determined in the navigation part of the application. If no succeeding page is set, the first page is reprocessed. Then, processing of the initialization part continues. For more information, see Control Flow of BSPs

Creating a BSP Application

You create your Web application in the form of a BSP application. For information about the procedure for creating BSP applications, see the documentation on Web Application Builder in the sections under Basic Functions..

Extending Security Aspects with BSP Applications

So that a BSP application can function correctly, there must be a node that corresponds to each BSP application in the service tree (Transaction SICF) of the Internet Communication Framework (ICF). When you create a BSP application in the Web Application Builder in SAP Web AS 6.20 and higher, this type of node is created and activated in the appropriate part of the ICF service tree (see Creating an ICF Service). If necessary, you can define permissions for this node (see Maintaining Service Data). For BSP applications that were created before SAP Web AS 6.20 and which therefore do not have any nodes in the ICF service tree, this node is generated automatically by the system as soon as you branch to the corresponding BSP application in change mode.
There may be conflict with old BSP applications with names that are longer than 15 characters. Before SAP Web AS 6.20, you could create BSP applications whose names could exceed the length of the service name in Transaction SICF. In this case, we recommend that you copy all of the old BSP application to a new BSP application with a shorter name, so that the node is automatically created.

Application Class of a BSP Application

Overview
A BSP application comprises a number of different development objects. One of these objects is the application class of the BSP application. The application class is a regular ABAP Objects class. As such, the application class can include any methods, attributes and events that the developers wish to have. The application class is usually used to store data and make it available across BSP pages. This data is stored as attributes. The application class also encapsulates BSP application logic in methods. This allows several BSP applications to use the same application class and provide one business application that contains different interfaces, such as for various devices, without having to replicate the business or application logic. This also means the global Object application can be used in the BSP application to access the attributes and methods of the application class. You do not have to use an application class in your BSP application. Rather, it is an optional way for application developers to structure their BSP application. You use the Web Application Builder in transaction SE80to assign an application class to a BSP application.

A simple example of where an application class could be useful would be a class for controlling dialog logic and maintaining data consistency in a BSP application for shopping. This application class would include a shopping basket (internal table or other object) as an attribute. There would also be methods for changing and processing the shopping basket, such as to add, change, or delete articles. Methods for determining prices, creating offers, and posting orders would also be helpful. In many cases, the application class is only used to encapsulate existing application functions, such as from SAP Customer Relationship Management (SAP CRM), and then access the function through BAPI interfaces. Using an application class to

encapsulate the functions ensures that the BSP application functions are stored in a central location (in the application class) and that both implementation and distribution are transparent (local method call but remote BAPI call internally). If a customer or developer wants to change or adapt a BSP application or use the application for an additional device, they have the full functions of the original BSP application available in the interface of the application class.

Runtime Behavior
Any ABAP Objects class can potentially be used as an application class of a BSP application. However, the BSP runtime environment must treat the class as a singleton, that is, a class for which there is only one instance per session. The lifetime of an application class depends on the state model of the BSP application. A BSP application can be stateful or stateless. Stateful BSP Application In Stateful BSP Applications, the only instance of the application class, the application object, is generated at the first request sent to the BSP application. The object is then available for the entire lifetime of the session. The end lifetime of the application object ends when the session ends. In stateful mode, the application class provides local buffering for data sets that are difficult to determine. Stateless BSP Application In Stateless BSP Applications, the application context (roll area) is only available for the lifetime of a single request and is released at the end of the request. When the application context is released, all data and objects held by the session on the application server are also released. This includes the application object. This means the lifetime of the application object starts when the request is received and ends when a response is sent. The application object is not available across several pages. Each page and each request interacts with a different instance of the application class. In stateless mode, the application object cannot hold data across requests. For stateless applications, application classes are usually used to store the business logic in methods, but do not buffer data.

Accessing the Application Object

To access the application object, you use a typed object reference that is stored as the parameter application in all event handlers of a BSP. Of course, you must ensure, however, that the parameter only exists if an application class is defined for a BSP application.

Requirements for an Application Class

The only real requirement for an application is that the constructor must be parameterless. Otherwise, the application class cannot be generically instantiated by the BSP runtime environment. Apart from this, there are no other restrictions. You do need to ensure that the internal implementation of methods is chosen correctly, depending on the state mode where the class is implemented. For stateless applications, for example, it would be useless to implement expensive data gathering routines as these would be lost after every request.

Instead, just get the exact data you need at that time. In stateful applications, you can implement an initialization phase where you get a large amount of data at one time, which can improve performance.

Application Events: The IF_BSP_APPLICATION_EVENTS Interface

In stateless BSP applications, an application often needs centralized control at certain times in the lifetime of the application. The BSP model provides this function for the application class in the predefined interface IF_BSP_APPLICATION_EVENTS. When an application class implements the optional interface IF_BSP_APPLICATION_EVENTS, the BSP runtime environment calls the interface methods at the relevant times. The following describes the methods and times:

IF_BSP_APPLICATION_EVENTS~ON_START

This method is called by the BSP runtime environment when the corresponding BSP application is first started at the start of the BSP session. This applies to both stateless and stateful applications. Typically, this time point is used to carry out authorization checks that apply to the entire application, or for preliminary data retrieval (in stateful applications). This method is called by the BSP runtime environment when the corresponding BSP application is explicitly ended. This applies for both stateless and stateful applications. Note that this time is not available after every request in stateless BSP applications. This time is not evaluated either if the session is implicitly terminated by a timeout. In this method, it is only possible therefore to

IF_BSP_APPLICATION_EVENTS~ON_STOP

execute optional operations that are non-critical. Typically, this is a good time for cleanup operations such as deleting browser cookies or server-side cookies, if the application generated them. IF_BSP_APPLICATION_EVENTS~ON_REQUEST This method is called by the BSP runtime environment for every incoming request to a BSP before the BSP is given control (in the OnRequest event handler). This time can be used by the application class, for example, to restore attributes that were rescued in clientor server-side cookies in a previous request.
BSP runtime for every outgoing response of a BSP after the BSP has been processed (after the OnManipulation event handler).

IF_BSP_APPLICATION_EVENTS~ON_RESPONSE This method is called by the

This time can be used by a stateless application class for tasks such as rescuing attributes in client-side or server-side cookies.

See also: You can find details of interface IF_BSP_APPLICATION_EVENTSin the reference documentation Interface IF_BSP_APPLICATION_EVENTS:

Application Base Class CL_BSP_APPLICATION

If an application class does not already have a super class, it can be derived from the predefined base class CL_BSP_APPLICATION. This class provides methods that are typically required by a BSP application for embedding in a Web environment. This is how information about the current BSP application (such as session timeout, current URL of BSP application, state mode, and so on) can be called or set.

As the application object is an application attribute in every BSP event handler, the methods of the CL_BSP_APPLICATION class are also available with the corresponding inheritance. This makes it easy to provide the relevant functionality to lower application levels using a single object reference. See also: You can find information about base class CL_BSP_APPLICATION in the reference documentation Class CL_BSP_APPLICATION:

BSP Components
Business Server Pages (BSPs) are HTML pages that contain the actual application logic and presentation logic. BSPs define the Web user interface and determine the elements of user interaction. BSPs consist of the following components:

Server-side scripting determines the presentation logic as part of layout processing. In the preview, you can check the appearance of your pages, without having to call up the browser. Page attributes are visible in the layout processing as well as in the event handlers of a page. They can be used to store data obtained in the standard handler OnInitialization, and to make this data accessible for the layout processing and the other event handlers. Predefined event handlers are available for the different events.

You can use type definitions to define local types. Similar to every object in the SAP System, BSPs also have different administration attributes.

Properties
BSPs have a number of general properties or attributes. For example, each BSP is assigned to a package in the SAP system, and each BSP has a URL used to call up the BSP in a Web browser. The following describes the most important additional properties.

Page Type
You can find additional information about the different features of a page in Structure of a BSP Application.

Error Handling
For more information see Creating Error Pages.

Status
A BSP can be stateful or stateless. For more information see Stateful and Stateless.

Caching
For more information see Caching BSPs.

Transmission Options
You can set the flags Compression and HTTPS as the transmission options. Compressing If you set this flat, the page is sent compressed to the browser, provided that the browser supports compression. Note that it only makes sense to activate compression for large pages. It is considerably more efficient to send small pages uncompressed. It is considerably more efficient to send small pages uncompressed. HTTPS By selecting this flag, you can determine that a BSP should be accessed using HTTPS, that is, a secure connection. The BSP runtime then checks the URL. In the case of http://... it redirects the browser immediately to https://... . Not the following browser-specific feature: As soon as you activate HTTPs, all other BSPs of your BSP application are accessed using HTTPS.

It is considerably more efficient to send small pages uncompressed.

Layout
Use
You determine the presentation logic for your BSP using server-side scripting in the layout. To ensure clean development, layout and presentation must be separated from processing logic. Therefore, scripting for the static details of a page is part of layout processing, while the dynamic processing steps are set in the different event handlers (see Event Handlers). The layout can also be regarded as an internal event handler for the presentation.

You can create your own stylesheets or use predefined ones.

Functions
You can access the following objects in the implementation: Object APPLICATION Reference Type type ref to application class Description

Application class re application or appli BSP application. If in the BSP applicat object application is

RUNTIME REQUEST

type ref to IF_BSP_RUNTIME type ref to IF_HTTP_REQUEST

The runtime object IF_BSP_RUNTIME

The request object IF_HTTP_REQUES

RESPONSE

type ref to IF_HTTP_RESPONSE

The response obje IF_HTTP_RESPON

PAGE PAGE_CONTEXT

type ref to IF_BSP_PAGE type ref to IF_BSP_PAGE_CONTEXT

Page object is defin IF_BSP_PAGE.

Page context objec IF_BSP_PAGE_CO

Example
BSP only with Layout

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 OnCreate Description OnCreate is called once when the page is first created (stateful mode), and performs a once-off data initialization or object creation. 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. 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. 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. You can use this event handler to manipulate the HTTP data stream later. This event handler is available for special functions.

OnRequest

OnInitialization

OnInputProcessing

OnManipulation OnDestroy

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

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

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) SAP SAP Value in OnInputProcessing Explicit Transfer Value in OnInitialization

automatic automatic Non-automatic

SAP SAP SAP

No Yes No

SAP SAP SAP

Non-automatic

SAP

Yes

SAP

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) SAP SAP Value in OnInputProcessing Explicit Transfer Value in OnInitialization

automatic automatic Non-automatic Non-automatic

SAP SAP SAP SAP

No Yes No Yes SAP

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) SAP SAP Value in OnInputProcessing Explicit Transfer Value in OnInitialization

automatic automatic Non-automatic Non-automatic

SAP SAP SAP SAP

No Yes No Yes SAP

Type Definitions
You can create type definitions for pages with flow logic. Type definitions are not available for views, however. If you want to use a page attribute that should only be used within a page and in the different methods of the page (event handler and layout), you can create a local type for this. Type definitions are therefore local types visible in all event handlers of a BSP and the BSP itself. Type definitions are also relevant when BAPIs are used (see BAPI Explorer). In the page editor, you call the BAPI browser through which you cut & paste the type definitions and a template for the requested BAPI call to the Type Definition and Event Handler tabs in your BSP.

You define local types only for those objects that are necessary within a BSP for the processing process. Types that are used several times or that can be implemented universally should be defined in the Data Dictionary.

BSP Directives
Overview
BSP directives are enclosed in tags: <% Directive %> The directives described in the following sections are supported by Business Server Pages (BSP). The syntax is compatible with the familiar server page technology. The following BSP directives are available: Page Directive Inline Code Comments Include Directive OTR Directives Extension Directive

You use the Tag Library to add BSP directives to your code using Drag & Drop. For more information see Transferring Variables.

Special Programming Features

The following code sections for the layout of a BSP are not equivalent: <% read table itab index lv_index. %> <% if sy-subrc ne 0. clear workarea. endif. %> and: <% read table itab index lv_index. if sy-subrc ne 0. clear workarea. endif. %> The first code extract above contains a function module call between the two ABAP commands. The second code extract does not: .... * BSP SCRIPT source read table itab index lv_index. * BSP STATIC source * HTML begin: #### ###### CALL METHOD %_IF_PM->ADD_STATIC_REF exporting encoding = 0 source = %_HTML_POOL offset = 0000018407 length = 0000000039 .

* BSP SCRIPT source if sy-subrc ne 0. clear workarea. endif. .... This means that the sy-subrc set when the internal table is read is overwritten by the function module call. The two pieces of code therefore behave differently.

Control Flow of BSPs

Overview
The control flow of a page is displayed in the following graphic:

You do not have to use all event handlers, for example a BSP can consist of just the layout, or it only contains the layout, OnInitialization and OnInputProcessing. Since event handler OnDestroy is used infrequently, it is irrelevant here. The following cases should be distinguished: stateless BSPs stateful BSPs

See also:

Interface IF_BSP_PAGE

Stateless
In the stateless case, the context is created each time that a request is received. The context is always destroyed when the response is sent. For the BSP runtime stateless means: runtime->keep_context = 0 When creating the output of a page, processing is the same as described in the following graphic. Output of a BSP (Stateless)

When creating the input for a page, processing is the same as described in the following graphic. Input for a BSP (Stateless)

With stateless BSPs (the default is stateless), the navigation can be executed either on the same page or on other pages.

Navigation Within the BSP

When the page is called, the system first checks if there is already a page object for this BSP. If this is not the case, the event handler OnCreate runs, which creates the page object or an instance of it. The event handler OnRequest then follows. If a page object already exists (in general, this does not happen with the first call, just as little as in stateless BSPs), the system branches directly to the event handler OnRequest. There then follows either OnInitialization, if there is no user interaction, and OnInputProcessing if there is user interaction. From OnInputProcessing, there is no further navigation to OnInitialization. Processing continues with the layout and then possibly with OnManipulation, although this event handler is used infrequently. The requested page is then displayed in the browser. User action can now take place, and then processing begins again.

Navigating to Other BSPs

The processing process is very similar to when you navigate within a BSP. If you now navigate from the OnRequest to a different page, event handler OnInputProcessing is called and evaluated. The follows OnInitialization, and then the layout and so on.

Stateful
In the stateful case, the context is held by gone request to the next. For the BSP runtime stateful means: runtime->keep_context = 1 When creating the output of a page, processing is the same as described in the following graphic. Output of a BSP (Stateful)

When creating the input for a page, processing is the same as described in the following graphic. Input for a BSP (Stateful)

With stateful BSPs, there can be three different variants of lifetime: Up to the page change (lifetime_page) The page is destroyed if a different page is used. For the duration of the request (lifetime_request) The page is destroyed after each individual request, that is, is only available for the duration of each request. For the duration of the session (lifetime_session) The page is destroyed at the end of the session.

Examples
BSP only with Layout BSP with Layout and Initialization BSPs with Layout, Initialization and Navigation BSPs with Layout, Initialization and Input Processing

Classes and Interfaces

The following classes and interfaces are central components of the BSP programming model. Classes:
Class CL_BSP_APPLICATION

 Class CL_BSP_MESSAGES Class CL_BSP_SERVER_SIDE_COOKIE Class CL_BSP_GET_TEXT_BY_ALIAS Class CL_BSP_CONTROLLER2

Interfaces:
Interface IF_BSP_APPLICATION Interface IF_BSP_APPLICATION_EVENTS Interface IF_BSP_NAVIGATION Interface IF_BSP_PAGE Interface IF_BSP_RUNTIME Interface IF_BSP_PAGE_CONTEXT Interface IF_HTMLB_TABLEVIEW_ITERATOR

Many of these classes and interfaces are the basis for their associated global objects.

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 Example: in the Web Application Builder.

BSP Extensions
Introduction
The BSP programming model, which is based on the server pages technology, provides developers with additional scope regarding the HTML coding that they can create, from an empty page right up to complex applications. However, repeatedly creating complex HTML coding is often a lengthy process that can easily result in errors. For example, a simple HTML pushbutton can be implemented thus: <input id=btn type=submit>: If you now start to use additional styles and other attributes for the size and the status of the button, the original simple HTML coding becomes considerably more complex and unclear. An abstraction technology can be used here to express more simply both the syntax and the semantics of a specific section of HTML coding. This mechanism is structured so that it can also be used by other types of BSPs, XML, WML and so on. This technology is known as BSP extensions. A BSP extension contains a collection of BSP elements. In the BSP context, each element is assigned to an ABAP class to represent the element functionality, which the generation of the HTML coding usually contains. Defining the elements and mapping them to the ABAP classes is so flexible that you can use this technology to solve many additional problems and difficulties. SAP provides an infrastructure that developers can use to implement BSP extensions within BSP applications. SAP delivers a set of predefined extensions, such as HTML Business for BSP (HTMLB), XHTMLB and PHTMLB that are available and can be used in every SAP Web Application Server 6.20 system. You can also define your own extensions to meet specific requirements. You can create these using an editor integrated in the development environment (transaction SE80). You include an extension in a BSP using the extension directive.

For more information see Creating Your Own BSP Extensions.

You can also create composite elements in order to facilitate layout changes with complicated BSP applications.

BSP Extensions and BSP Elements

Each BSP extension consists of a collection of BSP elements. Each element has specific attributes and is assigned to an ABAP class. The usual notation for XML elements is used when elements are written to BSPs. The attributes available in the element are used as input parameters for the ABAP class that is assigned to the element.
You can define a simple pushbutton on a BSP as follows: <htmlb:button id=btn1 text=Hit Me! /> Here htmlb is the XML namespace, button is the element and id and text are attributes. When the BSP compiler sees the element, it generates the following pseudocode. data: btn1 type ref to CL_HTMLBL_BUTTON. create object btn1. btn1->writer = current_output_writer. btn1->id = btn1. btn1->text = Hit Me!. btn1->begin_tag( ). btn1->end_tag( ). The element class writes the HTML to the HTML output stream based on the functionality that the element provides. This is based on the assumption that all elements in an extension support a common output style.

In the sample pushbutton above, the start tag is followed immediately by the end tag. No body components whatsoever are available or required (by the pushbutton). For other examples, it may be useful to manipulate the body or to process more detailed input.
A typical element, for example, could be an HTML link for creating a small text segment. In this case, the element has a body, which is first rendered in a string and then passed as a parameter to the element for further processing. <htmlb:link id=link1 reference=http://www.sap.com> Homepage of the e-company! </htmlb:link> This results in:

The link element takes the Internet address as the reference. The link element also provides formatting based on the style that is provided by the BSP extension. The body is used as input for the element.

Even if using elements and their resulting ABAP class calls seems to be fairly complex for this type of simple HTML element, using and supporting BSP extensions provides several advantages that should not be underestimated:

The standard XML syntax that is used can be parsed and checked during the BSP compile time. The returned HTML coding need only be generated once (by an expert) in the ABAP element class, thereby ensuring that the coding is correct. The element class can contain additional logic for generating browser-dependent HTML code. The HTML coding that is generated contains correct references to the style sheets that are available.

In addition to a BSP extension for standard HTML elements such as pushbuttons, input fields, dropdown lists and so on, you can also implement highly specialized extensions.
For example, you could develop an extension to map a companys corporate identity to an HTML page. In this case, the users coding for this extension, for example, could be as follows: <%@extension name=SAP_Corporate_Identity_Extension prefix=corp %> <corp:logo/> <corp:stock_ticker/> This could look as follows on the HTML page:

Examples
The system contains various examples of BSP applications that use BSP extensions. You can find simple examples of using BSP extensions HTMLB, XHTMLB and PHTMLB in the BSP applications SBSPEXT_HTMLB, SBSPEXT_XHTMLB and SBSPEXT_PHTMLB, and further examples in BSP extension HTMLB_SAMPLES. The following sections provide two simple examples of the HTMLB elements button and tableView: Button TableView

Button
You can find this example in the system under BSP application SBSPEXT_HTMLB, page button.bsp (package SBSPEXT_HTMLB).

Layout
<%@page language="abap"%> <%@ extension name="htmlb" prefix="htmlb"%>

<htmlb:content> <htmlb:page title = "BSP Extension: HTMLB / Element: Button"> <htmlb:form>

<htmlb:button id

= "myButton1"

text = "standard" />

<br><br>

<htmlb:button id

= "myButton2"

text = "Emphasized button" tooltip = "button quick info: Please click me" onClick = "MyButtonClick" design = "emphasized" />

<br><br>

<htmlb:button id

= "myButton3"

text = "Small button with fixed size " tooltip = "button tooltip: Please click me" onClientClick = "alert('myButton3 Clicked')" design = "small"

width = "300" />

</htmlb:form> </htmlb:page> </htmlb:content>

OnInputProcessing
CLASS CL_HTMLB_MANAGER DEFINITION LOAD.

* Optional: test that this is an event from HTMLB library. IF event_id = CL_HTMLB_MANAGER=>EVENT_ID.

* Scenario 1: Read event from manager. DATA: event TYPE REF TO CL_HTMLB_EVENT. event = CL_HTMLB_MANAGER=>get_event( runtime->server->request ).

IF event->name = 'button' AND event->event_type = 'click'. DATA: button_event TYPE REF TO CL_HTMLB_EVENT_BUTTON. button_event ?= event. ENDIF.

* Scenario 2: Dispatch event directly onto event class DATA: event_handler TYPE REF TO CL_HTMLB_EVENT_EXAMPLE.

CREATE OBJECT event_handler. CL_HTMLB_MANAGER=>dispatch_event( request = runtime->server->request event_handler = event_handler page_context = page_context ).

ENDIF.

Output

TableView
You can find this example in the system under BSP application SBSPEXT_HTMLB, page TableView.bsp (package SBSPEXT_HTMLB).

Layout
<%@page language="abap"%> <%@ extension name="htmlb" prefix="htmlb"%> <htmlb:content> <htmlb:page title = "BSP Extension: HTMLB / Element: tableView"> <htmlb:form> <htmlb:tableView id = "tv1" headerText = "Connections" headerVisible = "true" design = "alternating" visibleRowCount = "8" fillUpEmptyRows = "true" onHeaderClick = "MyEventHeaderClick" onRowSelection = "MyEventRowSelection"

selectionMode = "multiselect" table = "<%=sflight%>" > <htmlb:tableViewColumns> <htmlb:tableViewColumn columnName = "carrid" wrapping = "true" width = "100" onCellClick = "MyCellClickCarrid__" horizontalAlignment="center" title = "&nbsp;" type = "user" > <htmlb:textView id="$TVCID$" text = "$TVCVALUE$" design = "LABELSMALL" layout = "PARAGRAPH" required = "TRUE" width = "100%" tooltip = "$CARRNAME$" encode = "FALSE" wrapping = "TRUE" /> </htmlb:tableViewColumn> <htmlb:tableViewColumn columnName = "myicon" type = "user" title = "Image" horizontalAlignment="center" > <htmlb:link id = "$TVCID$" onClick = "$CARRNAME$" tooltip = "$CARRNAME$"> <htmlb:image src = "$TVCVALUE$" alt = "$TVCVALUE$" tooltip = "$CARRNAME$" /> </htmlb:link> </htmlb:tableViewColumn> <htmlb:tableViewColumn columnName = "myinputfield" type = "user" title = "Input Field" cellInvalidKey = "invalid" cellDisabledKey = "disabled" horizontalAlignment="center" > <htmlb:inputField id = "$TVCID$" width = "100%" value = "$myinputfield$" type = "Date" showHelp = "true" firstDayOfWeek = "2" /> </htmlb:tableViewColumn> <htmlb:tableViewColumn columnName = "mybutton" type = "button"

title = "Button" cellDesignKey = "design" onItemClick = "MyButton__" horizontalAlignment="center" /> <htmlb:tableViewColumn columnName = "fldate" onCellClick = "MyCellClickFldate__" title = "Datum" wrapping = "true" width = "100" horizontalAlignment="center" /> <htmlb:tableViewColumn columnName = "DDLKEY" title = "User defined: List Box" type = "user" > <htmlb:dropdownListBox id = "$TVCID$" table = "<%=sflight%>" nameOfKeyColumn = "DDLKEY" nameOfValueColumn = "CARRNAME" /> </htmlb:tableViewColumn> <htmlb:tableViewColumn columnName = "linktextid" title = "Link" type = "link" linkColumnKey = "linkcarrid" linkClickTarget = "_blank"/> <htmlb:tableViewColumn columnName="linkstextid" onItemClick = "MyLink__" title = "Link with Handler" type = "link" linkColumnKey = "linkcarrid"/> <htmlb:tableViewColumn columnName="linkid" horizontalAlignment = "center" type = "imagelink" linkColumnKey = "linkcarrid" linkClickTarget = "_blank" title = "ImageLink" /> </htmlb:tableViewColumns> </htmlb:tableView> </htmlb:form> </htmlb:page> </htmlb:content>

Attributes
Attribute rowSelection rowSelectionEvent sflight Auto Typing Type TYPE TYPE TYPE Reference Type STRING STRING MYSFLIGHT

OnInitialization
* event handler for data retrieval data: wa like line of sflight, name type string, value type string, str type string, scol type string, srow type string, id type string, mod type i, sytabix type sytabix, sflightlink type table of sflightlink. field-symbols: <wa> like line of sflight, <waLink> type sflightlink. select * from sflight into corresponding fields of table sflight. select * from sflightlink into table sflightlink.

loop at sflight assigning <wa>. sytabix = sy-tabix. read table sflightlink assigning <waLink> with key carrid = <wa>-carrid. <wa>-LINKCARRID = <waLink>-HTTPLINK.

<wa>-linktextid = <waLink>-CARRNAME. <wa>-linkstextid = <waLink>-CARRNAME. <wa>-myinputfield = sy-cdate. "<wa>-FLDATE <wa>-mybutton = <waLink>-CARRNAME. <wa>-FLOATT = 2000000. str = <wa>-FLDATE. concatenate <wa>-CARRID <wa>-CONNID str into <wa>-DDLKEY. str = page->to_string( value = <wa>-FLDATE ). concatenate <waLink>-CARRNAME ' (' <wa>-CONNID '/' str ')' into <wa>CARRNAME. if <wa>-carrid eq 'AA'. <wa>-linkid = '../HTMLB_SAMPLES/aa.gif'. else. concatenate '../HTMLB_SAMPLES/' <waLink>-CARRNAME '.gif' into <wa>-linkid. endif. mod = sytabix mod 8. case mod. when 0. <wa>-myicon = 'ICON_WF_WORKITEM_READY'. when 1. <wa>-myicon = 'ICON_WF_WORKITEM_RESERVED'. when 2. <wa>-myicon = 'ICON_WF_WORKITEM_STARTED'. when 3. <wa>-myicon = 'ICON_WF_WORKITEM_COMMITTED'. when 4. <wa>-myicon = 'ICON_WF_WORKITEM_WAITING'. when 5. <wa>-myicon = 'ICON_WF_WORKITEM_COMPLETED'.

when 6. <wa>-myicon = 'ICON_WF_WORKITEM_ERROR'. when 7. <wa>-myicon = 'ICON_WF_WORKITEM_CANCEL'. endcase. mod = sytabix mod 5. case mod. when 0. <wa>-invalid = 'X'. <wa>-disabled = 'X'. when 1. <wa>-disabled = 'X'. when 2. <wa>-invalid = 'X'. endcase. mod = sytabix mod 3. case mod. when 0. <wa>-design = 'STANDARD'. when 1. <wa>-design = 'EMPHASIZED'. when 2. <wa>-design = 'SMALL'. endcase. endloop.

OnInputProcessing
* event handler for checking and processing user input and * for defining navigation

CLASS CL_HTMLB_MANAGER DEFINITION LOAD.

* Optional: test that this is an event from HTMLB library. IF event_id = CL_HTMLB_MANAGER=>EVENT_ID.

* Scenario 1: Read event from manager. DATA: event TYPE REF TO CL_HTMLB_EVENT. event = CL_HTMLB_MANAGER=>get_event( runtime->server->request ).

IF event->name = 'tableView'. DATA: tableview_event TYPE REF TO CL_HTMLB_EVENT_TABLEVIEW. tableview_event ?= event. ENDIF.

* Scenario 2: Dispatch event directly onto event class DATA: event_handler TYPE REF TO CL_HTMLB_EVENT_EXAMPLE. CREATE OBJECT event_handler. CL_HTMLB_MANAGER=>dispatch_event( request = runtime->server->request event_handler = event_handler page_context = page_context ).

ENDIF.

Output

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. 2. 3. 4. 5.

Creating a BSP Extension Defining the Corresponding BSP Elements Implementing the Element Handler Class Activating the BSP Extension Entering Documentation

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 1. 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.

4. 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

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 must be defined whenever the BSP element is used in a BSP page. 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. 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.

Dynamic value allowed

Pass by reference

Kind of typing

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

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. Here you enter an explanatory attribute description.

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

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.

Procedure
1. Choose the required BSP extension from the object list. 2. Select the Activate function from the context menu or through the respective the application toolbar. icon in

The system displays a list of all inactive objects. The selected BSP extension is marked.

3. 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.

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

3. Creating further methods or attributes that enhance the element functions

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.

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. 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. 2. 3. 4.

Choose the Layout view for the required BSP page. Switch to Change mode. Click the switch button Tag Browser in the navigation area of the Object Navigator. 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.

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 for text design width <ui:inputField type value size design <ui:button text id id = "myLabel" = "carrier" = "Airline" = "LABEL" = "65" /> = "carrier" = "String" = "<%=carrier%>" = "3" = "standard" /> = "myButton" = "Find Flights"

onClick = "FIND" design <br><br> = "STANDARD" />

<ui:tableView id table

= "myTable" = "<%=flights%>"

headerVisible = "true" footerVisible = "true" fillUpEmptyRows= "true" selectionMode = "MULTISELECT" design </ui:form> </ui:page> </ui:content> Note on the prefix: The BSP extension HTMLB is imported into the BSP page through the extension directive (2nd 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). = "ALTERNATING" />

Composite Elements
Use
When you create BSP applications with BSP extensions, it may not be easy to use elements that are essentially simple BSP elements. To generate the layout you require, you often need a number of special elements. In such cases, you can create composite BSP elements to facilitate handling several special elements, and to minimize the amount of work required to develop BSP applications and their layouts. The following uses a complex, typical task to display possible solutions. A simple BSP extension is presented and implemented.

Although the example is restricted to three simple input fields, the composite element solution is intended for cases where a number of variable input fields should be displayed, including labels and tableformat displays.

Task Three input fields with labels should be displayed on a screen. Users should enter their name, password and e-mail address in these input fields. The three fields should be arranged under each other. You should use BSP extension HTMLB to solve this task, with the following predefined layout elements: <htmlb:gridLayout> <htmlb:label> <htmlb:inputField>

Process 1. Create a test BSP application. 2. First use the already existing BSP extension HTMLB on page before.htm. 3. Then create the composite element and use it on page after.htm.

Integration
Composite BSP elements use other, already existing BSP elements to generate the output within the layout framework by including and wrapping the BSP elements that already exist.

Prerequisites
You already understand the concept of BSP extensions and their implementation.

Activities
Create page before.htm Design solution Create a new BSP extension with elements Create page after.htm Dynamically process BSP elements Create a new BSP extension with composite elements Step 1 a) Implement <sf:SimpleFormItem> Step 1 b) Use <htmlb:SimpleFormItem> Step 2: Create <sf:SimpleForm> Step 3: Changes to the Look and Feel

Design Solution
After analyzing the page before.htm, you need a set of elements that are easy to use and which can be used for the outlined task area. As a result, this is not a universal solution, but a solution for a clearly delimited application area. Starting with the example, the initial situation is as follows: All row and index counters are calculated automatically All values for the layout (such as width, style, and so on) are hard-coded

Elements <htmlb:label> and <htmlb:inputField> are linked to each other. The flexibility of the <htmlb:inputField> is still available, so that you can carry out functions such as password handling without any problems

The format of the layout can be specified with BSP elements as follows: <sf:SimpleForm id = "sf" > <sf:SimpleFormItem id = "name" label = "Name:" value = "<%=name%>" />

<sf:SimpleFormItem id = "password" label = "Password:" value = "<%=password%>" password = "TRUE" /> <sf:SimpleFormItem id = "email" label = "Email:" value = "<%=email%>" /> </sf:SimpleForm> Here you require a new BSP extension, which contains all of the necessary elements. You also need a test page, of course. Finally, you also need to implement the elements.

Procedure
The following describes the procedure for implementing this solution:

1. Create the new BSP extension

2. Create the elements for the new BSP extension

a. Element <SimpleForm> b. Element <SimpleFormItem>

1. Generate your new BSP extension 2. Create the page after.htm 3. Specify that the BSP elements are processed dynamically