WebSphere Portal 配置向導的背景介紹
WebSphere Portal 裡的配置 向導一向是用戶所喜愛的工具，它可以幫助用戶簡化配置過程，原本需要用戶自 己手工修改配置文件中的大量配置參數，現在只需要跟隨配置向導一步一步填寫 簡單的信息就行了。簡單來說配置向導主要是從幾個方面來簡化配置流程的：
針對用戶所要完成的任務，配置向導將此任務所有相關的配置參數都挑選了 出來，並按照它們之間的關系分組放在不同的步驟中。這樣避免了讓用戶自己從 紛雜的上百個配置參數判斷哪些參數是需要修改，哪些參數是無關的不應該修改 。使用了配置向導之後，用戶從此不用再擔心漏填了必備參數。
配置向導會根據用戶在上一步填寫的信息來過濾下一步裡所需要填寫的配置 參數。例如，如果用戶在數據庫遷移的任務中選擇了目標數據庫類型是 DB2，那 麼接下來的步驟中就會將其他數據庫類型的配置參數都過濾掉，無需用戶填寫。 並且，配置向導還會針對每個配置參數提供默認值以及幫助信息，方便用戶來填 寫。
配置向導的運行環境介紹
在 WebSphere Portal 8.0 之前的版本裡， 配置向導是一個運行在 WebSphere Portal 所在的服務器上的 Java 客戶端程序 ，是基於 InstallShield 安裝配置向導來實現的，主要提供了對數據庫遷移以 及配置安全性任務的支持。在 WebSphere Portal 8.0 裡，配置向導有了全新的 升級，不僅僅運行方式上從 Java 客戶端程序轉向了基於 Dojo 的 Web 應用， 而且擴展性也大大增強，所覆蓋的配置任務也因此可以極大豐富了。我們知道， Web 應用自然是運行在 Web 服務器上的；同樣，我們的配置向導也是運行在 WebSphere 這個應用服務器上。有人可能看到這裡會有疑問了，在常用的配置任 務中，經常需要重啟 WebSphere 應用服務器來使修改的配置生效（例如，在給 WebSphere Portal 配置安全性時，就需要重啟 WebSphere 才能使新的安全性生 效），那麼在這種時候，我們的配置向導不就被中斷了麼？我們通過配置向導所 執行的配置任務從而也就被中斷了，從而無法完成了，不是麼？還有的人可能會 有其他的擔心，在集群環境中每個 WebSphere 節點都是由部署管理器 （Deployment Manager）來管理的，每個 WebSphere 自身的管理控制台是無法 訪問的，那這時候自然配置向導也就無法訪問了，這種情況該怎麼處理呢？
針對上面的問題，我們來了解一下配置向導的體系框架。首先，它是作 為集成解決方案控制台（Integrated System Console，縮寫為“ISC”）的一個 擴展模塊部署在 WebSphere 應用服務器上面的。其次，我們在 WebSphere 裡為 配置向導創建了其專屬的概要（Profile），這個概要的名字就叫 "cw_profile"。這個概要的運行及它的安全性是完全獨立的，因此更 改 WebSphere Portal 的安全性等配置任務完全不會影響到這個概要的運行，我 們的配置向導因此也就始終保持運行，能夠完整的完成各種配置任務了。最後， 雖然配置向導缺省部署在 WebSphere Portal 所在的機器上，但是我們依然能夠 將它部署到其他機器的 WebSphere 或者部署管理器上。這樣，我們保證了配置 向導的完全獨立運行，不受任何其他因素的影響。關於如何將配置向導部署到其 他機器的相關步驟可以在 WebSphere Portal 8.0 的信息中心中找到，這裡就不 贅述了。
圖 1. 集成解決方案控制台中的配置向導
配置向導的三大全新功能
在全新的配置向導中，所包含的功能也比之前版本有了極大的改善。簡單來說可 以分為三大新功能：從 Web 界面運行 ConfigEngine 任務，查看系統日志，工 作流程。前兩個功能可以看作是對現有 ConfigEngine 的功能補充，最後的工作 流程功能才是配置向導的重點所在。下面我們來逐個看看每塊功能中包含的內容 。
從 Web 界面運行 ConfigEngine 任務
我們知道，WebSphere Portal 中的所有配置任務最終都是通過 ConfigEngine 這個命令行工具來執行 的，而所有的配置任務也都是基於 ConfigEngine 來實現的 ANT 任務。通常來 說我們都是通過登錄安裝有 WebSphere Portal 的遠程機器，在上面通過命令行 方式運行 ConfigEngine 任務的。現在，配置向導移到了 Web 端之後，運行一 些簡單的 ConfigEngine 任務完全可以通過配置向導的這項功能從 Web 端來提 交，免去了登錄遠程機器的過程。
圖 2. 從 Web 界面運行 ConfigEngine 任務
從上圖可以看出，在 Web 端運行 ConfigEngine 任務是十分簡單的，主要需要用戶提供希望運行的任務名以及相 關的特性值即可。這項功能其實更主要的是提供了一種替代命令行的運行方式， 而不是繼承以前版本中配置向導的功能。真正強大的向導功能將會在後面的工作 流程小節中詳細介紹。
在上圖中同樣可以看出，我們在允許用戶點擊“ 立即運行任務”之前會在後台檢查 ConfigEngine 的狀態，這是因為 ConfigEngine 不支持並發執行多任務，所以我們需要避免用戶提交了任務之後 才發現 ConfigEngine 已處於運行中狀態。如果當前 ConfigEngine 處於可用狀 態，那麼用戶就可以立即運行任務，在任務提交後，頁面將會實時顯示後台的運 行進度及日志中的輸出結果直至任務運行完畢。在這裡同時提供了其他兩個選項 ：“首選項設置”和“創建腳本”。“首選項設置”主要是可以讓用戶修改缺省 的 WebSphere Portal 安裝路徑，放置臨時文件的路徑等信息。而“創建腳本” 則提供了打包功能，將用戶輸入的任務及特性值生成可執行的腳本文件和屬性文 件並提供下載。用戶可以保存這些打包的文件，在需要運行的時候只需要簡單的 運行一下裡面的可執行腳本文件即可，而無需重新輸入這些任務名及特性值。當 ConfigEngine 被鎖定的狀態下導致無法立即運行，或者將來希望重復利用這些 腳本的時候都可以使用這個功能來延時完成配置任務。
需要注意的是， 從 Web 端運行 ConfigEngine 任務僅限於配置向導與所管理的 WebSphere Portal 安裝在同一台機器上。如果配置向導被部署在了其他機器的 WebSphere 或者部署管理器上，是不能使用這項功能的。
系統日志管理功能
有過 ConfigEngine 和 WebSphere Portal 使用經驗的用戶可能知道，一般來說 有兩個日志文件在我們的配置管理過程當中十分重要：SystemOut.log 和 ConfigTrace.log。SystemOut.log 文件包含了 WebSphere Portal 自身輸出的 各種日志信息；而 ConfigTrace.log 則包含了 ConfigEngine 運行中輸出的所 有日志信息。在新版本的配置向導中，我們提供了一個強大的故障診斷工具，此 工具使故障診斷工作 不再令人生畏。 日志查看器在易於追蹤的界面中選擇想要 查看的日志文件， 在此界面中，您只需進行一次單擊即可找到日志文件中的錯 誤。需要注意的是，這裡的日志文件裡不止包含了通過命令行方式執行的 ConfigEngine 所輸出的日志，也包含了通過 Web 端執行 ConfigEngine 任務和 後面將要介紹的用工作流程執行時所輸出的日志信息。
圖 3. 使用系統 日志管理來查看 ConfigTrace.log
從上圖中可以看出，以前查看 ConfigTrace.log 時需要在龐大的文件中手工定位要查找的任務，逐行找出報錯 的地方。現在所有執行過的任務以列表的形式顯示，而且執行成功與否一目了然 ，很方便就能找到出錯的日志信息。
強大的工作流管理功能
如果 說以上兩個功能都是對現有 ConfigEngine 功能的有效補充，那麼工作流程則是 配置向導的拳頭功能了。什麼是工作流程呢？簡單來說就是如果有一個或多個配 置任務，組合起來能達到最終的配置效果，我們就可以把它組織成單一流程。這 樣可以節省您的寶貴時間，並可以使用現成的工作流程為配置方案生成定制腳本 。一個典型的例子就是為 WebSphere Portal 搭建集群環境，這個工作流程中包 含了很多步驟，需要執行多個 ConfigEngine 任務才能夠完成集群的搭建。在 WebSphere Portal 8.0 的配置向導中，缺省包含了如下這些工作流程。
圖 4. 配置向導中自帶的工作流程列表
工作流模板是如何簡化用戶配置流程的
讓我們暫時跳過工作流程是如何創建的，先來看看工作流程是怎麼通過 配置向導一步一步從而簡原有配置過程的。首先，所有的工作流程都可以看作是 一個模板，僅僅包含了框架和缺省值，用戶需要定制工作流程，填入符合自己環 境的各種數據來生成最終的工作流程實例，最後創建出此工作流程實例的腳本， 指示信息以及所有經過更新的屬性文件。用戶只需要下載這個打包好的文件，按 照裡面提示信息的指導，逐個運行裡面的腳本就能自動完成配置過程，無需再手 工執行 ConfigEngine 命令或者編輯配置文件。
我們可以看一個創建靜 態集群環境的工作流程例子，最終的生成結果如圖五所示。用戶只需要打開 CreateStaticCluster.html，根據裡面的指示，在相應的節點上逐個執行 Scripts 文件夾中包含的腳本文件即可。
圖 5. 工作流程實例生成的腳 本，指示信息以及所有經過更新的屬性文件
從一個工作流程模板到最終工作流程實例 生成的腳本文件，一共需要四個步驟 , 如圖六所示：
圖 6. 定制工作流 程的四個步驟
配置向導會指引用戶從步驟 1 一步一步 前進直到步驟 4 生成最終的腳本文件。
設置條件：在步驟 1 中的條件包括兩類，一是目標運行平台是何種操作系統 ，另一種就是工作流程中包含的各種條件參數。設置條件主要是為了過濾掉後續 步驟中無關的配置參數。例如，在數據庫遷移的工作流程中，如果用戶在步驟 1 裡對目標數據庫類型這一條件參數選擇了 DB2，那麼在後繼步驟中其他數據庫類 型的相關配置參數就會被自動過濾掉，不會顯示給用戶造成無謂的干擾。我們在 前文中提到過，配置向導可以和 WebSphere Portal 不運行在同一台機器上，因 此在這裡我們需要知道目標平台的操作系統類型從而最終生成正確的腳本類型（ .bat 文件或是 .sh 文件）。
定制工作流程：經過了步驟 1 的過濾，在步驟 2 裡將會分組顯示出需要用 戶按照目標環境做出相應修改的各種配置參數。而且配置向導為其中的配置參數 都提供了詳細的幫助信息來幫助用戶填寫，例如缺省值，有效格式，范例等等。
檢查值：在前兩步完成之後，在這裡我們將所得到的各種配置參數進行各種 有效性驗證並提供修改的機會。
創建工作流程：在這裡用戶可以對工作流程實例生成最終的腳本，指示信息 以及所有經過更新的屬性文件。用戶拿到這些文件之後就可以在目標機器上按照 指示信息中的步驟來執行相應的腳本文件就行了。
圖 7. 提供了詳細幫助信息的配置參數頁面
工作流中的各種術語介紹
看上去 很簡單，不是麼？其實簡單的工作流程背後有許多東西值得注意。其中就包括配 置向導中涉及到的各種術語，掌握了這些術語及它們的作用可以讓我們更好的了 解配置向導，而且這也是將來編寫你自己的工作流程時必須掌握的概念：
工作流程（Workflow）：一個工作流程可以包含多個任務，可以是 ConfigEngine 的任務，也可以是其他類型的任務。並且，工作流程是可以嵌套 在另一個工作流程中的。例如，在創建集群環境的工作流程中其實嵌套了多個其 他工作流程，包括有：安全性配置的工作流程，數據庫遷移的工作流程，重啟 WebSphere Portal 的工作流程等等。當用戶定制創建集群環境的工作流程時， 它所嵌套的子工作流程會被自動包含進來，用戶可以一次性就生成最終想要的所 有結果。
工作流程定義（Workflow Definition）：工作流程定義是作為模板提供給用 戶定制的，其中包含了所需的任務以及相應的配置參數和它們的缺省值。
工作流程實例（Workflow Instance）：工作流程實例是經過用戶定制之後生 成的，它包括了工作流程所需的任務以及經過用戶修改過後的配置參數值。用工 作流程實例就可以生成我們所需的最終腳本以相關文件。
工作流程步驟（Workflow Steps）：工作流程中所包含的任務。按照類別又 可以分為三大類：
ConfigEngine 步驟（ConfigTask Step）：這類任務對應的就是執行一個 ConfigEngine 命令，這也是最常見的任務類型了。
其他命令步驟（Command Step）：這類任務對應的是在命令行裡執行其他命 令，例如在配置過程中我們經常需要手工執行“ulimit -n”的命令來修改底層 操作系統的最大打開文件數，工作流程中自然也需要有地方來包含這類任務。
消息步驟（Info Step）：這類任務主要包含一些需要用戶手工完成的步驟， 例如從一台機器拷貝一些文件去另一台機器。
配置參數（Parameters）：配置參數包括了兩大類型，一類是執行 ConfigEngine 任務時所需要的存儲在 wkplc*.proerties 裡面的配置參數。另 一類就是供工作流程內部使用的配置參數。
條件參數（Condition）：條件參數是非常有用的，它可以作用在很多地方， 包括工作流程，工作流程步驟以及配置參數上。當用戶定制工作流程時，系統會 逐一判斷此工作流程中所有的條件參數是否滿足，如果不滿足就將它對應的對象 移除出去。之前我們提到過的移除不相關配置參數就是通過條件參數來實現的。
工作流程存儲庫（Workflow Repository）：工作流程存儲庫是一個 XML 文 件，其中存儲了當前包含的所有工作流程模板及所有的配置參數。在 WebSphere Portal 的信息中心中可以找到詳細的信息來恢復或者重建這個存儲庫。
看上去這些術語有些復雜，但這些概念對於普通用戶來說是完全透明的，用 戶完全能夠只通過前面介紹的簡單四步驟來定制工作流程就能夠完成日常所需的 工作。而對於 WebSphere Portal 開發者和服務團隊來說，掌握了這些概念能夠 有利於他們更好的把握工作流程的內部結構，創建出高效便利的工作流程。
與他人分享工作流程
我們之前提到過新版的配置向導提供了強大 的可擴展性，其體現就在於我們將不再僅限於 WebSphere Portal 缺省提供的這 些工作流程，用戶可以創建符合自己需求的新工作流程。並且，配置向導還提供 了導入和導出工作流程的功能，這樣用戶可以將自己創建的工作流程與其他用戶 分享。所謂眾人拾柴火焰高，這將極大豐富可用工作流程的種類和數量，避免了 重復工作並且能極大簡化日常所需的配置工作。
總結
WebSphere Portal 8.0 的配置向導作為一次全新的升級，從傳統的 Java 客戶端程序轉向 了 Web 端應用，從多方面有效補充了原有 ConfigEngine 的功能，並且引入了 工作流程來簡化了日常配置工作所需要的工作，用戶還可以導入和導出工作流程 並與他人進行分享從而擴大工作流程所覆蓋的應用范圍。相信在使用了新版的配 置向導之後一定會大大提高用戶的工作效率 , 簡化配置流程 .。
