History Management of BRF Objects

Use

You can perform history management on the BRF objects that are delivered, meaning that you can record and track chronological changes to a BRF object.

Features

History Manageable BRF Objects:

To enable recording of the chronological change to a BRF object, other statuses are needed in addition to status A (for Active). Listed below are all the statuses that a history manageable BRF object can have. The system displays the status for each BRF object in the Import Status field.

  • A (for Active)

    A BRF object with this status is used for rule evaluation.

    If no history management is possible, the system does not create any transport requests for BRF objects with status A. The current version is always 0. The oldest version has version number 1, and the second oldest version has version number 2, and so on. The penultimate version has the highest version number.

    Each BRF object has a time stamp. If history management is used in a claim, the time stamp indicates when the corresponding object was activated.

    If you want to see which version was active at a certain time in the past, you must select the latest BRF object whose time stamp is the same as or more recent than the reference date.

  • I (for Inactive)

    If you delete a BRF object logically, this BRF object is given status I. A BRF object with status I is not used for rule evaluation.

  • T (for To Be Exported (Active))

    A BRF object with status T is always based on a BRF object with status A. The prerequisite is that the underlying BRF object with status A has not been changed.

    BRF objects with status T are not used for rule evaluation. This is for one of the following reasons:

    • The BRF object has to be exported from the current system (meaning that transport entries have been written).

    • The BRF has been imported into the current system by means of a transport.

    History management is not required for BRF objects with status T. They always have the version number 0.

  • U (for To Be Exported (Inactive))

    BRF objects with the status U are similar to BRF objects with the status T. The only difference is that they originate from objects with status I. This means that they have an inherent logical deletion function.

  • D (for In Development)

    When you create a BRF object, it has the status D.

    BRF objects with status D are not used for rule evaluation. This means that you can change such a BRF object at any time, without any change history being recorded.

    You can physically delete BRF objects at any time.

    Viewed logically, BRF objects with status D have no version number. Technically, they always have the version number 0.

BRF objects with the status T and U are 'not visible' for the runtime environment of the BRF. For this reason, you can transport BRF objects with status T and U to a target system at any time without the behavior of the target system changing.

To execute such a transport, proceed as follows:

  1. To prepare the transport in the source system, execute report BRF_TRANSPORT.

    This report executes the following activities:

    • In the source system it copies the current BRF objects with status A and I to BRF objects with status T and U

    • It creates the transport requests

  2. Execute the transport.

    The BRF objects with status T and U that are imported to the target system do not influence the behavior of the BRF. They are not visible for the BRF runtime environment.

  3. After the import in the target system, execute report BRF_TRANSPORT_IMPORT.

    This report adds the imported BRF objects with the status T and U to the current BRF objects with status A and I.

    The new object definitions have a direct effect on the runtime behavior of the BRF and negatively influence performance.

    We therefore recommend that this report is run at a suitable time.

  4. To delete BRF objects with status T and U that are no longer required in the source system, execute report BRF_TRANSPORT_EXPORT_CLEANUP in the source system.

BRF Objects in Which History Management Is Not Possible:

Existing BRF objects in which history management is not possible always have status A (for Active) and they always have version number 0.

These BRF objects are integrated directly with the transport system.

If you change a BRF object in a client in which transport requests for customizing are written, you must also specify the corresponding customizing request.

Activities

You can define history management at two levels:

  • At the level of the application class

    Here you can define whether history management should be applied at all as part of the options for the maintenance classes.

    To activate history management at the level of the application class, proceed as follows:

    1. On the Business Rule Framework screen, choose Start of the navigation pathApplication Class Next navigation step ChangeEnd of the navigation path.

    2. On the following screen, in the Details section, set the History Management Active flag.

      You can only activate history management, you cannot deactivate it again. If you were to deactivate history management, this could lead to gaps in the history of a BRF object, particularly in production systems. The auditing acceptability would no longer be ensured.

  • At the level of the maintenance class

    Here you can define whether this maintenance class supports history management from a technical point of view.

    All the maintenance classes delivered in the standard delivery support history management.

    If you have developed your own maintenance class, you do not have to decide right at the onset whether you want to use history management. You can make the settings for history management for your own maintenance class at a later stage.

    History management is active at the level of the application class. All maintenance classes of the BRF are able to maintain BRF objects with history management. The attribute IF_MAINTENANCE_BRF~MV_HISTORY_AVAILABLE of the maintenance class is set to TRUE.

    If you have developed an own maintenance class in which history management is not yet possible, you must set this attribute to FALSE.