www.fisc.com.tw ■　41

打造企業 API服務〡資訊分享

打造企業 API服務蔡蔚華 /台灣 IBM軟體服務部工程師

一、 前言－ 企業數位轉型面臨的挑戰

金融機構業務數位轉型的推動力，主要

源於金融科技 (FinTech)的演變與競爭，如早

期核心系統的電子化、ATM的導入使用、後

有網際網路所引發的新應用等，不過「金融科

技」一詞本身的實際內涵，亦隨金融發展與資

訊科技進展而有所演化，愛爾蘭國家數位研究

中心以「金融服務創新」定義其主軸，並將其

認定為一種新型的解決方案，這種方案對於金

融服務業的業務模式、產品、流程、和應用系

統的開發來說，具有強烈顛覆性創新的特性。

在此商業思維潮流下，出現與以往科技

應用的巨大差異，即：以往是新的技術引發

新的應用，使得金融機構運作得以降低成本及

改善效率；現今是金融業務開始有新的創新商

業模式，從觀察使用者與市場著手，快速規劃

模式以建立營銷策略，並且不時檢驗以及彈性

調整，之後再選擇是否導入資訊科技來服務商

業模式。這波新的潮流並非由傳統金融巨人引

領，而是由電子商務公司或者新創公司創造出

市場機會所形成的廣泛熱議，並且引起金融領

域與資訊科技領域的注意，進而賦予金融科技

新的精神、發展思維與應用科技。

扮演組織內資訊科技舵手的資訊部門，面

臨外界的變化與典範移轉，開始著手研擬因應

的策略，下列幾點的需求議題，可帶領舵手們

思考如何協助引導業務大船駛向創新商業模式

的藍海：

(一 ) 快速打造新產品的需求：大量溝通、快

速交付軟體版本以及採行高效率與效果

佳的方法，以滿足客戶需求為任務價

值。

(二 ) 建立既有資源的重複可用性：企業原本

在異質平台間，所打造的服務導向架

構 (Service Oriented Architecture)， 實

際採用的技術可能包括XML、HTTP、

SOAP等，藉由這些開放產業標準讓資

訊環境內的各系統可以藉由各自所提供

的服務來達成互通，不需了解各自的程

式語言。

(三 ) 需快速回應市場：這個領域的市場需求

是新興的、快速發展的、變化大的，因

此在業務推展要求下需要前端應用系統

的敏捷能力，並專注於業務邏輯的開

發，以因應需求的快速變化。

(四 ) 需要較低的資訊處理成本：資訊環境整

合的一個思考點是，前端系統如何能方

便取用，且高效率使用後端核心系統的

資料與服務。

(五 ) 持續開發的業務系統功能：行動運算帶

來與使用者體驗更接近的媒介，同時也

對業務系統開發帶來快速的步調，可以

42　■ 財金資訊季刊 / No.93 / 2018.08

資訊分享〡打造企業 API服務

思考的是，若將單一包含多個執行模組

的交易切開成單一業務功能，對外提供

此項服務，這任務較小的服務應該可以

調和對於快速與持續的應用。

(六 ) 開放且符合當代趨勢的技術選項：開放

技術選擇性很多，在為創新商業模式評

估趨勢性的技術時，建議可以考慮如何

與企業內系統介接，以整體系統架構作

為選擇之準則。

二、 大型主機 API服務

在大型主機發展多項新興技術中，本文將

以大型主機應用於企業 API服務為觀點，因現

行主流行動服務與雲端服務係以 API服務為規

範，如何在企業內資訊環境建立 API服務是當

前課題、企業級設備、中介軟體亦多支援 API

服務，有取代 XML/SOAP/HTTP的趨勢，大

型主機網路設備商亦全力支援 TCP/IP網路方

向進行，企業須提早規劃運用以 API服務標準

進行應用，並整合至企業既有服務導向架構。

如何理解在刻板印象中封閉的大型主機上

應用或導入企業 API服務呢？謹以技術觀念說

明如下：

(一 ) 以「微服務」的觀點重構企業大型主機

的內部資源服務：「微服務」的概念無

明確之定義，其本身意涵是軟體工程發

展下的一種架構思維，後由社群、資訊

專家、資訊廠商發展至完整體系、工具、

技術、架構，「微服務」是一種架構風

格，開發單一應用程式時將之視為一組

微小服務的途徑，每個微小服務有自己

的執行流程、具備獨立業務任務、有透

過完整部署工具達到獨立部署的能力，

並與其他微小服務在輕量級機制下互相

溝通的能力；此框架下分布於最少集中

式平台 (也就是分散式 )－可以用不同

程式語言開發以及採用不同資料儲存技

術。

(二 ) 建立大型主機的介接API(如：JSON與

RESTful)：API服務已經有眾多工具與

技術框架來支援微服務的實現，其基本

的技術結構之一為JSON資料格式、另

一為RESTful架構風格，前者定義資料

規則與結構，後者基於HTTP環境的傳

遞訊息協定，基本模式包括：GET(查

詢 )、POST( 新 增 )、PUT( 修 改 )、

DELETE(刪除 )。主機交易電文轉換成

JSON的特性包含可驗證的資料結構，

可避免垃圾訊息進入主機、交易內容的

封裝性，只開放出需要的輸入欄位，避

免不正確的輸入、編碼轉換的支援，

提供Unicode的 JSON資料，工具支援

EBCDIC與Unicode之間的轉換，範圍

涵蓋主機造字區。利用RESTful模式將

主機交易設計出查詢、新增、修改、刪

除的用途，提供開放API的安全防護，

並可配合授權機制針對不同使用者設計

不同權限。另在HTTP環境下，配合企

業已有成熟的網路防護機制，可以建構

出符合安全規範的運行環境。

(三 ) 完全的TCP/IP環境，減少設備負擔以及

協定轉換之成本：目前與大型主機網路

通訊介接的傳統介面的成本包括維護費

用、系統提升額外費用或介面轉換新式

介面費用，若是行經網路骨幹為TCP/IP

則另需使用SNA模組，雖有維護費用與

額外費用，但利用TCP/IP環境運行主機

應用交易則可重複利用現有資源，採分

階段轉換介面以逐漸汰除使用傳統技術

www.fisc.com.tw ■　43

打造企業 API服務〡資訊分享

之衍伸費用。

(四 ) 開放的標準可以引導創新應用：大型主

機上的核心系統一直扮演著幕後穩定的

交易系統；另一方面，在穩定的框架下

在實現創新應用時有增加其執行之複雜

度。然而，開放標準生態圈正伴隨著金

融創新、科技新應用而活絡，在資訊科

技市場上具有相當大的影響力，將大型

主機連結開放生態，期能重新扮演引導

者的角色。

三、 API服務優點及維運架構

實務上，推動 API服務對於前線單位在選

擇資訊環境，可帶來的解決方案呢？在 2017

台灣 IMS技術論壇中，財金公司提出以下觀

察點，描述企業在當前技術架構風格選擇上的

參考：

(一 ) 不用撰寫處理專屬通訊層的程式碼，因

業務邏輯與通訊層程式碼在架構設計上

有困難度，而且錯誤處理程序繁複，不

易維護，且人力交接成本也高。

(二 ) 建立企業內各節點之共通語言與協議，

避免專屬規格山頭林立與維護困難：一

個業務就利用一種規格，資訊管理成本

高，開發語言不同也無法互通，而且資

料交換上也需準備自行開發轉換程式碼

或者額外中介技術來做轉換。

(三 ) 採 用 HTTP/HTTPS 的 通 訊 協 定、

RESTful規範以及 JSON資料格式，為

業界開放標準，坊間資源與工具多，在

HTTP的架構下網路拓樸在業界已相當

成熟，開發 JSON與RESTful的API工

具，包括視覺化工具、測試工具、資料

結構驗證、文件製作自動化等資源相當

多，並且大多不需購買完整版本的工具

即可滿足。

(四 ) 在大多數商業軟體與開源軟體均採取發

展API服務的趨勢下，資訊教育市場提

供相當多的資源學習，人力資源供應也

將會比較充足。

以往設計異地中心時的考量是當主中心發

生災難時可以在一定時間內接管業務系統，並

以減少業務服務中斷時間、降低營運損失為主

軸。基本上，異地中心的系統為備用，平時

是不提供業務服務，僅執行異地資料抄寫與同

步。以資產利用的角度觀之，若能「活化」異

地資產，使異地中心分擔部分業務服務工作，

可將原本負責備援單一任務之設備也可執行業

務交易，成為具備生產力之一環，創造其價

值。

大型主機異地備援架構傳統設計，為能夠

在最短時間以異地中心恢復業務服務為目的，

工作執行的主要考量如下 (圖 1)：

˙ 異地中心平時接收主中心透過資料抄寫傳

送的資料，以與主中心資料同步更新。

˙ 在企業內部網路的部分，各業務系統之節

點與大型主機核心系統的連結主要是建立

在 SNA骨幹網路上，其通訊協定基本上要

求所有節點都必須明確在網路上定義，成

為網路上一節點之後，才可與大型主機核

心系統溝通。

˙ 在企業對外網路的部分，通訊協定與應用

程式介面的種類十分多樣化，一般可能是

以 TCP/IP協定自訂訊息方式連結業務系

統，也可能與大型主機核心系統直接連結，

或是中間經過一套專屬介面程式或中介軟

體做跳板。

如何讓業務交易在雙中心的架構下成為可

行，就須考量 SNA節點定義如何管理以降低

44　■ 財金資訊季刊 / No.93 / 2018.08

資訊分享〡打造企業 API服務

圖 1　傳統備援架構與交易連線的簡單示意圖

複雜性、使用 SNA連結大型主機核心系統的

業務系統在程式面是否可以支援交易工作量分

散、外部單位的連線是否為持續連線、程式通

訊介面是否符合雙中心的規範。

以企業 API途徑的方法論來說，將大型主

機核心系統導入 API服務 (如圖 2)，在雙中心

架構下可具備以下特點：以 TCP/IP與 HTTP

協定為骨幹，原本在主中心與異地中心的網路

環境不論對內或對外已具備支援的能力，容易

導入、負載平衡設備放在主機前端可以具備工

作負載平衡、依據業務種類或者優先權決定連

結路徑、RESTful/HTTP之規格使得容錯移轉

容易實現，應用程式不須處理通訊程式接續的

問題，可以依據網頁程式設計方法來考量、搭

配安全閘道讓其他節點連接主機進行交易時可

以具備連線加密、訊息格式驗證、偵測阻斷服

務攻擊、身份驗證等安全策略能力。

在此小結，將傳統主機核心系統的交易轉

換成 API服務，有助於在設計雙中心營運模式

時降低交易應用程式、系統架構與網路環境三

者之間的複雜度。

圖 2　API服務架構下雙中心交易的簡單示意圖

www.fisc.com.tw ■　45

打造企業 API服務〡資訊分享

四、 導入 API服務的作法及效益

如何導入大型主機 API服務？我們期望

轉換傳統的交易成本不需太高，所謂較低成本

在於主機核心程式碼不須配合修改，或者修

改部分很少且能掌握，從 SNA轉換 RESTful/

HTTP協定的系統管理工作，可以明確定義並

讓主機系統人員理解與學習，目前主機核心程

式碼多為商用高階語言 (COBOL與 PL/I)，將

其資料模組轉換成 JSON之資料結構，作法

須使用自動化工具以方便轉換，且支援編碼互

換 (EBCDIC與 Unicode)。

目前大型主機上 API服務的中介軟體為 z/

OS Connect Enterprise Edition，而以下就主

機應用系統 IMS交易轉換說明具體實施作法：

(一 ) IMS轉換API服務核心程式不變

IMS傳統上接受之訊息格式係由位元組

所組成的字串，並採用 EBCDIC編碼之交易

內容。IMS收到交易後，將訊息依據交易代

碼 (Transaction Code)交由指定的程式執行。

z/OS Connect Enterprise Edition提供一套執

行物件 (Runtime Instance)，即獨立的中介軟

體在 z/OS上執行，於 IMS前端加上一層 API

服務，讓外部程式在呼叫 IMS交易時，採用

JSON格式並以 RESTful/HTTP協定介面傳

輸，此服務層將 JSON訊息轉換成 EBCDIC

編碼的格式送進 IMS。之後與傳統途徑一樣，

IMS進行交易分配與程式執行。程式執行完畢

回傳訊息給呼叫者，z/OS Connect Enterprise

Edition亦會將 EBCDIC編碼的格式轉換成

JSON格式，讓外部程式可以處理，如圖 3顯

示上述交易流程的簡單示意圖。

(二 ) IMS API服務轉換快速：

基礎架構的轉換並不需大幅更動 IMS

系統設計；原本 IMS 使用者已具備 TCP/

IP 的連線方式，主要是應用在跨行交易

上。故在實際環境面，IMS 所需的 OTMA

(Open Transaction Manager Access) 與 IMS

Connect的實作設定均已定義，而增加的元

件則為 z/OS Connect Enterprise Edition，於

與 IMS相同之主機內部或者因應 TCP/IP協定

所開設的獨立主機上執行。在開發服務上，z/

OS Connect Enterprise Edition包含圖形化介

面，可以用工具讀取 COBOL、PL/I 程式所定

義的資料模組，並將其轉換為 JSON格式以及

編碼轉換，工具亦提供資料結構對應的功能，

可自動產生 JSON/API服務的規格文件，並可

透過工具顯示與執行單元測試。圖 4顯示上述

基礎架構與服務開發的簡單示意圖。

圖 3　前端外部程式透過 z/OS Connect Enterprise Edition呼叫 IMS交易流程簡單示意圖

46　■ 財金資訊季刊 / No.93 / 2018.08

資訊分享〡打造企業 API服務

圖 4　API服務基礎架構與開發方法的簡單示意圖

五、 結語

英 國 政 府 科 技 辦 公 室 (Government

Office for Science)提出金融科技推展上極

為重要的四大關鍵領域中，其中之一的分

散式系統 (Distributed System)、行動支付

(Mobile Payment)與 P2P應用 (Peer-To-Peer

Applications)在與金融機構內的資訊系統整合

有相當大的關係。在此謹以 IBM公司與財金

公司合作之 IMS API服務驗證專案的執行成果

作為本文之總結。

˙ 藉由提供 API 服務，將傳統 IMS 3270

MFS文件介面改由更彈性的使用者介面設

計架構所替代。

˙ 取代傳統組合語言撰寫之訊息轉接程式，

以降低維護組合語言成本。

˙ 在撰寫連接 IMS的程式時，不需處理 IMS

Connect與 OTMA header，用標準 API即

可快速打造應用系統。

˙ 利用 TCP/IP網路架構與 API服務可以活

化異地備援中心資源，讓交易工作量分散

處理於兩地。

˙ 讓新進資訊人員藉由製作 API服務學習核

心系統，進而結合兩者背景。

從上述實作後的效益評估發現以下幾點效

益，可供參考：IMS應用環境維護的成本降低、

建立備援環境活化機制，朝多中心目標前進、

讓外部系統程式設計變得更容易、人力活用。

相呼應的是著名研究機構 FORRESTER

也針對金融服務行業如何利用 API服務，提出

以下四個關鍵應用領域與機會：

˙ 企業內部的 API服務可以增加組織運作彈

性、效率與效能。

˙ 企業與企業間的 API服務，可以優化相互

間業務處理與建立共贏合作關係。

˙ 企業對外的 API服務擴展市場機會，並採開

放性的作法發展各種金融服務的創新應用。

˙ 金融產品的 API服務可在生態圈中與之連

結與形塑，來提昇自身價值。

未來期待大型主機上的核心應用能整合至企

業 API服務，提供完整的解決方案，讓核心系統

在穩定平台上執行，並具備開放接軌的能力！

※參考文獻 /資料來源：1. IBM公司。2. FORRESTER研究機構。