Apache OFBiz 專案概觀
作者: David E. Jones
翻譯: T.C. Chou
原始英文網頁: Apache OFBiz Project Overview 係 ofbiz.apache.org 首頁的 about 項目。
目的
這份文件目的是從商業的角度對 OFBiz (Open For Business, 開放為商業) 專案做整體瞭解。這裡會檢視專案的一些原則及背後的動機、主要應用元件、還有關於系統技術組織的簡短說明。
此一文件中的功能性描述都是比較系統中高階概略的觀點。如果需要更深入細節資訊的話, 可從功能清單找到相關文件。
介紹
OFBiz (Open For Business, 開放為商業) 是一套企業應用程式，它建立在通用資料/邏輯/流程相關元件的共同架構之上。由於這些程式弱耦合的特性, 讓元件容易被瞭解、擴充、與客製化。
OFBiz 的工具、架構能便於開發及維護企業應用程式。讓在專案中, 身為創造者與維護者的我們能快速提供新的功能與維護既有功能, 而毋須費太多力氣。也得以按需求的需要, 容易客製或擴充既有功能。
獨立的架構可依據須求很容易進行程式的客製化, 但如果這個系統不是開放源碼軟體的話, 系統中很多最有彈性的部份也沒有意義, 甚至不可能達成。OFBiz 在 Apache 授權版本 2.0 之下, 賦予這個系統能客製、擴充、修改、重新製作、轉售、和更多潛在用途。
對這些行為沒任何限制, 是因為我們認為這類用途的軟體唯有如此才能發揮其用途。不像其他開源授權, 比如像是 GPL, 所做的修改一定也得公開成開源。明顯的好處在於改進、修正、補充能貢獻回饋核心專案, 但也有些變更涉及專利或機密資訊不便公開。基於此一因素, OFBiz 用的 Apache 授權版本 2.0 就不這樣要求。想瞭解更多開放源碼版權, 請參考開放源碼促進會(OSI, Open Source Initiative)網站資訊, 在 www.opensource.org。
這種開源模式的另一個好處, 能讓我們不斷的從那些使用軟體的人收到回饋意見。我們從 OFBiz 的一般與潛在使用者, 收到無數關於錯誤修正、改進建議、以及商務上最佳的實務建議。專案裡許多很棒的功能, 都是依據送到電子郵件論壇中的一些意見或建議而來。許多單位的使用, 數以百計的站台以單一或更多專案元件進行建置, 因此這專案每天大約有 20 到 30 封的電子郵件。
為了確保我們提供的功能是符合時宜以及有用的, 我們對任何要著手進行開發的元件, 總以研究公開標準和通用的做法開始。藉由實現標準流程和其他組織的成果, 確保我們使用了共通的辭彙, 而所提供的功能及選項有足夠廣度。這同時也開啟通向未來的大門 ... 能具備彈性與其他建立在相同標準的系統溝通, 無論是同一組織的系統之間, 或合作夥伴, 甚至其他的組織、公司。
伴隨系統所提供廣度和彈性具備為基礎的應用程式與元件, 可遵從以最佳實務為基礎的設計, 依樣畫葫蘆般的使用, 或按特殊需求進行訂製修改。我們的應用程式協助容易地管理所有事情, 從成員、產品到財務、客服、和內部資源/資產管理。這些題目帶領我們進入下一項主題 ...
主要應用元件
經由大規模社群的通力合作以及持續開發, OFBiz 希望包含各方面企業自動化資訊與知識的相關功能。早期在專案的開發設計時, 我們找尋一個良好的資料模型做為系統的基礎。
在找到 Len Silverston 先生所寫的 資料模型資源手冊修訂版, 第一/二冊 (The Data Model Resource Book, Revised Edition, Volumes 1 and 2) 之前, 我們研究過不少其他 ERP 與 CRM 系統, 並閱讀各種一般與特定系統的書籍。花費了數週轉換書中描述的邏輯資料模型, 成為有彈性並一般化的實際資料模型之後, 我們得到初始的系統組成。打從一開始資料模型以來, 它經歷了數以百計的修改與基於實際使用系統的改進, 且與許多既存的公開標準相容。由於系統架構的彈性, 很容易進行資料模型的變更。對於持續改進的專案, 這是非常必要的, 讓它能容易改為符合特定的需求。
最上層的應用程式以及應用邏輯元件組成的方式幾乎和資料模型的結構是一樣的。只要瞭解某一層的組織之後, 要進入其他層的只要花一點工夫即可。
接下來會對系統的主要功能區塊做簡短概略的描述。這些都是目前已有的功能, 且系統相關部分必要的所有資料元素(data elements)也已完成定義。未來會完成更多功能, 我們將持續改良資料模型, 但全部主要資料元素都還是在那裡。所以只要記得有絕大部份, 但不是全部 ... 在這裡所描述的功能, 在此刻都已完成。
共通資料 (Common Data)
系統裡共通資料包含的資料實體, 像是: 地理分界, 度量單位, 狀態代碼, 列舉項目, ... 等等。大部分這種資料是為種子資料, 系統安裝時就會被匯入, 一般很少需要修改。地理分界和其他一些種子資料, 是依據 ISO 和其他標準而來。
內容 (Content)
內容實體用來連接資料來源, 並構成一般內容與知識。其中包含許多概念, 像是: 一組分離資訊組成資料源被用在更多內容結構中; 內容關係的彈性安排, 包含圖式自由連結, 或限制成樹狀, 條列, 名值對映, 樣板, ... 等等; 提供了內容和資料源使用的詮釋資料明細能用在內部整理和外部描述。各個內容存放各式各樣的文字或特定檔案, 是以標準的多媒體型態(MIME)和字元編碼呈現。
常用維護工具有基本資訊, 進階工具像是關鍵字/詮釋資料/智慧的搜尋, 文字探勘, 到自動建立附加的結構或詮釋資料, 可用來開啟廣度為企業級的文件和知識管理。
內容實體具有網頁相關資訊, 像頁面與內容的操作包含網站(或應用程式)拜訪的記錄和全部送到網站的要求。以上追蹤使用者的行為, 對安全, 行銷, 使用性, 或其他相關應用程式非常有用。
安全 (Security)
安全實體用來控制系統各個部份的存取, 包含了使用者登入帳號, 使用者稽核資料, 權限資料, ... 等等。更多附加的安全功能, 是經由成員實體和透過特定角色把成員連結到各種其他資料。舉例來說, 有使用者具有檢視與修改全部產品資料的權限, 也有其他使用者被賦予單一分類的業主權限, 只能檢視與修改該類別下的產品資料。
成員 (Party)
一個成員可以是一個人、或一個成員群體。而一個成員群體也許是一個公司, 一個公司內的單位, 一個供應商, 一個客戶, ... 等等。成員明細或直接關連到成員的資訊都包含在實體之中。
一類的關連資料是連絡方式像是郵件地址, 電話號碼, 電子郵件地址, 網路網址。其他還有角色指定成員為客戶, 供應商, 員工, 管理者, 業主, ... 等等。通常, 一個成員將會以不同角色和其他成員溝通。
其他連到成員的資料類型還有成員之間的通訊與合約。這屬於成員的關係管理領域, 還有事例或問題追蹤。這些與工項實體搭配, 可用來計畫和追蹤相關的研究和解決方案的進行。
產品 (Product)
產品實體包含了一個公司銷售或使用產品的資訊。產品可以是成品或服務, 有各類型的成品有原料, 組裝品, 和最終成品。產品資訊有含括產品描述性資訊, 但並非承述(適用的)實際物體或物質成品的特有資訊, 那些是以存貨項目來處理。一筆存貨項目包含特定物品位置, 相關狀態, 以及有續項目的序列編號, 或者非續項目的擁有數量和承諾數量。
產品可放到產品分類組織起來。單一產品可存在於多個分類下, 分類本身可以是其他分類的子類別, 並可擁有多個子分類。產品還可指定其他具體的觀點, 像是變體產品, 交叉銷售, 價值提升銷售, 促銷包, ... 等等。
分類能夠連結到不同產品目錄下。產品目錄基本上是一個開始的點, 包含了某類要販售的產品。其中伴隨著促銷與庫存管理的相關選項, 因此不同的銷售通路對相同一組產品可以有不同的處理行為。
不同特性的類型具有的彈性模式, 提供產品實體能定義不同特性, 而實際特性可套在產品中。舉例來說, 襯衫是大的尺寸和藍色的。尺寸和顏色是屬於特性的類型, 而大的和藍的則是該襯衫產品的實際特性。
多項價格能夠連結到單一產品, 也能有多項成本。 不同價格能定義不同幣別, 不同場所(或商店), 並給予不同日期範圍。
這是一個介紹在 OFBiz 中廣泛在使用有效日期的好地方。有兩個通用欄位來表達有效日期: 開始日期和截止日期。以產品價格為例, 開始日期和截止日期用來表示一個價格成立的某段日期時間, 以及失效的日期時間。這能夠保留價格變動的歷史, 也能有效管理臨時的促銷價格。
除了明確指定價格外, 也可透過實體與邏輯依據規則運算出價格。舉例來說, 可建一個規則在一段時間對特定分類下的全部產品做促銷, 或以簡單規則給一個或一組客戶有特別優惠的價格。
訂單 (Order)
訂單實體用來管理銷售和採購訂單的資訊, 以及下訂單前的預備作業。例如客戶有特定產品或功能的要求, 這些會在訂單套件中以需求實體被追蹤。
要求可被追蹤並轉成一項需求, 之後在建成一筆工項(舉例來說: 任務, 請照下面工項部份), 可用來滿足需求, 並是為履行之前的要求。當需求被做成報價, 如果被客戶接受之後, 可用來建立訂單。當訂單被執行完畢, 可從訂單產生發票。發票部分在財務會計的實體套件, 將在後面描述。
訂單包含標頭, 任意數量的明細項目, 以及調整項目, 這些用來組成訂單的各種細節。有各式各樣的資訊連結到訂單, 不論是訂單的標頭或者單獨及多列的明細項目。例如包括了訂單運送目地與寄送偏好, 可以全部明細的列項都相同, 也可每項都不同。
調整項目做為訂單價格修正的資訊, 不會改變實際成品及服務的販售或購買金額。像是稅金, 運費, 折扣, 額外費用, ... 等等。調整項目可以是固定金額, 亦即每個數量的金額, 或整個訂單小計的百分比, 或每項細目的加成數。稅金和運費是以特殊方式處理, 每次調整可被指定或取消 ... 可以看是否以加總金額計算稅金, 以及是否包含運費來計算。
付款的偏好可依據訂單所建立的發票設為自動付款, 如果付款是用信用卡或其他電子交易, 這會特別有用。假使沒有付款偏好, 則會進行標準發票及付款的程序。
場所 (Facility)
場所是一個建築物或是指其他實際位置。例如倉庫, 商店, 辦公大樓, 大場所的獨立房間, 裝卸碼頭, ... 等等。通常場所都有相關的連絡方式, 像是郵件地址和電話號碼。
幾個場所可以成為場所群組, 而場所群組也可包含其他場所群組。可做為群組的例如商店街, 商業區, 商業中心, 這些特別群組用來作產品行銷或價格的區分。
庫存項目可關連到一個場所, 或場所內特別的區域。場所位置則用來追蹤與管理獨立的庫存項目, 用來簡化倉庫空間的管理與簡化庫存項目的位置。
另外, 關連到場所的成員, 代表在組織中控制或執行工作的人員, 可能是場所的管理者之類的。
運送 (Shipment)
運送實體用來追蹤送入和送出, 能從庫存中取出物品, 或收取物品到庫存中。
一個運送包含多個物品, 如訂單明細項目一般, 記錄特定產品的數量。當收到運送物品時, 可與採購訂單做核對處理, 利用運送收據實體追蹤相關資。
當替出貨提取一個庫存項目, 它會和取貨清單建立關連。一份清單可處理多份出貨, 以增進倉庫或其他場所取貨的效率。
可建立運送包來表示單一盒子或其他運送單位。單一盒子能夠包含多項運送物品, 即使這些物品分屬不同運送單, 只要是送到相同目的地就可以這樣處理。
運送途徑實體是用來分割運送旅途成為多個途徑區塊。某一個途徑區塊的運送可以是商業遞送服務, 其他區塊可能是私人遞送或交由公司的卡車負責。
財務會計 (Accounting)
會計實體的安排是依據長年經驗與大眾接受的準則, 像是複式分錄會計, 階層式科目的總帳, 帳簿, 交易過帳與對應分錄。結構基本上按照 OMG 組織的 GL 標準, 並完成了應收/應付擴充。與其他標準如 ebXML 和 OAGIS 也有很好的對應。
會計實體的結構能處理多個組織的會計。多個組織可以是多個公司, 或多個部門, 或是其他公司內的組織。 每個組織可以有不同的總帳科目, 因此能在主要會計科目表之下, 獨立出的子科目表。每個組織也有彈性擁有獨立的帳簿, 即使為了便於系統自動化, 帳簿的使用應該愈少愈好。系統能基於商業行為自動建立並交易過帳, 這是以標準程序和文件處理啟動, 像是採購、銷售訂單, 發票, 存貨轉移, 付款, 收據, ... 等等。
有一些實體是為預算, 和沖銷預算 ... 在指定財務週期內與實際總帳科目平衡。是的, 也有些實體用來追蹤客製的財務週期, 還有保持在指定期間內科目的彙總結果。
追蹤固定資產的實體也是屬於會計實體套件的一部分。包含額外維修的折舊資訊, 固定資產的調度 (伴隨著工項實體), ... 等等。
行銷 (Marketing)
行銷實體用來追蹤關於行銷活動的資訊, 並且關連到連絡清單 (一般郵件, 電子郵件, 或電訪清單), 以及追蹤碼。追蹤碼基本上用在自動化系統, 追蹤客戶從何而來。也可用來抽佣, 甚至進一步分析行銷活動包含廣告, 夥伴關係, 或結盟, ... 的效果。
工項, 工作項目 (Work Effort)
一筆工項可能是許多事情的其中一, 包含任務, 專案, 專案階段, 待辦事項, 行事曆項目, 或者是 工作流程 (不建議) 或 工作流程 (不建議) 的活動。
請注意 : OFBiz 放棄工作流程引擎。最終是有 Shark 實作, 但沒有真的被 OFBiz 採用。取代工作流程引擎的應用, OFBiz 採取 事件驅動架構(Event Driven Architecture, EDA) 並以 ECAs (SECA, EECA, MECA) 在 OFBiz 中展開實際流程。ECA 是事件-條件-行動(Event Condition Action)的首字母縮略。SECAs 用在服務 (以服務條件驅動), EECAs 用在實體 (以實體條件驅動), MECAs 用在電子郵件。
工作流程 (不建議) 是種特別情況, 並被 OFBiz 工作流程引擎 (不建議) 所管理。一項 工作流程 (不建議) 基本上是半自動作業, 可同時讓電腦進行自動化部份, 而由人進行手動作業, 或是透過人控制外部系統。工作流程引擎 (不建議) 處理 工作流程 (不建議) 是由工作流程管理聯盟(Workflow Management Coalition, WfMC.org) 所訂定的實體中定義。XPDL 檔案能夠匯入到這些實體中, 然後定義的 工作流程 (不建議) 會依據不同方式啟動。工作流程引擎 (不建議) 保持追蹤所有完成和必須處理執行的流程。
在工項實體套件中也有時間記錄卡的實體, 以及進行工項的特定成員支付費率。也有更多不同的資源可被追蹤, 像是固定資產, 場所, ... 等等。
當工項被用在生產製造或其它產品修改, 相關產品及存貨細目的消耗與產生都會建立特別的工項被追蹤。
人資, 人力資源 (Human Resources)
人資實體用來追蹤職位, 任務, 技能, 僱佣, 離職, 優點, 訓練, 支付職等, 和薪資帳冊偏好設定, 績效評估, 履歷, 以及應募, 和其他人資相關資訊。
架構和系統組織
架構實在只是時髦字眼來表達應用元件的組織和構成。有很多 Java, J2EE 不同部分的有用 "工具" 與 OFBiz 核心框架能夠快速有效地組織資料和商業邏輯, 提供與其他系統連接介面, 還有建立了使用者介面讓人和系統互動。
實體與服務 (Entities and Services)
大量在 OFBiz 基本元件是實體和服務。一個實體是關連資料建構任意數量的欄位, 和相關連的其他實體。基本實體對應實際資料庫結構。有種實體型態被稱為 "檢視-實體" 用來從其他實體中組合欄位、連結實體, 建立出虛擬實體。這些建構可用來彙總與群組資料, 然後準備在程式中檢視或使用。
許多架構的資料或持久層由數十萬或上百萬行程式碼構成, 其維護必須如同系統般開發和客製。實體引擎的做法, 這些會被精練成數千列的 XML 資料定義, 然後交由容易使用的動態 API 處理。即使沒什麼經驗的程式開發者, 只要花幾天時間不用學任何 SQL, 透過這工具也能很有生產力, 它會為你處理相關細節!
也許有聽過 "網路服務" 這個流行字眼, 流竄在軟體業的各個角落。OFBiz 系統不只能使用服務樣式和其他系統溝通, 也可在系統內使用服務樣式, 它提供了乾淨與容易使用的機制來建立並執行商業邏輯元件。
服務是進行特定操作的簡單程序。服務定義兩種參數: 使用的輸入參數和產生的輸出參數。服務能在實際邏輯進行前, 依據定義檢核傳入的資料。而在服務執行完畢, 會以相同方式檢核執行結果。
其他服務能自動在不同點執行, 依據 事件-條件-行動 (Event-Condition-Action,ECA) 規則來表達那個服務要在什麼情況下被呼叫。這讓處理邏輯得以擴充, 但不用更動原本的邏輯, 也讓系統更明確組織每個服務去進行單純, 特定的任務。
服務實作有幾種不同方式, 配合著開發人員手上那個合用的工具能夠容易進行。在系統上百個檔案中, 也可以很容易追蹤邏輯元件, 即使是公司內不同電腦, 或者是合夥公司的電腦。
流程與規則 (不建議) Workflow and Rules
請注意 : OFBiz 放棄工作流程引擎。最終是有 Shark 實作, 但沒有真的被 OFBiz 採用。取代工作流程引擎的應用, OFBiz 採取 事件驅動架構(Event Driven Architecture, EDA) 並以 ECAs (SECA, EECA, MECA) 在 OFBiz 中展開實際流程。ECA 是事件-條件-行動(Event Condition Action)的首字母縮略。SECAs 用在服務 (以服務條件驅動), EECAs 用在實體 (以實體條件驅動), MECAs 用在電子郵件。
工作流程引擎, 已被簡短的在上面工項部份描述過, 用來自動化商業上的程序, 由手工(人做)和自動(電腦做)兩部份的相關執行活動所組成。工作流程可如同服務被呼叫, 也可在流程內自動執行呼叫其他服務, 具備無窮的彈性組合這類小單元邏輯元件。
工作流程工具的目的是複雜商業流程的自動化與追蹤。可在相當規模組織中, 協助經常進行的作業、任務, 一方面確保規則被遵守, 另一方面讓重要工作不會在混屯紊亂中遺失。一個很好的例子是在 OFBiz 中, 以工作流程為基礎的訂單管理。當填妥訂單就會啟動工作流程, 之後追蹤訂單簽核與執行狀況。透過這工具很容易掌握特定訂單發生的狀況, 並瞭解還有什麼該做的。
還有更多流程範例可發揮這類管理的好處。例如: 內容建立與發佈, 客戶問題/投訴/服務管理, 銷售週期管理, 和其他不同角色, 不同人員投入的商務流程。
在 OFBiz 的規則引擎基本上是另一類程式語言, 與其他程序語言像 Java, Basic, C, Cobol, ... 等在概念上完全不同。事實與規則被宣告後, 用於下面兩種方式之一: 1) 如果要求的某判定為真, 則呈現相關判定證據的全部資訊。2) 以全部可用的資訊, 去要求規則引擎給出已知相關的所有事實與規則。
規則引擎發揮在很多不同應用。對決策支援特別有用, 幫助人們分析以紙本作業來說複雜的狀況, 或超出腦袋負荷, 或任何得花費大量時間的情形。使用規則, 如同去找尋一個問題的限制條件和所有符合的方案。像是安排登機門或卡車運送透過取貨途徑能省下大量時間, 並允許建立一貫適用的規則, 協助即使有豐富經驗的人避免有時也會發生的疏失。
網頁框架和 XML 微型語言 (Web Framework and XML Mini-Languages)
在 OFBiz 核心框架有很多有用的工具, 各有不同定位在網頁, 主從式, 以及對等式為基礎的企業應用程式。 有工具是為了簡化普通資料檔案的使用, 讓原有系統的整合更容易。各式各樣的工具提供了安排、組構網頁為基礎的內容, 以及協助應用程式的邏輯彈性分割和呈現。這些工具依據 J2EE 標準, 還有其他 Java 工具 ... 讓系統與使用者及其它系統的溝通更容易。
為了更容易使用這些核心框架, 因此建立另一個元件工具稱為 XML 微型語言。能讓開發者或使用者建立一個 XML 檔案, 以簡單明確的指令讓系統理解並執行。在微型語言的 "simple-method" 中表達邏輯通常只要相同功能 Java 程式碼的三分之一, 對半技術人員來說, 卻是更容易閱讀及修改。處理表單輸入, 組合服務成為更大的服務, 操作資料庫的資料 ... 都是這工具常見並容易處理的事物。
結論
OFBiz 是投入大量群組的使用者及開發者, 由小型中心團隊協調合作的一個成果。應用和框架元件被廣泛地使用在商務應用程式, 還有被軟體的使用單位依據許多狀況與碰到需求進行大量密集的客製。
這僅唯有是一個開源專案才能如此快速有效的進行。大部分商業廠商經由設計過的限制或版權的約束, 來箝制他們的軟體在許多方面的使用和擴充, 以榨出更多獲利的做法, 與我們的方式形成明顯的對比。與現在軟體相比, 早期商業軟體有更多的彈性, 並開放而較少約束。隨著這種趨勢的蔓延, 很多軟體的開發者與使用者會去開始考慮更值得信任的做法。
包含專案主持人, 所有貢獻到這個專案的人都不強迫其他使用的人一定得要付錢, 他們從其他地方獲利。通常會發現系統提供的已經很接近你所要的, 只要付一小筆金額進行部份修改, 就能讓系統完美。如果把這些貢獻回饋到社群, 其他有類似狀況的人就能獲得幫助, 也能持續改進及維護。可自由的從主專案著手加強升級自己的系統並進行貢獻, 就不必擔心自己與他人的變更發生衝突。
一般來說 OFBiz 提供許多有價值的東西, 應該會志願並樂意貢獻出某些回餽, 讓價值繼續成長。和商業強迫使用者付費獲得使用權利或修改相關軟體的做法, 也有顯著的對比。開放源碼的做法是讓資訊共享, 使相關資訊在社群中充分運用, 而後提升軟體以滿足本身的需求。
因此對專案主持人來說, 花費時間設計框架與應用程式, 撰寫程式, 還有回答問題 ... 最後我們得到什麼? 這回到基本的收穫法則: 種瓜得瓜, 種豆得豆。提供愈多價值, 收穫就會愈多。對我們而言, 這是個機會成為一個專案的核心成員, 並參與使它成長。這也讓我們有機會提供服務與你一起工作以換取收入, 保持專案進行。
我們只希望你能夠獲更多的價值, 由於有這個專案。