In theData Archiving Part 1 – A Tour d’Horizon of this weblog series I discussed some general techniques. No I go into details of archiving capabilities of an ABAP framework of SAP made for maintaing simple master data.
BDT Development
SAP created the Business Data Toolset framework BDT, which facilitates the development of large SAP applications and simultaneously supports configurability, divisibility, and extensibility. Since then, along with SAP Business Partner, the BDT has been used primarily in SAP industry solutions.
So if you are working with SAP Business Partner or certain industry solutions you will need detailed knowledge of the BDT - so Thorsten Franz and I decided to write the BDT together with SAP Business Partner, the locator framework together with BUS-screen framework in our book. I won't give an introduction into BDTprogramming in this blog and go right into the details of archiving.
The Misery of BDT
Before I start to discuss details of BDT programming let me give some personal statements about BDT programming. In my opinion nowadays you should avoid to develop new BDT applications. BDT is the right choice if you want to develop extensible applications or if you extend SAP applications which use the BDT. My reasons are as follows:
- BDT has a lot of overhead and much complexity.
- It is very challenging to write BDT applications so that you can reuse them in a modern, MVC-world like Web Dynpro.
- BDT is more than a GUI technology because there are standardized ways to integrate business logic like checks. But this leads to problems separating business logic from the UI.
Especially if you use BDT direct input as generic (and extensible) way to create data you will get problems because for Web Dynpro applications and in SOA scenarios BAPIs are a better solution. Using the BDT-functionality and processes in BAPIs is possible but I didn't found any good solution in SAP application. In the SAP Business Partner application some BAPIs use the global BDT-memory and even swap the data of top-includes but there doesn't seem to be neither a consistent nor simple solution to these problems.
So I suggest developing BDT-applications like it is described in Thorsten's and my book:
- Develop the central business classes and business logic like checks in separate classes.
- The BDT application uses those classes but not vice versa. If your business classes use the BDT then you will get into trouble if you want change the UI technology.
BDT Archiving
Archiving is a separate process: Usually data that will be archived won't be changed by business processes and archiving will be done by batch jobs that have no business logic or connections to other business processes. So in general you don't need to put that much effort in finding a clever software architecture for archiving - better study SAP solutions for BDT archiving.
The BDT supports data archiving in a straight forward way: As usual a set of BDT events are called by generic archiving programs. Those programs perform general task like creating and closing an archive fil, logging and so on while in the functions modules that are called by BDT you perform reading and writing of the data to be archived. So the BDT offers a generic, extensible solution for archiving the data of BDT applications that can be developed within very short time.
Therefore you have to develop an archiving object (transaction AOBJ) and add it to the customizing of the BDT application (transaction BUS0). Now BDT is able to use the infrastructure of the Archive Development Kit (ADK). Now there are selection screens for the write program BUSOBARCH that correspond to the header data of your BDT application.
There are special BDT events that are called by the archiving program BUSOBARCH:
- ARCH0 seems to obsolete.
- In ARCH1 you collect objects to be archived. It is possible to test whether a business object can be archived in this event but I recommend to do this in a preprocessing step.
- In ARCH2 you archive header data. Usually you will use the function module ARCHIVE_PUT_RECORD here.
- In ARCH3 you archive all data except the header data.
The program for deletion BUSOBARCH_DELETE uses the event ARCH4 to delete the data from the database. The program BUSOBARCH_RELOAD is used for reloading archived data and uses the BDT events:
- ARCH5 is used for testing whether reloading is possible.
- ARCH6 is used to write the data to the database.
The program for deletion BUSOBARCH_DELETE uses the event ARCH4 to delete the data from the database. The program BUSOBARCH_RELOAD is used for reloading archived data
There are further events like ARCHR for extending an archiving object dynamically. I recommend to study OSS in this case.
BDT Archiving in CRM Environment
In CRM systems archiving is different - and so is BDT archiving. This begins right from the start: there is no selection screen for your header data in the report BUSOBARCH. I suggest to search the report for the variable gv_is_crm to analyze the different behaviour of the program in CRM environment.
The objects to be archived have to written into the table CRM_JEST that contains objects together with status information. Perhaps you know its counterpart (the transparent table JEST) in the ERP system as well as the status concept for business objects. Compared to the ERP variant the CRM variant uses GUIDs.
If you develop your own archiving solution you have to create an own status schema using transaction BS12. I suggest to use the status I1100 (ready for archiving) in this case. You have to customize the status object together with the name of the archiving objects in BDT customizing (transaction BUS0).
The program BUSOBARCH will scan the transparent table CRM_JEST for objects that have to be archived. This has two consequences:
- As I already mentioned you'll have to fill the table CRM_JEST in a preprocessing step.
- The BDT event ARCH1 (collection of data to be archived) is not processed.
A simple consequence is that parallelization of BUSOBARCH using the selection screen variants is not possible.
Summary
Here are my recommendations concerning BDT archiving:
- Try to avoid BDT development. Use it only if you extend existing BDT applications or if you want to create extensible ABAP dynpro applications. If you create your own BDT applications your challenge will be to create a software architecture that allows you to change the UI to Web Dynpro and create BAPIs that can be used in SOA context.
- If you do BDT development then using BDT data archiving makes sense and is better than creating new archiving programs. The archiving solutions of the BDT are quite simple and straight forward to develop. In contrast to other BDT development you don't have to care about above mentioned problems of BDT programming.
- Study existing examples of archiving objects used by SAP standard BDT applications. So look how SAP implemented the function modules for the BDT events ARCH1, ARCH2 and so on.
- This is extremely important if you extend an existing BDT application of SAP standard. BDT archiving solutions for SAP Business Partner differ from archiving solutions of other components like INSURANCE and these are completely different compared to CRM scenarios.
