Best Practices for Configuring Archival Rule

Proper configuration of archival rules is critical for achieving optimal system performance and data integrity.

Test and Validate in Non-Production Environments

• Always create and validate new archival rules in a Development (DEV) or Test environment before deploying them to Production.

• Verify that archival logic, frequency, and target connections work as expected without impacting live data.

Define Criteria for Stable and Inactive Data

• Configure archival criteria that filter out older, inactive, or closed records that are unlikely to change.

• Avoid archiving data that may still be updated or queried frequently — doing so can lead to inconsistent parent-child relationships or record reprocessing issues.

Schedule Archival During Off-Peak Hours

• Configure the archival job execution window to run during off-peak business hours.

• This minimizes load on Siebel servers, REST interfaces, and the underlying database.

Revalidate Rules After Metadata or Repository Changes

• Any change in Siebel metadata — such as field renaming, column mapping, or Integration Object modifications — can invalidate existing archival rules.

• After such updates, review all active archival rules and ensure they reference the correct Integration Objects (IOs), fields, and relationships.

• If a rule is no longer valid, inactivate it and create a new rule reflecting the updated metadata.

Ensure Complete Hierarchy in Archival IO

• Confirm that all related child entities are properly included in the Integration Object used for the archival rule:

  • 1:M (One-to-Many) relationships must be explicitly configured to prevent orphaned child records.

  • M:M (Many-to-Many) relationships require inclusion of intersection table entities; otherwise, restoring data may require manual reconstruction of intersection records.

Maintain Referential Integrity During Restoration

• When archiving entities that are referenced by other active Siebel objects (e.g., Contact, Account, or Order), ensure restoration processes update dependent foreign keys to newly generated IDs.

• This prevents broken references and maintains referential integrity in restored data.

Understand and Account for Business Validations

• Archival follows Siebel Business Component and Business Service validations.

• Some entities may enforce rules preventing deletion of active or dependent records (e.g., an active Promotion or Service Request).

• If such validations prevent deletion:

  • Review Siebel logs for details.

  • Manually delete or deactivate the records preventing archival.

  • Future Siebel releases will introduce enhanced data recovery and exception-handling support for such cases.

Archival Process Best Practices

The archival process involves multiple sequential stages — Query, Archival, Summarization, and Delete.

Following the practices below ensures safe and efficient archival execution and cleanup.

If an Archival Job Fails

When an archival job fails, the corrective action depends on the stage where the failure occurred:

Stage	Description	Recommendation Action
Query	Data extraction from Siebel REST API.	No cleanup required — data remains unchanged.
Archival	Data transfer to target database or file system.	No cleanup required — partial data, if any, can be overwritten on re-run.
Summarization	Data summarization in the source Siebel environment.	Identify the failed Batch ID in the target system (DB or File System) and delete all archived records associated with that batch to prevent duplicate summarization.
Delete	Source record deletion after archival completion.	Search for the Batch ID in the target system and remove the related archived records. Additionally, query the Summary table in Siebel and delete the corresponding summarized records.

After cleanup, review Helidon and Siebel logs to correct the underlying issue (such as a validation error, network interruption, or timeout), then re-trigger the archival job.

Operational and Performance Recommendations

• Monitor System Health:

  Regularly check Siebel and Helidon service logs (eai.log, data-archival.log) for latency or failed job patterns.

• Use Separate Archival Targets per Environment:

  Configure distinct database schemas or file system paths for DEV, TEST, and PROD to avoid cross-environment data overlap.

• Retain Logs for Audit:

  Archive Archive History, Archival Activity Log, and Helidon system logs periodically for auditing and performance analysis.

• Monitor Network and REST Performance:

  Use the /metrics and /health endpoints in Helidon to monitor REST response times, job frequency, and error rates.

• Avoid Overlapping Rules:

  Ensure that no two archival rules overlap in frequency or criteria for the same entity set. Overlaps can cause duplicate archiving and inconsistent summaries.

• Backup Before Initial Archival Run:

  Take a full backup of Siebel database and file system before running new archival rules for the first time in Production.

• Regularly Review Expired Rules:

  Deactivate and purge expired or unused archival rules from the system to improve scheduler performance.

Recovery and Maintenance

• Validate Restoration Flow:

  Test the data retrieval and restoration workflow periodically to confirm end-to-end data recovery works as expected.

• Automate Cleanup:

  Develop scripts to automatically purge failed batch records and log entries older than a defined retention period.

• Security and Access Controls:

  Restrict access to archival configuration, logs, and target storage locations to authorized administrators.

• Version Alignment:

  Ensure the Siebel version, Helidon service version, and Java runtime version remain aligned as per Siebel 25.12 release certification.