Programming Model in BSP

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 as is a classic SAP R/3 transaction. Instead of being displayed using SAP GUI, these applications are displayed in a Web browser or a mobile device browser, such as a WAP cell phone. HTTP or HTTPS is used to access the application across the network, which means that standard products like firewalls and proxy servers can be used. 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, How to call an existing BSP application from a Web browser, see Accessing a BSP Application How to start and end 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
Tutorials
The following tutorials are available: 1. First tutorial: Getting Started with Business Server Pages 2. Second tutorial: A Simple BSP Application and A Sample BSP Application with HTMLB 3. Third tutorial: Online Bookshop 4. Fourth tutorial: Further Developing the Online Bookshop 5. A small tutorial is also available for getting started with the Model View Controller (MVC) Design Pattern. 6. A more comprehensive MVC tutorial based on the third tutorial: Our Online Bookshop Using MVC and HTMLB
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: Controllers 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 reponse 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: o 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. o View
Views are used to visualize data, see also Model View Controller (MVC). o 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 include directive (see Include Directive). Navigation structure 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. The application class is implemented using a global ABAP class. This global class implements access to business data, for example, via BAPI calls. 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. o Theme A theme is a container for MIME objects. These MIME objects can be used to modify the appearance of one or more BSP applications after the application has been created. You can replace every MIME object in your application with another object from the file system. A theme is created as an independent development object in the Web Application Builder. A theme can be assigned to BSP applications in order to redefine style sheets and MIMEs in the pages of a BSP application after they have been created. The theme concept is a powerful tool for easily changing the layout of your pages in accordance with your needs, without the need for modifying the layout source code. See also: See also: Tailoring Layouts to BSP Applications
Accessing a BSP Application Starting and Ending a BSP Application Building a BSP
Accessing a BSP Application

As we have already explained, you access a BSP application 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. For additional information about activating services, see Activating and Deactivating an ICF Service and Note 517484. As part of automatically creating the corresponding node in the service tree, the node is also activated only in the case of BSP applications that are newly created for SAP Web AS 6.20. 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> The protocol Prot is http or https (if configured). Host is the name of the application server that should execute the application. Domain and the Extension comprises several hosts under a common name, although they can either be made up 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 (see also Creating BSP Applications). 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). Otherwise, the BSP runtime environment returns an error. The full domain must be specified as otherwise there may be problems with HTTP cookies (such as Single Sign On). If the BSP that you start using Transaction SE80 contains a shortened URL (it does not specify the host name), then 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 within the SAP development environment, look on the Properties tab at the right side of the SAP GUI screen.
Example of page default.htm of BSP application IT00:
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 if it is not running already. To be compatible with the Internet Transaction Server (ITS), the following abbreviated format is supported, whereby the page name is replaced by an exclamation mark (!):
http://myServer.sap.corp:1080/sap/bc/bsp/sap/it00/!
This is the same as the following URL:

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?sapsessioncmd=open
or
http://myServer.sap.corp:1080/sap/bc/bsp/sap/it00/!
1. Ending the application externally:

http://myServer.sap.corp:1080/sap/bc/bsp/sap/it00?sapsessioncmd=close&sap-exiturl=http%3a%2f%2fwww.sap.com
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 sap-sessioncmd Value open: Description Restarts the BSP application named in the URL
close:
Ends the BSP application named in the URL and sends the browser, if specified, to the Web site defined by sap-exiturl. 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. 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-exiturl sap-theme sap-themeRoot
* * *
sap-client
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. For SAP Enterprise Portal 6, both DESIGN2002 and DESIGN2003 are supported.
sap-htmlb-design
sap-domainRelax sap-accessibility
off | min | max X|
Maximum domain relaxing, see also Domain Relaxing Specification for the accessibility See also SYSTEM_PUBLIC and Configuration Settings. To activate this indicator, an activated checkbox is placed on the logon screen for input help.
The parameter names are not case sensitive, nor are the parameter values (exception: sapexiturl, if it is pointed 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 creating BSP applications, see the various tutorials (Creating Web Applications with BSPs) and the documentation on Web Application Builder, specifically 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). From SAP Web AS 6.20, when you create a BSP application in the Web Application Builder, this type of node is created and activated in the appropriate part of the ICF service tree (see also Creating an ICF Service). If necessary, you can add permissions for this node (see also Service Options). 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 can include a multitude 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 the developers wants. The application class is usually used to store data and make it available across BSP pages. This data is stored as attributes. In addition, the application class 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. It is an optional way for you to structure your BSP application. You use the Web Application Builder in transaction SE80 to 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. For an example of the use of an application class, see Extending the Online Bookshop. 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 objects 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 requirement for an application is that the constructor is parameter-less. If not, the application class cannot be generically instantiated by the BSP runtime environment. Otherwise 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). IF_BSP_APPLICATION_EVENTS~ON_STOP This method is called by the BSP runtime environment when the corresponding BSP application is explicitly ended. This applies to both stateless and stateful applications.
Please note that this time point is not available after every request in stateless BSP applications. In addition this time is not evaluated if the session is implicitly terminated by a timeout. Consequently, in this method it is only possible to execute optional operations that are not 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 client- or server-side cookies in a previous request. IF_BSP_APPLICATION_EVENTS~ON_RESPONSE This method is called by the BSP runtime for every outgoing response of a BSP after the BSP has been processed (after the OnManipulationevent handler). 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_EVENTS in the reference documentation: Interface IF_BSP_APPLICATION_EVENTS
Application Basis 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 details of basis 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 refers to the individual application or application class specified in the BSP application. If there is no application class in the BSP application, this means object application is not available. runtime object is defined in interface IF_BSP_RUNTIME . request object is defined in interface IF_HTTP_REQUEST. response object is defined in interface IF_HTTP_RESPONSE. Page object is defined in interface IF_BSP_PAGE.
RUNTIME REQUEST
type ref to IF_BSP_RUNTIME type ref to IF_HTTP_REQUEST
RESPONSE
type ref to IF_HTTP_RESPONSE
PAGE PAGE_CONTEXT
type ref to IF_BSP_PAGE
type ref to IF_BSP_PAGE_CONTEXT Page context object is defined in interface IF_BSP_PAGE_CONTEXT.
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
OnCreate
Use
OnCreate is used when a page is called for the first time, and performs a once-off data initialization or object creation. OnCreate is called each time that the BSP page class is created. You can therefore initialize the page object (in object-oriented thought, this corresponds to the constructor). OnCreate initializes the parts of the object that are created once and then used for the entire lifetime of the object, such as the online shopping basket. create object shopbasket. The data that is used to fill the object is read in the event handler OnInitialization The BSP application is called in the following cases: Single call, if the BSP application is staeful. In this case, the the normal ABAP OO constructor. Call each time if the BSP page class is created in the stateless case.
The opposite of OnCreate is OnDestroy.
Integration
OnCreate is useful mainly in stateful applications, because in stateless mode, the page object is reinitialized every time the page is called. In you are working in stateful mode without an explicit navigation path, and if you run the page a second time (reuse the page), the page instance remains constant. OnCreate is not run the second time. See also: Stateful and Stateless BSP Applications
Functions
You can access the following objects in the implementation: Object APPLICATION Reference Type type ref to application class Description Application class refers to the individual application or application class specified in the
BSP application. If there is no application class in the BSP application, this means that the object application is not available. RUNTIME PAGE PAGE_CONTEXT type ref to IF_BSP_RUNTIME type ref to IF_BSP_PAGE type ref to IF_BSP_PAGE_CONTEXT The runtime object is defined in interface IF_BSP_RUNTIME . Page object is defined in interface IF_BSP_PAGE. Page context object is defined in interface IF_BSP_PAGE_CONTEXT.
OnRequest
Use
OnRequest is run when a request comes to access the current page. This request can be made in the following ways: The URL is entered in the browser. In this case, OnInitialization is run after OnRequest. The user inputs data on a page (current page or other pages). In this case, OnInputProcessing is run after OnRequest.
See also: Event Handlers
Integration
OnRequest is the second handler (after OnCreate) to be called when a BSP is being processed. The only exception to this occurs when a page is recalled in stateful mode without explicit navigation. In this case, OnCreate is skipped and OnRequest is called straight away.
Functions
You can access the following objects in the implementation: Object APPLICATION Reference Type type ref to application class Description Application class refers to the individual application or application class specified in the BSP application. If there is no application class in the BSP application, this means that the
object application is not available. RUNTIME REQUEST type ref to IF_BSP_RUNTIME type ref to IF_HTTP_REQUEST The runtime object is defined in interface IF_BSP_RUNTIME . The request object is defined in interface IF_HTTP_REQUEST.
EVENT_ID NAVIGATION PAGE PAGE_CONTEX T
type STRING type ref to IF_BSP_NAVIGATION type ref to IF_BSP_PAGE type ref to IF_BSP_PAGE_CONTEXT The navigation object is defined in interface IF_BSP_NAVIGATION. Page object is defined in interface IF_BSP_PAGE. Page context object is defined in interface IF_BSP_PAGE_CONTEXT.
Example
Persistency of Data Using Serverside Cookies
OnInitialization
Use
This event handler is processed directly after OnRequest during page processing. This handler implements data retrieval. The data is stored in page attributes and is therefore accessible in the layout and in the other event handlers.
Integration
While the event handler OnCreate is used to initialize objects needed for entire page, OnInitialization is used for getting data from database tables. If you develop a BSP for managing a shopping basket, the shopping basket object is initialized using OnCreate and then filled with selected products. Here, this would be the catalog ID and the number of objects. You use OnInitialization to read the short texts from the database, calculate the current subtotal, and so on.
Functions
You can access the following objects in the implementation:
Object APPLICATION
Reference Type type ref to application class
Description Application class refers to the individual application or application class specified in the BSP application. If there is no application class in the BSP application, this means that the object application is not available. The runtime object is defined in interface IF_BSP_RUNTIME . The request object is defined in interface IF_HTTP_REQUEST. The response object is defined in interface IF_HTTP_RESPONSE. The navigation object is defined in interface IF_BSP_NAVIGATION. Page object is defined in interface IF_BSP_PAGE. Page context object is defined in interface IF_BSP_PAGE_CONTEXT.
RUNTIME REQUEST
RESPONSE
NAVIGATION PAGE PAGE_CONTEXT
type ref to IF_BSP_NAVIGATION type ref to IF_BSP_PAGE type ref to IF_BSP_PAGE_CONTEXT
Example
BSPs with Layout, Initialization and Navigation
OnManipulation
Use
This event handler is processed after the WCF controls embedded in the page are generated.
You can use OnManipulation to manipulate the HTTP data stream again (in particular for XSLT processing).
Functions
You can access the following objects in the implementation: Object APPLICATION Reference Type type ref to application class Description Application class refers to the individual application or application class specified in the BSP application. If there is no application class in the BSP application, this means that the object application is not available. The runtime object is defined in interface IF_BSP_RUNTIME . The request object is defined in interface IF_HTTP_REQUEST. The response object is defined in interface IF_HTTP_RESPONSE. Page object is defined in interface IF_BSP_PAGE. Page context object is defined in interface IF_BSP_PAGE_CONTEXT.
RUNTIME REQUEST
RESPONSE
PAGE PAGE_CONTEXT
type ref to IF_BSP_PAGE type ref to IF_BSP_PAGE_CONTEXT
Example
Persistency of Data Using Serverside Cookies
OnDestroy
Use
This event handler runs immediately before the page instance is deleted and is therefore the exact opposite of OnCreate. You can use it to execute closing actions for a page.
Since locks and so on are reset in ABAP, this event handler is not usually required and is therefore rarely used. With stateful processing, the event handler OnDestroy is not called in every request-response cycle and the page object is not destroyed. OnDestroy is only called right at the end when you switch back to stateless processing. With stateless processing, both OnCreate and OnDestroy are called for every request-response cycle. This event handler is therefore called in very rare cases, for example if an application is stateful and the controllers lifetime is shorter. The system then explicitly destroys the controller and calls the corresponding method.
Object APPLICATION
Reference Type type ref to application class
Description Application class refers to the individual application or application class specified in the BSP application. If there is no application class in the BSP application, this means that the object application is not available. The runtime object is defined in interface IF_BSP_RUNTIME . Page object is defined in interface IF_BSP_PAGE. Page context object is defined in interface IF_BSP_PAGE_CONTEXT.
RUNTIME PAGE PAGE_CONTEX T
type ref to IF_BSP_RUNTIME type ref to IF_BSP_PAGE type ref to IF_BSP_PAGE_CONTEXT
You can use this event handler in connection with server-side cookies, for example: Using OnCreate you can load the cookie and then (at the end of the process flow) you use OnDestroy to store it again so that the information held in the cookie does not get lost.
Functions
You can access the following objects in the implementation:
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 Non-automatic
SAP SAP SAP SAP
No Yes No Yes
SAP SAP SAP 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
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
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.
Page Directive
Definition
This directive is used to specify the script language. ABAP and JavaScript are currently supported.
<%@ page language=("ABAP" | "JAVASCRIPT") %>
otrTrim
From SAP Web AS 6.20 Support Package 7, the attribute otrTrim is also available for the page directive.
<%@ page language=("ABAP" | "JAVASCRIPT") otrTrim=("TRUE" | "FALSE") %> This attribute is a boolean value, that is, it can have the values TRUE and FALSE. The default value is FALSE. If it is set to TRUE, all OTR texts on a page are condensed by removing all blank characters from the start and end of a string. An example of switched on attribute (otrTrim=true): <%@page language="abap" otrTrim="true" %> <% DATA: s TYPE STRING VALUE 'test'. %> [<otr> test line </otr>]<br> [<otr> before <%= s%> middle <%= s%> end. </otr>]<br> [<%= otr(sbsp_test/it00_otr_1) %>]
The output generated using this coding then looks as follows: [test line] [before test middle test end.] [This is a test for an alias text]
Example of the case when otrTrim is switched off (otrTrim=false): <%@page language="abap" otrTrim="false" %> <% DATA: s TYPE STRING VALUE 'test'. %> [<otr> test line </otr>]<br> [<otr> before <%= s%> middle <%= s%> end. </otr>]<br> [<%= otr(sbsp_test/it00_otr_1) %>] The output generated using this coding then looks as follows: [ test line ] [ before test middle test end. ] [This is a test for an alias text]
Inline Code
Definition
With this directive you can embed the script code into the page. The inline code is written in the language specified with the Page directive.
<% inline code %>
<%@ page language="javascript"%> <% inline code javascript %>
Comments
Definition
You can write comments on the code on the server. Unlike code that includes HTML comments, server-side comments are not included in the page sent to the client /browser. When you use HTML comments, however, they require longer processing times as well as larger bandwidths. This is why you should not use HTML comments with BSPs or views.
<%-- code comments or text --%>
Include Directive
Definition
With this directive you can paste in existing pages or pages fragments into the page. Enter the URL of the page to be pasted in relative to the URL of the current page.
<%@ include file="relative URL"%>
OTR Directives
Definition
The Online Text Repository (OTR) is a repository for all HTML texts, which are accessed using an alias. OTR texts can be translated into other languages using translation tools. At runtime, the OTR directive is replaced by the text defined for the logon language.
Use
There are two ways of using the OTR. 1. You can first write the text in the OTR and give it an alias that should be as meaningful as possible. Then you can display the text with the following syntax: <%=otr(alias)%>. 2. You can however also specify the text in the page layout: <otr> HTML text, can also contain scripting code </otr> This is an auto-OTR text that is automatically transferred to the OTR and translated there. If the user logs on in a different language, they see the translated text.
The text is only automatically transferred if it was entered in the original language. See also: Internationalization and Translation Online Text Repository (OTR)
Transferring Variables
You can transfer expressions, for example variables, with the following syntax:
Value transfer: object = <%=varname%>
bgcolor = "green" creates a green background by transferring the value green. With bgcolor = "<%=color%>" the current value of the variable color is assigned to the attribute bgcolor.
Extension Directive
Definition
You can use the extension directive to import a BSP extension into your BSP. As a result you can access all elements of the extension in your BSP. The extension directive is always located immediately after the page directive.
<%@extension name="<Name>" prefix="<Prfix>"%> The prefix is used as the namespace for all elements in the BSP extension. The prefixes sap and bsp are reserved. See also: BSP Extensions
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. To develop BSP applications with the focus on representing Web pages on different mobile end devices, you can use interface IF_CLIENT_INFO.
Class CL_BSP_APPLICATION
Overview
Class CL_BSP_APPLICATION is an optional superclass for BSP application classes. Each application has the option of deriving its own application class from CL_BSP_APPLICATION . If the application class has not already been derived in an inheritance hierarchy, we recommend that it is derived from CL_BSP_APPLICATION . Class CL_BSP_APPLICATION has 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.
All of the methods of class CL_BSP_APPLICATION can be accessed via the interface IF_BSP_APPLICATION and are described in the corresponding reference documentation. See Also: IF_BSP_APPLICATION Object application
Class CL_BSP_MESSAGES
Overview
You can use class CL_BSP_MESSAGES in BSPs for outputting error and information messages.
You can flag each message with a condition that serves as a key for the message. The effect of this is that a message is only output in a BSP if the pertinent condition is fulfilled. This makes it easy to place input-specific messages directly beside the relevant input fields. Each BSP has an instance of this class that contains the current messages of the class. The object is reset after every HTTP request/response cycle. The object is accessed from a BSP via the parameter page of the event handler as page->messages or via the self-reference me in the form of interface qualification me->if_bsp_page~messages.
Inheritance Hierarchy/Interface Composition

Implemented Interface
-
Superclass
-
Attributes
Attribute Name co_severity_error co_severity_fatal_error co_severity_info co_severity_success co_severity_warning Declaration Type Constants Constants Constants Constants Constants Description Error severity: error Error severity: Fatal error Error severity: Information Error severity: Confirmation of success Error severity: Warning
Methods
Method add_message
Signature method add_message importing condition type string message type string optional otr_alias type string optional severity type i default co_severity_error . This method inserts the message on the condition specified into the list of messages. If
Description
there is already a message with the condition, it is overwritten. One of the two parameters message or otr_alias must be specified (exclusive or). If message is used, the message text is transferred directly, if otr_alias is used, the alias name of an OTR text is transferred. This makes it easy to address language-dependent messages from the OTR. Parameters CONDITION MESSAGE Message condition Message text (if otr_alias-parameter is not used) Alias name of an OTR text to be used as message text (if message parameter is not used) Message severity (see constants co_severity_...)
OTR_ALIAS
SEVERITY
Return Values/Exceptions Cross References
See also: assert, assert_message, assert_severity
Method assert
Signature method assert importing condition type string returning index type i . This method returns the message index (1..n) for the condition specified or 0 if there is no message for this condition. Thus, you can use this method in BSPs in if statements if, for example, you want to insert HTML areas in the output on a messagedependent basis.
Description
Example: ... <% if page->messages->assert( 'invaliduser' ) <> 0. %> <img src="stop.gif"> <%= page->messages>assert_message( 'invaliduser' ) %> <% endif %> Parameters Return Values/Exceptions CONDITION INDEX Message condition =0: no message for condition >0: Message index Cross References See also: assert_message, assert_severity
Method assert_message
Signature method assert_message importing condition type string returning message type string . This method returns the message for a specified condition. If there is no message for the condition, it returns an empty string. CONDITION MESSAGE Message condition Message
Description
Parameters Return Values/Exceptions Cross References
See also: assert, assert_severity
Method assert_severity
Signature method assert_severity importing condition type string returning severity type i .
Description
This method returns the message severity (see constants co_severity_... ) for the specified condition, or 0 if there is no message for the condition. CONDITION SEVERITY Message condition =0: no message for condition >0: Message severity (see constants co_severity_...)
Parameters Return Values/Exceptions
Cross References
See also: assert, assert_message
Method get_message
Signature method get_message importing index type I exporting severity type I condition type string message type string . This method returns information about the message for the specified index (1..n). If there is no message for the index, in other words, if index > num_messages(), this is indicated by severity = 0 . INDEX message condition severity Message index (1..num_messages()) Message text Message condition Message severity (see constants co_severity_...)
Description
Cross References
See also: add_message, num_messages
Method num_messages
Signature
method num_messages returning count type I . This method returns the number of messages that were defined using add_message(). count See also: add_message Number of currently existing messages
Description
Class CL_BSP_SERVER_SIDE_COOKIE
Overview
Class CL_BSP_SERVER_SIDE_COOKIE provides methods for setting, getting, deleting, and managing cookies on the server. Server-side cookies are persistent data, similar to the usual client-side cookies. However, while on the client-side, there are restrictions that limit the size of cookies to around 4 kilobytes per cookie, the number of cookies to 300 in total and 20 per server or domain, server-side cookies are subject to no such restrictions. A server-side cookie is stored on the database. For technical reasons, each individual cookie can be stored in one of the following ways: as a field or as a structure or as an internal table
When you get a cookie, please note that it must be returned to the same data structure. Otherwise, an error will occur, which you can query using an error method. The parameters username and session_id deserve special attention. Setting username to sy-user is ambiguous in cases where an application is started by an anonymous user stored on the server. It would be better to use session_id (see example) since runtime->session_id indicates the browser session.
When you design an application, you should give careful consideration to whether the application should be stateless and the required context data be retained from page to page in cookies (client-side or server-side), or whether the application should be stateful. A stateful application makes sense when there is a large amount of context data that would otherwise have to be read from or written to the database using cookies and thus slow down performance (see also Stateful or stateless programming?). The program BSP_SHOW_SERVER_COOKIES provides an overview of all of the cookies set in the system. The program BSP_CLEAN_UP_SERVER_COOKIES deletes all expired cookies to the day.
The system administrator should schedule the program BSP_CLEAN_UP_SERVER_COOKIES to run in the background on a regular basis. Class CL_BSP_SERVER_SIDE_COOKIE is contained in the package SBSP_RUNTIME.

-
Superclass
-
Attributes
Attribute Name CC_OK CC_WRONG_DATA_OBJECT Declaration Type Constants Constants Description Action was successful. The data object of the cookie to be read does not match the data object of the set cookie. Call parameters are missing. Cookie does not exist.
CC_PARAMETER_MISSING CC_NOT_EXISTS
Constants Constants
Methods
All of the methods are in the visibility section public section.
Method get_server_cookie
Signature method GET_SERVER_COOKIE exporting NAME EXPIRY_TIME EXPIRY_DATE SESSION_ID USERNAME APPLICATION_NAMESPACE APPLICATION_NAME DATA_NAME DATA_VALUE This method gets a server cookie. EXPIRY_TIME EXPIRY_DATE DATA_NAME SESSION_ID USERNAME APPLICATION_NAMESPACE APPLICATION_NAME NAME DATA_VALUE Validity date (time): to time Validity date (date): to date Data object name Session ID Name of user Name space of BSP application Name of BSP application Name of cookie Data object content
Description Parameters
data: sorders type sales_orders, edate type d, etime type t, usr type string. clear sorders. call method cl_bsp_server_side_cookie=>get_server_cookie
exporting name = 'SALESORDER_GETLIST' application_namespace = runtime>application_namespace application_name = runtime->application_name username = usr session_id = runtime->session_id data_name = 'SORDERS' importing expiry_date = edate expiry_time = etime changing data_value = sorders.
Method delete_server_cookie
Signature method DELETE_SERVER_COOKIE exporting NAME APPLICATION_NAME APPLICATION_NAMESPACE USERNAME SESSION_ID This method deletes a server cookie. NAME APPLICATION_NAME APPLICATION_NAMESPACE USERNAME SESSION_ID Name of cookie Name of BSP application Name space of BSP application Name of user Session ID
data: usr type string. call method cl_bsp_server_side_cookie=>delete_server_cookie exporting name = 'SALESORDER_GETLIST' application_namespace = runtime>application_namespace application_name = runtime->application_name username = usr session_id = runtime->session_id.
Method set_server_cookie
Signature method SET_SERVER_COOKIE importing DATA_VALUE exporting EXPIRY_DATE_ABS EXPIRY_TIME_ABS DATA_NAME SESSION_ID USERNAME EXPIRY_TIME_REL EXPIRY_DATE_REL APPLICATION_NAMESPACE APPLICATION_NAME NAME This method sets a server cookie. DATA_VALUE EXPIRY_DATE_ABS EXPIRY_TIME_ABS Data object content Valid to date Absolute validity duration
If you do not specify a value, the system sets the absolute validity duration to 23.59. DATA_NAME SESSION_ID USERNAME EXPIRY_TIME_REL Data object name Session ID if required Name of user, and email address Relative validity duration in seconds
If you do not specify a value, the system sets the relative validity duration to 23.59.
EXPIRY_DATE_REL APPLICATION_NAMESPACE APPLICATION_NAME NAME
Validity duration in days Name space of BSP application Name of BSP application Name of cookie
data: sorders type sales_orders, edate type d, usr type string. call function 'BAPI_SALESORDER_GETLIST' destination 'ABC' exporting customer_number = '0000001000' tables sales_orders = sorders. edate = sy-date. add 1 to edate. "valid for one day
call method cl_bsp_server_side_cookie=>set_server_cookie exporting name = 'SALESORDER_GETLIST' application_namespace = runtime>application_namespace application_name = runtime->application_name username = usr session_id = runtime->session_id expiry_date_abs = edate expiry_time_abs = sy-uzeit data_name = 'SORDERS' data_value = sorders.
Method get_last_error
Signature method GET_LAST_ERROR importing RC This method returns the return code of the last call.
Description
Parameters
RC
Returncode
data: rc type i, txt type string. rc = cl_bsp_server_side_cookie=>get_last_error( ).
Method get_last_error_name
Signature method GET_LAST_ERROR_NAME importing NAME This method returns the internal name of the exception of the last call. NAME Internal error text
data: rc type i, txt type string. rc = cl_bsp_server_side_cookie=>get_last_error( ). if rc ne 0. txt = cl_bsp_server_side_cookie=>get_last_error_name( ). endif.
Method get_server_cookie_info
Signature method GET_SERVER_COOKIE_INFO exporting COOKIES APPLICATION_NAMESPACE APPLICATION_NAME SESSION_ID USERNAME NAME
This method returns information about server cookies. COOCIES APPLICATION_NAMESPACE SESSION_ID USERNAME NAME APPLICATION_NAME List of all cookies. Name space of BSP application Session ID Name of user Name of cookie Name of BSP application
data: usr type string, cookie_info type tsscookiei. call method cl_bsp_server_side_cookie=>get_server_cookie_info exporting application_name = runtime->application_name username = usr importing cookies = cookie_info .
Class CL_BSP_GET_TEXT_BY_ALIAS
Overview
Class CL_BSP_GET_TEXT_BY_ALIAS provides a method to fetch OTR alias texts.

-
Superclass
Attributes
-
Methods
Method GET_TEXT
Signature method GET_TEXT importing LANGUAGE ALIAS returning ALIAS_TEXT. This method fetches an OTR alias text for a specified OTR alias name. LANGUAGE ALIAS Current language of SAP System Name of alias in form <Paket>/<Aliasname> Text of the alias
ALIAS_TEXT Cross References See also:
Internationalization and Translation Method GET_OTR_TEXT of IF_BSP_RUNTIME
report OTRTEST. class CL_BSP_RUNTIME definition load. data TEXT type STRING. TEXT = CL_BSP_RUNTIME=>GET_OTR_TEXT( ALIAS = 'sbsp_test/it00_otr_1' ). write / TEXT.
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. Processing Process 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 DO_HANDLE_DATA DO_HANDLE_EVENT Description Reacts to user input. Processes data input for this component. 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 DO_INIT Description 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 CREATE_VIEW Description Creates or fetches a view instance
Use either the name of the view, or the navigation.
object
A view must always belong to the same BSP application as its controller. CALL_VIEW CREATE_CONTROLLER CALL_CONTROLLER Calls the request handler of the view instance. Creates or fetches a controller instance Calls the request handler (method DO-REQUEST) of the controller instance. Returns the specified page attributes. Generic method for reading an attribute value. Returns the lifetime of this page (only for the top-level controller) Returns the URL of the page or the current controller Sets the specified page attributes. Generic method for setting an attribute value. Changes the lifetime of this page (only for the toplevel controller) Creates a formatted string Writes a formatted string in the output Fetches the current output writer Changes the MIME type of the page or the content type of the header field Instantiates the parameter from the request using the request data Changes the caching values There are two types of caching: Browser cache Server cache
GET_ATTRIBUTE GET_LIFETIME GET_PAGE_URL SET_ATTRIBUTE SET_LIFETIME TO_STRING WRITE GET_OUT SET_MIME_TYPE INSTANTIATE_PARAMETER SET_CACHING
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 SET_MODEL CREATE_MODEL GET_CONTROLLER CONTROLLER_SET_ACTIVE Calculates the ID from the specified ID and the component ID Creates and registers a model instance Creates and registers a model instance Fetches a sub-controller Sets a controller to active/inactive. This is relevant with input processing, since you can use it to hide a controller. See also Lifetime Deletes a model instance Fills the model data Deletes a sub-controller Fetches a model instance Is this controller a top (main) controller (0: no, 1: yes)? Has a controller requested a navigation (0: no, 1: yes)?
DELETE_MODEL FILL_MODEL_DATA DELETE_CONTROLLER GET_MODEL IS_TOPLEVEL IS_NAVIGATION_REQUESTED
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 IF_BSP_DISPATCHER~REGISTER IF_BSP_CONTROLLER~FINISH_INPUT_PROCESSING IF_BSP_CONTROLLER~FILL_VALUES IF_BSP_CONTROLLER~HANDLE_EVENT GET_FIELD_COMPONENT GET_FIELD_MODEL Description Registers a sub-components Processes or dispatches: end of input processing. Processes or dispatches: handling values Processes or dispatches: Handle event Finds components for a field name Finds model for a field name
Methods DO_DESTROY and SUBSCRIBE are not relevant.
Interface IF_BSP_APPLICATION
Overview
The interface IF_BSP_APPLICATION is implemented using class CL_BSP_APPLICATION. It provides methods that enable a BSP application to call up information about its runtime environment or influence this environment.

Implementing Classes
CL_BSP_APPLICATION
Enhanced Interface
Specializing Interfaces
-
Attributes
-
Methods
Method get_application_name
Signature method get_application_name returning name type string . This method returns the name of the BSP application as defined in the development environment (transaction SE80). -
Description
Parameters
Return Values/Exceptions
NAME
Name of the BSP application
Method get_application_namespace
Signature method get_application_namespace returning namespace type string . This method returns the name space of the corresponding BSP application as defined in the development environment (transaction SE80). For BSP applications that have no explicit name space specified, this is the SAP name space, in other words, the method returns "sap".
Description
Parameters
NAMESPACE
Name space of the BSP application
Method get_application_start_page
Signature method get_application_start_page returning start_page type string . This method returns the start page of the corresponding BSP application as defined in the development environment (transaction SE80). If no page was explicitly specified, the method returns the name default.htm. The start page of a BSP application is called if no specific page is included in the URL when the application is started, in other words, when the URL ends with the application name. Parameters -
Description
START_PAGE
Start page of the BSP application
Method get_application_theme
Signature method get_application_theme returning theme type string . This method returns the name of the theme of the BSP application as defined in the development environment (transaction SE80). If there is no theme explicitly associated with the
Description
BSP application, the method returns an empty string (default theme). Themes can be used together with BSP applications to customize the look and feel, see also Layout Adjustments to BSP Applications. Parameters -
THEME
Name of the theme associated with the BSP application
Method get_application_url
Signature method get_application_url returning url type string . This method returns a server-specific URL that references the current BSP application, for example /sap/bc/bsp/sap/retailstore. -
Description
Parameters
URL
Server-specific URL of current BSP application
Method get_request
Signature method get_request returning request type ref to if_http_request . This method returns an interface reference to the current HTTP request object. -
REQUEST
Interface reference to the HTTP request object
Method get_response
Signature method get_response returning request type ref to if_http_response . This method returns an interface reference to the current HTTP response object. -
RESPONSE
Interface reference to the HTTP response object
Method get_runtime
Signature method get_runtime returning runtime type ref to if_bsp_runtime . This method returns an interface reference to the current BSP runtime object. -
RUNTIME
Interface reference to the BSP Runtime Object
Method get_timeout
Signature method get_timeout returning timeout type t .
Description
This method returns the current timeout value (length of time). The timeout value is only important for stateful BSP applications. Stateful applications use this value to determine after what length of time the server should terminate a running application when no further requests are received.
You can set timeout values in Transaction SICF for BSP applications, see also Creating an ICF Service. Parameters -
TIMEOUT
Maximum length of time which a BSP application may continue to run in the absence of requests. After this time the application is automatically terminated.
Cross References
set_timeout
Method is_stateful
Signature method is_stateful returning stateful type i . You can use this method to determine whether a BSP application is working stateful or stateless. -
Description
Parameters
STATEFUL
0: Application is stateless 1: Application is
stateful. Cross References See also: set_stateful, set_stateless
Method set_stateful
Signature Description Parameters Method set_stateful This method sets the BSP application to stateful processing. -
STATEFUL
0: Application is stateless 1: Application is stateful.
Cross References
See also: is_stateful, set_stateless
Method set_stateless
Signature Description Parameters method set_stateless. This method sets the BSP application to stateless processing. -
STATEFUL
0: Application is stateless 1: Application is stateful.
Cross References
See also: is_stateful, set_stateful
Method set_timeout
Signature
method set_timeout importing timeout type t . This method sets the current timeout value (length of time) of the BSP application. The timeout value is only important for stateful BSP applications. Stateful applications use this value to determine after what length of time the server should terminate a running application when no further requests are received.
Description
You can set timeout values in Transaction SICF for BSP applications, see also Creating an ICF Service. Parameters TIMEOUT Maximum length of time which a BSP application may continue to run in the absence of requests. After this time the application is automatically terminated.
See also: get_timeout
Interface IF_BSP_APPLICATION_EVENTS
Overview
The interface IF_BSP_APPLICATION_EVENTS can be implemented by a BSP Application Class if it wants to have control over executing its own functions at specific points in the lifecycle of a BSP application. The possible time points for doing so are at application start and end, and at HTTP Request Input and HTTP Response Output. Typically, these time points are used to carry out authorization checks, data persisting, or data restoration in stateless BSP applications.
Enhanced Interface
-
-
Attributes
-
Methods
Method on_start
Signature method on_start importing runtime type ref to if_bsp_runtime request type ref to if_http_request response type ref to if_http_response . 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). Parameters RUNTIME REQUEST RESPONSE Reference to the BSP runtime Reference to the current HTTP Request Reference to the current HTTP Response
Description
Method on_stop
Signature method on_stop
importing runtime type ref to if_bsp_runtime request type ref to if_http_request response type ref to if_http_response . Description This method is called by the BSP runtime environment when the corresponding BSP application is explicitly ended. This applies to both stateless and stateful applications.
Please note that this time point is not available after every request in stateless BSP applications. Moreover, the time point is not evaluated if the session is implicitly terminated by a timeout. Consequently, in this method it is only possible to execute optional operations that are not critical. Typically, this is a good time for cleanup operations such as deleting browser cookies or server-side cookies, if the application generated them. Parameters RUNTIME REQUEST RESPONSE Reference to the BSP runtime Reference to the current HTTP Request Reference to the current HTTP Response
Method on_request
Signature method on_request importing runtime type ref to if_bsp_runtime request type ref to if_http_request response type ref to if_http_response . This method is called by the BSP runtime
Description
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 client- or server-side cookies in a previous request. Parameters RUNTIME REQUEST RESPONSE Reference to the BSP runtime Reference to the current HTTP Request Reference to the current HTTP Response
Method on_response
Signature method get_parameter importing name type string returning value type string . This method is called by the BSP runtime for every outgoing response of a BSP after the BSP has been processed (after the OnManipulationevent handler). This time can be used by a stateless application class for tasks such as rescuing attributes in client-side or server-side cookies. Parameters RUNTIME REQUEST RESPONSE Reference to the BSP runtime Reference to the current HTTP Request Reference to the current HTTP Response
Description
Interface IF_BSP_NAVIGATION
Overview
The interface IF_BSP_NAVIGATION controls the transition between BSPs in a BSP application. The relevant interface reference is available in all event handlers of a BSP via the parameter NAVIGATION. There are two possible options for navigating between BSPs:
1. In the BSP layout, the subsequent page is addressed directly in the relevant HTML 2.
elements such as <form> or <a>. In the layout of a BSP only the page itself is referenced (for example, in <form> or <a>HTML elements with <%= page->page_name( ) %>) and a page change is triggered (per HTTP Redirect) by means of the navigation object (see also Object navigation) that corresponds to the event. This is the preferred method in BSP applications.
Page control via the navigation interface requires in some cases transfer of arguments to the auto page attributes of the subsequent page. There are methods available for this purpose in the navigation interface.
Please note that the amount of data to be transferred is restricted by Web Browser limitations (typically to 1KB). You should not try to transfer large amounts of data, but rather where possible selection IDs that lead to the data concerned. If this is not possible in every case, you can use the mechanism "AutoSubmit-Forms" as an alternative (see IF_BSP_NAVIGATION~USE_AUTO_SUBMIT_FORM() ). This lifts the data volume restriction. However, we recommend that you do not use this mechanism as a general rule since it causes problems with the browser history and it is not available for all devices (for example, WAP).

CL_BSP_NAVIGATION
Enhanced Interface
-
Attributes
-
Methods
Method call_application
Signature method call_application importing url type string return_url_parameter type string default 'sap-exiturl' return_event_id type string optional . You can use this method to call an external application. The application is accessed via the HTTP Redirect mechanism. You must specify the external application in the parameter URL. There are two prerequisites for returning to the calling application from the external application: 1. The calling application must be implemented accordingly and 2. The required return address must be specified. The current page from which the external application was accessed is taken as the return URL. The parameter return_event_id lets you select an additional event ID that should be triggered on return as the event ID in the onInputProcessing event handler of this BSP. Since we cannot assume that all external applications have the same prerequisites for transferring the return address, you have the option of selecting this in the parameter return_url_parameter as required. The default name is sap-exiturl, whereby BSP applications are able to call each other easily. For ITSbased applications, the address ~exitURL should be used.
Description
Actual navigation is not triggered at this point. It is triggered on return from the BSP event handler! Parameters URL RETURN_EVENT_ID URL of external application Name of the parameter used to transfer the return address/URL to the calling application Event ID used to address the onInputProcessing event handler of the calling page on return from the calling application
RETURN_URL_PARAMETER
Method encode_parameters
Signature method encode_parameters importing encoded type i value 1 . This method controls whether the parameters defined using set_parameter() should be passed uncoded in plaintext as name/value pairs in the query string of the URL, or coded, that is, BASE64-coded as a value of the URL parameter sap-params. Parameters are passed in coded form by default.
Description
Note that we are talking of coded form here, not encrypted Parameters ENCODED 0: Parameter is passed in plaintext as name/value pairs 1: Parameter is BASE64-coded
Method exit
Signature method exit importing exit_url type string optional . This method terminates this BSP application regardless of whether the application is working stateful or stateless. In particular, the event handler if_bsp_application_events~on_stop is triggered if the interface IF_BSP_APPLICATION_EVENTS is implemented by the application class. You can use the optional parameter exit_url to branch to any end page or URL per HTTP Redirect.
Description
Actual navigation is not triggered at this point. It is triggered on return from the BSP event handler! Parameters EXIT_URL URL to which a HTTP Redirect should branch as the "end page".
Method get_parameter
Signature method get_parameter importing name type string returning value type string . This method returns the value of the requested parameter from the navigation object.
Description
Unlike set_parameter(), this method always returns the value as a string. Parameters NAME VALUE Return Values/Exceptions Cross Reference set_parameter Parameter name Parameter value
Method goto_page
Signature method goto_page importing url type string . This method handles navigation to the specified URL. In most cases, this is a relative URL and contains only the name of the subsequent page, for example navigation>goto_page( 'confirm.htm' ). Unlike the method next_page(), here the subsequent page is specified directly.
Description
Actual navigation is not triggered at this point. It is triggered on return from the BSP event handler! Parameters URL URL of the subsequent page, typically a relative URL or only the page name
Return Values/Exceptions Cross Reference
next_page
Method has_parameters
Signature
method has_parameters returning has_parameters type i . This method indicates whether parameters have been set for the current navigation object (0: no, 1: yes). HAS_PARAMETERS 0: No parameters set 1: Parameters set
Description
Cross Reference
set_parameter
Method next_page
Signature method goto_page importing url type string . This method defines the subsequent page by specifying a page exit. You can define page exits of a navigation graph in the development environment (transaction SE80) of a BSP application. When you do so, starting from the current page, you assign a target page via a page exit (that is, a "link" identified by a unique name). Then, for navigating between pages, the subsequent page is not directly defined in ABAP code, an indirection is inserted instead. The name of the page exit is used to determine the subsequent page currently assigned to the page exit. This can be changed easily without having to adapt all of its usages in the code.
Description
Actual navigation is not triggered at this point. It is triggered on return from the BSP event handler! Parameters EXIT Name of page exit in the navigation graph (case-insensitive)
goto_page
Method response_complete
Signature Description Method response_complete You can use this method to indicate to the BSP runtime that no further event handlers/sections should be addressed on return from the BSP event handler in which it was called. On the contrary, the HTTP Response has already been completely generated and can be sent back to the client/browser. This method is typically called in the OnRequest or OnInitialization section of a BSP, when the HTTP Response was generated differently from the OnLayout section (for example, MIME Object from the database or generated XML Output) and was written directly to the HTTP Response object. Calling the OnLayout section would, in such cases, include unwanted output in the response (for example, blanks that are of critical importance in binary document). The call can be suppressed here. Parameters Return Values/Exceptions -
Method set_parameter
Signature method set_parameter importing name type string value type any optional . This method sets the specified parameter for the transfer to the subsequent page. As a rule, the name of the parameter is the same as an auto page attribute of the subsequent page. Otherwise, it can be read on the subsequent page using Request Object and the method
Description
if_http_request~get_form_field(). In certain circumstances, the value of the parameter can be omitted. This would be the case if a form field of the same name was sent in the current request to be passed on to the subsequent page. The parameter value is then simply taken over from the current request and passed to the subsequent page. Since it is possible to transfer any ABAP data types with the exception of references, the parameter VALUE can only be untyped. Parameters NAME VALUE Parameter name Parameter value. If the parameter is not specified; the value of the form field of the same name of the HTTP Request is taken.
get_parameter, has_parameters
Method use_auto_submit_form
Signature method use_auto_submit_form importing target_frame type string optional . With this method, when navigating to a subsequent page, no HTTP redirects can be used, but insread an HTML page is used with an embedded form. The parameters to be transferred are mixed into the form as hidden fields, and the form is automatically returned to the subsequent page (auto submit) after it is received in the browser. Using this method, you can circumnavigate the dataset restrictions with query string parameters. Note however, that auto submit forms can cause problems in the browser history and that this mechanism canot be used with WAP devices, for example.
Description
You can use parameter target_frame to control in which HTML frame (or new browser window) the subsequent page should be displayed. Parameters target_frame Name of frame in which subsequent page is to be displayed. Exception: the parameter type is not allowed.
cx_bsp_inv_param_type
Interface IF_BSP_PAGE Overview

The interface IF_BSP_PAGE gives access to information about a BSP such as the page names, the lifetime, the corresponding BSP application, the URL of the page, and so on. IF_BSP_PAGE is implemented using the class CL_BSP_PAGE, which is the base class of all BSPs. Consequently, the methods and attributes of this interface are indirectly available by inheritance in all BSPs and can be accessed with the appropriate qualification via the interface name (for example "name = if_bsp_page~get_page_name( )."). The interface can also be addressed in all BSP event handlers by means of the parameter page and can be extended to lower application levels if required. In particular, the BSP page attributes can be read and set using the methods get_attribute() and set_attribute().

CL_BSP_PAGE
Enhanced Interface
-
Specialized Interfaces
-
Attributes
Attribute Name co_format_currency co_format_long co_format_lower co_format_none co_format_short co_format_upper lifetime_page lifetime_request lifetime_session messages Declaration Type Constants Constants Constants Constants Constants Constants Constants Constants Constants Instance attribute
Description write()- or to_string()-method: Output as currency write()- or to_string()-method: long output write()- or to_string()-method: output in lower-case letters write()- or to_string()-method: standard formatting write()- or to_string()-method: short output write()- or to_string()-method: output in upper-case letters Page is valid until explicit navigation away from this page Page is only valid for this HTTP Request Page is valid for the complete session (only for stateful BSP applications) Reference to the messages-object of this BSP
Methods
Method get_application
Signature method get_application returning application type ref to object . This method returns the application object for this BSP. If no application class was defined for the BSP application of this page, a zero (0) reference is returned.
-
Description
application Name of the BSP application Application Class of a BSP Application
Method get_application_name
Signature method get_application_name returning name type string . This method returns the name of the BSP application of this page as defined in the development environment (transaction SE80).
-
Description Parameters Return Values/Exceptions Cross References
name -
Name of the BSP application
Method get_application_start_page
Signature method get_application_start_page returning start_page type string . This method returns the start page of the corresponding BSP application as defined in the development environment (transaction SE80). If no page was explicitly specified, the method returns the name default.htm. The start page of a BSP application is called if no specific page is included in the URL when the application is started, in other words, when the URL ends with the application name.
-
Description
start_page -
Start page of the BSP application
Method get_application_theme
Signature method get_application_theme returning theme type string .
This method returns the name of the theme of the BSP application as defined in the development environment (transaction SE80). If there is no theme explicitly associated with the BSP application, the method returns an empty string (default theme). Themes can be implemented in connection with BSP applications for Look & Feel customizing.
Description
theme
Name of the theme associated with the BSP application
Tailoring Layouts to BSP Applications
Method get_application_url
Signature method get_application_url returning url type string .
This method returns a server-specific URL that references the current BSP application, for example /sap/bc/bsp/sap/retailstore. -
url
-
Server-specific URL of current BSP application
Method get_attribute
Signature method get_attribute importing name type string exporting value type any .
This method returns the value of the requested attribute. Since attributes can be of any type, the return value can only be untyped and must be integrated type-related when called. ABAP move logic plays a role in the assignment of the attribute value to the return value to enable the type conversion to take place. The ABAP restrictions regarding type conversion apply so that exceptions may occur in the event of incompatible type assignments.
Description
name value
Name of attribute (case-insensitive) Attribute value Exception: Attribute does not exist
cx_bsp_inv_attr_name set_attribute()
Method get_lifetime
Signature method get_lifetime returning lifetime type i .
This method returns the current settings of the lifetime of this BSP page (see lifetime_..-constants of the IF_BSP_PAGEINTERFACE). This method has no effect on stateless applications and always returns the value lifetime_request.
Description
lifetime
Current lifetime of the BSP (see lifetime...constants of the IF_BSP_PAGE): lifetime_page | lifetime_request | lifetime_session
Cross References
set_lifetime, lifetime_page, lifetime_request, lifetime_session
Method get_page_name
Signature method get_page_name returning name type string .
This method returns the name of this BSP. -
name -
Name of the BSP
Method get_page_url
Signature method get_page_url returning url type string .
This method returns the server-specific URL for this BSP. -
Description Parameters Return Values/Exceptions Cross References url -
Server-specific URL of the BSP
Method get_request
Signature method get_request returning request type ref to if_http_request .
This method returns an interface reference to the current HTTP Request Object. -
request
Interface reference to the HTTP Request Object
IF_HTTP_SERVER IF_HTTP_RESPONSE and IF_HTTP_REQUEST
Method get_response
Signature method get_response returning response type ref to if_http_response .
This method returns an interface reference to the current HTTP Response Object. -
response
Interface reference to the HTTP Response Object
Method get_runtime
Signature method get_runtime returning runtime type ref to if_bsp_runtime .
This method returns an interface reference to the current BSP Runtime Object. -
runtime -
Interface reference to the BSP Runtime Object
Method serialize
Signature method serialize returning data type string .
This method serializes the content of this page (after processing in the layout event handler) in a string. This method is typically only called in the OnManipulation section of the BSP when the generated output needs to be postprocessed. However, for performance reasons this is not recommended unless absolutely necessary. The output of a BSP is no longer automatically returned to the client in the HTTP Response when this method is called explicitly. Instead, the developer is responsible for sending it. This can be done with the method if_http_response~set_cdata() and the HTTP Response Object.
Description
data:
Serialized response of the BSP after the layout section is processed.
Method set_attribute
Signature method set_attribute importing name type string value type any .
This method sets the value of the specified attribute. Since attributes can be of any type, the return value can only be untyped and must be integrated type-related when called. This method does not let you define new attributes dynamically at runtime. On the contrary, only attributes that were defined in the development environment (SE80) statically for the BSP page can have values assigned. Otherwise, the method will terminate with the exception cx_bsp_inv_attr_name. ABAP move logic plays a role in the assignment of a value to the attribute to enable the type conversion to take place. The ABAP restrictions regarding type conversion apply so that exceptions may occur in the event of incompatible type assignments.
Description
Parameters
name value
Name of attribute (case-insensitive) Value of attribute (appropriately typed) Exception: Attribute does not exist
cx_bsp_inv_attr_name get_attribute()
Method set_lifetime
Signature method set_lifetime importing lifetime type i .
This method returns the current lifetime of this BSP page (see lifetime_..-constants of the IF_BSP_PAGE). This method has no effect on stateless applications.
Description
Parameters
lifetime
New lifetime of the BSP (see lifetime...constants of the IF_BSP_PAGE): lifetime_page | lifetime_request | lifetime_session
get_lifetime, lifetime_page, lifetime_request, lifetime_session
Method to_string
Signature method to_string importing value type any format type i optional outputlength type i optional num_decimals type i optional reference_value type c returning string type string .
This method formats as a string the value of a scalar ABAP variable with any type. There are several optional parameters available to let you control the formatting. The string generated can be easily integrated in the output in a BSP using the output directive <%= .. %>.
Description
Parameters
value
Value to be formatted
format
Output format (see if_bsp_page~co_format_..constants) Maximum output length (in characters) Number of decimal places Reference value (for example, the currency) Formatted output string
outputlength num_decimals reference_value Return Values/Exceptions Cross References output write()
Method write
Signature method write importing value type any format type i optional outputlength type i optional num_decimals type i optional reference_value type c .
This method outputs as a string the value of a scalar ABAP variable with any type. Output is at the current write position in the BSP. There are several optional parameters available to let you control the formatting. This method can be used for output in a BSP for example, in script directives <% .. %>.
Description
Parameters
value format
Value to be formatted Output format (see if_bsp_page~co_format_..constants) Maximum output length (in characters) Number of decimal places Reference value (for example, the currency)
outputlength num_decimals reference_value Return Values/Exceptions Cross References to_string
Method otr_trim
Signature method otr_trim importing alias returning text .
This method returns the language-dependent text for an OTR alias (short text) This method is available from SAP Web AS 6.20 Support Package 7. alias
Description
Name of the defined OTR alias Text in current language
text
Internationalization and Translation
Interface IF_BSP_RUNTIME
Overview
The interface IF_BSP_RUNTIME gives you access to information contained in the current runtime environment of a BSP application. It gives you access to the most important objects and information in the form of attributes.
Accessibility is integrated in the BSP runtime.
Implementing Class
CL_BSP_RUNTIME
Attributes
Attribute Name application_name application_namespace application_theme application_url ddic_utils keep_context Declaration Type Instance attribute Instance attribute Instance attribute Instance attribute Static attribute Static attribute Description Name of the BSP application Name space of the BSP application Theme of the BSP application URL prefix of the BSP application Dictionary services Stateful/stateless BSP application
(0/1) page_name page_url runtime_url server session_manager client_info Instance attribute Instance attribute Static attribute Static attribute Static attribute Static attribute Name of the BSP URL prefix of the BSP URL prefix of the BSP runtime HTTP Server Workplace Session Manager Device properties for the current request BSP Session ID This attribute uniquely labels the user session. The backend is therefore completely independent, that is, the value of this attribute is set independently of the context at the server. The value of this attribute does not change: 1 1 If you set keep_context from 0 to 1 and
session_id
Static attribute
1 1 If you already have a browser open and you open a new one (using File New Window, for example)
The value of this parameter does change if you close the browser and open a new one.
Methods
Method construct_bsp_url
Signature class-method construct_bsp_url importing in_protocol type string default 'http' in_host type string optional in_port type string optional in_application_ns type string optional in_application type string in_page type string optional in_parameters type tihttpnvp optional in_suppress_rewrite type I default 0 exporting out_protocol type string out_host type string out_port type string out_local_url type string out_abs_url type string . This method builds a server-specific, absolute URL for a BSP application or BSP. You can use the parameter in_protocol to control whether a HTTP- or HTTPS URL should be generated. This method can be expensive at runtime, You are recommended not to call it unnecessarily often. At runtime, instead of using this static method, you can use the instance attribute runtime_url, application_url or page_url as an
Description
alternative. Parameters in_protocol in_host in_port in_application_ns in_application in_page in_parameters Requested protocol (HTTP or HTTPS) Requested host Requested port number Namespace of the BSP application (if not 'sap') Name of the BSP application Name of the BSP Table with name/value pairs that are to be integrated in the URL as query-string parameters 0: Allow URL rewriting of the BSP runtime 1: Suppress URL rewriting of the BSP runtime Actual protocol (HTTP or HTTPS), which can differ from in_protocol if not supported by the server Domain name of the application server Port number for protocol on the application server URL relative to current application server Absolute URL, that is, including protocol, application server name, port number etc.
in_suppress_rewrite
out_protocol
out_host out_port out_local_url out_abs_url
Method get_otr_text
Signature method get_otr_text importing
Description
alias type string returning text type string . This method returns the OTR text in the current language (sy-langu) for the alias specified. If there is no such alias, an empty string is returned. If there is no text for the alias in the current language, the secondary (or fallback) language is used. alias OTR alias including name space (caseinsensitive) OTR text for alias in the current language or empty string if no alias exists
Parameters
text
Method with_accessibility
Signature method with_accessibility returning access type boolean . You determine the accessibility using this method. Note that this does not make any statement about the accessibility of the application itself. access This return value states whether accessibility is active or not.
Description
Interface IF_BSP_PAGE_CONTEXT
Overview
Interface IF_BSP_PAGE_CONTEXT forms a wrapper around a BSP and is based on the Page Context Object.

Implementing Classes Enhanced Interface Specializing Interfaces -
Attributes
-
Methods
Method GET_OUT
This method outputs the current, active writer to the stack.
Method GET_RUNTIME
This method returns the runtime object.
Method GET_NAVIGATION
This method returns the navigation object.
Method GET_REQUEST
This method returns the request object.
Method GET_RESPONSE
This method returns the response object.
Method GET_PAGE
This method returns the page object.
Method POP_WRITER
This method takes the first writer off the stack and returns it.
Method PUSH_WRITER
This method sets a new writer on the stack and returns it as a response.
Method ELEMENT_PROCESS
You can use this method to process other BSP elements dynamically. You can use this when you create Composite Elements for example.
Iterator: Interface IF_HTMLB_TABLEVIEW_ITERATOR

Overview
Definition
The iterator is an instance object that implements the interface IF_TABLEVIEW_ITERATOR. With the iterator, you can create complex logic for <htmlb:tableView> elements, for example for the evaluation of a TableView row and calculation of the value of another row. This iterator interface makes it possible that a <htmlb:tableView> BSP element is not rendered in one step, but that there is a communication with the application after each field or column which enables the application to influence the rendering of a certain field, row or column. As <htmlb:tableView> does not contain application logic itself, the iterator allows the TableView to handle data very flexibly. The interface should be implemented by the corresponding application class of the BSP application, or when controllers are used by the controller class.
Process Flow
The interface IF_HTMLB_ITERTATORcontains 3 callback methods. When processing its BSP (in which its own iterator object is embedded) with <htmlb:tableView iterator="<%= my_iterator %>" ... />, the iterator calls back the three interface methods every time it encounters an <htmlb:tableView/> element or an <htmlb:tableViewColumns/> element.
Use
1. ... 1. 1. In transaction SE24, you can create your own class that implements the interface IF_HTMLB_TABLEVIEW_ITERATOR. 2. 2. Instantiate your iterator class.
Note that you execute the instantiation via the application class or the controller class.
3.
3. Embed your iterator instance in the <htmlb:tableView iterator=< %= my_iterator %> ... /> element. 4. 4. The three methods of IF_HTMLB_TABLEVIEW_ITERATOR are called, i.e., called back. You can implement them according to your needs.
Minimal example coding for the implementation of the method render_cell_start:
method if_htmlb_tableview_iterator~render_cell_start. * html_bee object is responsible to modify HTML code data: html_bee type ref to cl_bsp_bee_html. data: col_value type string. data: html_str type string. * <row> is a structure of table field-symbols: <row> type any, <col> type any. * p_column_key has a name of each table column if p_column_key = 'COLUMN_NAME'. * conventional logic to extract column value assign p_row_data_ref->* to <row>. assign component p_column_key of structure <row> to <col>. col_value = <col>. create object html_bee. if col_value = 'CONDITION_YOU_WANT'. * do something interesting html_str = "<HTML_code_you_want_to_generate_dynamically />" endif. * set HTML code you want...add() can have up to 10 params for concatenation html_bee->add( html = html_str ). p_replacement_bee = html_bee. endif. endmethod.
See also: How do I get a blank line using the iterator?
-
Enhanced Interface
-
Specialized Interfaces
-
Attributes
-
Methods
Method get_column_definitions Signature Description This method is called at the start of the rendering of the TableViews. This methode contains important import parameters which provide information about the current TableView. The row definitions of the TableViews are handed over. At this moment, the application can exert influence. Overwrite this methode, if you plan to make changes here.
Parameters
P_TABLEVIEW_ID
Import parameter for the ID parameter for columns in the TableView Changing parameter to overwrite certain cells in the TableView
P_COLUMN_DEFINITIONS Changing
P_OVERWRITES
Return values / Exceptions Method render_row_start Signature
Description
RENDER_ROW_START is called at the beginning of every row. This methode contains important import parameters which provide useful information about the current row. Use this method if you want to influence the rendering at the beginning of every row. You can filter rows or insert additional information to the rendering. This is especially convenient for tables that do not put out all rows. You can give the rendering information exactly to the rows that are rendered.
Parameters
P_TABLEVIEW_ID P_ROW_INDEX P_ROW_KEY
Import parameter for the ID Import parameter for the row index Import parameter for the row key the reference to the data of a row
P_ROW_DATA_REF Import parameter for P_EDIT_MODE

Return values / Exceptions Import parameter for a checkbox checkbox
P_SKIP_ROW
Method render_cell_start Signatur e Descripti on RENDER_CELL_START is called at the beginning of every column (cell), i.e., before the rendering of every single table field. You use this method to render columns dynamically. Via the import parameters, you obtain the row and column index, as well as a reference to the current row. Thus, you can define a custom rendering for a certain row as is shown in: Custom-Rendering for the Author column. To define a new rendering engine, use the parameter p_replacement_bee. Then, the <htmlb:tableView> element calls this application-specific renderer for this row.
Paramet ers
P_TABLEVIEW_ID P_CELL_ID P_CELL_BINDING P_ROW_INDEX P_ROW_KEY P_COLUMN_INDE X
Import parameter for the ID Import parameter for the cell ID Importparameter for the binding name Import parameter for the row index Import parameter for the row key Import parameter for the column index
P_COLUMN_KEY P_ROW_DATA_RE F P_EDIT_MODE P_REPLACEMENT _BEE
Import parameter for the column key Import parameter for the reference to the data of a row Import parameter for a checkbox Export parameter for a BSP extension expression (BEE)
P_STYLE
Changing parameter for <td style="...">. When using Design2003, you can change the background color of a cell with predefined colors via P_STYLE (P_CLASS is no longer analyzed in Design2003). To do this, use the attribute cellDesign in P_STYLE (e.g. P_STYLE="cellDesign:STCD_STANDARD"). Possible values of cellDesign are STCD_STANDARD, STCD_ALTERNATING, STCD_TRANSPARENT, STCD_NEGATIVE, STCD_POSITIVE, STCD_TOTAL, STCD_SUBTOTAL, STCD_SUBTOTAL_LIGHT, STCD_BADVALUE_DARK, STCD_BADVALUE_MEDIUM, STCD_BADVALUE_LIGHT, STCD_CRITICALVALUE_DARK, STCD_CRITICALVALUE_MEDIUM, STCD_CRITICALVALUE_LIGHT, STCD_GOODVALUE_DARK, STCD_GOODVALUE_MEDIUM, STCD_GOODVALUE_LIGHT, STCD_GROUP_HIGHLIGHTED, STCD_GROUP_HIGHLIGHTED_LIGHT, STCD_KEY_MEDIUM, STCD_GROUP_LEVEL1, STCD_GROUP_LEVEL2, STCD_GROUP_LEVEL3, STCD_MARKED, STCD_FILTER and STCD_POPIN. You can find an example for the use of cellDesign in the BSP application sbspext_table, page TableViewIterator.bsp, iterator class CL_SBSPEXT_ITERATOR, method
IF_HTMLB_TABLEVIEW_ITERATOR~RENDER_C ELL_START, row 50:

if design eq '2002'. p_style = 'background-color:#BBDDDD'. elseif design eq '2003'. p_style = 'celldesign:GROUP_HIGHLIGHTED_LIGHT'. endif. Note, that the specification of cellDesign does not have any effect in Design2002. If you want to change the background color there, you have to do this via CSS attributes. On the other hand, it is no longer possible to set specifications in Design2003 style for the cell, except via cellDesign itself.
P_CLASS
Changing parameter for <td
class="...">.
Note, that P_CLASS is no longer anaylzed in Design2003.
P_ISREADONLY
Return values / Exceptio ns -
Changing parameter for <td
readonly>.
Example
You find an example in the BSP tutorial: Our Little Online Bookshop using MVC and HTMLB and Custom-Rendering for the Author column.
IF_CLIENT_INFO Interface
Definition
The IF_CLIENT_INFO interface provides a range of methods that take into account the different display options for Web applications on different browsers, along with other device-specific properties such as screen size or input method.
Use
In this way, you can use the methods of the IF_CLIENT_INFO interface when you create Web applications like BSP application, and thus take the often substantial differences in the display of Web pages on different devices into account.
You can also use this Device Recognition Process and the comparable ClientInfo Interface when developing Java applications. So that you can estimate the significance for your Web application of the methods described in the following table, some of them have been assigned a priority. For those device properties not assigned a priority, you can decide yourself whether or not you want to use them in your Web application. Device properties can be categorized by their significance as follows:
Prio. 1 Title Prerequisite Description This property is prerequisite for running the mobile application at all. In general, these conditions are fulfilled by all "real" devices that fulfil the HTML or WAP standard. Emulators, however, do not fulfil these prerequisites. Thus this property need not be checked in the application. At most, you need a check program that ascertains whether or not an emulator is suitable for executing the application
Application does not work Loss of information
If this property is not assigned a value, the application may crash on some devices that is, may not be executable If this property is not assigned a value, the application may not show all its information For example, a loss of information may occur if the paragraph attribute for automatic line breaks is switched off (<p mode=nowrap>) and the paragraph (in a WML page) contains text that does not fit on one line. If the
mobile device does not support the GET_MARQUEE_TEXT_SUPPORTED property, it is possible that the end of the text is simply truncated. For this reason
we advise you to think carefully before switching off the automatic line break property even if doing so would allow you, for example, to make better use of a small screen on a mobile telephone. 4 Unacceptable display If this property is not assigned a value, the application may be displayed in a way that does not do justice to the look and feel of the device If this property is not assigned a value, the application may not be displayed at its best. However, the display should not actually disturb the user significantly.
Inappropriate display
Similarly, some properties are assigned to the markup languages WML (Wireless Markup Language) and HTML (Hypertext Markup Language) that is, you specify the markup language for which each method is relevant and thus how it can meaningfully be used. For example, the method GET_FRAMES_SUPPORTED is only significant in HTML, since only HTML-enabled browsers can interpret frames. In general, it is HTML browsers on handheld devices like PDAs and pocket PCs, WAP-enabled mobile telephones with small screens cannot display frames, because of their screen interfaces. If the appropriate table column does not contain a value, the method can be used in both markup languages. The following source code fragment shows how you can access the methods of the IF_CLIENT_INFO interface: <%@page language="abap"%> <% ... data client_info type ref to IF_CLIENT_INFO. client_info = runtime->client_info. if client_info->get_title_supported( ) = X. ... %>
To obtain more information on using some of the methods of the IF_CLIENT_INFO interface in your Web application, use the links in the table.
Methods
Method GET_ACCEPT Signature
method get_accept returning value type string
Description
Equivalent to the HTTP request-header "userAgent".
Possible values
Content type
Prio.
GET_ALERTING_SUPPORTED
method get_alerting_supported returning value type flag method get_anchor_supported returning value type flag method get_anchor_prev_support ed returning value type flag method get_app_links_supported returning value type flag method get_app_link_types returning value type string method get_back_hard_wired returning value type flag
Specifies whether or not the device supports messaging for example, using SMS. Specifies whether or not the <anchor> tag is supported
"X" or space
GET_ANCHOR_SUPPORTED
"X" or space
WML
GET_ANCHOR_PREV_SUPPORTE D
Specifies whether or not the anchor tag supports a "Back" action
"X" or space
WML
GET_APP_LINKS_SUPPORTED
Specifies whether or not you can call a local application on a device using a special link Specifies what type of application links the device supports
"X" or space
HTML
GET_APP_LINK_TYPES
HTML
GET_BACK_HARD_WIRED
Specifies whether or not you can execute the "Back" function using a fixed key without an associated tag Specifies whether or not a label attribute must be specified in the <do type=prev> tag to display a label Specifies whether the <do type="prev"> tag can lead to any Web address
"X" or space
WML
GET_BACK_LABEL
method get_back_label returning value type flag
"X" or space
WML
GET_BACK_TO_ANY_URL_SUPPO RTED
method get_back_to_any_url_sup ported returning value type flag method get_big_supported returning value type flag method get_bold_supported returning value type flag method get_breaking_space returning value type string method get_browser_category returning value type string
"X" or space
WML
GET_BIG_SUPPORTED
Specifies whether or not text can be formatted as "large"
"X" or space
WML
GET_BOLD_SUPPORTED
Specifies whether or not text can be formatted as "bold"
"X" or space
WML
GET_BREAKING_SPACE
Returns the smallest character string for an empty space
GET_BROWSER_CATEGORY
Returns the browser category
unknown" pocketie" avantgo" imode" palm" wap" epoc"
GET_BROWSER_NAME
method get_browser_name returning value type string
Returns the browser name
unknown" InternetExp lorer" NetscapeN avigator" mobile" unknown" HPUX" Linux" MacPPC" SunOS" Win32" mobile"
GET_BROWSER_NAME
method get_browser_os returning value type string
Returns the operating system running on the device
GET_BROWSER_VERSION
method get_browser_version returning value type int4 method get_cache_enabled_by_d efault returning value type flag method get_certificates_supported returning value type flag method get_char_height returning value type int4 method get_char_width returning value type int4 method get_color_depth returning value type float method get_color_supported returning value type flag method get_content_type returning value type string method get_content_type_version returning value type int2 method get_cookies_supported returning value type flag method get_css_supported returning value type flag
Returns the browser version, for example 5.5
GET_CACHE_ENABLED_BY_DEFA ULT
Specifies whether or not cache memory on the browser is activated by default
"X" or space
GET_CERTIFICATES_SUPPORTED
Specifies whether or not the device supports client certificates
"X" or space
GET_CHAR_HEIGHT
Returns the screen height in rows
GET_CHAR_WIDTH
Returns the screen width in characters
GET_COLOR_DEPTH
Returns the color depth, for example 256 colors
HTML
GET_COLOR_SUPPORTED
Specifies whether or not the device has a color screen
"X" or space
HTML
GET_CONTENT_TYPE
Returns the content type, for example HTML or WML Returns the version of the content type for example, 3.2 for HTML 3.2 or 1.1 for WML 1.1 Specifies whether or not browser cookies are supported "X" or space
GET_CONTENT_TYPE_VERSION
GET_COOKIES_SUPPORTED
GET_CSS_SUPPORTED
Specifies whether or not the browser supports CSSs (Cascading Style Sheets).
"X" or space
HTML
GET_CSS_VERSION
method get_css_version returning value type int4 method get_default_action_design returning value type string
Returns the CSS version
HTML
GET_DEFAULT_ACTION_DESIGN
Returns the default design for user interface elements representing an action
link" button" softkey" linkAndSoft key"
WML
GET_DEFAULT_BLOCK_SEPARAT OR
method get_default_block_separat or returning value type string method get_default_bullet returning value type string method get_default_form_style returning value type string method get_default_menu_style returning value type string method get_device_category returning value type string
Returns the default string used to separate paragraphs
GET_DEFAULT_BULLET
Returns the default symbol used to indicate points in a list Returns the default display type for input masks onePage" menu" wizard"
WML
GET_DEFAULT_FORM_STYLE
WML
GET_DEFAULT_MENU_STYLE
Returns the default display type for menus
selectionLis t" linkList"
WML
GET_DEVICE_CATEGORY
Returns the device category
unknown" Phone" PDA" Voice" PC"
GET_DEVICE_NAME
method get_device_name returning value type string method get_dom_supported returning value type flag method get_dom_version returning value type int4 method get_emphasized_supporte d returning value type flag method get_emulator returning value type flag
Returns the device name Unique ID for a set of device properties Specifies whether or not the browser supports a Document Object Model (DOM) Returns the Document Object Model (DOM) version supported Specifies whether or not text can be formatted as "highlighted" "X" or space "X" or space HTML
GET_DOM_SUPPORTED
GET_DOM_VERSION
HTML
GET_EMPHASIZED_SUPPORTED
WML
GET_EMULATOR
Specifies whether or not the device is to be categorized as an emulator Specifies how input fields that belong together are to be laid out using the <fieldset> tag
"X" or space
GET_FIELDSET_LAYOUT
method get_fieldset_layout returning value type string
notSupport ed" ignored" beneath" beneathWit hIndent"
WML
sideBySide "
GET_FIELDSET_TITLE_VISIBLE
method get_fieldset_title_visible returning value type boolean method get_font_proportional returning value type flag method get_form_factor returning value type string
Specifies whether or not the title attribute of the <fieldset> tag is used as label. Specifies whether or not the default font of the device is a proportional font Returns the screen format of the device
"X" or space
WML
GET_FONT_PROPORTIONAL
"X" or space
GET_FORM_FACTOR
PC" VGA" halfVGA" mediumLan dscape" mediumPor trait" phone" unknown "X" or space WML
GET_FORM_MENU_SUPPORTED
method get_form_menu_supporte d returning value type flag
Specifies whether or not the browser supports the technique of displaying a selection menu with the input mask Specifies whether or not frames are supported
GET_FRAMES_SUPPORTED
method get_frames_supported returning value type flag method get_gray_level returning value type float
"X" or space
HTML
GET_GRAY_LEVEL
Returns the number of shades of gray supported in grayscale pictures Specifies whether or not the device has a horizontal scroll bar
"X" or space
GET_HORZ_SCROLLING_SUPPOR TED
method get_horz_scrolling_suppor ted returning value type flag method get_href_with_params_su pported returning value type flag method get_http_get_supported returning value type flag method get_http_post_supported returning value type flag method get_image_alignment_sup ported returning value type flag
"X" or space
GET_HREF_WITH_PARAMS_SUPP ORTED
Specifies whether or not an Href attribute in a link can contain URL parameters.
"X" or space
WML
GET_HTTP_GET_SUPPORTED
Specifies whether or not the HTTP GET is supported
"X" or space
WML
GET_HTTP_POST_SUPPORTED
Specifies whether or not the HTTP POST is supported
"X" or space
WML
GET_IMAGE_ALIGNMENT_SUPPO RTED
Specifies whether or not a graphic can be aligned (left, right, or centered)
"X" or space
WML
GET_IMAGE_LINKS_SUPPORTED
method get_image_links_supporte d returning value type flag method get_image_size_max returning value type float method get_input_format_date returning value type string method get_input_format_numeric returning value type string method get_input_method_hand_ writing returning value type flag method get_input_method_keyboa rd returning value type flag method get_input_method_keypad returning value type flag method get_input_method_keypad _intell returning value type flag method get_input_method_voice returning value type flag method get_input_shown_with_ca ption returning value type flag method get_italic_supported returning value type flag method get_java_supported returning value type flag method get_java_version
Specifies whether or not a graphic can be used as link.
"X" or space
GET_IMAGE_SIZE_MAX
Returns the maximum memory size of a graphic
WML
GET_INPUT_FORMAT_DATE
Returns the character string used to format date values
WML
GET_INPUT_FORMAT_NUMERIC
Returns the character string used to format numeric values
WML
GET_INPUT_METHOD_HAND_WRI TING
Specifies whether or not the device supports handwritten input
"X" or space
GET_INPUT_METHOD_KEYBOARD
Specifies whether or not the device supports input using a keyboard
"X" or space
GET_INPUT_METHOD_KEYPAD
Specifies whether or not the device supports input using a telephone keypad Specifies whether or not the device supports input using T9 text input or similar
"X" or space
GET_INPUT_METHOD_KEYPAD_IN TELL
"X" or space
GET_INPUT_METHOD_VOICE
Specifies whether or not the device supports speech input
"X" or space
GET_INPUT_SHOWN_WITH_CAPTI ON
Specifies whether or not the browser uses the title attribute of the <input> tag is used as a label Specifies whether or not text can be formatted as "talic"
"X" or space
WML
GET_ITALIC_SUPPORTED
"X" or space
WML
GET_JAVA_SUPPORTED
Specifies whether or not the device supports the Java programming language Returns the Java
"X" or space
HTML
GET_JAVA_VERSION
HTML
returning value type int4
version supported
GET_LINKS_SEPARATED
method get_links_separated returning value type flag method get_link_decoration returning value type string
Specifies whether or not two consecutive links are visibly separated
"X" or space
WML
GET_LINK_DECORATION
Returns the delimiters that are automatically added to the link text by the device for example [ ] or < >. Returns the maximum number of characters that a link can have to fit into one line. Specifies whether or not the device supports locally stored graphics or symbols "X" or space
WML
GET_LINK_TEXT_WIDTH
method get_link_text_width returning value type int2 method get_local_images_support ed returning value type flag method get_local_variables_supp orted returning value type flag method get_marquee_link_suppor ted returning value type flag method get_marquee_text_suppor ted returning value type flag method get_max_link_length returning value type int4 method get_media_formats returning value type string
WML
GET_LOCAL_IMAGES_SUPPORTE D
GET_LOCAL_VARIABLES_SUPPO RTED
Specifies whether or not the browser supports local variables
"X" or space
WML
GET_MARQUEE_LINK_SUPPORTE D
Specifies whether or not a long link can be displayed in one line, for example as a tickertape. Specifies whether or not a long text can be displayed in one line, for example as a tickertape. Returns the maximum size of the Href attributes of a link.
"X" or space
WML
GET_MARQUEE_TEXT_SUPPORT ED
"X" or space
WML
GET_MAX_LINK_LENGTH
GET_MEDIA_FORMATS
Returns the list of multimedia formats supported such as .agif (animated .gif format), .gif, .jpg, .png, .wbmp Returns the maximum memory capacity of the device Returns the name of the device type such as 7110 for the Nokia 7110 mobile telephone Specifies whether or not the device supports "X" or space WML HTML
GET_MEMORY
method get_memory returning value type float method get_model returning value type string
GET_MODEL
GET_NBSP_SUPPORTED
method get_nbsp_supported
returning value type flag
non-breaking blank characters Specifies whether or not the browser supports nested tables "X" or space HTML 2
GET_NESTED_TABLES_SUPPORT ED
method get_nested_tables_suppor ted returning value type flag method get_newline_after_image returning value type flag method get_newline_after_input returning value type flag
GET_NEWLINE_AFTER_IMAGE
Specifies whether or not a line break is inserted automatically after an <img> tag. Specifies whether or not a line break is inserted automatically after an <input> tag on a specific mobile device. Specifies whether or not a line break is inserted automatically after a link
"X" or space
WML
GET_NEWLINE_AFTER_INPUT
"X" or space
WML
GET_NEWLINE_AFTER_LINK
method get_newline_after_link returning value type flag method get_newline_after_select returning value type flag method get_newline_before_imag e returning value type flag method get_newline_before_input returning value type flag method get_newline_before_link returning value type flag method get_newline_before_selec t returning value type flag method get_newline_between_im ages returning value type flag method get_newline_between_link s returning value type flag method get_newline_betw_link_an
"X" or space
WML
GET_NEWLINE_AFTER_SELECT
Specifies whether or not a line break is inserted automatically after an <select> tag. Specifies whether or not a line break is inserted automatically before an <img> tag.
"X" or space
WML
GET_NEWLINE_BEFORE_IMAGE
"X" or space
WML
GET_NEWLINE_BEFORE_INPUT
Specifies whether or not a line break is inserted automatically before an <input> tag. Specifies whether or not a line break is inserted automatically before a link Specifies whether or not a line break is inserted automatically before an <select> tag.
"X" or space
WML
GET_NEWLINE_BEFORE_LINK
"X" or space
WML
GET_NEWLINE_BEFORE_SELECT
"X" or space
WML
GET_NEWLINE_BETWEEN_IMAGE S
Specifies whether or not a line break is inserted automatically after an <image> tag
"X" or space
WML
GET_NEWLINE_BETWEEN_LINKS
Specifies whether or not a line break is inserted automatically between two <image> tags
"X" or space
WML
GET_NEWLINE_BETW_LINK_AND_ TAG
Specifies whether or not a line break is inserted
"X" or space
WML
d_tag returning value type flag
automatically between a link and a tag
GET_OFFLINE_BROWSING_SUPP ORTED
method get_offline_browsing_sup ported returning value type flag method get_offline_forms_support ed returning value type flag method get_page_size_max returning value type float method get_pixel_height returning value type float method get_pixel_width returning value type float method get_redir_absolute_suppo rted returning value type flag method get_redir_relative_support ed returning value type flag method get_script_supported returning value type flag method get_script_version returning value type int4 method get_secure_protocols_sup ported returning value type flag
Specifies whether or not the browser supports offline browsing through locally stored pages (that is, cached pages) Specifies whether or not the browser allows the user to fill out input forms offline on the device Returns the maximum page size that can be processed in a mobile device. Specifies the screen height in pixels.
"X" or space
HTML
GET_OFFLINE_FORMS_SUPPORT ED
"X" or space
HTML
GET_PAGE_SIZE_MAX
GET_PIXEL_HEIGHT
GET_PIXEL_WIDTH
Specifies the screen width in pixels.
GET_REDIR_ABSOLUTE_SUPPOR TED
Specifies whether or not the browser supports the redirection of an absolute URL address.
"X" or space
GET_REDIR_RELATIVE_SUPPORT ED
Specifies whether or not the browser supports the redirection of a relative URL address.
"X" or space
GET_SCRIPT_SUPPORTED
Specifies whether or not the browser supports scripting
"X" or space
GET_SCRIPT_VERSION
Returns the script version supported
GET_SECURE_PROTOCOLS_SUP PORTED
Specifies whether or not the browser supports SSL (Secure Socket Layer) or WTLS (Wireless Transport Layer Security) Returns the names of the security protocols supported The names are separated by semicolons
"X" or space
GET_SECURE_PROTOCOLS_NAM ES
method get_secure_protocols_na mes returning value type string method get_selection_menu_supp orted
GET_SELECTION_MENU_SUPPOR TED
Specifies whether or not the menu
"X" or space
WML
returning value type flag
layout type "selectionList" is supported

Specifies whether or not the <setvar> tag can be used within the <onevent type="onenterforward"> event handler Specifies whether or not the browser automatically skips to the first <input> tag and displays a screen extract starting from this tag Specifies whether or not text can be formatted as "small" "X" or space WML 1
GET_SETVAR_ON_EVENT_SUPPO RTED
method get_setvar_on_event_sup ported returning value type flag
GET_SKIPPING_TO_INPUT
method get_skipping_to_input returning value type flag
"X" or space
WML
GET_SMALL_SUPPORTED
method get_small_supported returning value type flag method get_softkey_num returning value type int1
"X" or space
WML
GET_SOFTKEY_NUM
Returns the number of Soft Keys supported by the device

Specifies how soft key 1 is displayed on the screen notShown" key" menu" screen" notShown" key" menu" screen"
WML
GET_SOFTKEY_STYLE1
method get_softkey_style1 returning value type string method get_softkey_style2 returning value type string method get_softkey_title_width returning value type int2 method get_sound_supported returning value type flag method get_strong_supported returning value type flag
WML
GET_SOFTKEY_STYLE2
Specifies how soft key 2 is displayed on the screen
WML
GET_SOFTKEY_TITLE_WIDTH
Returns the number of displayed characters for a soft key title.
WML
GET_SOUND_SUPPORTED
Specifies whether or not the device can play sounds
"X" or space
HTML
GET_STRONG_SUPPORTED
Specifies whether or not text with the <strong>can be formatted as "highlighted" Specifies whether or not "Submit" is supported within the <onevent type="onenterforward"> event handler Allows you to split devices into different sub-categories
"X" or space
WML
GET_SUBMIT_ONEVENT_SUPPOR TED
method get_submit_onevent_supp orted returning value type flag method get_sub_category returning value type string
"X" or space
GET_SUB_CATEGORY
Any text
GET_TABLE_HAS_BORDERS
method get_table_has_borders returning value type flag method get_table_supported returning value type flag method get_telephony_links_supp orted returning value type flag method get_text_alignment_suppo rted returning value type flag method get_text_styles_supported returning value type flag method get_title_supported returning value type flag
Specifies whether or not tables are displayed with gridlines
"X" or space
GET_TABLE_SUPPORTED
Specifies whether or not the browser supports tables with several columns Specifies whether or not a telephone can be dialed directly using a link
"X" or space
GET_TELEPHONY_LINKS_SUPPO RTED
"X" or space
GET_TEXT_ALIGNMENT_SUPPOR TED
Specifies whether or not text within a paragraph can be aligned left, right, or centered
"X" or space
WML
GET_TEXT_STYLES_SUPPORTED
Specifies whether or not the browser can format text using tags such as <b> or <small> Specifies whether or not a label is to appear on the top of the screen using the "title" property of the <card> WML tag. Returns the maximum number of characters of the title Specifies whether or not text can be formatted as "underlined"
"X" or space
WML
GET_TITLE_SUPPORTED
"X" or space
WML
GET_TITLE_WIDTH
method get_title_width returning value type int2 method get_underline_supported returning value type flag method get_user_agent returning value type string method get_vars_across_card_su pported returning value type flag method get_vendor returning value type string method get_xsl_supported returning value type flag
GET_UNDERLINE_SUPPORTED
"X" or space
WML
GET_USER_AGENT
Equivalent to the HTTP request header "userAgent" Specifies whether or not browser variables passed to a card can also be used for different cards Returns the manufacturers name "X" or space WML 1
GET_VARS_ACROSS_CARD_SUP PORTED
GET_VENDOR
GET_XSL_SUPPORTED
Specifies whether or not the browser supports Extensible Stylesheet Language (XSL) Returns the XSL version supported
"X" or space
HTML
GET_XSL_VERSION
method get_xsl_version returning value type int4
HTML
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.
Object application
Definition
The object application refers to the application class of a BSP application. See also: Class CL_BSP_APPLICATION Interface IF_BSP_APPLICATION
Integration
This object is only available if an application class was defined for the BSP application. If so, the methods defined there can be accessed.
Do not set parameters for the constructor.
Object navigation
Definition
The object navigation has the same type as interface IF_BSP_NAVIGATION. The following methods are available for navigation between BSP pages. They collect information required for the presentation of the subsequent page. After the subsequent is navigated to, the navigation object is deleted. The class contains methods which are used to determine the characteristics of the subsequent page, and methods which can be used for transferring parameters between pages.
Methods for Constructing the Subsequent Page

next_page
When called, this method determines the subsequent page from the navigation structure.
navigation->next_page( 'TOORDER' ). This call triggers a search for the navigation request TOORDER in the navigation structure of the BSP application, and the subsequent page is opened.
goto_page
When this method is called, the URL of the page that is to be navigated to next is displayed.
navigation->goto_page( 'error.htm' ).
exit
This method ends the current session in the active application and navigates to the given URL. If no exit URL is given, the exit URL of the BSP application is used.
navigation->exit( exit_url = 'http://www.sap.com' ).
call_application
You can use this method to navigate to a page (specified by the URL) in another application. If the BSP application in which the method was called is running in stateful mode, the current context is maintained. The foreign application receives the URL as a parameter.
Methods for Transferring Parameters to the Subsequent Page

A page can transfer parameters to a subsequent page. The following methods exist for this purpose.
set_parameter
Using the call navigation->set_parameter( name='myparameter' value = myvalue ). you can set the page parameter myparameter to the value myvalue. This value can then be used for processing in the subsequent page.
If the form field (in the layout part) and the page parameter are of the type string and are specified by the same name (in this case, myparameter), the following abbreviation can be used: navigation->set_parameter( 'myparameter' ).
get_parameter
You can use this method to obtain the value of a parameter.
This method is not recommended for BSP applications. It is used when the users own HTTP request handlers are implemented.
has_parameters
This method returns 1 if at least one parameter was specified. Otherwise, the method returns 0.
Object runtime
Definition
The runtime object refers to the interface IF_BSP_RUNTIME. The following attributes can be set: runtime->keep_context 0: stateless mode 1: stateful mode
See also: Stateful and Stateless BSP Applications A Sample BSP Application
Object request
Definition
The request object is of the type IF_HTTP_ENTITY. IF_HTTP_REQUEST. This interface contains the interface
The methods are explained in the section
IF_HTTP_ENTITY.
Object response
Definition
The request object is of the type IF_HTTP_ENTITY. IF_HTTP_REQUEST. This interface contains the interface
The methods are explained in the section
IF_HTTP_ENTITY.
Object messages
Definition
The object messages is the same type as the class CL_BSP_MESSAGES. This object is a message contained and outputs different types of error messages. It contains a list of error messages with details of severity, condition, and the corresponding text.
Use
You use the object to handle users incorrect entries in BSP applications. For more information see Handling Incorrect Input. An entry is made in the list if syntax errors occur in automatic page attributes, for example, when the entry cannot be converted to a specific format. The attribute name must be available. You can add additional entries to the messages object during input processing. Texts and conditions are user-definable in this case.
Structure
The following methods are available: NUM_MESSAGES This method returns the number of messages when it is called. ADD_MESSAGE This method adds a single message when it is called. GET_MESSAGE This method returns the requested message when it is called. ASSERT This method returns the message index for a specific condition or 0 when it is called. ASSERT_SEVERITY This method returns the severity of the error for a specific condition or 0 when it is called. ASSERT_MESSAGE This method returns the message for a specific condition or an empty string when it is called. The conditions specify the message types or error levels. The following error levels are available: Attribute Name CO_SEVERITY_ERROR CO_SEVERITY_FATAL_ERROR CO_SEVERITY_INFO CO_SEVERITY_SUCCESS CO_SEVERITY_WARNING Initial Value 2 1 4 5 3 Description of Error Level Normal error Fatal error Information Success message Warning
The messages are grouped together in a table (attribute M_MESSAGES).
Example
There is an example showing the use of this object in the SAP System in the BSP application bsptutorialmessages, in the package SBSP_DOCU.
Object page
Definition
The object page accesses information about a BSP. It is the same type as class CL_BSP_PAGE or the interface IF_BSP_PAGE
Structure
The following methods are the most important: Method get_page_name Use in Source Code <%= page>get_page_nam e( ) %> <%= page>get_page_url( ) %> <%= page>get_application _namespace( ) %> <%= page>get_application _name( ) %> <%= page>get_application _url( ) %> <%= page>get_application _theme( ) %> <%= page>get_application Output (Example) basic_page_object.htm Description Output of the BSP name
get_page_url
/ sap(bD1kZQ==)/bc/bsp/sap/it00/b asic_page_object.htm sap
Output of the BSP URL
get_application_namespace
Output of the BSP application namespace Output of the BSP application name Output of the BSP application URL Output of the BSP application theme Output of the BSP
get_application_name
it00
get_application_url
/sap(bD1kZQ==)/bc/bsp/sap/it00
get_application_theme
SAP_DEFAULT
get_application_start_page
default.htm
_start_page( ) %>
application start page
Object page_context
Definition
Based on the interface IF_BSP_PAGE_CONTEXT, the page context object provides information that is sent to all BSP elements.
This object is not used in the BSPs themselves, but only in connection with BSP extensions or elements.
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. As an example, a simple HTML pushbutton can be implemented very easily: <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. Here an abstraction technology can be used to express both the syntax and the semantics of a specific section of HTML coding simply. This mechanism is structured so that it can also be used by other types of BSPs, XML, WML and so on. With this technology you call them 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 which are available and can be used in every SAP Web Application Server 6.20 system. In addition you can define your own extensions to meet specific requirements. You can create these using an editor that is 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 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, for example: <htmlb:button id=btn1 text=Hit Me! /> Here htmlb is the XML namespace, button is the element and id and text are attributes. If 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. Furthermore, the link element 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
Different examples of BSP applications that use BSP extensions are available in the system. 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.
As part of the tutorials for creating Web applications with BSP, a Tutorial for a Small Online Bookshop is also available, whose layout is implemented using HTMLB.
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 = " " 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
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.
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 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.
1. 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.
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
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"> <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 >
User-Defined Validation
Use
Activate this option in the Attributes display for the BSP element if you wish to execute a userdefined 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 RUNTIME_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.
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.
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. 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
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( ). 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.
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.
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
Generated Classes and Class Hierarchy
The following figure shows the position of the element handler class within the inheritance hierarchy of the classes involved:
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. Basis class with a standard implementation of the IF_BSP_ELEMENT methods for all BSP elements.
CL_BSP_ELEMENT
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.
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. 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 userdefined 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 GET_ELEMENT_NAMED_PARENT GET_DIRECT_PARENT Interface Method For Error Handling RAISE_ERROR Triggers an exception of the class CX_BSP_ELEMENT_EXCEPTION. Returns an arbitrary parent element that is identified by the element handler class. Returns an arbitrary parent element that is identified by the name of the extension and the name of the element. Returns the direct parent element.
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 M_NAME M_EXTENSION M_CLASS_NAME M_PARENT M_PAGE_CONTEXT Predefined Interface Constants CO_PAGE_DONE CO_PAGE_CONTINUE CO_ELEMENT_DONE CO_ELEMENT_CONTINUE Interface Attribute for the BodyWriter M_OUT Interface Attribute for Validation M_VALIDATOR
BSP element ID BSP element name BSP extension name Name of element handler class Reference to a parent element Reference to the page context (IF_BSP_PAGE_CONTEXT)
This constant defines that the BSP page is not to be evaluated further. This constant defines that the BSP page is to be evaluated further. This constant defines that the BSP element is not to be evaluated further. This constant defines that the BSP element is to be evaluated (once more).
Reference to the BodyWriter that manages the element content.
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.
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 = "myLabel" = "carrier" = "Airline" = "LABEL" = "65" />
<ui:inputField type
id
= "carrier" = "String" = "<%=carrier%>" = "3" = "standard" /> = "myButton" = "Find Flights"
value size design <ui:button text id
onClick = "FIND" design <br><br> <ui:tableView id table = "myTable" = "<%=flights%>" = "STANDARD" />
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
Creating Page before.htm

Use
On this page, implement the output using HTMBL.
Prerequisites
You have created a BSP application (see also has the name BSP_TUT_COMPLEX. Creating BSP Applications). In our example, this
Procedure
1. In your BSP application, create page before.htm as a page with flow logic 2.
(see also Creating Pages). Define three page attributes for the three input fields:
Attribute name password email
Auto x x x
Typing Type TYPE TYPE TYPE
Reference Type STRING STRING STRING
3. Create the page layout with HTMBL elements:

<%@page language="abap"%> <%@extension name = "HTMLB" prefix = "htmlb" %> <htmlb:content> <htmlb:page> <htmlb:form> <htmlb:gridLayout cellSpacing = "2" cellPadding = "0" width = "100%" rowSize = "3" columnSize = "2"> <%-- name --%> <htmlb:gridLayoutCell columnIndex = "1" rowIndex = "1" > <htmlb:label id = "name_label" text = "Name:" for = "name" /> </htmlb:gridLayoutCell> <htmlb:gridLayoutCell columnIndex = "2" rowIndex = "1"> <htmlb:inputField id = "name" value = "<%=name%>"/> </htmlb:gridLayoutCell> <%-- password --%> <htmlb:gridLayoutCell columnIndex = "1" rowIndex = "2" > <htmlb:label id = "password_label" text = "Password:" for = "password" /> </htmlb:gridLayoutCell> <htmlb:gridLayoutCell columnIndex = "2" rowIndex = "2"> <htmlb:inputField id = "password" value = "<%=password%>" password = "TRUE" /> </htmlb:gridLayoutCell> <%-- email --%> <htmlb:gridLayoutCell columnIndex = "1" rowIndex = "3" > <htmlb:label id = "email_label" text = "Email:"
for = "email" /> </htmlb:gridLayoutCell> <htmlb:gridLayoutCell columnIndex = "2" rowIndex = "3"> <htmlb:inputField id = "email" value = "<%=email%>" /> </htmlb:gridLayoutCell> </htmlb:gridLayout> </htmlb:form> </htmlb:page> </htmlb:content> 4. Save and activate your page and the BSP application.
Result
The generated output is as follows:
Analysis
You need more than 40 lines coding to code the simple three input fields. Also, because of the <htmlb:gridLayout> element, you cannot always immediately recognize at a glance the coding structure. This element is not absolutely necessary for our example, although it makes sense to use it with more complex layouts. For these flow-type layouts, most attributes can now be calculated automatically, especially counters for rows and columns. It is exactly the same when you connect <htmlb:label> to <htmlb:inputField>. Many of the attributes can also be hard-coded in a set of wrapper elements. It is therefore recommended that you design a BSP extension library that also contains inherent information (that is, hard-coded elements) for the layout of a specific BSP application or a group of BSP applications. Ideally, the individual BSP extensions in this library will be "slim" and easy to create. These can be used to create "toolboxes" that encapsulate the appearance and the whole layout centrally. As a result, you can also make changes to the whole application very quickly. You can do all this using the Design Solution.
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
Creating a New BSP Extension with Elements

Procedure
To create the new BSP extension for the solution that is described, first define the extension itself and then the elements that it contains. At the end, activate the extension.
1. Create a new BSP extension in the ABAP Workbench (see also Creating BSP
Extensions). In our example, this has the name BSP_TUTORIAL_COMPLEX.
2. Enter a Default prefix.

The default prefix is used for this BSP extension if you use drag & drop to add elements of this extension in the page with flow logic, or if you want to insert them in the view without having used this extension previously. If you use the BSP extension, you can change the default prefix at any time by renaming the prefix attribute of the extension directive. In our example, this is TutCmplx.
3. In your new extension, create element <SimpleForm> (see also Defining BSP
Elements).
We recommend that you integrate the default BSP extension prefix with the name of the element handler class. In our example, the name of the element handler class is CL_BSP_TUTCMPLX_SIMPLE_FORM. 4. Define and configure the BSP element as usual. In our example, the element content consists exclusively of inner BSP elements and therefore does not have any freely-defined text. In our example, the element has an (obligatory) attribute called id of type string.
5. Create new BSP element <SimpleFormItem>.

This element displays an element that wraps both <htmlb:label> and <htmlb:inputField>. Since the <htmlb:inputField> element contains most of the attributes that you require for the new <TutCmplx:SimpleFormItem> element, you can simply copy the <htmlb:inputField> element.
a. To do this, branch to the BSP extension HTMLB for element <inputField> and on
the selected element in the context menu choose Copy....
b. Then enter as the destination the BSP extension BSP_TUTORIAL_COMPLEX and

SimpleFormItem as the destination BSP element. Since the copy function only copies the logical definition of the element, you must make a few additional changes. The new definition in particular is still linked to the original implementation class (element handler class).
c. Use the tabstrip Properties to change the connection to the element handler
class and enter CL_BSP_TUTCMPLX_SIMPLE_FORM_IT.
d. Add the additional attributes that you require for processing <htmlb:label>. In
this simple example, you only need one new attribute, which is the label name. On the tabstrip Attributes, enter the additional attribute label of type string. 1. Save the BSP extension and generate it.
Result
At this point, the empty implementations for the elements were already generated. You can now create a simple test page (although this does not create any output).
Creating Page after.htm

Use
Once you have created your new BSP extension with the two new elements, you can use this new extension already in a new page in your BSP application. All elements are defined, and empty standard implementations were generated by the system for each element. As a result, the elements can be used already, even if they do not create any tasks.
Procedure
1. In the Web Application Builder, use the context menu to copy the existing page 2.
before.htm to the name after.htm. Change the layout coding:
<%@page language="abap"%> <%@extension name = "HTMLB" prefix = "htmlb" %> <%@extension name = "BSP_TUTORIAL_COMPLEX" prefix = "sf" %> <htmlb:content> <htmlb:page> <htmlb:form> <sf:SimpleForm id <sf:SimpleFormItem id label value <sf:SimpleFormItem id label value password <sf:SimpleFormItem id label value </sf:SimpleForm> </htmlb:form> </htmlb:page> </htmlb:content>
= "sf" > = "name" = "Name:" = "<%=name%>" /> = "password" = "Password:" = "<%=password%>" = "TRUE" /> = "email" = "Email:" = "<%=email%>" />
3. Save, activate and test your BSP application.
Result
Everything runs as usual, although there is no output. In the next step, implement dynamic BSP element processing
Dynamically Processing BSP Elements

If a BSP element is located in the layout of a BSP, a compiler translates the XML syntax that represents the interface for the element in source code, which is then executed at runtime. In a simple example, (in simple pseudocode notation) this could be as follows: Element: <lib:element a1 = "v1" />
Source: DATA: e123 TYPE REF TO CL_LIB_ELEMENT. CREATE OBJECT e123. e123->a1 = v1. e123->parent = page->current_element. page->current_element = e123. e123->context = page->context. e123->DO_AT_BEGINNING( ). e123->DO_AT_END( ). page->current_element = e123->parent.
An element can, however, also require its own writer, and possibly also validation. The element can either contain body text only, or it can include inner, embedded elements that must be processed. Element: <lib:element2 a1 = "v1" /> ... </lib:element2> Source: DATA: e124 TYPE REF TO CL_LIB_ELEMENT2. CREATE OBJECT e124. e124->a1 = v1. e124->parent = page->current_element. page->current_element = e124. e124->context = page->context. e124->m_out = context->PUSH_WRITER( ). e124->RUNTIME_VALIDATION( ). IF e124->DO_AT_BEGINNING( ) = CO_ELEMENT_CONTINUE. context->current_writer->PRINT_STRING( `....` ). ENDIF. e124->DO_AT_END( ). context->POP_WRITER( ). page->current_element = e124->parent.
Furthermore, an element can specify that its body requires iteration. This suggests that the body of the element is processed more than once. Element: <lib:element3 a1 = "v1" /> ... </lib:element3> Source: DATA: e125 TYPE REF TO CL_LIB_ELEMENT3. CREATE OBJECT e125. e125->a1 = v1. e125->parent = page->current_element. page->current_element = e125.
e125->context = page->context. e125->m_out = context->PUSH_WRITER( ). e125->RUNTIME_VALIDATION( ). rc125 = e125-> DO_AT_BEGINNING( ). WHILE e125 = CO_ELEMENT_CONTINUE. context->current_writer->PRINT_STRING( `....` ). rc125 = e125->DO_AT_ITERATION( ). ENDWHILE. e125->DO_AT_END( ). context->POP_WRITER( ). page->current_element = e124->parent.
Obviously, the compiler uses the additional information about the BSP elements definition to generate the optimum code for processing the element. The same flexibility is now required for processing BSP elements externally of the actual BSP, that is, externally of the page.
From the examples above, you can see that to set an elements attributes you need a reference to the actual class, and not to interface IF_BSP_ELEMENT. Also, elements do not have methods to actually set attributes. The attributes are set directly as public attributes of the element classes. It is not effective to encapsulate the actual element class reference, or the phase in which attributes are set. If an element is processed dynamically, you must know the element class (you can find it in the BSP extension workbench). You can, however, pack the remaining code in one or more methods. You cannot encapsulate body processing, since it is not known if the body is a string, or if it consists of several embedded elements that have to be processed. Due to these design constraints, the following pseudocode can be written: DATA: eX TYPE REF TO CL_LIB_ELEMENTX. CREATE OBJECT eX. eX->a1 = v1. processing_before_body( eX ). ...body processing... processing_after_body( eX ).
This code is still not sufficiently flexible to handle element iteration. After the body has been processed, you must decide whether iteration is carried out, or if it should be stopped. The pseudocode can therefore be written as follows: DATA: eX TYPE REF TO CL_LIB_ELEMENTX. CREATE OBJECT eX. eX->a1 = v1. WHILE process_element( eX ). ...body processing... ENDWHILE. This enables users to set the element attributes first of all. Furthermore, users can be flexible when determining how inner elements are to be used.
This type of element processing method with the name ELEMENT_PROCESS is available in interface IF_BSP_PAGE_CONTEXT, which is available in every element. If a body is not required, or only a simple string body is required, processing continues as far as possible (until it is complete, if this is possible), provided that the optional body string is available. Now to processing an "empty" element. In this case, "empty" means that the element is flagged in the Workbench as empty; it does not mean that there is only an optional body. Element: <lib:eX a1 = "v1" /> Source: DATA: eX TYPE REF TO CL_LIB_ELEMENTX. CREATE OBJECT eX. eX->a1 = v1. m_page_context->ELEMENT_PROCESS ( element = eX ). If the simple element requires a body as well, this can be done when the body string is provided. Element: <lib:eX a1 = "v1" /> body string </lib.eX> Source: DATA: eX TYPE REF TO CL_LIB_ELEMENTX. CREATE OBJECT eX. eX->a1 = v1. m_page_context->ELEMENT_PROCESS ( element = eX body = body string). The body can also be written dynamically during the processing step.
Note however, that the active writer is used for writing the body. Each time a new element is (partly) processed, new writers may be pushed on the stack. The writer that is used must be the last writer that was added. Element: <lib:eX a1 = "v1" /> body string </lib.eX> Source: DATA: eX TYPE REF TO CL_LIB_ELEMENTX. CREATE OBJECT eX. eX->a1 = v1. m_page_context->ELEMENT_PROCESS ( element = eX ). DATA: out TYPE REF TO IF_BSP_WRITER. out = m_page_context->GET_OUT( ). out->PRINT_STRING( `body string` ). m_page_context->ELEMENT_PROCESS( element = eX ).
You can process inner elements by starting your processing when the external element is processed.
Ensure that you do not transfer a body to the processing code. If the body is transferred as a parameter, the system assumes that this body represents the whole body, and therefore then ends processing for that element. Element: <lib:eX a1 = "v1"> body before <lib:eY a1 = "v1"> body inside </lib:eY> body after </lib:eX>
Source: DATA: eX TYPE REF TO CL_LIB_ELEMENTX. CREATE OBJECT eX. eX->a1 = v1. m_page_context->ELEMENT_PROCESS( element = eX ). DATA: out TYPE REF TO IF_BSP_WRITER. out = m_page_context->GET_OUT( ).
out->PRINT_STRING( `body before` ). DATA: eY TYPE REF TO CL_LIB_ELEMENTY. CREATE OBJECT eY. eY->a1 = v1. m_page_context->ELEMENT_PROCESS( element = eY body = `body inside` ). out = m_page_context->GET_OUT( ). out->PRINT_STRING( `body after` ). m_page_context->ELEMENT_PROCESS( element = eX ). Iteration implies that the same body is processed until the element has enough. Element: <lib:iterator repeat = "3" /> body string </lib:iterator> Source: DATA: iterator TYPE REF TO CL_LIB_ITERATIR. CREATE OBJECT iterator. iterator->repeat = 3. WHILE m_page_context->ELEMENT_PROCESS ( element = iterator body = body string ) = CO_ELEMENT_CONTINUE. ENDWHILE.
In principle, it is always correct to write a WHILE loop around the ELEMENT_PROCESS()- call. This is the recommended technique for using this method.
As soon as an element has been processed, the element instance can not be reused, since you cannot rest all element default values like the BSP compiler does. The create object call must therefore always be executed when the same element is to be processed again. Element: <lib:eX a1 = "v1" /> <lib:eX a1 = "v1" /> Source: DATA: eX TYPE REF TO CL_LIB_ELEMENTX. CREATE OBJECT eX. eX->a1 = v1. m_page_context->ELEMENT_PROCESS ( element = eX ). CREATE OBJECT eX. eX->a1 = v1.
m_page_context->ELEMENT_PROCESS ( element = eX ).
Now create the new BSP extension with the composite elements.
Creating a New BSP Extension with Composite Elements

Use
Instead of creating a complete solution using the <htmlb:gridLayout> as in the first implementation, the following selects a two-level implementation. In the first section, a simple HTML code sequence is written using the <table> HTML element. The elements <htmlb:label> and <htmlb:inputField> are used for the actual table content. In the second step, the <htmlb:gridLayout> is added.
Finally, you will see how you can change the layout of all pages simply by changing the new elements.
Procedure
Step 1 a) Implement <sf:SimpleFormItem> Step 1 b) Use <htmlb:SimpleFormItem> Step 2: Create <sf:SimpleForm> Step 3: Changes to the Look & Feel
Step 1 a) Implementing <sf:SimpleFormItem>
Since the <sf:SimpleFormItem> requires an HTML <table> wrapper, first create the <sf:SimpleForm> element to render the correct HTML in the output stream. Within class CL_BSP_TUTCMPLX_SIMPLE_FORM, overwrite and implement the following two methods: method IF_BSP_ELEMENT~DO_AT_BEGINNING . DATA: out TYPE REF TO IF_BSP_WRITER. out = me->GET_PREVIOUS_OUT( ). out->PRINT_STRING( '<table>' ). RC = CO_ELEMENT_CONTINUE. endmethod.
method IF_BSP_ELEMENT~DO_AT_END . DATA: out TYPE REF TO IF_BSP_WRITER. out = me->GET_PREVIOUS_OUT( ). out->PRINT_STRING( '</table>' ). RC = CO_PAGE_CONTINUE. endmethod. For the actual element <sf:SimpleFormItem>, the rendering code is as follows: <tr><td> <htmlb:Label/> </td><td> <htmlb:inputField/> </td></tr> For the implementation, the HTML coding is fetched in the usual way using the current output writer, and written to the data stream.
Processing the <htmlb:*> element is slightly more difficult. Since both elements are empty (that is, they dont have a body), they can be processed in one step. The processing steps are as follows for each element: 1. Create the element class 2. Set the attributes 3. Use method ELEMENT_PROCESS for the final processing. The complete coding is then as follows: method IF_BSP_ELEMENT~DO_AT_BEGINNING .
DATA: out TYPE REF TO IF_BSP_WRITER. out = me->GET_PREVIOUS_OUT( ). * <tr><td> out->PRINT_STRING( '<tr><td>' ). * <htmlb:Label/> DATA: label TYPE REF TO CL_HTMLB_LABEL. CREATE OBJECT label. CONCATENATE me->id '_label' INTO label->id. label->encode = 'FALSE'. label->for = me->id. label->wrapping = 'FALSE'. label->text = me->label. m_page_context->ELEMENT_PROCESS( element = label ). * </td><td> out->PRINT_STRING( '</td><td>' ). * <htmlb:inputField/> DATA: inputField TYPE REF TO CL_HTMLB_INPUTFIELD. CREATE OBJECT inputField. inputField->id = me->id. inputField->description = me->description. inputField->disabled = me->disabled. inputField->firstDayOfWeek = me->firstDayOfWeek. inputField->invalid = me->invalid. inputField->maxlength = me->maxlength. inputField->password = me->password. inputField->required = me->required. inputField->showHelp = me->showHelp. inputField->size = me->size. inputField->type = me->type. inputField->value = me->value. inputField->visible = me->visible. inputField->width = me->width. m_page_context->ELEMENT_PROCESS( element = inputField ). * </td></tr> out->PRINT_STRING( '</td></tr>' ). rc = CO_ELEMENT_DONE. endmethod.
Note that you cannot make any changed to the actual output writer structures. The coding, exactly like the inner elements that are processed, is executed on the current writer. This is automatically controlled by the development environment (indirectly using the PROCESS_ELEMENT call). You can now test page after.htm. The following task appears:
Continue with Step1 b) Using <htmlb:SimpleFormItem>
Step 1 b) Using <htmlb:SimpleFormItem>

Element <sf:SimpleFormItem> has been implemented and can therefore be used. You must now ensure that each entry is rendered directly in the current output stream. If the <htmlb:gridLayout> is used later, a counter is required to count exactly the number of fields that are required so that the gridLayout and, of course, each individual cell can be configured correctly. This means that entries are first counted and then later rendered. The best way to do this is if elements <htmlb:label> and <htmlb:inputField> are rendered immediately, although not in the output stream. Instead, these elements are rendered in separate writers, in which the content is stored and the entries are counted, and with which they are finally rendered. To realize this, the entry must be changed so that it renders a string, and that this string is forwarded for rendering the <sf:SimpleForm> later. A new method ADD_ITEM is added to element <sf:SimpleForm> with the two parameters label_html and inputField_html, which are both of type string.
You can add additional methods to the BSP event handlers, which implement additional functionality, and which can in turn be used by "lesser" elements. The element handler classes are normal ABAP classes that can be processed in the Workbench. The simple coding will be as follows: method ADD_ITEM . DATA: out TYPE REF TO IF_BSP_WRITER. out = me->GET_PREVIOUS_OUT( ). out->PRINT_STRING( out->PRINT_STRING( out->PRINT_STRING( out->PRINT_STRING( out->PRINT_STRING( endmethod. The only task for ADD_ITEM at the moment to render the string immediately. In the next step, the coding is changed within <sf:SimpleFormItem>. For each internal element that is used, the element output must not be written to the current writer under any circumstance. As a result, this ensures that a new writer is pushed on the stack. Furthermore, all new elements will write to this new writer, and the context can be extracted from this new writer at any time. The changed coding is then as follows: method IF_BSP_ELEMENT~DO_AT_BEGINNING . DATA: my_out TYPE REF TO IF_BSP_WRITER, label_html TYPE STRING, inputField_html TYPE STRING. * Add own temporary writer on stack my_out = m_page_context->PUSH_WRITER( ). * <htmlb:Label/> .... label_html = my_out->GET_CONTENT( ). my_out->CLEAR( ). * <htmlb:inputField/> .... inputField_html = my_out->GET_CONTENT( ). '<tr><td>' ). label_html ). '</td><td>' ). inputField_html '</td></tr>' ). " <tr><td> " <htmlb:Label/> " </td><td> ). " <htmlb:inputField/> " </td></tr>
my_out->CLEAR( ). * Remove my writer from stack m_page_context->POP_WRITER( ). * Copy Text to <sf:SimpleForm> DATA: sf TYPE REF TO CL_BSP_TUTCMPLX_SIMPLE_FORM. sf ?= me->GET_CLASS_NAMED_PARENT( 'CL_BSP_TUTCMPLX_SIMPLE_FORM' ). sf->ADD_ITEM( label_html = label_html inputField_html = inputField_html ). rc = CO_ELEMENT_DONE. endmethod. Note the following points: The use of PUSH_WRITER() at the beginning to add an additional writer to the stack. All new elements that are now processed write to the top writer on the stack. At the end of this method, the additional writer must be removed from the stack using method POP_WRITER(). The use of methods GET_CONTENT() to extract the current string to the output, and CLEAR() to ensure that the two elements are in separate strings. The use of method GET_CLASS_NAMED_PARENT() to receive a reference to an element that is located "further up" in the element stack. The call of method ADD_ITEM(), which represents a local method that is defined by the element.
You can now execute page after.htm again to ensure that it still runs correctly. The element <sf:SimpleFormItem> is then complete. This section has described how BSP elements are processed on the stack. We have also described how the output of this type of element can be written to a string, so that it can be rendered later. For more information, see Step 2: Creating <sf:SimpleForm>
Step 2: Creating <sf:SimpleForm>
The next step after Step 1: Using <htmlb:SimpleFormItem> is similar. You must first enhance the simple form handler class so that the entries are not written as soon as they are added. The entries must be collected and rendered at the end. Add two string tables as class attributes to class CL_BSP_TUTCMPLX_SIMPLE_FORM: Name LABELS INPUTFIELDS Type Instance attribute Instance attribute Visibility private private Typing Type TYPE TYPE Reference Type STRING_TABLE STRING_TABLE Description Table of strings Table of strings
Change the ADD_ITEM method to collect the entries: method ADD_ITEM . APPEND label_html TO labels. APPEND inputField_html TO inputFields. endmethod.
Ensure that an element handler class can be reused several times. This is triggered by the code generator for the BSP. This is why the whole local data structure must be reset each time that a new element is restarted. The coding that is executed at the beginning must be changed as follows: method IF_BSP_ELEMENT~DO_AT_BEGINNING . CLEAR labels. CLEAR inputFields. RC = CO_ELEMENT_CONTINUE. endmethod.
In the last step, the whole rendering should be executed at the end tag of the element. The coding for the output would therefore be as follows:
<htmlb:GridLayout > LOOP AT labels/fields <htmlb:GridLayoutCell > output "label" string </htmlb:GridLayoutCell> <htmlb:GridLayoutCell > output "inputfield" string </htmlb:GridLayoutCell> ENDLOOP. </htmlb:GridLayout> Here, the most interesting point is that tags must be processed with bodies. An element would usually be processed by a WHILE loop, while PROCESS_ELEMENT is called at the end. As a result, both the start and the end tag are processed. After the first processing call, the element was pushed on the processing stack and is therefore available as if the compiler had generated the code. After the inner tag has been processed, the second call of PROCESS_ELEMENT is required for processing the end tag. The <htmlb:gridLayout> is processed in the first part of the coding. There then follows a LOOP, in which all of the calls are executed, and finally the end tag </htmlb:gridLayout> must be processed. Ensure that the whole output is written to the currently active writer. The coding is as follows: method IF_BSP_ELEMENT~DO_AT_END . * <htmlb:gridLayout> DATA: gridLayout TYPE REF TO CL_HTMLB_GRIDLAYOUT. CREATE OBJECT gridLayout. gridLayout->id = me->id. gridLayout->cellSpacing = '0'. gridLayout->cellPadding = '2'. gridLayout->rowSize = lines( labels ). gridLayout->columnSize = 2. gridLayout->width = '100%'. m_page_context->ELEMENT_PROCESS( element = gridLayout ). * Output all cells. DATA: label TYPE STRING, inputField TYPE STRING. LOOP AT labels INTO label. READ TABLE inputFields INTO inputField INDEX sy-tabix. ....code to process gridLayoutCell for label and for inputField ENDLOOP. * </htmlb:gridLayout> m_page_context->ELEMENT_PROCESS( element = gridLayout ). rc = CO_PAGE_CONTINUE.
endmethod.
Processing the <htmlb:gridLayoutCell> element is slightly more complex. The reason for this is that for each cell, the current body (the HTML string that was previously collected) must be written to the output stream. The coding is therefore split into three steps. First the start tag is processed, then the body is written to the current output writer, and finally the end tag is processed. For the <htmlb:label> string, the coding is as follows: * <htmlb:gridLayoutCell> for label DATA: gridLayoutCell TYPE REF TO CL_HTMLB_GRIDLAYOUTCELL. CREATE OBJECT gridLayoutCell. gridLayoutCell->rowIndex = sy-tabix. gridLayoutCell->columnIndex = 1. gridLayoutCell->horizontalAlignment = 'LEFT'. gridLayoutCell->verticalAlignment = 'MIDDLE'. m_page_context->ELEMENT_PROCESS( element = gridLayoutCell ). * print content DATA: out TYPE REF TO IF_BSP_WRITER. out = me->m_page_context->GET_OUT( ). out->PRINT_STRING( label ). * </htmlb:gridLayoutCell> m_page_context->ELEMENT_PROCESS( element = gridLayoutCell ).
Ensure that the output writer that is currently active is not received until just before it is used. It is important that GET_OUT() is called each time an element is processed. Every element can push additional writers on the stack, even the BSP framework can add its own writer to the stack from time to time. If only one single writer is received at the start of the method, this is therefore probably the parent writer of the gridLayout, that is, all of the new output is written to the parent writer of the gridLayout. It is therefore important that the new active writer is always received after a PROCESS_ELEMENT call and before the new output. The method PROCESS_ELEMENT is aligned with element processing, even if they require iteration. In theory, after every write/processing cycle the system should check explicitly whether the element has finished. In this case, the element does not include iteration. PROCESS_ELEMENT can therefore be called again without any problems. In cases where only one body must be written, particularly if the body is already present as a string, the body can be transferred as a parameter of the PROCESS_ELEMENT method. A writer is
not required, and the processing code automatically writes the body correctly and finished processing the method. The more simple coding is as follows (here string inputField is used as an example): * <htmlb:gridLayoutCell/> for inputField CREATE OBJECT gridLayoutCell. gridLayoutCell->rowIndex = sy-tabix. gridLayoutCell->columnIndex = 2. gridLayoutCell->horizontalAlignment = 'LEFT'. gridLayoutCell->verticalAlignment = 'MIDDLE'. m_page_context->ELEMENT_PROCESS( element = gridLayoutCell body = inputField
).
Ensure that the gridLayoutCell object is not reused. This is expressly forbidden. It must be newly created each time a new element is required. In the last step, you make changes to the look and feel.
Step 3: Changes to the Look and Feel

After <sf:SimpleForm> is implemented, there may be requirements for visualization, such as in our example that all field names should be formatted in bold. This is the advantage of composite elements. Instead of having to individually change all of the BSP elements that were already created, you only need to make one small change to a single BSP element. Within the coding for <sf:SimpleFormItem>, the change from: label->text = me->label.
to: CONCATENATE '<b>' me->label '</b>' INTO label->text. causes the following task:
Model View Controller (MVC)

Use
SAP Web Application Server 6.20 has implemented the Model View Controller (MVC) design pattern, which is widely used in the user interface programming field and which has proved its worth, as an extension of the previous BSP implementation model. Its controller-based use ensures an even clearer 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 advantages:
Structuring BSP applications is simplified, since the view is cleanly separated from the controller and the model. This not only facilitates changing BSP applications, but also considerably improves their maintenance. 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. Furthermore, you remain in the same work process, which can have advantages for creating objects and memory space. The call using <bsp:call> element is more variable than adding them using INCLUDEdirective, since it is triggered at runtime. With the call option using <bsp:call>, you can also distribute the user interface into components. Optimized performance due to fewer redirects. Intuitive and east-to-use interface for application development. Previous BSP applications, that is, BSP applications without MVC, can still be executed without requiring any changes. 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.
Functions
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.
Controllers
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 The controller also takes care of event handling. It takes on all of the tasks that were executed in the previous BSP programming model by the event handlers: It carries out initialization and request processing, manages data transfer and is responsible for managing views and controlling a views lifetime.
Redirects from the controller or page to the controller or page can be easily implemented. See also Navigation If it cannot be decided until input processing which page should follow, 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, and 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 can result in a complex tree structure of controllers and components can be formed (that consist 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 nor auto-page attributes, nor their own URL. Unlike auto-page attributes, normal page attributes can be used, which 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.
Models
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, refer to: Using MVC for BSP Class CL_BSP_CONTROLLER2 Navigation Lifetime BSP Component Call Options Components
Activities
Creating a Controller Creating a View Calling a Controller Calling a View Creating Error Pages
A simple Tutorial is available for your first steps with the MVC design pattern. The general bookshop tutorial for BSP contains a more extensive MCV tutorial: Our Online Bookshop Using MVC and HTMLB.
Example
You can find an example of MVC in the system in BSP application BSP_MODEL. Furthermore, the following Architecture Examples are outlined:
BSP Application with Controllers and Views BSP Application with Several Views per Controller Combination of the Previous Examples Calling Controllers of Other Applications Calling Several Controllers from a View
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.
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). 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.
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
1. 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.
2. 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.
3. 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.
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
1. 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. 2. Specify the layout and any attributes that may be required. 3. Save and activate your view.
Example
You can find examples of views in BSP application ITMVC2.
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
1. Place your cursor on the top controller in your BSP application. 2. Click on (Test/Execute) in the application toolbar. The browser starts and a logon screen may be displayed. 3. Log on to the system if this is necessary.
Result
The selected controller is started in the browser.
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
1. Create the controller instance. You have the following options: o data: l_ctrl type ref to cl_bsp_controller. l_ctrl = create_controller( key = navigation_key ). or o 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( ). 2. Set additional attributes: l_ctrl->set_attribute( name = name value = value ). 3. Call the request: call_controller( l_ctrl ).
Calling (Sub) Controllers

1. 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. 2. Call your sub-controller. a. 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.
a. 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. a. 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-controllers public attributes directly.
a. You can execute the parameter transfer from the view. <bsp:call> <bsp:parameter name = "" value = "" /> </bsp:call>
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
1. Create the view instance. data: l_view type ref to if_bsp_page. l_view = create_view( key = navigation_key ). or l_view = create_view( view_name = 'next.htm' ).
Note that you can call views only from your own application. 2. 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' ). 3. Call the view layout: call_view( l_view ).
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
1. You created the page (the controller) you want to use as error page. See also: Creating Pages or Creating Controllers. 2. You cannot assign an error page to a page or a controller that itself is marked as error page. 3. 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: 2. ... 3. Select the page or the controller for your BSP application. 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.
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
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 pagebased 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
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.
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.
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 controllers 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 subcontroller 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.
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: DATA: view TYPE REF TO if_bsp_page. view = create_view( view_name = 'main.htm' ). Do not use: DATA: view IF view IS INITIAL. view = 'main.htm' ENDIF. TYPE REF TO if_bsp_page. NOT BOUND. " or IS NOT create_view( view_name = ).
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
1. Structures
2. 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 (//...). 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:
1. The content of the attribute is assigned to the input field value using the above statement. 2. This generates the ID from the model. 3. Additional attributes are also generated, for example, one that determines whether fixed values exist. 4. User input is transferred to the model class at the next request. 5. 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>
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 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.
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: 1. With components, there are complex call sequences during an HTTP request. 2. The individual parts, of which a page in the browser consists, are dynamically assembled during runtime. 3. One component can call a different component. It should therefore be placed in a view. This is done using the <bsp:call> element. 1. 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.
Activities
5. 6. 7. 8. 1. 2. 3. 4. 4. ... Creating the top-level controller Creating a Component Calling the Component Determing the Input Processing
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. 2. Then call DO_INITATTRIBUTES. 3. 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. a. 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. ii. iii. iv. v. Handling events
DO_REQUEST determines whether data must be fetched from the model or from the global attributes. DO_REQUEST fetches the table with the object keys from the top-level controller. DO_REQUEST requests a view. DO_REQUEST sets the correct attributes for the view. DO_REQUEST calls the view.
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)
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 subcontroller can query its parent controller for the COMP_ID of each additional sub-controller.
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, and a third team is responsible for developing the models.
Process
1. 2. 3. 4.
Create the top-level controller Create a component Call the component Determine the input processing
Creating the Top-Level Controller

Procedure
1. 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. a. Enter a unique class name for the controller. b. 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. 9. Branch to the Methods tab page.
a. 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.
b. If necessary, overwrite method DO_INIT. c. 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.
a. In the following example, the view is called main.htm.

b. Fill the view layout with HTML coding or HTMLB coding. c. Save the view. 12. Activate and test your finished BSP application.
Continue by Creating Components.
Creating Components
Procedure
1. 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).
2. 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.
a. 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.
b.
1. Create one or several views. 2. Activate the views.
Continue by Calling the Components.
Calling Components
Use
You can call a main controller, sub-controller in two ways: A. By creating the sub-controller in a method of the main controller B. 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 1. 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( ... ). ... 2. 3. 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 ). ... 4.
5. 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>
Continue by Determining Input Processing.
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). 2. 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. 3. 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.
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. Processing Process 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 DO_HANDLE_DATA DO_HANDLE_EVENT Description Reacts to user input. Processes data input for this component. 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 DO_INIT Description 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 CREATE_VIEW Description Creates or fetches a view instance Use either the name of the view, or the navigation. object
A view must always belong to the same BSP application as its controller.
CALL_VIEW CREATE_CONTROLLER CALL_CONTROLLER
Calls the request handler of the view instance. Creates or fetches a controller instance Calls the request handler (method DO-REQUEST) of the controller instance. Returns the specified page attributes. Generic method for reading an attribute value. Returns the lifetime of this page (only for the top-level controller) Returns the URL of the page or the current controller Sets the specified page attributes. Generic method for setting an attribute value. Changes the lifetime of this page (only for the toplevel controller) Creates a formatted string Writes a formatted string in the output Fetches the current output writer Changes the MIME type of the page or the content type of the header field Instantiates the parameter from the request using the request data Changes the caching values There are two types of caching: Browser cache Server cache Caching BSPs.
GET_ATTRIBUTE GET_LIFETIME GET_PAGE_URL SET_ATTRIBUTE SET_LIFETIME TO_STRING WRITE GET_OUT SET_MIME_TYPE INSTANTIATE_PARAMETER SET_CACHING
See also
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 SET_MODEL CREATE_MODEL GET_CONTROLLER CONTROLLER_SET_ACTIVE Calculates the ID from the specified ID and the component ID Creates and registers a model instance Creates and registers a model instance Fetches a sub-controller Sets a controller to active/inactive. This is relevant with input processing, since you can use it to hide a controller. See also Lifetime Deletes a model instance Fills the model data Deletes a sub-controller Fetches a model instance Is this controller a top (main) controller (0: no, 1: yes)? Has a controller requested a navigation (0: no, 1: yes)?
DELETE_MODEL FILL_MODEL_DATA DELETE_CONTROLLER GET_MODEL IS_TOPLEVEL IS_NAVIGATION_REQUESTED
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 IF_BSP_DISPATCHER~REGISTER Description Registers a sub-components
IF_BSP_CONTROLLER~FINISH_INPUT_PROCESSING IF_BSP_CONTROLLER~FILL_VALUES IF_BSP_CONTROLLER~HANDLE_EVENT GET_FIELD_COMPONENT GET_FIELD_MODEL
Processes or dispatches: end of input processing. Processes or dispatches: handling values Processes or dispatches: Handle event Finds components for a field name Finds model for a field name
Methods DO_DESTROY and SUBSCRIBE are not relevant.
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
BSP Application with Controllers and Views

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 views, 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.
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.
Does this also work with several BSP applications? Of course!
Calling Controllers of Other Applications

You can also call controllers of other BSP applications:
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.
Model View Controller Tutorial

Uses
In this tutorial you can use a simple example to run through the first steps with the Controller design pattern for BSP. Model View
The general bookshop tutorial for BSP contains a more extensive MCV tutorial: Our Online Bookshop Using MVC and HTMLB.
Prerequisites
You are in an SAP Web AS 6.20 system You know how to use MVC for BSPs
Functions
Creating a View Calling a Controller
Prerequisites
You have created an empty BSP application for this tutorial.
Procedure
1. Create a controller within your BSP application. To do this, choose Create Controller.
2. On the following dialog box, give the controller a name and add a short description.
3. Choose
. 4. On the following screen, assign a class name to the controller. The class does not have to exist yet.
5. 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.
6. Choose the 7.
symbol to branch to the change mode in your class.
Se lect method DO_REQUEST and choose symbol to overwrite the methods.
8. 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. 9. Activate your class and your BSP application. 10. 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.
Confirm the following confirmation prompts. 11. You can now test the new controller page that you have created.
Result
Continue by creating a view.
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
9. 5. ... 1. Begin as if you are creating a normal page with flow logic in your BSP application.
To do this, choose Create Page.
10.
2. In the following dialog box, enter a name and short description of the view and select View as the page type:
11. 12.
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:
13.
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>
14. 15.
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( main_view ). 16. endmethod. 8. Activate your class and test your controller.
Result
You have created your own view for the layout.
Continue by Calling the Controller.
Calling a Controller
Use
You can call a controller from a page with flow logic, or from a view.
Procedure
1. Create a page within your BSP application. Ensure that you select Page with Flow Logic as the page type.
2. In the Tag Browser, select BSP extension bsp and drag it to the second line of your
BSPs layout under the page directive.
3. 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> 4. 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>
5. You can now try out the difference between the <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.
6. 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.
Session Handling
BSP applications can be implemented as both stateful and stateless applications. The term stateless does not mean that request data for a running application is not retained on principle; it refers to whether in the SAP Web Application Server the application context (also called Roll Area) is retained for individual requests, or whether it is released following each request. If you want to keep large datasets about request limits in the server (in internal tables), this can be done either by working in stateful mode, that is, retaining data using the Application Class or by Using Server-Side Cookies in a stateless application. Both ways have advantages and disadvantages, which are explained in the following sections. A running BSP application regardless of whether it is HTTP stateful or stateless is referred to as a session from here on. The start and end of a session is determined either by the user externally (compare System-Specific URL-Parameters) or by the application itself and then only the end is determined. The following topics are dealt with: Stateful BSP Applications Stateless BSP Applications Hybrid Forms Setting Stateful or Stateless Stateful or Stateless Programming?
Stateful BSP Applications

A stateful BSP application is executed like a normal SAP transaction, independent of all user interactions - in one single context (roll area). This means that data specified by the user during the application execution or data determined by the application itself is available potentially throughout the entire execution duration of the session. Since the HTTP protocol itself operates in stateless mode and knows no implicit mechanism to assign independent requests to a common logical session, the BSP runtime uses Session Cookies to group requests into one common session. The name of the cookie is sap-contextid, the validity area is restricted to the URL of the BSP application. This means that a BSP application can be executed within a browser only once at any one time. Different BSP applications can operate in parallel in the same browser. Multiple users/browsers can execute the same BSP application in parallel as often as required.
Advantage
The main advantage of stateful BSP applications is that they are simple to program. As usual, you have access to data determined previously and reading or re-calculating data can often be omitted. For database-intensive applications, this can lead to considerably better system performance compared to a procedure where identical read operations have to be executed for every request.
Disadvantage
This significant advantage is at the same time however a disadvantage the improved runtime is offset by a larger memory requirement. The number of possible parallel sessions in an SAP Web Application Server is restricted not least by the amount of available memory space. When this space is exhausted, no further sessions can be started and users cannot log on. A further advantage is the fact that, unlike SAPGUI, Web browsers do not log off servers, that is, if users navigate in their Web browsers to a different Web site, the SAP Web Application Server is not be informed. Thus, an open session cannot be terminated and is retained in the application server until the context is released by the timeout mechanism. Since this can take some time, scarce resources are unnecessarily blocked in the application server.
Note that with stateful applications, the application status can be easily distinguished from the status users accept based on their interface. This can be caused by users navigating in the browser history or using the browser Back button - information that is not necessarily passed on to the server. So a user may navigate back to a Web site and the Web site sends the information again even though the application is expecting other requests. Measures are required in the application to deal with this. In the next release, we plan to provide at least one detection mechanism.
See also: Stateless BSP Applications Hybrid Forms Setting Stateful or Stateless Stateful or Stateless Programming?
Session Cookie
Definition
A cookie is an HTTP mechanism that enables an HTTP server to store limited amounts of data in an HTTP client. This data can then be sent back to the server for requests based on specific criteria. There are two types of cookie: persistent cookies, which are usually saved on the hard disk of the client until an expiry date and session cookies, which are not saved in the file system; they are kept only in the memory of the client (for example, the Web browser) until this is closed. As such, session cookies involve no security risks and are deleted immediately the browser window is closed. Some browsers now differentiate between these two cookie types and, if required, only inform the user when persistent cookies are received, which require the users confirmation.
Integration
The next version of the SAP Web Application Server will also support applications with no cookies at all.
Stateless BSP Applications

Stateless BSP applications only block resources on the SAP Web Application Server during the time one single request is being processed. When the request has been processed, all resources in particular the application context are returned to the system for use in other requests.
Stateless applications allow - at least from the viewpoint of the memory resource optimal scaling regardless of the number of users. On the other hand, releasing the application context after every request may mean that identical data is read from the database and formatted multiple times. In this respect, the runtime may offset the memory saving. This should be evaluated and analyzed on a case by case basis.
Rule of Thumb: Stateful or Stateless?

As a rule of thumb, it is recommended that Internet scenarios used at the same time by a large number of users operate in stateless mode. Stateful programming is recommended for more complex applications that are used by a limited number of users in parallel and that operate with data that is expensive to determine.
Retaining Information in Stateless Mode Through Multiple Requests

The question arises of how to save information in stateless applications, such as user entries, across multiple requests despite the loss of the application context after each request. For this purpose, you must program the following functions for the application. Possible technical solutions include the following options: Temporary (Invisible) Storage of Data on the Web Site Itself: This can be done by means of what are called HTML hidden fields, for example: <input type=hidden name="customerID" value="4711">
You can include hidden fields by implementing a page fragment, which is embedded in each page of the application. You can easily define the attributes you want to save in the application class itself. The page fragment is then embedded in each Web site. The application attributes from the request (we are working in stateless mode) are restored in the OnRequest event handler of the page (or preferably in the ONREQUEST method of the IF_BSP_APPLICATION interfaces. You should pay particular attention to hyperlinks and to including the parameters you want to save, for example, in the query string part of the URL from the application. Storing Data in Client-Side Cookies: You must ensure that the size and number of cookies that can be saved in a Web client/browser is strictly limited. Server-Side Cookies: The BSP runtime provides a generic mechanism known as server-side cookies that can be used to efficiently store data types of any kind and number. For more information see Class CL_BSP_SERVER_SIDE_COOKIE as well as Data Persistency With Server-Side Cookies. Application-Specific DB Table for Temporary Data Storage
The application provides a database table specially designed to meet the specific requirements of the data to be saved. Unlike server-side cookies appropriate typed tables can be used here. These tables can provide for better performance than the generic solution. However, this solution involves considerable application programming (in particular, release of the database entry). The session ID can be used to identify an entry and can be accessed through the programming interface IF_BSP_RUNTIME. See also: Stateful BSP Applications Session Cookie Hybrid Forms Setting Stateful or Stateless Stateful or Stateless Programming?
Server-Side Cookies and Data Persistency

Use
You can use server-side cookies to make data persistent, especially page attributes. To do this you use simple ABAP statements in the event handlers OnManipulation and OnRequest, combined with methods of the class for server-side cookies: Using export you can store the data (strings) as a cluster in database tables and you can transfer them back again using import. Class CL_BSP_SERVER_SIDE_COOKIE provides methods to set, fetch, delete and manage cookies in the server.
Server-side cookies are persistent data, similar to the usual client-side cookies. Whereas the size of cookies on the client is restricted to four kilobytes per cookie, 300 cookies in total, and 30 per server or domain, server-side cookies do not have any size or quantity restrictions.
Server-side cookies consist of large datasets that are customized and stored on the server. They are not transferred between client and server.
Functions
In the specified event handlers you use the following ABAP expressions and class methods: OnManipulation: o o export (required page + controller + page attributes) to buffer XSTRING. CL_BSP_SERVER_SIDE_COOKIE->method for buffer(XSTRING).
OnRequest: o o CL_BSP_SERVER_SIDE_COOKIE->method for retrieval(XSTRING). import (required page + controller + page attributes) from buffer XSTRING.
The steps listed here are explained in more detail in the example below.
Example
In the following example you can see how, in a BSP, simple ABAP statements are used to group the page parameters (strings) using export in one object. The cookie is then stored with method SET_SERVER_COOKIE of class CL_BSP_SERVER_SIDE_COOKIE. Similarly the cookie can be fetched again with GET_SERVER_COOKIE and returned with import.
Page Attributes
This example contains some important page attributes that are to be defined as persistent. The list of page attributes looks like: Page Attributes Attribute Name LAST_STRING_ADDED NEXT_STRING STRINGS x Auto Typing Type type type type Reference Type STRING STRING STRING_TABLE Description Last string added by user Next string Table of strings
Not all page attributes should be persistent- only the strings added by users. They are displayed in a table on the interface. Therefore, in this BSP application only the strings LAST_STRING_ADDED and STRINGS are to be made persistent.
Event Handler
In this BSP application the following event handlers are important:
OnRequest This event handler is always triggered with inbound requests to restore the persistent data.
OnManipulation This is the last event handler before the response is sent. In this event handler the new values of the page attributes are stored in the form of server-side cookies.
OnManipulation is described first of all to explain the storage concept. OnManipulation In this event handler the values of specific page attributes are saved in the server-side cookie. Both parameters are saved on the server and then combined in one object. The user details are written to the page data using the ABAP statement export.
The export syntax is: export object1 from F ... Objectn from F to data buffer F. A data cluster is stored in data buffer f, which must be of type XSTRING. All page attributes that are relevant here are described in a byte sequence of variable length (XSTRING).
In this BSP we use the following code to receive XSTRING: data: PAGE_DATA type XSTRING. data: NAME type STRING.
export LAST_STRING_ADDED from LAST_STRING_ADDED STRINGS from STRINGS to data buffer PAGE_DATA.
Next we have to make the server-side cookie XSTRING persistent: NAME = SY-UNAME.
call method CL_BSP_SERVER_SIDE_COOKIE=>SET_SERVER_COOKIE exporting NAME = 'my_page_data' APPLICATION_NAME = RUNTIME->APPLICATION_NAME APPLICATION_NAMESPACE = RUNTIME -> APPLICATION_NAMESPACE USERNAME = NAME SESSION_ID = 'same_for_all' DATA_NAME = 'page_data' DATA_VALUE = PAGE_DATA EXPIRY_TIME_REL = 3600 . The export parameters mean: Parameters NAME APPLICATION_NAME APPLICATION_NAMESPACE USERNAME SESSION_ID DATA_NAME DATA_VALUE EXPIRY_TIME_REL Details of relative expiry time. Name and value of the data; these parameters must match. Meaning Any name can be chosen for the cookie Parameters which refer to the cookie and uniquely identify it. These are the name of the BSP application, the namespace of the BSP application, the user name and the session ID.
OnRequest
In this event handler the internal data structures of the requests are restored. The persistent page attributes are returned by the server-side cookie. So there are many parallels with the event handler OnManipulation. The server-side cookie is fetched by calling method GET_SERVER_COOKIE of class CL_BSP_SERVER_SIDE_COOKIE. The meaning of the parameters is essentially the same as for the parameters for the event handler OnManipulation (see above); only that here DATA_VALUE is a changing parameter. data: PAGE_DATA type XSTRING. data: NAME type STRING.
* User administration can, for example, use the ABAP system name NAME = SY-UNAME.
* The server-side cookie is fetched call method CL_BSP_SERVER_SIDE_COOKIE=>GET_SERVER_COOKIE exporting NAME = 'my_page_data' APPLICATION_NAME = RUNTIME->APPLICATION_NAME APPLICATION_NAMESPACE = RUNTIME -> APPLICATION_NAMESPACE USERNAME = NAME SESSION_ID = 'same_for_all' DATA_NAME = 'page_data' CHANGING DATA_VALUE = PAGE_DATA .
Provided that the data values do actually have values and therefore are not empty, the persistent page attributes are now restored by the server-side cookie. This is implemented by the ABAP statement import.
The syntax of import is: import Object1 = F ... Objectn = F from data buffer F. The data object (or several data objects) are imported from the specified data buffer F, which must be of type XSTRING. All data that has been stored using export ... to data buffer (see above) in the data buffer F and listed here, is imported. The system checks that the structure for export and import corresponds. In our example the call to restore the persistent cookies is: if PAGE_DATA is not initial. import LAST_STRING_ADDED = LAST_STRING_ADDED STRINGS = STRINGS from data buffer PAGE_DATA. endif.
See also:
You will find this example in the system in BSP application it00 (package SBSP_TEST) on page misc_page_persistence.htm.
Hybrid Forms
Realistically, the situation often arises in applications where neither one or the other model is the most suitable at all times. A typical example of this would be the online store, where browsing and navigating through the product catalog can very well be done in stateless mode, but where the actual ordering operation including first-time registration is, for technical reasons, very often realized in stateful mode. These scenarios are handled by switching the mode can be switched between stateful and stateless at runtime. See also: Stateful BSP Applications Stateless BSP Applications Stateful or Stateless Programming?
Setting Stateful or Stateless

You can classify a BSP application in two types stateful or stateless:
1. During development in the development environment (transaction SE80):
You can define a BSP application as stateful by selecting the BSP application characteristic Stateful. If the checkbox is deactivated, the BSP application is working in stateless mode.
2. At runtime using the programming interface IF_BSP_RUNTIME (compare Object

Runtime): At any given time, a BSP application can be switched from stateless to stateful (and vice versa). This would make sense, for example, if you wanted to retain the roll area for a few consecutive pages but not for the whole application. You can set this by setting or deleting the attribute KEEP_CONTEXT of the IF_BSP_RUNTIME interface at runtime. The runtime definition overrides any definitions made in the development environment. See also: Stateful or Stateless Programming?
Stateful or Stateless Programming?
As described in Stateless and Stateful Model, the underlying framework supports both stateful (user context in SAP System is maintained) and stateless (user context is terminated and regenerated for every request) modes. This process is represented in the following graphic:
1. 2. 3. 4. 5. 6. 7.
The first user enters the shop. The second user enters the shop. User 1 puts a book in his or her shopping basket. The third user enters the shop. User 3 puts a book in his or her shopping basket. User 1 places his or her order. User 2 performs an action.
In stateless mode, the process looks like this:
The numbers indicate which user performs each action. The time progression clarifies the sequence of events.
When Should Stateful Mode Be Used?

When developing a BSP application, you should weigh up the advantages and disadvantages of stateful and stateless modes. If a status needs to be maintained over a number of pages (for example, items in a shopping basket), stateful mode or the use of client-side cookies is advisable. If the application is working with stateful mode, the user context must not be kept over the entire flow logic of the BSP application. Alternatively, stateful mode could just be implemented for the length of time the status needs to be retained. It can be switched at any time to stateless by using the command RUNTIME->KEEP_CONTEXT = 0. Stateless mode is more suitable for applications that do not require any status information, as this mode avoids unnecessary use of SAP System resources.
How to Set the Mode

When a BSP application is created, this mode can be set by accessing the runtime object dynamically or in the development environment for the whole BSP application. This is described in the section Setting Stateful or Stateless Mode. Stateful means that the Object Application, specified by the application class is retained (see also Application Class of BSP Application). In stateless mode, the object is reset.
This is demonstrated in the example below: A Sample BSP Application
A Sample BSP Application

There is a sample BSP application called stateful_stateless_sample in your system (package SBSP_SAMPLES). It contains the application class thtest, which consists of only one attribute of type STRING, as well as 3 BSPs. On the first page, default.htm, you choose whether you want to work in stateful or stateless mode. Depending on what you choose, the value RUNTIME->KEEP_CONTEXT is set to 0 or 1. Whichever you choose, the application navigates to the page page1.htm. On this page, you can set the initial string of the application class by entering it in a HTML field. Choose to second page to navigate to the next page, page2.htm. On this page, the string in stateful mode has the value just set; in stateless mode the string is empty (initial) again. This is because in stateful mode the instance of the Application Object always retains its current value in the user context. In stateless mode, the object is re-generated on page1.htm when the application object is accessed. The graphic below illustrates the process.
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
BSP Only with Layout

Overview
This simple BSP merely consists of the layout. This layout: has the scripting language ABAP contains static HTML contains server-side scripting
In the Web Application Builder, the layout of this BSP looks as follows: <%@page language="abap"%> <html> <body> <center> <% do 5 times. %> <font size=<%=sy-index%>> Hello World! <br> </font> <% enddo. %> </center> </body> </html> See also: tutorial_1 in packet SBOOKSHOP or First Steps with the Business Server Pages
Processing Process
The individual steps that are followed when processing this BSP are as follows: The user calls a BSP application in the browser or enters an appropriate URL. An HTTP-GET request is sent to the BSP runtime.
The BSP runtime determines the suitable BSP application and the BSP that is called. Since the BSP only consists of the layout, the page layout that is established there is determined and the scripting code is processed. The BSP runtime then generates a suitable response. and sends it to the browser that displays the BSP.
BSP With Layout and Initialization

Overview
This simple BSP contains the layout, a page attribute and event handler OnInitialization. This outputs the title, publisher and ISBN of all books in the database table BSBOOK that were published in the year 2000. This BSP is as follows in the Web Application Builder: Layout <%@page language="abap"%> <html> <body> <h2> Book list </h2> <table border=1> <tr> <th>Title</th> <th>Publisher</th> <th>ISBN</th> </tr> <% data: wbook like line of books. loop at books into wbook. %>
<tr> <td><%= wbook-title %></td> <td><%= wbook-publisher %></td> <td><%= wbook-ISBN %></td> </tr> <% endloop. %> </table> </body> </html> OnInitialization select * from bsbook into table books where publyear = '2000'. Page Attributes Attribute Name books automatic Typing Type TYPE Reference Type BOOK_TAB Description Booklist
The internal table books of type BOOK_TAB is filled in OnInitialization.
Processing Process
The individual steps that are followed when processing this BSP are as follows: The user calls a BSP application in the browser or enters an appropriate URL. An HTTP-GET request is sent to the BSP runtime. The BSP runtime determines the suitable BSP application and the BSP that is called. In the BSP, data is retrieved using OnInitialization. Table BSBOOK is read for those book entries that were made in the year 2000. The scripting code is processed in the layout and the page is rendered: An HTML table is output and filled with content. The BSP runtime then generates a suitable response and sends it to the browser that displays the BSP.
This example can be enhanced by adding a second BSP with navigation: BSP Application with Layout and Initialization
BSPs with Layout, Initialization and Navigation

Overview
This simple BSP applications contains two BSPs with layout, page attributes and the event handler OnInitialization. Depending on the user input for the year of publication, the next page displays various lists of books in table form. These BSPs are as follows in the Web Application Builder: Layout of startpage.htm <%@page language="abap"%> <html> <head> <link rel="stylesheet" href="../../sap/public/bc/bsp/styles/sapbsp.css"> <title> Selection Page </title> </head> <body class="bspBody1"> Year of Publication: <form method="post" action="page2.htm" > <select name="sel_publyear"> <option value="2000"> Year 2000 <option value="2001"> Year 2001 </select> <input type="submit" value="Select">
</form> </body> </html> Layout of page2.htm <%@page language="abap"%> <html> <body> <h2> Book list </h2> <table border=1> <tr> <th>Title</th> <th>Publisher</th> <th>ISBN</th> </tr> <% data: wbook like line of books. loop at books into wbook. %> <tr> <td><%= wbook-title %></td> <td><%= wbook-publisher %></td> <td><%= wbook-ISBN %></td> </tr> <% endloop. %> </table> </body>
</html> OnInitialization of page2.htm data: year type int.
year = request->get_form_field( 'sel_publyear' ).
select * from bsbook into table books where publyear = year. Page Attribute of page2.htm Attribute Name books automatic Typing Type TYPE Reference Type BOOK_TAB Description Booklist
The internal table books of type BOOK_TAB is filled in OnInitialization.
Processing Process
The individual steps that are followed when processing this BSP are as follows: The user calls a BSP application in the browser or enters an appropriate URL. An HTTP-GET request is sent to the BSP runtime. The BSP runtime determines the suitable BSP application and the BSP that is called: startpage.htm. The layout is assessed, since this page only has layout. The BSP runtime generates the page and sends it to be displayed at the browser. In the pulldown menu, the user selects the required year of publication and selects the pushbutton. An HTTP-POST request is now sent to the BSP runtime. This POST request requests a different page, page2.htm. Event handler OnInitialization is assessed by this second page. Table BSBOOK is read for those book entries that were published in the year specified by the user. The scripting code is processed in the layout and the page is rendered: An HTML table is output and filled with content. The BSP runtime then generates a suitable response and sends it to the browser that displays the BSP.
BSPs with Layout, Initialization and Input Processing

In this example, there is a CD page as well as a book page. The CD page should be aligned with the distribution of CDs. Furthermore there is also user input, which outputs the book page or the CD page depending on the category that was selected on the selection page.
Overview
These BSPs are as follows in the Web Application Builder: Layout of select.htm <%@ page language="abap" %> <html> <body> <h2> Select CDs or Books! </h2> <form method="post" > <select name="sel_category"> <option value="0001"> Books <option value="0002"> CDs </select> <input type="submit" name="OnInputProcessing(select)" value="Select"> </form> </body> </html>
OnInputProcessing of select.htm * event handler for checking and processing user input and
* for defining navigation
data: cat type string.
case event_id.
when 'select'.
cat = request->get_form_field( 'sel_category' ).
if cat = '0001'. navigation->goto_page( 'books.htm' ). elseif cat = '0002'. navigation->goto_page( 'cds.htm' ). endif.
endcase. Layout of books.htm <%@ page language="abap" %> <html> <body>
<h2> All books </h2>
<table border=1> <tr> <th></th> <th>Title</th> <th>Author</th> <th>Publisher</th> <th>ISBN</th> </tr> <% data: wbook like line of books. loop at books into wbook. %> <tr> <td><img src="../../bookstore2/<%=wbook-category%><%=wbook-id %>_s.jpg"></td> <td><%= wbook-title %></td> <td><%= wbook-author %></td> <td><%= wbook-publisher %></td> <td><%= wbook-id %></td> </tr> <% endloop. %> </table>
</body> </html> OnInitialization of books.htm select * from bsparticle into table books where category = '0001'.cds
Page Attribute of books.htm Attribute Name books Layout of cds.htm <%@ page language="abap" %> <html> <body> automatic Typing Type TYPE Reference Type TARTICLE Description list of books
<h2> All CDs </h2>
<table border=1> <tr> <th></th> <th>Title</th> <th>by</th> <th>Label</th> <th>number</th> </tr> <% data: wcd like line of cds. loop at cds into wcd. %> <tr> <td><img src="../../bookstore2/<%=wcd-category%><%=wcd-id%>_s.jpg" border=1></td> <td><%= wcd-title %></td> <td><%= wcd-author %></td>
<td><%= wcd-publisher %></td> <td><%= wcd-author %></td> </tr> <% endloop. %> </table>
</body> </html> OnInitialization of cds.htm select * from bsparticle into table cds where category = '0002'. Page Attribute of cds.htm Attribute Name cds automatic Typing Type TYPE Reference Type TARTICLE Description list of cds
Caching BSPs
Use
With the Internet Server Cache (see also ICM Server-Cache) you can considerably increase the performance and scalability of your BSP application. The ICM server cache provides a dynamic and active content caching technology, resulting in the following advantages for developing BSPs: The resources required for creating BSPs are reduced You do not have to repeatedly execute BSPs that are frequently requested
The possible performance improvements can be up to factor 20.
Performance and Scalability

Benchmarking tests for cache hits in the main memory have resulted in latent response times of less than one millisecond per request, and a total run of under 3,000 requests per second on a 4 CPU hardware. These results are based on a strong parallel and multithreaded architecture that supports simultaneous read and write accesses with versioning. Furthermore, a patented indexing algorithm is used to access the cache directory quickly. This algorithm is particularly suitable for long Web URLs as cache keys.
Functions
The features and the architecture of the ICM server cache are described in Cache. You have the following options to control BSP caching: In the Web Application Builder (Transaction SE80), you can set the following properties for caching on the Properties tab page: o o o Expiry date for caching in the Internet server cache Expiry date for caching in the browser (client-side) Flag whether page caching should be browser-dependent Internet Server
In your BSP application you can control the behavior of the ICM server cache using response object method calls.
The following section describes how you should proceed.
Activities
Setting Caching Properties in the Web Application Builder
You can set the caching properties for the page on the Properties tab page of a BSP:
For both the browser cache and the ICM server cache you can determine how long the page should be held in the cache. If you do not enter any data, this means that the cache is not used for the page. Set flag Browser Dependent if you want the ICM server cache to fetch the page from the cache only if the request comes from the same browser type. If you do not set the flag, note that all of the elements used by the page must not be browser-dependent.
Note that when you use the browser cache, the client cannot tell when a page has changed. If the URL is the same, it always returns the same page from the cache until the expiry date has passed. If you use the ICM server cache, by using the invalidation methods you can ensure that the page stored in the cache is upto-date.
Setting Caching Properties Using Method Calls in the BSP

You have several options here. In addition to the relative expiry date and browser-dependency, you can specify a final expiry date and invalidate cache entries. You can also activate caching not just for the page in general, but also according to user input. Set the expiry time for an HTTP response with the methods of class CL_HTTP_RESPONSE (see also IF_HTTP_RESPONSE and IF_HTTP_REQUEST): SERVER_CACHE_EXPIRE_ABS SERVER_CACHE_EXPIRE_REL
Use appropriate automatic expiry times. For example, a banner displaying stock market tickers is updated every n minutes, whilst a product catalog should be updated only every n days or weeks. You refresh (invalidate) objects asynchronously using the methods of class CL_HTTP_SERVER (see also IF_HTTP_SERVER): You can use method SERVER_CACHE_INVALIDATE() to invalidate an individual object that can be identified by the following data: Complete name, that is, URI path, form fields and BSP application context Prefix of the name (hierarchical wildcards) E-tag, that is, the entity tag and the unique ID that was assigned at the time of creation You can use method SERVER_CACHE_INVALIDATE_LIST() to invalidate a list of objects (internal tables).
The system automatically forwards this data to other application servers, thus ensuring cache integrity.
You should avoid too frequent invalidations, so that system-wide transfers to other application servers are avoided. See also:
Manipulating Cache Properties
Example
You can find a simple example in the system in BSP application TUTORIAL_4, BSP results.htm in the event handler OnInitialization: * cache result page in case Plattner's books are searched
if 'PLATTNER' cp author. response->server_cache_expire_abs( expires_abs_time = '180000' browser_dependent = 'X' ). endif. The result list for querying the books from Hasso Plattner is only stored in the cache because you know that these are requested especially often. The cache entry is invalidated every night at 18.00. This function may be useful for things that must be recalculated every day (such as current prices). See also: Further Developing the Online Bookshop
Page Layout
Prerequisites
Before you can choose from the various options available for the layout of your BSP application, you need some knowledge of following: Page-based programming model HTML Work method of graphical Web design tools
Do you have to choose one or the other option?

The SAP Web Application Server provides a number of design options for the BSP layout.
The easiest option is to design a page with pure HTML. You either use the text editor in the BSP development environment (see also the documentation on the Web Application Builder) and design the page textually. This presupposes a good knowledge of HTML and it is usually a lengthy process. The advantage of it is: script can be added immediately to the correct parts of the page. Moreover, the Web Application Builder in the development environment has a preview function so that you can check the static layout of a page at any time.
From SAP Web AS 6.20 you can use BSP extensions as an ideal mechanism for easily integrating interface elements such as tableviews, buttons, input fields or charts into your BSPs. In particular, you can use the BSP extension HTML Business (HTMLB) for BSP applications. A more elegant solution is to design a page with a design tool such as AdobeGoLive5.0, Dreamweaver 4.0, Frontpage and so on. The SAP Web Application Server lets you check in Web pages created with such tools and directly edit such pages managed on the server. This is done by means of the WebDAV access of the SAP Web Application Server (see also Using External Tools). WebDAV is supported by the above-mentioned tools (Frontpage together with the WebFolders). After check-in, you can add script to the pages. If the pages checked in to the server are edited again using the tool, you should flag the server-side script parts so that a designer can recognize them as such. Thus, developers of Web applications using the SAP Web Application Server are subject to no design restrictions whatever.
Accessibility
Use
The Accessibility Guidelines (Section 508) established in many countries are intended to enable partially sighted users to use software interfaces. In general, all texts on an interface are read out using an external tool, provided that all screen elements, such as symbols, pushbuttons and so on have been assigned quick infos. In the context of BSP applications, you can use BSP extensions HTMLB,XHTMLB and PHTMLB to structure interfaces with the Tag Browser.
In particular, you should think about accessibility with BSP applications that contain tables, tabstrips and tree controls. These three types of interface elements are not always easy for Screen Reader to read out.
Integration
When developing BSP applications, you can specify whether or not you want to follow the accessibility rules.
The accessibility specification is integrated in the BSP runtime: 6. ... 17. 1. Specify the accessibility in the URL or use the corresponding parameter in the logon application:
...?sap-accessibility=X Defining the accessibility is also part of the new system logon for SAP Web AS 6.40 SP2.
18.
2. Query the accessibility in the BSP runtime:

runtime->with_accessibility( ) = 'X' Accessibility is activated. runtime->with_accessibility( ) = '' Accessibility is not activated.
This option sets an internal flag in the BSP runtime, which can be used by BSP applications to output additional information in the HTML output stream, so that screen reader programs can better present the visual information on the screen. BSP extensions HTMLB, XHTMLB undPHTMLB use this flag to change its rendering behavior. These parameters are not used after the logon.
Note that setting this indicator does not make any statement about that applications accessibility. The indicator merely indicates that additional help is required for that application.

Programming Model in BSP

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Programming Model in BSP

Загружено:

Авторское право:

Доступные форматы

Programming Model

What is a BSP Application?

Structure of a BSP Application

Accessing a BSP Application

Example of page default.htm of BSP application IT00:

Starting and Ending a BSP Application

This is the same as the following URL:

1. Ending the application externally:

System-Specific URL Parameters

sap-exiturl sap-theme sap-themeRoot

off | min | max X|

Processing a BSP Application

Creating a BSP Application

Extending Security Aspects with BSP Applications

Application Class of a BSP Application

Stateful BSP Application

Stateless BSP Application

Accessing the Application Object

Requirements for an Application Class

Application Events: The IF_BSP_APPLICATION_EVENTS Interface

Application Basis Class CL_BSP_APPLICATION

BSPs consist of the following components:

You can create your own stylesheets or use predefined ones.

type ref to IF_BSP_RUNTIME type ref to IF_HTTP_REQUEST

type ref to IF_HTTP_RESPONSE

type ref to IF_BSP_PAGE

type ref to IF_BSP_PAGE_CONTEXT Page context object is defined in interface IF_BSP_PAGE_CONTEXT.

Control Flow of BSPs

The opposite of OnCreate is OnDestroy.

See also: Event Handlers

EVENT_ID NAVIGATION PAGE PAGE_CONTEX T

Reference Type type ref to application class

type ref to IF_BSP_RUNTIME type ref to IF_HTTP_REQUEST

type ref to IF_HTTP_RESPONSE

NAVIGATION PAGE PAGE_CONTEXT

type ref to IF_BSP_NAVIGATION type ref to IF_BSP_PAGE type ref to IF_BSP_PAGE_CONTEXT

type ref to IF_BSP_RUNTIME type ref to IF_HTTP_REQUEST

type ref to IF_HTTP_RESPONSE

type ref to IF_BSP_PAGE type ref to IF_BSP_PAGE_CONTEXT

Reference Type type ref to application class

RUNTIME PAGE PAGE_CONTEX T

type ref to IF_BSP_RUNTIME type ref to IF_BSP_PAGE type ref to IF_BSP_PAGE_CONTEXT

Automatic Page Attributes

Non-automatic page attributes

Transferring Parameters Between Pages: Visibility of Page Attributes

Lifetime of Page Attributes

Lifetime of attributes with navigation to a different page

Lifetime of attributes remaining on the same page

automatic automatic Non-automatic Non-automatic

SAP SAP SAP SAP

SAP SAP SAP SAP

Lifetime of attributes with navigation to the same page

automatic automatic Non-automatic Non-automatic

SAP SAP SAP SAP

No Yes No Yes SAP

Lifetime of attributes with navigation to a different page

Value in Request (Example Value) SAP SAP

automatic automatic Non-automatic Non-automatic

SAP SAP SAP SAP

No Yes No Yes SAP

Special Programming Features

<%@ page language=("ABAP" | "JAVASCRIPT") %>

<% inline code %>