Concept card

SAC Scripting API (Analytic Application Scripting)

As of 2026-07-23

Edited by Cédric-Olivier Mâry, 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.

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 → Analytic Application: when interactions must orchestrate beyond static drill / filter / 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.
SAC Scripting API (Analytic Application Scripting) is mastered only when it changes a named buyer decision.
Start with the semantic contract and control model before demonstrating the tool.
Use current SAP, analyst, study, KG, and news signals as evidence, not decoration.
Separate verified facts from directional trends and modeled assumptions.
Define owner, metric, threshold, support path, and rollback before scaling.

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 chain dependent widget updates.
Decision owner: The accountable person who accepts the trade-off and funds the next action.
Semantic contract: The shared definition of business terms, metrics, entities, and access rules used by tools and teams.
Control plane: The layer that applies policy, access, lineage, monitoring, and escalation across the operating model.
Evidence grade: A label that separates verified fact, directional signal, modeled assumption, and field observation.

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.

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