Konzeptkarte

Benutzerdefinierte SAC-Widgets

Stand 27. September 2026

Redaktion: Cédric Mary, 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 Benutzerdefinierte SAC-Widgets?

SAC Custom Widgets lohnen sich nur, wenn eine Visualisierungslücke real ist und sich über viele Stories hinweg wiederholt — eine eigenständige Web Component liefert ein typischer Entwickler in 2-3 Tagen, aber jedes SAC-Release kann sie brechen.

Worum es geht

SAC Custom Widgets sind die Erweiterbarkeits-Oberfläche auf Entwicklerebene, mit der ein Berater Visualisierungen und interaktive Komponenten ausliefern kann, die SAC nicht von Haus aus bietet — Sankey-Diagramme, benutzerdefinierte Karten mit nicht standardmäßigen Projektionen, Charting-Bibliotheken von Drittanbietern (Highcharts, AmCharts), animationsreiche Darstellungen oder spezialisierte Eingabeformulare. Sie sind die Antwort auf 'das Standard-SAC-Diagramm kann nicht, was wir brauchen', ohne SAC aufzugeben und die Anwendung anderswo neu zu bauen.

Was ein Custom Widget tatsächlich ist. Technisch handelt es sich um ein in sich geschlossenes JavaScript-Bundle, verpackt als Web Component, das SAC zur Laufzeit in Analytic Applications lädt. Das Widget stellt Eigenschaften bereit (im SAC Application Designer konfigurierbar wie jedes Standard-Widget), Ereignisse (an Scripting-Code auslösbar) und Methoden (aus Scripting-Code aufrufbar). Es erhält Daten von SAC über einen definierten Vertrag — gebunden an ein Dataset oder Modell — und rendert in seinen zugewiesenen Bereich der Arbeitsfläche. Authentifizierung, Datenabruf und Lebenszyklus liegen vollständig bei SAC; das Widget verantwortet ausschließlich sein Rendering.

Das Entwicklungsmodell. Ein Custom Widget wird außerhalb von SAC entwickelt — in jedem modernen JavaScript-Framework (vanilla JS, React über Wrapper, Lit, Web Components) — und als Manifest-JSON + JS-Bundle verpackt. Es wird in das SAC-Custom-Widget-Repository auf Tenant-Ebene hochgeladen und steht danach jedem Analytic-Application-Designer zur Verfügung. SAP stellt ein Custom Widget SDK mit Vorlagen und einem CLI-Tool bereit; das typische erste Widget nimmt einen Entwickler 2-3 Tage End-to-End in Anspruch.

Warum es zählt

Das Widget verantwortet nur das Rendering — Authentifizierung, Datenabruf und Lebenszyklus bleiben über einen definierten Properties-/Events-/Methods-Vertrag bei SAC.
Für eine einmalige Visualisierung ist eine R-Visualization oder ein eingebettetes statisches Bild günstiger als der Bau und die Pflege eines Custom Widgets.
Eine Flotte von Custom Widgets ist eine echte Wartungsverbindlichkeit, da jedes SAC-Release sie potenziell brechen kann — berücksichtigen Sie das in der Build-vs-Buy-Entscheidung.

Kernpunkte

Web-Component-basiert — eigenständiges JS-Bundle, das SAC zur Laufzeit in Analytic Applications lädt; framework-agnostisch (Vanilla JS, React über Wrapper, Lit).
Drei Oberflächen — Properties (im Designer konfigurierbar), Events (an das Skript auslösbar), Methods (aus dem Skript aufrufbar); derselbe Vertrag wie jedes SAC-Widget.
SDK plus CLI — von SAP bereitgestellte Vorlagen, Build-Tool, lokaler Vorschauserver; erstes Widget in 2-3 Tagen End-to-End für einen kompetenten JS-Entwickler.
Bereitstellung auf Tenant-Ebene — einmal in das Custom-Widget-Repository hochgeladen; für jede Analytic Application im Tenant verfügbar.
Wartungslast — jedes SAC-Release kann das Widget kaputtmachen; Regressionstests pro Release einplanen.
Custom Widgets sind clientseitige Web Components, anders als die serverseitige Scripting-API (Begleitfiche C184) — sie können eigene ausgehende Netzwerkaufrufe aus dem Browser tätigen, vorbehaltlich CORS, was die Scripting-API nicht kann.
Die Wartungslast konzentriert sich um SACs vierteljährlichen Release-Rhythmus, nicht gleichmäßig über die Lebensdauer des Widgets — ein über viele Stories geteiltes Widget vervielfacht den Wirkungsradius einer einzigen Breaking Change.
Einen automatisierten Smoke-Test gegen jeden vierteljährlichen Release-Kandidaten ausführen, statt eine Breaking Change reaktiv über ein Nutzer-Support-Ticket zu entdecken.

Begriffe auf dieser Seite

Custom Widget: Eine Erweiterbarkeitsoberfläche von SAC — ein als Web Component verpacktes JS-Bundle, das SAC zur Laufzeit in Analytic Applications lädt; ermöglicht Entwicklern, Visualisierungen und Komponenten auszuliefern, die SAC nicht nativ bereitstellt.
Web Component: Ein W3C-Standard für eigenständige UI-Komponenten — Custom Elements, Shadow DOM und HTML Templates; das technische Fundament der SAC-Custom-Widgets und der Grund, warum sie clientseitig statt serverseitig ausgeführt werden.
Custom Widget SDK: Das von SAP bereitgestellte Entwickler-Kit — Vorlagen, CLI-Tool, lokaler Vorschauserver, Debugging-Werkzeuge; der offizielle Weg, um Widgets zu bauen, die SACs Laufzeitvertrag erfüllen.
Tenant repository: Der Speicher hochgeladener Custom Widgets auf SAC-Tenant-Ebene; sobald ein Widget im Repository ist, steht es jedem Analytic-Application-Designer im Tenant zur Verfügung.
Blast radius: Die Anzahl der Stories oder Analytic Applications, die gleichzeitig betroffen sind, wenn ein geteiltes Custom Widget bei einem SAC-Release-Upgrade kaputtgeht — skaliert direkt mit der Verbreitung des Widgets.
Release-Kandidaten-Smoke-Test: Eine automatisierte Prüfung, die ein Custom Widget in einem Nicht-Produktions-Tenant gegen jeden vierteljährlichen SAC-Release-Kandidaten lädt und bestätigt, dass es weiterhin mit Beispieldaten rendert, ausgeführt vor dem Release statt über ein Support-Ticket danach entdeckt.
Clientseitiger ausgehender Aufruf: Eine Netzwerkanfrage, die der eigene JavaScript-Code eines Custom Widgets direkt aus dem Browser tätigt (Fetch/XHR, vorbehaltlich CORS) — möglich bei Custom Widgets, nicht möglich bei der serverseitigen Scripting-API (Begleitfiche C184), und eine eigenständige Sicherheitsprüfungsfläche.

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 →

Offene SAP-Projekte

Aktuelle SAP-Analytics-Projekte und Stellen im DACH-Raum: SAP-Analytics-Projekte im DACH-Raum.