Order Modify Process. 주문정정처리. 관련 메시지 핸들러에서의 처리로직.

	개요.
	주문정정(Order Modify) 작용 이해.  Order Modify 는 이미 거래소에 있는 Order New 를 수정하여 새로운 Order New 를 생성하는 과정이다.  Client 에서 처음 부터 Order New 를 전송하여 거래소에 Order New 가 생성 되어 있는것이나,  이미 거래소에 있었던 Order New 를 수정하여 새롭게 Order New 를 생성하나 완전 동일한 결과이다. 따라서, client 측의 주문관리 로직 구현시에 Order Modify 는 Order New 를 생성하고 전송하는 것과 별반 다를게 없다. 차이나는 부분은 주문전송시 데이터의 내용이 다르다는점이며,  특히 수정대상의 주문아이디 를 지정해주는 부분과 "주문정정" 명령전송시 필요한 데이터가 다르다는 점이다.  해당 주문정정이 거래소에서 타겟 주문에 적용된 경우는 새롭게 생성된 Order New 를 관리해야한다. 해당 주문정정이 거래소에서 적용되지 못한 경우는 새로운 OrderNew 가 생성된 것이 아니므로 관리할 Order New 는 없다.

 

	Order Modify Process
	1. Order New 개체 생성. - 자체 관리아이디 할당. - 주문수정이 Exchange 에서 적용된 경우 거래소에 생성될 OrderNew 에 대응하는것을 미리 만들어 둔것임. 2.  Order Modify 개체 생성. - 자체관리아이디 할당. - 상기1을 Order Modify 개체의 멤버로 대응시켜둠. 3. Order Modify 전송용 데이터 생성. 4. 상기3을 거래소 전송. 전송경로 : 클라이언트(내 컴퓨터) -> Broker (증권사) -> Exchange(거래소) 상기 4이후에 Broker 와 Exchange 에서 Client 로 메시지 전송해옴. 5. Broker 에서 발송한 메시지 수신처리.  -  "주문아이디"와 상기 2의 클라이언트(내 컴퓨터)에서 생성한 주문 개체의 1:1대응 시킬 수 있는 유일한 지점이다. 6. Exchange 에서 발송한 거부,정상 메시지 수신처리. - 메시지에 "주문아이디" 를 같이 포함하여 전송해주고 Modify 적용 여부를 알려준다. 7. 상기6에서 "주문정정"이 거래소 정상처리된 경우, 이후 체결 메시지 통보가 발생할 수 있다. 정정것에 해당하는 "주문신규"가 거래소에 생성되며, 이후 체결이 발생한 시점에 채결메시지를 거래소가 클라이언트로 전송해준다. 상기 5,6,7에서 주요처리사항. 상기 5, 6, 7의 메시지 발생 순서가 고정되어있지 않다. 즉 5가 먼저 수신될 때도 있고, 상기 6이 먼저 수신될 때도 있다. 심지어는 7이 가장 먼저 수신될 수 도 있다. 상기 5의 시점이 client 에서 생성한 Order Modify 개체와 주문아이디의 대응을 알 수 있는 유일한 지점이므로 상기 6 혹은 7이  먼저 수신된 경우에는 이 주문아이디가 클라이언트에서 생성한 어떤 주문개체의 것인지 알 방법이 없다. 따라서, 상기 6, 7이 먼저 수신된 경우에는 주문아이디를 비롯하여 이 시점에 수신된 정보들을 임시 저장해뒀다가 상기5의 메시지 수신시점에서 클라이언트에서 관리하는 주문개체들의 미완성된 정보들을 확정시키는 처리 수행해야만 한다.

 

	"주문정정" 명령 전송이후 메시지 핸들러에서의 처리로직.
	검토. 주문정정과 관련되어 연동되는 3개의 메시지 핸들러가 있다. 각각의 메시지 핸들러의 처리 로직. 본 처리로직은 아래 사항이 고려된 것이다. 1. 3개 메시지의 발생순서가 고정되어있지 않다는 점. A. 주문정정 Broker ID 메시지. B. ExchAcpt 메시지, C.체결메시지. 2. 클라이언트에서 생성한 주문개체의 OrderID가 확보되는 지점은 Broker OrderID 메시지 수신지점뿐이라는점. 3. 상기 2의 요소때문에 주문정정 거래소수락(ExchAcpt) 메시지 핸들러, 체결메시지 핸들러 내에서 가장 먼저 Broker OrderID 메시지가 먼저 수신되었는지 체크하는 부분을 가장 먼저 선행하고 있다. 로직 무결성 검토. 3개의 메시지 A. 주문정정 Broker ID 메시지. B. ExchAcpt 메시지, C.체결메시지. 의 발생순서는 아래와 같이 총 6개의 순서가 가능하며 각각의 순서대로 메시지 발생한 경우 상기 처리로직대로 진행된 경우 모순없는지 점검한다. 메시시 발생순서   로직점검.    A, B, C A에서의 처리. OrderID가 클라이언트의 어떤 주문에 의한것인지 알수 있게 되고 이것을 컬렉션 map_CyOrderIDNew[OrderID]에 저장해두는걸로 끝. B 에서의 처리 CyOrderNew에 B에서 수신된 정보갱신하고 끝. C에서의 처리. CyOrderNew에 C에서 수신된 정보 갱신하고 끝. CyOrderNew  정보갱신순서. 거래소 접수 -> 체결  A, C, B A에서의 처리 : 상동. C에서서의 처리. : 상동. B에서의 처리 :  이상함. 체결 -> 거래소 접수 순. 즉, 정보가 모두 확보는 되나, 순서가 이상함. C에서 정정주문에 의해 신규 생성된 주문신규의 체결정보 갱신된 다음에 주문정정의 거래소 접수 정보가 갱신되는 순서다. 이 순서가 문제를 일으키지 않을지 점검필. 희망하는 CyOrderNew  정보 갱신순서는  거래소접수 -> 체결 순이다.  B, A, C  B에서의 처리. map_PreExchAcpt 에 정보임시저장. A에서의 처리. OrderID 에 대응하는 주문신규 개체에 ExchAcpt 정보갱신. C에서의 처리. OrderID 에 대응하는 주문신규 개체에 Fill  정보갱신. CyOrderNew  정보갱신순서.  거래소접수 -> 체결.  B, C, A B에서의 처리. map_PreExchAcpt 에 정보임시저장. C에서의 처리. map_PreFill 에 정보임시저장. A에서의 처리.  체결정보수신된것 등록시에 거래소접수부터 먼저갱신처리함.   CyOrderNew  정보갱신순서. 거래소접수 -> 체결  C, A, B  C에서의 처리. map_PreFill 에 정보임시저장. A에서의 처리.  체결정보수신된것 등록시에 거래소접수부터 먼저갱신처리함. B에서의 처리. A에서 이미 거래소 접수 정보갱신했기 때문에 무처리.   CyOrderNew  정보갱신순서. 거래소접수 -> 체결  C, B, A  C에서의 처리. map_PreFill 에 정보임시저장. B에서의 처리. map_PreExchAcpt 에 정보임시저장. A에서의 처리.  체결정보수신된것 등록시에 거래소접수부터 먼저갱신처리함.   CyOrderNew  정보갱신순서. 거래소접수 -> 체결 상기 검토에서는 A, C, B 순서로 발생한 경우외에는 CyOrderNew의 정보 갱신순서가 모두 거래소 접수 -> 체결순으로 정보 갱신되고 있다. A,C,B의 경우에는 체결 -> 거래소 접수 순으로 처리되고 있는데 이것 원하는 바 아니다. 이를 해결하기 위한 방법으로 체결 메시지 처리부를 아래처럼 변경하면 완전해진다. 추가된 부분은 1. "정정에 의한 주문신규에서의 체결" 판정부 . 즉 현재 체결발생한 건이 정정에 의해 생성된 주문신규에서의 체결 인지 점검하는것. 2. 상기 1이 참 인 경우 ExchAcpt 정보 갱신 여부 판정. 3. 상기 2에서 ExchAcpt 가 갱신되지 않은 경우 ExchAcpy 정보부터 갱신하고, 그다음 fill 정보 갱신처리하고 있다. 4. 상기 2에서 ExchAcpt가 이미 갱신되어있는 경우엔 Fill 정보만 갱신처리하고 있다. 상기 유일하게 불완전한 결과를 주는 A, C, B 순서로 발생한 경우를 보면, A시점 이후 C 메시지 수신된 경우 아래 2번째 판단문 "정정에 의한 주문신규에서의 체결"에서 참인 상황이고, 그 다음 판단문 "ExchACpt 가 현재 갱신되지 않았는가?" 에서 참인 경우는 현재 C실행시점에 B가 먼저 수신되지 않았다는 말이다. 이때는 ExchAcpt 를 먼저 갱신하고(갱신했음을 개체에 마킹도 해둔다.), 그다음 Fill 정보 갱신 하므로 OrderNew, OrderModi 개체의 정보 갱신순서는 거래소 접수(Modi의 접수수락, OrderNew의 거래소 생성까지 확정된 상태) ->  체결(OrderNew 의 체결) 순으로 희망하는 순서로 정보갱신되며, "ExchACpt 가 현재 갱신되지 않았는가?" 에서 부정인 경우는 B가 수신되었다는 말이고, 이미 "거래소 접수 수락" 건에 대해서 정보갱신완료되어있다는 말이다. 이때는 Fill 정보만 갱신하고 있다. 즉, 이 경우에도 거래소 접수 -> 체결 순으로 정상적인 순서로 정보 갱신되고 있다. 즉, 위에서 살펴본 바와 같이 정정에 의한 주문신규에서 발생한 체결 이벤트인 경우 모두 희망하는 순서대로 됨을 확인했다. 한편, 본 체결 메시지는 모든 주문신규(정정에 의해 생성된 주문신규외에도)에 의해서 발생하는데, 정정에 의한 주문신규가 아닌 경우에는 2번째 판단문에서 부정의 경로를 따라 실행되고, Fill 정보만 갱신처리되고 있다. 즉, 일반 주문신규인 경우에는 ExchAcpt 메시지가 발생하지 않고(단 거부는 발생할 수 있다는데<- 이것의 실제 발생여부가 명확하지 않아  주문신규에 대한 거부발생한 경우의 처리는 일단 고려치 않고 있다. 실전에서 활용하면서 결정할 일이다.) 와 체결 메시지 단 2개의 메시지만 발생가능하며   A->C, 혹은 C->A 의 순서만 가능하므로 정정에 의한 메시지 처리부 도다는 간단해진다. 1차 결론. - 처리요소가 많은 것이 만족스럽지 않고, 처리의 일관성 결여됨. 2차 결론. 검토 결론. -  최종 아래와 같은 3개의 메시지 처리부의 로직으로 구현하면 무결성 처리 달성됨. -  앞의 2차 결론에서의 Broker OdID수신, ExchAcpt 와 동일한것이나 실제 코딩의 간결함을 위하여 ExchAcpt 의 위치만 변경된 것임. -  메시지 수신순서 총 6개의 케이스에 대하여 각각의 상황에서 무결성위배 있는지 검토하였고 모든 상황에서 완전함. -  처리요소가 간결하여 코드 유지 보수 유리함. 속도에서 손해보는것 없음. 아래 체결부의 처리사항은 "주문정정" 에 의한 주문신규뿐만 아니라, 일반 주문신규 처리포함하여 정상적으로 수행하는 루틴임. 아래 첫번째 처리 블럭에서의 OrderNew 란 "주문정정" 에 의하여 새롭게 생성된 "주문신규" 개체를 의미함. CyFinAPI체계에서는 "CyOrderModify"개체 생성시 "CyOrderNew"개체도 동시에 생성하는 것으로 운용하고 있다.

 

///540.