Concept card

SAC Scripting API (Analytic Application Scripting)

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 Scripting API (Analytic Application Scripting)?

SAC scripting only becomes necessary when an application needs to orchestrate widget behaviour beyond what a static Story can express — everything else is easier to govern and hand over as a Story.

What it is

The SAC Scripting API is the TypeScript-flavoured programming surface inside SAP Analytics Cloud Analytic Applications — the engine that turns SAC from a drag-and-drop Story builder into a true application platform. When a customer needs an interactive analytics application with custom navigation, conditional formatting that no Story can express, programmatic data binding, or integration with external systems, Analytic Applications scripting is the answer.

What scripting actually controls: every widget on the canvas (chart, table, dropdown, input field, image) exposes a properties API and an events API. Properties let scripting code set the widget's data binding, filters, dimensions, measures, visibility, formatting at runtime. Events fire on user actions (onClick, onResultChanged, onSelect, onInitialization) and let scripting code react. The two surfaces together let an application designer build flows that no static Story can express — e.g. a drill flow where clicking a chart populates a second chart with the selected dimension as a filter, then conditionally enables a forecast widget if the data crosses a threshold.

The scripting language is a SAC-flavoured TypeScript subset. It runs server-side at runtime (not in the browser); it has access to SAC's data model (models, dimensions, measures, hierarchies, filters), the canvas widget collection, and SAC services like Planning, Smart Predict, R-Visualization. It does not have arbitrary REST-call capability — for that, integrate via OData connections or BTP iFrame integrations.

Why it matters

Scripting runs server-side, not in the browser, and has no arbitrary REST-call capability — external integration still requires OData connections or BTP iFrames.
Properties and events APIs on every widget let one chart's click populate a second chart and conditionally enable a forecast widget — the classic drill-flow pattern.
Over-using scripting produces applications only a developer can maintain, which defeats the point of handing them to a citizen analyst.

Key points

Two surfaces — Properties API (set widget data binding, filters, visibility, formatting at runtime) and Events API (react to user actions: onClick, onResultChanged, onSelect, onInitialization).
TypeScript subset — runs server-side; access to SAC data model, widget collection, Planning service, Smart Predict, R-Visualization.
No arbitrary REST — for external integration use OData connections or BTP iFrame patterns.
When Story to Analytic Application: when interactions must orchestrate beyond static drill, filter or link — e.g. conditional widget activation, programmatic dimension switching, multi-step navigation flows.
Over-use risk — scripting-heavy applications are developer concerns; produce unmaintainable artefacts if a Story would have done the job.
onResultChanged reacts to a widget's data changing for reasons outside the current script's control; it is the wrong tool for propagating a change the same script just caused, which belongs in the causing handler instead.
AI and agent integrations (Joule, AI Core, MCP) are never called directly from a script — they sit behind a BTP service (CAP or Integration Suite) exposed back to the application as an OData connection.
First-build economics: a competent developer typically ships a first working drill-flow in under a day, but debugging an unintended cross-widget event cycle can cost more time than the original build.

Terms used on this page

Analytic Application: SAC's developer-grade application surface; canvas with widgets, scripting API, lifecycle events; the answer when a Story is not enough.
Scripting API: The TypeScript-flavoured programming surface inside Analytic Applications; exposes widget properties and events; runs server-side at runtime.
Widget collection: The set of all widgets on the canvas; iterable from script; each widget addressable by name; the basis of programmatic widget manipulation.
onResultChanged: The event that fires when a widget's underlying data result is recomputed (e.g. after a filter change); the canonical place to react to externally-caused changes, not to propagate a change the same script just made.
onClick: The event that fires on a direct user interaction with a widget; the correct place to set every dependent widget's state in one handler when the script itself is the cause of the change.
Properties API: The half of the Scripting API's contract that lets code read and set a widget's configuration at runtime — data binding, filters, dimensions, measures, visibility, formatting — as opposed to reacting to events.
Event cycle (anti-pattern): An unintended chain where two or more widgets' event handlers repeatedly re-trigger each other, multiplying server round-trips because the Scripting API executes server-side; the fix is consolidating the causing logic into a single handler.

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 →

Guides that answer with this page

These guides cite this page as one of the sources their answer rests on.

SAP Analytics Cloud Stories: A Delivery Guide