Error Handling in the Web Request Form 

Use

You can use this function to provide checks in your Web request forms to support requesters or processors when they enter request data.

There are two types of checks: those delivered by SAP and those to be implemented by the customer as Business Add-Ins (BAdI). Checks take place when DDIC objects are included in the request data structure for which an entry check is defined. For example, fields of data category DATS can be checked for the correct date format.

Entry checks are always run as soon as a request is triggered in the request form, for example using events CHECK or SUBMIT. You can access all messages from the layout using method GET_MESSAGES of application class CL_USW_FORM_RUNTIME_BSP_SCR. The messages that occur are collected in the Web Application Server as XML data and transferred to the request form as return parameters where they are display as message short texts

Prerequisites

·        You must implement the definition of customer-specific error handling in BAdI CRM_SERVICE_WEBREQ using method FORM_ON_EVENT.

For more information, see the implementation guide of CRM under Customer Relationship Management ® E-Service ® Web Requests ® Business Add-In for Web Requests.

·        The messages intended for users must be made available in the corresponding request category view. You can access this message on the Web Application Server using class CL_UXX_MESSAGE. All messages have the following structure:

 

Component	Cat.	Description
TYPE	Char (1)	Message category I (information), W (warning) or E (error)
ID	Char (20)	Message class
NUMBER	Numc (3)	Message number
MESSAGE	Char (220)	Message text
MESSAGE _V1	Char (50)	Message variable
MESSAGE _V2	Char (50)	Message variable
MESSAGE _V3	Char (50)	Message variable
MESSAGE _V4	Char (50)	Message variable
PERSISTENT (optional)	Char (1)	Message is not deleted before new round trips
FIELD (optional)	String	Message with field reference
MESSAGE_PARAMETER (optional)	String	Customer-specific message parameter

 

Features

The following is intended to give an overview of the functions that you can program for customer-specific error handling.

Message with Field Reference

You can create the assignment between an error message and the corresponding input field. A possible application example would be the navigation of an error message to the incorrectly filled in the request form.

(See: Messages with Field Reference)

Formatting Incorrect Fields

You can highlight input fields on the request form that are filled in incorrectly. Depending on the error category, the frame or background of a field can be highlighted in color or a message icon can be attached.

(See: Formatting Incorrect Fields)

Saving Incorrect Request Data

The program is terminated by default as soon as a formatting error is processed with the DDIC data binding. This termination however also prevents customer-specific BAdIs being run and customer-specific messages being issued. You can override this system behavior and allow incorrect entries to be saved at BSP page level.

(see: Saving Incorrect Request Data)

Persistent Error Messages

Error messages are usually deleted before each new event and then processed again. You can override this system behavior and make individual error messages appear permanently. This function is suitable for entry corrections made in the system – this information is then normally deleted with the next event.

(see: Persistent Error Messages)

Customer-specific message parameter

You can control a different error handling method using this parameter. For example, you can control that certain messages are issued in the request category view of the requester.

(See: Customer-Specific Message Parameters)

Example

The above-mentioned functions are programmed in the processor view of sample request SAP_DEMO01. For more information, see SAP_DEMO01: Requesting a Parking Permit.