Konzeptkarte

SAC Scripting API (Analytic Application Scripting)

Stand 2026-07-23

Redaktion: Cédric-Olivier Mâry, alleiniger Redakteur und verantwortlich für die Veröffentlichung — 27 Jahre im SAP-Ökosystem. Wie diese Seiten entstehen und wo Automatisierung eingesetzt wird.

Was ist SAC Scripting API (Analytic Application Scripting)?

SAC Scripting wird erst dann notwendig, wenn eine Anwendung das Widget-Verhalten über das hinaus steuern muss, was eine statische Story ausdrücken kann — alles andere lässt sich im Rahmen der Governance einfacher steuern und als Story übergeben.

Worum es geht

Die SAC Scripting API ist die TypeScript-artige Programmierfläche innerhalb der SAP Analytics Cloud Analytic Applications — die Engine, die SAC von einem Drag-and-Drop-Story-Builder zu einer echten Anwendungsplattform macht. Wenn ein Kunde eine interaktive Analytics-Anwendung mit individueller Navigation, bedingter Formatierung, die keine Story ausdrücken kann, programmatischer Datenbindung oder Integration mit externen Systemen benötigt, ist Analytic-Applications-Scripting die Antwort.

Was Scripting tatsächlich steuert: Jedes Widget auf der Canvas (Chart, Tabelle, Dropdown, Eingabefeld, Bild) stellt eine Properties-API und eine Events-API bereit. Properties erlauben es dem Scripting-Code, zur Laufzeit die Datenbindung, Filter, Dimensionen, Kennzahlen, Sichtbarkeit und Formatierung des Widgets zu setzen. Events feuern bei Nutzeraktionen (onClick, onResultChanged, onSelect, onInitialization) und erlauben es dem Scripting-Code, zu reagieren. Die beiden Flächen zusammen erlauben es einem Anwendungsdesigner, Abläufe zu bauen, die keine statische Story ausdrücken kann — z. B. einen Drill-Flow, bei dem das Klicken auf ein Chart ein zweites Chart mit der gewählten Dimension als Filter befüllt und dann bedingt ein Forecast-Widget aktiviert, falls die Daten einen Schwellenwert überschreiten.

Warum es zählt

Scripting läuft serverseitig, nicht im Browser, und besitzt keine beliebige REST-Aufruf-Fähigkeit — externe Integration erfordert weiterhin OData-Verbindungen oder BTP-iFrames.
Properties- und Events-APIs auf jedem Widget erlauben es, dass der Klick auf ein Chart ein zweites Chart befüllt und bedingt ein Forecast-Widget aktiviert — das klassische Drill-Flow-Muster.
Übermäßiger Einsatz von Scripting erzeugt Anwendungen, die nur ein Entwickler warten kann, was den Zweck ihrer Übergabe an einen Citizen-Analysten zunichtemacht.

Kernpunkte

Zwei Flächen — Properties API (setzt Datenbindung, Filter, Sichtbarkeit, Formatierung des Widgets zur Laufzeit) und Events API (reagiert auf Nutzeraktionen: onClick, onResultChanged, onSelect, onInitialization).
TypeScript-Teilmenge — läuft serverseitig; Zugriff auf SAC-Datenmodell, Widget-Sammlung, Planning-Dienst, Smart Predict, R-Visualization.
Kein beliebiges REST — für externe Integration OData-Verbindungen oder BTP-iFrame-Muster verwenden.
Wann Story → Analytic Application: wenn Interaktionen über statisches Drill / Filter / Link hinaus orchestriert werden müssen — z. B. bedingte Widget-Aktivierung, programmatischer Dimensionswechsel, mehrstufige Navigationsabläufe.
Risiko bei Übernutzung — scripting-lastige Anwendungen sind Entwickler-Angelegenheiten; sie erzeugen unwartbare Artefakte, wenn eine Story den Zweck erfüllt hätte.
SAC Scripting API (Analytic Application Scripting) ist erst gemeistert, wenn es eine benannte Kaufentscheidung verändert.
Beginnen Sie mit dem semantischen Kontrakt und dem Kontrollmodell, bevor Sie das Tool demonstrieren.
Nutzen Sie aktuelle SAP-, Analysten-, Studien-, KG- und News-Signale als Beleg, nicht als Dekoration.
Trennen Sie verifizierte Fakten von richtungsweisenden Trends und modellierten Annahmen.
Definieren Sie Owner, Kennzahl, Schwellenwert, Support-Pfad und Rollback, bevor Sie skalieren.

Begriffe auf dieser Seite

Analytic Application: SACs entwicklergerechte Anwendungsfläche; Canvas mit Widgets, Scripting API, Lifecycle-Events; die Antwort, wenn eine Story nicht ausreicht.
Scripting API: Die TypeScript-artige Programmierfläche innerhalb von Analytic Applications; stellt Widget-Properties und -Events bereit; läuft zur Laufzeit serverseitig.
Widget-Sammlung: Die Menge aller Widgets auf der Canvas; per Skript iterierbar; jedes Widget über seinen Namen adressierbar; die Grundlage programmatischer Widget-Manipulation.
onResultChanged: Das Event, das feuert, wenn das zugrundeliegende Datenergebnis eines Widgets neu berechnet wird (z. B. nach einer Filteränderung); die kanonische Stelle, um abhängige Widget-Updates zu verketten.
Entscheidungsverantwortlicher: Die verantwortliche Person, die den Trade-off akzeptiert und die nächste Maßnahme finanziert.
Semantischer Kontrakt: Die gemeinsame Definition von Fachbegriffen, Kennzahlen, Entitäten und Zugriffsregeln, die von Tools und Teams verwendet wird.
Kontrollebene: Die Schicht, die Richtlinien, Zugriff, Lineage, Monitoring und Eskalation im gesamten Betriebsmodell durchsetzt.
Evidenzgrad: Ein Label, das verifizierte Fakten, richtungsweisende Signale, modellierte Annahmen und Feldbeobachtungen unterscheidet.

Quellen

Vollständige Karte für Mitglieder. Was die vollständige Karte ergänzt: den vollständigen Entscheidungsrahmen · den Vergleich SAP · Snowflake · Databricks · Fabric · die häufigen Fallstricke und ihre Behebung · die Kurzreferenz · die Architekturschemata · die Codeblöcke.

In der App öffnen →