Groovy, Fast Formula and BI Publisher translated into X++

Fusion extenders write Groovy triggers, Fast Formulas and BI Publisher templates against a SaaS object model with no embedded query language and no visible transaction boundary. D365 hands them a compiled, SQL-embedded language with select/while select/update_recordset, ttsbegin/ttscommit, and a RecId-keyed data model — a genuine promotion in power and a demotion in guardrails.

What you will be able to do

• Explain why moving from Fusion extensibility to X++ is a promotion in power and a demotion in guardrails, not a like-for-like syntax swap
• Translate a Groovy attribute read into the correct select, while select, update_recordset, delete_from or join form
• Own a transaction boundary explicitly with ttsbegin/ttscommit/ttsabort — something Application Composer never asked of them
• Account for DataAreaId injection and RecId surrogate keys when a Fusion business-unit or ledger-security query is ported
• Map every Fusion extension surface — Groovy trigger, DFF/EFF, Fast Formula, BPM Business Rule — to its X++ or Power Platform equivalent

Introduction

The previous chapter established the rule that governs everything you build in D365: extend, never overlay, and every extension has a named point of attachment in the AOT. This chapter is about the day job underneath that rule — the statements you actually type.

The select family: from bound attributes to embedded SQL

In Application Composer, reading a related object's data usually means navigating a view accessor or issuing a scoped REST query — there is no in-line query syntax at all:

Transactions: a boundary you now own

Application Composer never asks you where a unit of work begins or ends. You edit an object's attributes, the user (or the script) saves, and the ADF framework commits the whole object graph — or rejects it — as one operation you never had to declare.

Keys and company scoping: DataAreaId, RecId and crossCompany

Fusion secures data through business-unit assignment and data-access sets — configuration evaluated by the platform at the session layer, invisible in any individual script. D365 achieves an equivalent isolation, but as a literal, visible mechanism inside every query:

Extension surfaces, mapped

The five Fusion extensibility surfaces from chapter 1 each have a specific home in X++ once you are writing code, not just configuring an object:

Objects and types: what you actually have to learn

This is the one section of the chapter with genuinely good news, because Groovy is already object-oriented on the JVM. The vocabulary transfers with only cosmetic differences:

Where the data model surfaces

Fusion spreads its readable data model across three separate surfaces: view objects (inside Application Composer and VBCS), REST resources (for external and Power Platform integration) and OTBI subject areas (for reporting). D365 consolidates the equivalent surface into two constructs, and the difference in scope matters:

Worked translation: the same validation, twice

Consider a plausible Application Composer object: a custom Intercompany Settlement Request, with a Settlement Amount, a Requesting Business Unit and a Receiving Business Unit. The rule: the amount must be positive, and the two business units must differ.

Knowledge check

Summary

Fusion extensibility and X++ share a surprising amount of surface vocabulary — dot notation, ==, &&, object-oriented syntax — because Groovy and X++ are both C-family, JVM- or CLR-adjacent languages. What does not carry over is the execution model underneath, and that is what this chapter has been about.