Document 1

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

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 serverside 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: Tailoring Layouts to BSP Applications

See also: 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): ://.<domain>.<extension>:/sap/bc/bsp// 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: sap-ag.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:

See also: Starting and Ending a BSP Application Cache Key

Starting and Ending a BSP Application Use URL parameters can be used to inform the BSP runtime environment to start or end a BSP application (corresponds to the OK code “/n” in SAP GUI) To do this, the Query

String parameter sap-sessioncmd is added to the URL and the HTTP request is sent to the server. To be compatible with SAP Internet Transaction Server (ITS) and the SAP Enterprise Portal (SAP EP), you can also use ~SAPSessionCmd.

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

Procedure The following commands are supported: •

open: Restarts a BSP application that is running. The application is started 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?sap­ sessioncmd=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?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.

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.

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 element and call using the element. The advantage of using 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 element is more variable than adding them using INCLUDEdirective, since it is triggered at runtime. With the call option using , 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 view’s 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

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

SAP Library BI Content SAP BI Content Library

SAP Library BI Content

Getting Started

Glossary

Getting Started

Getting Started

Help on Help

Glossary

Glossary

Feedback

Help on Help

Help on Help

Adva

Feedback

Feedback

Adva