Extending SAP ILM for Custom Code

Technical Guide: Extending SAP ILM for Custom Code

When working with SAP ILM, many organizations discover that their custom developments (customer namespace apps, Z-tables, partner solutions) also contain personal or business-critical data. To stay compliant, these must be brought under ILM’s retention and destruction framework.

This guide walks through the step-by-step process of managing custom code with SAP ILM.

1. Assess the Need for ILM Extensions

Ask two key questions for each custom development:

1. Does the business object store data subject to retention? (tax, HR, GDPR, product liability)

2. Does it store mass data? (too large for the DB to hold during the full retention period)

➡ If yes to either, ILM enablement is needed. Otherwise, you may not need ILM integration

2. Options for Handling Customer-Specific Tables

During ILM analysis, several approaches are possible:

• Delete obsolete tables: Simply retire them.

• Enhance SAP ILM objects: Extend SAP standard objects using BAdIs.

• Create deletion programs: Custom reports for periodic cleanup (when no retention rules apply).

• Develop custom ILM objects: Needed when applying retention/destruction rules.

3. Converting Classical Archiving to ILM

If your development already has a classical archiving object (non-ILM-enabled):

• Review in SARA (Archive Administration).

• Enhance to become ILM-compatible, so retention rules can govern destruction.

4. Creating Custom ILM Objects (IRM_CUST)

1. Go to Transaction IRM_CUST.

2. Define the ILM object (name, description, linked tables).

3. If needed, link to a data destruction object.

4. Transport the ILM object from QA to Production after successful testing.

5. Check job logs after each run to ensure compliance.

5. Testing with ILMSIM (Rule Simulation)

Before going live:

• Use Transaction ILMSIM (or older ILM_SIM) to simulate rule evaluations.

• Select test data and run simulations to see how retention and destruction rules apply.

• Debug BAdI implementations with breakpoints if needed.

• Review simulation logs to confirm compliance

6. End-to-End Example

Imagine a custom Z-application that stores customer survey results:

• Step 1: ILM analysis identifies tables storing personal data.

• Step 2: Decision → create ILM object because retention rules (GDPR) apply.

• Step 3: In IRM_CUST, define ILM object Z_SURVEY.

• Step 4: Test destruction with ILMSIM → logs show expired data marked for deletion.

• Step 5: Move object to production → scheduled destruction runs begin.

Result: Compliance achieved with GDPR retention while keeping auditability.

7. Best Practices

• Always run in QA first before productive destruction.

• Keep audit trails of destruction jobs.

• Use legal holds where investigations or lawsuits prevent deletion.

• Document decision criteria (why ILM object was or wasn’t created).