转 Archiving SAP Work items

Archiving SAP Work items

By Pratik Vora, Wipro from Link

Introduction

Even the most modern and technologically advanced database systems can suffer from performance bottlenecks caused by large data volumes. On the application side these bottlenecks manifest themselves in the form of poor system performance and on the administration side in the form of an increased use of resources. High data volumes can also have a considerable effect on the Total Cost of Ownership of a system, in spite of falling storage prices.

To avoid the negative effects of large data volumes on costs, performance and system availability, business complete data, which is data no longer needed in everyday business processes, should be removed from the database. However, simply deleting this data is not a useful option in most cases, because often times the data still needs to be available for read accesses. Therefore the data needs to be removed from the database and stored in such a way that it can still be read-accessed later.

SAP Data Archiving is the only method supported by SAP to remove application data from the database in a consistent, secure and comprehensive manner. Consistency is ensured through the use of checks performed by the archiving programs. A purely database-integrated archiving is not used, because the database does not know the business context of the data to be archived. Using data archiving you can select significant objects, such as accounting documents, material master records or HR master data, and remove them from the database, without having to worry about the fundamental table design of the linked data.

The archived data is stored in a file system and from there can be moved to other storage media. For security reasons the archived data is not deleted from the database until the archive files have been read and hereby confirmed.

Functions

Data Archiving is a process in which system delete the unwanted data for the production system to some other system, you can think that we have back up option than why data archiving, Now the answer is there are differences between data archiving and data backup, During the backup we just delete the data and copy it on some other device or system, following things misses during backup,

1.             We do not have any option for validation, means suppose we are deleting some data from PO Item table but during back up it will not check in PO header table on that case there will be entry in EKKO table but no entry in EKPO table. System will not be consistent.

2.             After back we do not have any link with the back up data, if we want to read some of the data we do not have any option to read data based on Key field say PO Number.

3.             After deleting for some reason if back up fails we do not have option to restore it.  

All the above mention points and some other points also removed in Data Archiving process. Now Data Archiving process is a safe and reliable way to keep your system fast with recent data and up to date with old data stored in third system.

Now the question is why we need data archiving. In every org.  with increasing number of transaction the size of database increases  which leads the system to perform very slow, and expanses of unnecessary memory ( if we want to increase the performance). We just cannot delete the old data because various times we need those data, some time in Reporting purpose and sometime during Auditing purpose.

Concept of Data Archiving

Data archiving insure us that after archiving system will not be inconsistent. The concept is same which is concept of SAP Business Objects (Transaction Code: SWO1). Every Business Objects consist of various Attributes, Key Fields, Interface and Methods. The concept of business objects is same which the concept of OPPS Programming is.  Let’s take an example of Business Object PO (BUS2012), the key field would be PO Number, Attribute will be Vendor, PO Org etc, the method would be Creation of PO, Deletion of PO etc. With the help of method we can change the attribute of object means we can change the PO, we can delete the PO etc.

Now go on a little bit details, If we think about attributes than where these attributes are stored, they are stored in various transparent tables in SAP with some relations.  We cannot store all the attributes of an object in a single table, concept of Normalization in Data Base. So we have various tables where we are storing the data and making the validation based on Check Table, Value Table Etc. So for PO we have various tables say EKKO for PO Header, EKPO for PO Item, EKBE, MARA, MARC, EBAN……..and there is some link among all these tables so the valid records in all the tables can create a business object ( Close to BAPI).

Now We just cannot delete the records of only EKKO because some relation still exist in EKPO,  EKBE Etc Tables. So if we want to delete a record we need to delete all the related entries from all the dependent tables, and this is the concept of Data Archiving in SAP . In data archiving data cannot be deleted from the system unless it is successfully copied into third system.

The data archiving process in the SAP system can be divided into the following steps:

1. Data is written to the archive

The data to be archived is read from the database and written sequentially to newly created archive files.

2. Data is deleted from the database

The delete program deletes the data from the database after it has been completely written to the archive files. To ensure the integrity of the archived data, the delete session is not started until the created archive files have been read and confirmed.

3. Archive files are stored

The archive files that were created during the write phase can be moved to storage systems or to tertiary storage media. The storage phase is not part of the actual

Step by step Procedure of Archiving Work Items of workflows:

Workflows are quite bulky in nature as one workflow contains around 40000 lines. Workflow archival process is slow and sometime does not effectively reduce key tables and new workflow added faster rates then archival.

The system archives all data (not including runtime data) that belongs to a work item. You can display archived work items, but you cannot reload them into a system.

You can only archive completed workflow work items. This involves archiving all work items that are dependent on this workflow work item as well. A work item that depends on superordinate work items cannot be archived on its own.

You archive log data, workflow manager data, dependent work items and work item attachments (for example, graphics files).

The other objects in the container of a work item are archived only as references. They are not deleted.

Criteria for Archiving

You can only archive those work items that have one of the following statuses:

• Completed

The execution of the work item is completed.

• Logically deleted (CANCELLED)

Execution of the work item is no longer useful or required for the workflow logic.

Objective: To Archive Work items which are created between 12.06.2011 and 12.07.2011 and deleting them from the database.

Steps

1.     Customizing Archiving Objects: Transaction ABOJ

We have two options; either we have SAP Standard object / Custom Objects. For both the objects we have transaction code AOBJ. Object is get the SAP Object which we need to Archive.  

Archiving Object: WORKITEM

Double Click it for details. Here you will be able to see or modify write and deletion program names, which are used for archiving.

The WRITE program is the name of the program which will be used for writing data in to Archive file. Remember this program will change from object to object. Same for delete and reload programs.

Go to Customizing settings for maintaining Logical File path and Customizing for deletion Jobs.

1.     Archiving data: Transaction SARA

Now once you have got the details of the object next step is to configure the system for archiving process. Let’s go a little bit in details. Transaction code is SARA. If you do not put any name in object you will get the following screen.  

As soon as you put the object name there you will get the changed screen. The other attribute it will collect from AOBJ transaction. For Example if we delete the name of the deleting program from AOBJ than Delete option will be removed from here also and if you put some new program name there it will appear here also.

The next screen would be

Before going ahead let’s check what are the dependent tables for the object. Click on DATABASE TABLES. Your screen will be  

If you see at the bottom than you will see the name of the tables from which data will be deleted after archiving.

Now if we want to check what are the tables and these tables are involved in which click on radio button Object for Tables and put the table name say JEST, on the bottom window you will get the number of object in which this table is used. Select it and press Show Tables Button you will get the name of the tables involve in this object.

Let’s go ahead with the data archiving.

Now we need to configure the system. Now click on the WRITE option. You will get the following screen.  

Create & Maintain variant ZTEST and put suitable conditions as per requirement of archiving strategy.  

Maintain Suitable Start time and Spool parameters.

 

 Execute the session, which will create new archiving job. Logs can be seen through Jobs Button.

Archival logs will be displayed in spool request of the job.

As per our configuration Deletion job was also automatically triggered after completion of the writing action. This also can be seen through Job details.

Now data has been archived into application layer and data is removed from the database layer. Thus improving significant performance of the system and also marks completion of archiving process for Work items of the workflow.