Interface IF_BSP_NAVIGATION 
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 by the parameter NAVIGATION.
There are two possible options for navigating between BSPs:
In the BSP layout, the subsequent page is addressed directly in the relevant HTML elements such as <form> or <a>.
In the layout of a BSP only the page itself is referenced (for example, in <form> or <a>-HTML elements with <%= page->page_name( ) %>) and a page change is triggered (per HTTP Redirect) by means of the NAVIGATION Object that corresponds to the event. This is the preferred method in BSP applications.
Page control using the navigation interface requires in some cases transfer of arguments to the auto page attributes of the subsequent page. There are methods available for this purpose in the navigation interface.
Caution
Note that the amount of data to be transferred is restricted by Web Browser limitations (typically to 1KB). You should not try to transfer large amounts of data, but rather where possible selection IDs that lead to the data concerned.
If this is not possible in every case, you can use the mechanism "Auto-Submit-Forms" as an alternative (see IF_BSP_NAVIGATION~USE_AUTO_SUBMIT_FORM()). This lifts the data volume restriction. However, we recommend that you do not use this mechanism as a general rule since it causes problems with the browser history and it is not available for all devices (for example, WAP).
CL_BSP_NAVIGATION
-
-
-
Signature |
End of the code. |
|
Description |
You can use this method to call an external application. The application is accessed via the HTTP Redirect mechanism. You must specify the external application in the parameter URL. There are two prerequisites for returning to the calling application from the external application: 1. The calling application must be implemented accordingly and 2. The required return address must be specified. The current page from which the external application was accessed is taken as the return URL. The parameter return_event_id lets you select an additional event ID that should be triggered on return as the event ID in the OnInputProcessing event handler of this BSP. Since we cannot assume that all external applications have the same prerequisites for transferring the return address, you have the option of selecting this in the parameter return_url_parameter as required. The default name is sap-exiturl, whereby BSP applications are able to call each other easily. For ITS-based applications, the address ~exitURL should be used.
Actual navigation is not triggered at this point. It is triggered on return from the BSP event handler! End of the caution. |
|
Parameters |
URL |
URL of external application |
RETURN_EVENT_ID |
Name of the parameter used to transfer the return address/URL to the calling application |
|
RETURN_URL_PARAMETER |
Event ID used to address the OnInputProcessing event handler of the calling page on return from the calling application |
|
Return Values/Exceptions |
- |
|
Signature |
End of the code. |
|
Description |
This method controls whether the parameters defined using set_parameter() should be passed uncoded in plaintext as name/value pairs in the query string of the URL, or coded, that is, BASE64-coded as a value of the URL parameter sap-params. Parameters are passed in coded form by default.
Note that we are talking of coded form here, not encrypted. End of the caution. |
|
Parameters |
ENCODED |
0: Parameter is passed in plaintext as name/value pairs 1: Parameter is BASE64-coded |
Return Values/Exceptions |
- |
|
Signature |
End of the code. |
|
Description |
This method terminates this BSP application regardless of whether the application is working stateful or stateless. In particular, the event handler if_bsp_application_events~on_stop is triggered if the interface IF_BSP_APPLICATION_EVENTS is implemented by the application class. You can use the optional parameter exit_url to branch to any end page or URL per HTTP Redirect.
Actual navigation is not triggered at this point. It is triggered on return from the BSP event handler! End of the caution. |
|
Parameters |
EXIT_URL |
URL to which a HTTP Redirect should branch as the "end page" |
Return Values/Exceptions |
- |
|
Signature |
End of the code. |
|
Description |
This method returns the value of the requested parameter from the Navigation Object.
Unlike set_parameter(), this method always returns the value as a string. End of the caution. |
|
Parameters |
NAME |
Parameter Name |
VALUE |
Parameter value |
|
Return Values/Exceptions |
- |
|
Cross References |
Refer also to: set_parameter |
|
Signature |
End of the code. |
|
Description |
This method handles navigation to the specified URL. In most cases, this is a relative URL and contains only the name of the subsequent page, for example navigation->goto_page('confirm.htm' ). Unlike the method next_page(), here the subsequent page is specified directly.
Actual navigation is not triggered at this point. It is triggered on return from the BSP event handler! End of the caution. |
|
Parameters |
URL |
URL of the subsequent page, typically a relative URL or only the page name |
Return Values/Exceptions |
- |
|
Cross References |
Refer also to: next_page |
|
Signature |
End of the code. |
|
Description |
This method indicates whether parameters have been set for the current navigation object (0: no, 1: yes). |
|
Parameters |
- |
|
Return Values/Exceptions |
HAS_PARAMETERS |
0: No parameters set 1: Parameters set |
Cross References |
Refer also to: set_parameter |
|
Signature |
End of the code. |
|
Description |
This method defines the subsequent page by specifying a page exit. You can define page exits of a navigation graph in the development environment (transaction SE80) of a BSP application. When you do so, starting from the current page, you assign a target page via a page exit (that is, a "link" identified by a unique name). Then, for navigating between pages, the subsequent page is not directly defined in ABAP code, an indirection is inserted instead. The name of the page exit is used to determine the subsequent page currently assigned to the page exit. This can be changed easily without having to adapt all of its usages in the code.
Actual navigation is not triggered at this point. It is triggered on return from the BSP event handler! End of the caution. |
|
Parameters |
EXIT |
Name of page exit in the navigation graph (case-insensitive) |
Return Values/Exceptions |
- |
|
Cross References |
Refer also to: goto_page |
|
Signature |
End of the code. |
|
Description |
You can use this method to indicate to the BSP runtime that no further event handlers/sections should be addressed on return from the BSP event handler in which it was called. On the contrary, the HTTP Response has already been completely generated and can be sent back to the client/browser. This method is typically called in the OnRequest or OnInitialization section of a BSP, when the HTTP Response was generated differently from the OnLayout section (for example, MIME Object from the database or generated XML Output) and was written directly to the HTTP Response object. Calling the OnLayout section would, in such cases, include unwanted output in the response (for example, blanks that are of critical importance in binary document). The call can be suppressed here. |
|
Parameters |
- |
|
Return Values/Exceptions |
- |
|
Signature |
End of the code. |
|
Description |
This method sets the specified parameter for the transfer to the subsequent page. As a rule, the name of the parameter is the same as an auto page attribute of the subsequent page. Otherwise, it can be read on the subsequent page using Request Object and the method if_http_request~get_form_field(). In certain circumstances, the value of the parameter can be omitted. This would be the case if a form field of the same name was sent in the current request to be passed on to the subsequent page. The parameter value is then simply taken over from the current request and passed to the subsequent page. Since it is possible to transfer any ABAP data types with the exception of references, the parameter VALUE can only be untyped. |
|
Parameters |
NAME |
Parameter name |
VALUE |
Parameter value. If the parameter is not specified; the value of the form field of the same name of the HTTP Request is taken. |
|
Return Values/Exceptions |
- |
|
Cross References |
Refer also to: get_parameter, has_parameters |
|
Signature |
End of the code. |
|
Description |
With this method, when navigating to a subsequent page, no HTTP redirects can be used, but insread an HTML page is used with an embedded form. The parameters to be transferred are mixed into the form as hidden fields, and the form is automatically returned to the subsequent page (auto submit) after it is received in the browser. Using this method, you can circumnavigate the dataset restrictions with query string parameters. Note however, that auto submit forms can cause problems in the browser history and that this mechanism canot be used with WAP devices, for example. You can use parameter target_frame to control in which HTML frame (or new browser window) the subsequent page should be displayed. |
|
Parameters |
target_frame |
Name of frame in which subsequent page is to be displayed. |
Return Values/Exceptions |
cx_bsp_inv_param_type |
Exception: Exception: the parameter type is not allowed. |