Konzeptkarte

Custom SAC Visualizations — Vier Optionen, bevor man ein Widget baut

Stand 2026-08-29

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 Custom SAC Visualizations — Vier Optionen, bevor man ein Widget baut?

Individuelle Visualisierung in SAC bedeutet vier Optionen, die sich im Aufwand um zwei Größenordnungen unterscheiden: das Standarddiagramm konfigurieren, in einer Story komponieren, skripten oder ein Web-Component-Widget bauen, das jedes SAC-Release brechen kann.

„Das Standard-SAC-Chart kann nicht, was wir brauchen" ist ein Satz, der weit häufiger zu einem Custom Widget führt, als er sollte. Individuelle Visualisierung in SAP Analytics Cloud ist keine einzelne Option, sondern vier, und sie unterscheiden sich um etwa zwei Größenordnungen bei Kosten und Wartung. Die Liste der Reihe nach abzuarbeiten, ist der Unterschied zwischen einer Zwei-Tage-Änderung und einer dauerhaften Wartungsverpflichtung.

Die vier Optionen, günstigste zuerst

1 — Das Chart, das Sie bereits haben, richtig konfiguriert. Ein überraschender Anteil der „Das kann SAC nicht"-Anfragen wird durch bedingte Formatierung, eine berechnete Dimension, eine Referenzlinie oder einen anderen Chart-Typ beantwortet, den noch niemand ausprobiert hat. Kosten: Stunden. Wartung: keine. Das ist keine Scherzoption; sie löst mehr Anfragen als die anderen drei zusammen.

2 — Komposition in einer Story oder Analytic Application. Standard-Widgets übereinanderlegen, Tabs und Container nutzen, Sichtbarkeit über ein Skript steuern. Kosten: Tage. Wartung: gering, weil alles Verwendete von SAP unterstützt wird und Upgrades übersteht.

3 — Die SAC Scripting API. Analytic-Application-Scripting gibt programmatische Kontrolle über Standard-Widgets — auf Events reagieren, Filter setzen, ändern, was angezeigt wird. Immer noch von SAP unterstützte Oberfläche, immer noch upgrade-sicher, und sie deckt die meisten „interaktiven" Anforderungen ab, die man fälschlich für visuelle hält.

Warum es zählt

Option vier ist für einen Entwickler die interessanteste und für den Kunden die teuerste — eine Kombination, der man im eigenen Denken misstrauen sollte, weil die Wartungsverpflichtung nie ausläuft.

Kernpunkte

Individuelle Visualisierung in SAC sind VIER Optionen, nicht eine, mit einer Spanne von etwa zwei Größenordnungen bei Kosten und Wartung.
Option 1 — das Standard-Chart richtig konfigurieren. Bedingte Formatierung, berechnete Dimension, Referenzlinie, ein Chart-Typ, den noch niemand ausprobiert hat. Stunden, keine Wartung.
Sie löst mehr „Das kann SAC nicht"-Anfragen als die anderen drei Optionen zusammen.
Option 2 — Komposition in einer Story oder Analytic Application: übereinandergelegte Standard-Widgets, Tabs, Container, skriptgesteuerte Sichtbarkeit. Tage, upgrade-sicher.
Option 3 — die SAC Scripting API: programmatische Kontrolle von Standard-Widgets. Deckt die meisten „interaktiven" Bedürfnisse ab, die man fälschlich für visuelle hält.
Option 4 — ein Custom Widget: eine Web Component, die SAC zur Laufzeit lädt. Sankey-Diagramme, unübliche Kartenprojektionen, Highcharts/AmCharts, Animation, spezialisierte Eingabeformulare.
Ein typischer Entwickler liefert das erste Widget in 2–3 Tagen aus — und JEDES SAC-RELEASE KANN ES BRECHEN, dauerhaft.
Das Widget besitzt nur sein Rendering: Daten, Authentifizierung und Lebenszyklus bleiben über einen definierten Vertrag SAC-verwaltet.
Bauen Sie es nur, wenn die Lücke real UND wiederkehrend über viele Stories hinweg ist — fünfzehn Dashboards sind ein Widget, eine Anfrage einer Führungskraft ist ein Screenshot.
Benennen Sie einen Owner, bevor Sie bauen. Ein Widget ohne Owner bricht beim Release nach dem Projektwechsel seines Autors.

Begriffe auf dieser Seite

Custom Widget: Ein in sich geschlossenes JavaScript-Bundle, verpackt als Web Component, das SAC zur Laufzeit in Analytic Applications lädt und Properties, Events und Methoden exponiert.
Analytic Application: Der skriptfähige SAC-Anwendungstyp, im Gegensatz zu einer Story — dort sind Custom Widgets und die Scripting API verfügbar.
SAC Scripting API: Die programmatische Oberfläche zur Steuerung von Standard-Widgets — auf Events reagieren, Filter setzen, Anzeigen ändern —, ohne SAP-unterstützten Boden zu verlassen.
Web Component: Der browser-native Komponentenstandard, als der ein Custom Widget verpackt wird, weshalb jedes moderne JS-Framework eines produzieren kann.
Widget-Repository: Der tenant-weite Speicher, in den ein verpacktes Widget hochgeladen wird, wonach jeder Analytic-Application-Designer es nutzen kann.
Datenvertrag: Die definierte Bindung, über die SAC einem Widget seine Daten übergibt. SAC behält Authentifizierung, Abruf und Lebenszyklus; das Widget rendert.
Upgrade-Verpflichtung: Die wiederkehrende Kostenposition, dass jedes SAC-Release ein Custom Widget brechen kann — der Teil der Schätzung, der fast nie budgetiert wird.
Komposition: Das benötigte Visual aus übereinandergelegten Standard-Widgets, Tabs und Containern statt aus neuem Code bauen. Option zwei, und unterbenutzt.

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 · die zitierfähigen Kennzahlen.

In der App öffnen →