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_ACTION02 |
| Short Description | Archiving Object or Deletion Object |
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 | Step 02 |
| Medium | 10 | Step 02 |
| Long | 10 | Step 02 |
| Heading | 10 | Step 02 |
Documentation
Control
Here you specify the technical name of the archiving scenario or deletion scenario.
This scenario can be activated for the Archiving Engine. Only activated scenarios can be executed in the Archiving Engine.
Analysis
In the analysis, you first define the header table. The header table contains the business object header and is therefore the master table for the scenario.
Note: A database view can also be registered instead of a database table.
The projection is a structure. The set of fields in this structure is a subset of the fields from the header table. The projection must contain at least the fields from the business key as well as the fields to be archived or deleted (ARCHIVE_FLUD, ARCHIVE_STATUS, REJECTION).
Note: For performance reasons, you should include as few fields as possible in the projection.
The analysis strategy determines the response of the Archiving Engine when a business rejection reason occurs for the first time. There are two options:
a) When the first rejection occurs: No further business checks
b) When the first rejection occurs: Start further business checks to determine a better (further in the future) resubmission date.
If dynamic package formation is activated, you need to enter a structure that predefines sorting in the relevant field. The Archiving Engine then forms packages that all have the same values in the sorting attributes. Each time the group level is changed in the sorting attributes, a new package is formed.
The 'Summarization' field can be used to summarize the AIS. The following conditions must be met:
a) The structure of the sorting attributes must be registered as a table.
b) The AIS contains the exact fields in the sorting structure
c) The read module selects data according to the sorting attributes (not according to the business key)
d) An index must be defined in the header table (index fields = sorting attributes)
If summarization is active, the read module is called for each package (that is, each group level change in the sorting attributes)
'Rejection Reasons' lists the business rejections that can potentially occur. These are primarily the business rejection reasons from the business check. Technical rejection reasons are also listed here (such as rejection due to inconsistent business objects).
Note: a) You cannot change the sort sequence of the table that is transferred in parameter T_TABLE when implementing modules. You are also not permitted to add new entries or to delete existing entries.
b) In the 'Filling of Add-On Fields' module or the 'Determination of Scheduling' module, you can indicate a business object as inconsistent, if this is useful. REJECTION is set to 'XX' in this case, whereby the 'ARCHIVE_STATUS' and 'ARCHIVE_FLUD' fields are not changed. You can identify and analyze such business objects in Archiving Monitor Diagnostics.
Retention Policy
The aim of the analysis is to determine whether business objects can be separated from their business context. This is determined in the business check. Only business objects that have reached a time criterion (for example, credit card has been invalid for 5 months) are considered in the worklist for the business check.
To generate the worklist of business objects for the business check, the Archiving Engine requires:
- a) A reference date for the business object (such as valid-to date)
- A procedure for assigning a residence time to a business object
- A lower limit for the residence time
Business objects for which the following applies:
Business object basis date + business object residence time <= system date
are included in the worklist for the business analysis.
For a) The reference date of a business object is retrieved using the 'Scheduling' module.
For b) Under 'Add-On' fields, you define additional fields that are not in the header table. Under 'Filling of Add-On Fields', you can store a module that enters values in these add-on fields.
These add-on fields are relevant for residence time Customizing. There you can define rules (based on fields in the projection and add-on fields).
The Customizing for residence time definition can be activated for each attribute list.
The attribute list is a selection of the attributes in the 'add-on' fields structure. The residence time is derived from the set of attribute values for a specific business object header (input vector). This takes place in Customizing with the HDS (Hierarchical Derivation Service, transaction AR_HDS). The attribute list fields are provided there, and you can define suitable conditions. (For example, bank posting area = 001 and product = VISA* => residence time 5 months).
For c) The Archiving Engine ensures that business objects remain in the system for at least the 'minimum residence time', starting from the reference date.
Notes
1) Individually defined F4 search helps for the conditions in the HDS can be stored on field level in the DDIC structure. Navigation Attributes-->DDIC-->Search Help Connection.
2) If no attribute list is defined, the standard residence time is used (transaction AR_CUST ). This means that the Archiving Engine can be used without activating rules for calculating the residence time.
3) The residence time used is always later than or the same as the 'minimum residence time', regardless of the residence time calculation.
4) You cannot change the sort sequence of the table that is transferred in parameter T_TABLE when implementing modules. You are also not permitted to add new entries or to delete existing entries.
Business View Platform
On the Business View Platform tab page, you define a transaction code that provides access to the business display of the archived data. The AIS data is displayed with the SAP List Viewer. A single AIS data record refers to the position of a specific business object in the archive to be displayed using a business view.
The DISPLAY( ) service below displays this specific business object.
This service is called directly after an AIS data record has been selected using ON_HOTSPOTCLICK.
You can use CL_AR_BVW_PLATFORM_FACTORY=>S_GET_INSTANCE( ) to determine a business view platform.
Per interface IF_AR_BVW_PLATFORM
=>DISPLAY( )
in the dialog module, a business object for business key xy can be shown in a business display. Within the business display logic for the detail view,
CL_AR_ACCESS_FACTORY
=> S_GET_ALL_TABNAMES( )
=> S_RETRIEVE_TABLE_DATA( )
=> S_GET_ARCHIVE_POSITION( )
=> S_GET_ARCHIVE_POSITION( )
can be used to access the table contents for the business object and display these using the display logic.
Reference example: Archiving scenario SFLIGHTAR:
Execute using transaction AR_ENGINE->Flight Bookings (SFLIGHTAR)->Display->Execute
Define using transaction AR_FACTORY->Detail Screen 'Flight Bookings (SFLIGHTAR)' ->Tab 'Business View Platform'
Note: The registered business view transaction is provided on the Archiving Engine UI. If there is no transaction registered, the Archiving Engine UI provides the technical display only.
Other
You can specify a time period (in days) for reloading archived data here. Archiving runs that are older than this value can no longer be reloaded to the operational system.
A preprocessing program is primarily intended for the preparation of business objects. You can store a report here that prepares the business objects for participation in the archiving or deletion process.
Caution: The preprocessing program is not processed in parallel. It needs to use delta technology for performance reasons. Business objects that have been previously handled or prepared should not be reprocessed if execution is repeated.
You can store function modules for logging error messages under 'Logging Start' and 'Logging End'.
'Logging Start': This function module opens an application-specific log.
'Logging End': This function module closes the application-specific log. This module also determines the collected error messages in the application-specific log and forwards these to the Archiving Engine using the internal table T_MESSAGE.
The messages collected in this way are visible in the Archiving Monitor under 'Log'.
Caution: 'Logging Start' is called at the start of the first package in a thread. 'Logging End' is called after the last package in this thread.
Note: You must not re-sort, delete, or add entries in/
History
| Last changed by/on | SAP | 20110908 |
| SAP Release Created in | 40 |
