2000年4月26日 星期三

自動訊息發送系統

專案目的
「自動訊息通知系統」建置的主要目標在於提供各種客戶通知 ( 包括一般交易、對帳單及交易策略通知 ),可透過多管道 ( 手機簡訊、傳真、E-Mail、HTTP、FTP )、多收訊人等方式,傳送通知到達客戶端。
待該系統開發完成後,將計劃把相關交易系統送出訊息的通知系統整合入本系統內,以簡化並節省多套通知系統維護人力及費用。


功能要求與特性(Functional Requirements)








系統為一 Outbound 的訊息通知系統,並保證訊息送出
  1. 統主要是接收來自各主機交易系統的資料,經處理後產生 Outbound 訊息送給各通知管道,再透過簡訊、傳真、Email、HTTP、FTP 等管道通知客戶。
  2. 系統並不處理來自簡訊、傳真、Email、HTTP、FTP 等管道的 Inbound 訊息。
    • 系統僅處理自己的客戶的交易資料或對帳單等,不處理該客戶的下游客戶資料。
    • 系統訊息通知的對象係由本行客戶申請通知時所指定的,但不限該客戶本人。
    • 系統處理下列檔案格式的資料:
      • 純文字檔:固定長度文字檔案,經解析及字碼處理,組成通知格式。
      • XML 格式檔:經解析及字碼處理,組成通知格式。
      • 其他檔案:不須再經過處理 ( 格式處理 ) 的待傳送檔案,檔案類型不限制,須配合通知傳送控制檔。
      • 傳真通道接收檔案為Word(*.doc)、Execl(*.xls)、Powerpoint(*.ppt)、Tiff(*.tif)、PDF(*.pdf)、HTML(*.htm)。
      • 系統需能處理 Online 及 Batch 的交易。
      • 系統需有各種記錄及報表。
      • 系統需有 Auto EMail 附件加密的功能:提供客戶選擇是否對 EMail 附件進行加密機制。
  3. 系統通則
    • 容量規劃、管理
      • 須依照所需提供訊息通知項目,以各交易主機系統的交易量、系統所產生的各種管道訊息數量及成長量,妥善規劃系統的容量、並有定期 Purge 資料的管理機制。
      • 保證送出及模組間的監控機制
      • 須提供各系統及模組間的監控機制,保證資料從各主機交易系統 ( 承先 ) 下傳給系統組成通知訊息至各通知管道 ( 啟後 ) 的送達、各系統及模組間傳送及接收資料的筆數一致,過程中若有異常或傳送及接收的筆數不一致時,須有 alert 機制。
      • 系統通知送出失敗或通知送出逾時 ( 超過預設值 ) 的時候,亦須有 alert 的機制。
      • 前後 ( 與各主機交易系統及通知管道間 ) 的資料流量管制 ( Queue 的觀念 )
      • 須有區分各種訊息處理的優先順序的 Queue ,優先順序高的訊息不可因大量優先順序低的訊息而卡住,並有前後 ( 與各主機交易系統及通知管道間 ) 的資料流量管制機制。
      • 須有主動到 BANCS 主機取得 ( Retrive ) 客戶基本資料 ( 包含帳號 ) 及被動等待接收 ( Receive ) 各交易主機下傳檔案的功能。
      • 可接受 FTP / MQ 的方式取得訊息通知資料,及設定抓檔 / 收檔頻率的功能。
      • 所有對帳單的電文處理都需可處理重複多筆的資料錄。
  4. 系統基本功能
    • 系統架構簡單、高擴充性、高參數化、便捷的使用者介面、分多階段開發容易、提供多種通知管道滿足客戶多種需求、提供多個收訊人 ( 同一通知可送至不同收訊人 )。
    • 建立Customer Profile
    • 建立Product Profile
    • 建立各種產品類別通知訊息格式
    • 建立Free Format 功能
    • 接收各主機交易系統資料並依系統預設條件挑選並組成訊息格式
    • 產生簡訊、傳真、E-Mail、HTTP 及 FTP 通知訊息
    • 傳送上述訊息資料至訊息發送通道
    • 系統記錄及MIS統計報表
開發平台 : Windows 2000 + IIS + .NET(C#) + MS SQL Server 2000 + MS SQL ReportingService + COM+ Service
開發人員 : Tom Tang, Vinnie Hsu
系統架構圖(Architecture):


沒有留言: