《CMDS-Client-API-IMIX开发指引-V2.9.doc》由会员分享，可在线阅读，更多相关《CMDS-Client-API-IMIX开发指引-V2.9.doc（60页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、如有侵权，请联系网站删除，仅供学习与交流CMDS-Client-API-IMIX开发指引-V2.9【精品文档】第 47 页CFETS IMIX Protocol Development GuideCFETS/K04382015CMDS Client API IMIXDevelopment GUIDE(Version 2.9)Protocol Version 1.111.3CMDS Client APIPublish by CFETSContentsPrefaceIVForewordVRevision HistoryVI1 Scope12 IMIX Protocol Introduction12
2、.1 Scope of Application12.2 IMIX Message Structure12.2.1 Standard Message Header22.2.2 Standard Message Trailer62.2.3 Standard Message Body62.2.4 Repeating Groups62.2.5 Component Block73 Key Field and Group73.1 MsgType73.2 MarketIndicator73.3 UniqueOutputKey83.4 SecurityID83.5 LiquidProviderGrp83.6
3、MDTypeGrp83.7 Rule of RIC Code94 Business Scene Introduction104.1 Data Type104.1.1 Update data104.1.2 Snapshot data104.1.3 Refresh data104.2 Data Content104.2.1 Mid-price data104.2.2 Best quote data114.2.3 Market statistics data124.3 Message Flow125 Business Scene Sample135.1 Logon135.2 Logout145.3
4、Broadcast Request145.4 Broadcast Data145.4.1 Mid-price Data155.4.1.1 Content of Mid-price Data155.4.1.2 Example of Mid-price Data155.4.2 Best Quote Data165.4.2.1 For Spot, Forward and NDF Market165.4.2.1.1 Content of Best Quote Data165.4.2.1.2 Example of Best Quote Data175.4.2.2 For Swap Market185.4
5、.2.2.1 Content of Best Quote Data185.4.2.2.2 Example of Near Leg Data195.4.2.2.3 Example of Far Leg Data205.4.3 Market Statistics Data225.4.3.1 For Spot, Forward and NDF Market225.4.3.1.1 Content of Market Statistics Data225.4.3.1.2 Example of Market Statistics Data235.4.3.2 For Swap Market255.4.3.2
6、.1 Content of Market Statistics Data255.4.3.2.2 Example of Near Leg Data265.4.3.2.3 Example of Far Leg Data285.5 Refresh Request295.6 Refresh Data305.6.1 For Spot, Forward and NDF Market305.6.1.1 Content of Refresh Data305.6.1.2 Example of Refresh Data325.6.2 For Swap Market355.6.2.1 Content of Refr
7、esh Data355.6.2.2 Example of Near Leg Data375.6.2.3 Example of Far Leg Data395.7 Historical Data Retransmission Request425.8 Historical data436 Develop Guide436.1 Notice of Development436.2 Logon and Logout sample456.3 Send MarketDataRequest466.4 Deal with MarketDataSnapshotFullRefresh486.5 Exceptio
8、n Handing507 CNY CMDS API517.1 SenderSubID517.2 Market Configure527.3 Business Message527.4 Data Type in CNY Market527.5 Request type in CNY Market527.6 Business Scene in CNY Market52Reference53Diagram 1 architecture of system1Diagram2 IMIX Message Structure2Diagram 3 workflow of system13Table 1 Sta
9、ndard Message Header2Table 2 Standard Message Trailer6Table 3 Example Of a Repeating Group7Table 4 Example Of Component Block7Table 5 Example Of LiquidProviderGrp8Table 6 Example Of MDTypeGrp8Table 7 Example Of Mid-price Data11Table 8 Example of Best Quote Data11Table 9 Example Of Liquid Provider11T
10、able 10 Content of Broadcast Request14Table 11 Example of Broadcast Request14Table 12 Content of Mid-price Data15Table 13 Example of Mid-price Data15Table 14 Content of Best Quote Data in Spot, Forward and NDF Market16Table 15 Example of Spot, Forward and NDF Market17Table 16 Content of Best Quote D
11、ata in Swap Market18Table 17 Example of Near Leg Data19Table 18 Example of Far Leg Data21Table 19 Content of Market Statistics Data in Spot, Forward and NDF Market22Table 20 Example of Spot, Forward and NDF Market23Table 21 Content of Market Statistics Data in Swap Market25Table 22 Example of Near L
12、eg Data27Table 23 Example of Far Leg Data28Table 24 Content of Refresh Request29Table 25 Example of Refresh Request29Table 26 Content of Refresh Data in Spot, Forward and NDF Market30Table 27 Example of Spot, Forward and NDF Market32Table 29 Example of Near Leg Data37Table 30 Example of Far Leg Data
13、39Table 31 Content of Historical Data Retransmission Request42Table 32 Example of Historical Data Retransmission Request (By Data Time)42Table 33 Example of Historical Data Retransmission Request (By Unique Output Key)43Table 34 MarketDataRequest Structure46PrefaceCMDS is a market data broadcasting
14、system, CFETS wants to get the market data from CMDS, CMDS Client API is designed for that purpose, it can communicate with CMDS system, and the message provided to API user is IMIX message, and the users can develop their own application based on this API.This file is managed by CFETS.This file is
15、provided by CFETS.CFETS is responsible to draft the file.ForewordWith the continously deepen the financial reform in our country, the unceasingly enhanced informationization in interbank market, financial standards gradually penentrated into all aspects of marketing activities. As a team leader of I
16、nterbank Market Standard Working Group, CFETS has actively implemented the strategy of the Peoples Bank of China, continously contributed to the interbank market standardization construction, taken the lead in drafting JR/T 0065-2011 Interbank Market Basis Data Source, JR/T 0066-2011Interbank Market
17、 Business Data Exchange Protocol, JR/T 0078-2014 Interbank Data Interfaceand other financial industry standards. Based on these standards, CFETS provides straight-through processing interface, market data interface, quote interface, trade transaction interface and other interface service, and introd
18、uces including normative guidance documents, application programming interface (API), and data interface development service system to support technical and business requirements. IMIX protocol as a guidance document plays an important role to standardize the delvelopment of data interface. Therefor
19、e, this document pays more attention to our interbank makret self characteristics and standardization, further plays as a guidance of financial system construction, builds solid foundation for unifying interbank makret business data exchange system.Revision HistoryAuthorAuditorUser Guide VersionProt
20、ocol VersionDateRevision CommentsShuxin Li1.12008-08-251.Create the documentShuxin Li1.22008-10-101.Add business sceneLei Wang1.32008-10-171.Add examples in chapter 7Shuxin Li1.42008-10-201.Add example programsShuxin Li1.52008-10-281.Add key group example and business elements for each sceneLei Wang
21、1.62008-10-301.Update business elements for each scene;2.Add Field 10462 for each example;3.Add Field 34 and 52 for each Request message exampleShuxin Li1.72008-10-301.Add related documents to development guideShuxin Li 1.82008-11-181.Add Field 10483(SnapshotInterval) into each related example;2.Rem
22、ove field 22 (SecurityIDSource) andfield 603 (LegSecurityIDSource) from message;Lei WangShuxin Li1.92008-11-201.Remove field 272(MDEntryDate) and 273(MDEntryTime) from Mid-price data example.2.Remove field 10462(DelayPeriod) from refresh messagesLei Wang2.02008-11-271.Add last ask dealt rate data to
23、 refresh data examples;2.Add “dealt date, dealt time, last dealt rate, last allin, deal side” to refresh data;3.Review all the examples and modified some details(All changes are tracked in the document);4.Add comments in some examples;Shuxin LiWang Lei2.12008-12-311.Change NoLegss field number from
24、146 to 555;2.Adjust the order of field 10360 and 10359 in LiquidProviderGrp to fit IMIX protocol format;3.Update some fields value in Refresh data examples.Shuxin Li2.22009-5-131.All versions before 2.2 are about FX CMDS API, now API can receive messages from CNY CMDS, so add new chapter 8 to introd
25、uce the improvements of API and differences between two markets.Weina He2.32012-8-81.Replace 269 MDEntryType =d to 269 MDEntryType =1 in versions 6.4.2.1.1 and versions 6.4.2.2.1 Weina He2.42013-1-211.Add section 6.7: CFETS Cross Currency Swap CurvesTingkai Yan2.52013-12-31.Add section 6.8 Fx option
26、 delta curves of chapter sixTingkai Yan2.62013-12-61.Change the message header of 6.8.2Tingkai Yan2.72013-12-171.Change the values of 10164 and 10337 which located at 6.8.2Tingkai Yan2.82014-2-111.Delete 6.7 CFETS Cross Currency Swap Curves and 6.8 FX OPTION DELTA CURVESYujiaoXia2.91.111.32015-1-191
27、.Add chapter 3.7 to illustrate rule of RIC code2.Add comments of tag 602(LegSecurityID) in chapter 5.4.2.2.2, 5.4.2.2.3, 5.4.3.2.2, 5.4.3.2.3, 5.6.2.2 and 5.6.2.3CMDS Client API IMIX Development Guide1 ScopeCMDS Client API is designed for users who want to connect and communicate with CMDS. Before i
28、ntroducing API details, we firstly introduce the architecture of whole systems.Diagram 1 architecture of systemThe above diagram indicates that client should send request to CMDS before receiving data. The request message from Client to CMDS is represented by MarketDataRequest (MsgType=V), and all t
29、he business data from CMDS to client is transmitted by MarketDataSnapshotFullRefresh (MsgType=W).This document mainly has two parts: the first part is the specification of IMIX protocol, and the second part is to introduce the IMIX messages used in CMDS Client according to business scene.2 IMIX Prot
30、ocol Introduction2.1 Scope of ApplicationIMIX protocol covers business of chinese makret trasnactions, quotes and downloading market data, and parts of foreign exchange transactions.2.2 IMIX Message StructureIMIX message structure is illustrated in diagram 2.Diagram2 IMIX Message StructureThe genera
31、l format of an IMIX message is a standard header followed by the message body fields and terminated with a standard trailer.2.2.1 Standard Message HeaderEach session or application message has a header. Header defines message type, message body length, target destination, message sequence number, se
32、nder and sending time.Format of message header is shown in Table 1.Table 1 Standard Message HeaderTagFieldReqdComments8BeginStringYIMIX.1.0 (Must be first field in message)9BodyLengthY(Must be second field in message)35MsgTypeY(Must be third field in message)49SenderCompIDY56TargetCompIDY115OnBehalf
33、OfCompIDNTrading partner company ID used when sending messages via a third party.128DeliverToCompIDNTrading partner company ID used when sending messages via a third party.90SecureDataLenNRequired to identify length of encrypted section of message.91SecureDataNRequired when message body is encrypted
34、. Always immediately follows SecureDataLen field.34MsgSeqNumY50SenderSubIDN142SenderLocationIDNSenders LocationID (i.e. geographic location and/or desk).57TargetSubIDN“ADMIN” reserved for administrative messages not intended for a specific user.143TargetLocationIDNTrading partner LocationID (i.e. ge
35、ographic location and/or desk)116OnBehalfOfSubIDNTrading partner SubID used when delivering messages via a third party144OnBehalfOfLocationIDNTrading partner LocationID (i.e. geographic location and/or desk) used when delivering messages via a third party.129DeliverToSubIDNTrading partner SubID used
36、 when delivering messages via a third party.145DeliverToLocationIDNTrading partner LocationID (i.e. geographic location and/or desk) used when delivering messages via a third party.43PossDupFlagNAlways required for retransmitted messages, whether prompted by the sending system or as the result of a
37、resend request.97PossResendNRequired when message may be duplicate of another message sent under a different sequence number.52SendingTimeY122OrigSendingTimeNRequired for message resent as a result of a ResendRequest. If data is not available set to same value as SendingTime212XmlDataLenNRequired wh
38、en specifying XmlData to identify the length of an XmlData message block.213XmlDataNCan contain a XML formatted message block347MessageEncodingNType of message encoding (non-ASCII characters) used in a messages “Encoded” fields. Required if any “Encoding” fields are used.369LastMsgSeqNumProcessedNTh
39、e last MsgSeqNum value received by the IMIX engine and processed by downstream application, such as trading system or order routing system. Can be specified on every message sent. Useful for detecting a backlog with counterparty.627NoHopsNNumber of repeating groups of historical “hop” information. O
40、nly applicable if OnBehalfOfCompID is used, however, its use is optional. Note that some market regulations or counterparties may require tracking of message hops.628HopCompIDNThird party firm which delivered a specific message either from the firm which originated the message or from another third
41、party (if multiple “hops” are performed). It is recommended that this value be the SenderCompID (49) of the third party.629HopSendingTimeNTime that HopCompID (628) sent the message. It is recommended that this value be the SendingTime (52) of the message sent by the third party.630HopRefIDNReference
42、 identifier assigned by HopCompID (628) associated with the message sent. It is recommended that this value be the MsgSeqNum (34) of the message sent by the third party.2.2.2 Standard Message TrailerEach session message or application message has a trailer to termiante the message.Message trailer is
43、 used to separate messages, includes three byte checksum.The format of message trailer is as follows in Table 2.Table 2 Standard Message TrailerTagFieldReqdComments93SignatureLengthNRequired when trailer contains signature. Note: Not to be included within SecureData field89SignatureNNote: Not to be
44、included within SecureData field10CheckSumY(Always unencrypted, always last field in message)2.2.3 Standard Message BodyMessage body is mainly used to describe business information in application layers. Application messages share many common fields setscomponent. For example, most application messa
45、ge has adopted a set of fixed income defined fields, such as Symbol, Security ID, Security IDSource. In order to avoid replication, the protocol also defines some key components which is included in application messages. In practical message definition and usage, these compoents should be explored t
46、o corresponent fields sets.2.2.4 Repeating GroupsIt is permissible for fields to be repeated within a repeating group (e.g.384=2372=6385=R372=7385=R represents a repeating group with two repeating instances “delimited” by tag 372 (first field in the repeating group). If the repeating group is used, the first field of the repeating group is required. This allows implementations of