Application Class of a BSP Application

Use

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

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

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

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

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

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

Example

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

In many cases, the application class is only used to encapsulate existing application functions, such as from SAP Customer Relationship Management (SAP CRM), and then access the function through BAPI interfaces. Using an application class to encapsulate the functions ensures that the BSP application functions are stored in a central location (in the application class) and that both implementation and distribution are transparent (local method call but remote BAPI call internally). If a customer or developer wants to change or adapt a BSP application or use the application for an additional device, they have the full functions of the original BSP application available in the interface of the application class.

Runtime Behavior

Any ABAP Objects class can potentially be used as an application class of a BSP application. However, the BSP runtime environment must treat the class as a singleton, that is, a class for which there is only one instance per session.

The lifetime of an application class depends on the state model of the BSP application. A BSP application can be stateful or stateless.

Stateful BSP Application

In Stateful BSP Applications, the only instance of the application class, the application object, is generated at the first request sent to the BSP application. The object is then available for the entire lifetime of the session. The end lifetime of the application object ends when the session ends.

In stateful mode, the application class provides local buffering for data sets that are difficult to determine.

Stateless BSP Application

In Stateless BSP Applications, the application context (roll area) is only available for the lifetime of a single request and is released at the end of the request. When the application context is released, all data and objects held by the session on the application server are also released. This includes the application object.

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

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

Accessing the Application Object

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

Requirements for an Application Class

The only real requirement for an application is that the constructor must be parameterless. Otherwise, the application class cannot be generically instantiated by the BSP runtime environment.

Apart from this, there are no other restrictions. You do need to ensure that the internal implementation of methods is chosen correctly, depending on the state mode where the class is implemented. For stateless applications, for example, it would be useless to implement expensive data gathering routines as these would be lost after every request. Instead, just get the exact data you need at that time. In stateful applications, you can implement an initialization phase where you get a large amount of data at one time, which can improve performance.

Application Events: Interface IF_BSP_APPLICATION_EVENTS

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. Caution Note that this time point is not available after every request in stateless BSP applications. Moreover, the time point is not retained 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 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.