Alpha Archival - LTS Release Announcement
Release Version: 25.11-21.0.0.0-lts
Service Version: 25.11.0.0.13-87bff8cf7b-lts
Release Date: November 2025
Channel: LTS (Long-Term Support)
Introduction
We’re excited to announce the official LTS release of Alpha Archival – aservice for managing jBPM process data lifecycle with automated backup, restore, and archival capabilities.
What is Alpha Archival?
Alpha Archival is a archival and recovery API service designed for jBPM-backed process data. It provides comprehensive REST APIs to safely archive, backup, restore, and manage business process data at scale.
Key Features
Advanced Process Discovery
- Filter and retrieve process instances
- Paginated queries for efficient data retrieval
- Child process relationship tracking
Intelligent Backup & Restore
- Automated batch processing (100 processes per batch)
- Audit trail with detailed operation tracking
- Bi-directional data movement between production and backup databases
- SQL script generation for manual backup scenarios
Data Deletion
- Deletion of archived processes with full audit trails
Audit Logging
- Track every backup, restore, and delete operation
- Query audit history with flexible filtering and pagination
Security
- Bearer token authentication via IDS integration
- Secure database connections with SSL/TLS support
- Separate credentials for production and backup databases
- Optional CA certificate support for enhanced security
Installation (LTS Channel)
Deploy via Helm
helm install archival-release ./alpha-archival \
--namespace <your-namespace> \
--values ./alpha-archival/values.yaml
Configuration
Update values.yaml with your environment-specific settings:
image:
repository: neutrinos.azurecr.io/alpha/alpha-archival
tag: "25.11.0.0.13-87bff8cf7b-lts"
pullPolicy: Always
env:
# Primary Database
DB_HOST: your-primary-db.postgres.database.azure.com
DB_PORT: "5432"
DB_USERNAME: pgusername
DB_PASSWORD: pgpassword
DB_SSL: "true"
BPM_DB_NAME: WORKFLOW_DB
BPM_DB_SCHEMA_NAME: public
# Backup/Archive Database (must be different from primary)
BPM_BACKUP_DB_HOST: your-backup-db.postgres.database.azure.com
BPM_BACKUP_DB_PORT: "5432"
BPM_BACKUP_DB_NAME: WORKFLOW_BACKUP_DB
BPM_BACKUP_DB_USERNAME: pgusername
BPM_BACKUP_DB_PASSWORD: pgpassword
BPM_BACKUP_DB_SSL: "true"
BPM_BACKUP_DB_SCHEMA_NAME: public
# Authentication (IDS)
IDS_URL: https://your-ids-server.com
IDS_CLIENT_ID: your-client-id
IDS_CLIENT_SECRET: your-client-secret
IDS_ENABLE: "true"
# Alpha Auth Service
ALPHA_AUTH_SERVICE_URL: https://your-domain.com/authservice
# Optional
ENABLE_SWAGGER: "true"
CRITICAL: Primary and backup databases must use different host/port/database combinations to prevent data conflicts.
Full API documentation available at: https://<your-domain>/archivalservice/api-docs
Environment Variables Reference
| Variable | Description | Required |
|---|---|---|
DB_HOST |
Primary database hostname | Yes |
DB_PORT |
Primary database port | Yes |
DB_USERNAME |
Primary database username | Yes |
DB_PASSWORD |
Primary database password | Yes |
DB_SSL |
Enable SSL for primary DB | No |
DB_CA_CERT_PATH |
Path to CA cert for primary DB | No |
DB_CA_CERT |
CA cert content for primary DB | No |
BPM_DB_NAME |
Primary BPM database name | Yes |
BPM_DB_SCHEMA_NAME |
Primary database schema | Yes |
BPM_DB_LOGGING |
Logging levels for DB queries | No |
BPM_BACKUP_DB_HOST |
Backup database hostname | Yes |
BPM_BACKUP_DB_PORT |
Backup database port | Yes |
BPM_BACKUP_DB_NAME |
Backup database name | Yes |
BPM_BACKUP_DB_USERNAME |
Backup database username | Yes |
BPM_BACKUP_DB_PASSWORD |
Backup database password | Yes |
BPM_BACKUP_DB_SSL |
Enable SSL for backup DB | No |
BPM_BACKUP_DB_CA_CERT_PATH |
Path to CA cert for backup DB | No |
BPM_BACKUP_DB_CA_CERT |
CA cert content for backup DB | No |
BPM_BACKUP_DB_SCHEMA_NAME |
Backup database schema | Yes |
BPM_BACKUP_DB_LOGGING |
Logging levels for backup DB | No |
IDS_URL |
IDS authentication server URL | Yes |
IDS_CLIENT_ID |
IDS client credentials ID | Yes |
IDS_CLIENT_SECRET |
IDS client credentials secret | Yes |
IDS_ENABLE |
Enable IDS authentication | Yes |
ALPHA_AUTH_SERVICE_URL |
Auth service base URL | Yes |
ENABLE_SWAGGER |
Enable API documentation | No |
Verification
After deployment, verify the service is running:
# Check pod status
kubectl get pods -n <your-namespace> | grep archival
# Check service health
curl https://<your-domain>/archivalservice/ping
# Expected response:
# {
# "status": "ok",
# "timestamp": "2025-11-21T16:40:18.423Z"
# }
# Access Swagger UI (if enabled)
https://<your-domain>/archivalservice/api-docs
Common Use Cases
-
Archive Completed Workflows
- Reduce primary database size by moving completed processes to archive
- Improve query performance on active workflows
-
Compliance & Auditing
- Retain historical process data for regulatory requirements
- Maintain complete audit trails of all operations
-
Data Recovery
- Restore archived processes when needed for review or reprocessing
- Recover from accidental deletions
-
Database Maintenance
- Migrate data between database instances
- Test backup/restore procedures
Important Notes
- Single Instance Only: Run only one instance of alpha-archival at a time to prevent concurrent backup/restore conflicts
- Database Separation: Primary and backup databases must be completely separate instances
- Authentication: Requires valid IDS bearer token for all API calls
- Batch Size: Default batch size is 100 processes; this is optimized for performance and reliability
Support & Documentation
- LTS Release Notes:
041 - 25.11-21.0.0.0-lts.md - API Documentation: Available at
/archivalservice/api-docs(when Swagger is enabled) - Image Repository:
neutrinos.azurecr.io/alpha/alpha-archival - Image Tag:
25.11.0.0.13-87bff8cf7b-lts
What’s Next?
Current Channel Release: Coming Soon
The alpha-archival service will be available in the Current channel via Trinity deployment in an upcoming release. Stay tuned for the Current channel announcement!
Need Help?
For questions, issues, or feedback, please contact the Alpha platform team.
Happy Archiving!