Validating Physical File Names Entered by the
User
There are several steps involved in implementing the complete recommendation for validating physical file names entered by the user.

These steps are primarily relevant for validating physical file paths and file names that are provided using the user interface. There may be RFCs or other interfaces that also accept a physical file name as part of APIs. For these cases, implement steps 1 and 4.
The steps to perform are:
...
1. Define a constant to use for the logical file name. (Mandatory)
2. Create a default value for the physical file name, if applicable. (Recommended)
3. Validate the input, if suitable. (Recommended)
4. Validate the file name. (Mandatory)
See the following sections.
For each parameter for a physical file name in your application create one constant of type FILEINTERN (logical file name). Depending on the context of the file access, this constant can be a global constant within a program, local within a specific part of a program, or defined in a type pool for use across multiple programs.
Set the value of this constant to the logical file name used for file name validation in this context.

CONSTANTS gc_fname TYPE fileintern VALUE 'EXAMPLE_FIN1'. |
Create a default value for the physical file name, if applicable, by calling the function module FILE_GET_NAME with the parameter INCLUDING_DIR set to 'X' (for example, during INITIALIZATION).

INITIALIZATION. CALL FUNCTION 'FILE_GET_NAME' EXPORTING logical_file name = gc_fname * any parameters defined for that logical file name including_dir = 'X' IMPORTING file_name = pa_file EXCEPTIONS OTHERS = 1. IF sy-subrc <> 0. MESSAGE ID sy-msgid TYPE 'I' NUMBER sy-msgno WITH sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4. ENDIF. |

You need to catch the exception and change the message type to avoid the program aborting with a message. (FILE_GET_NAME will raise the exception with message type E, which is converted to message type A during PBO.)
There are cases where it is not suitable to create a default file name. Use the following guidelines to determine if it is suitable:
· If the user is required to enter a file name in the user interface, create a default file name.
· If it is optional for the user to enter the file name and an entry would affect the program logic in a misleading way, do not create a default file name. Otherwise, the user must delete the default file name from the field in order to keep the appropriate program logic in place.
· If it is optional for the user to enter the file name, but there is a parameter available to specify that a file should be created (for example, a checkbox item named Create File), then create the default file name.

Example for Creating a Default Value
* Parameter PA_FILE must be specified by the user. * >> CREATE a default value PARAMETERS pa_file TYPE fileextern OBLIGATORY. |
Example for Not Creating a Default Value
* Parameter PA_FILE2 does not have to be specified by the * user. If the file is created later, for example, the file name * is specified for this parameter later in the coding, DO NOT * create a default file name. This prevents the program from * creating a file when the user did not necessarily want this. PARAMETERS pa_file2 TYPE fileextern. |
Example for Creating a File Name Based on a Parameter
* Parameter PA_FILE3 does not have to be specified by the * user, but the program logic will only create the file if the * checkbox PA_CHECK was checked by the user. In this case, * CREATE a default value. If the user does not check the * checkbox, no file will be created. NOTE: if the default * value for the checkbox is that it is checked, you should also * create a default value. PARAMETERS pa_check AS CHECKBOX. PARAMETERS pa_file3 TYPE fileextern. |
Validate the physical file name supplied by the user on the screen where the file name was entered (for example, during AT SELECTION-SCREEN). This ensures that the program returns an error if the file name is invalid immediately and the user can adjust the file name as necessary. If the program performs a lot of its logic before the file name is validated, and the validation returns an error, the processing time and the use of system resources was unnecessary.

AT SELECTION-SCREEN. CALL FUNCTION 'FILE_VALIDATE_NAME' EXPORTING logical_filename = gc_fname * any parameters defined for that logical file name CHANGING physical_filename = pa_file EXCEPTIONS OTHERS = 1.
IF sy-subrc <> 0. MESSAGE ID sy-msgid TYPE sy-msgty NUMBER sy-msgno WITH sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4. ENDIF. |
Validate the file name again directly before the OPEN DATASET or related statement.

If you skipped step 3, for example, because OPEN DATASET is one of the first statements in the program logic, you must be careful about how you process error messages from FILE_VALIDATE_NAME. For example, the recommended procedure for handling error messages for a report is to show the message as an I or an S message and then exit the program in such a way that the user is returned to the selection screen, if possible. If you send an E or a W message, the program aborts and the user has to start over by calling the corresponding transaction or program again.

CALL FUNCTION 'FILE_VALIDATE_NAME' EXPORTING logical_filename = gc_fname * any parameters defined for that logical file name CHANGING physical_filename = pa_file EXCEPTIONS OTHERS = 1.
IF sy-subrc <> 0. * Implement suitable error handling here, for example, * MESSAGE ID sy-msgid TYPE sy-msgty NUMBER sy-msgno * WITH sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4. ENDIF.
OPEN DATASET pa_file FOR INPUT IN TEXT MODE ENCODING DEFAULT. IF sy-subrc <> 0. * ... ENDIF. |