Server-Side Scripting Instructions: Event Control 

Web requests support predefined server-page events for which the following functions can be used:

·        Page navigation (next page, previous page, exit)

·        Check data entered

·        Submit request data

 

Events for page navigation

Events NEXT_PAGE and PREV_PAGE can be used to navigate between the different pages. These events are triggered using the following buttons Page forward and Page back:

 

<input type="submit" value="Next Page"     name="onInputProcessing(NEXT_PAGE)">

     

<input type="submit" value="Previous Page"  name="onInputProcessing(PREV_PAGE)">

 

The corresponding BSP pages (here with the technical names next_page and prev_page), in which you can navigate through the BSP application, should be defined in the hidden fields UWS_NEXT_PAGE and UWS_PREV_PAGE

 

<input name="uws_next_page" type="hidden" value="next_page"/>

 

<input name="uws_prev_page" type="hidden" value="prev_page"/>

 

Dynamic navigation control using the BAdI

In some cases it may be necessary to control the order of pages dynamically in accordance with the request data entered. For example, to be able to skip certain pages depending on the field entries. This logic can be defined using BAdI method FORM_ON_EVENT to redefine the parameter CD_NEXT_PAGE, CD_PREV_PAGE and CD_FROM_EXIT_URL.

 

Exit event

Event EXIT is triggered using the Cancel button:

 

<input type="submit" value="Exit"  name="onInputProcessing(EXIT)"/>

 

This branches to a freely definable URL that you can specify using the hidden field UWS_FORM_EXIT_URL (in this example www.sap.com):

 

<input name="uws_form_exit_url"  type="hidden" value="http://www.sap.com"/>

 

The basic data (for example, the version) must then be transferred to the application as hidden fields. This occurs through the following command:

 

<%= application->insert_hidden_parameters( ) %>

 

Events for transferring request form data to the application

You can trigger events CHECK and SUBMIT analog to the above-mentioned navigation events. As these events are only useful in the create/change mode, the mode is first checked.

 

<% if not application->mode( ) = 'DISPLAY'. %>

   <input type="submit" value="Check"  name="onInputProcessing(CHECK) ">

   <input type="submit" value="Submit"  name="onInputProcessing(SUBMIT)">

<% endif. %>

 

If event SUBMIT is executed, the navigation is also triggered for the page specified under UWS_NEXT_PAGE. This is the confirmation page by default.

 

Make sure that the SUBMIT event can only be triggered once for each Web request. Otherwise more than one service order may be generated for each request created if an incorrect operation occurs.

 

Page parameters

Page parameters that refer mainly to the runtime environment are also generated in each BSP application generated. These are filled by the relevant request, in other words, with the data from the form or parameters of the URL.

Overview of page parameters

Parameter	Meaning
UWS_APPLICATION	In the case of Web requests this is CRM_ORDER
UWS_GUID	GUID of the form (is only filled through the URL when something is changed)
UWS_MODE	Mode: CREATE, CHANGE or DISPLAY
UWS_REFGUID	GUID of the original request (field is filled once the request has been created, or when the Service order instances are used)
UWS_SERVICE_ID	Identification number of request category
UWS_VERSION	Form version

 

Accessing XML data in the event handler:

Request data should be accessed using the corresponding BAdI method. Do you need data for the layout but in the Event handler, you can include the field in the form and assign the content using the same name with the corresponding page attributes.

Another possibility is to use the GET method in the event handler. This is shown in the following example:

 

* get guid

  lv_object_guid =

  application->get(‘//uxx:envelope/uxx:header/uxx:ref_guid' ).

 

See also:

Server-Side Scripting Instructions: Layout Definition

Layout Maintenance for Web Requests: Example