EximeeBPMS 1.3.0 Release Notes

Edition: Community  |  Release date: 17.07.2026

Highlights

• Script Guard — new pluggable script security policy, enforced both at BPMN parse time and at script runtime
• Configurable OAuth2 endpoints — authorization and redirection endpoint paths are now configurable and correctly respect a custom webapp context path
• Multi-threaded External Task Client — fetched tasks are dispatched to a configurable ThreadPoolExecutor, with optional execution statistics logging
• UUID v7 is now the default identifier generation strategy
• CMMN is deprecated and will be removed in EximeeBPMS 1.4.0
• Tomcat 9 and WildFly 26 are deprecated and will be removed in EximeeBPMS 1.4.0
• Fixed OR query logic for combined candidateUser / candidateGroup task filters

New Features

Script Guard

A new ScriptSecurityPolicy restricts which scripts the engine is allowed to execute. It is enforced in two places:

• BPMN parse time — ScriptSecurityBpmnParseListener rejects forbidden scripts in script tasks, execution/task listeners, and I/O mappings while parsing a process definition, so violations surface at deployment instead of at runtime.
• Script runtime — ScriptingEnvironment and the script engine resolvers enforce the same policy before executing inline, resource-based, or external-task scripts, covering Groovy, GraalJS/Nashorn JavaScript, and JUEL expressions (via SecureJuelExpressionManager).

The policy is enabled by default and can be scoped with an allowlist of process definition keys, or disabled entirely. This feature is documented under the name Script Guard.

→ Script Guard

Configuration

eximeebpms.bpm.script-security.mode=ENFORCE
eximeebpms.bpm.script-security.allowlisted-process-definition-keys=

mode accepts ENFORCE (the default), AUDIT — record violations but let execution continue — and DISABLED. allowlisted-process-definition-keys accepts a comma-separated list of process definition keys that are exempted from policy enforcement.

Configurable OAuth2 Endpoints

The OAuth2 authorization and redirection endpoint base URIs used during OAuth2 login were previously fixed to the Spring Security defaults and could break when the webapp was deployed under a custom context path. Both endpoints are now configurable and are sanitized and applied consistently regardless of the configured webapp path.

Configuration

eximeebpms.bpm.oauth2.endpoints.authorization-base-uri=/oauth2/authorization
eximeebpms.bpm.oauth2.endpoints.redirection-base-uri=/login/oauth2/code/*

redirection-base-uri must stay aligned with spring.security.oauth2.client.registration.*.redirect-uri.

→ Spring Security OAuth2 Integration — OAuth2 Endpoints

Multi-threaded External Task Client

The Java External Task Client (clients/java/client) now dispatches fetched tasks to a dedicated ThreadPoolExecutor per topic subscription instead of handling them one at a time on a single thread, increasing throughput for workers with many concurrent short-lived external tasks. The fetch size is automatically bounded by current pool utilization to avoid over-fetching while threads are busy.

Optional execution statistics (count, min/max/average execution time per process definition and topic) can be collected and logged periodically.

ExternalTaskClient client = ExternalTaskClient.create()
    .baseUrl("http://localhost:8080/engine-rest")
    .threadPoolSize(10)
    .maxFetchedTasksMultiplier(1.5)
    .statsSchedulerEnabled(true)
    .build();

→ External Task Client — Topic Subscription

UUID v7 as Default ID Generator

The default identifier generation strategy in StrongUuidGenerator changes from UUID v1 (time-based, MAC-address-seeded) to UUID v7 (time-ordered epoch, RFC 9562). UUID v7 combines a millisecond-precision timestamp with random bits, giving monotonically ordered, globally unique identifiers — improving database index locality and INSERT throughput — without exposing a MAC address or other node metadata.

IDs generated after the upgrade use UUID v7 format. Existing rows are not affected and remain valid, standard UUID strings. UUID v1 remains available as a deprecated legacy fallback (id-generator=uuid-v1) for compatibility and will be removed in EximeeBPMS 1.4.0.

→ Id Generators

Deprecations

CMMN Support (Deprecated — Removal in 1.4.0)

Starting with 1.3.0, support for the CMMN notation is deprecated and will be removed in 1.4.0. This decision reflects marginal CMMN adoption and EximeeBPMS’s strategic focus on BPMN, Human Workflow, and business orchestration — the areas of highest value for banking and insurance customers. The change applies to both the Open Source and Enterprise editions, though not at the same time: the Enterprise Edition already removed CMMN support ahead of this schedule, in 1.2.19-ee — see CMMN Deprecation & Removal for the full per-edition timeline.

Behavior in 1.3.0: no functional changes. The engine logs a warning at startup when it detects CMMN definitions or data in the database, and when a deployment contains a .cmmn file. The CaseService Java API and the /case-* REST endpoints are marked as deprecated.

Behavior in 1.4.0 (preview): deployments containing .cmmn files will be rejected with an explicit error; engine startup will be blocked when active case instances exist, with instructions on how to proceed; historic CMMN data will remain untouched in the database.

Recommended actions:

1. Check your environment for CMMN usage — see CMMN Deprecation & Removal for detection queries.
2. Test your environment’s readiness by setting eximeebpms.bpm.cmmn-enabled=false (simulates 1.4.0 behavior).
3. If you use CMMN, finish or close active instances on 1.3.0 and plan a migration of your patterns to BPMN.
4. If you don’t use CMMN, no action is required.

Case management remains fully supported through BPMN patterns: ad-hoc subprocesses, event subprocesses, and dynamic tasks. See CMMN Deprecation & Removal for a pattern mapping table.

Legacy Application Server Support (Tomcat 9, WildFly 26)

Starting with 1.3.0, support for Tomcat 9 and WildFly 26 is deprecated and will be removed in 1.4.0, mirroring the removal already completed in the Enterprise edition. The distro/wildfly26 distribution module and the Tomcat 9 QA test runtime will be removed; the current, fully supported versions are Tomcat 10.1.50+ and WildFly 37.0.0.Final+.

Behavior in 1.3.0: no functional changes. Deploying the REST API webapp on a deprecated container logs a one-time startup warning identifying the detected server version. Building the deprecated distro/wildfly26 Maven module prints a build-time deprecation banner.

Recommended actions:

1. Check your deployment target against the Tech Stack matrix for the versions supported per release.
2. Plan a migration to Tomcat 10+ or WildFly 37+ before upgrading to 1.4.0.

Legacy UUID v1 Generator

See UUID v7 as Default ID Generator above — id-generator=uuid-v1 is deprecated and will be removed in 1.4.0.

Bug Fixes

Task Query OR for candidateUser / candidateGroup

Fixed OR query logic when filtering tasks by both candidateUser and candidateGroup simultaneously. The combined OR clause previously missed tasks matching only one of the two criteria; it now correctly returns tasks matching either condition.

Java API:

List<Task> tasks = taskService.createTaskQuery()
    .or()
      .taskCandidateUser("jdoe")
      .taskCandidateGroupIn(List.of("sales"))
    .endOr()
    .list();

REST API — POST /task:

{
  "orQueries": [
    { "candidateUser": "jdoe" },
    { "candidateGroup": "sales" }
  ]
}

Both return tasks for which jdoe is a candidate user or sales is a candidate group.

Security

This Community Edition release does not fix any additional CVEs beyond 1.2.0 — none of the dependency versions listed below were bumped in 1.3.0. Five CVE fixes already released in the Enterprise Edition track (1.2.16-ee through 1.2.19-ee) are not yet included in Community Edition; the versions below are still the vulnerable ones. Full per-notice detail is published on the Security Notices page. All five were curated into Community Edition in 1.4.0: