Sunflower (R1 2025) Modules deployment changes

mod-dcb

Was introduced service_point_expiration_period table in mod-dcb for configuration of hold shelf expiration period for dcb (virtual) service points. The default value of hold shelf expiration is 10 days. If the value needs adjustment, it could be updated by the FSE team in the table or via database script.

Changes to this table will only affect newly created virtual service points and virtual service points that are reused during the creation of a new DCB transaction. Existing virtual service points will not automatically update when changes are made to the hold-shelf-expiration value in the database. Additionally, the DCB service point originally created when this module was enabled for a tenant will not be altered if the hold shelf expiration value is dynamically updated in the table.

@Gurleen Kaur1

mod-bulk-operations

The following configuration should be applied to module deployment - JAVA ARGS: XX:MetaspaceSize=384m -XX:MaxMetaspaceSize=512m -Xmx2048m,
AWS container: memory - 3072, memory (soft limit) - 2600, cpu - 1024.

These values allow to achieve stable module operating.

@Viachaslau Khandramai

mod-bulk-operations

Add env variables

Eureka

SYSTEM_USER_ENABLED=false

Okapi

SYSTEM_USER_NAME={SYSTEM_USER_NAME}

SYSTEM_USER_PASSWORD={SYSTEM_USER_PASSWORD}

Starting from Sunflower mod-bulk-operations creates and uses system user to perform marc instance updates

@Viachaslau Khandramai

mod-fqm-manager

For large consortia tenants, the value of MOD_FQM_MANAGER_QUERY_RETENTION_DURATION should be set to a larger value (~12h).

A new environment variable is used to control how long queries are persisted in the DB: MOD_FQM_MANAGER_QUERY_RETENTION_DURATION. The default for this is 3h. Notably, this is documented incorrectly (with the wrong env var name) in the README for the Sunflower release.

@Matt Weaver @Bobby Sharp