Creating Archiving Objects

The archiving object is a central component of SAP Data Archiving. The archiving object specifies precisely which data is archived and how. It describes which database objects must be handled together as a single business object. and interprets the data irrespective of the technical specifications at the time of archiving

To archive data from InfoProviders, you first need to create an archiving object for the InfoProvider. InfoCubes and ODS objects usually contain one of the closed datasets for a specific business area. Therefore, an archiving object is created for each InfoProvider. Only one archiving object can be created for each InfoProvider.

First of all, maintain the metadata of the archiving object in the InfoProvider. The actual object is not generated until the InfoProvider is activated.

You can also create the archiving object afterwards for an InfoProvider that already exists and is filled with data.

Procedure

1. Call transaction AOBJ.
2. Choose New Entries and enter the following data:

• General Information

• Object Name
  Name of the archiving object

• Text
  Short description
• Application Area
  Organizational category for assigning archive files
• Application Component
  Used for assigning archive files

• Programs and Functions

• Write Program

Name of the program that writes the archive files

• Interruption Possible

Setting this indicator means the archiving object supports Interruption and Continuation of an Archiving Session. If you set this, the write program must also handle the interruption request. This indicator must not be set if the Do Not Start Before End of Write Phase is set.

• Delete Program
  Name of the program that deletes the data from the database after the write program has finished
• Do Not Start Before End of Write Phase

If this indicator is set, the delete programs do not start until the write program is finished. To actually start the delete phase immediately, the Start automatic. indicator must be set in archiving-object-specific Customizing.

This indicator should not be set for most archiving objects. Before you set this indicator, decide whether you actually need to use this indicator or can do without it.

• Reload Program (optional)
  Name of the program with which the data can be loaded from the archive back into the database.

• Prohibit New Session During Reload

If this indicator is set, no new archiving session is generated when reloading archiving sessions. The reload program is not authorized to call the function module ARCHIVE_SAVE_OBJECT.

• Preprocessing Program (optional)
  Name of the program with which data is to be prepared for data archiving.
• Postprocessing Program (optional)
  Name of the program with which data is to be processed after it has been archived. If, for example, the data is only marked for deletion in the delete program, the actual deletion can be executed in the postprocessing program.
• Index Build Program

Name of the program for building indexes

• ArchiveSelect.Active

If this indicator is set, the Archive Selection pushbutton is displayed in transaction SARA for building and deleting indexes. If you select archive files using variants, do not set this indicator.

• Index Delete Program

Name of the program for deleting indexes

• Index Build Allowed

If this indicator is set, an index can be created for this archiving object. For more information, see Creating ADK Indexes and Using Them to Access Archive. The actual index creation can be controlled by a Customizing entry.

• "Invalid" Indicator Cannot Be Revoked

If this indicator is set, the "Invalid" indicator for archiving sessions cannot be reset in archive management once it is set.

• Archiving Object Generated

Indicates the archiving object was generated.

As of SAP Web Application Server 6.10 write and delete programs can no longer be generated at runtime.

• Cross-Client
  Archiving is client-independent.

• End Dialog
  Dialog mode must stop before archiving can begin. Only set this if collisions may occur during data archiving. In general, this should not be set as it was primarily designed for older archiving objects where parallel operation was not able to be guaranteed between online operation and data archiving.

• Documentation

• Info for Write Program

Name of the document containing information about the object-specific write program

• Info for Delete Program
  Name of the document containing information about the object-specific delete program.
• Info for Reload Program

Name of the document containing information about the object-specific reload program.

• Info for Preprocess Prog
  Name of the document containing information about the object-specific preprocessing program.
• Info for Postproc Prog
  Name of the document containing information about the object-specific postprocessing program.
• Info for Read Program

Name of the document containing information about the object-specific read program.

You create the documents using the documentation maintenance transaction (SE61).

3. Save your entries and return to the initial screen of transaction AOBJ.

Result

Your new archiving object is included in the list of archiving objects in the system. You can now create additional information about your archiving object by selecting the line and choosing one of the actions under Archiving Object.

Custom Transaction codes

If we develop some Module pool programs or Report Programs, to make these programs available to the end users. we create transaction codes for these programes."se93" is the transaction where one can create his own custom Transaction codes.
Custom Tcodes will start with Y* or Z*.
For performing any kind of task in the SAP R/3 or BW system, a transaction is used. SAP provides a standard set of transactions to manipulate i.e insert, update, delete and display data in the system. But sometimes, the need to create a customer specific transaction may arise due to the following reasons

--> Standard SAP may not support that task

--> A particular transaction needs to be customized to suit the customer requirements

A transaction is defined as a sequence of dynpros (sap term for screens) having input and output fields and corresponding processing logic behind them to perform a particular task.

We call an execution of an ABAP program using a transaction code a transaction . There are dialog , report, parameter, variant, and - as of Release 6.10 - OO transactions. A transaction is started by entering the transaction code in the input field on the standard toolbar or by means of the ABAP statements CALL TRANSACTION or LEAVE TO TRANSACTION. Transaction codes can also be linked to screen elements or menu entries. Selecting such an element will start the transaction.