SARA vs. TJC ASC: Why the SAP transaction SARA cannot deliver full archiving automation

Author: Thierry Julien, CEO, TJC Group

You need to archive FI_DOCUMNT. You open transaction SARA, type in the object name, and press Enter. The screen loads. Now what? You are looking at a set of buttons: Write, Delete, Store, Read, and a link to Customising. Everything from this point forward is on you: which company codes, which fiscal years, which variant, when to schedule, what to do when something breaks. SARA has given you the tools. It has not given you a plan. This article explains why that distinction matters, and what full archiving automation actually looks like.

The scenario: You need to archive financial documents

Let us start where every archiving effort starts: with a real problem.

Your SAP system has been running for some years. The ACDOCA tables have grown to hundreds of millions of records. System performance is degrading to a point where you are not sure closing the fiscal year will be possible next year, and you don’t think there is budget for additional memory or a move to a larger T-shirt size. Your Basis team is telling you the database needs relief.

The answer, everyone agrees, once ageing and tiering have been identified as misleading solutions, is data archiving. You will archive FI_DOCUMNT, the archiving object for financial accounting documents. It covers tables like BKPF, BSEG, BSAD, BSAK, BSAS, and (in S/4HANA) ACDOCA. It is one of the highest-volume archiving objects in any SAP system, and it is typically one of the first candidates in any archiving programme.

So you log into SAP, type SARA in the command field, enter FI_DOCUMNT as the archiving object, and press Enter. The Archive Administration screen appears. You are ready to begin. But begin what, exactly?

What SARA actually shows you

SARA, SAP Archive Administration, is a well-structured screen. For FI_DOCUMNT, it presents you with the following:

The action buttons

Write: This is where you create and schedule the write job. The write program (FI_DOCUMNT_WRI) reads financial documents from the database and writes them into archive files. Before you can run it, you need a write variant, a set of selection criteria that tells the program which documents to select. For FI_DOCUMNT, main key selection fields are company code and fiscal year/period. You can also filter by document type, posting date, and other criteria.

Delete: Once the write job has started running and created the first archive file, the delete program (FI_DOCUMNT_DEL) removes the corresponding records from the database. This is the step that actually frees space. The delete job does not accept its own selection criteria. It operates on the archive session number created during the write phase.

Store: The store job optionally transfers the archive files to a content repository or external storage. Depending on your customising, this can run automatically after the write phase or be triggered manually.

Post-processing: The post-processing program (FI_DOCUMNT_PST) cleans up secondary index tables (BSAK, BSAS, BSIS) by removing records that were flagged during the delete phase. It should run directly after deletion.

The customising link

Through Customising, you configure object-specific settings: the logical file name for archive files, maximum file size, whether delete and store jobs run automatically or manually, and the archive scenario (delete before store, or store before delete). You also maintain some minimum residence time in order to protect data that should not be archived.

What SARA does well

Credit where it is due: SARA gives you a complete, transparent view of the archiving infrastructure for any object. You can see the programs, the customising, the logs from previous sessions, and the status of current runs. For a single archiving session on a single object, it provides everything you need to execute the process correctly.

This is genuinely useful. SARA is a reliable, well-documented interface that has served SAP customers for decades. The problem is not what SARA shows you. The problem is everything it expects you to do next, on your own, by hand, every single time.

The gap: SARA is a launchpad, not an engine

SARA shows you the programs. It gives you access to the buttons. But it provides no logic for running them safely, in sequence, at scale, and on a recurring basis. Here is where the gaps appear, and they compound rapidly as you move from archiving a single object to running an enterprise-wide archiving programme.

You must build and maintain every variant by hand

To archive FI_DOCUMNT for company code 1000, fiscal years 2015–2018, you create a write variant with those selection criteria. For company code 2000, you create another. For company code 3000, another. If you have 40 company codes and want to archive six fiscal years for each, you are looking at dozens of variants, each created, named, and maintained manually. That sounds like only a few dozen jobs, but a complete archiving programme ends up with tens of thousands of jobs. This is a non-reversible data archiving process, so a manual run is not exactly what top management is looking for, once they are aware of the process.

SAP does offer variant variables that can dynamically calculate dates, but this functionality hits a wall quickly. Financial document archiving is typically driven by fiscal period and residence time, not by calendar date. Variant variables use the current system date as their reference point, which means they cannot correctly generate the selection criteria for a delayed archiving run that should have run years ago. The variant must then be manually adapted before it can be used, a tedious, error-prone step that defeats the purpose of any scheduling you have set up.

You have no control over what happens after the write job

An archiving session consists of several jobs, and some of them (the store job and the delete job) are not known when the session starts. You don’t even know how many delete jobs should run. Their execution depends on the outcome of the write job. In SARA, you have two choices: configure these jobs to launch automatically via ADK, or schedule them manually after the write job completes.

If you choose automatic launch, you lose control over how many jobs run simultaneously. These delete jobs, running in parallel, may overwhelm the database and cause performance issues during peak business hours. If you choose manual launch, you are back to watching and waiting, checking whether the write job finished, then manually triggering the next phase. Neither option is satisfactory. What you actually need is governed execution: jobs launched according to defined rules, within defined time slots, with limits on concurrent processing. SARA does not offer this.

Sequencing across objects is entirely your responsibility

FI_DOCUMNT is rarely archived in isolation. A typical archiving programme includes MM_MATBEL (material documents), SD_VBAK (sales orders), IDOC (intermediate documents), and potentially dozens of other objects. Some of these objects, now including FI_DOCUMNT, have dependencies. Certain ILM objects must be processed in a defined sequence, where the session for object A should only start after the session for object B has completed successfully.

SARA has no mechanism for managing these dependencies. Each object is administered independently. If object B fails and you do not notice, object A will either run on stale data or fail in turn when scheduled. Coordinating the sequence across 20 or 30 objects, across multiple company codes, is a manual orchestration exercise that requires constant attention. When the archiving/ILM consultant leaves or goes on vacation, everything stops, and usually never restarts.

Error recovery is manual

Archiving sessions fail. A document is locked by another process. A batch job times out. The system restarts during a maintenance window. When this happens in SARA, the session stalls. The administrator must notice the failure (by checking logs or job status), diagnose the cause, resolve it, and manually restart the interrupted phase.

SAP has released OSS notes over the years to improve this (note 2520094 provides guidance on continuing interrupted sessions, note 2586921 warns about uncompleted previous runs), but these are informational aids, not automated recovery mechanisms. The human is still the error handler. These manual pitfalls are among the key reasons why SAP data archiving projects can fail.

There is no awareness of when archiving should or should not run

Archiving jobs consume system resources. Running a large FI_DOCUMNT write job during peak business hours will degrade response times for online users. Running it during month-end close is worse. SARA’s job scheduling is basic: you pick a start date and time. It has no concept of business calendars, maintenance windows, or blackout periods. Aligning archiving runs with these constraints is a manual coordination exercise between the archiving team, the Basis team, and the business.

Gains evaporate without recurrence

This is the most consequential gap. An initial archiving project for FI_DOCUMNT might remove six years of historical documents and following ACDOCA compression may reduce the relevant tables by 30% or more. Impressive results. But SAP databases typically grow by 15–20% per year. Without regular, recurring archiving sessions, those gains will erode within 18 months.

SARA provides no mechanism to ensure that archiving continues after the project team moves on. There is no recurrence engine, no scheduled programme of sessions, no alerting if archiving has not run for a defined period. This is why so many organisations find themselves restarting archiving projects from scratch every couple of years, a costly, frustrating cycle that TJC Group has witnessed repeatedly over more than 25 years of SAP data management engagements. Adopting the right archiving strategies from the outset, including planning for automation and recurrence, is essential to breaking this cycle.

Key takeaways

SARA is a launchpad, not an engine. It shows you the archiving programs, the customising, and the logs. It does not plan your sessions, generate your variants, sequence your objects, recover from errors, or ensure that archiving runs next month. Everything beyond pressing the buttons is your responsibility.

The real challenge is not executing one session. It is sustaining an archiving programme. A single FI_DOCUMNT run in SARA is straightforward. Running 30 objects across 40 company codes, every month, for years, without gaps or errors, is a fundamentally different problem. That problem requires automation.

Archiving gains are temporary without automated recurrence. Databases grow by 15–20% per year. An initial archiving project buys time; automated recurrence through ASC makes the reduction permanent.

If you are managing SAP data archiving through SARA alone, manually creating variants, manually scheduling jobs, manually checking logs, you are spending skilled resources on work that should be automated. TJC Group, with over 25 years of expertise in SAP data volume management, built the Archiving Sessions Cockpit to solve exactly this problem. Contact us to see what full archiving automation can look like in your landscape.