Application systems produce application data, think of invoices, contract information but also master data. Some of those data must not be deleted for the reasons of compliance. In this case we should consider to archive them. You’ll find a lot of information about data archiving in SDN, for example SAP NetWeaver Developer´s Guide Release: SAP NetWeaver 2004s Data Archiving Document Version 1.00 from September 2005 which will answer you most questions.
In this blog series I will deal with topics that are not mentioned in online resources and I will give some best practices for archiving project in custom development. So let’s get started by telling you my first experiences.
There different Archiving Techniques in different SAP Product: ERP, CRM, BI...
The first thing I learned was that implementation of archiving solutions for SAP ERP or CRM is not the same as developing your own archiving solution. So what are the differences? If you write AddOns to SAP standard usually you extend archiving archiving objects of SAP standard, think of FI_DOCUMNT for example which will explained later. So archiving experts usually know how to extend those objects, set up storage systems and link them to the SAP systems. Those knowledge is quite important and you’ll need it if you test your archiving solutions. Of course experience with FI archiving will help you creating your own archiving solution, but it doesn’t guarantee that you’ll make the correct decisions.
The second thing I learned is that there are different technologies for data archiving. Of course we can create our own archiving programs by copying and modifying SAP standard reports. But there are also frameworks and I recommend to use them. In some cases you don’t even have the choice and you have to use a certain framework: In SAP BI you will have to use SAP BI archiving techniques – so I recommend to read a book like http://www.sap-press.com/product.cfm?account=&product=H956 for getting an overview as well detailed knowledge.
Unfortunately from the perspective of an developer even in this concise book questions are left open. A good example is the BDT archiving technology that will be covered in detail in my next blog instalment. BDT (Business Data Toolset) is a framework that is used by SAP standard and facilitates the development of large SAP applications and simultaneously supports configurability, divisibility, and extensibility. Since then, the BDT has been used primarily in SAP industry solutions as well as SAP Business Partner application. So if you create AddOns to industry solutions it can be necessary to use BDT archiving. By the way – even in this BDT framework there are differences in ERP and CRM world but these details will be covered in the next instalment of this blog series.
CRM uses a very sophisticated BOR (Business Object Repository) related techniques which are even able to deal with very complex data models – think of CRMD_LINK.
What comes next?
Then I will show how to create archive display functions – this includes new views used within the Archive Explorer (transaction SARI) as well the API you need for writing your own display applications.
Later in this series I will cover different archiving techniques like Archiving Workbench (transaction AFX_WB) and perhaps even XML archiving. In the next entry I will introduce the ADK (Archive Development Kit) which is the cornerstone of ABAP archiving. Then I will explain the variety of jobs that have to be created and scheduled during an archiving session. Then I will explain transaction AOBJ and an archive object.
But before getting into the tricky details of arching technology it is worth to mention what questions has to be solved before starting to code. The most important thing is that doing archiving means to remove business objects from the database and creating archiving files that are stored in a storage system. Reloading archives data usually makes no sense and should be done only if objects are archived too early due to an error.
This has a severe consequence: you have to make sure that no business object that is associated to the archived object (think of a foreign key in the ABAP Dictionary or as reference as a BOR object). Otherwise you have to ensure that your dialog and batch processes don’t crash if they want to access that object. And if you keep references to archives objects within the SAP system you have to consider that access to them can take a long time – which can be fatal in batch processes.
Some Important Questions in an Archiving Project
This problem will get worse in heterogenous scenarios like ALE or processes that involve different SAP and / or non-SAP systems. Here you have to define which objects can be archive in which order – what are the pre- and postconditions if you want to archive business objects? I think those details should be considered if you design an ABAP application. If you can’t answer this question easily then there is the risk that the model is not as easy as it should be and this can a risk of the whole development project.
The following questions have to be answered, too:
Of course there are even more things to consider but from my experience there questions turned to out the most complicated.
OK, that’s all for now – and I promise the next instalment will contain the announced technical details.
