CONNEQTOR

ユーザ用ツール

サイト用ツール

現在位置: CONNEQTOR Top » spec » en » isv » CONNEQTOR FIX Interface Specifications (Investor/Connection)
spec:en:isv:connection

差分

このページの2つのバージョン間の差分を表示します。

この比較画面にリンクする

次のリビジョン 		前のリビジョン
spec:en:isv:connection [2023/08/04 13:52]
editor 作成 		spec:en:isv:connection [2024/01/22 10:04] (現在)
editor
行 28: 行 28:
 === 2.1.1 Production Environment === === 2.1.1 Production Environment ===
  
-The production environment is for the purpose of using the system service, and available from 8 a.m. (JST) to 6 p.m. (JST) on trading days.The investor system logs on to CONNEQTOR during the available hours of the trading day.　CONNEQTOR does not have a disaster recovery site. In the event of a broader disaster of CONNEQTOR (production), network equipment at the primary center, or arrownet, shown in Figure 2.1.1, the service shall be stopped until the equipment is restored. Investors are allowed to have multiple FIX clients with the same IP address or the different IP addresses for fault tolerance. Figure 2.1.1 shows the overall configuration image of the production environment. The investor system logs out to CONNEQTOR during the available hours of the trading day.\\+The production environment is for the purpose of using the system service, and available from 8:00 a.m. (JST) to 6:30 p.m. (JST) on trading days.The investor system logs on to CONNEQTOR during the available hours of the trading day.　CONNEQTOR does not have a disaster recovery site. In the event of a broader disaster of CONNEQTOR (production), network equipment at the primary center, or arrownet, shown in Figure 2.1.1, the service shall be stopped until the equipment is restored. Investors are allowed to have multiple FIX clients with the same IP address or the different IP addresses for fault tolerance. Figure 2.1.1 shows the overall configuration image of the production environment. The investor system logs out to CONNEQTOR during the available hours of the trading day.\\
 \\ \\
-{{ :draft:investorfix:Figure 2.1.1 Overall configuration image (Production).svg?800 |Figure 2.1.1 Overall configuration image (Production)}}+{{ ::spec:en:isv:Figure 2.1.1 Overall configuration image (Production).svg?800 |Figure 2.1.1 Overall configuration image (Production)}}
 ;#; ;#;
 **Figure 2.1.1 Overall configuration image (Production)** **Figure 2.1.1 Overall configuration image (Production)**
行 37: 行 37:
 \\ \\
 === 2.1.2 Staging Environment === === 2.1.2 Staging Environment ===
-The staging environment is for testing purposes, and the test day is basically the same day as the trading day of the production environment. It is available from 8 a.m. (JST) to 9 p.m. (JST) on the day of testing. When the investor performs the test, the investor system will attempt to log in to CONNEQTOR during available hours on the day of the test. If the FIX session is disconnected during the test, the investor system may attempt to log in again.+The staging environment is for testing purposes, and the test day is basically the same day as the trading day of the production environment. It is available from 8:00 a.m. (JST) to 9:00 p.m. (JST) on the day of testing. When the investor performs the test, the investor system will attempt to log in to CONNEQTOR during available hours on the day of the test. If the FIX session is disconnected during the test, the investor system may attempt to log in again.
 In the case where investor selects a securities company that does not log in FIX, the test cannot be performed after RFQ sending. Therefore, TSE will prepare pseudo participants to enable investors to send RFQs. In the case where investor selects a securities company that does not log in FIX, the test cannot be performed after RFQ sending. Therefore, TSE will prepare pseudo participants to enable investors to send RFQs.
 In the event of a broader disaster of CONNEQTOR (staging), network equipment at the primary center, or arrownet, shown in Figure 2.1.2, the test shall be stopped until the equipment is restored, in order to resume the service in this environment. Figure 2.1.2 shows the overall configuration image of the staging environment. Investors can connect to CONNEQTOR via the arrownet. In the event of a broader disaster of CONNEQTOR (staging), network equipment at the primary center, or arrownet, shown in Figure 2.1.2, the test shall be stopped until the equipment is restored, in order to resume the service in this environment. Figure 2.1.2 shows the overall configuration image of the staging environment. Investors can connect to CONNEQTOR via the arrownet.
行 54: 行 54:
 The connection between investor system and CONNEQTOR is shown below. TCP/IP shall be used as the transmission control procedure, and it is connected through the arrownet. The connection between investor system and CONNEQTOR is shown below. TCP/IP shall be used as the transmission control procedure, and it is connected through the arrownet.
  
-{{ :draft:investorfix:Figure 3.1.1 Connection Configuration.svg?800 |Figure 3.1.1 Connection Configuration}}+{{ :spec:en:isv:Figure 3.1.1 Connection Configuration.svg?800 |Figure 3.1.1 Connection Configuration}}
 ;#; ;#;
 ** Figure 3.1.1 Connection Configuration ** ** Figure 3.1.1 Connection Configuration **
行 88: 行 88:
 The IP address and port number for investor system shall be assigned by investor at the time of applications. Investors are also required to assign their IP addresses and port numbers for their secondary system if they use, in addition to ones for their primary site. Those for CONNEQTOR shall be assigned by Exchange. The IP address and port numbers assigned by Exchange are described in the following figure. The IP address and port number for investor system shall be assigned by investor at the time of applications. Investors are also required to assign their IP addresses and port numbers for their secondary system if they use, in addition to ones for their primary site. Those for CONNEQTOR shall be assigned by Exchange. The IP address and port numbers assigned by Exchange are described in the following figure.
  
-{{ :draft:investorfix:Figure 3.2.2-1 IP Address and Port Number.svg?800 |Figure 3.2.2-1 IP Address and Port Number}}+{{ ::spec:en:isv:Figure 3.2.2-1 IP Address and Port Number.svg?800 |Figure 3.2.2-1 IP Address and Port Number}}
 ;#; ;#;
 **Figure 3.2.2-1 IP Address and Port Number ** **Figure 3.2.2-1 IP Address and Port Number **
行 130: 行 130:
 FIX session continues over multiple TCP connections (time-wise). Multiple Logons/Logouts are possible during a single FIX session. FIX session continues over multiple TCP connections (time-wise). Multiple Logons/Logouts are possible during a single FIX session.
  
-{{ :draft:investorfix:Figure 4.2.1 Relationship between TCP connection and FIX Session.svg?800 |Figure 4.2.1 Relationship between TCP connection and FIX Session}}+{{ ::spec:en:isv:Figure 4.2.1 Relationship between TCP connection and FIX Session.svg?800 |Figure 4.2.1 Relationship between TCP connection and FIX Session}}
 ;#; ;#;
 **Figure 4.2.1 Relationship between TCP connection and FIX Session** **Figure 4.2.1 Relationship between TCP connection and FIX Session**
行 218: 行 218:
   *Note) Regularly, Sequence Reset-GapFill(GapFilLFlag(123)=Y) will be used for messages sent in place of administrative messages, however in cases where the message indicated in the request cannot be sent (such as when it is not in the transmission history), Sequence Reset-Reset(GapFillFlag(123)=N) shall be used. When using SequenceReset-Reset, the message may have been lost.   *Note) Regularly, Sequence Reset-GapFill(GapFilLFlag(123)=Y) will be used for messages sent in place of administrative messages, however in cases where the message indicated in the request cannot be sent (such as when it is not in the transmission history), Sequence Reset-Reset(GapFillFlag(123)=N) shall be used. When using SequenceReset-Reset, the message may have been lost.
  
-{{ :draft:investorfix:Figure 4.6.1 GapFill Sequence.svg?600 |Figure 4.6.1 GapFill Sequence}}+{{ ::spec:en:isv:Figure 4.6.1 GapFill Sequence.svg?600 |Figure 4.6.1 GapFill Sequence}}
 In this sequence, when the AplMessage MsgSeqNum=13 is received, a gap is detected and GapFill procedures are conducted. AplMessage means application message. All application messages are eligible for resending.\\ In this sequence, when the AplMessage MsgSeqNum=13 is received, a gap is detected and GapFill procedures are conducted. AplMessage means application message. All application messages are eligible for resending.\\
 *1 In cases where a Retransmission Request is sent in response to Gap Detection, resending range requested by the ResendRequest message shall be between the sequence number following the last message received normally and 0 (meaning infinity). Including up to 0 indicates that messages up until the last sent are eligible.\\ *1 In cases where a Retransmission Request is sent in response to Gap Detection, resending range requested by the ResendRequest message shall be between the sequence number following the last message received normally and 0 (meaning infinity). Including up to 0 indicates that messages up until the last sent are eligible.\\
行 298: 行 298:
 FIX protocol transmission sequence primarily consists of the Establishment Sequence for the Logon exchange, the message transmission for the application message exchange, the Release Sequence for the Logout exchange. The FIX protocol transmission sequence is outlined below. FIX protocol transmission sequence primarily consists of the Establishment Sequence for the Logon exchange, the message transmission for the application message exchange, the Release Sequence for the Logout exchange. The FIX protocol transmission sequence is outlined below.
  
-{{ :draft:investorfix:Figure 6.1.1 Sequence overview.svg?800 |Figure 6.1.1 Sequence overview}}+{{ ::spec:en:isv:Figure 6.1.1 Sequence overview.svg?800 |Figure 6.1.1 Sequence overview}}
 ;#; ;#;
 Note that the sequence numbers are continued even after releasing the sequence. Note that the sequence numbers are continued even after releasing the sequence.
行 314: 行 314:
 (Note) The MsgSeqNum of the Logon request/response is not always 1. (Note) The MsgSeqNum of the Logon request/response is not always 1.
  
-{{ :draft:investorfix:Figure 6.1.2 Establish (Authentication OK).svg?800 |Figure 6.1.2 Establish (Authentication OK) }}+{{ ::spec:en:isv:Figure 6.1.2 Establish (Authentication OK).svg?800 |Figure 6.1.2 Establish (Authentication OK) }}
 ;#; ;#;
 ** Figure 6.1.2 Establish (Authentication OK) ** ** Figure 6.1.2 Establish (Authentication OK) **
行 322: 行 322:
 If there is a problem authenticating Logon request received from investor system, it is judged to be a party with invalid connection, and the connection will be refused by disconnecting the TCP connection. If there is a problem authenticating Logon request received from investor system, it is judged to be a party with invalid connection, and the connection will be refused by disconnecting the TCP connection.
  
-{{ :draft:investorfix:Figure 6.1.3 Establish (Authentication Denied).svg?800 |Figure 6.1.3 Establish (Authentication Denied)}}+{{ ::spec:en:isv:Figure 6.1.3 Establish (Authentication Denied).svg?800 |Figure 6.1.3 Establish (Authentication Denied)}}
 ;#; ;#;
 ** Figure 6.1.3 Establish (Authentication Denied) ** ** Figure 6.1.3 Establish (Authentication Denied) **
行 330: 行 330:
 Active release in the investor system receives a Logout response from the CONNEQTOR to the Logout request, at which point the release is complete. Investor system shall disconnect the TCP connection. Active release in the investor system receives a Logout response from the CONNEQTOR to the Logout request, at which point the release is complete. Investor system shall disconnect the TCP connection.
  
-{{ :draft:investorfix:Figure 6.1.4 Active Release.svg?800 |Figure 6.1.4 Active Release}}+{{ ::spec:en:isv:Figure 6.1.4 Active Release.svg?800 |Figure 6.1.4 Active Release}}
 ;#; ;#;
 ** Figure 6.1.4 Active Release ** ** Figure 6.1.4 Active Release **
行 349: 行 349:
 Below is the sequences in which CONNEQTOR uses HeartBeat. When no message is sent even after the time set in the HeartBtInt of the Logon response has elapsed, a HeartBeat message shall be sent. Below is the sequences in which CONNEQTOR uses HeartBeat. When no message is sent even after the time set in the HeartBtInt of the Logon response has elapsed, a HeartBeat message shall be sent.
  
-{{ :draft:investorfix:Figure 6.1.5 HeartBeat Transmission.svg?800 |Figure 6.1.5 HeartBeat Transmission}}+{{ ::spec:en:isv:Figure 6.1.5 HeartBeat Transmission.svg?800 |Figure 6.1.5 HeartBeat Transmission}}
 ;#; ;#;
 ** Figure 6.1.5 HeartBeat Transmission ** ** Figure 6.1.5 HeartBeat Transmission **
行 357: 行 357:
 When the investor system uses a HeartBeat, CONNEQTOR monitors the interval of messages received from the investor system. When no messages are sent even after the monitoring time elapses, CONNEQTOR shall send a TestRequest to confirm the existence of the investor system. If, due to some reason, no response is received from the investor system again, CONNEQTOR shall deem that a failure has occurred in the line or investor system and disconnect the TCP connection. When the investor system uses a HeartBeat, CONNEQTOR monitors the interval of messages received from the investor system. When no messages are sent even after the monitoring time elapses, CONNEQTOR shall send a TestRequest to confirm the existence of the investor system. If, due to some reason, no response is received from the investor system again, CONNEQTOR shall deem that a failure has occurred in the line or investor system and disconnect the TCP connection.
  
-{{ :draft:investorfix:Figure 6.1.6 Timeout of HeartBeat Reception Monitoring.svg?800 |Figure 6.1.6 Timeout of HeartBeat Reception Monitoring}}+{{ ::spec:en:isv:Figure 6.1.6 Timeout of HeartBeat Reception Monitoring.svg?800 |Figure 6.1.6 Timeout of HeartBeat Reception Monitoring}}
 ;#; ;#;
 ** Figure 6.1.6 Timeout of HeartBeat Reception Monitoring **\\ ** Figure 6.1.6 Timeout of HeartBeat Reception Monitoring **\\
行 367: 行 367:
 When a ResendRequest is received from the invesor system, retransmission shall be performed according to the details of the ResendRequest. Since administrative messages other than Reject are not subject to retransmission, when such messages are including in the retransmission range, SequenceReset-GapFill shall be sent instead. When a ResendRequest is received from the invesor system, retransmission shall be performed according to the details of the ResendRequest. Since administrative messages other than Reject are not subject to retransmission, when such messages are including in the retransmission range, SequenceReset-GapFill shall be sent instead.
  
-{{ :draft:investorfix:Figure 6.1.7 Receive ResendRequest (retransmission request) from investor system.svg?800 |Figure 6.1.7 Receive ResendRequest (retransmission request) from investor system}}+{{ ::spec:en:isv:Figure 6.1.7 Receive ResendRequest (retransmission request) from investor system.svg?800 |Figure 6.1.7 Receive ResendRequest (retransmission request) from investor system}}
 ;#; ;#;
 ** Figure 6.1.7 Receive ResendRequest (retransmission request) from investor system ** ** Figure 6.1.7 Receive ResendRequest (retransmission request) from investor system **
行 377: 行 377:
 Note) CONNEQTOR shall specify that all messages after the beginning of a missing message are requested to retransmit a ResendRequest. (EndSeqNo=0 fixed) Note) CONNEQTOR shall specify that all messages after the beginning of a missing message are requested to retransmit a ResendRequest. (EndSeqNo=0 fixed)
  
-{{ :draft:investorfix:Figure 6.1.8 Gap Detection when Receiving AplMessages.svg?800 |Figure 6.1.8 Gap Detection when Receiving AplMessages}}+{{ ::spec:en:isv:Figure 6.1.8 Gap Detection when Receiving AplMessages.svg?800 |Figure 6.1.8 Gap Detection when Receiving AplMessages}}
 ;#; ;#;
 ** Figure 6.1.8 Gap Detection when Receiving AplMessages ** ** Figure 6.1.8 Gap Detection when Receiving AplMessages **
行 385: 行 385:
 When CONNEQTOR detects a sequence Gap in a message from the investor system at the receipt of a Logon request, CONNEQTOR shall first send a Logon response to the investor system, then send a ResendRequest to request the retransmission of the message. For example, if CONNEQTOR could not receive the message from the investor system due to the system down, this sequence shall be performed. When CONNEQTOR detects a sequence Gap in a message from the investor system at the receipt of a Logon request, CONNEQTOR shall first send a Logon response to the investor system, then send a ResendRequest to request the retransmission of the message. For example, if CONNEQTOR could not receive the message from the investor system due to the system down, this sequence shall be performed.
  
-{{ :draft:investorfix:Figure 6.1.9 Gap Detection when Receiving Logon request.svg?800 |Figure 6.1.9 Gap Detection when Receiving Logon request}}+{{ ::spec:en:isv:figure_6.1.9_gap_detection_when_receiving_logon_request.svg?800 |Figure 6.1.9 Gap Detection when Receiving Logon request}}
 ;#; ;#;
 ** Figure 6.1.9 Gap Detection when Receiving Logon request ** ** Figure 6.1.9 Gap Detection when Receiving Logon request **
行 393: 行 393:
 When a sequence gap is detected in a message from investor system at the receipt of a Logout request, CONNEQTOR shall immediately send a ResendRequest to request a retransmission of the message. Then it shall send a Logout response when it receives all the messages that requested the retransmission. When a sequence gap is detected in a message from investor system at the receipt of a Logout request, CONNEQTOR shall immediately send a ResendRequest to request a retransmission of the message. Then it shall send a Logout response when it receives all the messages that requested the retransmission.
  
-{{ :draft:investorfix:Figure 6.1.10 Gap Detection when Receiving Logout request.svg?800 |Figure 6.1.10 Gap Detection when Receiving Logout request}}+{{ ::spec:en:isv:Figure 6.1.10 Gap Detection when Receiving Logout request.svg?800 |Figure 6.1.10 Gap Detection when Receiving Logout request}}
 ;#; ;#;
 ** Figure 6.1.10 Gap Detection when Receiving Logout request ** ** Figure 6.1.10 Gap Detection when Receiving Logout request **
行 401: 行 401:
 When a sequence gap is detected in a message from the investor system at the receipt of a HeartBeat, CONNEQTOR shall immediately send a ResendRequest to request a retransmission of the message. When a sequence gap is detected in a message from the investor system at the receipt of a HeartBeat, CONNEQTOR shall immediately send a ResendRequest to request a retransmission of the message.
  
-{{ :draft:investorfix:Figure 6.1.11 Gap Detection when Receiving HeartBeat.svg?800 |Figure 6.1.11 Gap Detection when Receiving HeartBeat}}+{{ ::spec:en:isv:Figure 6.1.11 Gap Detection when Receiving HeartBeat.svg?800 |Figure 6.1.11 Gap Detection when Receiving HeartBeat}}
 ;#; ;#;
 ** Figure 6.1.11 Gap Detection when Receiving HeartBeat ** ** Figure 6.1.11 Gap Detection when Receiving HeartBeat **
行 411: 行 411:
 (Note) When a gap is detected, a HeartBeat shall not be sent in response to the TestRequest. (Note) When a gap is detected, a HeartBeat shall not be sent in response to the TestRequest.
  
-{{ :draft:investorfix:Figure 6.1.12 Gap Detection when Receiving TestRequest.svg?800 |Figure 6.1.12 Gap Detection when Receiving TestRequest}}+{{ ::spec:en:isv:Figure 6.1.12 Gap Detection when Receiving TestRequest.svg?800 |Figure 6.1.12 Gap Detection when Receiving TestRequest}}
 ;#; ;#;
 ** Figure 6.1.12 Gap Detection when Receiving TestRequest ** ** Figure 6.1.12 Gap Detection when Receiving TestRequest **
行 419: 行 419:
 When a sequence gap is detected in a message from the investor system at the receipt of a ResendRequest, CONNEQTOR shall first process the retransmission request from the investor system and then send a ResendRequest to request a retransmission of the message. When a sequence gap is detected in a message from the investor system at the receipt of a ResendRequest, CONNEQTOR shall first process the retransmission request from the investor system and then send a ResendRequest to request a retransmission of the message.
  
-{{ :draft:investorfix:Figure 6.1.13 Gap Detection when Receiving ResendRequest.svg?800 |Figure 6.1.13 Gap Detection when Receiving ResendRequest}}+{{ ::spec:en:isv:Figure 6.1.13 Gap Detection when Receiving ResendRequest.svg?800 |Figure 6.1.13 Gap Detection when Receiving ResendRequest}}
 ;#; ;#;
 ** Figure 6.1.13 Gap Detection when Receiving ResendRequest ** ** Figure 6.1.13 Gap Detection when Receiving ResendRequest **
行 427: 行 427:
 When a sequence gap is detected in a message from the investor system at the receipt of a SequenceReset-GapFill, CONNEQTOR shall send another ResendRequest to the investor system requesting a retransmission of the message, even though the GapFill process is still ongoing. When a sequence gap is detected in a message from the investor system at the receipt of a SequenceReset-GapFill, CONNEQTOR shall send another ResendRequest to the investor system requesting a retransmission of the message, even though the GapFill process is still ongoing.
  
-{{ :draft:investorfix:Figure 6.1.14 Gap Detection when Receiving SequenceReset-GapFill.svg?800 |Figure 6.1.14 Gap Detection when Receiving SequenceReset-GapFill}}+{{ ::spec:en:isv:Figure 6.1.14 Gap Detection when Receiving SequenceReset-GapFill.svg?800 |Figure 6.1.14 Gap Detection when Receiving SequenceReset-GapFill}}
 ;#; ;#;
 ** Figure 6.1.14 Gap Detection when Receiving SequenceReset-GapFill ** ** Figure 6.1.14 Gap Detection when Receiving SequenceReset-GapFill **
行 435: 行 435:
 When a sequence gap is detected in a message from the investor system at the receipt of a Reject, CONNEQTOR shall immediately send a ResendRequest to request a retransmission of the message. When a sequence gap is detected in a message from the investor system at the receipt of a Reject, CONNEQTOR shall immediately send a ResendRequest to request a retransmission of the message.
  
-{{ :draft:investorfix:Figure 6.1.15 Gap Detection when Receiving Reject.svg?800 |Figure 6.1.15 Gap Detection when Receiving Reject}}+{{ ::spec:en:isv:Figure 6.1.15 Gap Detection when Receiving Reject.svg?800 |Figure 6.1.15 Gap Detection when Receiving Reject}}
 ;#; ;#;
 ** Figure 6.1.15 Gap Detection when Receiving Reject **\\ ** Figure 6.1.15 Gap Detection when Receiving Reject **\\
行 445: 行 445:
 If an Application Message from the investor system and a ResendRequest from CONNEQTOR cross over after sending a ResendRequest following a detection of a sequence gap, CONNEQTOR will detect another sequence gap in the Application Message and send another ResendRequest. There is a possibility that another resent message could be lost, thus CONNEQTOR shall send a ResendRequest every time a sequence gap is detected. If an Application Message from the investor system and a ResendRequest from CONNEQTOR cross over after sending a ResendRequest following a detection of a sequence gap, CONNEQTOR will detect another sequence gap in the Application Message and send another ResendRequest. There is a possibility that another resent message could be lost, thus CONNEQTOR shall send a ResendRequest every time a sequence gap is detected.
  
-{{ :draft:investorfix:Figure 6.1.16 Cross-over between ResendRequest (retransmission request) and AplMessages.svg?800 |Figure 6.1.16 Cross-over between ResendRequest (retransmission request) and AplMessages}}+{{ ::spec:en:isv:Figure 6.1.16 Cross-over between ResendRequest (retransmission request) and AplMessages.svg?800 |Figure 6.1.16 Cross-over between ResendRequest (retransmission request) and AplMessages}}
 ;#; ;#;
 ** Figure 6.1.16 Cross-over between ResendRequest (retransmission request) and AplMessages ** ** Figure 6.1.16 Cross-over between ResendRequest (retransmission request) and AplMessages **
行 459: 行 459:
 The following diagram shows the basic sequences of CONNEQTOR normal messages. The following diagram shows the basic sequences of CONNEQTOR normal messages.
  
-{{ :draft:investorfix:Figure 6.2.1 Sequences From RFQ Sending to Receive Execution Notifice (Normal).svg?600 |Figure 6.2.1 Sequences From RFQ Sending to Receive Execution Notifice (Normal)}}+{{ ::spec:en:isv:Figure 6.2.1 Sequences From RFQ Sending to Receive Execution Notifice (Normal).svg?600 |Figure 6.2.1 Sequences From RFQ Sending to Receive Execution Notifice (Normal)}}
   - Investor system sends RFQ to CONNEQTOR.   - Investor system sends RFQ to CONNEQTOR.
   - CONNEQTOR sends acceptance notification to investor system.   - CONNEQTOR sends acceptance notification to investor system.
行 472: 行 472:
 The following diagram shows the basic sequences for an error case in RFQ sending. The following diagram shows the basic sequences for an error case in RFQ sending.
  
-{{ :draft:investorfix:Figure 6.2.2 Sequences of RFQ Sending (Error Case).svg?600 | Figure 6.2.2 Sequences of RFQ Sending (Error Case)}}+{{ ::spec:en:isv:Figure 6.2.2 Sequences of RFQ Sending (Error Case).svg?600 | Figure 6.2.2 Sequences of RFQ Sending (Error Case)}}
   - Investor system sends RFQ to CONNEQTOR.   - Investor system sends RFQ to CONNEQTOR.
   - CONNEQTOR sends rejection notice to investor system.   - CONNEQTOR sends rejection notice to investor system.
行 482: 行 482:
 The following diagram shows the basic sequences of RFQ Cancellation, etc. The following diagram shows the basic sequences of RFQ Cancellation, etc.
  
-{{ :draft:investorfix:Figure 6.2.3 Sequences of RFQ Cancelled, etc.svg?600 |Figure 6.2.3 Sequences of RFQ Cancelled, etc.}}+{{ ::spec:en:isv:Figure 6.2.3 Sequences of RFQ Cancelled, etc.svg?600 |Figure 6.2.3 Sequences of RFQ Cancelled, etc.}}
   - Investor system sends RFQ to CONNEQTOR.   - Investor system sends RFQ to CONNEQTOR.
   - CONNEQTOR sends acceptance notification to investor system.   - CONNEQTOR sends acceptance notification to investor system.
行 498: 行 498:
 The following diagram shows the sequences for an invalid protocol case where an downstream message from CONNEQTOR is not FIX compliant (i.e. it does not conform to the FIX protocol v4.2 (Errata)) and the investor system does not recognize it as normal. Figure 6.3.1 Sequence for Malformed Messages The following diagram shows the sequences for an invalid protocol case where an downstream message from CONNEQTOR is not FIX compliant (i.e. it does not conform to the FIX protocol v4.2 (Errata)) and the investor system does not recognize it as normal. Figure 6.3.1 Sequence for Malformed Messages
  
-{{ :draft:investorfix:Figure 6.3.1 Sequence for Malformed Messages.svg?600 |Figure 6.3.1 Sequence for Malformed Messages}}+{{ ::spec:en:isv:Figure 6.3.1 Sequence for Malformed Messages.svg?600 |Figure 6.3.1 Sequence for Malformed Messages}}
   - When investor system recognizes a message from CONNEQTOR as an invalid FIX-protocol, investor system sends a Reject to CONNEQTOR.   - When investor system recognizes a message from CONNEQTOR as an invalid FIX-protocol, investor system sends a Reject to CONNEQTOR.
   - Investor is required to contact TSE to investigate the cause of the error.   - Investor is required to contact TSE to investigate the cause of the error.
行 513: 行 513:
 The following diagram shows the sequences for an invalid protocol case where an upstream message from the investor system is not FIX compliant (i.e. it does not conform to the FIX protocol v4.2 (Errata)) and CONNEQTOR does not recognize it as normal. The following diagram shows the sequences for an invalid protocol case where an upstream message from the investor system is not FIX compliant (i.e. it does not conform to the FIX protocol v4.2 (Errata)) and CONNEQTOR does not recognize it as normal.
  
-{{ :draft:investorfix:Figure 6.3.2 Sequence for Malformed Messages.svg?600 |Figure 6.3.2 Sequence for Malformed Messages}}+{{ ::spec:en:isv:Figure 6.3.2 Sequence for Malformed Messages.svg?600 |Figure 6.3.2 Sequence for Malformed Messages}}
   - When CONNEQTOR recognizes a message from investor system as an invalid FIX-protocol, CONNEQTOR sends a Reject to investor system.   - When CONNEQTOR recognizes a message from investor system as an invalid FIX-protocol, CONNEQTOR sends a Reject to investor system.
   - When receiving another malformed message, CONNEQTOR resends a Reject.   - When receiving another malformed message, CONNEQTOR resends a Reject.
行 530: 行 530:
 The following diagram shows the sequences for an invalid data case (minor error) and the investor system does not recognize it as normal. The following diagram shows the sequences for an invalid data case (minor error) and the investor system does not recognize it as normal.
  
-{{ :draft:investorfix:Figure 6.3.3 Sequence for Malformed Messages.svg?600 |Figure 6.3.3 Sequence for Malformed Messages}}+{{ ::spec:en:isv:Figure 6.3.3 Sequence for Malformed Messages.svg?600 |Figure 6.3.3 Sequence for Malformed Messages}}
   - When investor system detects an invalid message content, it sends a Logout request to CONNEQTOR and release the FIX session. Furthermore, it is required to contact TSE to investigate the cause of the error.    - When investor system detects an invalid message content, it sends a Logout request to CONNEQTOR and release the FIX session. Furthermore, it is required to contact TSE to investigate the cause of the error. 
   - After getting rid of a cause, investor system sends a Logon request to CONNEQTOR to establish a FIX session.   - After getting rid of a cause, investor system sends a Logon request to CONNEQTOR to establish a FIX session.
行 543: 行 543:
 The following diagram shows the sequences for an invalid data case (minor error) detected by CONNEQTOR. The following diagram shows the sequences for an invalid data case (minor error) detected by CONNEQTOR.
  
-{{ :draft:investorfix:Figure 6.3.4 Sequence for Malformed Messages.svg?600 |Figure 6.3.4 Sequence for Malformed Messages}}+{{ ::spec:en:isv:Figure 6.3.4 Sequence for Malformed Messages.svg?600 |Figure 6.3.4 Sequence for Malformed Messages}}
   - When a data error (minor error) is detected by CONNEQTOR, the error content is set to Reject Message and sent to investor system.   - When a data error (minor error) is detected by CONNEQTOR, the error content is set to Reject Message and sent to investor system.
   - The entry message becomes invalid, but the FIX session is not released and processing of the next entry message continues.   - The entry message becomes invalid, but the FIX session is not released and processing of the next entry message continues.
行 568: 行 568:
 The following shows the daily system operation. The following shows the daily system operation.
  
-{{ :draft:investorfix:Figure 7.1.1 Daily System Operation.svg?600 |Figure 7.1.1 Daily System Operation}}+{{ ::spec:en:isv:Figure 7.1.1 Daily System Operation.svg?600 |Figure 7.1.1 Daily System Operation}}
 Reset the sequence number on the first Logon of the day. Reset the sequence number on the first Logon of the day.
 ;#; ;#;
spec/en/isv/connection.1691124735.txt.gz · 最終更新: 2023/08/04 13:52 by editor

ページ用ツール

特に明示されていない限り、本Wikiの内容は次のライセンスに従います： CC Attribution-Noncommercial-Share Alike 4.0 International
CC Attribution-Noncommercial-Share Alike 4.0 International Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki