Oracle與PHP執行個體開發Myers訂單跟蹤系統

關於 PHP/Oracle 開發模型如何在Myers Internet縮短應用程式生命週期的案例研究。

對於主要由應收款業務模型驅動的公司而言，其核心的業務功能之一是輸入、跟蹤和記錄訂單。在這方面比較出色的公司可以伸縮它們的機構，並提高它們的利潤，而不會遇到基礎架構的限制。當訂單處理很麻煩、容易出錯或不一致時，公司將因為直接的成本和降低的生產效率而蒙受經濟上的損失。

在我的公司 Myers Internet，核心的業務事項圍繞著建立客戶基礎，為 Myers 提供持續的服務並協助它在客戶問題出現時解決問題。公司正使用許多不同的系統來處理訂單輸入和實施周期的各個方面。這些系統既不是彼此整合的，也不具備確保每一份訂單都得到正確記帳的機制。

Myers 訂單跟蹤系統 (MOTS)

就像其它許多機構一樣，Myers 從一個小型公司成長為一個中型公司，同時在它的整個成長期間始終保留了相同的過程和系統。大多數這些過程在建立時，所有的交易處理都通過電子郵件、紙質記錄和實地拜訪來人工地完成。5 或 6 年前，Myers 的一個工程師利用 Allaire 的 Cold Fusion 和一個 Microsoft SQL Server 資料庫組裝了一個系統來跟蹤訂單實施，這個系統稱為 MOTS （Myers 訂單跟蹤系統），它允許銷售和帳目管理部門輸入訂單，然後由支援、工程、設計、資訊系統和會計部門實施這些訂單。雖然這個系統是向前邁進的重要的一步，但它仍然留有許多人工的步驟，並且沒有和任何其它的業務系統整合在一起。

大概在同一時間，還建立了一個系統，在這個系統中客戶和銷售代表可以線上訂購 Myers 網站的產品。這個系統可以建立新的 Web 網站，並計算提供的 Web 網站程式包的安裝和重複性費用的總和。然後它寄送電子郵件給各個部門，各個部門可以將訂單輸入到 MOTS 中，並在帳目管理系統中建立記帳資訊。

體繫結構障礙

這種類型的體繫結構飽受幾種系統問題之苦。在 Myers，較明顯的問題之一包括啟動訂單跟蹤所需的人工資料輸入，以及作為這種人工過程的結果而產生的錯誤。另一個問題是公司中的訂單輸入、訂單跟蹤和記帳系統之間的脫節、訂單丟失、資訊遺漏和其導致的錯誤。

另一個僅偶而出現的問題是 MOTS 系統本身有內在的缺陷。由於編寫 MOTS 的方式，可以輸入沒有部門分配資訊或者丟失了部門分配資訊的訂單。當這種情況發生時，訂單最終將在系統中丟失。當訂單丟失時，準確、及時的記帳就更難實現了。

隨著業務的成長，體繫結構中的缺陷變得越來越明顯，並且隨著客戶和訂單數量的增加，丟失和錯誤輸入的訂單出現的頻率越來越高，從而給公司收入帶來了難於估量的影響。此外，人工輸入的資料的數量導致了延遲和處理效率低下。

由於在實施機構內對收入的影響加大和效率降低，很明顯必須要有一個替換系統來將一切聯絡起來，並提高效率和降低錯誤率。舊系統圖示如下。

　

圖 1：舊的系統體繫結構

該圖顯示了需要人工資料輸入的所有地區。由於這些系統都不是整合的，所以資料丟失或失真的可能性非常大。全域需求馬上變得明顯起來。

訂單系統需要直接和實施跟蹤系統聯絡起來。該系統需要安全保護來防止訂單在未經處理之前脫離系統。需要保持精確性，以確保準確的記帳和正確的訂單實施。系統需要使內部成本最小化。所以，要達到那個目的，需要快速地建立系統，但系統必須擁有完整的功能。

雖然一個好的訂單輸入和跟蹤系統可以協助降低成本，但它本身並不創造收入。

深入結構

在開始模式設計之前，需要解決一些基本的體繫結構問題。第一個底層的技術需求是系統必須可配置，且無需額外的編碼。本質上，這意味著需要把工作流程嵌入到資料庫中，而不是用解釋/處理代碼來進行寫入程式碼。第二，資料庫需要包含足夠的資訊，以便能夠表現訂單輸入介面的主要（和可更改）的方面以及實施處理。

在努力解決上述問題的過程中，該系統逐漸適合於兩個部分 — 訂單輸入和訂單跟蹤，並在兩者之間提供了明確定義的聯絡。訂單輸入系統需要知道如何用準確的產品代碼、折扣和定價條款來表示訂單。訂單實施系統需要知道如何跟蹤各種類型的任務、相關的作業和各個部門，以處理和記錄每份訂單。最後，需要定期和可預測地把訂單轉化成實施作業。下圖顯示了目前存在的新系統的結構。

　

圖 2：新的系統體繫結構

該圖顯示了通向新的訂單系統的所有資訊路徑，新的訂單系統位於後端的門戶管理網站。所有的初始資料輸入都僅一次性完成，並且只需要每個小組在處理的各個階段驗證資料。通過引入從訂單系統到帳目管理系統的自動資料轉送，至關重要的資料轉送的另一個主要的領域也變為自動化。

依賴 PHP

在純技術的層面上，早期決定使用 PHP 作為主要的開發語言和 Oracle 作為系統的資料資訊庫，這有幾個主要的原因。首先，Myers 現有的後端門戶幾乎完全是用 PHP 根據一個現有的 Oracle 資料庫編寫的，這消除了一個產生不相容性的潛在來源。這還意味著要建立這個新的系統，Myers 可以利用自身的能力，這些能力建立了現有的後端門戶。

第二，實驗測試顯示，與其它開發語言相比，PHP 提供了一個比較高的效能水平。因為 PHP 是作為一個動態載入的資料庫駐留在 Apache 伺服器內部的，所以每一次與系統串連都無需額外的啟動時間。此外，PHP 最佳化的改善（通過 Zend 項目）意味著在代碼內部執行的一般操作不會明顯變慢。最後，為 PHP 編寫的 OCI 介面模組是用 C 代碼編譯和最佳化的，這使得訪問 Oracle 資料庫非常高效。

第三，我們瞭解到因為 PHP 代碼將其自身嵌入到了 HTML 環境中，所以對於設計人員和編程人員而言，建立協作使用者介面功能代碼變得更加自然。雖然最後這個特性其它的伺服器端指令碼語言也具備，但 Myers 發現 PHP 更不可能帶來開發人員和設計人員之間的衝突。此外，PHP 的文法和提供的程式碼程式庫意味著它可以做它需要做的所有事情。

最後，將所有代碼嵌入到 HTML 程式碼中的另一個好處是，僅需要對標準文字檔進行修改控制就可以控制原始碼。我們用 CVS 作為它的標準修改控制系統。因為 PHP 代碼不一定要用某一種方式進行編譯，所以建立系統的一次“編譯”僅涉及到從資訊庫中檢索文本原始碼檔案，然後把它們放到 網頁伺服器上。這意味著我們可以使用 CVS 中的控制機製為它的測試和生產環境發布增量的 bug 補丁，而無需建立複雜的編譯系統。

設計模式來支援可重新設定性

下面的基本模式示意圖顯示了訂單系統是如何構建的。兩種主要的模式都分為原型表和事務表。無論何時當業務情況發生變化時，原型表都允許重新設定系統，而無需重新編碼。事務表包含實際客戶訂單的訂單詳情和作業詳情。

　

圖 3：基本模式示意圖

圖 4：基本模式示意圖

這些模式示意圖看起來很複雜，當然，它們的確很複雜。不過，如果把它們分開，使得只出現原型表（以 _def 結束的表），那麼該體繫結構的基本結構就變得很清楚了。訂單由行組組成，這些行組包括詳細資料、訂單行或兩者。訂單行可以隨意地建立作業，作業由一個工作順序組成，並且包含幾條詳細資料。必需要為各種任務輸入這些詳細資料。任務出現在不同的隊列中，這些隊列可以由不同部門的特定使用者進行訪問。

為了檢驗系統，策略是分階段將訂單系統原型化。系統要檢驗的第一部分是它單獨從訂單原型表中建立一份清楚的訂單的能力。一旦完成了最初的模式定義，訂單產生器就是原形化的系統的第一個可視部分。

為構建和配置這個系統而組成的小組除含受這個系統影響最大的各個部門的經理之外，還包括三個開發人員。開發人員的分工分別為：構建配置功能、顯示功能和交易處理功能。在整個最初的構建周期內，部門經理提供了關於介面（這些介面使使用者能夠輸入和處理資料）類型的有價值的反饋。

利用 PHP 繪製使用者介面

要原型化的初始訂單是基本的 Web 網站訂單，在 webwiz.myersinternet.com/ 上提供。得到的訂單是由一個開發人員用 PHP 在三天的時間內建立的。如果訂單原型定義 — 依靠只在資料庫和瀏覽器之間的一層 PHP 代碼，就能夠完全定義訂單輸入的外觀和行為，那麼在資料庫設計中需要一定程度的折衷。為此，諸如訂單行組之類的結構必須支援兩個用途：(1) 在輸入表單上提供可視化的區分，以使類似的產品組可以繪製在一起 (2) 從功能上對類似的商品分組，比如說打了一定折扣的商品，或一個選項列表，從中可以作出唯一的選擇。

因為 PHP 是開發語言，所以原型組建相當快速，從而可以快速地完成模式所需的修改並且為表單產生器重新編碼（一前一後）。此外，因為模式是考慮了繪製的使用者介面而設計的，所以當在原型構建過程中出現新的可視化需求時，可以容易地進行模式修改和改編。產生的表單外觀與下圖相似：

　

圖 5：訂單產生

建立一個功能完全的系統

在提供訂單之後，需要使它變得功能完全。首先，系統需要儲存在訂單中輸入的用於交易處理的訂單資料。第二，填寫訂單的人需要能夠根據進行中中的訂單資料來填寫。