Concept card

SAC Custom Widgets

As of 2026-09-27

Edited by Cédric Mary, sole editor and publication director — 27 years in the SAP ecosystem. How these pages are produced, and where automation is used.

What is SAC Custom Widgets?

SAC Custom Widgets are worth building only when a visualisation gap is real and recurring across many Stories — a self-contained Web Component a typical developer ships in 2-3 days, but each SAC release can break.

What it is

SAC Custom Widgets are the developer-grade extensibility surface that lets a consultant ship visualisations and interactive components SAC does not provide out of the box — Sankey diagrams, custom maps with non-standard projections, third-party charting libraries (Highcharts, AmCharts), animation-rich displays, or specialised input forms. They are the answer to 'the standard SAC chart doesn't do what we need' without abandoning SAC and rebuilding the application elsewhere.

What a Custom Widget actually is. Technically it is a self-contained JavaScript bundle, packaged as a Web Component, that SAC loads at runtime into Analytic Applications. The widget exposes properties (configurable in the SAC Application Designer like any standard widget), events (firable to scripting code), and methods (callable from scripting code). It receives data from SAC via a defined contract — bound to a dataset or model — and renders into its allotted canvas region. Authentication, data fetching, and lifecycle are all SAC-managed; the widget only owns its render.

The development model. A Custom Widget is developed outside SAC — in any modern JavaScript framework (vanilla JS, React via wrappers, Lit, Web Components) — and packaged as a manifest JSON + the JS bundle. It is uploaded to the SAC Custom Widget repository at the tenant level, then becomes available to every Analytic Application designer. SAP provides a Custom Widget SDK with templates and a CLI tool; the typical first widget takes a developer 2-3 days to deliver end-to-end.

Why it matters

The widget only owns rendering — authentication, data fetching, and lifecycle stay SAC-managed via a defined properties/events/methods contract.
For a one-off visualisation, an R-Visualization or a static image embed is cheaper than building and maintaining a custom widget.
A fleet of custom widgets is a real maintenance liability, since every SAC release can potentially break them — factor that into the build-vs-buy decision.

Key points

Web-Component-based — self-contained JS bundle SAC loads at runtime into Analytic Applications; framework-agnostic (vanilla JS, React via wrapper, Lit).
Three surfaces — Properties (designer-configurable), Events (firable to scripting), Methods (callable from scripting); same contract as any SAC widget.
SDK plus CLI — SAP-provided templates, build tool, local-preview server; first widget 2-3 days end-to-end for a competent JS developer.
Tenant-level deployment — uploaded once to the Custom Widget repository; available to every Analytic Application in the tenant.
Maintenance burden — every SAC release can break the widget; budget for regression testing per release.
Custom Widgets are client-side Web Components, unlike the server-side Scripting API (companion C184) — they can make their own outbound network calls from the browser, subject to CORS, which the Scripting API cannot.
The maintenance burden concentrates around SAC's quarterly release cadence, not evenly across the widget's lifetime — a widget shared across many Stories multiplies the blast radius of a single breaking change.
Run an automated smoke test against each quarterly release candidate rather than discovering a break through a user's support ticket.

Terms used on this page

Custom Widget: A SAC extensibility surface — a Web-Component-packaged JS bundle that SAC loads at runtime into Analytic Applications; lets developers ship visualisations and components SAC does not provide natively.
Web Component: A W3C standard for self-contained UI components — Custom Elements, Shadow DOM and HTML Templates; the technical foundation of SAC Custom Widgets, and the reason they execute client-side rather than server-side.
Custom Widget SDK: The SAP-provided developer kit — templates, CLI tool, local preview server, debugging utilities; the official path for building widgets that meet SAC's runtime contract.
Tenant repository: The SAC tenant-level store of uploaded Custom Widgets; once a widget is in the repository, it is available to every Analytic Application designer in the tenant.
Blast radius: The number of Stories or Analytic Applications simultaneously affected when a shared Custom Widget breaks on a SAC release upgrade — scales directly with how widely the widget has been adopted.
Release-candidate smoke test: An automated check that loads a Custom Widget in a non-production tenant against each SAC quarterly release candidate and confirms it still renders with sample data, run ahead of the release rather than discovered via a support ticket after it.
Client-side outbound call: A network request a Custom Widget's own JavaScript code makes directly from the browser (fetch/XHR, subject to CORS) — possible for Custom Widgets, not possible for the server-side Scripting API (companion C184), and a distinct security-review surface.

Sources

Full card available to members. What the full card adds: the full decision framework · the SAP vs Snowflake / Databricks / Fabric comparison · the common pitfalls and their fix · the cheat sheet · the architecture schemas · the code blocks · the facts worth quoting.

Open in the app →