6729135 bsp-2

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?

OverviewA Business Server Page (BSP) application is a complete functional application, like a classic SAP transaction. However, this application is executed in a Web browser rather than in the SAPGUI. HTTP or HTTPS is the protocol used to access the application across the network, thus allowing the use of standard products like firewalls and proxy servers.

The Business Server Pages programming model is similar to the server page technology. The focus of the BSP programming model are points that ensure optimum structure in interfaces and business logic.

For more information about BSP applications, see:● The components of a BSP application and how they interact, see Structure of a BSP

Application.

● How to call an existing BSP application from a Web browser, see Accessing a BSP Application.

● How to open and close a BSP application, see Starting and Ending a BSP Application.

● How a BSP application is processed, see Processing a BSP Application

● How to create a BSP application, see Creating a BSP Application.

● The URL parameters you can use to access the BSP runtime environment and BSP applications, see System-Specific URL Parameters.

● The concept of an application class for encapsulating the business logic of a BSP application, see Application Class of a BSP Application

Structure of a BSP Application A Business Server Page (BSP) application is an independent development project that is created and edited in the SAP development environment (transaction SE80). External design tools, such as Adobe GoLive, Dreamweaver, or Microsoft FrontPage 2000 can be used to design the BSP application, as well as BSP extensions.

Analog to a classic transaction, a BSP application consists of a user interface and business logic that is assigned to a logical unit, in this case the BSP application.

The user interface of a BSP applications includes:• Static Web sites

• Dynamically generated Web sites, which are BSPs or templates that contain server-side scripting that is executed dynamically at runtime to generate a static Web site BSPs can either be pages with flow logic or views.There can also be controllers if the MVC design pattern is used

• Various MIME objects, such as pictures, icons, sound files, style sheets, and so on, that are parts of a typical Web application

All of these objects are integrated in the Change and Transport Organizer as parts of the BSP application and are handled as a logical unit. This allows all objects that are part of a BSP application to be fully and consistently transported between all the systems in an SAP system landscape.

The business logic can be accessed from the BSP application using the typical methods, such as BAPIs, function modules, or class libraries. In addition, the BSP programming model provides a structuring tool, the BSP-Application class , that can be used to encapsulate the business logic functionality in the BSP application.

A BSP application consists of the following components:• Controller

Controllers contain business logic and application data. Controllers assess the data of an incoming request based on a model and then select a suitable view for rendering the response to the user, see also Model View Controller (MVC).

• Business Server Pages (BSPs)

BSPs are the Web sites that are displayed in the browser when the application is in use. BSPs can contain static HTML code and dynamic scripting code (ABAP or JavaScript). The scripting code is interpreted on the server. The exact structure of a BSP is described in Building an BSP.

A page can have the following versions:

Page with flow logic

These are simple pages with event handlers, but without much application logic or visualization elements. It is possible to build a BSP application exclusively out of pages with flow logic and event handlers.

View

Views are used to visualize data, see also Model View Controller (MVC).

Page fragment

These are created in the same way as normal BSPs, but are then marked as page fragments. Other BSPs can also include these fragments using the includedirective (see Include Directive).

• Navigation structures

The navigation structure determines which navigation request is used to direct the navigation process from which page to which subsequent page.

• Application class

The business logic of a BSP application is encapsulated in an application class. This class is realized by means of a global ABAP class which implements the access to business data using BAPI calls, for example. Every page of a BSP application can directly reference the components of this class (attributes, methods, and so on) using the predefined Object application.

You can also assign several BSP applications to an application class.

For more information, see Applications Class of a BSP Application .

• MIME objects

In the SAP system, all MIMEs, such as graphics, style sheets (used to define formatting properties of individual HTML tags), audio files, video files, and so on, are stored and administered in a central repository, the MIME repository.

For every new BSP application, a directory of the same name is created in the MIME repository. This directory is used as a storage location for all application-specific MIMEs.

See also:

Accessing a BSP Application

Starting and Ending a BSP Application

Building a BSP

Accessing a BSP Application As explained previously, you access BSP applications using the HTTP or HTTPS (Secure HTTP) protocol. The BSP runtime environment uses the HTTP framework of the SAP Web Application Server (compare Interaction Model). In the Internet Communication Framework (ICF), for a BSP application to function smoothly you need a node, that is, a service in the service tree (see also Creating a BSP Application).

Ensure that after a SAP Web AS has been installed, that all services are inactive and that they must be activated accordingly. You can find further information about activation under Activating and Deactivating an ICF Service and in Business Server Pages Administration. The node is activated in the service tree only with BSP applications that were newly created for SAP Web AS 6.20 as part of automatically creating the corresponding node.

A BSP application is addressed and executed through HTTP using a Uniform Resource Locator (URL). The URL of a BSP application has the following structure (default configuration):

<Prot>://<Host>.<domain>.<extension>:<Port>/sap/bc/bsp/<namespace>/<application name>

Protocol Prot is httpor https (if configured). Host is the name of the application server that should execute the application. The domainwith the extension

encompasses several hosts under a common name. These can either be part of an individual host or a network. The Port number can be omitted if the default port 80 (http) or 443 (https) is used.

For SAP Web Application Server, the default port number is 1080 (HTTP) or 1443 (HTTPS). The namespace is the namespace ID of the BSP application. SAP applications are delivered in the sap namespace. If you create your BSP application in a separate namespace, it must be used in the URL. The application name is the name of the BSP application as defined in the development environment.

Here is an example of a URL for BSP test application IT00:

http://myServer.sap-ag.de:1080/sap/bc/bsp/sap/it00

The full name of the server is specified, including the network domain (here: sap-ag.de). If this is not done, the BSP runtime environment returns an error. The full domain must be entered, as there may otherwise be problems with HTTP cookies (such as Single Sign On).

If the BSP that you start by calling Transaction SE80 contains a shortened URL (excluding the host name), proceed as described in Note 434918.

When this URL is started in the Web browser, the BSP application is started, and the initial page is displayed (by default this is default.htm).

To determine the URL of a BSP or BSP application in the SAP development environment, select the Properties tab to the right of the SAP GUI screen.

Example of page default.htm of BSP application IT00:

For more information:

Starting and Closing a BSP Application

Cache Key

Starting and Ending a BSP Application

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

ProcedureThe following commands are supported:

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

• close: Ends a running BSP application and either tells the system to display a blank page or go to a specific Web site (exit URL). The exit URL is specified using an additional URL parameter,This parameter is calledsap-exiturl,and must contain a full HTTP URL.

To be compatible with SAP Internet Transaction Server (ITS) and the SAP Enterprise Portal (SAP EP), you can also use ~exitURL.

Example1. • Restart of BSP test application IT00:

http://myServer.sap.corp:1080/sap/bc/bsp/sap/it00?sap­sessioncmd=open

1. • Ending the application externally:

http://myServer.sap.corp:1080/sap/bc/bsp/sap/it00?sap­sessioncmd=close&sap­exiturl=http%3a%2f%2fwww.sap.com

Pay attention to the spelling of the URL - all URI parameters, that is everything following the ?, must be URL-encoded.

System-Specific URL Parameters To control the BSP runtime environment and the BSP application, you can use the following URL query string parameters in a request URL.

URL Parameter

Value Description

sap-sessioncmd open: 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).

sap-exiturl * Specifies the URL to which the browser is directed when the BSP application ends (for example, http://www.sap.com)

sap-theme * Overrides the theme for a BSP application to use other MIME objects, such as pictures and Stylesheets for visualization.

sap-themeRoot * Used to handle paths to other locations from where stylesheets are taken.

See also:

Changing Stylesheets for HTMLB and XHTMLB

This parameter is available from SAP Web AS 6.20 Support Package 7.

sap-client * Specifies the client for a logon to the SAP Web Application Server; can be used in the URL or in HTML forms to override the default client.

sap-user * Specifies the user for a logon to the SAP Web Application Server; can be used in the URL or in HTML for forms.

sap-password * 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-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.

sap-htmlb-design

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

off | min | max

Maximum domain relaxing, see also Domain Relaxing

sap-accessibility X | Specification for the accessibility

See also Configuration Settings

To activate this indicator, an activated checkbox is placed on the logon screen for input help.

sap-rtl True | False

Details of the RTL support

The family of <HTMLB> libraries supports RTL (right-to-left) rendering for design2003. You can activate RTL rendering using the URL parameter sap-rtl=true (but only for the first call before the BSP URL finds out about the URL mangling). Use attribute rtlAutoSwitch from <htmlb:content> to activate the RTL mode automatically, depending on the currently active language (SY-LANGU). The decision about activating RTL is delegated to the function module NLS_RTL_DISPLAY.

Parameter names and parameter values are not case sensitive (exception: sap-exiturl is case-sensitive, if the link is to a case-sensitive server). You can combine several parameters in one URL.

Here is an example of how to restart a BSP application in client 800 with logon language English.http://myServer.sap.com:1080/bc/bsp/sap/it00?sap-sessioncmd=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 hasn’t already, OnInitialization is run, so that the initialization phase data is assessed. Data in the SAP system, such as table contents or BAPIs, can be accessed in this phase. Then, the layout part (the hidden part of the event handler OnLayout) is processed, which determines the design and presentation logic of a page. This code consist of static parts (for example, HTML) and scripting code. To ensure clean programming, no business logic or data retrieval is carried out in the layout part. The manipulation part becomes important if the HTTP data stream should be modified later. The manipulation code should likewise contain no business logic or statements for data retrieval functionality. If there are no subsequent changes, the manipulation part is not required.

On the basis of all this data, the first page is built and sent to the user.

Next comes the user interaction phase, in which the user inputs data. The user input is sent back to the BSP. This input triggers an additional HTTP request.

You can specify for every page whether stateful or stateless mode is required. This is done in the input processing part. For example, incorrect input can be checked, data can be read from the database, and the succeeding page can be determined.

The subsequent page for the navigation request is determined in the navigation part of the application. If no succeeding page is set, the first page is reprocessed.

Then, processing of the initialization part continues.

For more information, see Control Flow of BSPs

Creating a BSP Application You create your Web application in the form of a BSP application.

For information about the procedure for creating BSP applications, see the documentation on Web Application Builder in the sections under Basic Functions..

Extending Security Aspects with BSP ApplicationsSo that a BSP application can function correctly, there must be a node that corresponds to each BSP application in the service tree (Transaction SICF) of the Internet Communication Framework (ICF).

When you create a BSP application in the Web Application Builder in SAP Web AS 6.20 and higher, this type of node is created and activated in the appropriate part of the ICF service tree (see Creating an ICF Service). If necessary, you can define permissions for this node (see Maintaining Service Data).

For BSP applications that were created before SAP Web AS 6.20 and which therefore do not have any nodes in the ICF service tree, this node is generated automatically by the system as soon as you branch to the corresponding BSP application in change mode.

There may be conflict with old BSP applications with names that are longer than 15 characters. Before SAP Web AS 6.20, you could create BSP applications whose names could exceed the length of the service name in Transaction SICF. In this case, we recommend that you copy all of the old BSP application to a new BSP application with a shorter name, so that the node is automatically created.

Application Class of a BSP Application

OverviewA BSP application comprises a number of different development objects. One of these objects is the application class of the BSP application.

The application class is a regular ABAP Objects class. As such, the application class can include any methods, attributes and events that the developers wish to have.

The application class is usually used to store data and make it available across BSP pages. This data is stored as attributes. The application class also encapsulates BSP application logic in methods. This allows several BSP applications to use the same application class and provide one business application that contains different interfaces, such as for various devices, without having to replicate the business or application logic.

This also means the global Object application can be used in the BSP application to access the attributes and methods of the application class.

You do not have to use an application class in your BSP application. Rather, it is an optional way for application developers to structure their BSP application.

You use the Web Application Builder in transaction SE80to assign an application class to a BSP application.

A simple example of where an application class could be useful would be a class for controlling dialog logic and maintaining data consistency in a BSP application for shopping. This application class would include a shopping basket (internal table or other object) as an attribute. There would also be methods for changing and processing the shopping basket, such as to add, change, or delete articles. Methods for determining prices, creating offers, and posting orders would also be helpful.

In many cases, the application class is only used to encapsulate existing application functions, such as from SAP Customer Relationship Management (SAP CRM), and then access the function through BAPI interfaces. Using an application class to

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

Runtime BehaviorAny 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 ApplicationIn 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 ApplicationIn Stateless BSP Applications, the application context (roll area) is only available for the lifetime of a single request and is released at the end of the request. When the application context is released, all data and objects held by the session on the application server are also released. This includes the application object.

This means the lifetime of the application object starts when the request is received and ends when a response is sent. The application object is not available across several pages. Each page and each request interacts with a different instance of the application class.

In stateless mode, the application object cannot hold data across requests. For stateless applications, application classes are usually used to store the business logic in methods, but do not buffer data.

Accessing the Application ObjectTo 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 ClassThe only real requirement for an application is that the constructor must be parameterless. Otherwise, the application class cannot be generically instantiated by the BSP runtime environment.

Apart from this, there are no other restrictions. You do need to ensure that the internal implementation of methods is chosen correctly, depending on the state mode where the class is implemented. For stateless applications, for example, it would be useless to implement expensive data gathering routines as these would be lost after every request.

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

Application Events: The IF_BSP_APPLICATION_EVENTS InterfaceIn 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 for both stateless and stateful applications.

Note that this time is not available after every request in stateless BSP applications. This time is not evaluated either if the session is implicitly terminated by a timeout. In this method, it is only possible therefore to

execute optional operations that are non-critical.

Typically, this is a good time for cleanup operations such as deleting browser cookies or server-side cookies, if the application generated them.

IF_BSP_APPLICATION_EVENTS~ON_REQUEST This method is called by the BSP runtime environment for every incoming request to a BSP before the BSP is given control (in the OnRequest event handler).

This time can be used by the application class, for example, to restore attributes that were rescued in 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 OnManipulation event 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_EVENTSin the reference documentation Interface IF_BSP_APPLICATION_EVENTS:

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

As the application object is an application attribute in every BSP event handler, the methods of the CL_BSP_APPLICATION class are also available with the corresponding inheritance. This makes it easy to provide the relevant functionality to lower application levels using a single object reference.

See also:

You can find information about base class CL_BSP_APPLICATION in the reference documentation Class CL_BSP_APPLICATION:

BSP Components

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

BSPs consist of the following components:

Server-side scripting determines the presentation logic as part of layout processing. In the preview, you can check the appearance of your pages, without having to call up the browser.

Page attributes are visible in the layout processing as well as in the event handlers of a page. They can be used to store data obtained in the standard handler OnInitialization, and to make this data accessible for the layout processing and the other event handlers.

Predefined event handlers are available for the different events.

You can use type definitions to define local types.

Similar to every object in the SAP System, BSPs also have different administration attributes.

Properties

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

Page Type

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

Error Handling

For more information see Creating Error Pages.

Status

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

Caching

For more information see Caching BSPs.

Transmission Options

You can set the flags Compression and HTTPS as the transmission options.

• Compressing

If you set this flat, the page is sent compressed to the browser, provided that the browser supports compression.

Note that it only makes sense to activate compression for large pages. It is considerably more efficient to send small pages uncompressed.It is considerably more efficient to send small pages uncompressed.

• HTTPS

By selecting this flag, you can determine that a BSP should be accessed using HTTPS, that is, a secure connection. The BSP runtime then checks the URL. In the case of http://... it redirects the browser immediately to https://... .

Not the following browser-specific feature: As soon as you activate HTTPs, all other BSPs of your BSP application are accessed using HTTPS.

It is considerably more efficient to send small pages uncompressed.

Layout

Use

You determine the presentation logic for your BSP using server-side scripting in the layout.

To ensure clean development, layout and presentation must be separated from processing logic. Therefore, scripting for the static details of a page is part of layout processing, while the dynamic processing steps are set in the different event handlers (see Event Handlers).

The layout can also be regarded as an internal event handler for the presentation.

You can create your own stylesheets or use predefined ones.

Functions

You can access the following objects in the implementation:

Object Reference Type Description

APPLICATION type ref to application class 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 type ref to IF_BSP_RUNTIME The runtime objectIF_BSP_RUNTIME

REQUEST type ref to IF_HTTP_REQUEST The request objectIF_HTTP_REQUEST

RESPONSE type ref to IF_HTTP_RESPONSE The response objectIF_HTTP_RESPONSE

PAGE type ref to IF_BSP_PAGE Page object is defined in interface IF_BSP_PAGE.

PAGE_CONTEXT type ref to IF_BSP_PAGE_CONTEXT Page context objectIF_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 Description

OnCreate OnCreate is called once when the page is first created (stateful mode), and performs a once-off data initialization or object creation.

OnRequest OnRequest is called whenever a request is made for a particular page and is used to restore the internal data structures from the request. This is important when working in stateless mode.

OnInitialization This event handler is mainly used for data retrieval. For example, it allows data required for displaying the BSP to be read from the database. It can also execute any program.

OnInputProcessing This event handler checks and processes user input. It can also define navigation, that is, whether the user should be taken to the same page or another when the BSP is called.

OnManipulation You can use this event handler to manipulate the HTTP data stream later.

OnDestroy This event handler is available for special functions.

The ABAP syntax checks that apply in the context of ABAP Objects also apply to event handlers.

Read and modify access to page attributes is available in all handlers. Global objects are also available.

Global objects and their signatures for individual event handlers are

displayed if you choose in the Web Application Builder.

The use of the individual event handlers is explained in more detail in the individual sections of the documentation.

See also:

Control Flow of BSPs

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 AttributesIf 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 AttributesBefore 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 attributesIf you flag a page attribute as non-automatic, the attribute gets its values from the class attribute.

Transferring Parameters Between Pages: Visibility of Page AttributesThe 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 AttributesWhen 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 pageNo navigation takes place.

Attribute Type Value in Request (Example Value)

Value in OnInputProcessing

Explicit Transfer

Value in OnInitialization

automatic SAP SAP No SAP

automatic SAP SAP Yes SAP

Non-automatic SAP No SAP

Non-automatic SAP Yes SAP

Lifetime of attributes with navigation to the same pageThe navigation object is used (navigation->goto_page(samepage.htm)) to navigate to the same page.

Attribute Type Value in Request (Example Value)

Value in OnInputProcessing

Explicit Transfer

Value in OnInitialization

automatic SAP SAP No

automatic SAP SAP Yes SAP

Non-automatic SAP No

Non-automatic SAP Yes

Lifetime of attributes with navigation to a different pageThe navigation object is used (navigation->goto_page(otherpage.htm)) to navigate to a different page.

Attribute Type Value in Request (Example Value)

Value in OnInputProcessing

Explicit Transfer

Value in OnInitialization

automatic SAP SAP No

automatic SAP SAP Yes SAP

Non-automatic SAP No

Non-automatic SAP Yes

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 FeaturesThe following code sections for the layout of a BSP are not equivalent:

<% read table itab index lv_index. %> <% if sy-subrc ne 0. clear workarea. endif. %>

and: <% read table itab index lv_index. if sy-subrc ne 0. clear workarea. endif. %>

The first code extract above contains a function module call between the two ABAP commands. The second code extract does not: .... * BSP SCRIPT source read table itab index lv_index.

* BSP STATIC source * HTML begin: #### ###### CALL METHOD %_IF_PM->ADD_STATIC_REF exporting encoding = 0 source = %_HTML_POOL offset = 0000018407 length = 0000000039 .

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

Control Flow of BSPs

Overview

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

You do not have to use all event handlers, for example a BSP can consist of just the layout, or it only contains the layout, OnInitialization and OnInputProcessing.

Since event handler OnDestroy is used infrequently, it is irrelevant here.

The following cases should be distinguished:

• stateless BSPs • stateful BSPs

See also:

Interface IF_BSP_PAGE

StatelessIn 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 = 0When 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 BSPWhen 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 BSPsThe 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.

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

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

With stateful BSPs, there can be three different variants of lifetime:

• Up to the page change (lifetime_page)

The page is destroyed if a different page is used.

• For the duration of the request (lifetime_request)

The page is destroyed after each individual request, that is, is only available for the duration of each request.

• For the duration of the session (lifetime_session)

The page is destroyed at the end of the session.

Examples

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

Classes and Interfaces The following classes and interfaces are central components of the BSP programming model.

Classes:● Class CL_BSP_APPLICATION

● Class CL_BSP_MESSAGES

● Class CL_BSP_SERVER_SIDE_COOKIE

● Class CL_BSP_GET_TEXT_BY_ALIAS

● Class CL_BSP_CONTROLLER2

Interfaces:● Interface IF_BSP_APPLICATION

● Interface IF_BSP_APPLICATION_EVENTS

● Interface IF_BSP_NAVIGATION

● Interface IF_BSP_PAGE

● Interface IF_BSP_RUNTIME

● Interface IF_BSP_PAGE_CONTEXT

● Interface IF_HTMLB_TABLEVIEW_ITERATOR

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

Global Objects

Certain global objects can be accessed from all parts of a BSP (initialization, layout, input processing). For example, the request and response object, the application object (if an application class was defined for the BSP application), the navigation object, and the runtime object, can be accessed.

The following global objects are available:

• Object application • Object navigation • Object messages • Object runtime • Object request • Object response • Object page • Object page context

This is described in more detail below.

The objects and their signatures for the individual event handlers are

displayed if you choose in the Web Application Builder.Example:

BSP Extensions

IntroductionThe BSP programming model, which is based on the server pages technology, provides developers with additional scope regarding the HTML coding that they can create, from an empty page right up to complex applications. However, repeatedly creating complex HTML coding is often a lengthy process that can easily result in errors. For example, a simple HTML pushbutton can be implemented thus: <input id=btn type=submit>: If you now start to use additional styles and other attributes for the size and the status of the button, the original simple HTML coding becomes considerably more complex and unclear. An abstraction technology can be used here to express more simply both the syntax and the semantics of a specific section of HTML coding. This mechanism is structured so that it can also be used by other types of BSPs, XML, WML and so on. This technology is known as BSP extensions.

A BSP extension contains a collection of BSP elements. In the BSP context, each element is assigned to an ABAP class to represent the element functionality, which the generation of the HTML coding usually contains. Defining the elements and mapping them to the ABAP classes is so flexible that you can use this technology to solve many additional problems and difficulties.

SAP provides an infrastructure that developers can use to implement BSP extensions within BSP applications. SAP delivers a set of predefined extensions, such as HTML Business for BSP (HTMLB), XHTMLB and PHTMLB that are available and can be used in every SAP Web Application Server 6.20 system. You can also define your own extensions to meet specific requirements. You can create these using an editor integrated in the development environment (transaction SE80).

You include an extension in a BSP using the extension directive.

For more information see Creating Your Own BSP Extensions.

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

BSP Extensions and BSP Elements Each BSP extension consists of a collection of BSP elements. Each element has specific attributes and is assigned to an ABAP class. The usual notation for XML elements is used when elements are written to BSPs. The attributes available in the element are used as input parameters for the ABAP class that is assigned to the element.

You can define a simple pushbutton on a BSP as follows:

<htmlb:button id=”btn1” text=“Hit Me!” />

Here “htmlb” is the XML namespace, “button” is the element and “id” and “text” are attributes. When the BSP compiler sees the element, it generates the following pseudocode.

data: btn1 type ref to CL_HTMLBL_BUTTON.create object btn1.btn1->writer = current_output_writer.btn1->id = ‘btn1’.btn1->text = ‘Hit Me!’.btn1->begin_tag( ).btn1->end_tag( ).

The element class writes the HTML to the HTML output stream based on the functionality that the element provides. This is based on the assumption that all elements in an extension support a common output style.

In the sample pushbutton above, the start tag is followed immediately by the end tag. No body components whatsoever are available or required (by the pushbutton). For other examples, it may be useful to manipulate the body or to process more detailed input.

A typical element, for example, could be an HTML link for creating a small text segment. In this case, the element has a body, which is first rendered in a string and then passed as a parameter to the element for further processing.

<htmlb:link id=”link1” reference=“http://www.sap.com”> Homepage of the e-company!</htmlb:link>

This results in:

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

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

● The standard XML syntax that is used can be parsed and checked during the BSP compile time.

● The returned HTML coding need only be generated once (by an expert) in the ABAP element class, thereby ensuring that the coding is correct.

● The element class can contain additional logic for generating browser-dependent HTML code.

● The HTML coding that is generated contains correct references to the style sheets that are available.

In addition to a BSP extension for standard HTML elements such as pushbuttons, input fields, dropdown lists and so on, you can also implement highly specialized extensions.

For example, you could develop an extension to map a company’s corporate identity to an HTML page. In this case, the user’s 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:

ExamplesThe system contains various examples of BSP applications that use BSP extensions. You can find simple examples of using BSP extensions HTMLB, XHTMLB and PHTMLB in the BSP applications SBSPEXT_HTMLB, SBSPEXT_XHTMLB and SBSPEXT_PHTMLB, and further examples in BSP extension HTMLB_SAMPLES.

The following sections provide two simple examples of the HTMLB elements button and tableView:

Button

TableView

Button

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

Layout

<%@page language="abap"%>

<%@ extension name="htmlb" prefix="htmlb"%>

<htmlb:content>

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

<htmlb:form>

<htmlb:button id = "myButton1"

text = "standard"

/>

<br><br>

<htmlb:button id = "myButton2"

text = "Emphasized button"

tooltip = "button quick info: Please click me"

onClick = "MyButtonClick"

design = "emphasized"

/>

<br><br>

<htmlb:button id = "myButton3"

text = "Small button with fixed size "

tooltip = "button tooltip: Please click me"

onClientClick = "alert('myButton3 Clicked')"

design = "small"

width = "300"

/>

</htmlb:form>

</htmlb:page>

</htmlb:content>

OnInputProcessing

CLASS CL_HTMLB_MANAGER DEFINITION LOAD.

* Optional: test that this is an event from HTMLB library.

IF event_id = CL_HTMLB_MANAGER=>EVENT_ID.

* Scenario 1: Read event from manager.

DATA: event TYPE REF TO CL_HTMLB_EVENT.

event = CL_HTMLB_MANAGER=>get_event( runtime->server->request ).

IF event->name = 'button' AND event->event_type = 'click'.

DATA: button_event TYPE REF TO CL_HTMLB_EVENT_BUTTON.

button_event ?= event.

ENDIF.

* Scenario 2: Dispatch event directly onto event class

DATA: event_handler TYPE REF TO CL_HTMLB_EVENT_EXAMPLE.

CREATE OBJECT event_handler.

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

ENDIF.

Output

TableView

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

Layout

<%@page language="abap"%>

<%@ extension name="htmlb" prefix="htmlb"%>

<htmlb:content>

<htmlb:page title = "BSP Extension: HTMLB / Element: tableView">

<htmlb:form>

<htmlb:tableView id = "tv1" headerText = "Connections" headerVisible = "true" design = "alternating" visibleRowCount = "8" fillUpEmptyRows = "true" onHeaderClick = "MyEventHeaderClick" onRowSelection = "MyEventRowSelection"

selectionMode = "multiselect" table = "<%=sflight%>" >

<htmlb:tableViewColumns>

<htmlb:tableViewColumn columnName = "carrid" wrapping = "true" width = "100" onCellClick = "MyCellClickCarrid__" horizontalAlignment="center" title = "&nbsp;" type = "user" > <htmlb:textView id="$TVCID$" text = "$TVCVALUE$" design = "LABELSMALL" layout = "PARAGRAPH" required = "TRUE" width = "100%" tooltip = "$CARRNAME$" encode = "FALSE" wrapping = "TRUE" /> </htmlb:tableViewColumn>

<htmlb:tableViewColumn columnName = "myicon" type = "user" title = "Image" horizontalAlignment="center" > <htmlb:link id = "$TVCID$" onClick = "$CARRNAME$" tooltip = "$CARRNAME$"> <htmlb:image src = "$TVCVALUE$" alt = "$TVCVALUE$" tooltip = "$CARRNAME$" /> </htmlb:link> </htmlb:tableViewColumn>

<htmlb:tableViewColumn columnName = "myinputfield" type = "user" title = "Input Field" cellInvalidKey = "invalid" cellDisabledKey = "disabled" horizontalAlignment="center" > <htmlb:inputField id = "$TVCID$" width = "100%" value = "$myinputfield$" type = "Date" showHelp = "true" firstDayOfWeek = "2" /> </htmlb:tableViewColumn>

<htmlb:tableViewColumn columnName = "mybutton" type = "button"

title = "Button" cellDesignKey = "design" onItemClick = "MyButton__" horizontalAlignment="center" />

<htmlb:tableViewColumn columnName = "fldate" onCellClick = "MyCellClickFldate__" title = "Datum" wrapping = "true" width = "100" horizontalAlignment="center" />

<htmlb:tableViewColumn columnName = "DDLKEY" title = "User defined: List Box" type = "user" > <htmlb:dropdownListBox id = "$TVCID$" table = "<%=sflight%>" nameOfKeyColumn = "DDLKEY" nameOfValueColumn = "CARRNAME" /> </htmlb:tableViewColumn>

<htmlb:tableViewColumn columnName = "linktextid" title = "Link" type = "link" linkColumnKey = "linkcarrid" linkClickTarget = "_blank"/>

<htmlb:tableViewColumn columnName="linkstextid" onItemClick = "MyLink__" title = "Link with Handler" type = "link" linkColumnKey = "linkcarrid"/>

<htmlb:tableViewColumn columnName="linkid" horizontalAlignment = "center" type = "imagelink" linkColumnKey = "linkcarrid" linkClickTarget = "_blank" title = "ImageLink" />

</htmlb:tableViewColumns>

</htmlb:tableView>

</htmlb:form>

</htmlb:page>

</htmlb:content>

Attributes

Attribute Auto Typing Type Reference Type

rowSelection TYPE STRING

rowSelectionEvent TYPE STRING

sflight TYPE 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 SupportIn 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 FlowComplete implementation of a BSP extension takes place in the following steps:

1. Creating a BSP Extension 2. Defining the Corresponding BSP Elements 3. Implementing the Element Handler Class 4. Activating the BSP Extension 5. Entering Documentation

Defining BSP Elements

Use

You create individual elements for a BSP extension and these are inserted later on as tags in BSP pages. Each BSP element has a handler class assigned to it that implements its specific functions. Also, you can create and declare attributes for each BSP element.

Prerequisites

The BSP extension already exists.

Procedure

Creating BSP Elements

1. Choose the required BSP extension from the object list.

2. Choose the function Create → BSP Element from the context menu.

The system displays the Create BSP Element dialog box.

3. Enter the name of the BSP element, a valid name for the Element Handler Class, and a meaningful description for the BSP extension as a short text.

You can specify an existing, valid ABAP class as the element handler class. A valid class must support the interface IF_BSP_ELEMENT.

We recommend that you derive this class from the automatically-generated basis class(Z)CLG_<name of BSP extension>_<name of BSP elements>. This basis class already contains a standard implementation of the interface methods and is automatically updated whenever changes are made to the element data.

As a rule, you enter the name of a non-existing class as the element handler class into the respective input field. Then you have this generated, together with the corresponding basis class.

4. Choose Continue to confirm your entries.

The properties of the created BSP element are displayed in the editor. Defining Attributes of the BSP ElementYou 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 ElementTo create attributes for a BSP element, choose the Attributes tab in the element view and, if necessary, switch to change mode. To create and declare an attribute, make the following specifications:

Attribute X In this column, enter a name that uniquely identifies the attribute.

After you have activated the BSP extension , the system generates a public attribute with the same name in the basis class (CLG_* or ZCLG_*).

Required By setting this flag, you define that the attribute must be defined whenever the BSP element is used in a BSP page.

Dynamic value allowed By setting this flag, you define that the value of the attribute in a BSP page may also be specified dynamically through a BSP expression (<%= ...%>). Otherwise, only static values are possible in the form of a string.

Pass by reference By setting this flag, you define that the attribute is passed to the event handler class as a reference. Otherwise, no value is passed.

For more information, refer to the section Pass by Reference for Attributes.

Kind of typing X You have at your disposal the two types TYPE and TYPE REF TO, depending on whether you have data or object references.

Note that the selection TYPE REF TO is only appropriate in combination with the active option Dynamic Value Allowed. The reason for this is that object references in BSP pages can only be passed with the help of BSP expressions, not statically in the form of a string.

Reference type X As reference type, you can use the elementary ABAP types (however, no generic types) or object types (classes and interfaces). Generic types such as C, N, X, P, and so on are not allowed because generically-typed attributes are not allowed in ABAP classes either. There

is a 1:1 relationship between the attributes of the BSP element and the class attributes.

Default value Here you always enter a value if the attribute is to be predefined with a value. This value is copied from the Tag Browser into the BSP page when you insert the attribute or the entire BSP element.

Description Here you enter an explanatory attribute description.

The specifications marked with X are absolutely mandatory for each attribute.

ResultThe new BSP element is assigned as a subobject to the BSP extension and copied inactive into the object list. With the new BSP element, the basis class (Z)CLG_<name of BSP extension>_<name of BSP elements> is automatically created itself, and possibly also the specified element handler class, provided this does not yet exist. Also, you have specified the BSP element behavior at runtime through further properties, and have also declared the corresponding attributes. In the next workstep, you can activate the BSP extension

Activating the BSP Extension

Use

You use this standard function of the Workbench in order to put the entire BSP extension, including its elements, into the active version. If necessary, the system will generate the basis class (CLG_* or ZCLG_*) again upon activation. This renewed generation always tales place during activation in the following cases:

• If generation-relevant element data has been changed because, for example, element attributes have been created, deleted, or changed.

• If a basis class for a particular element does not exist at all because, for example, it was deleted manually, or was not transported by mistake.

PrerequisitesYou 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 icon in

the application toolbar.

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

3. Confirm the selection by clicking Continue.

ResultWhen you activate, you create a runtime version of the BSP extension. If necessary, the system will also regenerate the element handler classes and your basis classes. Newly-created classes are automatically written to the same transport request as the BSP extension. Now the active version of the BSP extension appears in the Tag Browser under the entry BSP Extensions. There it is assigned to the selection Transportable or Local, depending on the object catalog entry.

Note that activating the extension can invalidate all the BSP pages that use this extension. Calling the respective BSP pages again means they will be regenerated if changes have been made.

Implementing Element Handler Classes

Use

The element handler class is the central class of a BSP element. It implements the specific functions of an element and thus influences the flow logic of the BSP page that uses this element. Through the type of implementation of certain methods belonging to this class, you can control whether data is updated in the HTML data stream and whether the content of a BSP element is processed or discarded. Element handler classes are instantiated during the processing of a BSP page and called at defined points in time using certain class methods.

Prerequisites

A valid element handler class must implement the interface IF_BSP_ELEMENT. We therefore recommend that you derive this class from the generated superclass (Z)CLG_<EXTENSION>_<ELEMENT> because it already contains the standard implementations for the interface methods.

Process Flow

The flow during implementation of the specific functions of a BSP element is divided up into the following three steps:

1. Creating the attributes for the BSP element See also Defining BSP Elements.

In this way, you make sure that the new attributes are added as attributes of the element handler classes after activation of the BSP extension.

2. Overwriting certain interface methods of the element handler class 3. Creating further methods or attributes that enhance the element functions

Entering Documentation

Use

You can create a long text documentation both for a BSP extension as well as for each BSP element in the system that is contained in this extension. This document is of particular importance for the productive usage of the extension in BSP pages because you can include special aspects of the individual BSP elements here.

If you store the documentation in the system, it is then available to users through the context menu in the Tag Browser and also through insertion of the tag into a BSP page – also by pressing F1 in the layout editor.

Prerequisites

• The BSP extension and the elements to be documented have already been created. • There are two different templates available for the BSP extension and the BSP elements.

The procedure for creating the documentation is the same, however.

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

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

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

ProcedureTo insert BSP elements or their attributes into a BSP page, proceed as follows:

1. Choose the Layout view for the required BSP page. 2. Switch to Change mode. 3. Click the switch button Tag Browser in the navigation area of the Object Navigator. 4. Under BSP Extensions, choose the appropriate extension. 5. Expand the tree display and click the required BSP element. 6. Double-click the selected entry in order to display the documentation for the BSP

element. 7. Using Drag and Drop, drag the selected element or element attribute to the appropriate

position in the layout editor.

Multiple selection within the tree display is currently not supported.

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

ExampleThe 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 = "myLabel"

for = "carrier"

text = "Airline"

design = "LABEL"

width = "65" />

<ui:inputField id = "carrier"

type = "String"

value = "<%=carrier%>"

size = "3"

design = "standard" />

<ui:button id = "myButton"

text = "Find Flights"

onClick = "FIND"

design = "STANDARD" />

<br><br>

<ui:tableView id = "myTable"

table = "<%=flights%>"

headerVisible = "true"

footerVisible = "true"

fillUpEmptyRows= "true"

selectionMode = "MULTISELECT"

design = "ALTERNATING" />

</ui:form>

</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).

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 table-format 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.

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

PrerequisitesYou already understand the concept of BSP extensions and their implementation.

ActivitiesCreate page before.htmDesign solutionCreate a new BSP extension with elementsCreate page after.htmDynamically process BSP elementsCreate a new BSP extension with composite elementsStep 1 a) Implement <sf:SimpleFormItem>Step 1 b) Use <htmlb:SimpleFormItem>Step 2: Create <sf:SimpleForm>Step 3: Changes to the Look and Feel

Design Solution

After analyzing the page before.htm, you need a set of elements that are easy to use and which can be used for the outlined task area. As a result, this is not a universal solution, but a solution for a clearly delimited application area.

Starting with the example, the initial situation is as follows:

• All row and index counters are calculated automatically • All values for the layout (such as width, style, and so on) are hard-coded

• Elements <htmlb:label> and <htmlb:inputField> are linked to each other. • The flexibility of the <htmlb:inputField> is still available, so that you can carry out

functions such as password handling without any problems

The format of the layout can be specified with BSP elements as follows:

<sf:SimpleForm id = "sf" >

<sf:SimpleFormItem id = "name" label = "Name:" value = "<%=name%>" />

<sf:SimpleFormItem id = "password" label = "Password:" value = "<%=password%>" password = "TRUE" />

<sf:SimpleFormItem id = "email" label = "Email:" value = "<%=email%>" />

</sf:SimpleForm>

Here you require a new BSP extension, which contains all of the necessary elements. You also need a test page, of course. Finally, you also need to implement the elements.

ProcedureThe 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