How I applied SOLID principles and Interface patterns in AL to build an AppSource-ready BC extension

Yahya Touil — Thu, 05 Mar 2026 20:33:17 +0000

Most AL developers have written this at least once:

alcase Strategy of
    Standard: Score := CalculateStandard(...);
    Weighted: Score := CalculateWeighted(...);
end;

It works. Until a third strategy. Then a fourth. Then a partner wants their own.

Every addition means opening production code, touching the calculator, risking a regression, redeploying.

The Cash Flow Risk Engine, a BC extension that scores customers 0–100 on payment behavior and generates risk-adjusted 30/60/90-day forecasts, was built to never have this problem. Here's the core pattern:

Interface + Enum = permanently closed calculator

alinterface ICFR_RiskStrategy
{
    procedure CalculateScore(...): Decimal;
}

Each algorithm implements the interface independently. The enum binds each value to its codeunit via AL's Implementation keyword. The calculator becomes:

alStrategy := CFRSetup."Default Risk Strategy";

Score := Strategy.CalculateScore(...);

It never mentions a specific codeunit by name. A partner ships a new ML-based strategy as their own extension, zero changes to core code.

Other patterns worth knowing about in this project:

SetLoadFields on every Cust. Ledger Entry read, critical on 1M+ row tables
Query objects instead of table loops for aggregation (compiles to SQL GROUP BY)
Use temporary tables and single bulk writes; avoid commits inside processing loops.
Implement per-record error isolation so that one corrupted entry doesn’t abort an entire batch (e.g., 8,000 customers).
Maintain a telemetry facade with one codeunit, ensuring consistent custom dimensions and respect for the enable/disable flag.
Treat AppSource compliance as a design constraint from day one, not merely a submission checklist.

The probability model is interesting too, every expected amount is discounted by a collection probability derived from the risk score, so the CFO sees the realistic number alongside the raw one.

Full architecture breakdown with every design decision on my blog 👉 blog link

Source code 👉 https://github.com/yahyatouil-dev/bc-cashflow-forecasting-risk-engine

I built 7 VS Code tools for Business Central developers because the workflow pain was real

Yahya Touil — Thu, 05 Mar 2026 20:26:32 +0000

Field 19 of 43. Typed by hand. From a JSON response.

That was the moment I stopped accepting the workflow and started building something better.

Business Central development carries a lot of invisible overhead, and none of it is the hard part. It's the boilerplate, the folder setup, the JSON-to-AL mapping, the constant Postman context switching. Mechanical work that consumes focus without earning it.

I spent six months building BC HERO: a free VS Code extension with seven tools that eliminate the most painful parts of the AL development workflow.

What's inside:

🗂️ Quick Project Setup — select your AL component folders, preview the structure, generate in one click. No more five-minute directory rituals.

🧱 AL Object Creator — all 16 AL object types, guided form, auto-calculated next available ID, batch queue. Generate everything in one pass.

⚡ JSON → AL Generator — drop a JSON file (plain objects, arrays, OData { "value": [...] } all work). BC HERO infers AL types, lets you customise, outputs syntax-highlighted AL. 30 fields in about 3 minutes instead of 25.

🔌 API Explorer — full HTTP client inside VS Code. Scans your workspace for API pages and queries. Basic Auth and OAuth 2.0. I haven't opened Postman for a BC project since I built this.

🌍 Translation Assistant — visual XLIFF editor with progress bars, inline editing, validation, and batch updates. A 200-unit review cycle went from over an hour to under 20 minutes.

📊 Schema Viewer — interactive force-directed graph of your table relationships with field metadata sidebar. First thing I open in an unfamiliar codebase.

🔗 Dependency Graph — visualization of every object in your workspace, color-coded by type, with directed dependency edges.
It's free and always will be.

Full story and design rationale on my blog 👉 blog link

VS Code Marketplace 👉 https://marketplace.visualstudio.com/items?itemName=yahyatouil.bc-hero

GitHub (issues, roadmap) 👉 https://github.com/yahyatouil-dev/bc-hero-info

Forem: Yahya Touil

How I applied SOLID principles and Interface patterns in AL to build an AppSource-ready BC extension

I built 7 VS Code tools for Business Central developers because the workflow pain was real