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

JR/T 0022—2004 目 次 前 言 III 證券交易數(shù)據(jù)交換協(xié)議 1 1 范圍 1 2 規(guī)范性引用文件 1 3 術(shù)語和定義 1 4 應(yīng)用環(huán)境 2 5 會話機(jī)制 2 5.1 STEP會話 2 5.1.1 消息序號 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 整數(shù)int 5 6.1.2 浮點(diǎn)數(shù)float 6 6.1.3 單個字符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 會話消息 10 10.3.1 心跳消息（MsgType=0） 10 10.3.2 登錄消息（MsgType=A） 11 10.3.3 測試請求消息（MsgType=1） 11 10.3.4 重發(fā)請求消息（MsgType=2） 12 10.3.5 會話拒絕消息（MsgType=3） 12 10.3.6 序號重設(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 注冊類 25 10.4.4 行情 26 10.4.5 市場控制 30 11 數(shù)據(jù)字典 32 附　錄　A 應(yīng)用環(huán)境參考實(shí)例 61 附　錄　B 重復(fù)組實(shí)例 62 附　錄　C 缺口填補(bǔ)方式 63 附　錄　D 會話連接場景 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ù)委員會歸口。 本標(biāo)準(zhǔn)起草單位：中國證券監(jiān)督管理委員會信息中心承擔(dān)，上海證券交易所負(fù)責(zé)起草，深圳證券交易所、上海期貨交易所、國信證券公司、泰陽證券公司、華夏證券公司參與制訂。 本標(biāo)準(zhǔn)的主要起草人：楊淑琴、許強(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)境、會話機(jī)制、消息格式、安全與加密、數(shù)據(jù)完整性、擴(kuò)展方式、消息定義、數(shù)據(jù)字典等內(nèi)容。 本標(biāo)準(zhǔn)適用于證券交易所與市場參與者和相關(guān)金融機(jī)構(gòu)間的業(yè)務(wù)數(shù)據(jù)交換。 本標(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)，然而，鼓勵根據(jù)本標(biāo)準(zhǔn)達(dá)成協(xié)議的各方研究是否可使用這些文件的最新版本。凡是不注明日期的引用文件，其最新版本適用于本標(biāo)準(zhǔn)。 GB/T 2659 世界各國和地區(qū)名稱代碼 GB/T 12406 表示貨幣和資金的代碼 ISO 10383 交易所和市場代碼標(biāo)志識別碼(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-Single 交易客戶方新產(chǎn)生的訂單。 3.3　 執(zhí)行報告 Execution Report 交易服務(wù)方響應(yīng)交易客戶方的消息，主要用于：訂單確認(rèn)、訂單狀態(tài)變化確認(rèn)（如撤單確認(rèn)和修改單確認(rèn)）、發(fā)送訂單的成交回報、訂單拒絕。 3.4　 指定交易 Designated Trading 將證券賬號與某一證券營業(yè)部所屬的參與者業(yè)務(wù)單元（如席位號）相聯(lián)系，從而限定該證券賬號的交易應(yīng)在該參與者業(yè)務(wù)單元下進(jìn)行的交易方式。 3.5　 轉(zhuǎn)托管 Designation Transfer 投資者將其托管在某一券商處的證券轉(zhuǎn)到另一券商處托管的行為，并且投資者只能將證券在其托管的券商處賣出。 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è)部、交易所會員等。 4　 應(yīng)用環(huán)境 證券交易數(shù)據(jù)交換協(xié)議應(yīng)用環(huán)境請參考附錄A應(yīng)用環(huán)境參考實(shí)例。 5　 會話機(jī)制 5.1　 STEP會話 5.1.1　 消息序號 任何一條消息都被分配有一個消息序號來唯一標(biāo)識，消息序號在每次會話過程中從1開始，在整個會話過程中連續(xù)遞增，直到該會話過程全部結(jié)束。通過監(jiān)視消息序號的連續(xù)性可以知道交換中的消息缺口，并做出反應(yīng)，使得連接雙方數(shù)據(jù)同步。 連接雙方都明確確定相互獨(dú)立的消息序號，參與連接的任何一方負(fù)責(zé)維護(hù)自己發(fā)送的消息序號，并監(jiān)視接收的消息序號以保證消息缺口的發(fā)現(xiàn)和處理。 5.1.2　 心跳 在消息交換的空閑期間，連接雙方將會產(chǎn)生有規(guī)則的心跳消息。通過心跳消息可以監(jiān)控通訊連接的狀態(tài)。心跳間隔時間由會話發(fā)起人在登錄時確定。在發(fā)送任何消息后，應(yīng)立即重新設(shè)置心跳間隔計(jì)時器。心跳間隔時間應(yīng)該得到連接雙方的確認(rèn)，由登錄發(fā)起人給出并得到登錄接受方的確認(rèn)。連接雙方使用相同心跳間隔時間。 5.1.3　 缺口填補(bǔ) 由于協(xié)議是基于樂觀的消息傳輸模式，消息在傳輸過程中可能存在丟失，而這種消息丟失發(fā)送方不能檢測，因此接收方應(yīng)負(fù)責(zé)檢測消息的缺口并處理。有兩種處理方法：接收方發(fā)現(xiàn)缺口后向發(fā)送方請求發(fā)送缺口消息及其后的所有消息；接收方發(fā)現(xiàn)缺口后，保存已收到消息，并向發(fā)送方請求重復(fù)發(fā)送缺口消息。 5.1.4　 消息重復(fù)發(fā)送 響應(yīng)一個重發(fā)請求而重復(fù)發(fā)送消息時，或者不確定對方是否收到某消息而重復(fù)發(fā)送該消息時，要求在該消息內(nèi)加上可能重復(fù)標(biāo)志（Possible Duplicate=Y）。如何處理該消息則是接收方的事情。由于當(dāng)生成有此類可能重復(fù)發(fā)送的消息時，仍使用該消息的原來序號，但某些信息可能會改變，如原始時間、發(fā)送時間、正文長度、可能重復(fù)標(biāo)志等，所以應(yīng)重新計(jì)算校驗(yàn)和。 5.1.5　 消息重新發(fā)送 基于應(yīng)用層的可能重發(fā)，如發(fā)送的訂單在相當(dāng)長的時間內(nèi)沒有確認(rèn)，或者懷疑其根本未曾發(fā)送過，可以通過設(shè)置可能重新發(fā)送標(biāo)志來重新發(fā)送(Possible Resend=Y) ，并使用新的消息序號。接收方應(yīng)用層收到該類消息后，應(yīng)通過查詢消息內(nèi)的域（如訂單編號等）來確定此前是否收到此條消息。該類消息應(yīng)確定包含相同的正文數(shù)據(jù)，同樣，由于某些信息可能會改變，所以應(yīng)重新計(jì)算校驗(yàn)和。 5.1.6　 消息確認(rèn) 由于協(xié)議是基于樂觀的消息傳輸模式，通過監(jiān)視消息序號發(fā)現(xiàn)缺口，不支持對每個消息收發(fā)的確認(rèn)。但大量消息收發(fā)的確認(rèn)可在應(yīng)用層定義。在應(yīng)用層接受和拒絕是允許的，如訂單的確認(rèn)。 5.2　 STEP連接（會話） 會話過程的數(shù)據(jù)交換可以這樣描述：連接雙方各有一個連續(xù)的消息序號隨消息傳送，而交易期間可以多次斷開并重新連接，其斷開的原因可以是外因引起，也可以是連接雙方根據(jù)系統(tǒng)來統(tǒng)一制定何時斷開并重新連接。一次會話連接通常不應(yīng)超過24小時，當(dāng)然，如需要保持24小時以上的連接，則需要發(fā)送一條含有序號重設(shè)標(biāo)志的登錄消息來建立新的起始消息序號。 STEP連接分為三個部分：登錄、消息交換、注銷。 STEP會話包含一個或多個STEP連接，即一個STEP會話可以跨越多個登錄。 5.2.1　 登錄 登錄連接包含三個步驟：建立電信通訊連接、連接雙方的確認(rèn)/認(rèn)證、消息傳輸同步的初始化。主要有以下幾點(diǎn)： 5.2.1.1　 連接 會話的發(fā)起方與接收方建立電信通訊連接。 5.2.1.2　 認(rèn)證 發(fā)起方發(fā)送登錄消息（Logon），接收方認(rèn)證發(fā)起方身份的合法性。登錄消息應(yīng)包括認(rèn)證的必要數(shù)據(jù)，如用戶名、密碼等。如果發(fā)起方身份通過認(rèn)證，則接收方發(fā)送一個登錄消息作回應(yīng)。如果認(rèn)證失敗，會話接收方則在發(fā)送一個含失敗說明的注銷消息（Logout）后關(guān)閉連接。不過發(fā)送注銷消息并非是必須的，因?yàn)樵谀承┣闆r下往往會引起其他問題。在發(fā)起方收到接收方的登錄消息之后即可認(rèn)為會話連接建立完成。會話發(fā)起方可以緊隨登錄消息之后開始發(fā)送其他消息。 通常在登錄后或者剛發(fā)送完測試請求消息（TestRequest）時延遲等待一段時間，然后再發(fā)送新的消息，使得連接雙方能有效控制重發(fā)請求。否則可能會導(dǎo)致一方會針對對方的每一條新消息發(fā)出重發(fā)請求。 5.2.1.3　 初始化 在身份通過認(rèn)證之后，發(fā)起方和接收方應(yīng)首先同步消息序號，然后才能相互發(fā)送新的信息。同步消息序號通過消息序號域（MsgSeqNum）來確定，將登錄消息里的消息序號（MsgSeqNum）與內(nèi)部監(jiān)控的下一個預(yù)期的消息序號進(jìn)行比較就能發(fā)現(xiàn)消息的消息序號缺口。同樣，發(fā)起方通過將接收方發(fā)送的登錄消息里的消息序號（MsgSeqNum）與下一個預(yù)期的消息序號進(jìn)行比較也能發(fā)現(xiàn)消息的缺口。 5.2.2　 消息交換 在以上初始化完成之后，可以開始進(jìn)行信息交換。所有有效消息的格式將在“會話消息”和“應(yīng)用消息”部分中詳細(xì)敘述。 5.2.3　 注銷 會話的正常結(jié)束是通過連接雙方互相發(fā)送注銷消息（Logout）完成的。若結(jié)束時沒有收到回送的注銷消息（Logout），則把對方視作已注銷。除此之外的其它方式的會話結(jié)束視為非正常，并應(yīng)按錯誤來處理。 在發(fā)送注銷消息（Logout）之前，應(yīng)發(fā)送測試請求消息（TestRequest）以要求對方的心跳信息，這有助于保證不出現(xiàn)消息序號缺口。 在結(jié)束會話之前，注銷消息（Logout）的發(fā)起方應(yīng)該等待對方回送的注銷消息（Logout），這樣給接收方一個填補(bǔ)缺口的機(jī)會。待重發(fā)請求的信息全部收到后，接收方才可發(fā)送應(yīng)答的注銷消息（Logout）。如果接收方在一定時間內(nèi)沒有答復(fù)，那么會話就可以立即中斷。（注注：注銷不影響任何訂單的狀況。所有有效的訂單都可在注銷（Logout）之后執(zhí)行。 ） 5.2.4　 消息恢復(fù) 以下描述了有關(guān)恢復(fù)消息的具體方法。 每一方必須維護(hù)兩個消息序號，一個為了發(fā)送，一個為了接收。 當(dāng)接收進(jìn)來的消息序號與預(yù)期的消息序號不相符合時，需進(jìn)行修正處理。但需要注意的是，如果接收進(jìn)來的是序號重設(shè)-重設(shè)（SeqReset-Reset）消息則不需要修正處理，因?yàn)樘幚碓撓r不必考慮它的消息序號。如果接收的消息的消息序號比預(yù)期的消息序號小，而且沒有設(shè)置可能重復(fù)標(biāo)志（PossDupFlag），那么表明發(fā)生了嚴(yán)重的錯誤。因此必須立即結(jié)束會話，并開始進(jìn)行人工干預(yù)。如果接收進(jìn)來的消息序號比預(yù)期的大，那么表明有消息被遺漏，應(yīng)通過發(fā)送重發(fā)請求申請?zhí)钛a(bǔ)缺口。 當(dāng)收到重發(fā)請求時，重發(fā)人可以作出回應(yīng)為以下三種之一：（注注：本文中請求人指的是提出重發(fā)請求的那一方，重發(fā)人指的是回應(yīng)重發(fā)請求的那一方。 ） a) 作為正常回應(yīng)，重發(fā)人按順序發(fā)送被請求的消息，這些消息的消息序號仍為原消息序號，并且將可能重復(fù)的標(biāo)志（PossDupFlag）置位為“Y”。 b) 作為正?；貞?yīng)，重發(fā)人發(fā)送序號重設(shè)-缺口填補(bǔ)（SeqReset-GapFill）消息，可能重復(fù)標(biāo)志（PossDupFlag）置位為“Y”，以表示刪除過時或多余的消息。 c) 作為非正?；貞?yīng)，重發(fā)人發(fā)送序號重設(shè)-重設(shè)（SeqReset-Reset）消息，可能重復(fù)的標(biāo)志（PossDupFlag）置位為“Y”，以強(qiáng)制消息序號同步。 在缺口填補(bǔ)過程中，不需要重新發(fā)送某些會話消息。取而代之的是一種特殊的序號重設(shè)-缺口填補(bǔ)（SeqReset-GapFill）消息。不需要重新發(fā)送的會話消息是：登錄、注銷、重發(fā)請求、心跳、測試請求、序號重設(shè)-重設(shè)（SeqReset-Reset ）和序號重設(shè)-缺口填補(bǔ)（SeqReset-GapFill）。這樣會話拒絕消息便成為了唯一可能被重新發(fā)送的會話消息。 會話過程中應(yīng)監(jiān)視接收進(jìn)來的消息以便發(fā)現(xiàn)由于疏漏而被對方重新發(fā)送了的會話消息（設(shè)置了可能重復(fù)標(biāo)志（PossDupFlag）的）。當(dāng)收到這些消息以后，處理時，只要確保它們具有消息序號的完整性即可，而忽略對它們的業(yè)務(wù)或應(yīng)用的處理。 如果碰到多個連續(xù)的不需要重發(fā)的會話消息，則只需發(fā)送一個序號重設(shè)-缺口填補(bǔ)（SeqReset-GapFill）消息取而代之。該序號重設(shè)-缺口填補(bǔ)消息的消息序號是下一個預(yù)期的消息序號。序號重設(shè)-缺口填補(bǔ)（SeqReset-GapFill）消息的新消息序號（NewSeqNo）為本連續(xù)會話消息段中最大消息序號+1。（注注：如在重新發(fā)送操作期間，有7條連續(xù)的會話消息等待發(fā)送，他們以消息序號9開始和以消息序號15結(jié)束，此時只發(fā)送一個序號重設(shè)-缺口填補(bǔ)（SeqReset-GapFill）消息來代替那7條消息，那么該序號重設(shè)-缺口填補(bǔ)（SeqReset-GapFill）消息的消息序號是9，這是因?yàn)橐薪由蠗l消息而保持消息序號的連續(xù)性；其中新消息序號（NewSeqNo）是16，這樣使得對方知道下一消息發(fā)送時的消息序號。 ） 在缺口被填補(bǔ)完成之后，交換引擎應(yīng)將無序的消息暫時保存為有序的排列并按順序?qū)λ鼈冞M(jìn)行處理。這樣防止出現(xiàn)對n->m,n->m+1,n->m+2,…的重發(fā)請求，從而導(dǎo)致了大量的可能重復(fù)（PossDupFlag=’Y’）標(biāo)記。 檢驗(yàn)消息序號的連續(xù)在會話過程管理中是必不可少的部分。不過，針對消息類型的不同，處理消息序號流的差異也就不同。下列的表１列出了當(dāng)進(jìn)來的消息序號大于預(yù)期消息序號時而應(yīng)采取的措施。 （注注：在任何情況下，除了序號重設(shè)－重設(shè)消息外，如果進(jìn)來的消息序號比預(yù)期的消息序號小，而且可能重復(fù)標(biāo)志（PossDupFlag）沒有被設(shè)置，那么應(yīng)立即終止會話過程。并應(yīng)在結(jié)束會話之前，向?qū)Ψ桨l(fā)送帶有解釋正文的注銷（Logout）消息。 ） 表１ 消息類型 針對消息序號錯誤所采取的措施 登錄 永遠(yuǎn)是連接雙方發(fā)送的第一條消息，用于認(rèn)證和連接。如果發(fā)現(xiàn)登錄消息中有缺口，則應(yīng)在回送登錄確認(rèn)消息之后立即發(fā)送重發(fā)請求 注銷 如果發(fā)現(xiàn)有缺口，應(yīng)發(fā)送重發(fā)請求消息以重新接收所有丟失的消息，然后再發(fā)送注銷消息作為對注銷請求的確認(rèn)。注意嚴(yán)禁在有缺口情況下結(jié)束會話。并由注銷的最初發(fā)起人負(fù)責(zé)結(jié)束會話，因此注銷發(fā)起人有責(zé)任回應(yīng)所有的重發(fā)請求 重發(fā)請求 首先處理完對方的重發(fā)請求，隨后發(fā)送自己的重發(fā)請求以填補(bǔ)消息序號錯誤而發(fā)現(xiàn)的消息缺口。 序號重設(shè)-重設(shè) 可以忽略消息序號錯誤。因?yàn)樵谛蛱栔卦O(shè)-重設(shè)（SeqReset-Reset）消息中的新消息序號（NewSeqNo）強(qiáng)制為下一發(fā)送消息的消息序號。 序號重設(shè)-缺口填補(bǔ) 應(yīng)立即向?qū)Ψ桨l(fā)送重發(fā)請求。但是，重要的是要確保沒有無意間跳過任何消息，這意味著缺口填補(bǔ)消息應(yīng)按次序被接收到，如果次序不對，那么表示出現(xiàn)了非正常的情況 所有其它信息 執(zhí)行正常的缺口填補(bǔ)。 6　 消息格式 6.1　 數(shù)據(jù)類型 數(shù)據(jù)類型用于定義數(shù)據(jù)域的取值類型，本標(biāo)準(zhǔn)由幾個基本的數(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 無逗號和小數(shù)位的序號，可表示正負(fù)（ASCII碼字符‘-’,‘0’至‘9’組成）。符號占據(jù)一個字符位置。允許前置字符零（例：“00023”=“23”）。 整數(shù)類型的擴(kuò)展定義： 長度Length:以整數(shù)表示字節(jié)為單位的數(shù)據(jù)長度，正數(shù)。 重復(fù)數(shù)NumInGroup:以整數(shù)表示重復(fù)組的個數(shù)，正數(shù)。 消息序號SeqNum:以整數(shù)表示消息序號，正數(shù)。 域號TagNum:以整數(shù)表示的域號（或稱Ｔａｇ），正數(shù)，首位不能為零。 月日期號 DayOfMonth：以整數(shù)表示的月份中第幾天，取值1至31。 6.1.2　 浮點(diǎn)數(shù)float 含有可選的小數(shù)部分，可表示正負(fù)（ASCII碼字符‘-’,‘0’至‘9’和‘.’組成）。最多15位有效數(shù)字。允許前置字符零（例：“00023”=“23”）。允許小數(shù)部分后置字符零（例：“23.0”=“23.0000”=“23”）。 浮點(diǎn)數(shù)類型的擴(kuò)展定義： 除非特別聲明，浮點(diǎn)數(shù)類型均有正負(fù)。 量Qty: 股份數(shù)量、資產(chǎn)數(shù)量等，可以有小數(shù)部分。 價格Price:小數(shù)位數(shù)可變。 價格偏移量PriceOffset:代表價格偏移量的浮點(diǎn)域。 金額Amt: 典型的價格與數(shù)量相乘結(jié)果，如成交金額。 百分比Percentage:小數(shù)表示方法：.05代表5%。 6.1.3　 單個字符char 指除界定符外所有字母字符和標(biāo)點(diǎn)字符，區(qū)分字母大小寫。 字符類型的擴(kuò)展定義： 布爾Boolean: 該域取值于兩個字符，（’Y’=True/Yes,’N’=False/No） 6.1.4　 字符串String 區(qū)分字母大小寫。 字符串類型的擴(kuò)展定義： 多元值字符串MultipleValueString: 用空格分隔。 國家Country: 參見GB/T 2659。 字符串貨幣類型Currency: 參見GB/T 12406。 交易所或市場編號Exchange: 字符串，參見ISO10383。 年月日期month-year: 格式Y(jié)YYYMM或YYYYMMDD或YYYYMMWW，YYYY = 0000-9999, MM = 01-12，DD = 01-31，WW = w1,w2,w3,w4,w5。 國際標(biāo)準(zhǔn)時時間戳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)時時間UTCTimeOnly:格式 HH:MM:SS或HH:MM:SS.sss， HH = 00-23, MM = 00-59, SS = 00-60 (秒)，sss=000-999 (毫秒)。 國際標(biāo)準(zhǔn)時日期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ù)域兩個部分，數(shù)據(jù)域數(shù)據(jù)可以包含數(shù)值0x01，長度域指明數(shù)據(jù)域的字節(jié)數(shù)。 6.2　 域 域是基本的數(shù)據(jù)元素，每個域有其域號、業(yè)務(wù)含義和確定的取值范圍，域號統(tǒng)一分配給不同的域，是域的區(qū)分標(biāo)志，在消息中，通過域號來確定不同的域。域的數(shù)據(jù)類型決定了其取值類型，域的取值范圍可以是一個集合，任何在此集合外的取值被認(rèn)為是非法取值。數(shù)據(jù)字典部份詳細(xì)定義了所有域的業(yè)務(wù)定義、數(shù)據(jù)類型和取值范圍。 6.2.1　 域的使用 在消息中，域的使用有三種方式：必須的，可選的，條件限制選擇（即根據(jù)其他相關(guān)域的存在與否或取值來決定）。作為一個完整的消息，必須域和條件限制選擇域是需要包含的。 6.2.2　 自定義域 如本標(biāo)準(zhǔn)中定義的域不夠使用時，證券交易所或市場參與者可以擴(kuò)展定義新的域，即自定義域。 6.2.3　 域漢字編碼 域取值為漢字時需要使用統(tǒng)一的GBK漢字編碼標(biāo)準(zhǔn)，。 6.2.4　 域界定 消息中所有的域（包含data類型數(shù)據(jù)域）都有一個分隔符來界定分隔，該分隔符就是不可打印字符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)格由多個“域號=值”的基本結(jié)構(gòu)組成，“域號=值”基本結(jié)構(gòu)用域界定符分隔。消息組成結(jié)構(gòu)如圖１： 圖１：消息格式 消息由消息頭、消息的正文和消息尾組成。同樣，每個組成部份都由一系列“域號=值”組成，并且在遵循以下規(guī)則前提下“域號=值”基本結(jié)構(gòu)可以是任意的次序： a) 開始部分應(yīng)是消息頭，隨后是正文，最后是消息尾； b) 消息頭的前3個域的次序不能改變：起始串（Tag =8）、消息體長度（Tag =9）、消息類型（Tag =35）； c) 消息尾的最后一個域應(yīng)是校驗(yàn)和域（Tag =10）； d) 重復(fù)組中，域出現(xiàn)的順序應(yīng)遵循該重復(fù)組在消息或組件中定義時的次序。 e) 在一條消息中，除重復(fù)組域外任何其他域不能重復(fù)出現(xiàn)。 （消息格式的例子見注注： ８＝ＳＴＥＰ．１．０．０＜ＳＯＨ＞９＝１１２＜ＳＯＨ＞３５＝Ｄ＜ＳＯＨ＞４９＝ＢＲＫＲ＜ＳＯＨ＞５６＝ＩＮＶＭＧＲ＜ＳＯＨ＞３４＝２３５＜ＳＯＨ＞５２＝２００３０６２０－０９：３５：２７＜ＳＯＨ＞１１＝０００００７＜ＳＯＨ＞２１＝２＜ＳＯＨ＞５５＝青島啤酒＜ＳＯＨ＞４８＝６００６００＜ＳＯＨ＞ ５４＝１＜ＳＯＨ＞４４＝８．５２０ ＜ＳＯＨ＞ ３８＝１０００ ＜ＳＯＨ＞ ６０＝２００３０６２０－０９：３５：２８＜ＳＯＨ＞４０＝２＜ＳＯＨ＞１０＝１５７＜ＳＯＨ＞ ） 6.2.6　 重復(fù)組 域可以在重復(fù)組里多次重復(fù)，用以傳輸數(shù)組類的數(shù)據(jù)。通常域名起始為’No’字符的域指明重復(fù)的次數(shù)，并位于重復(fù)組的開始處。本文檔中重復(fù)組的定義通過縮進(jìn)的符號表示，重復(fù)組也可嵌套。使用子重復(fù)組時不能省略父重復(fù)組。 具體可參考附錄B重復(fù)組實(shí)例。 7　 安全與加密 由于消息有可能在公網(wǎng)或不安全的網(wǎng)絡(luò)上傳輸交換，因此需要對相關(guān)的敏感數(shù)據(jù)加密處理。 具體加密的方法由連接雙方達(dá)成的協(xié)議而定。 消息內(nèi)除某些需要公開識別的域以明文傳輸外其他任何域都可以加密放置密文數(shù)據(jù)域（SecureData）內(nèi)。當(dāng)然，這些被加密的域也可以同時保留明文的表示方式。 當(dāng)決定使用加密方案時，可以對消息正文內(nèi)所有的域加密。如果消息的重復(fù)組內(nèi)有部分需要加密的，那么要求對整個重復(fù)組加密。 本協(xié)議還提供的一些域用以支持?jǐn)?shù)字簽名、密鑰交換和正文加密等安全技術(shù)。 正文加密方案有三種： a) 將安全敏感的域加密后移至SecureData域。 b) 將所有允許加密的域加密后移至SecureData域。 c) 將所有允許加密的域加密后移至SecureData域，同時這些域以明文在消息中重復(fù)出現(xiàn)。 8　 數(shù)據(jù)完整性 數(shù)據(jù)的完整性通過兩個方法保證：消息體長度和校驗(yàn)和的驗(yàn)證。 消息體長度是以BodyLength域來表示，其值是計(jì)算出的消息長度域后面的字符數(shù)，包含緊靠校驗(yàn)和域標(biāo)志‘10=’之前的界定符SOH。 校驗(yàn)和是把每個字符的二進(jìn)制值從消息開頭‘8=’中的‘8’開始相加，一直加到緊靠在校驗(yàn)和域‘10=’之前的域界定符，然后取按256取模得到的結(jié)果。 校驗(yàn)和域位于消息的最末 一個，校驗(yàn)和的計(jì)算是在加密之后進(jìn)行的。計(jì)算校驗(yàn)和的代碼段可參考附錄F計(jì)算校驗(yàn)和。 9　 擴(kuò)展方式 9.1　 擴(kuò)展分類 擴(kuò)展分為兩個部分：消息定義擴(kuò)展和域定義擴(kuò)展。 消息定義擴(kuò)展可以通過新增消息類型來實(shí)現(xiàn)，但盡量在已有消息中通過域定義或取值擴(kuò)展來定義新業(yè)務(wù)。已有消息所代表的業(yè)務(wù)在擴(kuò)展時不能改變。 域定義擴(kuò)展可以通過新增域來實(shí)現(xiàn)，但盡量通過擴(kuò)展域值來擴(kuò)展域的定義。消息中已定義的必須的域不能取消定義，也不能改變成可選域。 9.2　 擴(kuò)展規(guī)則 自定義消息的消息類型值首字符為‘U’。其他類型的消息由全國金融標(biāo)準(zhǔn)化技術(shù)委員會根據(jù)國際相關(guān)標(biāo)準(zhǔn)的變化統(tǒng)一定義并發(fā)布。 消息和域臨時定義原則：上海證券交易所臨時定義消息的消息類型值首兩位字符為‘UA’，深圳證券交易所臨時定義消息的消息類型值首兩位字符為‘UB’；消息和域的臨時定義應(yīng)同時報備至全國金融標(biāo)準(zhǔn)化技術(shù)委員會。 域號1-4999由全國金融標(biāo)準(zhǔn)化技術(shù)委員會根據(jù)國際標(biāo)準(zhǔn)的變化統(tǒng)一定義并發(fā)布，該域區(qū)間只有全國金融標(biāo)準(zhǔn)化技術(shù)委員會有權(quán)擴(kuò)展、修改和發(fā)布；域號8500-8999由全國金融標(biāo)準(zhǔn)化技術(shù)委員會自行定義，其中8800-8999為臨時定義區(qū)間；臨時定義區(qū)間中域號8800-8899為全國金融標(biāo)準(zhǔn)化技術(shù)委員會授權(quán)上海證券交易所市場臨時定義區(qū)間，域號8900-8999為全國金融標(biāo)準(zhǔn)化技術(shù)委員會授權(quán)深圳證券交易所市場臨時定義區(qū)間。域號10000以上由連接雙方自行約定定義。 消息的模塊順序在擴(kuò)展定義時不能改變，即保持消息頭、消息體和消息尾的順序。而模塊的內(nèi)部，域和重復(fù)組的順序是可以變化的。 消息頭的頭三個域的定義和位置不能改變，但可以擴(kuò)展增加消息頭的可選域。 消息尾最后一個域的定義和位置不能改變，但可以擴(kuò)展增加消息尾的可選域。 9.3　 版本管理 本協(xié)議的版本管理權(quán)屬于全國金融標(biāo)準(zhǔn)化技術(shù)委員會。 版本號格式為X.Y.Z，版本號從1.0.0起始，當(dāng)新版本完全兼容上一版本時只改變版本號中的Z。 本協(xié)議當(dāng)前版本的版本號為1.0.0。 全國金融標(biāo)準(zhǔn)化技術(shù)委員會定期審核臨時定義，并在新版本中統(tǒng)一定義發(fā)布，同時取消相關(guān)臨時定義。 10　 消息定義 10.1　 消息頭 每一個會話或應(yīng)用消息有一個消息頭，該消息頭指明消息類型、消息體長度、發(fā)送目的地、消息序號、發(fā)送起始點(diǎn)和發(fā)送時間。 其中有兩個域用于消息重發(fā)，對于會話級的事件而重復(fù)發(fā)送消息時將可能重復(fù)發(fā)送標(biāo)志(PossDupFlag)設(shè)置為Y（發(fā)送時用原來的消息序號），當(dāng)重新發(fā)送時使用新的消息序號時將可能重新發(fā)送標(biāo)志（PossResend）設(shè)置為Y，接受者應(yīng)按以下方法處理上述消息： 可能重復(fù)發(fā)送：如果帶有該消息序號的消息在以前曾經(jīng)接受過，則忽略消息，如果未曾收到過，則按正常步驟處理。 可能重新發(fā)送：將消息傳遞給應(yīng)用層以確定此前是否收到該消息（通過檢查訂單編號或相關(guān)參數(shù)）。 消息頭格式見表２： 表２　消息頭 Tag 域名 必需 說明 8 BeginString Y 起始串STEP.1.0.0 (不可加密，消息的第一個域) 9 BodyLength Y 消息體長度(不可加密，消息的第二個域) 35 MsgType Y 消息類型(不可加密，消息的第三個域) 49 SenderCompID Y 發(fā)送方代碼(不可加密，發(fā)送方標(biāo)識符) 56 TargetCompID Y 接收方代碼(不可加密，接收方標(biāo)識符) 115 OnBehalfOfCompID N 最初發(fā)送方標(biāo)識符（可加密），用于經(jīng)第三方發(fā)送。 128 DeliverToCompID N 最終接收方標(biāo)識符（可加密），用于經(jīng)第三方發(fā)送。 90 SecureDataLen N 密文數(shù)據(jù)長度 91 SecureData N 密文數(shù)據(jù)（緊跟密文數(shù)據(jù)長度域） 34 MsgSeqNum Y 消息序號（可加密） 50 SenderSubID N 發(fā)送方子標(biāo)識符（可加密） 142 SenderLocationID N 發(fā)送方方位標(biāo)識符（可加密） 57 TargetSubID N 接收方子標(biāo)識符（可加密） 143 TargetLocationID N 接收方方位標(biāo)識符（可加密） 116 OnBehalfOfSubID N 最初發(fā)送方子標(biāo)識符（可加密） 144 OnBehalfOfLocationID N 最初發(fā)送方方位標(biāo)識符（可加密） 129 DeliverToSubID N 最終接收方子標(biāo)識符（可加密） 145 DeliverToLocationID N 最終接收方方位標(biāo)識符（可加密） 43 PossDupFlag N 可能重復(fù)標(biāo)志，重復(fù)發(fā)送時，作此標(biāo)記。（可加密） 97 PossResend N 可能重發(fā)標(biāo)志。（可加密） 52 SendingTime Y 發(fā)送時間（可加密） 122 OrigSendingTime N 原始發(fā)送時間（可加密） 347 MessageEncoding N 消息中Encoded域的字符編碼類型（非ASCII碼） 表２（續(xù)）　消息頭 Tag 域名 必需 說明 369 LastMsgSeqNumProcessed N 最后處理消息序號（可加密） 370 OnBehalfOfSendingTime N 最初發(fā)送時間（用UTC表示時間） 627 NoHops N 歷史跳躍信息重復(fù)組，記錄消息經(jīng)第三方發(fā)送的歷史，每次經(jīng)第三方發(fā)送為一個跳躍，僅當(dāng)OnBehalfOfCompID使用時有效，主要用于跟蹤消息的路徑。 628 HopCompID N 取值第三方的SenderCompID 629 HopSendingTime N 取值用第三方的SendingTime 630 HopRefID N 取值第三方的MsgSeqNum 10.2　 消息尾 每一個消息（會話或應(yīng)用消息）有一個消息尾，并以此終止。消息尾可用于分隔多個消息，包含有3位數(shù)的校驗(yàn)和值。 消息尾格式見表３： 表３　消息尾 Tag 域名 必需 說明 93 SignatureLength N 數(shù)字簽名長度（不可加密） 89 Signature N 數(shù)字簽名（不可加密） 10 CheckSum Y 校驗(yàn)和，消息的最末域。（不可加密） 10.3　 會話消息 會話消息涉及標(biāo)準(zhǔn)的使用機(jī)制，將在以下各節(jié)中予以介紹，并定義會話消息格式。 連接雙方均可生成會話消息。 10.3.1　 心跳消息（MsgType=0） 心跳消息用于監(jiān)控通信連接的狀況，并可確認(rèn)是否接收到最后一條消息。 當(dāng)STEP連接的任何一方在（[HeartBtInt] 秒，心跳間隔）時間內(nèi)沒有發(fā)送任何數(shù)據(jù)的時候，將產(chǎn)生一個心跳消息并傳送出去。當(dāng)連接的任何一方在（[HeartBtInt]＋[合理傳輸時間] ）時間內(nèi)都沒有收到任何有關(guān)的數(shù)據(jù)的時候，將產(chǎn)生一個測試請求消息并傳送出去。如果在此之后的（[HeartBtInt]＋[合理傳輸時間] ）時間內(nèi)，仍沒有收到心跳消息，那么可認(rèn)為此次連接失敗，而且需開始實(shí)施修正操作。如果 HeartBtInt 被設(shè)置為零，那么將不會定期生成心跳消息。并且不論 HeartBtInt 取值多少，任何一方都可發(fā)送測試請求消息，接收方由此將強(qiáng)行生成心跳消息。 因?qū)Ψ降臏y試請求消息而產(chǎn)生的心跳（Heartbeats）消息應(yīng)包括對方測試請求消息中的測試請求標(biāo)識符（TestReqID）。這有利于確定該心跳消息是響應(yīng)測試請求而產(chǎn)生的，而不是由于超時而產(chǎn)生的。 心跳消息格式見表４： 表４　心跳（Heartbeat） Tag 域名 必需 說明 標(biāo)準(zhǔn)消息頭 Y MsgType = 0 112 TestReqID N 測試請求標(biāo)識符，如是對測試請求而響應(yīng)的心跳消息，則應(yīng)包含本域。 標(biāo)準(zhǔn)消息尾 Y 10.3.2　 登錄消息（MsgType=A） 登錄消息能證實(shí)用戶是否已建立與對方系統(tǒng)的連接。登錄消息應(yīng)是在STEP會話開始時的連接雙方發(fā)送的第一個消息。 HeartBtInt域用來聲明產(chǎn)生心跳的時間間隔（連接雙方HeartBtInt取相同的值）。連接雙方事先約定取值，由登錄發(fā)起方產(chǎn)生并得到接收方的確認(rèn)響應(yīng)。 在接收登錄消息時，接收方將驗(yàn)證發(fā)起方身份的合法性，并且同樣發(fā)出登錄消息以確認(rèn)連接請求已被接受。同樣，確認(rèn)登錄消息也可以被發(fā)起方使用以驗(yàn)證連接了身份合法的接收方。 接收方應(yīng)在收到登錄消息之后，立即作好開始消息處理的準(zhǔn)備。發(fā)起方可以選擇在接收到確認(rèn)登錄消息之前開始STEP消息傳輸。不過本標(biāo)準(zhǔn)規(guī)定：在有關(guān)密鑰確認(rèn)的登錄消息收到之后，才實(shí)施正常的消息交換。 確認(rèn)登錄消息還可被用于密鑰相互確定。如果認(rèn)為當(dāng)前會話密鑰強(qiáng)度較弱，需要更換密鑰，那么就可通過發(fā)回帶有新密鑰的登錄消息來建議使用更強(qiáng)的會話密鑰。當(dāng)然，這僅僅對允許密鑰相互確認(rèn)的加密協(xié)議有意義。 登錄消息還可以用來指明最大消息長度（MaxMessageSize），也可以用來指明發(fā)送和接受時所支持的消息類型。 登錄消息格式見表５： 表５　登錄（Logon） Tag 域名 必需 說明 標(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 序號重設(shè)標(biāo)志 383 MaxMessageSize N 最大消息長度，單條消息的最大字節(jié)數(shù) 384 NoMsgTypes N 消息類型個數(shù) 372 RefMsgType N 消息類型 385 MsgDirection N 消息方向 464 TestMessageIndicator N 測試標(biāo)志，指明該會話是測試連接或正常運(yùn)行連接，用于防止意外 553 Username N 用戶名 554 Password N 密碼 標(biāo)準(zhǔn)消息尾 Y 10.3.3　 測試請求消息（MsgType=1） 測試請求消息能強(qiáng)制對方發(fā)出心跳消息。測試請求消息的作用是檢查對方消息序號和檢查通信線路的狀況。對方用帶有測試請求標(biāo)識符（TestReqID）的心跳作應(yīng)答。 測試請求標(biāo)識符（TestReqID）用以指明對方生成心跳消息是響應(yīng)測試請求而非正常超時引起的。對方發(fā)送心跳消息作為應(yīng)答時，將測試請求標(biāo)識符（TestReqID）包括在消息中。任何字符串都可以用作測試請求標(biāo)識符（TestReqID）（可使用時間戳（timestamp））。 測試請求消息格式見表６： 表６　測試請求（Test Request） Tag 域名 必需 說明 標(biāo)準(zhǔn)消息頭 Y MsgType = 1 112 TestReqID Y 測試請求標(biāo)識符 標(biāo)準(zhǔn)消息尾 Y 10.3.4　 重發(fā)請求消息（MsgType=2） 重發(fā)請求消息由接收方發(fā)出，目的是向發(fā)送方申請某些消息重復(fù)發(fā)送。此功能用于：發(fā)現(xiàn)消息序號缺口、接收方丟失了消息和在初始化過程中也可能使用。 重發(fā)請求消息能被用來請求重新發(fā)送單個消息、一系列的消息或在某一特定消息之后的所有消息。 當(dāng)重復(fù)發(fā)送消息的時候，發(fā)送方將考慮消息類型；如：在重復(fù)發(fā)送系列中有一條會話消息，由于過期而不再有效，發(fā)送方不需要重復(fù)傳輸這條消息。因此，當(dāng)發(fā)送方不重復(fù)發(fā)送某消息時，序號重設(shè)-缺口填補(bǔ)（SeqReset-Gap Fill）消息將被用來跳過消息。（注注：接收方按訂單順序進(jìn)行消息處理是非常有必要的。例如，如果訂單第7條消息被錯過，而收到第8和第9條，那么應(yīng)用方將忽略8和9，然后要求重發(fā)送第7-第9，或者要求重新發(fā)送第7-第0（0表現(xiàn)無限）。在順序混亂的狀況中通常用后一方案恢復(fù)消息，因?yàn)楫?dāng)連接雙方都同時試圖盡快恢復(fù)缺口的狀況下，此種方法能更快地進(jìn)行消息恢復(fù)。 ） 重發(fā)請求消息有以下幾種表示方式： l 請求重發(fā)一條消息：起始消息序號（BeginSeqNo）=結(jié)束消息序號（EndSeqNo） l 請求重發(fā)某個范圍內(nèi)的消息：起始消息序號（BeginSeqNo）=該范圍中的第1條消息，結(jié)束消息序號（EndSeqNo） =該范圍中的最后一條消息序號 l 請求重發(fā)某一特定消息之后的所有的消息：起始消息序號（BeginSeqNo）=該范圍中的第1條消息，結(jié)束消息序號（EndSeqNo） =0（無限大）。 重發(fā)請求消息的格式見表７： 表７　重發(fā)請求（Resend Request） Tag 域名 必需 說明 標(biāo)準(zhǔn)消息頭 Y MsgType = 2 7 BeginSeqNo Y 起始消息序號 16 EndSeqNo Y 結(jié)束消息序號 標(biāo)準(zhǔn)消息尾 Y 10.3.5　 會話拒絕消息（MsgType=3） 當(dāng)接收方收到一條消息時，由于違反了會話機(jī)制而造成不能適當(dāng)?shù)靥幚碓撓r，應(yīng)該發(fā)出會話拒絕消息。如：當(dāng)收到一條消息，這條消息雖成功地通過了解密、校驗(yàn)和和正文長度檢驗(yàn)，但卻被發(fā)現(xiàn)帶有無效的數(shù)據(jù)（如：消息類型（MsgType）=&），此時應(yīng)發(fā)出拒絕消息。 被拒絕的消息應(yīng)該寫入日志。 接收方應(yīng)該忽略任何被歪曲，不能被解析，或數(shù)據(jù)完整性核對失敗的消息。立即對下一個有效的STEP消息進(jìn)行處理將會發(fā)現(xiàn)消息缺口，并且，將產(chǎn)生重發(fā)請求。在STEP交換引擎內(nèi)應(yīng)能夠識別這種無限重發(fā)循環(huán)。 當(dāng)產(chǎn)生和收到會話拒絕消息意味著出現(xiàn)了嚴(yán)重錯誤，可能發(fā)送方或接收方的應(yīng)用存在邏輯錯誤。 如果要重新傳輸拒絕消息，那么應(yīng)賦予該消息一個新的消息序號，并設(shè)置可能重發(fā)標(biāo)志（PossResend）為Y。 無論何時，本標(biāo)準(zhǔn)規(guī)定應(yīng)在正文域里盡可能描述拒絕原因。 如果所收到的應(yīng)用層消息遵循了會話機(jī)制，那么可以開始在業(yè)務(wù)層處理該消息。如果在處理過程中，發(fā)現(xiàn)違反業(yè)務(wù)規(guī)則，那么應(yīng)該發(fā)出業(yè)務(wù)層的“拒絕”消息。很多業(yè)務(wù)層的消息都有指定的“拒絕”消息，此時這些消息可以發(fā)揮作用。其它無對應(yīng)會話拒絕消息的，則均可通過業(yè)務(wù)“拒絕”消息進(jìn)行拒絕。 會話拒絕消息格式見表８： 表８　會話拒絕（Reject） Tag 域名 必需 說明 標(biāo)準(zhǔn)消息頭 Y MsgType = 3 45 RefSeqNum Y 關(guān)聯(lián)消息序號，即被拒絕的消息序號 371 RefTagID N 相關(guān)錯誤域號 372 RefMsgType N 相關(guān)錯誤消息類型 373 SessionRejectReason N 會話拒絕原因編號 58 Text N 文本，可作解釋拒絕的原因 354 EncodedTextLen N 編碼文本長度 355 EncodedText N 編碼文本（非ASCII碼） 標(biāo)準(zhǔn)消息尾 Y 會話拒絕原因見表９： 表９　會話拒絕原因 會話拒絕原因 0 = 存在無效的域號 1 = 該消息中必須的域丟失 2 = 該消息中出現(xiàn)未曾定義的域 3 = 未定義域號 4 = 域未賦值 5 = 域取值錯誤（范圍溢出） 6 = 取值格式錯誤 7 = 解密錯誤 8 = 簽名錯誤 9 = 公司標(biāo)識符錯誤 10 = 發(fā)送時間精度錯誤 11 = 無效的消息類型 12 = XML驗(yàn)證錯誤（XML Validation error） 13 = 同一域多次出現(xiàn)（非重復(fù)組） 14 = 有序的域出現(xiàn)次序錯誤 15 = 重復(fù)組域次序錯誤 16 = 重復(fù)組重復(fù)次數(shù)錯誤 17 = 非data數(shù)據(jù)域中出現(xiàn)域界定符 10.3.6　 序號重設(shè)消息（MsgType=4） 序號重設(shè)消息由發(fā)送方發(fā)出，用于告知接收方下一個消息的消息序號。序號重設(shè)消息有兩種模式：序號重設(shè)-缺口填補(bǔ)（SeqReset-Gap Fill）；序號重設(shè)-重設(shè)（SeqReset -Reset）。序號重設(shè)-重設(shè)通常在災(zāi)難恢復(fù)情況下使用。 當(dāng)需要支持24小時的連接并用序號重設(shè)標(biāo)志（ResetSeqNumFlag）來建立新的一套消息序號的時候，關(guān)于連接雙方的序號重設(shè)時間和發(fā)起方另行確定，但序號重設(shè)的發(fā)起方不同于登錄過程的發(fā)起方。其處理過程如下：其中一方先發(fā)送測試請求（TestRequest）。在收到心跳消息后，確認(rèn)沒有消息序號缺口后，發(fā)起方發(fā)送一條登錄消息，在該消息中應(yīng)附有設(shè)為Y的序號重設(shè)標(biāo)志（ResetSeqNumFlag），并且它的消息序號（MsgSeqNum）為1。接收方則應(yīng)該發(fā)送一條登錄消息作回應(yīng)，其中序號重設(shè)標(biāo)志（ResetSeqNumFlag）為Y，消息序號（MsgSeqNum）為1。此后，連接雙方發(fā)送出的消息的消息序號應(yīng)從2 開始。需要注意的是一旦發(fā)起方發(fā)送附有序號重設(shè)標(biāo)志（ResetSeqNumFlag）的登錄消息，那么接收人應(yīng)服從該請求，并且，“昨天”傳送的消息不可能再重發(fā)。如果不遵守以上的處理規(guī)則應(yīng)立即中斷連接，并手工設(shè)置干預(yù)。 序號重設(shè)消息兩種模式表示： 當(dāng)GapFillFlag＝Y(jié)時，該消息為序號重設(shè)-缺口填補(bǔ)（SeqReset-Gap Fill），當(dāng)GapFillFlag＝N或沒有設(shè)置時，該消息為序號重設(shè)-重設(shè)（SeqReset-Reset）。 序號重設(shè)消息能在下列情況下使用： a) 在重新發(fā)送的處理過程中，發(fā)送方可以選擇不發(fā)送某個消息（例如一個會話消息）。序號重設(shè)-缺口填補(bǔ)（SeqReset-Gap Fill）能被用來填補(bǔ)那條消息。 b) 在重新發(fā)送的處理過程中，有大量的會話消息不需要發(fā)送，這樣產(chǎn)生的消息序號缺口也可以由序號重設(shè)-缺口填補(bǔ)（SeqReset-Gap Fill）消息來填補(bǔ)。 c) 在應(yīng)用層失敗的情況下，有必要通過發(fā)送序號重設(shè)-重設(shè)（SeqReset-Reset）在發(fā)送和接收的連接雙方進(jìn)行強(qiáng)制消息序號同步。 在任何情況下，序號重設(shè)消息都指定了NewSeqNo（新的消息序號），并重設(shè)該值為下一個將被傳送消息的消息序號。 如果缺口填補(bǔ)標(biāo)志（GapFillFlag）域被設(shè)置為Y，那么消息序號（MsgSeqNum）域取值應(yīng)該遵循消息序號規(guī)則，即：序號重設(shè)-缺口填補(bǔ)（SeqReset-Gap Fill）消息的消息序號（MsgSeqNum）應(yīng)該對應(yīng)缺口范圍內(nèi)第一條消息的消息序號，因?yàn)閷Ψ秸郎?zhǔn)備接收這個消息序號的消息。 序號重設(shè)-缺口填補(bǔ)（SeqReset-Gap Fill）只能增加消息序號。如果收到的序號重設(shè)-缺口填補(bǔ)（SeqReset-Gap Fill）消息試圖使下一個預(yù)期的消息序號變小，那么此消息應(yīng)該被拒絕接受，并被視作為錯誤。（注注：如可能存在接收方發(fā)送多個重發(fā)請求（如先請求重發(fā)5～10，隨后請求重發(fā) 5～11）。如果消息序號8，10和11表示應(yīng)用消息，而5-7和9表示會話消息，那么為響應(yīng)該重發(fā)請求，有一些應(yīng)用消息需被重新發(fā)送，首先發(fā)送的SeqReset-GapFill中新消息序號（NewSeqNo）設(shè)置為8，即第8條消息；完成重發(fā)應(yīng)用消息后，發(fā)送SeqReset-GapFill且新消息序號（NewSeqNo）設(shè)置為10，即第10條消息，接著完成重發(fā)應(yīng)用消息。隨后又可能發(fā)送SeqReset-GapFill且新消息序號（NewSeqNo）設(shè)置為8，即第8條消息（序號變?。煌瓿芍匕l(fā)應(yīng)用消息后，發(fā)送SeqReset-GapFill且新消息序號（NewSeqNo）設(shè)置為10，即第10條消息，以及第11條消息，接著完成重發(fā)應(yīng)用消息。此時接收方通過檢查在序號重設(shè)-缺口填補(bǔ)（SeqReset-Gap Fill）中的新消息序號（NewSeqNo）是否比預(yù)期的小可發(fā)現(xiàn)此種錯誤。如果發(fā)現(xiàn)有這種錯誤，那么說明該序號重設(shè)-缺口填補(bǔ)（SeqReset-Gap Fill）是重復(fù)的，應(yīng)該放棄處理。 ） 如果缺口填補(bǔ)標(biāo)志（GapFillFlag）域沒有出現(xiàn)（或被設(shè)為N），即為序號重設(shè)-重設(shè)（SeqReset-Reset）消息，那么有可能是此序號重設(shè)-重設(shè)（SeqReset-Reset）消息的目的是恢復(fù)混亂順序的消息。此時消息頭里的消息序號（MsgSeqNum）應(yīng)該忽略。禁止在重發(fā)請求的正?；貞?yīng)中使用序號重設(shè)-重設(shè)（SeqReset-Reset）（應(yīng)使用序號重設(shè)-缺口填補(bǔ)（SeqReset-Gap Fill））。序號重設(shè)-重設(shè)（SeqReset-Reset）僅用于無法用序號重設(shè)-缺口填補(bǔ)（SeqReset-Gap Fill）進(jìn)行恢復(fù)的災(zāi)難情況。注意使用序號重設(shè)-重設(shè)（SeqReset-Reset）可能會造成消息丟失。 序號重設(shè)消息格式見表１０： 表１０　序號重設(shè)（Sequence Reset） Tag 域名 必需 說明 標(biāo)準(zhǔn)消息頭 Y MsgType = 4 123 GapFillFlag N 缺口填補(bǔ)標(biāo)志 36 NewSeqNo Y 新消息序號 標(biāo)準(zhǔn)消息尾 Y 10.3.7　 注銷消息（MsgType=5） 注銷消息是發(fā)起或確認(rèn)STEP會話終止的消息。未經(jīng)注銷消息交換而斷開連接，一律視為非正常的斷開。 在最后終止會話之前，注銷的發(fā)起人應(yīng)該等待連接對方確認(rèn)注銷消息。這使得連接對方有了實(shí)施任何有必要的缺口填補(bǔ)的機(jī)會。如果連接對方?jīng)]有在適當(dāng)?shù)臅r間間隔里作回應(yīng)，那么會話就可以終止。 注銷發(fā)起人在發(fā)送注銷消息之后不應(yīng)發(fā)送任何消息，除非接收到連接對方發(fā)出的重發(fā)請求消息。 注銷消息格式見表１１： 表１１　注銷（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)用消息都會用到一系列定義證券品種的數(shù)據(jù)域：Symbol, SecurityIDSource, SecurityID, ……。為避免重復(fù)，本標(biāo)準(zhǔn)中定義了一些關(guān)鍵組件，在應(yīng)用消息定義中直接用名稱引用這些組件。實(shí)際的消息定義和使用中，則應(yīng)該將組件擴(kuò)展開成為相應(yīng)的數(shù)據(jù)域集合。 組件可以是重復(fù)組的部分，此時組件對應(yīng)的整組數(shù)據(jù)域都位于組件所