Checking and Testing a Smart Form

Checks

To activate a Smart Form, the individual nodes as well as the interactions between the nodes must be correct. To achieve this, the system offers a large variety of checks.

Before you can use a Smart Form, you have to activate it. During activation, the system checks the entire form (all individual checks executed together). If this check does not reveal any errors, the system activates the form, which means that it generates a new function module.

Each node and each tab has its own check function ( Check pushbutton on tab). This check function is a local check for the current node or the corresponding tab page. Which checks are carried out in detail depends on the type of node. The system checks the conditions mentioned in the discussion of the individual nodes in the preceding sections.

In addition, the application toolbar contains a Check function for an overall check of the form. This check executes all existing individual checks plus some special checks that are to be executed only in the overall context. The result of this overall check is displayed in an error list (see also Field List and Error List).

Data Flow Analysis

The system checks whether a particular field used in a text has a defined value at the moment the text is displayed in a window of the form. This check is called data flow analysis. The data flow analysis is part of the overall check of the form (see above).

After a modification of the output control, you can check whether any printed data still has a defined value or whether the modification created a state in which some data is still initial when it is printed.

The system assumes that a field of a node has a defined value if one of the following conditions is true:

• The field is part of the form interface.

• The field is defined globally and appears as an output parameter in a coding node that was processed before.

• The field is defined globally and is part of the header of a data table, for which repeated processing is defined in one paragraph.

The data flow analysis can produce three different results for globally defined fields:

• The field has one defined value.

• The field has no defined value.

• The field can have a defined value. This happens, for example, if an alternative was processed before and the field receives a value in only one branch of the alternative.

The system checks for all nodes whether the fields used have defined values. If not, the system displays a list of warnings (see also Field List and Error List). These warnings do not terminate the activation or generation.

Checking Text

You can check whether all fields that appear in the text are declared in the form interface or in the global data of the form. Form, use the function module test.

For text modules and include texts it is possible to test at runtime using the system field SFSY-SUBRC if the module or include text exists in the system.

Testing the Smart Form

To test a Smart Form, use the function module test. After activating the Smart Form, choose Test. The initial screen of the Function Builder (transaction SE37) appears. Choose Single Test to go to the test mode for the generated function module. Now you can use all the methods for testing a single function module that the Function Builder provides.

Besides testing a Smart Form, you can also track the processing of a Smart Form using the Smart Forms Trace.

Runtime Error

Each Smart Form can trigger a number of exceptions during its execution. To limit this number of exceptions, you can bundle the occurring errors in error classes and store them in an error log in the composer. Besides the error class, an internal error number and (if possible) a message from table T100 (application, message number, message text, and parameter) are also stored for each field. An exception is assigned to each error class, meaning that if the recognized error has to cause the form processing to terminate, this exception is triggered. When an exception occurs, the caller of the Smart Form can use predefined function modules to read the error log and then decide which reaction is appropriate in the specific error context.

Possible exceptions for the generated function module are:

• FORMATTING_ERROR

• INTERNAL_ERROR

• SEND_ERROR

• USER_CANCELED

In addition, you can define your own exceptions.

If an error (or a warning) occurs, an error table is filled internally. The application can read this table as soon as the function module for the form is processed completely. To read the table that contains all errors and warnings that occurred, call function module SSF_READ_ERRORS. The table has structure SSFERROR. The fields in the table are: the number of the document within the job, the form name, an error number, a message class, a message type, a message number, and four additional message variables. If processing is terminated, the application can display a message dynamically. The error numbers are defined in the include SSF_ERROR.

If you want to trigger your own exception in the free coding of the Smart Form, you can use one of the following methods:

• Use the macro user_exception<exception>, which triggers the exception <exception> and fills the above tables. After the termination, additional system variables for the error (sy-msgno, sy-msgtyp, and so on) do not contain the values required for your own exception.

• If you want to access the system variables sy-msgno, sy-msgtyp, and so on for your exception directly, proceed as follows: Call function module SSF_MESSAGE and trigger your exception yourself using the RAISE statement.