3071139 - SuccessFactors Story Reports: Memory Limits and Design Guidelines

Incorrectly choosing the combination of objects can result in Cartesian joins, leading to an explosion of records being fetched for a single user. This creates numerous combinations of data that must be held in memory, causing OOM exceptions.

• Choosing a Driving object which has multiple records for each user
  • Employee Timesheet
  • Compensation Information 
• Using Driving object with Time filter 'Show All'
• Change Reporting
  • Fetching all data from both the original and duplicated object to perform change reporting for an older date range 

• Identify the number of records fetched for a single user by filtering on a single user at driving object level.
• Verify if the Driving object is a good choice
  • Any object that would fetch single record for User
  • Time filter is set to 'Current Date' 
• Look for joins, such as User data to Timesheet or All Templates (PM/GM) and so on, which could fetch 10s of records for each user.
• Verify if Inner Join works
• See if offline scheduling works

• Driving object to fetch a single record of User 
• Time filter to be set as a specific date, and avoid 'Show All', especially for Driving object.

Using the same object multiple times by duplicating it is a common scenario, to transpose data. This can lead to excessive memory consumption as multiple instances of the same object occupy the memory.

• This is commonly seen in reports where conversion of multiple rows to a single row is required
• Mostly used for fetching 
  • All Pay components in a single row
  • All Dependents in a single row 

• Verify the query design to see if any object is duplicated multiple times. 
  • If duplicated only once, it could be used for 'Change Reporting'.
  • Any duplication, greater than one, would be for Transpose.

• Can implement one of the 3 suggestions provided in Dos and Donts to report on compensation data of em... - SAP Community

Using calculated columns within other calculated columns and employing multiple If-Else blocks in a single calculated column can increase the complexity and memory usage. Each layer of calculation consumes additional memory, exacerbating the OOM issue.

Example:

If (PayComp = '123', A, 
    If (PayComp = '234', B,
        If (PayComp = '345', C,
            If (PayComp = '456', D,
                If (PayComp = '567', E,
                    If (PayComp = '678', F, X))))))

• Calculated column A which has 5 IF() conditions. Now we create another calculated column B which has 10 IF(A) conditions using the calculated column A. When the final query is generated, it will have 50 IF() conditions (A x B) and hence become performance heavy.

• Check for calculated column complexity
• Look for depth of IF-ELSE conditions
• Identify the calculated columns, that are used within other calculated columns 
• See if offline scheduling works

• Simplify the conditions used in the Calculated columns. Using functions rather
• Avoid nested calculated calculations as much as possible. 

Adding too many filters at the Story level means retrieving and rendering a vast amount of data before applying the filters. This approach requires the entire dataset to be held in memory, resulting in potential OOM exceptions.

• Fetching Global data of large organizations, without selectively restricting, based on country/business unit/location, at query level
• Fetching data without Time filters and applying date range at Story level

• Verify if there is risk of Parallel execution
• See if the filters used at Story level can be moved to Query level

• Ensure that all the reports have 'Apply Selection for Filters' setting ON for all Reports. 
• Move filters to Query level
• Divide the Report into multiple copies, based on Location, Business Unit etc

• Fetching Global data of large organizations, with filters based on country/business unit/location, at query level

• Check if there are too many filters at Query level
•  Look for filtering options on Driving objects

• For filters at Query level, identify the ones which can be moved to Object level. 
  • Country/Location type of fields will reduce the amount of data fetched from DB, when filtered at Object level

• Using Time Filter 'Show All' on most of the objects used in the Query
• Change Reporting
  • Fetching all data from both the original and duplicated object to perform change reporting for an older date range 

• Fetch the data for Current Date and see if the report works
  • If it does, extend the time frame to an year and see if it works
• See if offline scheduling works

• Fetching yearly data can be tested and reports be divided based on years
• Using Charts rather than List widgets might work for Time Trend Analysis

• There is a Standard template, designed to show how simple supervisor reports can be created. Customers increase the levels in it.

• Reduce the levels and see if the report works
• Try offline schedule export

• Try not go past 5 levels for large organizations
• Make sure to use Time Filter to a specific date (Show All will certainly fail)

• Users are creating multiple calculated columns at the widget level to aggregate the results, instead of creating using a calculation at the query level. 
• Historically, changing this design of the query can reduce the memory consumption significantly (when there is large amount of data).