Title
Check in a (new) solution module for BRE

Purpose

• Individual test of a new function module

If you want to include a new solution path for the BRE, you can executea preliminary test using this test environment. You can check that yourfunction module meets the formal requirements, such as correct interface, treatment of exceptions and so on.
You can test your function module before you put it productive use andavoid BRE terminations in the transactions BREE and FLEXBRE.
SAP also recommends that you test your function module for theindividual installations that contain the error the function module hasto correct.
It is, of course, not possible to test all possible situations in thisway, but you can at least avoid basic errors. To do this, executetransaction BREE for just for the individual installation.
You cannot, of course, test all possible situations in this way, but youcan, at least, avoid basic errors.

• Mass test of function modules before BRE runs

To avoid terminating BRE runs, (BREE or FLEXBRE), check all functionmodules in a non-productive dummy installation.
To do this, select the field Execute Functions. Leave the field Function (Individual Test) blank.
If a short dump occurs, temporarily deactivate the function responsiblein the table view ISU_SOLPATH 'solution paths' (see transactionSOLPA) by selecting the indicator OL.
Do not forget to reset the indicator once the function module that caused the short dump has been repaired.
Mass testing modules enables you to locate and correct all incorrectfunction modules that lead to termination.
The mass test does not identify all possible problems, but doesoffer a certain amount of protection from unpleasant surprises.
You have to use this iterative method due to technical reasons. Run timeerrors cannot be simultaneously determined and the system cannot createa complete list of functions that lead to BRE terminations in one go.

Appendix: Formal requirements for BRE function modules
Automatic solutions for the BRE must currently have the form of afunction module (for example, FUNCTION_MODULE), with the followingstandard interface:
CALL FUNCTION FUNCTION_MODULE
EXPORTING
X_SETNO = SETNO
X_MSGID = MSGID
X_MSGNO = MSGNO
X_ANLAGE = INSTALLATN
X_MSGV1 = MSGV1
X_MSGV2 = MSGV2
X_MSGV3 = MSGV3
X_MSGV4 = MSGV4
X_CAUSE = CAUSE
EXCEPTIONS
GENERAL_FAULT = 1
NO_AUTOMATIC_CORR_POSSIBLE = 2
CAUSE_NOT_FITTING = 3
OTHERS = 4.
All parameters, with the exception of 'CAUSE', refer to a backlog entryin the extract table INSTSET. Data is entered in this tableduring extract generation (see, for example, DSETGEN
) where it is processed by the BRE runs (see BREEor FLEXBRE).
"CAUSE" refers to the corresponding field in ISU_CAUSES (check tablefor error causes) (see transaction SOLPA).
In order for the BRE runs to work properly, your new function modulemust correctly return the following exceptions:
CAUSE_NOT_FITTING ,,If the cause does not applyto 'CAUSE'
NO_AUTOMATIC_CORR_POSSIBLE ,,If automatic correction does not
work
GENERAL_FAULT ,,If another general error occurs
If there are no errors, an exception must not be triggered.
For further information on the basis table INSTSET see the documentationon the extract Table INSTSET

Features