工作n多年了，從來沒寫過技術部落格，最近在做建行的e商貿通對接，文件比較有限，對相關業務和名詞也不是很熟悉，很多基礎知識也不紮實，前面同事已經做了一部分基礎工作，但是剛接手的時候確實有點蒙。幸虧在網上搜到這個部落格系列，了解了一些基本概念，才順利開發完建行的介面，也突然有衝動把相關的東西整理一下，做個記錄，也方便遇到類似問題的碼農。
1：業務背景
首先先介紹一下背景，我個人是這樣，如果不知道乙個東西的定義，就很難去學習其他方面。我個人的理解，建行的商貿通，以及其他銀行類似的產品，都是依託銀行的資金管理能力，為交易市場（比如大宗交易，以及各種交易所等）提供資金託管的介面，和**公司使用的銀證託管類似。目的就是為了交易資金的安全，防止跑路等。
交易所涉及到商貿通的基本業務包括：
其他涉及到現貨的大宗交易所可能還有其他的業務，因為我們使用的是日結模式，銀行文件有時候也叫中遠期，所以就不清楚現貨相關的流程。
其實還乙個概念需要再說明一下。
2：通訊方式
前面接觸的幾家銀行都是採用socket短連線進行通訊，而建行使用的是http協議。因為協議本身的單向性（即請求-響應），如果只有銀行作為伺服器，不能滿足銀行觸發的業務需求，所以銀行和交易所都作為伺服器和客戶端。銀行的url有：
市場端url：
剛開始我搞不清楚市場端 業務請求 和 訊息推送的區別，後面才知道主要是是否需要市場反饋來區分的，比如網銀入金，銀行只會通知市場，這個事件，並不需要徵求市場端的意見或反饋。相反網銀出金，銀行不可能直接出金，然後只是通知市場，而是需要徵求市場端的意見，就需要呼叫市場的業務請求。市場內部自動或人工審核後，再反饋銀行，該筆出金是否允許。銀行根據反饋訊息，在做出相應的業務操作。
報文的加密簽名是為了安全考慮。其中加密使用對稱加密des，簽名使用rsa私鑰簽名，公鑰驗證。既可以驗證身份，也可以防止抵賴，因為只有私鑰擁有者才能簽名，如果收到正確簽名的報文，就可以防止對方抵賴沒有傳送過該報文。
交換秘鑰時使用的des秘鑰是雙方，根據約定，也就是市場編號加日期作為秘鑰，來加密交換秘鑰報文。
所有報文使用gbk，gb2312編碼，而不是utf8。文件裡面規定的每個欄位的長度是對應的gbk編碼的位元組長度，而不是轉成字串後的長度。
秘鑰都是用base64格式存放，base64就是以文字的形式展示二進位制資料，便於一些協議的傳輸，儲存。注：base64裡面換行符，不會影響解密，spec規定75個字元左右換行。
前面那個博文提到很多人卡在秘鑰這塊，可能就是因為這些基礎概念不是太理解。通過這個對接，對這些概念的具體使用有了更多的理解。
建行E商貿通支付開發系列之一（了解E商貿通）
事先要在平台註冊賬號 開席位號，在銀行開通網銀 席位號關聯之類的工作都不再多說了，這些事情在後面會陸續的說到，我們先直接看一種最常見最完整的交易流程，先對e商貿通有個大概的了解。a 採購方 買家 b 方 賣家 1 a在平台上要購買b的商品，a需要先登入建行的網銀，做入金操作，先把要購買的商品錢放到e...
建行E商貿通支付開發系列之三（2 金鑰生成與交換）
前言 在看本篇文章的時候，一定要細心些，因為這個總分的內容非常的重要，對於我接觸過的幾家公司，都是在這一步耽誤的時間最長的。這一部分的內容雖然是重點之一，但是除了編寫 以外，其它的重點也沒有什麼太多的了，這塊大家用的語言都不一樣，所以就關於下面兩個內容，我分享一下我的經驗吧。關於生成商戶的金鑰，原理...
商貿通帳套隱藏方法
問題現象 新稅版。在帳套列表處。ctrl f9 給帳套設上密碼。儲存後。在主介面就看不到這個帳套了。然後使用的時候按ctrl f8 錯誤輸入的話沒任何提示。正確的話就能看到帳套名了。原因分析 新稅版。在帳套列表處。ctrl f9 給帳套設上密碼。儲存後。在主介面就看不到這個帳套了。然後使用的時候按c...