0
Help us understand the problem. What are the problem?

posted at

updated at

auカブコム証券のkabuステーションREST APIで自前のトレイル注文の改善(残高管理方法変更)

はじめに

前記事

  1. auカブコム証券のkabuステーションREST APIをcurlで叩く
  2. auカブコム証券のkabuステーションREST APIをjava(generated by the swagger code generator)で叩く
  3. auカブコム証券のkabuステーションREST APIの残高照会をcurlとjavaで叩く
  4. auカブコム証券のkabuステーションREST APIの残高照会から先物OPのdeltaを計算する
  5. auカブコム証券のkabuステーションREST APIのテスト用モックサーバーを作る
  6. auカブコム証券のkabuステーションREST APIの認証済TOKENをファイル管理する
  7. auカブコム証券のkabuステーションREST APIで自前のトレイル注文を作ってみる(情報収集編)
  8. auカブコム証券のkabuステーションREST APIで自前のトレイル注文を作ってみる(注文発注編)
  9. auカブコム証券のkabuステーションREST APIで自前のトレイル注文を作ってみる(ツール完成編)
  10. auカブコム証券のkabuステーションREST APIで自前のリピート注文を作ってみる(注文約定調査編)
  11. auカブコム証券のkabuステーションREST APIで自前のトレイル注文の改善(トレイル幅の動的拡張)
  12. auカブコム証券のkabuステーションREST APIで自前のリピート注文を作ってみる(設計、検証用実装編)
  13. auカブコム証券のチャートデータの日付を調整する
  14. auカブコム証券のkabuステーションPUSH APIのサンプル
  15. auカブコム証券のkabuステーションREST APIで自前のリピート注文を作ってみる(リファクタリング編)
  16. auカブコム証券のkabuステーションPUSH APIを受信してCSVファイルへ保存する
  17. 5分足の時刻を列挙する
  18. 保存した4本値チャートデータの終値と、PUSH APIで受信したチャートデータをマージする
  19. マージしたチャートデータからテクニカル指標を計算する(SMA6,SMA12,SMA24編)
  20. マージしたチャートデータからテクニカル指標を計算する(ボリンジャーバンド編)
  21. auカブコム証券のkabuステーションREST APIで自前のトレイル注文の改善(前回実行時からの高値/安値)

当初、残高管理方法を含み益を記録する目的で設計したため、後になって無理な状態のまま使っていた。
特に決済後に含み益の値がクリアされない問題の解決が難しいので主キーを変更する。

修正前のカラム定義

主キーは、(code, price, side)の複合キー。同じ価格の建玉が1レコードにまとめられるため、返済注文のためにexecutionIdsがリストで管理する必要がある。
APIの主キーはexecutionIdのため、APIのレスポンスから生成と削除のタイミングが一致しない。開発当初は、決済注文から新規注文までのstate遷移がどんくさいため、2ターンほど余計に時間がかかっていたため、いったんこのレコードが削除されてから、新規注文決済された際のレコードが作成されていた。しかし、state遷移の見直しを行った結果、異なるexecutionIdで同じ価格の注文が入れ替わることが起きると、以前の含み益などの情報が引き継がれてしまい、トリガーの発生が初期値条件とならない問題がある。

No Name Description Example
1 code 残高照会APIの銘柄コード(Symbol) 167060019
2 name 残高照会APIの銘柄名(SymbolName) 日経225mini 22/06
3 price(qty) 残高照会APIの値段(Price)と残数量(LeavesQty)、拘束数量(HoldQty)の集計 28000(2-0)
4 side 残高照会APIの売買区分(Side)。1(S):売、2(L):買。 1(S)
5 curPrice 残高照会APIの現在値(CurrentPrice) 27675
6 profitHigh 含み益の最大値 325
7 profitLow 含み損の最小値 -10
8 triggerPrice トリガー価格 27700
9 createDate 作成日時(currentTimeMillis値)と文字列形式 1649136073840(2022/04/05 14:21:13.840)
10 updateDate 更新日時(currentTimeMillis値)と文字列形式 1649136073841(2022/04/05 14:21:13.841)
11 executionIds 残高照会APIの約定番号(ExecutionID)と残数量(LeavesQty)、拘束数量(HoldQty)の配列をカンマ区切り E2022040601ZS8(1-0),E2022040603BWT(1-0)

修正後のカラム定義

主キーはexecutionIdで、APIの主キーと同じため、APIのレスポンスから生成と削除のタイミングが一致する。
決済されればexecutionIdに紐づく含み益が削除され、別レコードで作成されるため、含み益の管理が容易になる。

No Name Description Example
1 executionId 残高照会APIの約定番号(ExecutionID) E2022040601ZS8
2 code 残高照会APIの銘柄コード(Symbol) 167060019
3 name 残高照会APIの銘柄名(SymbolName) 日経225mini 22/06
4 price 残高照会APIの値段(Price) 28000
5 leavesQty 残高照会APIの残数量(LeavesQty) 2
6 holdQty 残高照会APIの拘束数量(HoldQty) 0
7 side 残高照会APIの売買区分(Side)。1(S):売、2(L):買。 1(S)
8 curPrice 残高照会APIの現在値(CurrentPrice) 27675
9 profitHigh 含み益の最大値 325
10 profitLow 含み損の最小値 -10
11 triggerPrice トリガー価格 27700
12 createDate 作成日時(currentTimeMillis値)と文字列形式 1649136073840(2022/04/05 14:21:13.840)
13 updateDate 更新日時(currentTimeMillis値)と文字列形式 1649136073841(2022/04/05 14:21:13.841)

readPositions()の公開

MainTrailOrderは、含み益を判断するため、execute()メソッドを呼び出す必要があるが、EntryOrdersLogicやMainStopLossOrderは参照する目的のため、本来ならばreadPositions()でファイルから読むだけでよい。
しかし、readPositions()がexecutionIdsカラムを読まずに、APIのレスポンスから毎回生成していたために、毎回execute()を呼び出していた。

修正後のカラム定義ではexecutionId単位で読むことが可能で、APIの呼び出し回数を減らすため、readPositions()でファイルから読む。

追記:ソートキーの修正

修正前のカラム定義のときは、(code, price, side)が主キーであり、ソートキーだったが、修正後で(executionId)を主キーで、ソートキーにすると、price順に並ばないので、ソートキーを変える。
なお、(code, price, side)より(code, side, price)の方がロング/ショートでグルーピングできるので、後者にする。
(code, side, price)が複数レコード存在する可能性があるので、あまり意味はないが(code, side, price, executionId)をソートキーにする。
今の時点では問題はないので、結合した文字列で比較する。

OPなど桁数の異なるcode, priceが入ってきたときに対応する。

githubソース

Register as a new user and use Qiita more conveniently

  1. You can follow users and tags
  2. you can stock useful information
  3. You can make editorial suggestions for articles
What you can do with signing up
0
Help us understand the problem. What are the problem?