New in v2026.5.2

OpenIAM version 2026.5.2 continues the platform's move toward a more modular microservice architecture. The headline change is the extraction of the batch task subsystem from the ESB into its own service, with a dedicated database and independent resource budget. Customers running large numbers of batch jobs (audit-log pruning, access certification, leaver process, request reminders/escalations, business rule recalculation, etc.) should see a measurable reduction in ESB memory pressure and fewer GC spikes during heavy batch windows.

New features

Platform architecture

OE-3716 – Batch Task Manager extracted into its own microservice The batch task subsystem — schedulers, initializers, the BATCH_CONFIG/BATCH_SCHEDULE tables, and the Groovy task runners — has been pulled out of openiam-esb and into a new standalone microservice, batch-task-manager.

Why this matters:

• Batch jobs no longer share heap with the ESB. The ESB can be sized for API traffic; the batch manager can be sized (and scaled) independently for job load.
• Lower ESB memory footprint and fewer GC spikes during heavy batch windows.
• Failure isolation — a stuck or memory-heavy job no longer impacts the ESB request path.
• Resolves cache-consistency issues between the ESB and the batch runtime that previously surfaced as EntityNotFoundException: Unable to find ... BatchTaskScheduleEntity (FD 1225). Schedule entities are now owned and evicted exclusively by the batch task manager.

What's introduced:

• A new deployable: batch-task-manager (Spring Boot, packaged jar). Shipped as a new Helm chart (helmcharts/batch-task-manager/) and a new ArgoCD application (openiam-batch-task-manager).
• A new database, batchtasks, which now owns BATCH_CONFIG and BATCH_SCHEDULE. These tables are no longer maintained in the openiam DB. Flyway migrations are shipped for MySQL/MariaDB, MSSQL, Oracle, and PostgreSQL under conf/schema/<vendor>/batchtasks/2026.5.2.0/.
• An automatic, one-shot migration that copies existing BATCH_CONFIG rows from the legacy openiam DB into the new batchtasks DB the first time the batch task manager starts. No flag or operator action is required — simply starting the new service triggers the migration. Subsequent starts are no-ops.

See the instructions for upgrading and the configuration steps in RPM, and Kubernetes.

Groovy Script Management

OE-4025 – Groovy Script bulk import and export Administrators can now move Groovy scripts between environments — or back them up — without manual copy-paste. Two new operations are available in the Webconsole Groovy Manager screen and via the REST API:

• Export all scripts — downloads every Groovy script as a single .zip archive (groovy-scripts.zip). Each entry is placed at <folder>/<name>_<version>.groovy preserving the folder hierarchy.
• Export selected scripts — select individual scripts in the file-browser tree and export only those as groovy-scripts-selected.zip.
• Import from zip — upload a .zip file to bulk-create or update scripts. The importer matches existing scripts by path + name + version and updates them in-place rather than creating duplicates. Entries at the root level (no folder) and entries whose filename does not match the name_version.groovy format are skipped with a warning written to the audit log.

Both import and export operations are fully audited under the IMPORT_GROOVY_SCRIPTS and EXPORT_GROOVY_SCRIPTS audit actions respectively.

See Groovy Manager API reference for the new endpoint details.