When migrating mod-finance-storage from a version < 7.0.0 to a version >= 7.0.0 this migration script is executed:
It directly accesses a mod_orders_storage database table.
This illegal cross-module database access fails because mod-finance-storage doesn't have any permissions for mod_orders_storage tables.
The FOLIO architecture mandates that cross-module communication goes through HTTP APIs only, not via direct database access.
SysOps that configure their installations correctly (for example GBV multi-tenant installation) use database ROLEs with access restricted to the current schema. Migrations fail when running this migration script because this illegal cross-module database access is blocked.
If one module requires that some other module exists it must list that other module's interface in its ModuleDescriptor "requires" section. mod-finance-storage's ModuleDescriptor correctly doesn't have a "requires" section. The FOLIO architecture mandates that storage backend modules do not depend on each other.
Upgrade tasks that require access to multiple back-end modules should NOT be in mod-finance-storage but in mod-finance. This ensures a clean architecture and reduces module dependencies.
Move the cross-module migration code into some business-login back-end module, for example mod-finance.
The migration code
- fetches records to update from mod-finance-storage's /finance-storage/transactions API
- fetches the matching records from mod_orders_storage's /orders-storage/purchase-orders API
- merges the information from the purchase order record into the transaction record
- writes the updated transaction record using PUT /finance-storage/transactions API