Check on BRF Objects of an Application Class

Use

You can start a check in which the system checks whether all BRF objects of an application class are correct. The system then produces a results log showing the result of the check for each BRF object.

Integration

The BRF uses the infrastructure of the Business Application Log to display the results log.

If you want to find out detailed information on the results log of the Business Application Log, choose Application Help on the results log screen.

Features

Problem Classes of the Business Application Log

The BRF uses the four problem classes of the Business Application Log as follows:

  • Problem class 'Extremely Important' (flagged with a red square)

    Error messages are assigned to this problem class.

  • Problem class 'Important' (flagged with a yellow triangle)

    Warnings are assigned to this problem class.

  • Problem class 'Medium' (flagged with a green dot)

    BRF objects whose configuration is correct and error-free, but whose dependent tables are no longer up to date, are assigned to this problem class.

  • Problem class 'Additional Information' (also flagged with a green dot)

    Success messages are assigned to this problem class.

Format of Results Log

The results log has the following format for each row:

  • Flag for problem class

  • Message text

  • Long text of message

    If there is a long text for a message, this column displays the Long Text Exists icon. Choose this icon to call the long text.

  • Details

    In this column, the system displays the Details Exist icon.

    From here you can navigate directly to the relevant BRF object, check the object, and change it if necessary (see below under 'Activities', 'Correct Errors')

General Notes on Use of Results Log by the BRF

  • As part of product maintenance on the BRF, it might be the case that SAP changes the checks on BRF objects.

    For this reason, you should perform the check on all BRF objects for your application class at regular intervals. This ensures that you are made aware of errors that arise from changes in the product maintenance of the BRF.

    In this check the system might detect and display errors that were not displayed in earlier releases. For example, this might happen after a support package is imported. This means that these were also errors in the past, but that the system did not check these error constellations in the past.

  • If the system displays an error with a BRF object, the error does not necessarily have to be in the object itself. Sometimes just a symptom is visible there.

    Note the following:

    • You can delete entries in data sources without the system performing a check. This can lead to errors in expressions of the type 'Field of a Structure' (implementing class 0SM001) or of the type 'Field of a Line of an Internal Table' (implementing class 0TB001).

    • If you release transports to a target system in an unfavorable sequence, it is possible that one or more than one subexpression is missing.

  • Especially with complicated transport constellations, you should perform this check in both the source and target system, thereby ensuring the consistency of BRF objects.

  • With expression type 'Call a Function Module/Method' (implementing class 0CF001) and action type 'Execute Function Module' (implementing class 0FM001), the system outputs deviations from the relevant reference interface as a warning.

    In each individual case, check whether this deviation is intentional and therefore correct.

  • The system also checks objects that do not belong to the BRF standard. If you have introduced own object types with own maintenance classes, their PAI1 method is executed, among others. The error check is then made in this method.

    Consider the following:

    In the methods PBO1,

    PBO2, PAI1 and

    PAI2, there is no coding that refers to controls (text edit control, tree control, and so on). The check here takes place without the user interface. Since the reference to the control is usually initial, each attempt to call a method of the control leads to a termination.

    For this reason, you should implement control-relevant coding in the maintenance classes in the methods PBO_CONTROL and

    PAI_CONTROL. These methods are called only in dialog, and not in the absence of a user interface.

Activities

Performing Checks

  1. Call the Business Rule Framework initial screen. To do so, enter transaction code BRF.

    If you are already working in the BRF workbench, enter transaction code /nBRF.

  2. Under BRF Objects, enter the application class whose objects you want to check.

  3. Choose Check Everything.

    The system displays the results log.

    The system does not save this results log.

Correcting Errors

If the system displays an error for a BRF object, or if you simply want to check a BRF object, you can navigate from the results log directly to the relevant BRF object.

Proceed as follows:

  1. In the Details column, choose Details Exist.

    The system displays the BRF object in display mode.

  2. Switch to change mode. To do so, choose Change.

  3. Make the necessary changes.

  4. Save your entries.

  5. To navigate back to the results los, choose Back.

    In this case, the system does not update the results log, meaning that the original message is still displayed. If you want to update the results log, you must navigate back and then start the check again.