Vous êtes sur la page 1sur 14

What is a BSP Application?

Overview
A Business Server Page (BSP) application is a complete functional application similar to a SAP
R/3 transaction. Instead of being displayed using SAP GUI, these applications are displayed in a
Web browser or a mobile device browser, such as a WAP cell phone. HTTP or HTTPS is used to
access the application across the network, which means that standard products like firewalls and
proxy servers can be used.

Business Server Pages were introduced in release SAP WEB AS 6.10. BSPs are SAP’s
implementation of a server-side scripting framework.

Naturally, ABAP was extended with a new Web development environment, called Business
Server Pages (BSP). Like all other ABAP programming tools, BSP is integrated into the ABAP
workbench (SE80) and fully supports the Transport management system.

BSP has been shipped as an integrated 'part of the ABAP technology stack since Web AS
Release 6.10. Release 6.10 contains the functionality to create basic BSP pages with flow logic.

With Web AS Release 6.20, SAP introduced major enhancements to the BSP technology: Model
View Controller and BSP Extension Elements.

BSPs allow developers to create web applications that can dynamically access SAP data.

Clients utilize web browsers such as Microsoft Internet Explorer or Netscape Navigator to access
BSPs rather than the traditional transactions in SAP GUI.

Kalyan
BSP v/s Web-Dynpro:

There are several architectural differences between BSP and WDA. WDA may have some more
advanced features compared to BSP, but it is a far more restrictive framework.

1. WDA is state-full only. BSP supports both state-full and stateless programming models.
2. WDA hides the clients rendering technology; as a consequence it does not allow low-
level access to include custom html or java-script or others.
3. WDA targets today’s browser, it presents abstract UI layer with abstract controls, BSP is
centered on browser-based deployment and allows extreme low-level of custom
rendering without hiding the rendering logic.
4. WDA is only available from Netweaver-04S.

Architecture of BSP Runtime Environment.

Client submits request via HTTP to SAP system running SAP WEB AS
ICM receives request, SAP complies with BSP page, formats into HTML
SAP returns response to ICM which forwards to client
Client receives response via HTTP from ICM.

ICM:
The Internet Communication Manager (ICM) is responsible for handling all

Kalyan
aspects of the HTTP communications between all browsers and the Web AS. The
ICM is completely implemented inside the Web AS kernel, and always runs as a
separate process, to be able to handle the high overhead involved in establishing
and managing TCP/IP connections.
When the user enters a URL in the browser that points to the Web AS, the browser will first open
a TCP/IP connection to the Web AS. The ICM will accept the incoming TCP/IP connection and
then will wait until the complete HTTP request has been received from the browser before
dispatching it to the next layer for processing. After processing within the ABAP stack, an HTIP
response is available for transmission to the browser. The HTIP requests and responses are
transferred between the ICM (running in a separate process) and the ABAP stack using
shared memory pipes.
The operation of ICM is controlled via transaction SMICM. This transaction gives a complete
overview of all facets of ICM.

ICF – Internet communication Framework:


The Internet Communication Framework (ICF) handles access control, authentication, and
dispatching of incoming HTIP requests. In addition, the ICF starts and controls the debugging of
HTTP requests.
The operations of the ICF layer is controlled by transaction SICF

Components of a 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.

• Business Server Pages (BSPs)

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

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.

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.

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

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.

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

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

• Page attributes:

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.

• Layout: presentation logic for BSP using server-side scripting is implemented in the
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

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

Programming Models for BSP:

The Business Server Pages programming model is similar to the Server Page Technology. This
technology has been widely used in the field of Web development. The focuses of the BSP
programming model are points that ensure optimum structure in interfaces and business logic.

BSPs can be programmed in two ways.


1. Basic BSP Programming model
2. MVC design pattern

With the basic BSP Programming model the BSP applications are created by controlling event
handlers and navigation structures for redirection. In this model we use page attributes for data
transfer, event handlers for dynamic programming and navigation structures for page redirection.

MVC Design Pattern: is a widely used and proven user interface programming model. Its
controller-based use ensures an even clearer distinction between application logic and
presentation logic in BSP applications.

The Model View Controller (MVC) design pattern contains a clear distinction between
processing control, data model and displaying the data in the interface. These three areas are
formally distinguished from each other by three objects: model, view and controller. As a result,
you can easily split Web applications into logical units.

The model is used as an application object of the application data administration. It responds to
information requests about its status, which usually come from the view, as well as to statements
for status changes, which are usually sent by the controller. In this way, only the model is used to
process data internally, without making reference to the application and its user interface.
There can be different views for a model, which can be implemented using different view pages.

The view handles the graphical and textual output at the interface and therefore represents the
input and output data in each interface element, such as pushbuttons, menus, dialog boxes and

Kalyan
so on. The view takes of visualization. To visualize the status, the view queries the model, or the
model informs the view about possible status changes.

The controller interprets and monitors the data that is input by the user using the mouse and the
keyboard, causing the model or the view later to change if necessary. Input data is forwarded and
changes to the model data are initiated. The controller uses the model methods to change the
internal status and then informs the view about this. This is how the controller determines
reactions to the user input and controls processing.

BSP Directives:

BSP directives are enclosed in tags: <% Directive %>

Page Directive: is used to specify the script language. ABAP and JavaScript are currently
supported.

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

Inline Code: With this directive you can embed the script code into the page. The inline
code is written in the language specified with the Page directive.

<% inline code %>

Kalyan
Comments: used to write comments on the code on the server. Unlike code that includes
HTML comments, server-side comments are not included in the page sent to the client
browser.

When you use HTML comments, however, they require longer processing times as well
as larger bandwidths. This is why you should not use HTML comments with BSPs or
views.

<%-- code comments or text --%>

Include Directive: this directive is used to paste in existing pages or pages fragments into
the page.

<%@ include file="relative URL"%>

Transferring Variables: transfer expressions, for example variables, with the following
syntax:

object = <%=varname%>.

Extension Directive: to import a BSP extension into your BSP. As a result you can access
all elements of the extension in your BSP. The extension directive is always located
immediately after the page directive.

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

Accessing a BSP Application.


BSP application can be accessed using the HTTP or HTTPS (Secure HTTP) protocol.
The BSP runtime environment uses the HTTP framework of the SAP Web Application
Server.
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>
Eg: http://myServer.sap-ag.de:1080/sap/bc/bsp/sap/it00

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.

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.

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

Session Handling:

Typically, Web pages are designed to be stateless, meaning that the server will process an
incoming request from a browser and then completely forget about that browser. In such
scenarios, all possible state information required must be stored with the browser. The
server stores no state information. This model allows one server to handle many clients
and even may allow different requests from the same client to be handled by different
servers each time, governed by a load-balancing algorithm.

For more complex business applications, where more information is involved or where
database locks are required until an application is completed, a stateful approach is
required. This can be done either by working in stateful mode, that is, retaining data using
the Application Class or by Using Server-Side Cookies in a stateless application. This
implies that the ABAP session is not destroyed after the HTTP response has been
processed but rather left in memory. All subsequent HTTP requests will not start new
sessions but will all be processed within the same session. This session is exactly the
same as a session opened with SAP GUI.

The only difference between these sessions is that SAP GUI sessions are managed over
TCP/IP connections that are not closed until the end of the session.

Useful Classes and Interfaces in BSP:

Class CL_BSP_APPLICATION is an optional super-class for BSP application classes. It


is recommended that every application class should inherit this class. Class
CL_BSP_APPLICATION has methods that are typically required by a BSP application
for embedding in a Web environment. This is how information about the current BSP
application (such as session timeout, current URL of BSP application, state mode and so
on) can be called or set.

Kalyan
CL_BSP_MESSAGES in BSPs is used for outputting error and information messages.
Each BSP has an instance of this class that contains the current messages of the class.
The object is reset after every HTTP request/response cycle. The object is accessed from
a BSP via the parameter page of the event handler as page->messages or via the self-
reference me in the form of interface qualification me->if_bsp_page~messages.

Class CL_BSP_SERVER_SIDE_COOKIE provides methods for setting, getting,


deleting, and managing cookies on the server. Server-side cookies are persistent data,
similar to the usual client-side cookies. However, while on the client-side, there are
restrictions that limit the size of cookies to around 4 kilobytes per cookie, the number of
cookies to 300 in total and 20 per server or domain, server-side cookies are subject to no
such restrictions. A server-side cookie is stored on the database as a field or as a structure
or as an internal table.

Class CL_BSP_CONTROLLER2 is used to create controllers and Components. Every


controller class automatically inherits all methods and attributes from this central basic
class.

The interface IF_BSP_APPLICATION is implemented using class


CL_BSP_APPLICATION. It provides methods that enable a BSP application to call up
information about its runtime environment or influence this environment.

The interface IF_BSP_APPLICATION_EVENTS can be implemented by a BSP


Application Class if it wants to have control over executing its own functions at specific
points in the lifecycle of a BSP application. The possible time points for doing so are at
application start and end, and at HTTP Request Input and HTTP Response Output.
Typically, these time points are used to carry out authorization checks, data persisting, or
data restoration in stateless BSP applications.

The interface IF_BSP_NAVIGATION controls the transition between BSPs in a BSP


application. The relevant interface reference is available in all event handlers of a BSP
via the parameter NAVIGATION.

The interface IF_BSP_PAGE gives access to information about a BSP such as the page
names, the lifetime, the corresponding BSP application, the URL of the page, and so on.
IF_BSP_PAGE is implemented using the class CL_BSP_PAGE, which is the base class
of all BSPs.

The interface IF_BSP_RUNTIME gives you access to information contained in the


current runtime environment of a BSP application. It gives you access to the most
important objects and information in the form of attributes.

Interfaces IF_HTTP_RESPONSE and IF_HTTP_REQUEST can be reached by an HTTP


request handler using attribute RESPONSE or REQUEST of the interface
IF_HTTP_SERVER. They are used to work with the data of the HTTP request or the
HTTP response.

Kalyan
Global Objects:

The object application refers to the application class of a BSP application.

The object navigation has the same type as interface IF_BSP_NAVIGATION. It contains
methods for navigation between BSP pages. They collect information required for the
presentation of the subsequent page. After the subsequent is navigated to, the navigation
object is deleted.

The runtime object refers to the interface IF_BSP_RUNTIME.

The request object is of the type IF_HTTP_REQUEST.

The response object is of the type IF_HTTP_REQUEST.

The object messages is the same type as the class CL_BSP_MESSAGES. This object is a
message contained and outputs different types of error messages. It contains a list of error
messages with details of severity, condition, and the corresponding text.

The object page accesses information about a BSP. It is the same type as class
CL_BSP_PAGE or the interface IF_BSP_PAGE.

Molding BSP Application to MVC:

Creating a Controller: create a global class that is derived from


CL_BSP_CONTROLLER2.

DO_REQUEST is the central method in a controller class.


n DO_REQUEST you specify the request processing, that is, this method is called for
every request. This method does the "main work"; in particular it should branch to the
correct view.

DO_REQUEST can be used in two different areas:

* If it is the top-level controller of a component, then this method handles both input
and output processing.

* If it is a sub-controller of a component, then this method only handles output


processing.

You should overwrite these methods in order to determine input processing.

Method Description

DO_HANDLE_DATA Reacts to user input.


Processes data input for this component.

Kalyan
DO_HANDLE_EVENT Reacts to user input.
Processes events if the component contains them.

Exactly one view controller is called to handle the


event, which contains an event such as a save
button, for example.

DO_FINISH_INPUT Ends the input processing.

Functions where overwriting is possible

You can overwrite these methods in order to determine input processing.

Method Description

DO_INIT This method is called once at the start and is used


for initialization.

This method behaves like a constructor method.

DO_INITATTRIBUTES This method is called with every request and is used


to initialize the attributes. The parameters are read
from the request. In this method, you can also
execute initializations that are required for each
request.

You can also use this method to set additional


attributes. This method is not absolutely necessary,
since you can use DO_REQUEST to solve everything
that you can (theoretically) handle here.

Creating a View:
• Use the Web Application Builder in the ABAP Workbench (Transaction SE80) to create a page
with the page type View as a sub-object of your BSP application.
• Specify the layout and any attributes that may be required.
• Save and activate your view.

Navigation:

navigation->goto_page

With goto_page, there is a redirect to the specified page (or to the controller), that is, the
browser is informed that it may request a different page. There is then a new browser
request to the destination page.

This has the following effect:

Kalyan
• The browser recognizes the URL for the destination page, since it requested it
itself. In the page does not run in a frame, its URL is displayed in the address line
of the browser.
• An additional browser request is required, which leads to increased network load.
Even if the amount of data is extremely small, this may slow down performance
with very slow networks (such as via satellite).
• In a stateless case, all temporary data from previous processing is lost.

<bsp:goto> Element

With the <bsp:goto> element, the new controller or view is called to provide the content
for the current request.

This means that:

• The browser does not recognize the URL for the destination page, but tries to
communicate with the existing page.
• No additional browser request is required.
• If no

target has been entered in the form of the target page, the request that results
from sending the form (or also from a refresh) is sent to the requesting page. As
a result, the target page only has the task of creating the HTML (view) and does not
usually have to worry about input. The calling page is responsible for this and
thereby takes over the controller functionality.

• The work process does not change, that is, the context remains the same even in a
stateless application and you can therefore access the data and objects that have
already been created.

• The controller must be able to use the input to decide on its current "status" if it
should display several views after each other. It should not store this status on the
server, otherwise the "Back" processing would not function correctly. With
different URLs, this is easier using redirects.

• When you use different views, the URL does not change. As a result, you cannot
use bookmarks on these pages.

DATA Binding:

To make programming easier for you with the MVC design, the framework for the model
of an application provides you with basic class CL_BSP_MODEL, which you can use in
your own model class as a class that passes on its properties. The model class represents
the data context of your application and, as a result, receives a copy of the data (or
references to the data) that are relevant for the view from the database model.

The model class provides:

• The data that are used for the views, with the corresponding type and data Dictionary
information.

Kalyan
• Input conversions

• Information about input errors that occurred for which data

A controller can instantiate a model class or even several model classes. The controller
has a list of all model instances, analogous to the list of sub-controllers.

The controller assigns unique IDs to each model instance.

Note: If you are using the MVC Design Pattern, you do not need to use the Structure
linkApplication Class. Instead of the usual application class with purely page-based BSP
applications, you should use controllers and model classes in the MVC environment.

Process Flow in MVC Approach:

1. First call - DO_INIT.


2. Then call - DO_INITATTRIBUTES.
3. Then call - DO_REQUEST.

Input processing in DO_REQUEST: The browser request is sent directly to the top-level
controller. This dispatches the input to the sub-controllers. Service function DISPATCH_INPUT is
available for this.

The following methods are called:

# DO_HANDLE_DATA

# DO_HANDLE_EVENT

# DO_FINISH_INPUT

These three methods are called by the parent controller only with the form fields for the current
controller.

At output, DO_REQUEST carries out the following tasks:

1. determines whether data must be fetched from the model or from the global
attributes.

2. fetches the table with the object keys from the top-level controller.

3. requests a view.

4. sets the correct attributes for the view.

5. calls the view.

Kalyan

Vous aimerez peut-être aussi