Creating Data Actions and Multi Actions for Optimized Performance

Data actions, multi actions, or allocations running in the background may impact the performance of other planning activities. For this reason, it's important to optimize them so that they do not impact on performance for users trying to use other planning functionality in SAP Analytics Cloud.

In this lesson, we use a series of scenarios, we will explore some of the best practice for creating and configuring data actions, multi actions, and allocations.

For the purpose of this lesson, when we refer to data actions, we also mean multi actions and allocations, unless otherwise specified.

While the Data Actions Performance Statistics and Analysis Tool helps you to analyze the duration of data actions in planning stories by model, user, and date range, the Job Monitor can be used to monitor runtime information for specific actions, including run history for all jobs you have started or, if you are an administrator, for all jobs started across the tenant. For any individual job, you also can view detailed step information including the number of records affected per step.

To avoid additional and unrequired data load, too many selections and long runtime, you can optimize performance by filtering the data on which you are running a data action.

Scenario: You have a story that is causing performance concerns when planners are copying data using the data action in the story.

In this video, we will explore how you can improve performance by linking story filters to your data action prompt.

Summary: You minimize the scope of their execution by strictly controlling the filters passed at runtime. Meaning, you work as much as possible with input controls and story filters, linking them to the parameters of your data action.

As a consequence, the data action is only executed for the filter selections and/or input controls selected in the story, resulting in fewer data sets.

Scenario: You have a planning story that includes a data action which calculates both labor costs and benefits at the same time. Labor hours, one part of the labor cost calculation, are copied from the previous year, then updated manually by the planner. Once the labor hours are updated, a data action is used to calculate labor costs and benefits, lately the planners have been raising concerns about the story performance when the data action runs.

In the first step, labor costs in the expenses plan model are calculated by taking labor hours from the expenses plan model and multiplying it by the labor rate, which is read at runtime from the HR plan model.

123
MEMBERSET [d/Date] = (BASEMEMBER([d/Date].[h/YQM], "[2025]"))
MEMBERSET [d/P00D_CostCenter] = (BASEMEMBER([d/P00D_CostCenter].[h/H1], %CostCenter%))
DATA([d/Account] = "Labor") = RESULTLOOKUP([d/Account] = "LHours") * LINK([P00M_HR_Plan], [d/Account] = "LRate", [d/Personnel_Area] = "AMER", [d/Version] = "public.PubHrPlan")

In the second step, benefits in the expenses plan model are calculated by taking labor costs from the expenses model and multiplying it by the benefit rate. This rate is entered by the planner at runtime.

123
MEMBERSET [d/Date] = (BASEMEMBER([d/Date].[h/YQM], "[2025]"))
MEMBERSET [d/P00D_CostCenter] = (BASEMEMBER([d/P00D_CostCenter].[h/H1], %CostCenter%))
DATA([d/Account] = "Benefits") = RESULTLOOKUP([d/Account] = "Labor") * %BenefitRate%

In this video, we will explore how you can improve performance by using focused execution of data actions in a planning story.

Summary: You evaluate the data action and realize that not all steps in the data action are required for each execution. You reduce the number of operations being performed within a given data action execution whenever possible. For example, a data action may perform some driver-based calculations within a given model, while also synchronizing data to and from another model.

In the first data action, labor costs in the expenses plan model are calculated by taking labor hours from the expenses plan model and multiplying it by the labor rate, which is read at runtime from the HR plan model.

123
MEMBERSET [d/Date] = (BASEMEMBER([d/Date].[h/YQM], "[2025]"))
MEMBERSET [d/P00D_CostCenter] = (BASEMEMBER([d/P00D_CostCenter].[h/H1], %CostCenter%))
DATA([d/Account] = "Labor") = RESULTLOOKUP([d/Account] = "LHours") * LINK([P00M_HR_Plan], [d/Account] = "LRate", [d/Personnel_Area] = "AMER", [d/Version] = "public.PubHrPlan")

In the second data action, benefits in the expenses plan model are calculated by taking labor costs from the expenses model and multiplying it by the benefit rate. This rate is entered by the planner at runtime.

123
MEMBERSET [d/Date] = (BASEMEMBER([d/Date].[h/YQM], "[2025]"))
MEMBERSET [d/P00D_CostCenter] = (BASEMEMBER([d/P00D_CostCenter].[h/H1], %CostCenter%))
DATA([d/Account] = "Benefits") = RESULTLOOKUP([d/Account] = "Labor") * %BenefitRate%

An embedded data action step can be added to data action that you are working on. Combining these steps with dynamic parameters lets you reuse data actions with different source or target members. When given the choice between modularizing a data action using an embedded data action step or creating a multi action, embedded data actions are preferred when optimizing performance.

Embedded data actions allow for better performance over multi actions, as all the embedded data actions are based on the same model or version, so the validation checks are optimized. While multi actions provide more flexibility across models and where there are more step capabilities, each step in a multi action is handled as a separate task. This adds extra time because each step needs to be started and finished individually.

The more reference members and reference dimensions involved in your allocation, the higher the volume of data that has to be processed simultaneously. This substantially increases the likelihood of performance bottlenecks and longer execution time as more resources are required for processing, especially if the dataset is large or complex.

Scenario: The Utilities cost center has electric expenses that have to be allocated to the receiving cost centers HR, IT, Accounting, and Administration based on kilowatt hours. When cost center Utilities collected the electric expense costs, they were stored against two different audit trails, Environmental Audit and Process Audit.

In this video, we will explore how you can improve performance when working with data actions that use reference members. We look at how the system calculates the allocation results with and without reference members in the definition of the data action, look an example of each approach, and ways to optimize performance.

Summary: Breaking down an allocation step containing many reference members can impact performance, especially if you're using multiple reference dimensions as this results in a large number of combinations that need to be processed. Instead, limit the number of defined reference dimensions as far as possible if your business scenario allows it. If they are required, then try filtering the reference dimensions when you run the allocation so that there are fewer combinations of members to process. By applying filters, you essentially cut down the combinations of the allocation that require calculation to a manageable subset of data rather than processing all possible combinations. This optimizes performance and resource usage.

If you have a data action that has issues and standard troubleshooting steps did not work, then you may need to debug the data action using SAP Analytics Cloud data action tracing. Tracing is a debugging tool whereby you can execute a data action and check its intermediate results at manually specified locations called tracepoints and the data changes between these tracepoints.

To use it, you set tracepoints, run your data action in trace mode, and then check the results. Based on insights from tracing, you can then proceed to edit or refine your data action to fix issues with your data action.

Detailed instructions on how to use SAP Analytics Cloud data action tracing can be found in Debugging Data Actions with Tracing in the SAP Help Portal section.