Upgrading notes for v.2026.5.2 in Kubernetes environment

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. Separating batch processing from the ESB enables independent scaling, reduces memory pressure and GC overhead, isolates failures so batch jobs can't impact API traffic, and eliminates cache-consistency errors like EntityNotFoundException for BatchTaskScheduleEntity.

Upgrade notes for v2026.5.2

Provision the new batchtasks database

Before upgrading, create a new batchtasks database/schema on your existing database server (MySQL/MariaDB, MSSQL, Oracle, or PostgreSQL). The batch task manager applies its own Flyway migrations on first start.

New configuration properties

Configure the following properties (and matching Vault secrets) in datasource.properties:

jdbc.batchtasks.url=<jdbc URL for the new batchtasks DB>
vault.secret.batchtasks.jdbc.username=<username>
vault.secret.batchtasks.jdbc.password=<password>
batchtasks.databaseSchema.name=batchtasks

Deploy the new microservice — migration runs automatically

Deploy the batch-task-manager Helm chart alongside openiam-esb. The ArgoCD application openiam-batch-task-manager is included in the conf repo and points at helmcharts/batch-task-manager.

On the first start of the new service:

1. Flyway applies the batchtasks schema (BATCH_CONFIG, BATCH_SCHEDULE).
2. Existing openiam.BATCH_CONFIG rows are copied into batchtasks.BATCH_CONFIG via JPA (so listeners, audit, and cache see the inserts the same way as any other save).
3. The migration runner short-circuits if batchtasks.BATCH_CONFIG already has rows, so subsequent starts and restarts are no-ops.

BATCH_SCHEDULE is intentionally NOT migrated — the scheduler rebuilds future runs from each task's cron expression, and historical schedule rows have no operational value after cutover.

Notes for developers maintaining custom Groovy scripts

Classes that customer Groovy scripts extend or import were moved out of org.openiam.esb.core.batch.tasks.* as part of the extraction. Any customer-customized Groovy scripts that reference the old packages will fail to compile until imports are updated.

Package moves to apply in customer Groovy scripts:

• org.openiam.esb.core.batch.tasks.implementation.AbstractActivateProcess → org.openiam.batch.manager.initializer.implementation.AbstractActivateProcess
• org.openiam.esb.core.batch.tasks.implementation.AbstractLeaverProcess → org.openiam.batch.manager.initializer.implementation.AbstractLeaverProcess
• org.openiam.esb.core.batch.tasks.AccessCertificationHelper (base class for CustomCertificationHelper) → org.openiam.batch.manager.initializer.AccessCertificationHelper
• org.openiam.esb.core.batch.tasks.TerminatedUsersReportHelper → org.openiam.common.batch.TerminatedUsersReportHelper
• org.openiam.esb.domain.BatchTaskEntity → org.openiam.batch.manager.domain.BatchTaskEntity

More broadly, the entire org.openiam.esb.core.batch.tasks.* namespace has moved to org.openiam.batch.manager.initializer.*. The batch task entity/repository/service/scheduler/MQ-listener packages have moved from org.openiam.esb.* to org.openiam.batch.manager.* (domain, repository, service, scheduler, mq, thread, annotation).

Out-of-the-box scripts shipped in conf/iamscripts/batch/ and conf/iamscripts/bpm/certification/ have already been updated to the new packages.