Including an Archiving Object in the Application (Archiving WB) 

Use

Each time an archiving object is generated with the Archiving Workbench (CA-GTF-TS-GMA), you, as the developer of the application containing the data to be archived, must ensure your application is connected.

You are responsible for the following on the application side:

·       Programming the business check that the system uses to determine whether the data can be archived.

You must ensure that data is only archived if it is no longer required in the operational system.

Typical questions to be included in the check:

¡      Does the master table entry have a status attribute that can affect the archivability of a data object?

¡      Are there any data objects from other applications that are dependent on the data object you want to check?
(This implicitly determines an archiving sequence for data objects from different archiving objects).

¡      Do you have to guarantee a consecutive archiving of data objects from one particular application? Are there several data objects from the same archiving object that have to be archived simultaneously?
(This implicitly determines an archiving sequence for data objects from the same archiving object).

·       Calculating the resubmission date on the basis of which the system determines whether database access is permitted in view of the archiving status of the data record in question.

This document contains a list of factors you must consider when integrating an archiving object in an application. We also advise you to read it if you developed the archiving object, but not the application.

Prerequisites

Before you can proceed, the corresponding archiving object must be generated with the Archiving Workbench.

Business Check Module

Check Module Interface

The check module is called up by the archiving analysis process. The system uses the module to transfer master table entries with residence times that have elapsed.

...

      1.      Specify the following data for the interface on the Changing tab page of the corresponding function module:

¡      Parameter name: s[prefix]_[archiving object name]_CHECK_ARCHIVE

¡      Classification: TYPE

¡      Reference category: : [prefix]_tab_[name of master table]_rt

      2.      Make sure the check module is in a function group from your application since you are responsible for this function module.

However, the table type [prefix]_tab_[name of master table]_rt is in the package generated by the Archiving Workbench for the archiving object. This table type contains some or all of the fields from the archiving object master table, in addition to archiving control fields.

Specify which fields are required for your check. You can improve performance considerably by reducing the structure down to the required fields. You must, however, include all fields that the customers could use for customer enhancements.

Activities Permitted in the Check Module

If the checks for a data record from the table transferred determine that it cannot be archived, make sure the system changes the ARCHIVE_STATUS indicator from 2 (Can Be Archived) to 1 (Cannot Be Archived).

If the checks determine that the data record can be archived, you do not need to take any action.

Make sure the following applies:

·       The system does not remove any records from or add any records to the internal table.

·       The system does not change any attributes except ARCHIVE_STATUS. This applies to the resubmission date ARCHIVE_FLUD in particular. The system calculates the latter on the archiving side, in other words, for the application in general.

These rules also apply when programming the customer enhancements (BTE, BADI).

Includes

Use the AFX_GLOBAL_ARCHSTAT_PUBLIC include for constantsg_con_archive_status_arch and g_con_archive_status_noarch.

Check Sequence

§       Make any selective and/or cheap checks before non-selective and/or expensive checks.

§       Ensure that the system skips all other checks as soon as it determines that a data record cannot be archived.

§       Make the customer enhancements (BTE, BAdI) at the end of the check sequence.

Error Handling and Log

Make sure the system flags the data records with Cannot Be Archived if there is an error during the data record check. If the error is serious, meaning that inconsistent data results, make the following log entries:

·       Only write one message in the error log for each data record.

·       Make sure that it is the check module itself writing messages in the log and not any of the function modules called up by it. Deactivate the log before calling up other function modules.

·       Ensure that the error message contains the object key and a note stating that the system has flagged this data record with Cannot Be Archived, as well as the short text error information.

·       Do not write any status messages in the log. If a business prerequisite is not met, it does not constitute an archivability error. Ensure that the system terminates if any serious errors occur that may have an effect on all the subsequent data records.

Additional Information

Package Concept

If you use the package concept (defining package interfaces and use access) in your project, you must submit a use access against package interface _ABA_PLUS_DEFAULT and the package interface defined for the archiving object package.

Determining the Archiving Status and Resubmission Date when Newly Creating a Data Record

When newly creating a data object, use function module [prefix]_API_AR_[abbreviation of archiving object]_FLU_STA_GET to help you enter values in the two newly added fields ARCHIVE_STATUSand ARCHIVE_FLUD in the master table.

Note that the Workbench does not generate this function module in its current version at this stage. When you create this function module, make sure that it calculates the residence time correctly (you can reuse the analysis program coding here). Also note that you must set the ARCHIVE_STATUS value to 1 (Cannot Be Archived) since the system does not make any business checks here.

Note that it may be necessary for the system to calculate the resubmission date for database updates of the data object in question, depending on the business context. In individual cases, it may make sense to calculate this date for updates only.

Checking the ARCHIVE_STATUS Field

Take note of the following:

·       Since the archiving object, as generated, does not participate in any locking logic you may have implemented in your project, you must check the value in the ARCHIVE_STATUS field at the start of a processing unit (logical unit of work) and before updating the database.

Using locks during the archiving process may be performance-critical, especially in the mass data environment. Therefore, check whether you really need to set locks for your project.

·       When starting the logical processing unit (logical unit of work), you may only select data to be changed if the value of the ARCHIVE_STATUS attribute in the master table is g_con_archive_status_noarch 1 (Cannot Be Archived).

·       You must make the check again before updating an entry in the master table.

·       Make sure the system terminates processing with an error message if one of the scenarios below occurs:

¡      Scenario 1: The ARCHIVE_STATUS attribute has the value 2 (Can Be Archived) because the system analyzed the entry in the master table and found it was archivable.

¡      Scenario 2: The data record no longer exists because the system analyzed, archived and deleted it.

Result

If you have executed all the steps described, the archiving object is technically complete from the application side. However, there are some technical administrative activities still open (such as assigning the transactions) that have to be executed by the developer of the archiving object, along with other manual postprocessing steps. You can find more information on this in the Manual Postprocessing (Archiving Workbench) section of the SAP Library.