民國 92 年 2 月 8 日

前言

所謂的資訊整合技術 早在 Win3.1 的那個年代就已經開始蓬勃的發展，時至今日各種為整合各種不同性質系統的技術，正如雨後春筍般的出現。但是可惜的是我們並不能憑藉著其中的幾項技術，就可以幫助我們整合所有的系統，所以如果你是一個系統分析師！？如果你需要為龐大的資訊系統作設計、整合時！？你就需要對這些技術作深入的瞭解。特別是現今的資訊市場跨企業、跨平台的要求又十分殷切的前提之下，我們大約也無法完全置身於這些技術之外。但是筆者在本文中並不打算介紹所有的技術，因為這些資料讀者隨便用搜尋引擎，就可以找到一大堆，筆者不用在此作狗尾續貂。筆者要介紹的則是另外一個非主流的整合技術 -- 『AP 控制器』。不過在這之前還是要先談一下目前整合技術的種類。

整合技術的分類

目前市場上的整合技術，我們以它們功能作為分類，大約可以分成資料處理類，與功能呼叫類兩種。其中資料處理類以資料庫存取為主，例如 BDE、ODBC、ADO、SQL Link 等，這些也就是所謂的 Middleware 的軟體技術，而這些技術使得資料庫軟體與我們應用程式軟體結合起來，形成所謂的『資料庫應用系統』。而另一種功能呼叫類則是以元件的型態，或者是服務的型態存在為主，例如 OLE、COM、COM+、DCOM、ActiveX、CORBA、SOAP 等。這些技術提供應用程式溝通以及跨越平台服務的機制。然而，就以上的技術而言，不管是哪一種，在使用上都有一定程度上的限制。例如 Middleware 的使用，除了要熟悉程式、資料庫語言、Middleware 本身的特性外，更重要的是必須要熟悉應用程式所使用的資料

圖 1.

圖 2.

同樣的，在功能呼叫類型的系統整合技術上也有類似的情形，從圖 2. 之上我們可以看到雖然資料驗證的部分仍然由 AP 來負責，但是程式設計師還是需要瞭解每一種連結介面的結構，甚至是作業系統底層的通訊協定。無疑的，這對於系統分析師或者是程式設計師而言都是一種的負擔。不過，這對於新的系統而言，以上兩種的整合方式也許不會造成太多的負荷。但是對於舊 有系統的整合工作而言，這種工程肯定是浩大且沈重的，因為我們必須去改寫舊有系統的呼叫方式以符合新系統架構，所以， 姑且不論這些異動會造成系統多大的影響，單就工程的大小，可能就會讓人吃不消。因此有鑑於此，為了解決這種繁瑣的問題，另一種稱之為『AP 控制器』的技術便應運而生，並且讓系統分析師於整合工作中，多了項選擇。

AP 控制器

圖 3.

何謂 AP 控制器？這是一種利用作業系統底層的核心技術所發展出來應用系統， 如圖 3. 中所示 AP 控制器在於模擬 使用者操作 AP 操作的介面的方式，將資料由某一個資料端（可以是由 AP 所產生的 XML 文件，亦或是由遠端 Web 所傳送過來的一份 XML 文件），填入另一個 可以是完全不同的 AP 的介面程式之中，並藉此達到多個系統之間資料交換的目的。 而這種類似駭客（Hacker）的作法，使得系統分析師於整合工作之時，根本不需要像前面描述的兩類技術一樣，必須顧慮到 AP 背後所隱藏龐大複雜的資料結構，以及資料驗證的工作，可以直接逕行資料的交換（因為這樣機制，這些工作還是交由原來 AP 來執行）。同時，如圖 3. 中所示由於使用 XML 作為資料交換的媒介，所以程式設計師在資料交換之前可以很容易 對資料進行篩選以及濾通的工作，這樣一來使得整合工作變得輕鬆容易許多。特別是這套系統對於以傳統方式開發的系統，如 2-tier 的資料庫應用系統，以及其他單機使用或單純應用程式之間的整合，更具其實用的價值，因為透過這透過這套系統，系統分析師就可以繼續沿用原來的系統，並且作更廣泛的變形應用。

那麼既然是模擬 AP 介面的操作方式。那我們又要如何模擬出使用者的操作動作呢？其實 AP 控制器被設計成一種稿本語言，而每一種稿本語言的命令即為模擬使用者操作的動作。所以藉由對 Script 的編輯，我們就可以開始對目標的 AP 進行模擬操作。圖 4. 表示 AP 控制器在定義模擬動作之前，事先收集 AP 中每一個操作步驟的畫面。其中畫面左方顯示 AP 控制器從使用者的 AP 擷取下來的畫面，而畫面的右邊則顯示使用者 AP 中的元件清單以及屬性。

圖 4.

圖 5.

圖 6.

圖 7.

實際應用案例

政府實施健保 IC 卡的推行，雖然對於民眾而言較以往提供了更多的便利，但是對於醫療院所而言則必須修改許多系統，如此方能配合相關的政令與作業流程。例如健保 IC 推行的第一個階段，醫療院所需要於前端配置讀卡機，以便於將卡片中的資料讀出後完成掛號，然後再將由讀卡機所產生的就醫序號、安全簽章等資訊留存，然後在於民眾就診完畢後將就診記錄、所發生的費用、醫令等資訊回傳給健保局，以便完成整個申報的作業。因此對於 HIS、CIS、RIS、PATH 等醫療資訊系統而言則必須經過一定幅度的變動，換言之就是醫療院所需要經歷一段不算小的工程才能使 IC 健保卡的業務順力推展。所以利用 AP 控制器的機制，我們可以在不修改任何系統的前提之下，順利加入健保 IC 卡的作業。

圖 8.

在上圖中畫面上方的小工具視窗，是封裝了 AP 控制器與東元讀卡機驅動程式的小工具，這個小工具可以自動從讀卡機中讀取相關卡片資料後，填入使用者醫療系統中的掛號程式，並且在隨後的醫令系統、批價系統中取得申報所需資料，最後以 VPN 上傳的方式完成每日申報的作業。

在這個案例中是個很典型繞過傳統系統整合過程的一個範例，雖然對於醫療院所而言可以依據這個工具省卻許多因 IC 健保卡政策所附加的成本（例如：系統分析、程式修改撰寫、測試、系統與健保局認證、教育訓練等），但是對於擁有紙卡健保卡的醫療系統而言，使用這套工具，無疑的是宣布系統中關於紙卡部分的功能為廢功。所以對於系統分析師，這是個值得斟酌的議題。

結論

就像文章之初所提到的，系統的整合不太可能藉助某幾項技術就可完全達到我們的需求！！同樣的，AP 控制器在使用上也有其限制，就在筆者撰寫本文之時為例，AP 控制器目前的版本暫時也只支援 DOS 與 Windows 兩種，而且對於圖形控制方面也僅限於螢幕圖形的抓取而已，同時也不具備通訊的能力。所以就整個系統整合層面而言，AP 控制器僅能算是資料交換的環節之一而已，使用者在應用上還是需要搭配其他的技術才行。例如，我們在上面的例子中所表現的就是一種資料交換應用上的變形，它不但延續舊有系統的使用壽命，更進一步藉由與 Web Service 的結合，將舊有系統的功能擴大與推廣。因此，筆者在本文結束之前，要向讀者說明的是，今日不管技術如何的推陳出新，最後還是必須由『人』來決定這些技術是否有其價值，並且強調，『技術是死的，但是創意卻是無限的。』