OFBiz Go

App 很紅, 主要在行動設備上, 上下游都很火紅。要談的 App 是現在不太紅的 Ent App (Enterprise Applications), 或是說已經紅過了, 但仍然是每個公司, 組織都會用到的。

App 多是產品, 而 Ent App 是種社會(Social), 俗名是江湖, 充滿交流與妥協, 大多以專案形式進行。就算從產品開始, 後面也會帶專案, 常見區分出軟體, 硬體, 開發, 維護, … 各個階段。

由於 Ent App 牽涉層面通常既廣又深, 以技術角度來看, 擴散方式(銷售, 安裝)一直沒太大改變。現在雖然服務導向, 雲端喊得震天嘎響, 但除了網路基礎服務(信件,檔案), Web應用或特殊應用, 要把 Ent App 放上去, 應該還有些東西要準備好。用雲端的榜樣電與水比擬, 水除了自來水, 還有各式來源; 電除了公共設施, 也有可移動型的, 或私人備援。因此資料的移動能力要具備, 否則還是有些不足。

開放源碼讓技術普及, 加上硬體設備的大幅提升, 過去得詳加規劃, 才能執行的 Ent App, 現在只要在雲端或筆電開個 VM (虛擬機器) 就行開工。再者, 小公司不需要 24 小時運轉的系統, 功能有的話, 需要時再開啟。甚至中型單位, 只要合宜的環境及配套規劃, 也能朝這方面努力。

首先, 要面對的問題是 … 怎麼去開始?

在 OFBiz 下載頁面中, 寫明只要有 JDK(Java 1.6 SDK), 下載 zip 後解開壓縮檔, 執行指令就可以開始。

似乎還算容易?

但每個平台準備 JDK 其實都不太一樣, 更不用說如果發生衝突的話要怎麼辦, 例如在 Linux 上用 OpenJDK。這些說明字句雖少, 看起來簡單, 毫無疑問是寫給工程人員看的。再加上 Ent App 的社會屬性是有機成長, 如果要修改, 要調整, 按照慣例就得靠自學, 或找人助拳。

以整個過程來看, 愈到後面, 障礙愈高, 的確是不太容易推動。

之前在一種應用源碼管理的實作討論過 可短小, 可長久, 可分享 的客製化方式。路雖然通了一小段, 但想想, 比原來 OFBiz 官方的安裝方式還要複雜, 素人要開始, 會有不小的障礙。

因此做了 OFBiz Go 用一個步驟完成 所有 繁瑣的準備工作。

準備工作有:

1. 下載必須的 JDK, Python, Subversion, Mercurial 以及相關工具(patch, diff, cURL, 或 Wget), Windows 要再加 MinGW。
2. 安裝妥上面這些東西, 做好設定 … 例如系統變數, Mercurial 的設定, 與 virtualenv 的環境。

當然如果機器上已經有的軟體項目, 就略過不下載, 也不安裝。

寫上一篇的時候, 略過這些步驟。對熟悉這些工具的人, 早就備妥; 但不熟悉的人, 繁瑣且容易漏東漏西的過程, 反而造成困擾。即使自己做, 將這些裝到 Linux, 也碰上不少問題。

想做個 VM 來用, 但每次要把數 GB 的東西搬來搬去, 還得搬進雲裡頭, 舉重若輕恐怕也不太容易辦到。

在支援 Windows 前提下, 也考慮 Puppet, Chef, 或老牌 CFEngine 這類 組態管理 工具。但即便輕如 CFEngine 都必須做額外的安裝設定, 所以這工具還是留給 應用系統, 做為其中的組件。

剩下可用的大概就是系統腳本語言(Shell Script)。

OFBiz Go 是先在 OS X 上寫個 .sh 做完上述工作。然後找到 Windows 2008 用 Powershell 寫個 .ps1。最後用 VMWare 開啟 Ubuntu 11.10, 原本認為 OS X 小改就可以用, 但還是改了不少。

比較特別是 Powershell 挺有 Power 的 … 要正確合法下載 JDK, 需使用者同意。Powershell 可控制 IE 瀏覽器帶出正確下載網頁, 當使用者點選同意後, 繼續腳本的工作。

目前在 OS X 10.6, Windows 2008R2 / 7, 還有 Ubuntu 11.10 測試過。OS X 可能會不太行, 因為環境不乾淨。;-)

只要腳本的下載, 安裝, 驗證的工作做完, 就可和 應用程式源碼溝通。把繁瑣的過程, 劃分成兩個階段, 方便入門者, 也方便自己。

由於大部份工具和 Python 相關(Fabric, MQ), 下週三(2011/12/21) 晚上 19:30 在新竹的 PyHUG 會描述 配置方式 與 應用客製 兩階段的安排, 及運作細節。除了 Ent App, 很多類似的狀況, 也可用相同方式處理。歡迎參加, 和我們一起討論。

開放源碼資訊應用系統的開發觀點

資訊應用系統較開放的定義: 公司、組織所需要的應用系統, 下面縮減為企業應用(Ent App), 與當下常見移動 (Mobile) 和 Web 應用有所區別。開放源碼顧名思義即可。身處在公司組織中, 資訊系統所涵蓋的可能是有什麼用什麼, 或依需要採買。企業應用則依公司組織的需求, 所打造的應用 … 有些是獨立系統, 或某個系統的擴充。常要與不同單位, 甚至跨公司組織的各系統聯繫以協同作業。

去年 2010 接觸一個國外頗具規模組織的企業方案導入, 從基礎設施開始到應用系統的那種。儘管方案已落入 M 社手中, 仍有許多可深入思考借鏡之處。

這個需要方案的組織, 雖然考慮過開放源碼方案, 對技術有想像, 對未來有憧憬, 最後還是回到踏實的 … 支援問題。

按捺支援問題, 整理過程中一些溝通討論的部份。

從頭開始的組織, 討論的觀點有多高? 大概有太空那麼高。平常較常用的辭彙字眼, 鮮少在此時派上用場。與非開發者進行討論, 還是得用流行 … 呃, 太空的觀點來溝通, 也難怪不斷有人創造一些東西來滿足。在其中討論的議題有目錄服務, 檔案分享搜尋, 管理監控, 入口網站, 工作流程, 應用系統, … 等。前三個題目, 一般公司組織都給 M 社綁住, 接下來似乎 M 社都把東西都準備好, 都可一次夠足儘管用。

曾被詢問: 如果不用 M 社方案, 這些問題如何解? 兜幾家公司產品才解決又沒參考案例, 說服力自動下降。能否找到適當資源滿足這些要求, 就成了給自己的寒假作業。

選擇以 Java, Python 為基礎, 避免對作業系統的依賴太深。

把問題劃分幾個區塊, 否則以系統/應用分太簡略, 純以開發觀點來看又太複雜:

• 應用系統: 這是已經存在並使用的應用。ERP, B2B, 入口網站, 網購平台, 生產系統, … 甚是以套件存在的論壇, 而開發成果也在此區塊。
• 基礎系統: 不需要應用也存在的系統。例如電子郵件, 資料庫, 網站網路服務(Web/FTP), …。
• 工具: 基本上是支援開發相關工具。像源碼的版本管理, 記錄工作的事例追蹤, 負責測試建置, 文件產生, 資料處理, …
• 開發作業: 可以是獨立的應用, 但通常除了基礎系統, 也與其他應用系統打交道。現在複雜環境, 選適當語言外, 更需要適當框架加持。

這些區塊的涵蓋面是否恰當, 以流行的 Web 框架來檢視: 資料庫/網站在基礎系統; 編輯器/版本管理在工具區; 開發框架本身在開發作業區; 如果套在入口網站裡, 就看成在應用系統區。

再來把之前討論議題在放進來:

• 目錄服務: 有名的 OpenLDAP 使用過一陣子, 那時要編得安全一點不太容易。現在 ApacheDS, 有 Java 環境就能很快上手。雖沒 M 社搭配其作業系統的特異功能, 但具備 Kerberos, DNS, NTP, DHCP。另有 Directory Studio 處理綱目和資料都便利, 而單一簽入(SSO)可交給 CAS 處理或 PicketBox。這些放到基礎系統區。
• 檔案分享搜尋: 從歷史來看, M 社把之前拳王 N 社撂倒後就一直雄據著, 不過移動設備和 Web 普及應該稍有機會推動一下這板塊 … 內容管理交互服務(CMIS)。實作不少, 偏好的是 Nuxeo, 實際選擇視需求而定。也放到基礎系統區。
• 管理監控: 之前做都是一兩個系統加上數個服務, 要求是把自己做的管好就好, 沒從組織觀點來看。這方面有許多成熟產品, 例如 SpringSurce 有併入 Hyperic。會考慮的是 Zenoss, 畢竟現在有各式各樣服務, 彈性大一些會比較好。而 Java 在開發作業考量與 Zenoss 搭配, 執行記錄方面從 log4j 著手走 syslog 即可。還是放到基礎系統區。
• 入口網站: 已經流行過好一陣子的題目, 或許每個人都有自己的一套, 就略過。分類的話, 由於依使用方式不同而有差異, 所以放應用系統區。
• 工作流程: 推薦的是原 jBPM 開發人員從 jBoss 離開, 在 Alfresco 支持下做的 Activiti 專案。從 2010 年底釋出 5.0 以來, 2011 的前兩個月都按表操課, 穩定釋出新版本 5.1, 5.2。具備彈性流程工具外, 比較特別的是考慮開發人員甘苦, 不會一昧討好商務端人員。Activiti 可考慮嵌入與應用共存, 但從服務獨立、聯合管理的角度, 應該是單獨存在的系統, 因此放到基礎系統區。
• 應用系統: 從開發觀點來看, 只要一個語言就可做任何事, 然而任何人能完成的事情都是有限。現成開源應用系統也不少(ERP, CRM), 加上在雲端的就更多。但能否存活, 像後者在 2010 收了好幾家, 特別讓人有疑慮。因此期望把關鍵資料放在自己可以掌握的地方, 彈性/好用是必需的, 但也不會因為開發專案的公司策略調整或併購而影響。因此選擇 OFBiz 來擔任企業核心的應用系統。

回頭看各區塊, 應用系統依實際狀況而定, 基礎系統補上即時訊息(IM) Openfire 做即時通訊, 另外以通用伺服器 Felix, Karaf, Camel, ServiceMix 統籌日漸增長的服務。工具區塊比較被熟悉, 也常見許多討論個人、團體開發過程中面對的問題與解決方式。這裡對之前 近未來 IT 開發 一文做補充, 成為開發作業區塊:

• 穩定層: 包含應用系統與基礎系統, 有穩定的界面。例如 ERP 財務的界面, 或像檔案傳輸的方式也固定。
• 動態層: 原本以樣板打造動態層, 要含括一般且普遍的情況下, 得選用框架。以 Web 來說, 會用 Grails, 他和原本 Java 與企業大宗資源 DB 溝通方式非常的 … 一脈相承, 能快速且彈性建立 Web 應用或服務。在 Web 應用方面, 加上 ZK 協助能使用先進的 Web 技術, 卻毋需太煩惱衍生的問題。而面對複雜的服務與模組, 有更強力的 Scala/Akka 組合以函數編程與靜態語言協助建立穩定的服務。
• 領域層: 有了上面分門別類的區塊提供各式的服務, 接下來在 grails 與 akka 下, 開發領域相關的東西。

整理如下圖:

歡迎指教與補充。 :)

參考連結:

• Activiti: http://www.activiti.org/
• Akka: http://akka.io/
• ApacheDS & Directory Studio: http://directory.apache.org/
• Camel: http://camel.apache.org/
• CMIS: http://en.wikipedia.org/wiki/Content_Management_Interoperability_Services
• Felix: http://felix.apache.org/site/index.html
• Grails: http://www.grails.org/
• Groovy: http://groovy.codehaus.org/
• log4j 搭配 syslog
• Jasig CAS: http://www.jasig.org/cas
• JBoss PicketBox: http://www.jboss.org/picketbox
• Karaf: http://karaf.apache.org/
• Nuxeo: http://www.nuxeo.com/en
• OFBiz 完全中文安裝教學
• Openfire: http://www.igniterealtime.org/projects/openfire/index.jsp
• Scala: http://www.scala-lang.org/
• ServiceMix: http://servicemix.apache.org/home.html
• Zenoss: http://www.zenoss.com/
• ZK: http://www.zkoss.org/

OFBiz 完全中文安裝教學

OFBiz 是 ERP, CRM, eCommerce, SCM, MRP, … 以 Apache 授權的企業自動化軟體。之前可能不太容易上手, 一方面這種軟體需要關注的層面太多, 另一方面沒有中文化(有簡體中文)。

以上在這兩週有些改變。上週(11/18) Bakker 先生提供了快速設定的方式(r1036323), 包含: 公司, 倉儲, 商店, 電子商務網站, 第一位客戶, 第一筆產品 … 只要走過幾個 Web 畫面就可完成 OFBiz 基本資料設定。而這週中文化進入 trunk (r1039574), 應該能降低語言的隔閡。

大部分這類軟體要設定 網站伺服器,資料庫以及系統本身。而 OFBiz 由於 Java 語言的優勢, 嵌入了網站伺服器與資料庫, 只要一個指令就可啟動, 假使需要也可用常見的網站伺服器或資料庫替代。除了降低入門門檻, 同時也具備擴充性。

更多的 OFBiz 介紹可參考: 什麼是 OFBiz, 專案概觀 (各模組介紹), OFBiz 適合我嗎?

下面把 OFBiz 在 Windows 完整安裝過程 (從下載檔案開始), 包含必要的修正, 並簡單示範了銷貨訂單, 採購訂單的建立與使用 … 做成影片放到 Youtube 頻道中 ... OFBiz 線上教學。

Avro 的使用與 Groovy Builder

Avro 是動態型別的資料序列化工具, 協助資料存放保留, 主要是讓網路化的應用程式有效率的溝通。如同使用語言設計模組溝通一般會透過界面方式, 在網路的服務常有著不同語言的實作, Avro 提供這些服務溝通的方式。

定義網路溝通的是通訊協定(Protocol), Avro 利用 JSON 定義通訊協定。

協定內包含有若干具名(name)的訊息(Protocol.Message), 每個訊息含有 3 種型態內容: 要求(Requst), 回覆(Response), 還有錯誤(Errors)。這些內容都以綱目(Schemas)定義內容的組成。

Avro 協助按綱目組成傳送的訊息。這裡有兩個關鍵: 一是組成, 一是傳送。

組成部份請參考 Patrick Hunt 先生的快速開始使用 Avro 範例 中可看出 python 與 ruby 都用語言本身的 collection 組成; 而 Java 則用 GenericData 套件。

而傳送方面 Avro 有 HTTP 與 Socket 兩種通用方式, 服務端是 Server, 使用端是 Transceiver。如果用訊息服務(MOM)或搭配既有SOA,ESB系統, 就得抓訊息產生結果來操作。(在 Java 用 GenericRequestor, GenericResponder 中的 read/write 方法)

以 Groovy 與上面 Python 範例對連:

import org.apache.avro.Protocol
import org.apache.avro.util.Utf8
import org.apache.avro.ipc.HttpTransceiver
import org.apache.avro.generic.GenericData
import org.apache.avro.generic.GenericRequestor

def avpr = """
......
"""

def proto = Protocol.parse(avpr)

def trans = new HttpTransceiver(new URL('http://localhost:8080'))
def req = new GenericRequestor(proto, trans)
def message = new GenericData.Record(proto.getType('Message'))
message.put('to', new Utf8('wei'))
message.put('from', new Utf8('tcc'))
message.put('body', new Utf8('Hello 123'))
def params = new GenericData.Record(proto.messages.send.request);
params.put('message', message)
def ret = req.request('send', params)
println "Result: " + ret

其中 import 群下的 def avpr = """......""" 是把 src/avro/mail.avpr 定義的通訊協定拷貝進去。

如果不想用嵌入式, 可改為類似 python 範例中的:

def proto = Protocol.parse(new File('../avro/mail.avpr'))

再做 Groovy 的 Server:

import org.apache.avro.Protocol
import org.apache.avro.util.Utf8
import org.apache.avro.ipc.HttpServer
import org.apache.avro.generic.GenericData
import org.apache.avro.generic.GenericResponder

def avpr = """
......
"""

def proto = Protocol.parse(avpr)

class MyResponder extends GenericResponder {
    public MyResponder(Protocol proto) {
        super(proto)
    }
    public Object respond(Protocol.Message msg, Object req) {
        return new Utf8("""Sent message ${req.message['to']}
  from ${req.message['from']}
  with body ${req.message['body']}""")
    }
}
def res = new MyResponder(proto)

new HttpServer(res, 8080)

其中 respond(Protocol.Message msg, Object req) 的 req 為 GenericData.Record 在 Groovy 利用 GPath 直接操作相當便利。但客戶端用 GenericData 組成看起來頗辛苦, 想改用 Groovy Builder 式:

avro_builder.send { request {
    message(to:'wei', from:'tcc', body:'Hello 123')
}}

寫個 AvroGroovyBuilder.java 放在 github。 (注意: 目前沒處理 List)

使用端就可簡化成為:

import org.apache.avro.Protocol
import org.apache.avro.ipc.HttpTransceiver
import org.apache.avro.generic.GenericRequestor

def avpr = """
......
"""

def proto = Protocol.parse(avpr)

def trans = new HttpTransceiver(new URL('http://localhost:8080'))
def req = new GenericRequestor(proto, trans)
def avro_builder = new org.tcchou.groovy.AvroGroovyBuilder(proto)
avro_builder.send { request {
    message(to:'wei', from:'tcc', body:'Hello 123')
}}
def ret = req.request('send', avro_builder.params)
println "Result: " + ret

Jailer 的使用

經常與資料庫為伍的開發者來說, 雖然 ORM 的普及解決大部分與 DB 溝通的問題, 但屬於型態上的。特別是常見的資訊系統, 很多工作直接與資料相關, 缺少實際資料根本是無以為繼。

以生產系統為例, 產品料表、流程定義與處置資料分由不同部門負責, 即便開發新的或調整 B2B, 缺乏這些資料還是無從下手。縱使 SA/SD 幾個單位走完, 最末還是要這些資料才好開工。

經歷過專案時程是上游廠商壓下游, 雛型只做一個段落就直接在正式環境運作 ... 邊進行、邊修程式、邊改資料的歲月真是折磨人。

前一陣子瀏覽到 http://jailer.sf.net 就看它閃耀著光輝。與資料整合(Data Integration)或 ETL 工具相比較, 這些傢私可能過大而不合用。

因為 jailer 只要關注兩件事: 首先定義表格(Tables)的相關性; 再來是抽取資料的條件。至於表格本身的定義 jailer 可抽取出來, 關連性雖然原則上可由鍵值決定, 但 jailer 也提供人工設定關連, 這點相當符合一般需求。

舉例來說 Order(1) -> Batch(N) ... 訂單關連到投產批是 1:N 關係; Batch(1) -> Job(N) ... 投產批與生產批也是 1:N 關係。其他與流程、處置、記錄相關資料零零總總, 這些關連都事先定義妥(大約有 10+ 個表格的關係)。日後只要指定投產批號, 就可拿到所有相關表格資料, 相當方便。

拿到資料的方式, 可選擇 SQL 直入測試資料庫; 或產生 Flat XML 與 http://www.dbunit.org 搭配使用。

近未來 IT 程式開發

今年初(2009)看到 InfoQ 上匯集 2008 年度文章, 其中一篇 JRuby 開發者之一 Ola Bini 先生的相關文章 "Programming languages in future systems" , 將應用系統用到的語言類型分為三層, 印象很深刻 ... 因為幾乎花整個 2008 年的時間打造這樣的系統 ... 在讀到文章之前, 做起來不盡相同。在案子完成之際, 借用相似標題記錄一下這個過程。

大多數 IT 相關系統, 都是處理資料 ... 絕大部分的人都會同意這是領域(domain)主導, 不是技術主導。在一些廠商強力運作下, 開發人員近乎被催眠在執行一些固定工作 ... 選用主流技術(沒人喜歡意外), 然後踏上規劃, 分析, 設計, 實作, 測試, ... 的履帶。

在專案執行之前, 有 IT 主要廠商已下海幾年宣告失敗 ... 就不得不審視一些基本問題:

1. 這是一個財務資訊系統 (AIS, Accouting Information System) 主要得完成 "成本系統" ... 屬資料市集 (Data Mart) 規模, 資料變異不大但資料量大。


2. 使用者都全天候使用, 需求經常性改變 ... 使用角色的人數約開發者的 5 倍。


3. 之前系統是 dbase 系, 因為原廠不支持, 決定換 Java。要接手的 IT 部門沒人有經驗 ...

審視第一點 ... 之前也習慣用 ORM, 但時薪較我日薪還高的廠商都搞不定的資料量 ... 立馬決定透過 SQL 把資料處理的問題都丟給資料庫, 捨棄物件導向方式。

關於第二點 ... 全天候使用, 帶給系統更大的壓力。而需求改變, 更是許多系統不穩定的致命一擊。但揉合這兩個問題, 使用腳本(Scripting)語言達成快速變更, 測試就交給使用者(與開發人員關係良好) ... 原則上是這樣, 還有一些方式, 下段再述。

而最末一點 ... 要從頭學習 Java, 並好好發揮不是每個人都辦得到。但主要是匯入/匯出、維護/查找資料、檢核、計算、報表、傳票 ... 這幾件事，大致就是 SQL 加上個別功能就收工。後來都是 SQL 測試完成後, 再用樣板(template)套入功能 ... 大約可完成八、九成工作。

以技術拆解來看是: SQL + 腳本語言 + 功能模組樣板 ... 有人認為 Java 可達成, 的確也是。但 Java 的問題在於, 直接放 SQL 勢必會分段(SQL 都是長得誇張), 再加上變數會更亂; 而做成獨立檔案(iBatis 做法), 或 Stored Procedure 或 View, 造成非功能性分割, 竊認為是修改應用程式不易的禍首。

使用腳本語言就一個功能一個檔, 很直覺, 清清處處 ... 開發過程曾有 SQL 部份算式要改, 還是使用者(只會 SQL 查資料)直接指出哪邊要改。

專案開始(2007年中), 就決定使用Groovy, 即便用過 jython, 當時也較成熟; 而 jruby 如日中天 ... 但偏好 Groovy 補 Java 不足的角度, 特別是支援類似 python 三引號(triple-quotes)的樣板字串(template string), 可直接寫 SQL 再加上需要的變數、函式都很容易 ... 除了 Groovy 本身支援的 SQL, 後來也嵌入EBNF 的語法描述, 再來做 DSL 處理也很方便。

回頭看打造的系統與 Ola Bini 先生宣告三層類型的對應:

1. 穩定層(Stable layer): 沒與應用太多相關, 以靜態語言打造 ... Groovy 程式的載入、執行都是用 Java 寫的。


2. 動態層(Dynamic layer): 與應用相關, 以動態語言打造 ... 功能模組樣板(匯入/匯出, 檢核, 計算, ...), 都是用 Groovy 寫的 ... 像報表小計方式百百種, 都一一解決。


3. 領域層(Domain layer): 與應用相關, 以領域語言打造 ... 使用 SQL + Groovy 方式, 大抵 SQL 能動就了結。

其文中提到的 Drools 也有用到, 因為決策表格(Decision Table)對使用者更容易使用 ... 也在此做證言 :-)

OFBiz 概覽

功能特色

1. 主要功能
   
   • 財務: 應收/付、發票、帳戶、稅務(貨品)、總帳。
   • 進銷存: 庫存、採購/銷貨、進/出貨。
   • 生產: BOM(數量)、途程(時間)、製造流程、生產計畫。
   • 其他:客戶管理、產品、人事、專案、電子商務網站、POS、BI。
2. 特點
   
   • 跨 OS, DB
   • Web 化
     
     UI 介面眾多(硬體/OS/規格), 而 web 最普遍 ... 近來 web 更接近 GUI (參考 OFBiz POS, 庫存)。
     ERP 主要在表單、報表, web 挺合適。
     在安全狀況下，隨時隨地都能掌握公司狀況。
   • 功能串接
     
     不僅提供功能項目。
     財務聯繫: 各項作業拋轉傳票。
     資訊聯繫:
     a. 從產品查詢相關訂單、存貨、銷售、生產結構。
     b. 從客戶查詢相關合約、交易、款項。
3. 使用概況
   
   • 國別 (多語言、多幣別)
     美、義、法、英、德、中、日、泰、...
     南台灣(?)
   • 專案 (擴展中)
     
     相對於許多開源 ERP 專案由特定公司掌握。
     Data Model: 有人用新技術做不同版本(Grails/ORM)。
     從 OFBiz 衍申不同專案: JIRA(開發追蹤)、Mvelopes(個人財務)、opentaps(財務)、SourceTap(客戶關係)、Neogia(製造)、...。
   
   

商業產品 vs. 開放源碼

1. 費用
   
   • 商業產品: 產品、導入(客製)、維護。
   • 開放源碼: 導入(客製)、維護(選擇性)。
2. 文件、支援
   
   • 開發方面
     
     商業產品這方面佔有優勢，不論原廠手冊、官方網站參考資料、熱門產品還有更多作者推出書籍。而較專業的在支援也採取認證措施、甚至建立跨國支援網路。
     開放源碼的資源除了提供服務廠商、網際網路(社群、佛心文件)、重要的還是源碼本身。
   • 使用方面
     
     由於 ERP 高度客製、與資料相關的特性，通常由關鍵使用者與廠商打通功能，關鍵使用者再整理出使用方法 ...
     通常僅有幾個步驟、畫面。
3. 整合一條鞭
   
   基於商務、資訊流的頻繁，將有更多功能與整合的需求。
   商業產品多是選擇其策略廠商產品、或客製化專案解決。
   由於開放源碼普及，過去關鍵技術通常都有解決方案。(CORBA)
   諸如供應鏈、規則引擎、工作流程、商業智能、... 等。

導入建議

1. 概要
   
   體驗取代按部就班。
   
2. 前置準備
   
   • 關鍵使用者(單位)
     
     考量最前面『主要功能』列表，依職權指定關鍵使用者。
     從關鍵作業出發、瞭解系統運作。
     思考按原有程式處理、或規劃調整方式。
   • 運作協調(組織)
     
     評估原有跨部門作業是否合乎需求?
     釐清部門間作業、勾稽。
     確定作業程序。
3. 階段施行模組 (製造業)
   
   • 產品、客戶、財務。
   • 進銷存、生產。
   • 其他。
   
   

小結

1. IT 系統，資料至為重要
   
   OFBiz 以資料模型為重。
   
2. Web 最為普遍的使用者介面
   
   效益保障 ... 使用者習慣、新舊機器/不同OS皆可使用。
   有 ERP 的 Web 版是另外收費的模組。
   許多 Web 版的 ERP 功能偏重特定類別(i.e. 電子商務)。
3. 導入 OFBiz 比較像擁有 ERP 的 IP 元件
   
   是可以運作的元件。
   許多 ERP 元件修改不易, OFBiz 在資料模型、Java 功能完成前提下。所有皆可透過普通編輯器修改、即時改變。
   需類似『IC 設計』的角色把元件組合成更好用。