Sap Sac Custom Widget

SAP Analytics Cloud Custom Widget Development

Related Skills

• sap-sac-scripting: Use when custom widgets interact with SAC scripting, widgets, or story/application APIs
• sap-sac-planning: Use when widgets participate in planning workflows or planning table interactions
• sapui5: Use for Web Component/UI5 frontend implementation patterns and browser-side quality
• sap-dependency-security: Use when adding third-party charting or build dependencies to widget projects

Table of Contents

• Overview
• AI-Assisted Generation
• Widget Discovery and Evidence Intake
• Local Custom Widget Builder
• SAP Sample Widget Lessons
• Browser Design Runtime
• CSS and Styling Compliance
• SAC Import and Packaging
• Production Audit Lessons
• Property Lifecycle
• Verification and Artifact Discipline
• Plugin Components
• Quick Start
• Community Sample Widgets
• Key Concepts
• Common Errors & Solutions
• Bundled Resources

Overview

This skill enables development of custom widgets for SAP Analytics Cloud (SAC). Custom widgets are Web Components that extend SAC stories and applications with custom visualizations, interactive elements, and specialized functionality.

When to Use This Skill

Use this skill when:

• Building custom visualizations not available in standard SAC
• Generating prompt-driven widget ideas, branded widget packages, or composite-ready widget designs
• Integrating third-party charting libraries (ECharts, D3.js, Chart.js)
• Creating interactive input components for SAC applications
• Implementing specialized data displays or KPI widgets
• Extending Analytics Designer applications with custom functionality
• Troubleshooting custom widget loading or data binding issues

Requirements:

• SAC tenant with Optimized Story Experience or Analytics Designer
• JavaScript/Web Components knowledge
• External hosting (GitHub Pages, AWS S3, Azure) OR SAC-hosted resources (QRC Q2 2023+)

AI-Assisted Generation

For prompt-driven widget creation, first classify the widget role and data-source mode, then suggest 2-3 role-aware options before generating the selected complete package. Keep AI-generated code SAC-compatible, preserve data-binding order when used, and validate/repair before import. See `references/ai-assisted-composite-generation.md` for output contracts, RAG context patterns, brand styling, and composite caveats.

Widget Discovery and Evidence Intake

Before generating a table, chart, KPI, menu, sidebar, filter, or hybrid control, select both its widget role and data-source mode. Request dimensions, measures/key figures, dates, versions, filters, and feed order only for SAC-bound widgets. For pure UI controls, collect interaction, navigation, state, method/event, accessibility, and responsive-layout requirements instead. Accept user-provided screenshots, PDFs, images, brand guides, and sanitized data as evidence, but confirm technical IDs, feed mappings, asset rights, and licenses before code generation. See `references/widget-discovery-intake.md` for the Widget Brief, evidence boundaries, and hosted-tool safeguards.

Local Custom Widget Builder

For enterprise or locked-down local environments, offer `templates/local-builder/` as the standard no-install scaffold builder. It runs as static HTML/CSS/vanilla JavaScript, avoids public CDNs and external packages, and exports SAC upload artifacts as two separate downloads: widget.json and a Resource-ZIP containing only root-level component JavaScript files. Use Node's server.mjs fallback when direct file:// use is blocked. When a user explicitly permits public-web use for a non-sensitive desktop prototype, optionally suggest the Custom Widget Builder or live demo; never send tenant material or trust its exports without local validation. See `references/local-builder-workflow.md` for builder boundaries, export rules, hosted-tool safeguards, and validation checks.

SAP Sample Widget Lessons

Before generating a chart, KPI, hierarchy, input utility, Widget Add-On, or build-based widget, consult `references/sap-sample-widget-lessons.md`. It audits every SAP sample folder and distills reusable lessons for Data Binding-first scaffolds, root-relative Resource-ZIP URLs, styling/builder panel separation, support flags, custom types, script methods/events, add-on extensions[], and build-based app caveats. Use the lessons for structure and risk checks only; do not copy SAP sample code or assets into generated packages.

Browser Design Runtime

Generated widget packages should include `templates/design-runtime/` as a no-build, file-first browser preview scaffold. Use it after generation to mock custom-widget essentials outside SAP, adjust properties/design tokens/sample data/viewports, compare multiple widgets, and export an agent iteration payload. See `references/browser-design-runtime.md` for runtime boundaries and configuration/export contracts. Use templates/local-builder/ for scaffold generation/export; use templates/design-runtime/ for preview and iteration.

CSS and Styling Compliance

Style custom widgets inside their Web Component/Shadow DOM boundary. Do not rely on SAC optimized story theme CSS, SAP shell selectors, or global story CSS to style widget internals. For generated packages, confirm the hosting mode before splitting CSS/HTML into separate files, because SAC ZIP upload packages support component JavaScript and PNG/JPG icons only. See `references/css-and-styling-compliance.md` for SAP Help-backed allowed/restricted styling rules.

SAC Import and Packaging

Decide the delivery mode before generating widget.json: SAC Resource-ZIP upload and external HTTPS hosting use different URL rules. For SAC Resource-ZIP upload, deliver widget.json separately, upload it first, and only then upload a Resource-ZIP containing root-level component JavaScript files such as widget.js, builder.js, and styling.js. Do not include widget.json, subfolders, tests, README files, CSS, or HTML in that Resource-ZIP.

For Resource-ZIP manifests, use root-relative component URLs such as "/widget.js"; for external hosting, use complete HTTPS URLs. Keep local-preview paths like "widget.js" in preview-only configs unless the target SAC flow explicitly documents that resolution mode. Model simple configurable colors as string properties with hex defaults such as "#f4f7fa"; use the Color type only after the exact SAC tenant and target panel flow accepts it. Browser preview and Node tests are useful, but they are not proof of SAC importability. For widgets with builder/styling panels, preserve focus and collapse state during text edits, keep component JS self-contained, and validate final outputs/ artifacts rather than source-only previews. When the widget is done, the final chat response must offer both completed upload artifacts for download: the widget.json manifest and the Resource-ZIP. See `references/sac-import-packaging-lessons.md` for upload sequence, ZIP content checks, final-artifact tests, builder/tree rules, final download handoff, and SAC error triage.

Production Audit Lessons