Apex Code Development You need to sign in to do that
Don't have an account?
gireeshz Best Practice Question - Embedded Visualforce pages or Apex Triggers?
Hello - would like to get the community's opinion/input on this:
We are performing an implementation where the user is requiring a large set of individual 'roll-up' fields on the Opportunity (and other) objects. These fields are essentially summaries for fields on other objects that are related to the opportunity. These objects are not master-detail, and actually may not be directly related (could be 2 objects away, for example). After refactoring the object design as much as possible, it is not possible to bring things together nicely into master-detail relationships to use the Salesforce 'Roll-up Summary fields'. (although Salesforce allowing 3-deep master detail relationships would go a long way)
So, when we decided how to implement this, we come up with the following two options:
1) Create 'mini', single-field Visualforce pages for each of these summaries that can be embedded into the Standard Opportunity page layout. These pages would be for the standard 'Opportunity' controller but have a controller extension, lets call it 'oppFieldCalcs'. Create the apex class 'oppFieldCalcs' to generate the values of each of these 'mini' visalforce pages/fields using SOQL statements, etc. as normal. When the page loads, it runs all that code and builds the values for the fields. Essentially, the 'pull' model of obtaining these summary fields.
or
2) Create fields on the Opportunity object to act as placeholders for the summary values, then put logic in in insert/update/delete triggers for each of the 'related' objects that will update those placeholder field values incrementally as the related object records are manipulated. (i.e. when a new related object record is created, summary field count value is 'current value +1', etc.) This is essentially the 'push' model of obtaining these summary fields.
What does the expert community think about this?
Currently, we are proceeding with option 1. The visualforce embedding seems to work fine, although the layout restriction of harcoded page heights and delay-processed iframes feels a little kludgey. Plus, the user feels that the application is 'slower' since the page takes longer to grab all the extra field values.
On the other hand, this way the code is all in one place rather than distributed amongst a variety of triggers on disparate objects. It seems more manageable and resilient to change this way. Even though the trigger-based 'push' model makes the page layouts very clean for the user.
Many Thanks for your input.
I have a similar situation. I have only one object from which to summarize data, but the summarized data is eventually reflected on three different objects.
I chose the push method to implement the solution through triggers for two reasons. First, since the summarized data becomes a value in a field on the object in which it is contained, the data becomes more readily available for reports. Secondly, once I had summarized the data into a field as appropriate, that data immediately becomes available for system supported summary fields, thus circumventing some of the restrictions in setting up a summary field because of master-detail relationship problems. Therefore, once I had pushed up the data one level, it became available for summary fields at the next level.
This technique also circumvents the problem with slow screen displays. However, my situation seems less complex than yours in that I am only dealing with one object from which summary data must be drawn.
I generally error on the side of making things easier and more robust for the user as long as I can do so in a reliable manner. Afterall, that's what they pay me for.
Good luck in crafting your solution.
AQ,
Thanks for a very insightful response. Your point of making these summary fields available for future reporting is extremely well taken.
Also, the idea of simply 'pushing' values up a level into a location where it is easier to utilize in normal Roll-ups makes a lot of sense.
Many Thanks
I definitely agree with AQ- fields updated by triggers are the way to go. They are reportable, much easier to manage on the page layout, and you can write tests for the formula calculations.
One drawback is if you have other triggers on these related objects. If so, be mindful of the governor limits.
We implemented a similar solution, except with Contact and Account as the destination object, and it works well.