Why do SAC Model and Datasphere Analytic Model use di...

[#1]

When creating calculated measures, I notice that some functions are available in SAP Analytics Cloud but not in SAP Datasphere Analytic Models, while other functions are available in Datasphere but not in SAC.

What is the architectural reason for maintaining different calculation engines and function sets between the two products? Are there plans to align these function libraries in the future so calculations can be more easily migrated between Datasphere and SAC?

For example:

Example 1: 

In SAC, functions such as SUBSTRING() are available in calculated measures.
In Datasphere Analytic Models, equivalent string manipulation functions may be different or unavailable.

This means the same business logic often needs to be rewritten when moving calculations between the two platforms.

Example 2: 

Datasphere provides conversion functions such as TO_DATE() for converting strings into date data types, while SAC's calculated measure engine does not expose the same function.

[aamirshahzad]

Why the two function sets differ

The two products compute calculations in different places, so each is limited to what its engine can run.

• Datasphere Analytic Models are a semantic layer on top of Datasphere views. Calculated measures there are translated into SAP HANA Cloud queries and executed in the database. The available functions are therefore the subset that can be pushed down safely and combined with aggregation behavior (exception aggregation, aggregation before or after calculation, and so on). The model is meant for numeric, aggregation-aware logic. Row-level string and date handling is expected to happen in the view layer below it, where the full HANA SQL library is available (SUBSTRING, TO_DATE, etc.).
• SAC calculated measures run in SAC's own calculation and formula engine. This is true for import models and story-level calculations, and for planning. For live connections, SAC relies on what the source supports. That engine has its own function set, including functions that only make sense in a visualization or planning context, such as lookups, rank, and time-based functions. It also has a syntax and data-type model tuned for interactive analytics, not SQL.

These engines were built by different teams, at different times, for different execution contexts. Neither is a superset of the other, which is why your two examples go in opposite directions: SUBSTRING-type logic fits better in the Datasphere view layer, and TO_DATE is a SQL-layer conversion that SAC's measure engine doesn't expose.

Plans to align them

I'm not aware of any public SAP commitment to unify the two function libraries, and I can't confirm roadmap items. The best places to check are:

• SAP Roadmap Explorer (roadmaps.sap.com), filtering on SAP Datasphere and SAP Analytics Cloud
• The SAP Customer Influence portal, where you can post or upvote an enhancement request for function parity
• An SAP support incident or your SAP account team, if this is blocking a migration

Practical way to avoid rewriting logic

1. Move string, date, and type-conversion logic into Datasphere views as calculated columns or expressions. Both Datasphere and SAC then consume the already-cleaned fields.
2. Keep only aggregation-dependent logic in the Analytic Model's calculated measures.
3. Use SAC with live connections to Datasphere Analytic Models, so measures defined once in Datasphere are reused. Keep SAC-side calculations for presentation-specific needs.
4. Maintain a small mapping table of equivalent functions (e.g. SUBSTRING vs. SAC's text functions) for the cases where you do have to port logic.