Hyper Abstraction

What if business logic never had to care about the UI system it runs in?

That is the guiding idea of the AI-Driven Development Model: one domain model, one annotation layer, many rendering targets. The developer declares what should happen — the model decides how it looks, depending on where it runs.

Core idea

Write once, render anywhere. A single CAP domain model, annotated once, materializes into whatever design language the target environment demands — SAP Fiori, SAP Sales & Service Cloud v2, Salesforce, or a custom product UI.

The foundation: intent, not pixels

Domain-Driven Design meets SAP CAP:

• Domain model — CDS: Entities, Aggregates, and Bounded Contexts via CDS namespaces.
• Intent-based rendering — CAP-based @UI.* annotations express intent (this is a list report, that is an object page, this field is a value help). This is a concept familiar from SAP Fiori elements — but here it is no longer bound to the UI5 rendering stack.

The annotation layer is the contract. The renderer is pluggable.

The enabler: headless shadcn components

The reason a single technology can hit any target design language is that the shadcn/ui layer is headless. Components sit on Base UI primitives — which own behavior, accessibility, focus, and keyboard interaction — while the look and feel is nothing but Tailwind CSS classes on top. Behavior and appearance are fully decoupled.

That decoupling flips the usual integration problem on its head:

• The old way — integrate a grab-bag of vendor Web Component libraries (one per target: UI5 for Fiori, Lightning for Salesforce, …), each with its own runtime, theming model, and lifecycle, and wrestle them into one app.
• The Hyper Abstraction way — keep one React + shadcn technology and reverse-engineer the target design language pixel-perfect with shadcn primitives and Tailwind. Only the visual skin is reproduced; the behavior, state, and data access stay identical underneath.

Look & feel only — for embedding

The goal of a reverse-engineered skin is purely visual integration — making UDINA-built functionality look native inside an existing external UX. It reproduces the target's look and feel so embedded functions are visually indistinguishable from the host application; it does not reimplement the host's runtime or business behavior.

This is the same headless foundation described on the React & shadcn/ui page — applied here as a retargeting strategy rather than a single-look product UI.

Rendering targets

SAP Fiori

Annotation-driven Fiori building blocks in the shadcn stack, or — when strict Fiori design compliance is mandated — UI5 Web Components. Same annotations either way.

SAP Sales & Service Cloud v2 — the Cloud Native Stack (CNS)

SAP Sales Cloud and Service Cloud v2 no longer support Custom Business Objects. Custom business logic instead lives side-by-side on SAP BTP, modeled in CAP, and the resulting UI is embedded via Mashup — visually indistinguishable from the native application. We call this the Cloud Native Stack (CNS) approach.

Restricted availability — request access first

The Custom Service feature has restricted availability. Before you can use it, access must be requested by opening a case in SAP Sales & Service Cloud v2 against support component CEC-CRM-PM-PF:

"Custom service has restricted availability. To request access to this feature, you must create a case with the CEC-CRM-PM-PF component."

A Custom Service is developed, implemented, and deployed outside the SAP Sales/Service Cloud v2 systems; only its metadata (entity definitions, event structures) is imported into the systems' metadata repository — which is exactly what the CAP file conversion below produces.

Preferred integration: via CAP

For Sales & Service Cloud v2, the preferred integration path is CAP — SAP provides native tooling for it. The CAP file conversion feature converts a CAP CDS model directly into the metadata JSON that the Custom Service extensibility UI expects, cutting the manual effort of hand-modeling the service:

# local CDS service
cds -2 json <service.cds>

# service deployed on SAP BTP
cds pull && cds -2 json <service.cds>

Upload the generated JSON under Extensibility → Extensibility Management → Custom Service, then validate/adjust (set the root entity, resolve namespaces). CDS annotations drive the mapping — @isRoot, @description, @readonly, @Core.Immutable, @UI.HiddenFilter, and @dataFormat: 'AMOUNT' | 'QUANTITY' (with @isCnsEntity: true) — so the same annotated domain model that renders the UI also generates the CNS service definition.

References: CAP file conversion (SAP Help) · Styling a custom frontend like Sales & Service Cloud v2 (SAP Community) · CustomServiceBasicCAPSample (GitHub)

Supported UI integrations

A Custom Service in Sales & Service Cloud v2 comes in two flavours — both driven by the CAP model:

Integration	What it is	Where the UI comes from
Entity-based	An OData V4 entity (from the CAP file conversion above) exposed as a custom service	Rendered natively by the SSCv2 UI framework — no custom frontend to build
Mashup-based	An external app embedded into the SSCv2 shell	Your own frontend — a reverse-engineered shadcn skin, embedded as an iframe or Web Component

For each custom service you define the standard UI views — Details, Quick Create, Quick View, and Worklist (list view). Each generated UI gets a Routing Key (prefixed customer.ssc) so it is addressable in the SSCv2 navigation framework — including navigation from a mashup into a custom-service UI view.

Limits

Per system: up to 15 entity-based and 30 mashup-based custom services. Mashups embed either as a simple iframe or as a Web Component.

Which path for Hyper Abstraction

The entity-based path is the zero-frontend route: the annotated CAP model is the UI. Reach for the mashup path when you need full visual control — that is where the headless shadcn skin reproduces the SSCv2 look and feel pixel-perfect for a seamless embed.

Salesforce — Lightning Design System 2 (LDS2)

For customers running Salesforce alongside SAP, the same annotation-driven UI is rendered in Salesforce Lightning Design System 2 (LDS2) — natively integrated, visually consistent, with the identical domain model and annotation layer underneath.

Custom product UI

The default modern, product-style look via shadcn/ui.

Flexible persistence — no lock-in

The extension owns its persistence layer, and the customer chooses:

Option	Characteristics
BTP HANA Cloud	Fully cloud-native, scalable
SAP S/4HANA on-stack / on-premise	Via Custom Business Objects — reuses the existing database at no extra cost

Both paths are first-class citizens in the architecture.

What the developer does

Write Fiori-style annotations against one CDS domain model. The model handles the rest — rendering the correct UI for the correct target system, whether that is SAP Fiori, SAP Sales & Service Cloud v2, Salesforce, or a custom web application.

Hyper Abstraction, in one line

One domain model, one annotation layer, infinite rendering targets.