Why avoid specifying Exception Aggregations in an SAC Model?

[moshenaveh]

According to SAP's Best Practices for Performance in SAC, it is recommended to avoid using exception aggregations in Models in lieu of using restricted measures or calculation functionality within a Story. Why does specifying this in the model have a greater performance impact than doing it directly in a Story? As I understand it, the model should pre-calculate these values.

It is inconvenient to specify the calculation each time a member is used in a story. For example, if I have an Account member which I would always like to average (such as price per kilo, which it does not make sense to sum), why should I have to specify this in every story in which it is used, instead of doing this just once in the model?

I should mention that, in this example, the model is built using an on-premises universe, and we have made price per kilo available as a measure here to simplify other reporting requirements.

Thanks for your input.

[moshenaveh]

Thank you for visiting SAP Community to get answers to your questions. Since you're asking a question here for the first time, I recommend that you familiarize yourself with https://community.sap.com/resources/questions-and-answers (if you haven't already), as it provides tips for preparing questions that draw responses from our members.
Should you wish, you can revise your question by selecting Actions, then Edit.
Finally, if you're hoping to connect with readers, please consider adding a picture to your profile. Here's how you do it: https://www.youtube.com/watch?v=F5JdUbyjfMA&list=PLpQebylHrdh5s3gwy-h6RtymfDpoz3vDS. By personalizing your profile with a photo of you, you encourage readers to respond.

[SeerOfSig · Accepted solution]

The exception aggregation values are not pre-calculated and stored when applied in the model.

SAP Note https://launchpad.support.sap.com/#/notes/2892674 provides a good overview of this issue.

To be clear, exception aggregations is a supported feature and there are certainly good cases where they should be used. It is important however to understand that they can have a high performance cost and so should be used only in cases where the benefit is clearly supported.

Regards,

Peter