Storage, Simulated
Since Business Central 2025 release wave 1, the System Application ships the External File Storage module: one unified API (codeunit "External File Storage") that application code talks to, and pluggable connectors — Azure Blob Storage, Azure Files, SharePoint — that do the actual storage behind the interface "External File Storage Connector". Your team wants to develop and test file-based features without ever provisioning a storage account, so you will build the fourth connector: one that keeps every file in memory for the lifetime of the session. Then you will prove the plumbing works by writing a small document archive that talks exclusively to the unified API — if the archive works against your in-memory connector, it will work against Azure unchanged.
Requirements
The starter already contains the registration boilerplate: an enumextension that adds the value "In-Memory" to enum "Ext. File Storage Connector" and wires it to your connector codeunit. Keep it exactly as it is — the tests resolve your connector through Enum::"Ext. File Storage Connector"::"In-Memory".
You implement two codeunits. Pick object IDs in the 50100–50199 range and reference every object by name, never by ID — IDs are remapped at grading time.
Codeunit "In-Memory Connector"
It implements the interface "External File Storage Connector"; the starter declares all seventeen procedures with empty bodies, so the signatures are already fixed for you. The tests call these procedures both directly through an Interface "External File Storage Connector" variable and indirectly through codeunit "External File Storage" instances initialized with a "File Account" whose Connector is your enum value.
The store:
- Files live purely in memory — never in a database table. This is graded: one test warms the connector up, snapshots the session's SQL statement counter, runs create-and-read round-trips, and fails if even one SQL statement was executed. The grading transaction is also rolled back, so nothing may commit.
- The store is session-wide: a file written through one
codeunit "External File Storage"instance must be readable through a different instance initialized with the same account. Every instance of your connector must see the same store. - Every file belongs to the account it was written under: the same path under two different
AccountIdvalues is two independent files, and an account never sees another account's files.
Solve it with Pro
You’re reading the opening of the statement. Pro unlocks the whole problem:
- The full statement
- Starter code in the browser editor
- 19 grading tests, run on Business Central 28.5
- 4 hints
- The reference solution
Pro also opens all 92 Pro problems and lifts the daily limits on compile checks and submissions.
Already on Pro? Sign in