Well it has been under development for few weekends now, but I’m finally announcing the latest release of this tool. But before I go into the details of installing it and whats in it, i want to thank everyone who has shared feedback and encouragement with me via tweets, GitHub and comments on the original post, all of which has been a huge motivation for me!

 

This release completes the feature set i set out in my original post as well as some bug fixes.

• New Feature: Scheduled calculation mode (alternative to the existing Realtime mode)
• New Feature: Calculate button to run a full rollup calculation on existing data
• New Feature: Developer API, for embedding calculations in existing Apex Triggers
• Bug Fix: Realtime mode, improved optimisation to monitor rollup criteria fields and re-parenting

The tool now also has its own Application in the drop down containing the original tab and a new one.

New Feature : Scheduled Calculation Mode

For those that prefer to differ the lookup calculations, perhaps for performance or governor reasons (see below), you can now choose Scheduled from the Calculation Mode field. This requires a small Apex Trigger as per the previous release, it’s super easy, no developers required, just click the Manage Child Trigger button.  Then simply schedule the job using the standard Schedule Apex button under Setup then Apex Classes, the Apex Class is RollupJob.

Once this mode is enabled, you will see the new related list, Lookup Rollup Summary Schedule Items (as shown above) will fill up as child records are added, deleted or updated (only when lookup referenced fields are modified) with a list of parent records that are effectively queued up ready for the scheduled job to process. Once processed successfully they will be removed automatically.

If there are any errors (other triggers, validation rules etc preventing the master records being updated) you will see these in the new tab Lookup Rollup Summary Logs. Once you correct these you can remove the log entry or wait for the next scheduled execution and the log entry will automatically be removed for the effected parent record.

Tip: Add a Workflow Email Action to this object if you want to monitor log entries against certain objects.

New Feature: Calculation of existing Records

If you implement this tool and there are existing records in your objects, you can now use the Calculate button to start a background job to retrospectively calculate the rollups (time this accordingly to your user activity). Its also useful if your changing the rollup criteria or have deactivated and are now reactivating your rollup for some reason.

The button will start a job to select ALL of the records in the parent object (due to platform restrictions applying the child filter criteria), however the rollup criteria will still be applied as the rollups are calculated. If there are any issues during this process the above Lookup Rollup Summary Logs tab will list these errors, as with the scheduled mode, correct the errors and delete the log entries manually or rerun the calculate process.

New Feature: Developer API

If you have developers writing Apex Triggers or other Apex processes where you would like the rollups recalculated, you can have them call the Developer API. Simply select Developer from the Calculation Mode field and any lookups that are related to the child records passed into the API will be calculated automatically (the developer does not need to know or ask you for the rollups themselves, meaning you can continue to declaratively add or update them afterwards).

The main API, is the rollup method as shown below. Though there is also API’s to invoke the Calculate and Schedule jobs. The triggerHandler method is really for use by the Apex Triggers generated by the Manage Child Triggers button. Though if your in a Apex Trigger context it will work equally well from your triggers also.

List<Opportunity> opportunities =
    [select AccountId from Opportunity where Id in :myOpportunityIds];
List<SObject> parents = (List<SObject>) dlrs.RollupService.rollup(opportunities);
update parents;

NOTE: As minimum the relationship fields must have been included in the query before passing the children to the API. Also keep in mind if you have multiple parent rollups the list of SObject’s returned will be a mix of SObject types.

Advanced Relationship Criteria Handling

As an optimisation the tool will only attempt to recalculate rollups if relevant fields (such as those in the Field to Aggregate or Relationship Field fields) have been modified by the user (or if a child record is added or deleted). In this new release if references to other fields are made in the Relationship Criteria field, such as the example shown here, you must also ensure to specify the field/s in the Relationship Criteria Fields field. So the tool can also monitor these fields as being changed by the user. In the example used in this blog it means that if the AccountId, Amount or the StageName fields are changed on the Opportunity by the user, the Account rollup will be recalculated (this applies to Realtime and Scheduled modes).

Installation and Upgrade

As before the full source code for the tool is open source and available via the GitHub project, however if you have installed via the previous managed package you can now upgrade to obtain the new features above. All installation links and release history can be found here. There are some post installation steps to enable some new components. If your installing for the first time you can skip these.

1. Add the Calculate button to the layout
2. Add the Relationship Criteria Fields and Calculate Job Id fields to the layout (as shown above)
3. Add the Lookup Rollup Summary Schedule Items related list to the layout (as shown above, remove the New button and make Parent Id and Parent Record fields visible)
4. Depending on the security options you took during install, you may need to enable the Declarative Lookup Rollup Summaries application and Lookup Rollup Summaries Logs tab on relevant profiles / permission sets.

 

Dealing with the 50k Aggregate Query Limit

If you hit this limit its likely due to the fact that you have a LOT of child records related to  some or an average most of your parent records your rolling up on. Another reason, especially if your hitting this in Realtime mode, it maybe because you have to many rollups defined to one parent (though the tool attempts to merge rollup calculations, its not always possible). In this case switching to Scheduled mode for those effected lookups is the next thing to try.

If your already running in Scheduled mode or having a governor issue with the Calculate facility, you can try reducing the number of parent records processed at a time by these jobs. For this you will find under Custom Settings, the Declarative Rollup Summary Tool settings, the default for both the scope size settings is 100 parent records, try adjusting it downwards, the jobs may take longer (more chunks to process) as a result but they will stand a better chance of completing within the current platform query governor.

Feedback and Issues

Feedback, ideas etc via comments below most welcome, please report any issues via the GitHub issues page.