In 2004, a financial company archived all its data from August 1996 and earlier using the Archive Development Kit (ADK)-based archiving process, a component of the overall SAP NetWeaver BI support for archiving and information life cycle management.

This is phase 1 of the archiving process. In this phase, the company created the archive process object, which in turn created the archiving object for ADK-based archiving. In phase 2 you perform the actual archiving by removing the data from the database (InfoCube or DataStore object [DSO]) and send it to the ADK file structure.

Unfortunately, five years later an emergency occurs and Alex the auditor needs to review data from February 1996. Now you must perform phase 3 of the archiving process, in which you retrieve the data by bringing it back from the ADK file structure so you can review it and report on it.

I’ll describe phases 2 and 3, showing you how to archive the data and then recover it for a hypothetical emergency need. Figure 1 shows the pre-August 1996 data that the company archived in 2004 that I use in my example. It is from an SAP NetWeaver BI InfoCube named T_SDDEMO2, which I access using transaction LISTCUBE.

Note
To understand more about phase 1, refer to my article, "Archiving Process, Phase 1: Setting Up Your System."

 

Figure 1

The LISTCUBE output showing the data you want to archive

Phase 2: Archiving

Process chains are the best way to integrate archiving into your information life cycle strategy for SAP NetWeaver BI. Using process chains, the same people who set up the data load can implement the archiving strategy.

Figure 2 shows the end result process chain that you use to execute ADK-based archiving. It is a simple chain with a Start and two Archive Data from an InfoProvider process steps. The secret is in the variants used for the archive steps used to make this chain.

Figure 2

The process chain used to archive the data from InfoCube T_SDDEMO2

Figure 3

Write the data to the archive

Based on the 143 months entry in the Relative section and the date this chain was displayed, the system dynamically calculates the = month (07.1996 in this case) each time the system executes the process chain. These are the records that the system archives during this process chain run. You could place additional non-time-based restrictions on which data to archive using the Further Restrictions tab (Figure 4). The Division option appears here because of the setting made when I created the archiving process in phase 1.

Figure 4

Optional further restrictions

Figure 5

Archive process variant to delete the data from the InfoCube

You should test a reload and be sure that it works before adding this delete process step. This delete variant only deletes because of the settings Continue Open Archiving Request(s) and the fact that I set it to go to the deletion phase (70).

Figure 6

The data has been both written to the archive and deleted from the InfoCube

I want make sure that the data does not exist in the InfoCube, so I look at transaction T_SDDEMO2 again (Figure 7). Transaction T_SDDEMO2 shows no records for before August 1996.

Figure 7

Transaction T_SDDEMO2 showing no records for July 1996 and prior

As I mentioned in part 1, this process chain performed both the write and delete phases of the normal ADK archive process. You can see this by accessing the ADK transaction SARA for the archiving object build as a part of the archiving process object (Figure 8). If you click the Management tab in Figure 8, it brings up the screen shown in Figure 9, which shows that the ADK archiving was executed by process chains.

Figure 8

Click the Management tab

Figure 9

ADK archiving executed via process chains

In addition to process chains and transaction SARA, after you’ve created the archiving process object (shown in part 1) you can access archiving from a new tab in the manage context menu of an InfoCube or DSO in transaction RSA1. You can access the archive request and see its status by clicking on the lock icon. From here you can also invalidate the archive request, allowing you to archive the same data set again. My successful request 3.012 and my failed and invalidated one 3.011 are shown in Figure 10. Click the Archiving Request…button at the bottom of the screen to execute an archive run without a chain or transaction SARA. You can also see a link to transaction SARA with the ADK Archive Admin. button.

Figure 10

The new Archiving tab in the manage dialog of an InfoCube

Phase 3: Retrieval

Now that you have stored the data in an archive file and deleted it from the InfoCube, you can move on to the future. Five years from now, Alex the auditor wants to review the data from February 1996. You need to access the archive and bring the data back to an InfoCube for BEx access for the auditor.

Figure 11 shows the big picture of what you need to do. First create an InfoCube as a copy of the production data InfoCube from which you archived. In this case, I called it a restore InfoCube. Then create a transformation (because the fields are the same, SAP proposes a perfect mapping) from the production data to your restore InfoCube. Next you need to create a MultiProvider to link both InfoCubes, for easier BEx access, to the archived and newer data sets. These steps are all straightforward and require basic SAP NetWeaver BI back-end skills.

Figure 11

Recover the archive data using ADK, a restore InfoCube, and a MultiProvider

The next step is the tricky part. Create a data transfer process (DTP) with a special setting to move the data from the archive of the production InfoCube via the transformation to the restore InfoCube (Figure 12). You would not know this setting was there if you did not know how to find it. By setting the DTP into full mode, you can choose the Archive (Full Extraction Only) radio button, driving the DTP to access the source InfoCube’s archive, not the InfoCube itself. In addition, you can use the Filter button to select the exact data that Alex the auditor wanted to retrieve from the archive. The system automatically accesses any archive files that have the data you select during the execution of the DTP.

Figure 12

The special features of a DTP in full extraction mode

After you execute the DTP, you can prove success. Go back to the LISTCUBE transaction, but this time for the restore InfoCube (SDEMARCH), as shown in Figure 13. It shows that the only data is from February 1996 (199602), which is just what you filtered in the DTP.

Figure 13

LISTCUBE on the restore InfoCube

Ned Falk

Ned Falk is a senior education consultant at SAP. In prior positions, he implemented many ERP solutions, including SAP R/3. While at SAP, he initially focused on logistics. Now he focuses on SAP HANA, SAP BW (formerly SAP NetWeaver BW), SAP CRM, and the integration of SAP BW and SAP BusinessObjects tools. You can meet him in person when he teaches SAP HANA, SAP BW, or SAP CRM classes from the Atlanta SAP office, or in a virtual training class over the web. If you need an SAP education plan for SAP HANA, SAP BW, BusinessObjects, or SAP CRM, you may contact Ned via email.

You may contact the author at ned.falk@sap.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.