RunFromApex Doesnt work in UPSERT Context

[jayeshtejwani]

Hi James,

As per our discussion, I have used runFromApex from my queueable framework, but I have encountered an issue.
I am using custom metadata to calculate sum of opportunity amount on the Account annualrevenue field.

In the After Update trigger context, I pass the updated opportunities(amount is changed) to runfromapex, it runs an insert operation(adds the value to annual revenue) and doesn't upsert or recalculate. I am passing the After_Update context so it should run an update operation right?

My Code:
RollUp.runFromApex(rollUpData.opportunities, TriggerOperation.AFTER_UPDATE);

Secondly,

I have a scenario, where I have 2 different amount fields on opportunity and two different custom roll-up fields on the account. I would like to run the rollup calculations only on field value changes using custom metadata when anyone of the amount fields on Opportunity changes. So the conclusion I would to know if there is a method I can use where I can pass which custom metadata to be used when any one of the fields changes? also, pass the context of after update to update the amount?

[jamessimone]

Hi @jayeshtejwani, converting this to a discussion as I don't have reason to believe (yet) that there's any issue with Apex Rollup at play here:

1. I don't think that we've discussed why you're calling Rollup from within your queueable. If I understand you correctly, you have a queueable (and associated framework) that is updating opportunities in memory. If you were to ask me, calling Rollup from the queueable itself is an anti-pattern; you should simply update the opportunities and have Rollup.runFromTrigger(); called from within your trigger handler framework. That is enough for 95% of use-cases. We spoke a little bit about this via email and I believe that at that time you were saying that there were issues with Apex Rollup enqueuing jobs when done through your queueable. There are quite a few jobs allowed to be queued from within a single queueable, but even if the default Should Run As value on the provided Rollup Control CMDT did not suffice, you could always have another Rollup Control record associated only with the rollups that you were looking to run through your queueable - all so that you could use Synchronous as the Should Run As picklist value. As it stands, Apex Rollup already auto-detects if it's not possible to enqueue (regardless of what the Should Run As default value is) and would swap to batch/sync processing on its own.

All of that being said - since you're updating the records in memory (prior to presumably committing them to the database with the updated amounts?), if you absolutely had to call Apex Rollup without letting your trigger handler framework call Apex Rollup: you can still do that. I described how you would go about doing so in the email chain we've had together; namely, calling Rollup.performRollup (the same method called from Flow). I could also expose additional methods to make this even easier, for example:

global static Rollup runFromApex(
  List<Rollup__mdt> rollupMetadata,
  Rollup.Evaluator eval,
  List<SObject> calcItems,
  Map<Id, SObject> oldCalcItems) {
  // ...
}

At the moment that method is safeguarded from external entry points that are not trigger-based, but I could overload this method to allow for non-trigger-based invocations. I am just not sure it makes sense to do so, and in that I beg your pardon because it could just be that I haven't gotten enough information from you to understand why you would want to circumvent the traditional method for calling Apex Rollup - namely, via Record-Triggered Flow or from an Apex trigger. Again, I'm open to exposing another method to allow you to do this more easily, but I'd like to understand the use-case prior to doing so since the base Rollup class isn't getting any smaller in size.

2. This is a very common rollup use-case; again, it only requires Rollup.runFromTrigger() to be called. Depending on how your Rollup CMDT records are set up, however many of them match the items (in this case, opportunity) being updated will determine which ones get pulled in by the framework. It auto-detects what the TriggerContext is and reacts accordingly. There should be literally one line of code to set up this functionality.

[jayeshtejwani]

@jamessimone

1. I think I have made things very complex here. To simplify, we have created a framework internally that chains the queueable jobs based on the order it was inserted in the custom object. This framework usage is must, we cant bypass this framework for async classes. The records are picked from the custom objects and queued in that order. Queueable records are created in the trigger handler and passed to the framework.
   For example, the opp amount is getting updated by the user, in the after update (trigger handler framework), I create a collection for old and new opps and pass the queueable class created for Rollup operations.
   In the class, I am initializing the FlowInput class object with the expected values by following the wikilink for CMDT based rollup.
   Org Defaults are kept as Synchronous as shared by you.
   But still the calculations are not being fired, queueable class doesnt run.

Queueable Class code:

Trigger Code:

2. Rollup.runFromTrigger() is not an option since I have got to run the code from Queueable class.

[jamessimone]

@jayeshtejwani you will probably need to set additional properties on each FlowInput instance — in particular, the deferProcessing flag must be set to false unless you also call Rollup.processStoredFlowRollups(); (this is what Flow actually calls through RollupFlowBulkSaver since there can only be one Invocable method per class). Please also ensure you’ve enabled the Org Defaults for the Rollup Setting Custom Setting- this is a commonly missed part of one-time setup. Lastly, if you need additional insight into what’s going on within Apex Rollup, keep your Salesforce developer console open while trying to use it with the Is Rollup Logging Enabled checkbox toggled on the Org Default Rollup Control record — you’ll be able to see a lot of additional info in your Apex Debug Logs using that.

[jayeshtejwani]

Hi @jamessimone,

Thank you for the last comment. We can close this discussion as I found the right solution to call the Rollup calculations from our Async framework. Secondly during the UPDATE of a specific field, managed to run a single calculation instead of all calculations defined in CMDT.

There were two issues in my previous code screenshots:

1. Issue was there are 7 required fields which needs to be initialized before calling Rollup.performRollup() whereas I was initializing only couple of fields.
2. Another issue was when I call RollupFlowBulkProcessor.addRollup(flowInputList); it runs for CMDT records defined on Account instead of running for changed field, hence I had to come up with below approach.

Here is the final code.

[jamessimone]

@jayeshtejwani nicely done!