Look at aspects around customizing the behaviour of BSP applications
Error Pages
When an exception is raised within any BSP application (or within a BSP element used within a BSP application), one strategy could be not to catch the exception, but allow it to return back to the kernel. The ICF layer will handle it by writing a dump to database and writing a default error page back to the browser. However, having web pages writing dumps could cause extensive overhead for the server, and prevents customers from writing their own error pages (typically to display company local helpdesk information or link to a trouble ticket system).
With 620SP48, 640SP11 and 700, a change was made so that customers can install their own error handlers. See Handling of errors/exceptions in BSP pages for the complete details. The technique is that the BSP runtime installs an exception handler right at the entry point into the BSP runtime to catch all exceptions and render out a default error page. Important: only exceptions can be caught; hard errors that lead directly to an ABORT_STATE (for example MESSAGE X), can not be caught, and will immediately return from ABAP VM to kernel.
To allow customers to install their own error handlers, an exception database table BSPERRHANDLER is defined. The error reporting of BSP has been changed to look first in this table for an alternative method to use to render the error page.
Any alternative rendering can be implemented in any class, in a public static method. The method must have exactly the same signature as the method cl_http_ext_bsp=>report_error method (importing exception TYPE REF TO cx_root and importing server TYPE REF TO if_http_server). The implementation of the method will usually be very similar to that of method cl_http_ext_bsp=>report_error_html.
Once a new method is completed, the database table BSPERRHANDLER must be updated using transaction SE16.
MANDT |
The client in which the alternative rendering is to be used. |
SORT_KEY |
Entries are matches in this sequence. |
URL |
This is a wildcard string that is matched against the incoming URL to determine if this handler is to be used. For example, having a URL of |
ERR_CLASS |
Name of class the contains error rendering method. |
ERR_METHOD |
The actual method. It must be METHODS: my_error_method
IMPORTING
exception TYPE REF TO cx_root
server TYPE REF TO if_http_server
|
An example error handler class CL_BSP_ERRHANDLER_SAMPLE is also shipped.
Keep in mind that the table BSPERRHANDLER must be configured in each and every system and for all required clients were required. It can be considered to place the table onto a transport using the transport key: R3TR TABU BSPERRHANDLER (for key specify client number and * to transport all records).
See also:
Stylesheets
See BSP In-Depth: ALFS: ABAP (Quick and Dirty) Look and Feel Service for one way to achieve a very quick customization of stylesheets. However, this is limited to allowing you to only define a few basic colours and the base font to use. The benefit of this approach is a relatively good approximation with little work to closely match a corporate identity scheme. The downside is that there is no flexibility for micro adjustment at any level.
Another, more flexible way is described in the weblog BSP/HowTo: CSS Hints - Custom Design for your BSP Applications. There you can find a brief description on additional possibilities the customize the style of your applications and pages.
In addition, see: Handling of themes for HTMLB.