salesforce開發(fā)中,我們會對object進行很多的操作,比如對object設置字段的必填性唯一性等,設置validation rule實現(xiàn)一下相關的字段的邏輯校驗,設置workflow實現(xiàn)某個字段的更改或者發(fā)送郵件等,設置trigger實現(xiàn)before和after的數(shù)據(jù)相關邏輯處理,設置sharing setting實現(xiàn)數(shù)據(jù)share,設置master detail的rollup summary字段等。當這些操作鋪天蓋地的上來時,你還搞得清楚當新增/修改一條記錄以后到底怎么運行的嗎?有了下面的圖以后(從國外博客盜的圖,忘記了鏈接,不好意思),相信可以以后對于這些操作的處理順序變得游刃有余。
1.當數(shù)據(jù)進行新增/修改操作時,從DB中獲取原始數(shù)據(jù);
2.從request中加載新數(shù)據(jù)的value;
3.如果請求來自標準的UI,UI上面可以自動check相關的pagelayout上的必填性校驗等,相關字段必填性配置可以放在page layout做限制;
4.如果請求來自自定義的VF頁面或者apex進行匿名塊操作,則先忽略相關pagelayout上的必填性校驗,執(zhí)行before trigger內(nèi)容;
5.運行系統(tǒng)的校驗,比如字段級別的必填性,validation rule;
6.當通過validation rule以后,執(zhí)行save操作,此時數(shù)據(jù)保存到DB,不過事務上還沒有commit,在after trigger及以后如果此obj有addError類似操作,會導致數(shù)據(jù)的rollback,簡單demo:
1 trigger GoodsTrigger on Goods__c (after insert) { 2 if(trigger.isAfter) { 3 if(trigger.isInsert) { 4 List<Goods__c> goodsList = trigger.new; 5 for(Goods__c goods : goodsList) { 6 goods.addError('測試錯誤提示信息'); 7 } 8 } 9 }10 }
理論上after trigger以前數(shù)據(jù)已經(jīng)保存到DB上了,但是因為after操作對object進行了addError操作,導致事務回滾,添加失敗。
7.執(zhí)行after trigger操作;
8.通過sharing rule分配相關數(shù)據(jù)共享操作;
9.執(zhí)行workflow rules,workflow rules可以執(zhí)行field update,如果進行了field update以后會重新執(zhí)行before trigger,workflow rules可以設置field update只是進行一次還是每次更改都會進入workflow rules,這里根據(jù)需求好好選擇,避免和trigger作用發(fā)生死循環(huán);
10.如果有rollup summary字段,更新rollup summary;
11.提交事務,此時才真正事務commit,7-10期間 如果有addError類似操作便會使數(shù)據(jù)rollback;
12.如果有email send操作,發(fā)送郵件。
總結(jié):了解數(shù)據(jù)處理的順序無論對初學者還是有經(jīng)驗的人來說都是必要的,因為有的時候,因為執(zhí)行順序的問題可能導致意想不到的錯誤發(fā)生。千里之行,始于足下,打好基礎方能放眼未來。如果篇中有描述錯誤的地方歡迎指出,有問題歡迎留言。
作者:zero
博客地址:http://www.cnblogs.com/zero-zyq/
本文歡迎轉(zhuǎn)載,但未經(jīng)作者同意必須保留此段聲明,且在文章頁面明顯位置給出原文連接
個人下載了一些相關學習的PDF文件,如果需要下載請訪問百度云 點擊此處訪問 密碼:jhuy
如果文章的內(nèi)容對你有幫助,歡迎點贊~
http://www.cnblogs.com/zero-zyq/p/6675967.html