Concept card

Analytic Applications

As of 2026-07-24T14:00:00Z

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 Analytic Applications?

Reach for Analytic Applications only when standard widgets genuinely can't express the interaction — scripting can approximate anything, but 500 lines of unstructured script is one resignation away from becoming a black box.

What it is

Analytic Applications are the layer of SAP Analytics Cloud where a story stops being a dashboard and becomes a piece of software. Standard SAC stories give business users filters, charts, and tables built from drag-and-drop widgets; an analytic application adds a scripting layer — an event-driven, JavaScript-like language — that lets a developer control exactly what happens when a user clicks a button, changes an input control, or loads a page. The result is custom interactivity: multi-step filter cascades that narrow a selection step by step, what-if scenario sweeps that let a planner nudge several variables and watch a forecast recompute, write-back workflows that push edited numbers into a planning model, or conditional visibility that hides an entire section of a page until a prerequisite is met.

Why it matters is less about the technology than about the ceiling it removes. Most SAC projects never need scripting; the standard widget library covers the vast majority of reporting and even a good share of planning use cases. But a meaningful slice of engagements hits a genuine wall: the business process requires an interaction standard widgets cannot express. Analytic Applications are the escape hatch. They are also, not coincidentally, where the more senior and better-paid work concentrates, because building and maintaining a script-driven application demands software engineering discipline that pure story building does not.

Why it matters

The 10-15% of projects that need custom scripting also carry the premium €1,200-1,400/day rate — knowing when it's genuinely needed is a pricing signal, not just a technical one.
Heavy computation belongs in Datasphere Analytic Models, not in script — script should orchestrate UX, not compute, or render performance degrades.
Modular functions under 100 lines, named for business intent, peer-reviewed and version-controlled are what keeps a scripted app maintainable after the original author leaves.

Key points

Use only when standard widgets insufficient (10-15 % of projects)
Script orchestrates UX; Datasphere computes
< 100 lines per script function, modular
Peer review + version control in git
DAC enforced; never bypass via API
ADR documents why analytic app vs standard
85-90 % of stories should remain standard widgets
Refactor cycle quarterly to avoid drift
Analytic Applications is mastered only when it changes a named buyer decision.
Start with the semantic contract and control model before demonstrating the tool.

Terms used on this page

Analytic Application: SAC story type with scripting + custom interactivity
Event handler: Script function triggered by widget event (onClick, onSelect)
Input control: Story-time parameter bound to widgets
Variable: Story-time value used across widgets and scripts
Widget API: Programmatic interface for show/hide/setData on widgets
Custom CSS: Story-level styling override (use sparingly)
ADR: Architecture Decision Record documenting design choices
Script peer review: Mandatory review process before script changes ship

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 →