Data Aging Objects
Data Aging takes place on the basis of data aging objects and their enhancements that contain data tables that are to be moved.
Data Aging Objects
Data Aging Objects (DAgOs) define the number of participating tables for a data aging run. If necessary, data aging objects can be enhanced with additional tables. The enhancement of data aging objects takes place using one or more specified Business Add-Ins (BAdIs) that are provided by the corresponding application. A table can be assigned to a data aging object and also to all of its enhancements just once. This makes it possible to assign a table multiple times within a data aging object, as long as it has enhancements. A table can be assigned to more than one data aging object.
Data aging objects and their enhancements are delivered by the individual SAP applications. You can enhance the data aging object if needed.
Example
If table DAAG_EXA_SFLIGHT is already assigned to an enhancement of data aging object DAAG_SFLIGHT, then this table cannot be assigned to the data aging object DAAG_SFLIGHT itself or to a second enhancement belonging to the same data aging object. The table can be assigned to an additional data aging object, for example DAAG_SFLIGHT2.Type of Data Aging Objects
There are four types of data aging objects:
- Application Data Aging Object - The Application Data Aging object is implemented by the applications. It has a runtime class that implements the interface IF_DAAG_RUNTIME. In this runtime class, the following checks are performed for the data records that are intended for data aging:
- Moving of data from current to historical data
- Setting a data aging temperature
An Application Data Aging object can be enhanced. If an enhancement declaration is made, it needs to provide BAdIs as specified by the application and call them for the application-specific runtime. The BAdIs are implemented by the parties providing the enhancement.
- Service Data Aging Object - The Service Data Aging Object has an entity of a data aging object with the characteristics of a service and has a self-determined runtime independent of other data aging objects. The applications use some common services such as SBAL or IDOCS that have self-contained time or date information within their tables that can be used for aging decisions by its own rules. Therefore, this type of service can run as an independent data aging object that has its own IF_DAAG_RUNTIME implementation. It must not be involved in the aging run of an Application Data Aging object. Service Data Aging object offers a veto BAdI that is called within the runtime logic. You can avoid the relocation of the data managed by the common service.
- Reuse Data Aging Object - An entity of a data aging object that has reuse character and is without self-determined runtime depending on the application data aging object. This is because applications use some common services such as Status Management (Jest) that do not have self-determined time or date information within their tables. For this reason, this type of reuse service cannot run as an independent Data Aging Object. It needs to be involved in the aging run of a leading Data Aging Object. Hence it needs to provide a service class that selects the data. This class needs to be called within the runtime class of the leading Data Aging Object.
- A data aging object can have multiple enhancements. An enhancement belongs to exactly one data aging object. Data aging objects that can be enhanced call one or more BAdIs at runtime. These BAdIs can be implemented by industry-specific solutions or by customers. Enhancements do not have their own runtime class that is called by data aging during runtime. The runtime of enhancements depends on the implementation of the available BAdIs belonging to the data aging object. The tables participating in the enhancements are defined by the SAP application during design time. The tables must all fulfill the same criteria as the tables for the data aging objects.