Multiple CMDT Failing

[shane-saltbox]

We have two separate rollup's we'd like to perform between the same object, 'Hours' and 'Cost'. We're running into issues where when we have both records configure as CMDT records, only one of the records is actually getting calculated. We've verified that both record configuration works by deleting the other and confirming it works.

The records are getting created / updated from a Lightning component which is potentially creating 5-50 child records at once.

I've enabled the debug logging and it looks as though both are running as expected, but only one of the fields gets updated. In our case it seems as though it's the last metadata record 'Cost' that is getting filled in.

Is there anything we have to do in order to have multiple rollups on the same object?

[jamessimone]

@shane-saltbox hi there, multiple rollups are not only possible but very common. This is the first time I'm hearing of an issue like this - we have some users performing dozens of rollups on the same child object to parent. Is there any more info you can give me? It sounds like you've already enabled logging: -

• what is the output when the parent records are being updated?
• is there any logic further downstream that might be preventing a field update?

[shane-saltbox]

@jamessimone I just tried the upgrade and recieve the following error:

Let me know if there is anything specific I should do besides clicking upgrade on the package install page.

[shane-saltbox]

I also got a follow up email with this detail:

1. Apex compile failure
   Apex class RollupFirstLastSorterTests: line 5, column 5: Invalid type: RollupFirstLastSorter

2. Apex compile failure
   Apex class RollupFirstLastSorterTests: line 24, column 5: Variable does not exist: sorter

3. Apex compile failure
   Apex class RollupFirstLastSorterTests: line 32, column 5: Invalid type: RollupFirstLastSorter

4. Apex compile failure
   Apex class RollupFirstLastSorterTests: line 49, column 5: Variable does not exist: sorter

5. Apex compile failure
   Apex class RollupFirstLastSorterTests: line 57, column 5: Invalid type: RollupFirstLastSorter

6. Apex compile failure
   Apex class RollupFirstLastSorterTests: line 72, column 5: Variable does not exist: sorter

7. Apex compile failure
   Apex class RollupFirstLastSorterTests: line 82, column 5: Invalid type: RollupFirstLastSorter

8. Apex compile failure
   Apex class RollupFirstLastSorterTests: line 98, column 5: Variable does not exist: sorter

9. Apex compile failure
   Apex class RollupFirstLastSorterTests: line 106, column 5: Invalid type: RollupFirstLastSorter

10. Apex compile failure
    Apex class RollupFirstLastSorterTests: line 121, column 5: Variable does not exist: sorter

11. Apex compile failure
    Apex class RollupFirstLastSorterTests: line 130, column 5: Invalid type: RollupFirstLastSorter

12. Apex compile failure
    Apex class RollupFirstLastSorterTests: line 143, column 5: Variable does not exist: sorter

13. Apex compile failure
    Apex class RollupFirstLastSorterTests: line 158, column 5: Invalid type: RollupFirstLastSorter

14. Apex compile failure
    Apex class RollupFirstLastSorterTests: line 167, column 5: Variable does not exist: sorter

15. Apex compile failure
    Apex class RollupFirstLastSorterTests: line 175, column 5: Invalid type: RollupFirstLastSorter

16. Apex compile failure
    Apex class RollupFirstLastSorterTests: line 183, column 5: Variable does not exist: sorter

17. Apex compile failure
    Apex class RollupRelationshipFieldFinderTests: line 18, column 44: Constructor not defined: [RollupRelationshipFieldFinder].(RollupControl__mdt, Rollup__mdt, Set, Schema.SObjectType, Map<Id,SObject>)

18. Apex compile failure
    Apex class RollupRelationshipFieldFinderTests: line 33, column 14: Constructor not defined: [RollupRelationshipFieldFinder].(RollupControl__mdt, Rollup__mdt, Set, Schema.SObjectType, Map<Id,SObject>)

19. Apex compile failure
    Apex class RollupRelationshipFieldFinderTests: line 52, column 44: Constructor not defined: [RollupRelationshipFieldFinder].(RollupControl__mdt, Rollup__mdt, Set, Schema.SObjectType, Map<Id,SObject>)

20. Apex compile failure
    Apex class RollupRelationshipFieldFinderTests: line 73, column 44: Constructor not defined: [RollupRelationshipFieldFinder].(RollupControl__mdt, Rollup__mdt, Set, Schema.SObjectType, Map<Id,SObject>)

21. Apex compile failure
    Apex class RollupRelationshipFieldFinderTests: line 112, column 44: Constructor not defined: [RollupRelationshipFieldFinder].(RollupControl__mdt, Rollup__mdt, Set, Schema.SObjectType, Map<Id,SObject>)

22. Apex compile failure
    Apex class RollupRelationshipFieldFinderTests: line 124, column 14: Constructor not defined: [RollupRelationshipFieldFinder].(RollupControl__mdt, Rollup__mdt, Set, Schema.SObjectType, Map<Id,SObject>)

23. Apex compile failure
    Apex class RollupRelationshipFieldFinderTests: line 147, column 44: Constructor not defined: [RollupRelationshipFieldFinder].(RollupControl__mdt, Rollup__mdt, Set, Schema.SObjectType, Map<Id,SObject>)

24. Apex compile failure
    Apex class RollupRelationshipFieldFinderTests: line 162, column 14: Constructor not defined: [RollupRelationshipFieldFinder].(RollupControl__mdt, Rollup__mdt, Set, Schema.SObjectType, Map<Id,SObject>)

25. Apex compile failure
    Apex class RollupRelationshipFieldFinderTests: line 184, column 44: Constructor not defined: [RollupRelationshipFieldFinder].(RollupControl__mdt, Rollup__mdt, Set, Schema.SObjectType, Map<Id,SObject>)

26. Apex compile failure
    Apex class RollupRelationshipFieldFinderTests: line 206, column 44: Constructor not defined: [RollupRelationshipFieldFinder].(RollupControl__mdt, Rollup__mdt, Set, Schema.SObjectType, Map<Id,SObject>)

27. Apex compile failure
    Apex class RollupRelationshipFieldFinderTests: line 233, column 44: Constructor not defined: [RollupRelationshipFieldFinder].(RollupControl__mdt, Rollup__mdt, Set, Schema.SObjectType, Map<Id,SObject>)

28. Apex compile failure
    Apex class RollupRelationshipFieldFinderTests: line 287, column 44: Constructor not defined: [RollupRelationshipFieldFinder].(RollupControl__mdt, Rollup__mdt, Set, Schema.SObjectType, Map<Id,SObject>)

29. Apex compile failure
    Apex class RollupRelationshipFieldFinderTests: line 316, column 44: Constructor not defined: [RollupRelationshipFieldFinder].(RollupControl__mdt, Rollup__mdt, Set, Schema.SObjectType, Map<Id,SObject>)

30. Apex compile failure
    Apex class RollupRelationshipFieldFinderTests: line 333, column 44: Constructor not defined: [RollupRelationshipFieldFinder].(RollupControl__mdt, Rollup__mdt, Set, Schema.SObjectType, Map<Id,SObject>)

31. Apex compile failure
    Apex class RollupRelationshipFieldFinderTests: line 353, column 44: Constructor not defined: [RollupRelationshipFieldFinder].(RollupControl__mdt, Rollup__mdt, Set, Schema.SObjectType, Map<Id,SObject>)

32. Apex compile failure
    Apex class RollupRelationshipFieldFinderTests: line 382, column 44: Constructor not defined: [RollupRelationshipFieldFinder].(RollupControl__mdt, Rollup__mdt, Set, Schema.SObjectType, Map<Id,SObject>)

[jamessimone]

Ah you may need to use the advanced options in the package installation GUI to do a Deprecate mode installation - most people don’t have the tests so this isn’t a problem, but I changed the name of that class a few versions ago.

Worst case scenario you could probably comment out the code in those test classes and then upgrade the base package and then upgrade the test class package! If you are still wanting to manually deploy the test classes, RollupFirstLastSorterTests was renamed to RollupCalcItemSorterTests - the relationship field finder test class’s problems will be fixed through the comment out/un comment after upgrading since that was a method signature that changed.

[jamessimone]

Edited my response above with more clarity after reflecting on how to make the upgrade path as clear as possible — commenting again in case you’re tracking this conversation (as I do, on occasion) via email.

[shane-saltbox]

@jamessimone I ended up having to comment out two of the test classes to get the package to install, but I got it in this morning. When we get the other test coverage discussion solved we'll end up backing all of this out and using the plugin instead.

Here are the logs from an initial test run I ran (this one was successfull):
apex-07L7j00000FGvJqEAL.log
apex-07L7j00000FGvHqEAL.log

I ran through the below tests to validate the functionality:

• New parent, new bulk child
• Existing parent, update existing childs & new childs
• Existing parent, delete childs (We had a gap here before because we didn't have a delete flow, but I have in now and it seems to be working correctly)
• Existing Parent, delete childs & add new childs

All the above seems to be working except the last case where we're both deleting the childs and adding new ones at the same time. In the test I ran it looks as though the deleted records are reflected, i'm wondering if there is a conflict happening with the different operations. I was expecting two QueueableHandlers to fire, but I'm actually seeing three in this use case.
QueueableHandler Logs
apex-07L7j00000FGvZqEAL.log
apex-07L7j00000FGvfnEAD.log
apex-07L7j00000FGvhFEAT.log

Sync Log
apex-07L7j00000FGvi7EAD.log

For reference, here is what the delete flow configuration looks like:

Any thoughts on what's happening in this situation?

[jamessimone]

I will take a look! We are close to getting this resolved, I feel, and I was able to get the necessary test coverage this morning for your base case, so I'll encapsulate the delete situation in another test as well. I will be able to spend quite a bit of time today on this, feeling good about the progress so far.

[shane-saltbox]

@jamessimone got it, I understand what you were saying earlier now.
If we used that second parameter, would we also need to query for the full set of child records against the respective parents and send a 'full' list of records against the parent? Or would the invocable know to take the existing values on the parent and +/- the new values being updated?

Sounds like that would be a good solve for this though!

[jamessimone]

@shane-saltbox try this updated beta package where you can stipulate a second argument for that full recalc invocable. You may need to retrieve the flow metadata with SFDX in order to add the SObject type of that collection to the invocable after upgrading - this was an old limitation in Flow when adding generic SObject lists as parameters to existing flows, and I can't remember if that specific issue has since been fixed.

This will constrain the full recalc properly without you having to supply other information and make the operation must less intensive.

[shane-saltbox]

@jamessimone I have the package upgraded and I think I can easily just delete the existing recalc node and add a new one to get the Object type in there.

As far as the second parameter, what exactly am I suppose to pass it? Do I just pass it {!CurrentRecords} which I created for the last invocable?

[jamessimone]

that's right!

[shane-saltbox]

@jamessimone I just started the test and i'm running into issues with just a simple add execution. It looks like it's only grabbing a single record now instead of the full set of new insert records.

Did I configure this as you're expecting? (this is the same on both the delete and insert/update flow)

[jamessimone]

You’ve configured it the way I expected, yes. It’s … bizarre … that the results differ so drastically from your usage of the flow without that argument — where the Flow engine seems to have properly bulkified the insert/update/delete — to with that argument (since it seems to only be getting a single record at a time for this).

At this point, I don’t think that adding that second parameter will actually contribute much, if that’s the way the underlying requests are going to be sent. My gut reaction is that the Full Record Set changes I am working through will prove more fruitful in the long term.

I don’t know if you tried using Apex instead of Flow; that might produce different results for you (assuming the component you were demoing bulkifies it’s record inserts/updates/deletes).

[shane-saltbox]

@jamessimone sorry for the delay here! This week has been something else! Do you still want me to test the beta or is that merge into master mean I can test the latest sandbox version?

[jamessimone]

You should be able to test using the latest sandbox link in the README, yup. Not to worry!

[shane-saltbox]

@jamessimone I just ran through a full round of testing (mentioned below) and everything seems to be working as expected! I'm going to get this moved up our pipeline so we can get it validated by business users in a 'real world' examples, but it's looking very promising right now. Thanks for the hard work on this!

New parent, new bulk child
Existing parent, update existing childs & new childs
Existing parent, delete childs
Existing Parent, delete childs & add new childs

[jamessimone]

Awesome, great to hear. Thanks for being so patient, and thanks for your thoroughness in testing - otherwise that issue with Is Full Record Set might have gone unnoticed for a long time! Let me know if you need anything else.

[shane-saltbox]

Any time! Looking forward to using this package to it's fullest! Thanks for your help!

[jamessimone]

This was resolved in v1.5.8 - excellent feedback and testing cycle from @shane-saltbox