架構(gòu)
CRM/SFA應(yīng)用很大程度不同于其它的OFBizBiz應(yīng)用，OFBIZ應(yīng)用設(shè)計(jì)為一組可以整合在一起適合各種商業(yè)活動(dòng)的進(jìn)程，CRM/SFA應(yīng)用設(shè)計(jì)為支持角色/活動(dòng)的全部活動(dòng)在CRM應(yīng)用中，這樣子，它將帶來(lái)與其它應(yīng)用的很多不同點(diǎn)
1.CRM/SFA的商業(yè)邏輯粒度小于其它OFBiz，而且通常會(huì)調(diào)用很多其它應(yīng)用中的action。如當(dāng)創(chuàng)建一個(gè)帳戶時(shí)，CRM/SFA應(yīng)用將調(diào)用另一個(gè)OFBiz服務(wù)創(chuàng)建Party、PartyGroup、PartyRole、PartyRelationship等等
2.在OFBiz其它應(yīng)用中高度抽象的數(shù)據(jù)模型在這里表達(dá)成更傳統(tǒng)直觀的概念。示例，“Party”被表達(dá)成為account ,lead, contact, team, 或 team member, 它們擁有不同的用戶界面和業(yè)務(wù)邏輯。
3.OFBiz的“WorkEffort”面向用戶時(shí)表達(dá)為“Activity”,而且只是事件和業(yè)務(wù)可作為“Activity”,其它的 “WorkEffort”例如制造產(chǎn)品過(guò)程在CRM/SFA中不顯示出來(lái)。
4.它擁有PartyRelationship.securityGroupId定義多個(gè)參與者之間權(quán)限的不同的安全模型（示例，組成員A是否有權(quán)訪問(wèn)B帳戶？）它使用了不同的安全方法（查看“Security Documentation”了解詳細(xì)信息）
用戶界面原則
CRM/SFA應(yīng)用有一個(gè)不同于其它OFBiz應(yīng)用的界面原則。簡(jiǎn)單來(lái)說(shuō)，此原則就是 建立一個(gè)容易讓用戶明白和使用的界面，好過(guò)讓用戶不停的思考如何使用。
示例，“work effort”是一個(gè)OFBiz中的a task, a project, an event, 或a manufacturing production step,在OFBiz的WorkEffort應(yīng)用中讓用戶自己創(chuàng)建它時(shí)選擇對(duì)應(yīng)的實(shí)例選項(xiàng)，而在這里，WorkEffort被分離在不同的人機(jī)界面上顯示各自的特性。
大多數(shù)使用者，不會(huì)想“我打算創(chuàng)建一個(gè)work effort在參與者X和Y之間”，他們通常想“我為參與者X和Y在明天上午建立一個(gè)約會(huì)”。這樣CRM/SFA應(yīng)用提供創(chuàng)建約會(huì)界面并加入?yún)⑴c者X和Y，在此界面啟動(dòng)約會(huì)及完成它。
所以這意味著有些在OFBiz中允許的操作在CRM/SFA界面中不再被允許。示例，在OFBiz創(chuàng)建一個(gè)“EVENT”類型的work effor時(shí)可把它關(guān)聯(lián)到貨運(yùn)或產(chǎn)品制作過(guò)程。這些信息在OFBiz的work effort中是可見(jiàn)字段，盡管work effort在event中并無(wú)這些關(guān)聯(lián)字段。另一面，在CRM/SFA中界面看不到這些字段
這樣的功能減少帶來(lái)的是操作的易于理解，且也讓一些日常的操作減少不必要的步驟。
另一個(gè)UI原則是將很多分離的步驟合而為一個(gè)操作步驟。最好的例子是當(dāng)你創(chuàng)建一個(gè)聯(lián)系人時(shí)，你可以在一個(gè)屏幕內(nèi)輸入所有聯(lián)系人信息，而系統(tǒng)會(huì)自動(dòng)的根據(jù)信息創(chuàng)建參與者、聯(lián)系信息及關(guān)聯(lián)項(xiàng)，將很多分離在不同OFBiz中的應(yīng)用合而為一。
最后，我們打算避免用戶點(diǎn)擊回退、向前去查看信息，所以太多數(shù)屏幕都把信息顯示在同一個(gè)屏幕里，而不是提供很多的信息標(biāo)簽
編碼約定
另外，創(chuàng)建CRM/SFA應(yīng)用，我們還有一些與其它不同的編碼約定：
1.強(qiáng)制要求將視圖與數(shù)據(jù)準(zhǔn)備分離，我們限制視圖層如freemaker頁(yè)/XML只承擔(dān)展現(xiàn)數(shù)據(jù)功能。這樣意味著在form組件中不會(huì)存在”action”標(biāo)簽。
2.在屏幕組件定義中，使用beanshell腳本比<entity-one> XML操作更好。
3.Minilang腳本在一個(gè)方法中不要超過(guò)十行。使用java來(lái)編寫復(fù)雜的商業(yè)邏輯。不要在minilang中使用<or>、<and>及計(jì)算。
4.保證代碼塊簡(jiǎn)捷。一般的，如果你的方法超過(guò)兩百行，建議你考慮如何重構(gòu)它。
5.為你的代碼加上注釋。描述你編碼的目的和結(jié)果，而不僅是你做了什么。示例，如果你編寫了如下代碼
invoiceId=null;
不要注釋寫成：//設(shè)置InvoiceId為null
而應(yīng)該寫成：//invoiceId應(yīng)該為空，否則服務(wù)不會(huì)創(chuàng)建一個(gè)新的發(fā)票
6.使用較長(zhǎng)的變量/方法名稱，如：computeForecastParentPeriod，而不是一個(gè)很短無(wú)意義的名稱。
7.使用意指你所調(diào)用的實(shí)體對(duì)象的變量名，而不僅是一個(gè)縮略的變量名。 示例，如果你獲得一個(gè)orderItems集合，變量名不要僅叫做”item”——可以叫它們”orderItems”或”nextOrderItem”，諸如此類。如果你獲得一個(gè)OrderPaymentPreference實(shí)體，不要命名為“payments”，因?yàn)镻ayment實(shí)體同你命名的這個(gè)對(duì)象不是同一個(gè)東西。
8.在FTL、表單組件、beanshell和Java服務(wù)中使用java來(lái)幫助將復(fù)雜的邏輯進(jìn)行分離。
9.將代碼分離在應(yīng)用的不同目錄中，將表單、屏幕組件XML文檔放在widgets目錄中，將JAVA包放在src/目錄下，F(xiàn)TL放在webapp/crmsfa/，BSH腳本放在webapp/crmsfa/WEB-INF/actions/中…
10.在服務(wù)XML中加了相關(guān)注釋指出需注意的事項(xiàng)或此服務(wù)可能發(fā)生的意外
本文檔譯自opentaps v0.9 manual,本人翻譯,歡迎轉(zhuǎn)載,請(qǐng)注明出處.