SAP Analytics Cloud: Advanced Development and Governance Patterns

By Sarah Chen, Lead SAP Architect – SAPExpert.AI Weekly Deep Research Series

Executive Summary

SAP Analytics Cloud (SAC) has matured into a fully-featured cloud analytics and planning platform. This guide presents advanced architecture and governance patterns for enterprise-scale SAC deployments. Key takeaways include:

• Hybrid data architectures – Combine live and import models to balance freshness and performance. For example, use a live connection to SAP S/4HANA for up-to-the-minute sales data, while importing historical or budget data for offline planning. This dual approach ensures real-time insight without overloading the SAC in-memory engine.
• Layered modeling – Organize models into tiers (raw data, enriched models, planning models) that can be assembled in composite models. For instance, store transactional tables (raw layer), then build a consolidated view with calculated measures (business logic layer), and finally derive a planning model with input-enabled versions. Layered models enhance re-use and maintainability.
• Analytic Application development – Leverage SAC’s Analytic Designer (scripting) to create custom dashboards and applications. Use modular JavaScript-based code with event handlers (e.g. onClick, onChange) and error-handling to build interactive interfaces. Code snippets for filtering or updating charts show how to tie UI widgets to model data.
• Robust governance and security – Define clear roles and folder structures to prevent content sprawl. Implement role-based access control (RBAC) with least privilege, teams, and data access control to secure data. Use consistent naming conventions (e.g. LXX_Model_Finance_Dept) to align objects across environments. Protect production data by segregating it from development content, and require SSO for both UI and live data sources.
• Lifecycle management – Adopt a multi-tenant landscape (Dev/Test/Prod) to separate development and production. Use SAC’s import/export features or APIs to transport content. Automated pipelines (e.g. using SAP Cloud ALM or CI/CD scripts) can manage versioning and quality gates. At a minimum, manually export models/story files from a test tenant and import into production. Ensure naming consistency so migration is smooth (help.sap.com) (help.sap.com).
• BTP integration and emerging trends – SAC integrates with SAP BTP components for extensibility and security. For example, SAP Identity Authentication (IAS) provides SAML SSO and user provisioning to SAC. SAP Datasphere (formerly Data Warehouse Cloud) can serve as a semantic layer or data mart, with SAC connected via live to Datasphere views. On the horizon are more “augmented analytics” features (auto-insights, smart predict) and DevOps-oriented tooling (governance-as-code, content repositories).

This report provides detailed guidance, code examples, and procedural steps to implement these patterns. It equips SAP architects with the know-how to build scalable, secure, and maintainable SAC solutions.

Technical Foundation

Core Concepts and Terminology

• SAP Analytics Cloud (SAC): A cloud-native SaaS platform by SAP that unifies Business Intelligence (BI), Planning, and Predictive Analytics. All artifacts (models, stories, applications) live in the SAC cloud tenant.
• Models: Define the data schema for analysis or planning. SAC models include dimensions (e.g. Time, Account, Cost Center) and measures (numeric facts). Models can be Import Data Models (data copied into SAC in-memory) or Live Data Models (where SAC queries an external source in real time). Models may also include calculated measures (formulas) and chained lookups.
• Stories and Reports: SAC’s interactive dashboards. A story is built on one or more models, and can contain charts, tables, input controls, text, and scripting. Optimized Stories support reusable components (“spaces” and composites) and improved performance.
• Analytic Applications (Apps): Custom applications created in the SAC Analytic Designer. These use JavaScript-based scripting (SAP Analytics Cloud SDK) to define UI elements and logic. Apps can respond to events (clicks, selections) and execute client-side or server-side actions (data queries, imports). Typical use cases include financial dashboards, custom controls, or wizards that Go beyond the standard story capabilities.
• Planning Models: SAC models with write-back and versioning. These allow business users to enter or adjust data (e.g. budget amounts), create scenario versions (Base, Forecast), and run planning functions or data actions. Planning models support formula calculations and data actions (set, copy, delete). Each planning model can have private versions that individuals edit, which can be promoted to a public version.
• Data Access Controls (DAC): A model-level security feature. You can define rules on a dimension (like Product or Cost Center) to restrict which members a user or team can see or change. For example, sales managers only see their region’s data. DACs provide row-level restriction in SAC models (help.sap.com).
• Fusion of Live and Import: SAC supports hybrid architectures. For example: use a Live Connection to a SAP S/4HANA or HANA source for current transactional data, while using an Import Connection for legacy data, third-party data, or planning data. SAC composites can blend them. In practice you might connect Decryptly to an OData view on S/4HANA via SAML SSO (live), and also upload a CSV of product forecasts (import). This way current and historical/planning data co-exist.
• Governance: Policies and processes controlling SAC usage. Includes user authentication (SSO, multi-factor), authorization (roles/teams), content organization (folders, spaces), data security (DAC, network), change management (Dev/Test/Prod lifecycle), and monitoring.
• Transport/Lifecycle Management: Methods to promote SAC content between systems. SAC does not have a built-in transport landscape like ABAP; instead, content is typically exported (files or APIs) from a development/test tenant and imported into production. Modern approaches may use SAP Cloud ALM or scripted pipelines to automate this process.

Architecture Overview

A robust SAC deployment involves multiple layers:

• Data Layer: This includes the sources and connections. SAC can connect live to SAP BW/4HANA, S/4HANA, HANA Cloud, Datasphere (DW Cloud), or even third-party sources via OData. For on-premise data, set up SAP Cloud Connector and the SAP Analytics Cloud Agent as a reverse proxy. For import scenarios, SAC can ingest from cloud systems (S/4HANA Cloud, SuccessFactors) and on-prem systems (SQL, ERP, Cosmos, BW) via the agent.
• Model Layer: Defines the data schema. You’ll typically have:
  • Raw models connected directly to sources (with minimal logic).
  • Business logic models that add calculated measures, hierarchies, or composite joins.
  • Planning models derived from them (with input-enabled measures and versions). Composite Models can combine these sources; for example, you can join an import model (with targets) to a live model (actuals) on common dimensions like Customer or Time.
• Presentation Layer: Stories and Analytic Apps. These are user-facing. They consume one or more models, define visualizations, and use input controls or write-backs (in planning). Stories are good for self-service dashboards, whereas Analytic Apps (Designer) support customized UI and logic (e.g. pop-ups, push-button calculations).
• Integration Layer: SAC offers REST APIs and OData APIs. Use the Web service to automate administrative tasks, data loads, or content migration. For example, the SAC Content API lets you list/create/update models, stories, users, etc. These APIs can be called from scripts or SAP BTP services (like Cloud Integration) to integrate SAC into larger landscapes.
• Identity & Security: SAC supports SAML 2.0 SSO through SAP Identity Authentication Service (IAS) or other IdPs. Best practice is to configure SAC to use the same IAS tenant as other SAP BTP applications, enabling centralized user management. Role-Based Access Control (RBAC) is defined in SAC: assign users or teams to roles (like Analyst or custom roles) to grant modeling, administration, or story privileges. Multi-factor authentication can be enforced at the IdP.
• Monitoring and Audit: SAC has dashboards for usage and performance, and audit logs for security events (logins, data changes). Integrate with SAP Enterprise Threat Detection or SIEM if needed for enterprise governance.

Prerequisites and Technical Specifications

• SAC Version: Use SAC release 2023.15 or later (June 2024+), which includes the latest APIs and composite model features. Check SAP’s Feature Highlights for new updates.

• Licensing: Ensure your tenant has licenses for the needed capabilities (e.g. Planning licenses for write-back; predictive add-on licenses for Smart Predict). Features like Live BW may require specific connectivity entitlements.

• Connectivity Setup:

  • Cloud Agent and Cloud Connector: If accessing on-premises data for imports, install the SAC agent on a local server and configure the SAP Cloud Connector. Map the on-premise system (e.g. ERP) to a virtual host and allow only the necessary resources. Assign the Cloud Agent to a Cloud Agent Group tag (for example, “SCAGrp1”) when creating the connection in SAC.
  • Network: Ensure HTTPS (443) access between SAC and your systems. For Live connections to HANA or BW, open the necessary firewall ports. For Tunnel connections, coordinate with Basis to set up a BTP Cloud Connector.
  • Front-end Requirements: Use supported browsers (Chrome, Edge, Safari). For Analytic Designer, enable JavaScript.

• Authentication (SSO):

  • Register SAC as a Service Provider in your IAS (or other IdP). Download the SAC SAML metadata and import it into IAS, and vice versa (upload IAS metadata to SAC).
  • In SAC, under Security > SAML Configurations, create an authentication configuration pointing to IAS. Ensure the Issuer and Certificate match.
  • Enable SSO for each system (Dev/Test/Prod) using the copied metadata so users can log in with corporate credentials. It’s also recommended to set up SSO on live data connections so that user permissions in the source system are enforced automatically (help.sap.com) (community.sap.com).

• Development Tools: Analytic Applications can be developed in the SAC web editor or using the SAP Analytics Cloud SDK for Visual Studio Code**
  Live connections allow SAC to query data on demand without storing it. The SAC tenant only stores metadata (queries, measures, filters) – the actual data resides in the source (community.sap.com). This is ideal when data freshness or data sovereignty is critical.

  Example Setup (S/4HANA Cloud Live):

  1. Prepare the Source: In S/4HANA Cloud, ensure the OData service for the required entity is active (e.g. API_SALES_ORDER_SRV). If using on-premise S/4HANA or BW, configure the system alias and activate the OData/analytical views.
  2. SSL and IdP Trust: Both SAC and S/4HANA must trust the same Identity Provider (e.g. SAP IAS or ADFS) (community.sap.com). Import the IdP certificate in S/4, and configure SAML trust in SAC (admin console → SAML).
  3. Create Connection in SAC: Go to Main Menu > Connections > Add Connection > Live Data Connection.
     • Select source type (e.g. SAP S/4HANA Cloud or SAP HANA).
     • Enter system details: For HANA, specify Host, Instance Number, and Database. For S/4HANA Cloud, enter the tenant URL (e.g. https://<tenant>.sapbyd.com) and the service path.
     • Authentication: Choose SAML 2.0 and select the SAML configuration you imported. This ensures seamless SSO.
     • (Optional) For direct browser connections, enable CORS (Direct) mode. This avoids using an agent and leverages the browser’s CORS support. SAP recommends Direct connections for simplicity (community.sap.com).
  4. Test Connection: Use the “Test Connection” button. If successful, SAC will list available InfoProviders (for BW) or OData entities (for S/4).
  5. Build Live Model: In SAC, create a model on top of this connection. Choose fields and filters. For example, create a live model “Live_S4_Sales” with dimensions Customer, Material, Date, and measures OrderQuantity, Revenue. Hierarchies from the source (e.g. Customer Group) flow through automatically in a live connection.

  Key Points: A live connection does not take up SAC cache. All calculations happen in the source system (so design the view carefully). Ensure the network latency is low for good performance. Users must have the necessary authorizations on the source (SAC will pass the user’s SAML identity to the backend). For multiple tenants, name connections consistently (e.g. PRD_S4_Live, QAS_S4_Live).

• Import Data Connection Setup (Offline Data)
  Import connections copy data into SAC’s ELT engine, enabling rich in-memory analytics and planning. Use this for scenarios requiring data blending, large aggregations, or planning write-back. SAC supports importing from files or databases (via the Cloud Agent for on-prem sources).

  Example Setup (CSV Import):

  1. Prepare Data: Export or generate data (e.g. sales targets or forecasts) into a CSV file. Ensure date fields are in ISO format, measures are numeric, and the file is under 100 MB (or use Data Wrangling for larger).
  2. Create Connection: Main Menu > Connections > Add Connection > Import Data Connection. Choose CSV FILE or File Server. If on-premise, set up the agent group (created earlier) to allow reading from a local folder.
  3. Upload and Create Model: In SAC go to Modeler > Create Model > Import Data. Select the connection, then either upload the file directly or browse via the agent. SAC will parse columns.
  4. Define Model Details: Assign dimensions and measures in the wizard. E.g. mark ProductID, Region as dimensions, and BudgetUSD as a measure. Set up hierarchies or formulas here if needed (e.g. Currency conversion).
  5. Schedule Refresh (Optional): After creating the model, go to the model’s Data Management panel. You can upload data schedule or enable incremental loads. For example, on a date column YearMonth, define an Incremental Load so each refresh only fetches the latest period from the source (help.sap.com).

  Best Practice: Limit the volume in import models. For very large datasets, pre-aggregate or break into multiple models. Use SAC’s Incremental Load (time-based) for ongoing refresh efficiency (help.sap.com). Remember that import connections require duplicating the data; plan capacity accordingly.

• Composite Models and Blending
  SAC allows composite models that join live and import models in a single semantic model. This enables powerful scenarios like blending actuals and forecasts. For example:

  1. In SAC Modeler, create Composite Model.
  2. Add an existing Live_S4_Sales model and an Import_Forecast model to the composite.
  3. Define join key(s) – e.g. join on CustomerID and Month. Choose join type (Left Outer is common: pull all actuals and match forecasts where available).
  4. Map measures and dimensions. For example, hide duplicate dimensions and create consolidated measures (e.g. ForecastValue = Import.ForecastAmt, ActualValue = Live.Revenue).

  Example (pseudocode) constructing a composite model:

      var compositeModelConfig = {
          models: [
            { id: "liveSalesModel", type: "live" },
            { id: "importBudgetModel", type: "import" }
          ],
          joinConditions: [
            {
              leftModel: "liveSalesModel",
              rightModel: "importBudgetModel",
              leftKey: "Date",
              rightKey: "Date",
              joinType: "INNER"  // or "LEFT"
            }
          ]
      };
  

  (Use the SAC modeler UI to set this up without coding.) The key is to align dimensionality. For example, ensure Date hierarchies are compatible or create a common Date dimension in both models. Once built, a single story can visualize actuals vs forecasts from the composite.

  Performance Tip: Live model queries can slow down dashboards if many users or complex queries. Consider using SAC Import models for aggregated summaries in those cases, or cache frequently accessed aggregated data via BW queries.

2. Layered Model Design

Organizing models into layers results in clearer, reusable architecture. We recommend a three-tier modelling approach:

Design Steps:

1. Source (Raw) Models: For each major data subject, create a base model. E.g., a SalesRaw model might import data from a sales CSV or connect live to a sales fact view. Keep this model ‘pure’: no extra formulas beyond basic currency or unit conversions.

2. Enrichment (Logic) Layer: Create a second model that references the raw one (or its data via calculation logic). In this layer, add:

   • Calculated Measures: e.g. Profit = Revenue – Cost. In SAC, use the modeler’s Formula column or the scripting API (model.addCalculatedMeasure({ ... });).
   • Hierarchy Enhancements: Define alternate hierarchies or combine hierarchies. E.g. group regions, or build a custom date hierarchy (Year > Quarter > Month).
   • Filtered Views: You may create a version of the model filtered for a region or product line for specific teams.
   • Composite Joins: If needed, integrate multiple raw models by joining on shared keys.

   Example: A company may have a raw imported model SalesRaw and another raw BudgetRaw. Build a composite SalesBudgetCombined with both, adding measures like Revenue + Budget or variance.

3. Planning Model Creation: Copy or derive the enriched model and enable planning features:

   • Go to the model settings and toggle Planning on. SAC will ask if you want “enable version management”. Say yes, which turns this into a planning model.
   • Define input-enabled measures. For example, mark Budget or ForecastVolume as An Input-Enabled Column so users can write values.
   • Set default Read/Write versions (e.g. a Public version called “Active” for final submissions, and allow personal private versions).
   • Add business logic for planning: possibly Data Actions (saved operations like “Copy Actuals to Forecast”) or value driver trees.

   Example: Start from SalesBudgetCombined, make SalesBudgetPlan.

   // Pseudocode: derive a planning model with write-back
   var planningModel = enrichedModel.copy();
   planningModel.enablePlanning();
   planningModel.setVersioning("Public & Private");
   planningModel.addDimension("Version", ["Actual", "Budget", "Forecast"]);
   planningModel.enableWriteBack("Budget");
   

   In practice, perform this in the SAC UI by choosing Create > Model from Existing Model and selecting Planning.

4. Model Privacy and Security: Decide who can see what. For live models, source system authorizations apply automatically. For import/planning models, use Model Privacy settings and/or Data Access Control. E.g., create a role “Finance_Manager” who can view all cost centers, and a role “Regional_Analyst” who only sees their region. In the modeler’s Sharing Settings, you can restrict by role or by team.

Considerations:

• Keep raw models in the Saved in Private Folder during development, then move to a “Public” folder when ready to share (help.sap.com).
• Use a consistent project tagging or namespace (e.g. prefix all related models with FIN_).
• Archive obsolete versions to avoid clutter. SAC does not auto-purge old snapshots, so periodically cleanup unused models or use the content API to debug.

3. Analytic Application Development

SAC’s Analytic Designer allows custom app development on top of SAC models and data. Advanced apps might include dynamic filters, dialogs, linked analysis, and custom layouts.

Key Techniques:

• Modular Code: Write reusable JavaScript functions. For example, a function to apply filters to any chart:

  // Apply a filter on a model and refresh a chart
  function applyFilterAndRefresh(modelId, dimension, value, chartId) {
    var model = Application.getModel(modelId);
    var chart = Application.getWidgetById(chartId);
    model.setFilter(dimension, value);
    // Asynchronously fetch data then update the chart
    model.loadData().then(function() {
      chart.setData(model.getData());
    }).catch(function(err) {
      Application.showMessage("Update failed: " + err);
    });
  }
  

• Event-Driven UI: Bind code to widget events. For instance, when a user selects a region from a dropdown:

  function onRegionSelected(event) {
    var region = event.getParameter("selectedKey");
    applyFilterAndRefresh("salesModel", "Region", region, "salesChart");
  }
  // Attach handler to dropdown widget
  Application.getWidgetById("regionDropdown").attachSelectionChange(onRegionSelected);
  

• Dynamic Visibility & Layout: Show or hide parts of the UI as needed. Example: toggle the visibility of a table:

  function onToggleView(event) {
    var showTable = event.getParameter("checked");  // from a toggle button
    var table = Application.getWidgetById("detailTable");
    table.setProperty("visible", showTable);
  }
  

• Data Actions & Calculations: Trigger planning functions from the app. Example (pseudocode):

  function runBudgetCopy() {
    try {
      var actionCall = {
        "model": "SalesPlanningModel",
        "actionName": "CopyActualsToBudget"
      };
      Application.runDataAction(actionCall);
      Application.showMessage("Budget updated successfully.");
    } catch (e) {
      Application.showMessage("Data action failed: " + e);
    }
  }
  

• Error Handling: Wrap critical calls in try-catch and report issues to the user with Application.showMessage. This prevents apps from silently failing.

Step-by-Step Example: Create a responsive selector that updates charts.

1. Create Widgets: In the App canvas, add a dropdown (e.g. Regions) and a chart (Sales by Product).
2. Define Models: Ensure the chart is bound to a model (e.g. SalesForecastModel).
3. Script: Under Code > Init(), write code to load the model initially. Under the dropdown’s onSelect event, call a function that sets a filter on the model and updates the chart (as above).
4. Performance Tip: Minimize loadData() calls. If possible, use analyzers or aggregated datasets. Avoid fetching the entire data for large models; use model.getData({dimension: {Row: ["Region", region]}}) to query specific slices.
5. Testing: Use the built-in debugger (or console logs) in the browser’s developer tools. Check for slow operations; use console.time() / console.timeEnd() to profile critical sections.

Best Practices:

• Input and Output Bindings: Use setData and getData for widgets to reflect model changes. For example, after filtering a model, use chart.setData(model.getData()).
• Version Control: Store your analytic app code in a version-controlled repository (e.g. Git). The SAC UI supports downloading and uploading app definitions.
• Avoid Hard-Coding: Use widget IDs and model IDs dynamically (e.g. from app parameters) so the code can be reused.
• Defer Heavy Lifting: If a calculation is heavy, move it to the model or data action; do not compute millions of rows in script. For instance, use a model-calculated measure or an SAC Planning script for massive data processing, then the app only changes visualization.

4. Governance and Lifecycle Management

Implementing a disciplined framework is crucial. This includes security, naming, content organization, and transportation of artifacts between environments.

• Role-Based Access Control (RBAC): Define user roles with the principle of least privilege. SAC provides standard roles (e.g. Admin, Modeler, Consumer) as a baseline (help.sap.com). Create custom roles to match your organization’s needs (e.g. FIN_Planner, HR_Analyst). Assign only the needed privileges. For example:

  • Finance_Planner – Model -> Manage, Story -> View/Comment/Build, Data Action -> Execute.
  • Sales_Viewer – Story -> View only.

  Use Teams to group users: a team called “SalesTeam” can be granted sharing permissions on sales dashboards. Teams make it easier to assign folder access and roles collectively.

• Content Organization: Standardize folder structure and naming. E.g., use folders by line of business or project. Naming Convention: Prefix all objects with a project or department code, and optionally an environment indicator. Example:

  FIN_Model_Customers_V1
  FIN_Story_RevenueTrend
  HR_App_Headcount
  

  Keep version numbers (V1, V2) and do not reuse names across tenants to avoid confusion during import. SAP recommends keeping object names identical across Dev/Test/Prod when possible (help.sap.com) (export/import will preserve the folder path).

• Lifecycle Stages: Adopt a multi-tenant landscape. A typical approach is two or three systems (Dev/Test, QA, Prod). In Dev, developers create content in their private area. After unit testing, they move it to a shared test folder (within a test tenant) for QA. Only after formal testing (including security checks) do you export it to production. Advantages of multiple systems are cited in SAP docs (help.sap.com): separate content, data safety, and performance isolation.

• Data Security: Enforce data restrictions both at the source and in SAC:

  • For live models, rely on the backend security (S/4HANA roles, BW user restrictions) by enabling SSO.
  • For import models, use Model Privacy: restrict whole model access to a group (in Model > Settings). Use Data Access Control (DAC) on dimensions to restrict specific values (help.sap.com). For example, in a CompanyCode dimension, set a DAC rule so Region Managers only see their company’s codes.
  • In Stories, set widget-level security if needed (e.g. hide a chart using widget.setProperty("visible",false) for certain users, though this is not a secure control by itself).

• Standards and Naming: Define and enforce naming templates to aid lifecycle. Include:

  • Prefix or suffix to indicate environment (e.g. _DEV, _QA, _PRD).
  • Type codes (Model, Story, App).
  • Descriptive parti (BusinessUnit, functional area).
  • Version suffix if multiple iterations (e.g. _v01).

  Example: SALES_Model_CountrySales_v02 or DATAAPP_INVentory_v1. This helps when migrating; as [12†L99-L107] notes, having identical names simplifies imports.

• Transport Mechanisms: SAC does not have a built-in transport request system. Use one of these approaches:

  1. Manual Export/Import: In the SAC UI (Files area), select the content (stories, models, applications) and choose “Export”. This generates a .zip (or multiple) with all definitions and data. Then in the target tenant, use “Import Content” to load the zip file. This is simple for one-off migrations. It preserves folder paths if similarly structured.
  2. Model/Story Export to File: For models and stories, SAC offers specialized export options. For example, in Modeler, “Export Model” creates a .sacmodel file. In a story, “Schedule Export” or “Download” yields a .twbx-like file. Import them via Modeler or Story > Import Content.
  3. APIs and Automation: For larger or repeatable processes, use SAC’s REST APIs. The Content API can programmatically retrieve content. For example:

     GET   /sap/fpa/odata/v1/ContentList?$filter=Title eq 'SALES_Story_RevenueTrend'
     

     retrieves the story’s ID, which you can use with /Download to get the binary content. A pseudo-script might be:

     // Pseudocode for scripted export
     var token = getRecursiveAuthToken();
     var storyId = fetch("GET /api/v1/content?$filter=Title eq 'MyStory'", token);
     fetch("GET /api/v1/content/" + storyId + "/download", token);
     

     Then import on the next tenant via /import. (Remember to do this in your CI/CD toolchain outside of SAC UI.)
  4. SAP Cloud ALM / Solution Manager: SAP Cloud ALM has connectors to SAC that can orchestrate content promotion. For example, use a deployment plan to import a content snapshot from one tenant to another. This is still maturing, but can provide audit trails in ALM.

• Example Stage Process:

  • Development: Build in “My Files” or project folder on Dev tenant.
  • Testing: Copy final content to a “Staging” folder in a QA tenant or a designated project space for UAT. Run integration tests and involve business reviewers.
  • Production Release: Use the transport mechanism to move content. After import, verify in Prod: fix any data source connections (often you must re-point connections if, for instance, the Production S/4 system has a different name than Dev). Assign roles/teams for production users.

• Audit and Monitoring: Enable Usage Analytics in the SAC Admin to track which stories/models are used or idle. Periodically review logs (e.g. who exported what, who changed roles). This governance ensures compliance (especially for sensitive data).

• Governance-as-Code (Emerging): Advanced teams increasingly treat SAC content like software code. They keep model/story definitions in Git repositories. For example, the Analytic Designer apps (scripts) can be exported to .js files in source control. Some use Terraform or BTP CLI to provision SAC subaccounts and manage service instances. While official tools are still growing, the mindset is to script as much configuration as possible (e.g. create roles via API, not manually).

• Naming and Version Example: The following table illustrates a naming scheme and DAC rule example:

  Object	Naming Convention	Notes
  Connection (Dev)	DEV_Conn_BW	Separate by env prefix
  Model (Finance)	FIN_Model_GLActuals_v01	BusinessUnit_Type_Version
  Story (Sales)	SALES_Story_MonthlyReport	No version if one used; or _v02
  AnalyticApp	HR_App_HeadcountPln_v1	Teams-based content names
  Role	Sales_Analyst, FIN_Planner	Roles include domain and function
  DAC Rule	Table (see below)	Restrict data by Cost Center or Region

  Data Access Control Example: Suppose you have a CostCenter dimension. You can define DAC groups:

  | Role/Team    | Allowed CostCenter Values      |
  |--------------|---------------------------------|
  | FinanceTeam  | 1000, 1100, 1200, 1300          |
  | HRTeam       | 2000, 2100, 2200                |
  | SalesTeam    | 3000, 3100, 3200, 3300, 3400   |
  

  Then assign users to teams (Team:FinanceTeam, etc.). In the model, set up Data Access for dimension CostCenter so that members of FinanceTeam only query rows where CostCenter = 1000–1300 (help.sap.com).

• Transport Example (API): To illustrate automating content export via API, consider this pseudo-workflow:

  POST /api/v1/contentExportJobs