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.

[suryacreatx]

I think the main reason is that the calculations are happening at different layers.

SAC-calculated measures are part of the analytical/consumption layer, whereas Datasphere Analytic Model calculations are part of the semantic modeling layer. Because of that, they don't share the exact same calculation engine or function set.

For example, SUBSTRING() being available in SAC doesn't necessarily mean the same function will be available in a Datasphere Analytic Model. Similarly, Datasphere has functions such as TO_DATE() that aren't exposed in the SAC calculation editor.

So in practice, I don't think SAP is trying to make these two function libraries completely interchangeable. The more reusable approach is usually to keep business logic that needs to be shared across reports in Datasphere and use SAC calculations mainly for presentation/analytical-specific logic.

As for future alignment, I haven't seen an official SAP statement confirming that the two function libraries will be fully aligned. It would definitely make migration easier, but I wouldn't assume function parity unless SAP documents it for a particular release.