《證券交易數(shù)據(jù)交換協(xié)議》STEP協(xié)議

《《證券交易數(shù)據(jù)交換協(xié)議》STEP協(xié)議》由會(huì)員分享，可在線閱讀，更多相關(guān)《《證券交易數(shù)據(jù)交換協(xié)議》STEP協(xié)議（79頁珍藏版）》請(qǐng)?jiān)谘b配圖網(wǎng)上搜索。

1、JR/T 0022—2004 目 次 前 言 III 證券交易數(shù)據(jù)交換協(xié)議 1 1 范圍 1 2 規(guī)范性引用文件 1 3 術(shù)語和定義 1 4 應(yīng)用環(huán)境 2 5 會(huì)話機(jī)制 2 5.1 STEP會(huì)話 2 5.1.1 消息序號(hào) 2 5.1.2 心跳 2 5.1.3 缺口填補(bǔ) 2 5.1.4 消息重復(fù)發(fā)送 2 5.1.5 消息重新發(fā)送 2 5.1.6 消息確認(rèn) 3 5.2 STEP連接 3 5.2.1 登錄 3 5.2.2 消息交換 3 5.2.3 注銷 3 5.2.4 消息恢復(fù) 4 6 消息格式 5 6.1 數(shù)據(jù)類型 5 6.1.1

2、整數(shù)int 5 6.1.2 浮點(diǎn)數(shù)float 6 6.1.3 單個(gè)字符char 6 6.1.4 字符串String 6 6.1.5 數(shù)據(jù)Data 6 6.2 域 6 6.2.1 域的使用 7 6.2.2 自定義域 7 6.2.3 域漢字編碼 7 6.2.4 域界定 7 6.2.5 語法 7 6.2.6 重復(fù)組 7 7 安全與加密 7 8 數(shù)據(jù)完整性 8 9 擴(kuò)展方式 8 9.1 擴(kuò)展分類 8 9.2 擴(kuò)展規(guī)則 8 9.3 版本管理 8 10 消息定義 9 10.1 消息頭 9 10.2 消息尾 10 10.3 會(huì)話消息 10 10.3.1 心跳消息（

3、MsgType=0） 10 10.3.2 登錄消息（MsgType=A） 11 10.3.3 測試請(qǐng)求消息（MsgType=1） 11 10.3.4 重發(fā)請(qǐng)求消息（MsgType=2） 12 10.3.5 會(huì)話拒絕消息（MsgType=3） 12 10.3.6 序號(hào)重設(shè)消息（MsgType=4） 14 10.3.7 注銷消息（MsgType=5） 15 10.4 應(yīng)用消息 15 10.4.1 應(yīng)用消息組件 15 10.4.2 訂單業(yè)務(wù)類 18 10.4.3 注冊(cè)類 25 10.4.4 行情 26 10.4.5 市場控制 30 11 數(shù)據(jù)字典 32 附　錄　A 應(yīng)用環(huán)

4、境參考實(shí)例 61 附　錄　B 重復(fù)組實(shí)例 62 附　錄　C 缺口填補(bǔ)方式 63 附　錄　D 會(huì)話連接場景 64 附　錄　E 應(yīng)用消息場景 68 附　錄　F 計(jì)算校驗(yàn)和 74 前 言 本標(biāo)準(zhǔn)部分內(nèi)容參照了金融信息交換協(xié)議（FIX4.4）。 本標(biāo)準(zhǔn)的附錄A、B、C、D、E、F為資料性附錄。 本標(biāo)準(zhǔn)由證券交易標(biāo)準(zhǔn)化小組提出。 本標(biāo)準(zhǔn)由全國金融標(biāo)準(zhǔn)化技術(shù)委員會(huì)歸口。 本標(biāo)準(zhǔn)起草單位：中國證券監(jiān)督管理委員會(huì)信息中心承擔(dān)，上海證券交易所負(fù)責(zé)起草，深圳證券交易所、上海期貨交易所、國信證券公司、泰陽證券公司、華夏證券公司參與制訂。 本標(biāo)準(zhǔn)的主要起草人：楊淑

5、琴、許強(qiáng)、陳忠蘇、丁樺、吳韶平、黃寅飛、喻華麗、萬春波、王海、黃賓、劉漢西、湯玉龍、李大鵬。 III 證券交易數(shù)據(jù)交換協(xié)議 1　 范圍 本標(biāo)準(zhǔn)規(guī)定了證券交易所交易系統(tǒng)與市場參與者系統(tǒng)之間進(jìn)行證券交易所需的數(shù)據(jù)交換協(xié)議（Securities Trading Exchange Protocol，簡稱STEP），規(guī)定了應(yīng)用環(huán)境、會(huì)話機(jī)制、消息格式、安全與加密、數(shù)據(jù)完整性、擴(kuò)展方式、消息定義、數(shù)據(jù)字典等內(nèi)容。 本標(biāo)準(zhǔn)適用于證券交易所與市場參與者和相關(guān)金融機(jī)構(gòu)間的業(yè)務(wù)數(shù)據(jù)交換

6、。 本標(biāo)準(zhǔn)提供了市場參與者內(nèi)部系統(tǒng)與市場參與者協(xié)議轉(zhuǎn)換接口的連接標(biāo)準(zhǔn)以及市場參與者內(nèi)部系統(tǒng)通過開放接口與證券交易所間連接標(biāo)準(zhǔn)。 本標(biāo)準(zhǔn)也可支持證券交易所與其他外部交易所間連接。 2　 規(guī)范性引用文件 下列文件中的條款通過本標(biāo)準(zhǔn)的引用而成為本標(biāo)準(zhǔn)的條款。凡是注明日期的引用文件，其隨后所有的修改單（不包括勘誤的內(nèi)容）或修訂版均不適用于本標(biāo)準(zhǔn)，然而，鼓勵(lì)根據(jù)本標(biāo)準(zhǔn)達(dá)成協(xié)議的各方研究是否可使用這些文件的最新版本。凡是不注明日期的引用文件，其最新版本適用于本標(biāo)準(zhǔn)。 GB/T 2659 世界各國和地區(qū)名稱代碼 GB/T 12406 表示貨幣和資金的代碼 ISO 10383 交易所和市場代

7、碼標(biāo)志識(shí)別碼(MIC)[Codes for exchanges and regulated markets-Marked identifier Codes(MIC)] ISO 10962 證券金融票據(jù)的分類(CFI代碼)[Securities-Classification of Financial Instruments(CFI code)] 3　 術(shù)語和定義 下列術(shù)語和定義適用于本標(biāo)準(zhǔn)。 3.1　 組件塊 Component block 消息中具有一定業(yè)務(wù)相關(guān)的數(shù)據(jù)域集合，如證券品種定義，主要用于更直觀描述消息的業(yè)務(wù)含義。 3.2　 新訂單 New Order-Si

8、ngle 交易客戶方新產(chǎn)生的訂單。 3.3　 執(zhí)行報(bào)告 Execution Report 交易服務(wù)方響應(yīng)交易客戶方的消息，主要用于：訂單確認(rèn)、訂單狀態(tài)變化確認(rèn)（如撤單確認(rèn)和修改單確認(rèn)）、發(fā)送訂單的成交回報(bào)、訂單拒絕。 3.4　 指定交易 Designated Trading 將證券賬號(hào)與某一證券營業(yè)部所屬的參與者業(yè)務(wù)單元（如席位號(hào)）相聯(lián)系，從而限定該證券賬號(hào)的交易應(yīng)在該參與者業(yè)務(wù)單元下進(jìn)行的交易方式。 3.5　 轉(zhuǎn)托管 Designation Transfer 投資者將其托管在某一券商處的證券轉(zhuǎn)到另一券商處托管的行為，并且投資者只能將證券在其托管的券商處

9、賣出。 3.6　 公司行為 Corporate Action 上市公司的非交易類業(yè)務(wù)，如新股配售、配股認(rèn)購、可轉(zhuǎn)債轉(zhuǎn)股、回售等。 3.7　 PBU（參與者業(yè)務(wù)單元） Participant Business Unit 市場參與者行使交易權(quán)利，獲取交易服務(wù)的唯一邏輯通道。 3.8　 市場參與者 Market Participants 參與證券交易的客戶方，如券商、證券公司、證券營業(yè)部、交易所會(huì)員等。 4　 應(yīng)用環(huán)境 證券交易數(shù)據(jù)交換協(xié)議應(yīng)用環(huán)境請(qǐng)參考附錄A應(yīng)用環(huán)境參考實(shí)例。 5　 會(huì)話機(jī)制 5.1　 STEP會(huì)話 5.1.1　 消息序號(hào) 任何一條消息

10、都被分配有一個(gè)消息序號(hào)來唯一標(biāo)識(shí)，消息序號(hào)在每次會(huì)話過程中從1開始，在整個(gè)會(huì)話過程中連續(xù)遞增，直到該會(huì)話過程全部結(jié)束。通過監(jiān)視消息序號(hào)的連續(xù)性可以知道交換中的消息缺口，并做出反應(yīng)，使得連接雙方數(shù)據(jù)同步。 連接雙方都明確確定相互獨(dú)立的消息序號(hào)，參與連接的任何一方負(fù)責(zé)維護(hù)自己發(fā)送的消息序號(hào)，并監(jiān)視接收的消息序號(hào)以保證消息缺口的發(fā)現(xiàn)和處理。 5.1.2　 心跳 在消息交換的空閑期間，連接雙方將會(huì)產(chǎn)生有規(guī)則的心跳消息。通過心跳消息可以監(jiān)控通訊連接的狀態(tài)。心跳間隔時(shí)間由會(huì)話發(fā)起人在登錄時(shí)確定。在發(fā)送任何消息后，應(yīng)立即重新設(shè)置心跳間隔計(jì)時(shí)器。心跳間隔時(shí)間應(yīng)該得到連接雙方的確認(rèn)，由登錄發(fā)起人給出并得到

11、登錄接受方的確認(rèn)。連接雙方使用相同心跳間隔時(shí)間。 5.1.3　 缺口填補(bǔ) 由于協(xié)議是基于樂觀的消息傳輸模式，消息在傳輸過程中可能存在丟失，而這種消息丟失發(fā)送方不能檢測，因此接收方應(yīng)負(fù)責(zé)檢測消息的缺口并處理。有兩種處理方法：接收方發(fā)現(xiàn)缺口后向發(fā)送方請(qǐng)求發(fā)送缺口消息及其后的所有消息；接收方發(fā)現(xiàn)缺口后，保存已收到消息，并向發(fā)送方請(qǐng)求重復(fù)發(fā)送缺口消息。 5.1.4　 消息重復(fù)發(fā)送 響應(yīng)一個(gè)重發(fā)請(qǐng)求而重復(fù)發(fā)送消息時(shí)，或者不確定對(duì)方是否收到某消息而重復(fù)發(fā)送該消息時(shí)，要求在該消息內(nèi)加上可能重復(fù)標(biāo)志（Possible Duplicate=Y）。如何處理該消息則是接收方的事情。由于當(dāng)生成有此類可能重復(fù)發(fā)

12、送的消息時(shí)，仍使用該消息的原來序號(hào)，但某些信息可能會(huì)改變，如原始時(shí)間、發(fā)送時(shí)間、正文長度、可能重復(fù)標(biāo)志等，所以應(yīng)重新計(jì)算校驗(yàn)和。 5.1.5　 消息重新發(fā)送 基于應(yīng)用層的可能重發(fā)，如發(fā)送的訂單在相當(dāng)長的時(shí)間內(nèi)沒有確認(rèn)，或者懷疑其根本未曾發(fā)送過，可以通過設(shè)置可能重新發(fā)送標(biāo)志來重新發(fā)送(Possible Resend=Y) ，并使用新的消息序號(hào)。接收方應(yīng)用層收到該類消息后，應(yīng)通過查詢消息內(nèi)的域（如訂單編號(hào)等）來確定此前是否收到此條消息。該類消息應(yīng)確定包含相同的正文數(shù)據(jù)，同樣，由于某些信息可能會(huì)改變，所以應(yīng)重新計(jì)算校驗(yàn)和。 5.1.6　 消息確認(rèn) 由于協(xié)議是基于樂觀的消息傳輸模式，通過監(jiān)視消

13、息序號(hào)發(fā)現(xiàn)缺口，不支持對(duì)每個(gè)消息收發(fā)的確認(rèn)。但大量消息收發(fā)的確認(rèn)可在應(yīng)用層定義。在應(yīng)用層接受和拒絕是允許的，如訂單的確認(rèn)。 5.2　 STEP連接（會(huì)話） 會(huì)話過程的數(shù)據(jù)交換可以這樣描述：連接雙方各有一個(gè)連續(xù)的消息序號(hào)隨消息傳送，而交易期間可以多次斷開并重新連接，其斷開的原因可以是外因引起，也可以是連接雙方根據(jù)系統(tǒng)來統(tǒng)一制定何時(shí)斷開并重新連接。一次會(huì)話連接通常不應(yīng)超過24小時(shí)，當(dāng)然，如需要保持24小時(shí)以上的連接，則需要發(fā)送一條含有序號(hào)重設(shè)標(biāo)志的登錄消息來建立新的起始消息序號(hào)。 STEP連接分為三個(gè)部分：登錄、消息交換、注銷。 STEP會(huì)話包含一個(gè)或多個(gè)STEP連接，即一個(gè)STEP會(huì)話可

14、以跨越多個(gè)登錄。 5.2.1　 登錄 登錄連接包含三個(gè)步驟：建立電信通訊連接、連接雙方的確認(rèn)/認(rèn)證、消息傳輸同步的初始化。主要有以下幾點(diǎn)： 5.2.1.1　 連接 會(huì)話的發(fā)起方與接收方建立電信通訊連接。 5.2.1.2　 認(rèn)證 發(fā)起方發(fā)送登錄消息（Logon），接收方認(rèn)證發(fā)起方身份的合法性。登錄消息應(yīng)包括認(rèn)證的必要數(shù)據(jù)，如用戶名、密碼等。如果發(fā)起方身份通過認(rèn)證，則接收方發(fā)送一個(gè)登錄消息作回應(yīng)。如果認(rèn)證失敗，會(huì)話接收方則在發(fā)送一個(gè)含失敗說明的注銷消息（Logout）后關(guān)閉連接。不過發(fā)送注銷消息并非是必須的，因?yàn)樵谀承┣闆r下往往會(huì)引起其他問題。在發(fā)起方收到接收方的登錄消息之后即

15、可認(rèn)為會(huì)話連接建立完成。會(huì)話發(fā)起方可以緊隨登錄消息之后開始發(fā)送其他消息。 通常在登錄后或者剛發(fā)送完測試請(qǐng)求消息（TestRequest）時(shí)延遲等待一段時(shí)間，然后再發(fā)送新的消息，使得連接雙方能有效控制重發(fā)請(qǐng)求。否則可能會(huì)導(dǎo)致一方會(huì)針對(duì)對(duì)方的每一條新消息發(fā)出重發(fā)請(qǐng)求。 5.2.1.3　 初始化 在身份通過認(rèn)證之后，發(fā)起方和接收方應(yīng)首先同步消息序號(hào)，然后才能相互發(fā)送新的信息。同步消息序號(hào)通過消息序號(hào)域（MsgSeqNum）來確定，將登錄消息里的消息序號(hào)（MsgSeqNum）與內(nèi)部監(jiān)控的下一個(gè)預(yù)期的消息序號(hào)進(jìn)行比較就能發(fā)現(xiàn)消息的消息序號(hào)缺口。同樣，發(fā)起方通過將接收方發(fā)送的登錄消息里的消息序號(hào)

16、（MsgSeqNum）與下一個(gè)預(yù)期的消息序號(hào)進(jìn)行比較也能發(fā)現(xiàn)消息的缺口。 5.2.2　 消息交換 在以上初始化完成之后，可以開始進(jìn)行信息交換。所有有效消息的格式將在“會(huì)話消息”和“應(yīng)用消息”部分中詳細(xì)敘述。 5.2.3　 注銷 會(huì)話的正常結(jié)束是通過連接雙方互相發(fā)送注銷消息（Logout）完成的。若結(jié)束時(shí)沒有收到回送的注銷消息（Logout），則把對(duì)方視作已注銷。除此之外的其它方式的會(huì)話結(jié)束視為非正常，并應(yīng)按錯(cuò)誤來處理。 在發(fā)送注銷消息（Logout）之前，應(yīng)發(fā)送測試請(qǐng)求消息（TestRequest）以要求對(duì)方的心跳信息，這有助于保證不出現(xiàn)消息序號(hào)缺口。 在結(jié)束會(huì)話之

17、前，注銷消息（Logout）的發(fā)起方應(yīng)該等待對(duì)方回送的注銷消息（Logout），這樣給接收方一個(gè)填補(bǔ)缺口的機(jī)會(huì)。待重發(fā)請(qǐng)求的信息全部收到后，接收方才可發(fā)送應(yīng)答的注銷消息（Logout）。如果接收方在一定時(shí)間內(nèi)沒有答復(fù)，那么會(huì)話就可以立即中斷。（注注：注銷不影響任何訂單的狀況。所有有效的訂單都可在注銷（Logout）之后執(zhí)行。 ） 5.2.4　 消息恢復(fù) 以下描述了有關(guān)恢復(fù)消息的具體方法。 每一方必須維護(hù)兩個(gè)消息序號(hào)，一個(gè)為了發(fā)送，一個(gè)為了接收。 當(dāng)接收進(jìn)來的消息序號(hào)與預(yù)期的消息序號(hào)不相符合時(shí)，需進(jìn)行修正處理。但需要注意的是，如果接收進(jìn)來的是序號(hào)重設(shè)-重設(shè)（SeqR

18、eset-Reset）消息則不需要修正處理，因?yàn)樘幚碓撓r(shí)不必考慮它的消息序號(hào)。如果接收的消息的消息序號(hào)比預(yù)期的消息序號(hào)小，而且沒有設(shè)置可能重復(fù)標(biāo)志（PossDupFlag），那么表明發(fā)生了嚴(yán)重的錯(cuò)誤。因此必須立即結(jié)束會(huì)話，并開始進(jìn)行人工干預(yù)。如果接收進(jìn)來的消息序號(hào)比預(yù)期的大，那么表明有消息被遺漏，應(yīng)通過發(fā)送重發(fā)請(qǐng)求申請(qǐng)?zhí)钛a(bǔ)缺口。 當(dāng)收到重發(fā)請(qǐng)求時(shí)，重發(fā)人可以作出回應(yīng)為以下三種之一：（注注：本文中請(qǐng)求人指的是提出重發(fā)請(qǐng)求的那一方，重發(fā)人指的是回應(yīng)重發(fā)請(qǐng)求的那一方。 ） a) 作為正?；貞?yīng)，重發(fā)人按順序發(fā)送被請(qǐng)求的消息，這些消息的消息序號(hào)仍為原消息序號(hào)，并

19、且將可能重復(fù)的標(biāo)志（PossDupFlag）置位為“Y”。 b) 作為正?；貞?yīng)，重發(fā)人發(fā)送序號(hào)重設(shè)-缺口填補(bǔ)（SeqReset-GapFill）消息，可能重復(fù)標(biāo)志（PossDupFlag）置位為“Y”，以表示刪除過時(shí)或多余的消息。 c) 作為非正?；貞?yīng)，重發(fā)人發(fā)送序號(hào)重設(shè)-重設(shè)（SeqReset-Reset）消息，可能重復(fù)的標(biāo)志（PossDupFlag）置位為“Y”，以強(qiáng)制消息序號(hào)同步。 在缺口填補(bǔ)過程中，不需要重新發(fā)送某些會(huì)話消息。取而代之的是一種特殊的序號(hào)重設(shè)-缺口填補(bǔ)（SeqReset-GapFill）消息。不需要重新發(fā)送的會(huì)話消息是：登錄、注銷、重發(fā)請(qǐng)求、心跳

20、、測試請(qǐng)求、序號(hào)重設(shè)-重設(shè)（SeqReset-Reset ）和序號(hào)重設(shè)-缺口填補(bǔ)（SeqReset-GapFill）。這樣會(huì)話拒絕消息便成為了唯一可能被重新發(fā)送的會(huì)話消息。 會(huì)話過程中應(yīng)監(jiān)視接收進(jìn)來的消息以便發(fā)現(xiàn)由于疏漏而被對(duì)方重新發(fā)送了的會(huì)話消息（設(shè)置了可能重復(fù)標(biāo)志（PossDupFlag）的）。當(dāng)收到這些消息以后，處理時(shí)，只要確保它們具有消息序號(hào)的完整性即可，而忽略對(duì)它們的業(yè)務(wù)或應(yīng)用的處理。 如果碰到多個(gè)連續(xù)的不需要重發(fā)的會(huì)話消息，則只需發(fā)送一個(gè)序號(hào)重設(shè)-缺口填補(bǔ)（SeqReset-GapFill）消息取而代之。該序號(hào)重設(shè)-缺口填補(bǔ)消息的消息序號(hào)是下一

21、個(gè)預(yù)期的消息序號(hào)。序號(hào)重設(shè)-缺口填補(bǔ)（SeqReset-GapFill）消息的新消息序號(hào)（NewSeqNo）為本連續(xù)會(huì)話消息段中最大消息序號(hào)+1。（注注：如在重新發(fā)送操作期間，有7條連續(xù)的會(huì)話消息等待發(fā)送，他們以消息序號(hào)9開始和以消息序號(hào)15結(jié)束，此時(shí)只發(fā)送一個(gè)序號(hào)重設(shè)-缺口填補(bǔ)（SeqReset-GapFill）消息來代替那7條消息，那么該序號(hào)重設(shè)-缺口填補(bǔ)（SeqReset-GapFill）消息的消息序號(hào)是9，這是因?yàn)橐薪由蠗l消息而保持消息序號(hào)的連續(xù)性；其中新消息序號(hào)（NewSeqNo）是16，這樣使得對(duì)方知道下一消息發(fā)送時(shí)的消息序號(hào)。 ） 在缺口被填補(bǔ)完成之后，交換引擎應(yīng)將無序

22、的消息暫時(shí)保存為有序的排列并按順序?qū)λ鼈冞M(jìn)行處理。這樣防止出現(xiàn)對(duì)n->m,n->m+1,n->m+2,…的重發(fā)請(qǐng)求，從而導(dǎo)致了大量的可能重復(fù)（PossDupFlag=’Y’）標(biāo)記。 檢驗(yàn)消息序號(hào)的連續(xù)在會(huì)話過程管理中是必不可少的部分。不過，針對(duì)消息類型的不同，處理消息序號(hào)流的差異也就不同。下列的表１列出了當(dāng)進(jìn)來的消息序號(hào)大于預(yù)期消息序號(hào)時(shí)而應(yīng)采取的措施。 （注注：在任何情況下，除了序號(hào)重設(shè)－重設(shè)消息外，如果進(jìn)來的消息序號(hào)比預(yù)期的消息序號(hào)小，而且可能重復(fù)標(biāo)志（PossDupFlag）沒有被設(shè)置，那么應(yīng)立即終止會(huì)話過程。并應(yīng)在結(jié)束會(huì)話之前，向?qū)Ψ桨l(fā)送帶有解釋正文的注銷（Logout

23、）消息。 ） 表１ 消息類型 針對(duì)消息序號(hào)錯(cuò)誤所采取的措施 登錄 永遠(yuǎn)是連接雙方發(fā)送的第一條消息，用于認(rèn)證和連接。如果發(fā)現(xiàn)登錄消息中有缺口，則應(yīng)在回送登錄確認(rèn)消息之后立即發(fā)送重發(fā)請(qǐng)求 注銷 如果發(fā)現(xiàn)有缺口，應(yīng)發(fā)送重發(fā)請(qǐng)求消息以重新接收所有丟失的消息，然后再發(fā)送注銷消息作為對(duì)注銷請(qǐng)求的確認(rèn)。注意嚴(yán)禁在有缺口情況下結(jié)束會(huì)話。并由注銷的最初發(fā)起人負(fù)責(zé)結(jié)束會(huì)話，因此注銷發(fā)起人有責(zé)任回應(yīng)所有的重發(fā)請(qǐng)求 重發(fā)請(qǐng)求 首先處理完對(duì)方的重發(fā)請(qǐng)求，隨后發(fā)送自己的重發(fā)請(qǐng)求以填補(bǔ)消息序號(hào)錯(cuò)誤而發(fā)現(xiàn)的消息缺口。 序號(hào)重設(shè)-重設(shè) 可以忽略消息序號(hào)錯(cuò)誤。因?yàn)樵谛蛱?hào)重設(shè)-重設(shè)（SeqReset-Res

24、et）消息中的新消息序號(hào)（NewSeqNo）強(qiáng)制為下一發(fā)送消息的消息序號(hào)。 序號(hào)重設(shè)-缺口填補(bǔ) 應(yīng)立即向?qū)Ψ桨l(fā)送重發(fā)請(qǐng)求。但是，重要的是要確保沒有無意間跳過任何消息，這意味著缺口填補(bǔ)消息應(yīng)按次序被接收到，如果次序不對(duì)，那么表示出現(xiàn)了非正常的情況 所有其它信息 執(zhí)行正常的缺口填補(bǔ)。 6　 消息格式 6.1　 數(shù)據(jù)類型 數(shù)據(jù)類型用于定義數(shù)據(jù)域的取值類型，本標(biāo)準(zhǔn)由幾個(gè)基本的數(shù)據(jù)類型（整數(shù)、浮點(diǎn)數(shù)、單字符、字符串、二進(jìn)制數(shù)據(jù)塊）和在此基礎(chǔ)上擴(kuò)展的數(shù)據(jù)類型組成。除“data”數(shù)據(jù)類型外，其他數(shù)據(jù)類型均以ASCII碼字符串表示。 6.1.1　 整數(shù)int 無逗號(hào)和小數(shù)位的序

25、號(hào)，可表示正負(fù)（ASCII碼字符‘-’,‘0’至‘9’組成）。符號(hào)占據(jù)一個(gè)字符位置。允許前置字符零（例：“00023”=“23”）。 整數(shù)類型的擴(kuò)展定義： 長度Length:以整數(shù)表示字節(jié)為單位的數(shù)據(jù)長度，正數(shù)。 重復(fù)數(shù)NumInGroup:以整數(shù)表示重復(fù)組的個(gè)數(shù)，正數(shù)。 消息序號(hào)SeqNum:以整數(shù)表示消息序號(hào)，正數(shù)。 域號(hào)TagNum:以整數(shù)表示的域號(hào)（或稱Ｔａｇ），正數(shù)，首位不能為零。 月日期號(hào) DayOfMonth：以整數(shù)表示的月份中第幾天，取值1至31。 6.1.2　 浮點(diǎn)數(shù)float 含有可選的小數(shù)部分，可表示正負(fù)（ASCII碼字符‘-’,‘0’至‘9’和‘.’組

26、成）。最多15位有效數(shù)字。允許前置字符零（例：“00023”=“23”）。允許小數(shù)部分后置字符零（例：“23.0”=“23.0000”=“23”）。 浮點(diǎn)數(shù)類型的擴(kuò)展定義： 除非特別聲明，浮點(diǎn)數(shù)類型均有正負(fù)。 量Qty: 股份數(shù)量、資產(chǎn)數(shù)量等，可以有小數(shù)部分。 價(jià)格Price:小數(shù)位數(shù)可變。 價(jià)格偏移量PriceOffset:代表價(jià)格偏移量的浮點(diǎn)域。 金額Amt: 典型的價(jià)格與數(shù)量相乘結(jié)果，如成交金額。 百分比Percentage:小數(shù)表示方法：.05代表5%。 6.1.3　 單個(gè)字符char 指除界定符外所有字母字符和標(biāo)點(diǎn)字符，區(qū)分字母大小寫。 字符類型的擴(kuò)展定義

27、： 布爾Boolean: 該域取值于兩個(gè)字符，（’Y’=True/Yes,’N’=False/No） 6.1.4　 字符串String 區(qū)分字母大小寫。 字符串類型的擴(kuò)展定義： 多元值字符串MultipleValueString: 用空格分隔。 國家Country: 參見GB/T 2659。 字符串貨幣類型Currency: 參見GB/T 12406。 交易所或市場編號(hào)Exchange: 字符串，參見ISO10383。 年月日期month-year: 格式Y(jié)YYYMM或YYYYMMDD或YYYYMMWW，YYYY = 0000-9999, MM = 01-12，D

28、D = 01-31，WW = w1,w2,w3,w4,w5。 國際標(biāo)準(zhǔn)時(shí)時(shí)間戳UTCTimestamp: 格式 YYYYMMDD-HH:MM:SS(秒)或 YYYYMMDD-HH:MM:SS.sss（毫秒）， YYYY = 0000-9999, MM = 01-12, DD = 01-31, HH = 00-23, MM = 00-59, SS = 00-60 (秒)，sss=000-999 (毫秒)。 國際標(biāo)準(zhǔn)時(shí)時(shí)間UTCTimeOnly:格式 HH:MM:SS或HH:MM:SS.sss， HH = 00-23, MM = 00-59, SS =

29、00-60 (秒)，sss=000-999 (毫秒)。 國際標(biāo)準(zhǔn)時(shí)日期UTCDateOnly:格式 YYYYMMDD， YYYY = 0000-9999, MM = 01-12, DD = 01-31。 本地市場日期LocalMktDate: 格式Y(jié)YYYMMDD，YYYY = 0000-9999, MM = 01-12, DD = 01-31。 6.1.5　 數(shù)據(jù)Data 無格式和內(nèi)容限制的原始數(shù)據(jù)，包含長度域和數(shù)據(jù)域兩個(gè)部分，數(shù)據(jù)域數(shù)據(jù)可以包含數(shù)值0x01，長度域指明數(shù)據(jù)域的字節(jié)數(shù)。 6.2　 域 域是基本的數(shù)據(jù)元素，每個(gè)域有其域號(hào)、業(yè)務(wù)含義和確定的取值范圍，域號(hào)統(tǒng)一分

30、配給不同的域，是域的區(qū)分標(biāo)志，在消息中，通過域號(hào)來確定不同的域。域的數(shù)據(jù)類型決定了其取值類型，域的取值范圍可以是一個(gè)集合，任何在此集合外的取值被認(rèn)為是非法取值。數(shù)據(jù)字典部份詳細(xì)定義了所有域的業(yè)務(wù)定義、數(shù)據(jù)類型和取值范圍。 6.2.1　 域的使用 在消息中，域的使用有三種方式：必須的，可選的，條件限制選擇（即根據(jù)其他相關(guān)域的存在與否或取值來決定）。作為一個(gè)完整的消息，必須域和條件限制選擇域是需要包含的。 6.2.2　 自定義域 如本標(biāo)準(zhǔn)中定義的域不夠使用時(shí)，證券交易所或市場參與者可以擴(kuò)展定義新的域，即自定義域。 6.2.3　 域漢字編碼 域取值為漢字時(shí)需要使用統(tǒng)一的GBK漢字編碼標(biāo)準(zhǔn)

31、，。 6.2.4　 域界定 消息中所有的域（包含data類型數(shù)據(jù)域）都有一個(gè)分隔符來界定分隔，該分隔符就是不可打印字符ASCII碼“SOH”(#001，hex：0x01，本文檔中以表示)。因此，所有消息以“8=STEP.x.y.z”字符串開始并以“10=nnn”字符串結(jié)束。 除data數(shù)據(jù)類型域外，其他數(shù)據(jù)域內(nèi)容都不應(yīng)包含域界定符。 6.2.5　 語法 任何消息都嚴(yán)格由多個(gè)“域號(hào)=值”的基本結(jié)構(gòu)組成，“域號(hào)=值”基本結(jié)構(gòu)用域界定符分隔。消息組成結(jié)構(gòu)如圖１： 圖１：消息格式 消息由消息頭、消息的正文和消息尾組成。同樣，每個(gè)組成部

32、份都由一系列“域號(hào)=值”組成，并且在遵循以下規(guī)則前提下“域號(hào)=值”基本結(jié)構(gòu)可以是任意的次序： a) 開始部分應(yīng)是消息頭，隨后是正文，最后是消息尾； b) 消息頭的前3個(gè)域的次序不能改變：起始串（Tag =8）、消息體長度（Tag =9）、消息類型（Tag =35）； c) 消息尾的最后一個(gè)域應(yīng)是校驗(yàn)和域（Tag =10）； d) 重復(fù)組中，域出現(xiàn)的順序應(yīng)遵循該重復(fù)組在消息或組件中定義時(shí)的次序。 e) 在一條消息中，除重復(fù)組域外任何其他域不能重復(fù)出現(xiàn)。 （消息格式的例子見注注： ８＝ＳＴＥＰ．１．０．０＜ＳＯＨ＞９＝１１２＜ＳＯＨ＞３５＝Ｄ＜ＳＯＨ＞４９＝ＢＲＫＲ＜ＳＯＨ＞５６＝

33、ＩＮＶＭＧＲ＜ＳＯＨ＞３４＝２３５＜ＳＯＨ＞５２＝２００３０６２０－０９：３５：２７＜ＳＯＨ＞１１＝０００００７＜ＳＯＨ＞２１＝２＜ＳＯＨ＞５５＝青島啤酒＜ＳＯＨ＞４８＝６００６００＜ＳＯＨ＞ ５４＝１＜ＳＯＨ＞４４＝８．５２０ ＜ＳＯＨ＞ ３８＝１０００ ＜ＳＯＨ＞ ６０＝２００３０６２０－０９：３５：２８＜ＳＯＨ＞４０＝２＜ＳＯＨ＞１０＝１５７＜ＳＯＨ＞ ） 6.2.6　 重復(fù)組 域可以在重復(fù)組里多次重復(fù)，用以傳輸數(shù)組類的數(shù)據(jù)。通常域名起始為’No’字符的域指明重復(fù)的次數(shù)，并位于重復(fù)組的開始處。本文檔中重復(fù)組的定義通過縮進(jìn)的à符號(hào)表示，重復(fù)組也可嵌套。使用子重復(fù)組時(shí)不能省略父重復(fù)

34、組。 具體可參考附錄B重復(fù)組實(shí)例。 7　 安全與加密 由于消息有可能在公網(wǎng)或不安全的網(wǎng)絡(luò)上傳輸交換，因此需要對(duì)相關(guān)的敏感數(shù)據(jù)加密處理。 具體加密的方法由連接雙方達(dá)成的協(xié)議而定。 消息內(nèi)除某些需要公開識(shí)別的域以明文傳輸外其他任何域都可以加密放置密文數(shù)據(jù)域（SecureData）內(nèi)。當(dāng)然，這些被加密的域也可以同時(shí)保留明文的表示方式。 當(dāng)決定使用加密方案時(shí)，可以對(duì)消息正文內(nèi)所有的域加密。如果消息的重復(fù)組內(nèi)有部分需要加密的，那么要求對(duì)整個(gè)重復(fù)組加密。 本協(xié)議還提供的一些域用以支持?jǐn)?shù)字簽名、密鑰交換和正文加密等安全技術(shù)。 正文加密方案有三種： a) 將安全敏感的域加密后移至Secure

35、Data域。 b) 將所有允許加密的域加密后移至SecureData域。 c) 將所有允許加密的域加密后移至SecureData域，同時(shí)這些域以明文在消息中重復(fù)出現(xiàn)。 8　 數(shù)據(jù)完整性 數(shù)據(jù)的完整性通過兩個(gè)方法保證：消息體長度和校驗(yàn)和的驗(yàn)證。 消息體長度是以BodyLength域來表示，其值是計(jì)算出的消息長度域后面的字符數(shù)，包含緊靠校驗(yàn)和域標(biāo)志‘10=’之前的界定符SOH。 校驗(yàn)和是把每個(gè)字符的二進(jìn)制值從消息開頭‘8=’中的‘8’開始相加，一直加到緊靠在校驗(yàn)和域‘10=’之前的域界定符，然后取按256取模得到的結(jié)果。 校驗(yàn)和域位于消息的最末 一個(gè)，校驗(yàn)和的計(jì)算是在加

36、密之后進(jìn)行的。計(jì)算校驗(yàn)和的代碼段可參考附錄F計(jì)算校驗(yàn)和。 9　 擴(kuò)展方式 9.1　 擴(kuò)展分類 擴(kuò)展分為兩個(gè)部分：消息定義擴(kuò)展和域定義擴(kuò)展。 消息定義擴(kuò)展可以通過新增消息類型來實(shí)現(xiàn)，但盡量在已有消息中通過域定義或取值擴(kuò)展來定義新業(yè)務(wù)。已有消息所代表的業(yè)務(wù)在擴(kuò)展時(shí)不能改變。 域定義擴(kuò)展可以通過新增域來實(shí)現(xiàn)，但盡量通過擴(kuò)展域值來擴(kuò)展域的定義。消息中已定義的必須的域不能取消定義，也不能改變成可選域。 9.2　 擴(kuò)展規(guī)則 自定義消息的消息類型值首字符為‘U’。其他類型的消息由全國金融標(biāo)準(zhǔn)化技術(shù)委員會(huì)根據(jù)國際相關(guān)標(biāo)準(zhǔn)的變化統(tǒng)一定義并發(fā)布。 消息和域臨時(shí)定義原則：上海證券交易所臨時(shí)定義消息的

37、消息類型值首兩位字符為‘UA’，深圳證券交易所臨時(shí)定義消息的消息類型值首兩位字符為‘UB’；消息和域的臨時(shí)定義應(yīng)同時(shí)報(bào)備至全國金融標(biāo)準(zhǔn)化技術(shù)委員會(huì)。 域號(hào)1-4999由全國金融標(biāo)準(zhǔn)化技術(shù)委員會(huì)根據(jù)國際標(biāo)準(zhǔn)的變化統(tǒng)一定義并發(fā)布，該域區(qū)間只有全國金融標(biāo)準(zhǔn)化技術(shù)委員會(huì)有權(quán)擴(kuò)展、修改和發(fā)布；域號(hào)8500-8999由全國金融標(biāo)準(zhǔn)化技術(shù)委員會(huì)自行定義，其中8800-8999為臨時(shí)定義區(qū)間；臨時(shí)定義區(qū)間中域號(hào)8800-8899為全國金融標(biāo)準(zhǔn)化技術(shù)委員會(huì)授權(quán)上海證券交易所市場臨時(shí)定義區(qū)間，域號(hào)8900-8999為全國金融標(biāo)準(zhǔn)化技術(shù)委員會(huì)授權(quán)深圳證券交易所市場臨時(shí)定義區(qū)間。域號(hào)10000以上由連接雙方自行約定

38、定義。 消息的模塊順序在擴(kuò)展定義時(shí)不能改變，即保持消息頭、消息體和消息尾的順序。而模塊的內(nèi)部，域和重復(fù)組的順序是可以變化的。 消息頭的頭三個(gè)域的定義和位置不能改變，但可以擴(kuò)展增加消息頭的可選域。 消息尾最后一個(gè)域的定義和位置不能改變，但可以擴(kuò)展增加消息尾的可選域。 9.3　 版本管理 本協(xié)議的版本管理權(quán)屬于全國金融標(biāo)準(zhǔn)化技術(shù)委員會(huì)。 版本號(hào)格式為X.Y.Z，版本號(hào)從1.0.0起始，當(dāng)新版本完全兼容上一版本時(shí)只改變版本號(hào)中的Z。 本協(xié)議當(dāng)前版本的版本號(hào)為1.0.0。 全國金融標(biāo)準(zhǔn)化技術(shù)委員會(huì)定期審核臨時(shí)定義，并在新版本中統(tǒng)一定義發(fā)布，同時(shí)取消相關(guān)臨時(shí)定義。 10　 消息定義

39、 10.1　 消息頭 每一個(gè)會(huì)話或應(yīng)用消息有一個(gè)消息頭，該消息頭指明消息類型、消息體長度、發(fā)送目的地、消息序號(hào)、發(fā)送起始點(diǎn)和發(fā)送時(shí)間。 其中有兩個(gè)域用于消息重發(fā)，對(duì)于會(huì)話級(jí)的事件而重復(fù)發(fā)送消息時(shí)將可能重復(fù)發(fā)送標(biāo)志(PossDupFlag)設(shè)置為Y（發(fā)送時(shí)用原來的消息序號(hào)），當(dāng)重新發(fā)送時(shí)使用新的消息序號(hào)時(shí)將可能重新發(fā)送標(biāo)志（PossResend）設(shè)置為Y，接受者應(yīng)按以下方法處理上述消息： 可能重復(fù)發(fā)送：如果帶有該消息序號(hào)的消息在以前曾經(jīng)接受過，則忽略消息，如果未曾收到過，則按正常步驟處理。 可能重新發(fā)送：將消息傳遞給應(yīng)用層以確定此前是否收到該消息（通過檢查訂單編號(hào)或相關(guān)參數(shù)）。 消息

40、頭格式見表２： 表２　消息頭 Tag 域名 必需 說明 8 BeginString Y 起始串STEP.1.0.0 (不可加密，消息的第一個(gè)域) 9 BodyLength Y 消息體長度(不可加密，消息的第二個(gè)域) 35 MsgType Y 消息類型(不可加密，消息的第三個(gè)域) 49 SenderCompID Y 發(fā)送方代碼(不可加密，發(fā)送方標(biāo)識(shí)符) 56 TargetCompID Y 接收方代碼(不可加密，接收方標(biāo)識(shí)符) 115 OnBehalfOfCompID N 最初發(fā)送方標(biāo)識(shí)符（可加密），用于經(jīng)第三方發(fā)送。 128 Deli

41、verToCompID N 最終接收方標(biāo)識(shí)符（可加密），用于經(jīng)第三方發(fā)送。 90 SecureDataLen N 密文數(shù)據(jù)長度 91 SecureData N 密文數(shù)據(jù)（緊跟密文數(shù)據(jù)長度域） 34 MsgSeqNum Y 消息序號(hào)（可加密） 50 SenderSubID N 發(fā)送方子標(biāo)識(shí)符（可加密） 142 SenderLocationID N 發(fā)送方方位標(biāo)識(shí)符（可加密） 57 TargetSubID N 接收方子標(biāo)識(shí)符（可加密） 143 TargetLocationID N 接收方方位標(biāo)識(shí)符（可加密） 116 OnBehalfO

42、fSubID N 最初發(fā)送方子標(biāo)識(shí)符（可加密） 144 OnBehalfOfLocationID N 最初發(fā)送方方位標(biāo)識(shí)符（可加密） 129 DeliverToSubID N 最終接收方子標(biāo)識(shí)符（可加密） 145 DeliverToLocationID N 最終接收方方位標(biāo)識(shí)符（可加密） 43 PossDupFlag N 可能重復(fù)標(biāo)志，重復(fù)發(fā)送時(shí)，作此標(biāo)記。（可加密） 97 PossResend N 可能重發(fā)標(biāo)志。（可加密） 52 SendingTime Y 發(fā)送時(shí)間（可加密） 122 OrigSendingTime N 原始發(fā)送時(shí)間

43、（可加密） 347 MessageEncoding N 消息中Encoded域的字符編碼類型（非ASCII碼） 表２（續(xù)）　消息頭 Tag 域名 必需 說明 369 LastMsgSeqNumProcessed N 最后處理消息序號(hào)（可加密） 370 OnBehalfOfSendingTime N 最初發(fā)送時(shí)間（用UTC表示時(shí)間） 627 NoHops N 歷史跳躍信息重復(fù)組，記錄消息經(jīng)第三方發(fā)送的歷史，每次經(jīng)第三方發(fā)送為一個(gè)跳躍，僅當(dāng)OnBehalfOfCompID使用時(shí)有效，主要用于跟蹤消息的路徑。 à 628 HopCompID N

44、 取值第三方的SenderCompID à 629 HopSendingTime N 取值用第三方的SendingTime à 630 HopRefID N 取值第三方的MsgSeqNum 10.2　 消息尾 每一個(gè)消息（會(huì)話或應(yīng)用消息）有一個(gè)消息尾，并以此終止。消息尾可用于分隔多個(gè)消息，包含有3位數(shù)的校驗(yàn)和值。 消息尾格式見表３： 表３　消息尾 Tag 域名 必需 說明 93 SignatureLength N 數(shù)字簽名長度（不可加密） 89 Signature N 數(shù)字簽名（不可加密） 10 CheckSum Y 校驗(yàn)和，消息

45、的最末域。（不可加密） 10.3　 會(huì)話消息 會(huì)話消息涉及標(biāo)準(zhǔn)的使用機(jī)制，將在以下各節(jié)中予以介紹，并定義會(huì)話消息格式。 連接雙方均可生成會(huì)話消息。 10.3.1　 心跳消息（MsgType=0） 心跳消息用于監(jiān)控通信連接的狀況，并可確認(rèn)是否接收到最后一條消息。 當(dāng)STEP連接的任何一方在（[HeartBtInt] 秒，心跳間隔）時(shí)間內(nèi)沒有發(fā)送任何數(shù)據(jù)的時(shí)候，將產(chǎn)生一個(gè)心跳消息并傳送出去。當(dāng)連接的任何一方在（[HeartBtInt]＋[合理傳輸時(shí)間] ）時(shí)間內(nèi)都沒有收到任何有關(guān)的數(shù)據(jù)的時(shí)候，將產(chǎn)生一個(gè)測試請(qǐng)求消息并傳送出去。如果在此之后的（[HeartBtInt]＋[合理傳輸時(shí)間

46、] ）時(shí)間內(nèi)，仍沒有收到心跳消息，那么可認(rèn)為此次連接失敗，而且需開始實(shí)施修正操作。如果 HeartBtInt 被設(shè)置為零，那么將不會(huì)定期生成心跳消息。并且不論 HeartBtInt 取值多少，任何一方都可發(fā)送測試請(qǐng)求消息，接收方由此將強(qiáng)行生成心跳消息。 因?qū)Ψ降臏y試請(qǐng)求消息而產(chǎn)生的心跳（Heartbeats）消息應(yīng)包括對(duì)方測試請(qǐng)求消息中的測試請(qǐng)求標(biāo)識(shí)符（TestReqID）。這有利于確定該心跳消息是響應(yīng)測試請(qǐng)求而產(chǎn)生的，而不是由于超時(shí)而產(chǎn)生的。 心跳消息格式見表４： 表４　心跳（Heartbeat） Tag 域名 必需 說明 標(biāo)準(zhǔn)消息頭 Y MsgType = 0

47、112 TestReqID N 測試請(qǐng)求標(biāo)識(shí)符，如是對(duì)測試請(qǐng)求而響應(yīng)的心跳消息，則應(yīng)包含本域。 標(biāo)準(zhǔn)消息尾 Y 10.3.2　 登錄消息（MsgType=A） 登錄消息能證實(shí)用戶是否已建立與對(duì)方系統(tǒng)的連接。登錄消息應(yīng)是在STEP會(huì)話開始時(shí)的連接雙方發(fā)送的第一個(gè)消息。 HeartBtInt域用來聲明產(chǎn)生心跳的時(shí)間間隔（連接雙方HeartBtInt取相同的值）。連接雙方事先約定取值，由登錄發(fā)起方產(chǎn)生并得到接收方的確認(rèn)響應(yīng)。 在接收登錄消息時(shí)，接收方將驗(yàn)證發(fā)起方身份的合法性，并且同樣發(fā)出登錄消息以確認(rèn)連接請(qǐng)求已被接受。同樣，確認(rèn)登錄消息也可以被發(fā)起方使用以驗(yàn)證連接了身份合法

48、的接收方。 接收方應(yīng)在收到登錄消息之后，立即作好開始消息處理的準(zhǔn)備。發(fā)起方可以選擇在接收到確認(rèn)登錄消息之前開始STEP消息傳輸。不過本標(biāo)準(zhǔn)規(guī)定：在有關(guān)密鑰確認(rèn)的登錄消息收到之后，才實(shí)施正常的消息交換。 確認(rèn)登錄消息還可被用于密鑰相互確定。如果認(rèn)為當(dāng)前會(huì)話密鑰強(qiáng)度較弱，需要更換密鑰，那么就可通過發(fā)回帶有新密鑰的登錄消息來建議使用更強(qiáng)的會(huì)話密鑰。當(dāng)然，這僅僅對(duì)允許密鑰相互確認(rèn)的加密協(xié)議有意義。 登錄消息還可以用來指明最大消息長度（MaxMessageSize），也可以用來指明發(fā)送和接受時(shí)所支持的消息類型。 登錄消息格式見表５： 表５　登錄（Logon） Tag 域名 必需 說

49、明 標(biāo)準(zhǔn)消息頭 Y MsgType = A 98 EncryptMethod Y 加密方法(不可加密) 108 HeartBtInt Y 心跳間隔 95 RawDataLength N 無格式數(shù)據(jù)長度，用于認(rèn)證 96 RawData N 無格式數(shù)據(jù)，用于認(rèn)證 141 ResetSeqNumFlag N 序號(hào)重設(shè)標(biāo)志 383 MaxMessageSize N 最大消息長度，單條消息的最大字節(jié)數(shù) 384 NoMsgTypes N 消息類型個(gè)數(shù) à 372 RefMsgType N 消息類型 à 385 MsgDire

50、ction N 消息方向 464 TestMessageIndicator N 測試標(biāo)志，指明該會(huì)話是測試連接或正常運(yùn)行連接，用于防止意外 553 Username N 用戶名 554 Password N 密碼 標(biāo)準(zhǔn)消息尾 Y 10.3.3　 測試請(qǐng)求消息（MsgType=1） 測試請(qǐng)求消息能強(qiáng)制對(duì)方發(fā)出心跳消息。測試請(qǐng)求消息的作用是檢查對(duì)方消息序號(hào)和檢查通信線路的狀況。對(duì)方用帶有測試請(qǐng)求標(biāo)識(shí)符（TestReqID）的心跳作應(yīng)答。 測試請(qǐng)求標(biāo)識(shí)符（TestReqID）用以指明對(duì)方生成心跳消息是響應(yīng)測試請(qǐng)求而非正常超時(shí)引起的。對(duì)方發(fā)送心跳消息作

51、為應(yīng)答時(shí)，將測試請(qǐng)求標(biāo)識(shí)符（TestReqID）包括在消息中。任何字符串都可以用作測試請(qǐng)求標(biāo)識(shí)符（TestReqID）（可使用時(shí)間戳（timestamp））。 測試請(qǐng)求消息格式見表６： 表６　測試請(qǐng)求（Test Request） Tag 域名 必需 說明 標(biāo)準(zhǔn)消息頭 Y MsgType = 1 112 TestReqID Y 測試請(qǐng)求標(biāo)識(shí)符 標(biāo)準(zhǔn)消息尾 Y 10.3.4　 重發(fā)請(qǐng)求消息（MsgType=2） 重發(fā)請(qǐng)求消息由接收方發(fā)出，目的是向發(fā)送方申請(qǐng)某些消息重復(fù)發(fā)送。此功能用于：發(fā)現(xiàn)消息序號(hào)缺口、接收方丟失了消息和在初始化過程中也可能

52、使用。 重發(fā)請(qǐng)求消息能被用來請(qǐng)求重新發(fā)送單個(gè)消息、一系列的消息或在某一特定消息之后的所有消息。 當(dāng)重復(fù)發(fā)送消息的時(shí)候，發(fā)送方將考慮消息類型；如：在重復(fù)發(fā)送系列中有一條會(huì)話消息，由于過期而不再有效，發(fā)送方不需要重復(fù)傳輸這條消息。因此，當(dāng)發(fā)送方不重復(fù)發(fā)送某消息時(shí)，序號(hào)重設(shè)-缺口填補(bǔ)（SeqReset-Gap Fill）消息將被用來跳過消息。（注注：接收方按訂單順序進(jìn)行消息處理是非常有必要的。例如，如果訂單第7條消息被錯(cuò)過，而收到第8和第9條，那么應(yīng)用方將忽略8和9，然后要求重發(fā)送第7-第9，或者要求重新發(fā)送第7-第0（0表現(xiàn)無限）。在順序混亂的狀況中通常用后一方案恢復(fù)消息，因?yàn)楫?dāng)連接雙方都同時(shí)

53、試圖盡快恢復(fù)缺口的狀況下，此種方法能更快地進(jìn)行消息恢復(fù)。 ） 重發(fā)請(qǐng)求消息有以下幾種表示方式： l 請(qǐng)求重發(fā)一條消息：起始消息序號(hào)（BeginSeqNo）=結(jié)束消息序號(hào)（EndSeqNo） l 請(qǐng)求重發(fā)某個(gè)范圍內(nèi)的消息：起始消息序號(hào)（BeginSeqNo）=該范圍中的第1條消息，結(jié)束消息序號(hào)（EndSeqNo） =該范圍中的最后一條消息序號(hào) l 請(qǐng)求重發(fā)某一特定消息之后的所有的消息：起始消息序號(hào)（BeginSeqNo）=該范圍中的第1條消息，結(jié)束消息序號(hào)（EndSeqNo） =0（無限大）。 重發(fā)請(qǐng)求消息的格式見表７： 表７　重發(fā)請(qǐng)求（Resend Reque

54、st） Tag 域名 必需 說明 標(biāo)準(zhǔn)消息頭 Y MsgType = 2 7 BeginSeqNo Y 起始消息序號(hào) 16 EndSeqNo Y 結(jié)束消息序號(hào) 標(biāo)準(zhǔn)消息尾 Y 10.3.5　 會(huì)話拒絕消息（MsgType=3） 當(dāng)接收方收到一條消息時(shí)，由于違反了會(huì)話機(jī)制而造成不能適當(dāng)?shù)靥幚碓撓r(shí)，應(yīng)該發(fā)出會(huì)話拒絕消息。如：當(dāng)收到一條消息，這條消息雖成功地通過了解密、校驗(yàn)和和正文長度檢驗(yàn)，但卻被發(fā)現(xiàn)帶有無效的數(shù)據(jù)（如：消息類型（MsgType）=&），此時(shí)應(yīng)發(fā)出拒絕消息。 被拒絕的消息應(yīng)該寫入日志。 接收方應(yīng)該忽略任何被歪曲，

55、不能被解析，或數(shù)據(jù)完整性核對(duì)失敗的消息。立即對(duì)下一個(gè)有效的STEP消息進(jìn)行處理將會(huì)發(fā)現(xiàn)消息缺口，并且，將產(chǎn)生重發(fā)請(qǐng)求。在STEP交換引擎內(nèi)應(yīng)能夠識(shí)別這種無限重發(fā)循環(huán)。 當(dāng)產(chǎn)生和收到會(huì)話拒絕消息意味著出現(xiàn)了嚴(yán)重錯(cuò)誤，可能發(fā)送方或接收方的應(yīng)用存在邏輯錯(cuò)誤。 如果要重新傳輸拒絕消息，那么應(yīng)賦予該消息一個(gè)新的消息序號(hào)，并設(shè)置可能重發(fā)標(biāo)志（PossResend）為Y。 無論何時(shí)，本標(biāo)準(zhǔn)規(guī)定應(yīng)在正文域里盡可能描述拒絕原因。 如果所收到的應(yīng)用層消息遵循了會(huì)話機(jī)制，那么可以開始在業(yè)務(wù)層處理該消息。如果在處理過程中，發(fā)現(xiàn)違反業(yè)務(wù)規(guī)則，那么應(yīng)該發(fā)出業(yè)務(wù)層的“拒絕”消息。很多業(yè)務(wù)層的消息都有指定的“拒絕”消

56、息，此時(shí)這些消息可以發(fā)揮作用。其它無對(duì)應(yīng)會(huì)話拒絕消息的，則均可通過業(yè)務(wù)“拒絕”消息進(jìn)行拒絕。 會(huì)話拒絕消息格式見表８： 表８　會(huì)話拒絕（Reject） Tag 域名 必需 說明 標(biāo)準(zhǔn)消息頭 Y MsgType = 3 45 RefSeqNum Y 關(guān)聯(lián)消息序號(hào)，即被拒絕的消息序號(hào) 371 RefTagID N 相關(guān)錯(cuò)誤域號(hào) 372 RefMsgType N 相關(guān)錯(cuò)誤消息類型 373 SessionRejectReason N 會(huì)話拒絕原因編號(hào) 58 Text N 文本，可作解釋拒絕的原因 354 EncodedTextLen

57、N 編碼文本長度 355 EncodedText N 編碼文本（非ASCII碼） 標(biāo)準(zhǔn)消息尾 Y 會(huì)話拒絕原因見表９： 表９　會(huì)話拒絕原因 會(huì)話拒絕原因 0 = 存在無效的域號(hào) 1 = 該消息中必須的域丟失 2 = 該消息中出現(xiàn)未曾定義的域 3 = 未定義域號(hào) 4 = 域未賦值 5 = 域取值錯(cuò)誤（范圍溢出） 6 = 取值格式錯(cuò)誤 7 = 解密錯(cuò)誤 8 = 簽名錯(cuò)誤 9 = 公司標(biāo)識(shí)符錯(cuò)誤 10 = 發(fā)送時(shí)間精度錯(cuò)誤 11 = 無效的消息類型 12 = XML驗(yàn)證錯(cuò)誤（XML Validation error） 13 = 同一域多次出

58、現(xiàn)（非重復(fù)組） 14 = 有序的域出現(xiàn)次序錯(cuò)誤 15 = 重復(fù)組域次序錯(cuò)誤 16 = 重復(fù)組重復(fù)次數(shù)錯(cuò)誤 17 = 非data數(shù)據(jù)域中出現(xiàn)域界定符 10.3.6　 序號(hào)重設(shè)消息（MsgType=4） 序號(hào)重設(shè)消息由發(fā)送方發(fā)出，用于告知接收方下一個(gè)消息的消息序號(hào)。序號(hào)重設(shè)消息有兩種模式：序號(hào)重設(shè)-缺口填補(bǔ)（SeqReset-Gap Fill）；序號(hào)重設(shè)-重設(shè)（SeqReset -Reset）。序號(hào)重設(shè)-重設(shè)通常在災(zāi)難恢復(fù)情況下使用。 當(dāng)需要支持24小時(shí)的連接并用序號(hào)重設(shè)標(biāo)志（ResetSeqNumFlag）來建立新的一套消息序號(hào)的時(shí)候，關(guān)于連接雙方的序號(hào)重設(shè)時(shí)間和發(fā)起

59、方另行確定，但序號(hào)重設(shè)的發(fā)起方不同于登錄過程的發(fā)起方。其處理過程如下：其中一方先發(fā)送測試請(qǐng)求（TestRequest）。在收到心跳消息后，確認(rèn)沒有消息序號(hào)缺口后，發(fā)起方發(fā)送一條登錄消息，在該消息中應(yīng)附有設(shè)為Y的序號(hào)重設(shè)標(biāo)志（ResetSeqNumFlag），并且它的消息序號(hào)（MsgSeqNum）為1。接收方則應(yīng)該發(fā)送一條登錄消息作回應(yīng)，其中序號(hào)重設(shè)標(biāo)志（ResetSeqNumFlag）為Y，消息序號(hào)（MsgSeqNum）為1。此后，連接雙方發(fā)送出的消息的消息序號(hào)應(yīng)從2 開始。需要注意的是一旦發(fā)起方發(fā)送附有序號(hào)重設(shè)標(biāo)志（ResetSeqNumFlag）的登錄消息，那么接收人應(yīng)服從該請(qǐng)求，并且，“

60、昨天”傳送的消息不可能再重發(fā)。如果不遵守以上的處理規(guī)則應(yīng)立即中斷連接，并手工設(shè)置干預(yù)。 序號(hào)重設(shè)消息兩種模式表示： 當(dāng)GapFillFlag＝Y(jié)時(shí)，該消息為序號(hào)重設(shè)-缺口填補(bǔ)（SeqReset-Gap Fill），當(dāng)GapFillFlag＝N或沒有設(shè)置時(shí)，該消息為序號(hào)重設(shè)-重設(shè)（SeqReset-Reset）。 序號(hào)重設(shè)消息能在下列情況下使用： a) 在重新發(fā)送的處理過程中，發(fā)送方可以選擇不發(fā)送某個(gè)消息（例如一個(gè)會(huì)話消息）。序號(hào)重設(shè)-缺口填補(bǔ)（SeqReset-Gap Fill）能被用來填補(bǔ)那條消息。 b) 在重新發(fā)送的處理過程中，有大量的會(huì)話消息不需要發(fā)送，這樣產(chǎn)生的消

61、息序號(hào)缺口也可以由序號(hào)重設(shè)-缺口填補(bǔ)（SeqReset-Gap Fill）消息來填補(bǔ)。 c) 在應(yīng)用層失敗的情況下，有必要通過發(fā)送序號(hào)重設(shè)-重設(shè)（SeqReset-Reset）在發(fā)送和接收的連接雙方進(jìn)行強(qiáng)制消息序號(hào)同步。 在任何情況下，序號(hào)重設(shè)消息都指定了NewSeqNo（新的消息序號(hào)），并重設(shè)該值為下一個(gè)將被傳送消息的消息序號(hào)。 如果缺口填補(bǔ)標(biāo)志（GapFillFlag）域被設(shè)置為Y，那么消息序號(hào)（MsgSeqNum）域取值應(yīng)該遵循消息序號(hào)規(guī)則，即：序號(hào)重設(shè)-缺口填補(bǔ)（SeqReset-Gap Fill）消息的消息序號(hào)（MsgSeqNum）應(yīng)該對(duì)應(yīng)缺口范圍內(nèi)第一條消息的消息序號(hào)

62、，因?yàn)閷?duì)方正準(zhǔn)備接收這個(gè)消息序號(hào)的消息。 序號(hào)重設(shè)-缺口填補(bǔ)（SeqReset-Gap Fill）只能增加消息序號(hào)。如果收到的序號(hào)重設(shè)-缺口填補(bǔ)（SeqReset-Gap Fill）消息試圖使下一個(gè)預(yù)期的消息序號(hào)變小，那么此消息應(yīng)該被拒絕接受，并被視作為錯(cuò)誤。（注注：如可能存在接收方發(fā)送多個(gè)重發(fā)請(qǐng)求（如先請(qǐng)求重發(fā)5～10，隨后請(qǐng)求重發(fā) 5～11）。如果消息序號(hào)8，10和11表示應(yīng)用消息，而5-7和9表示會(huì)話消息，那么為響應(yīng)該重發(fā)請(qǐng)求，有一些應(yīng)用消息需被重新發(fā)送，首先發(fā)送的SeqReset-GapFill中新消息序號(hào)（NewSeqNo）設(shè)置為8，即第8條消息；完成重發(fā)應(yīng)用消息后，發(fā)送Seq

63、Reset-GapFill且新消息序號(hào)（NewSeqNo）設(shè)置為10，即第10條消息，接著完成重發(fā)應(yīng)用消息。隨后又可能發(fā)送SeqReset-GapFill且新消息序號(hào)（NewSeqNo）設(shè)置為8，即第8條消息（序號(hào)變小）；完成重發(fā)應(yīng)用消息后，發(fā)送SeqReset-GapFill且新消息序號(hào)（NewSeqNo）設(shè)置為10，即第10條消息，以及第11條消息，接著完成重發(fā)應(yīng)用消息。此時(shí)接收方通過檢查在序號(hào)重設(shè)-缺口填補(bǔ)（SeqReset-Gap Fill）中的新消息序號(hào)（NewSeqNo）是否比預(yù)期的小可發(fā)現(xiàn)此種錯(cuò)誤。如果發(fā)現(xiàn)有這種錯(cuò)誤，那么說明該序號(hào)重設(shè)-缺口填補(bǔ)（SeqReset-Gap Fil

64、l）是重復(fù)的，應(yīng)該放棄處理。 ） 如果缺口填補(bǔ)標(biāo)志（GapFillFlag）域沒有出現(xiàn)（或被設(shè)為N），即為序號(hào)重設(shè)-重設(shè)（SeqReset-Reset）消息，那么有可能是此序號(hào)重設(shè)-重設(shè)（SeqReset-Reset）消息的目的是恢復(fù)混亂順序的消息。此時(shí)消息頭里的消息序號(hào)（MsgSeqNum）應(yīng)該忽略。禁止在重發(fā)請(qǐng)求的正?；貞?yīng)中使用序號(hào)重設(shè)-重設(shè)（SeqReset-Reset）（應(yīng)使用序號(hào)重設(shè)-缺口填補(bǔ)（SeqReset-Gap Fill））。序號(hào)重設(shè)-重設(shè)（SeqReset-Reset）僅用于無法用序號(hào)重設(shè)-缺口填補(bǔ)（SeqReset-Gap Fill）進(jìn)行恢復(fù)的災(zāi)難情況。注意使

65、用序號(hào)重設(shè)-重設(shè)（SeqReset-Reset）可能會(huì)造成消息丟失。 序號(hào)重設(shè)消息格式見表１０： 表１０　序號(hào)重設(shè)（Sequence Reset） Tag 域名 必需 說明 標(biāo)準(zhǔn)消息頭 Y MsgType = 4 123 GapFillFlag N 缺口填補(bǔ)標(biāo)志 36 NewSeqNo Y 新消息序號(hào) 標(biāo)準(zhǔn)消息尾 Y 10.3.7　 注銷消息（MsgType=5） 注銷消息是發(fā)起或確認(rèn)STEP會(huì)話終止的消息。未經(jīng)注銷消息交換而斷開連接，一律視為非正常的斷開。 在最后終止會(huì)話之前，注銷的發(fā)起人應(yīng)該等待連接對(duì)方確認(rèn)注銷消息。這使得連接

66、對(duì)方有了實(shí)施任何有必要的缺口填補(bǔ)的機(jī)會(huì)。如果連接對(duì)方?jīng)]有在適當(dāng)?shù)臅r(shí)間間隔里作回應(yīng)，那么會(huì)話就可以終止。 注銷發(fā)起人在發(fā)送注銷消息之后不應(yīng)發(fā)送任何消息，除非接收到連接對(duì)方發(fā)出的重發(fā)請(qǐng)求消息。 注銷消息格式見表１１： 表１１　注銷（Logout） Tag 域名 必需 說明 標(biāo)準(zhǔn)消息頭 Y MsgType = 5 58 Text N 文本 354 EncodedTextLen N 編碼文本長度 355 EncodedText N 編碼文本（非ASCII碼） 標(biāo)準(zhǔn)消息尾 Y 10.4　 應(yīng)用消息 10.4.1　 應(yīng)用消息組件 應(yīng)用消息中有很多共用的數(shù)據(jù)域集合——組件。比如說，大多數(shù)應(yīng)用消息都會(huì)用到一系列定義證券品種的數(shù)據(jù)域：Symbol, SecurityIDSource, SecurityID, ……。為避免重復(fù)，本標(biāo)準(zhǔn)中定義了一些關(guān)鍵組件，在應(yīng)用消息定義中直接用名稱引用這些組件。實(shí)際的消息定義和使用中，則應(yīng)該將組件擴(kuò)展開成為相應(yīng)的數(shù)據(jù)域集合。 組件可以是重復(fù)組的部分，此時(shí)組件對(duì)應(yīng)的整組數(shù)據(jù)域都位于組件所