The CML Compiler
“When evaluation becomes the constraint, build the missing runtime.”
Deterministic RCA / Revenue Cloud Evaluation via an embedded TypeScript language runtime.
What Made the Problem Difficult
Enterprise Revenue Cloud implementations rely heavily on CML evaluation for complex pricing calculations, attribute dependencies, and configuration validation. As business rules expanded across multi-product catalog structures, the standard evaluation mechanism created severe performance friction.
Core Platform Constraint
The implementation encountered a difficult round-trip evaluation issue where sending rule expressions back and forth between client interactions and platform evaluation endpoints introduced high latency, network overhead, and evaluation non-determinism across interactive quoting sessions.
- !Must evaluate CML rules deterministically across both native Salesforce LWC and external React runtimes
- !Zero compromise on rule semantic fidelity between client evaluation and server validation
- !Eliminate repeated server round-trip network hops during interactive rule and attribute selection
- !Strict compliance with Lightning Locker / Lightning Web Security (LWS) without dynamic eval()
- !Must package as a standalone, zero-dependency reusable TypeScript library deployable to LWC static resources and NPM
- !Maintain strict adherence to Revenue Cloud and RCA contracts without mutating standard platform schemas
What System Was Designed
Designed and implemented a full language compiler pipeline and deterministic runtime in TypeScript. CML source expressions are parsed into a strongly typed Abstract Syntax Tree (AST), checked against semantic validation constraints, and evaluated synchronously in-memory. The compiled runtime is packaged as a universal library that runs identically inside Salesforce LWC (via static resources) and headless React applications.
Pivotal Architectural Choices
Key Architectural Decisions
Client-Side Compiler Runtime vs. Chained Remote Server Calls
Standard evaluation models force continuous round-trips to the server for expression evaluation, causing UI lag and race conditions.
- Server-side Apex micro-evaluators
- Headless remote evaluation API
- Client-side regular expression parsing
Moving the evaluation runtime directly into client memory space eliminates round-trip latency entirely while ensuring identical evaluation semantics across LWC and React runtimes.
AST Interpreter vs. Dynamic Code Generation (eval / Function)
Compiling directly to JavaScript functions via new Function() offers maximum execution speed but is strictly forbidden by Salesforce Lightning Web Security (LWS).
- Dynamic eval() code generation
- Server-only compilation
Ensures 100% security compliance with Lightning Web Security while keeping execution overhead negligible for typical CML rule depths.
What Was Actually Built
Custom lexical scanner and recursive-descent parser producing strongly typed AST representations of CML expressions.
Semantic validation pass resolving variable bindings, operand types, and Revenue Cloud domain-specific constraints.
Deterministic evaluation engine executing with zero dynamic code injection (no eval or Function constructor) to satisfy LWS.
Cross-runtime packaging producing ESM and UMD artifacts loaded in LWC via platformResourceLoader and in React via NPM.
Comprehensive test matrix verifying algebraic identities, boundary conditions, and exact runtime parity between Salesforce and React environments.
Deliberate Architectural Compromises
Trade-offs & Mitigations
⚖Client Bundle Size vs. Server Network Round-Trips
Instantaneous, zero-network evaluation of complex configuration rules in memory.
Initial download and parsing overhead of the compiler library in browser memory.
Engineered a lean parser with minimal memory footprint (<35KB uncompressed) loaded asynchronously via static resources.
⚖Strict Grammar Subsetting vs. Unbounded Macro Recursion
Guaranteed bounded execution time with zero risk of UI-thread infinite loops.
Language grammar intentionally disallows unbounded recursive macros.
Structured declarative constraint definitions aligned with Revenue Cloud architectural best practices.
Verified Outcomes
Completely eliminated the round-trip evaluation bottleneck during interactive quoting sessions
Guaranteed 100% deterministic rule parity between native Salesforce LWC and external React surfaces
Established a reusable, version-controlled TypeScript library shared across multiple enterprise digital touchpoints
Exact benchmark latency reduction and throughput improvements: [VERIFY WITH KULDEEP]
System Schematic & Data Flow
CML expressions compiled into deterministic ASTs and evaluated across Salesforce LWC and React runtimes without network round-trips.
Text alternative for screen readers: Architecture flow: CML Source to TS Lexer & Parser via Recursive-Descent AST; TS Lexer & Parser to Semantic Validator via Type & Scope Resolution; Semantic Validator to Deterministic Engine via In-Memory Evaluation Core; Deterministic Engine to LWC & React Targets via Universal TS Library Distribution
Architectural Conclusion
“Instead of fighting the evaluation model, build the language runtime that gives the solution the determinism it needs.”
- •When platform evaluation boundaries become an operational constraint, owning the compilation pipeline unlocks unprecedented responsiveness and architectural portability.
- •Building clean, standards-compliant TypeScript runtimes allows Salesforce-native solutions to seamlessly bridge into broader enterprise digital ecosystems.