Hierarchy
SAP_ABA (Software Component) Cross-Application Component⤷
CA-FS-ARE (Application Component) Archiving Engine⤷
ARFA_ARCHIVING_FACTORY (Package) Archiving Factory
Basic Data
| Data Element | TYP_ACTION20 |
| Short Description | Check Module |
Data Type
| Category of Dictionary Type | D | Domain |
| Type of Object Referenced | No Information | |
| Domain / Name of Reference Type | XFELD | |
| Data Type | CHAR | Character String |
| Length | 1 | |
| Decimal Places | 0 | |
| Output Length | 1 | |
| Value Table |
Further Characteristics
| Search Help: Name | ||
| Search Help: Parameters | ||
| Parameter ID | ||
| Default Component name | ||
| Change document | ||
| No Input History | ||
| Basic direction is set to LTR | ||
| No BIDI Filtering |
Field Label
| Length | Field Label | |
| Short | 10 | 20 |
| Medium | 15 | 20 |
| Long | 20 | 20 |
| Heading | 2 | 20 |
Documentation
The business check is organized as a hierarchy. In this step, you assign one or more check modules to a check plug-in.
The business context is checked in a check module. If, for example, the current business object refers to neighboring operational business objects, this cannot be removed from the operational system. In this case, there is a business rejection. A rejection reason, as defined on the level of the check plug-in, needs to be set for the current business object.
Often, it is easy to determine the future date on which the neighboring business object might still be operational. This date can then be set as the resubmission date for the current business object. The further in the future this date is, the less often the current business object is selected in the analysis (worklist for analysis is distributed in the future => roll-forward of business objects to be analyzed in the future => better performance, since such business objects are not included in the analysis phase unnecessarily often).
Analysis Strategy 'Optimum Resubmission Time'
The Archiving Engine consolidates the resubmission times from all check modules and determines the date the furthest in the future. This consolidated date is then saved in the business object header in the database. It is used as the basis for future selection for analysis (resubmission).
The sorting criterion is not relevant for this analysis strategy.
Analysis Strategy 'Optimum Performance
The sorting criterion determines the lexicographical sequence of execution of the individual check modules within a check plug-in.
The check plug-ins themselves are also executed according to the sorting criterion. In this way, the sequence of all registered check modules can be defined (sequence definition is optional).
The sequence of check modules is relevant in this analysis strategy. The Archiving Engine ends the chain of registered check modules as soon as the first business rejection occurs.
This has the disadvantage that the resubmission date determined might not be the best one possible (the chain is ended early, the following check modules might determine a resubmission date even further in the future). However, the advantage is that no more performance-intensive checks have to be made after the first rejection occurs. It is advantageous to determine the sequence of execution in such a way that the check modules with the strictest checks are at the start of the execution sequence.
Each check module can be activated or deactivated. Only active check modules are called at runtime in the Archiving Engine.
When you double-click the check module, you are taken to the relevant editor (display/change/create mode).
Interface:
A check module has a whole package of business objects transferred to T_TABLE. T_TABLE has the projection structure' as its row structure, as defined on the Analysis tab page on archiving object level.
The projection contains the fields of the business key, other fields from the header table, and the tupel trio (archiving status, resubmission date and rejection reason).
At call-up, the archiving status is initially set to '2' = archivable, and the resubmission date and rejection reason are initial.
If an entry from table T_TABLE (one entry corresponds to one business object) cannot be archived, the status needs to be set to 1 = not archivable. You always need to set a business rejection reason and, if possible, the resubmission date (results from the neighboring business objects).
If a business object in T_TABLE no longer has an operational context, the table entry can remain unchanged. (The status remains 2 = archivable; the rejection reason and resubmission date remain.
Setting Resubmission Date in T_TABLE for Objects That Cannot Be Archived (Optional)
Example:
Business object A references business object B. Therefore, A must be archived first, then B.
B must always remain in the system longer than A. The resubmission date for B is always later than or the same as the resubmission date for A.
If A exists in the system, B needs to be set to #Not Archivable# in the check.
If B is currently in T_TABLE to be checked, the resubmission date for A can be set as the resubmission date for B, if A references B (non-archivability).
Such references need to be checked in the check module (which business objects reference B).
If more than one business object references B, the resubmission date furthest in the future is selected for this business object.
The further in the future a resubmission date is, the better the Archiving Engine can manage mass data volumes. This avoids multiple time-consuming analyses for a specific business object over time.
Note The resubmission date can also be initial in the check module. In this case, there are more analyses for the individual business objects over time. (performance losses in the archiving scenario).
Note: You must not resort, delete, or add entries in/to table T_TABLE.
History
| Last changed by/on | SAP | 20110908 |
| SAP Release Created in | 40 |
