Skip to main content
Gruppo in evidenza

Commons Project: DLRS

Declarative Lookup Rollup Summaries Tool, an Open Source Commons project. This group has been created to support discussion around this tool. This is a community powered tool so questions may not get answered immediately. Please post a screenshot of your DLRS record when asking for troubleshooting help =) In August 2021 DLRS joined the Salesforce.org Open Source Commons program to build community around this package. Joining the OSC helps ensure DLRS remains a trusted and sustainable open source package, that is free, community-led, and managed for years to come. If you'd like to contribute to DLRS, please post in the group!

I'm testing out an upgraded version of DLRS in our Sandbox and reviewing our setup. A consultant set up all of our scheduled DLRS under the older version of "Process Builder" which is now "Invocable by Automation" in more recent versions. These were never tied to a process builder or flow, only scheduled jobs. I'm trying to understand the difference between a scheduled job of "Watch for Changes" vs scheduled "Invocable...". Does Watch for Changes only pick up child records that are created or updated and Invocable is always a full recalculation?

3 risposte
  1. 6 ago, 18:30

    Invocable by Automation means taking control of timing and change detection. Best used with Flows or Scheduled Recalculation. Invocable by Automation disables all the "proactive" parts of DLRS for that rollup. Something else has to tell is that it is time to recalculate. 

     

    People will often drive DLRS via Flow when they need advanced criteria to know when a record should force an update, or because they want to use an async path to cause the rollup to update. (usually faster than Watch for Changes) 

     

    Scheduled Recalculation isn't really a "mode" by itself. It is the bulk reconciliation process. Paired with Invocable by Automation means DLRS only recalculates when told and that recalculation is across the entire dataset, not focussed on only those records that need to change. You can also use this with other modes, such as Realtime. If my Relationship Criteria uses a related object or relative dates (such as THIS_MONTH) then I need a Scheduled Recalculation as a backup to run once in a while and make sure all the values are correct. Realtime and Scheduled can only evaluate records when they are saved, if the change is isolated to the formula logic, or driven by a related record, then DLRS doesn't notice. 

     

    Realtime is usually best for when a rollup value MUST always be correct. If that field ever didn't match the data in the system it could mean real harm for your business. For most people this isn't the case but it still gets used often because people think they want it. As you've already figured out, Realtime is the most likely to expose errors because it adds the most processing work during the original record save so if it has problem or encounters something like a validation rule then DLRS will prevent the child from saving. 

     

    Scheduled/Watch for Changes is great for focussed updates that don't need to be immediate. It doesn't need to process every record in the system but can still delay processing for the RollupJob. This helps to separate the work that needs to be done from the act of saving child records. For most people this is good enough. It gives fewer errors to end-users and updates the rollup value when it is convenient. I usually recommend running every hour but I know many people need every 15 minutes. It is about how long you can go without the number being correct. Because errors are moved to a background job it becomes important to monitor the DLRS Log object, that is where most problems from here or the Scheduled Recalculate will show up. 

     

    Hopefully that adds more detail and decision points. There are a lot of ways to reach your goal. Usually I would recommend using Watch for Changes unless you have a reason to do something else.

0/9000

Is there any kind of log for realtime DLRS calculations? I know you can see scheduled rollups in the Job logs, but I'm looking to see if there's a way to see a log of when realtime calculations are triggered. 

4 risposte
0/9000

I've configured an External Client App, Auth Provider, and Named Credential following the DLRS documentation and updated the custom setting. I'm also using the most up-to-date version of DLRS. 

 

The authentication appears to work correctly initially. After authenticating the External Credential Principal, I'm able to use DLRS without issue. However, if I return an hour or so later and try to use DLRS app again, I receive the following error below. It seems like a timeout issue but I'm not sure what setting is causing it.

 

  • Unable to connect to the Salesforce Metadata API.
  • Web service callout failed: WebService returned a SOAP Fault: INVALID_SESSION_ID: Invalid Session ID found in SessionHeader: Illegal Session. Session not found, missing session hash:  This error usually occurs after a session expires or a user logs out. Decoder: DataInDbSessionKeyDecoder faultcode=sf:INVALID_SESSION_ID faultactor=

Has anyone run into this with the newer External Client App + Named Credential configuration? 

Any guidance would be appreciated.

9 risposte
0/9000

New to DLRS so may be completely missing something. I have a count lookup which I built in our UAT environment which operates perfectly. I brought it into our Prod and it is not calculating anything. Only thing I can think is different is the number of existing records in UAT vs in Prod would be different. There is nothing at all showing in my summary logs or calculate jobs. I'm not getting any errors. I tried changing from User to System but still nothing. Any thoughts? 

 

DLRS working in UAT but not in Production - no errors

 

 

image.png

 

 

 

6 risposte
  1. 29 lug, 15:38

    @Michael Kolodner thank you so much for your help. The issue was an old active roll up flow bringing it back to zero!

0/9000
4 risposte
  1. 29 lug, 09:38

    Install the same DLRS package version in production first. Then deploy the rollup’s Custom Metadata record through a change set or your usual metadata deployment process.

     

    If the rollup uses Realtime or Watch for Changes and Process Later mode, include the DLRS-generated trigger and test class as well. Any scheduled jobs will need to be recreated manually in production. Once deployed, run a recalculation and test the rollup with a sample record before activating it fully.

0/9000

I have been using the tool, but I get caught up when deleting all of the child records that the DLRS rolled up previously. It will give a value before the delete and when all of the child records are deleted or the field that they are aggregating are all null, it will show up as 0 instead blank/null. Is this by design or could this be a feature that is to be added. 

 

Use Case. We have an Account that rolls up all of the Opportunities and a custom currency field for outstanding Opportunities. Whenever all of the opportunities do not meet that criteria, the result roll up field is showing $0 instead null. It would make us believe that we have $0 in the pipeline and have things to do instead of just having null, meaning there are no opportunities

5 risposte
  1. 24 lug, 18:03

    I am more on the technical side, so that could be more manageable for me, but I am not sure about other end users

0/9000

I ran a Hubbl scan and it looks like there are some 300k+ records under dlrs__LookupRollupSummaryScheduleItems__c object. We only have around 60 DLRSs. Does anyone know where these come from and how we can make sure we don't develop any tech debt?

5 risposte
  1. 21 lug, 14:31

    @Faizan Khan

    there are two different paths here. 

     

    Scheduled/Watch for Change and Process Later

    will use the trigger to monitor DML and when a record might cause a recalculation, it will create a Scheduled Item record to enqueue a future recalculation. Needs the RollupJob Apex class scheduled to process those Item records. 

     

    Process Builder/Invocable by Automation

    does not use a trigger and expects either a Flow or a Scheduled Full Calculation to determine when to recalculate. 

     

    We often see people doing a mix. They put the Rollup in Scheduled mode but use the Scheduled Full Calculate, seeing the obvious mirror in the word Scheduled. This is going to create the situation I think you're seeing. DLRS is creating the Scheduled Item records but nothing is consuming them. Alternatively, you're running full calculates so you're getting the correct rollup values. 

     

    This situation isn't blocked because there are very good reasons to do it but if you want to only use full calculate then switch to Process Builder/Invocable by Automation instead. Alternatively, you may see better time to accuracy and lower system load by leaning into the Invocable by Automation and adding the RollupJob Apex class. (Starting in v2.21 the new LWC wizard has a GUI to help schedule the RollupJob to process those records)

0/9000

Hi!  

I have an org in which I created a DLRS roll-up based on real-time, but then moved to 'watch and process later' but it's messing with a flow that I have running. The flow is record triggered, and on a scheduled path to wait 30 minutes. With the roll-up happening over-night I don't feel like it should be affecting my record triggered flow, but this is the error I'm getting even on a batch of 2 records (when an import happens):  

Error Occurred: The flow tried to update these records: 006Rz00000WgqLVIAZ. This error occurred: CANNOT_INSERT_UPDATE_ACTIVATE_ENTITY: dlrs_OpportunityTrigger: execution of AfterUpdate caused by: System.DmlException: Upsert failed. First exception on row 0; first error: UNABLE_TO_LOCK_ROW, unable to obtain exclusive access to this record or 1 records: a1aRz000006lTxZIAU: () (dlrs) Trigger.dlrs_OpportunityTrigger: line 7, column 1. You can look up ExceptionCode values in the

SOAP API Developer Guide

.---  

 

Is it possible that the trigger is still running on real-time? I can see in the scheduled jobs that the jobs are running at the allocated overnight time (I have 3 DLRS roll-ups in this org)  

If so, what's the best way for me to deal with that trigger? OR any other suggestions here for what I'm (not) seeing.  

Thanks! 

3 risposte
  1. 16 lug, 14:03

    Invocable by Automation is the "I'm going to tell you when to run" option. It bypasses DLRS' "watch these records" and takes over things on your own. 

     

    If you're driving by Flow, or using Scheduled Recalculation then that is exactly what you're looking for. 

     

    There is a DLRS Invocable Action available to kick off recalculation. You give it a Rollup Name as well as the Parent Ids that should be recalculated. (If I'm remembering correctly.)

0/9000

Whenever sandboxes are refreshed, any scheduled DLRS that exist must be manually rescheduled, which is a tedious process when there are several scheduled jobs and more than one sandbox to tackle.  Is there a more efficient way to reschedule such rollup jobs?

8 risposte
  1. 16 lug, 12:22

    @Ankit Vashishth

    thank you for adding those, unfortunately all of those options would fail in this case. 

     

    The Apex classes are part of a managed package and not marked

    Global

    so they can't be scheduled outside of the package's UI. 

     

    https://github.com/SFDO-Community/declarative-lookup-rollup-summaries/blob/5dbd186bb057bc8aea13d24dcf94d561830376c1/dlrs/main/classes/RollupCalculateJob.cls#L30

     

     

    In this case I think part of the problem is also being able to quickly extract what the current schedules are so they can be quickly recreated. Something that for a few different reasons still couldn't be done using only inspection of the scheduled job objects.

0/9000

I'm trying to figure out if I can use DLRS when there could be more than 50,000 child records for a given parent -- will this process rollups across batches.  

 

It seems that the scheduled / run now jobs are batched, as we can set a batch size, but the documentation references capturing >50K records among several parents:

 

 

"Why am I receiving this error “System.LimitException: dlrs:Too many query rows: 50001”

DLRS usually queries from the perspective of the parents, retrieving all of the child records that match the given criteria. If the parents in a given batch have an average of 250 (50,000 / 200) children, have many DLRS jobs configured, or have lots of cascading rollups (rollup from grandchild to parent to grandparent) then DLRS can easily request a total of >50,000 records in the given transaction.

If this is happening during a scheduled calculation or a full calculation batch job then you can adjust the batch size in the Declarative Lookup Rollup Summaries hierarchy custom setting. It defaults to 200." 

 

I've looked but haven't found anything definitive yet so thought the group could help! 

7 risposte
  1. 10 lug, 21:46

    @Jennifer Carneiro

    Salesforce makes special exceptions for "Count" actions. 

     

    In my scratch org I created 52,000 Contacts attaches to an Account. 

     

    If I run "SELECT AccountId, COUNT(Id) FROM Contact GROUP BY AccountId" then Salesforce will let it run and succeed. If I change it to "SELECT AccountId, MAX(CreatedDate) FROM Contact GROUP BY AccountId" then it throws the error "Too many query rows: 50001". (Run using Anonymous Apex) 

     

    So the good news is your specific case gets a pass but something slightly different would cause it to fail.

0/9000