Announcement

Collapse
No announcement yet.

Partner 728x90

Collapse

reconnect to open Position

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    reconnect to open Position

    Hi.

    Task: reconnect to the open position after re-open the strategy
    Steps:
    1. the strategy is enabled.
    2. the strategy to open the position.
    3. manual shutdown of the strategy(a stress test, it may be shut down after exception).
    4. the position remains open.
    5. reconnection the strategy from code.
    6. the strategy enabled. the position is still open.
    7. access to the position from the strategy is limited.
    8. tracing writes there is no exit to the position.
    9. orders are present in the table.

    Goal: how to access the open position data from a re-enabled strategy?
    ************************************************** ********************************
    used:
    Code:
    ...
    lock (NinjaTrader.Cbi.Account.All)    myAccount = NinjaTrader.Cbi.Account.All.FirstOrDefault(a => a.Name == "Sim101");
    ...
        foreach(var posa in myAccount.Positions)
            {
                if(posa.Instrument.MasterInstrument.Name.Equals(ticker))
                {
                    if(posa.MarketPosition == MarketPosition.Long)
                    {
                            ExitLong(close, open);// order sent but without target goal
                    }
                    //if to used Position.MarketPosition, market position after reconnect always FLAT.
    Click image for larger version

Name:	Q_6.png
Views:	117
Size:	114.2 KB
ID:	1213092
    Attached Files
    Last edited by Danila; 08-24-2022, 10:38 AM.

    #2
    Hello Danila,

    It may or may not be possible to resync that position with the steps you listed. This depends on how your strategy works historically. To resync orders or positions that is what the Start Behavior is for. You can read about the different behaviors in the following link:



    A short summary of what would need to happen:

    1. the strategy is enabled.
    2. the strategy to open the position.
    3. manual shutdown of the strategy(a stress test, it may be shut down after exception).
    4. the position remains open.
    5. manually re enable the strategy
    6. Strategy processes historical bars
    7. The exact same sequence of events that originally created the position now need to happen historically to recreate that position again.

    If for any reason the strategy cannot historically recreate the position then it will not know about it when the strategy hits realtime. If you find that your strategy cannot historically work in the same way then it would not be possible to resync it. You would need to manually close the position and then start your strategy over.

    The code you are showing also should not be used to manipulate positions from a strategy, you are referencing an account directly which is not how strategies work. The position exists on the account but the strategy does not know about that because it did not create it when you re enabled it. Trying to exit the account position with the strategy logic won't work. That code is not relevant to what your strategy is actually doing. That code is from the addon framework and would be used from other types like Indicators or addons which don't have an account selection. Strategies use their own virtualized performance so they have their own position and other values separate from the actual account.

    Comment


      #3
      Hi Jesse! Thank You for your answer.

      This depends on how your strategy works historically.
      my strategy is simple. it was created only to process orders and send data (bars, orders, account statistics) to another source. there is no logic in the strategy.
      I need to get access to the current position when reconnecting to further manage it. how should the strategy work historically?


      7. The exact same sequence of events that originally created the position now needs to happen historically to recreate that position again.

      If for any reason the strategy cannot historically recreate the position then it will not know about it when the strategy hits real-time. If you find that your strategy cannot historically work in the same way...
      what do you mean by "The exact same sequence of events", which events are you writing about? Please provide a simple code example that will exactly repeat the events on restart.
      You write "If for any reason...", it means it's possible. if it was not possible. you wrote, "since it is not possible to recreate, then ..."

      And do not understand:
      I have access to the order and a re-run strategy on the same ticker as the order.
      but I can't get access to the order state management from the code (closing the order not when the strategy is restarted by Start Behavior)
      Even if the strategy is virtualized, what is the reason for limiting my ability to manage my orders after restarting the strategy?
      I have the name of the order, its status, ticker, and the name of the account.

      The code you are showing also...
      it was an attempt with crutches because I did not find a direct and natural way to achieve the goal.

      Base Q: how to get control over open position orders using API after manually restarting the strategy on the same ticker?
      more precisely, after reconnecting, I want to resume control over the open order and position data.
      ps. starting behavior without closing open orders.
      Last edited by Danila; 08-25-2022, 03:09 AM.

      Comment


        #4
        Hi again!
        If I use the sync behavior, how to get the names of the orders that were closed when reopening the strategy?
        If I use the synchronization behavior in the main window in the tabs Orders/Executions there is no data on which open order they are closed, only the name of the closing is "Synchronization"

        Comment


          #5
          Hello Danila,

          I need to get access to the current position when reconnecting to further manage it. how should the strategy work historically?
          You would need to develop your strategy to work historically the same as it does in realtime to do that. If your strategy creates a position in realtime based on some condition and then you disable it, it will loose track of that position. For it to re learn about that position it would need to re create that same orders which created the position originally.


          what do you mean by "The exact same sequence of events", which events are you writing about?
          In your strategy you have conditions to enter orders. The exact same sequence of events would mean that in relatime some condition became true to enter. That bar is now a historical bar when you re enable the strategy at a later time. The strategy would need to now process the historical data and re submit that order during historical to create that position again in order to know about it.

          Please provide a simple code example that will exactly repeat the events on restart.
          You write "If for any reason...", it means it's possible. if it was not possible. you wrote, "since it is not possible to recreate, then ..."
          I don't have a sample of that, this heavily relies on your trading goals and the conditions you created. An example where you can't re create the same events would be if you used OnEachTick in realtime, in historical OnBarClose is used. That would mean the condition to enter can't be checked in the same way during historical processing so it wouldn't be able to re create the same orders. A case where you can see similar results would be if you use OnBarClose processing. In both realtime and historical the same processing is used for your conditions so it could potentially produce the same result as it did in realtime. This heavily depends on the conditions you create and what the requirements to enter orders are.

          I have access to the order and a re-run strategy on the same ticker as the order.
          but I can't get access to the order state management from the code (closing the order not when the strategy is restarted by Start Behavior)
          Even if the strategy is virtualized, what is the reason for limiting my ability to manage my orders after restarting the strategy?
          I have the name of the order, its status, ticker, and the name of the account.
          I explained this in my last post, the addon code you are using is not intended to be used in a strategy. You don't actually have access to the orders or that position, the strategy doesn't know about it because it didn't re create the orders that created that position. The code you are using is for addons or other types of scripts that don't normally work with the account. That code can see the account position directly but your strategy cant work with that position using strategy methods. The strategy needs to create the order/position while enabled to be able to work with them. A previous strategy can submit an order or create positions but a new strategy cant work with those items. A new strategy would need to also create those same orders or positions to be able to work with them.

          Base Q: how to get control over open position orders using API after manually restarting the strategy on the same ticker?
          more precisely, after reconnecting, I want to resume control over the open order and position data.
          ps. starting behavior without closing open orders.
          Your strategy needs to re create that position when you re enable it to track it again. When you disable a strategy that instance is done working forever. The next time you reenable it that is a brand new instance, it will need to re process the bars and start all over again. If your historical logic does not re create the same orders which leads to that position then it won't know about that position.


          If I use the sync behavior, how to get the names of the orders that were closed when reopening the strategy?
          The strategy would have to create the orders while running to know about them. The sync behavior notes that any open orders which the strategy did not create will be cancelled. By create that means this instance, not a previous instance. A previous instance of the strategy may have created the orders but they wont be relevant to the new instance, that new instance needs to re create the orders to know about them.


          If the strategy cannot re create the same orders/positions in historical it is generally suggested to avoid disconnecting or restarting the strategy. That strategy is not going to be able to resume where it left off.









          Comment


            #6
            Thank you very much for such a precise and detailed answer.
            I really appreciate it, thanks again for your answer and your time.

            I understand and accept your answer.

            but the main thing is not clear: How to implement it?
            Please specify how to send order(s) "to the history" after/during/before reconnecting the strategy.

            my strategy is simple:
            1. The strategy receives a request from a custom queue.
            2. Using your API create order(s) and sends it to the NT.
            3. The strategy then processes the NT responses
            and returns them (order(s)...) to an external module that is outside NT.

            I have all the data for a previously submitted order.
            1. What data do I need to create a historical order?
            2. What code and in what area of strategy should I
            implement to add to the "history" order(s)?
            3. How do I understand that the system really accepted this "to history" order(s)
            and that my code controls the previously opened order and that past position?

            Thank You in advance.
            Last edited by Danila; 08-25-2022, 09:49 AM.

            Comment


              #7
              Hello Danila,

              From the details it sounds like either you won't be able to or you would need to figure out how to re process the #1 step for historical bars.


              1. The strategy receives a request from a custom queue.
              This is different that how normal strategies work. A strategy normally will process historical data and then move into realtime. From your description it sounds like you are getting some kind of signal in realtime which the strategy acts on.

              We can walk through a simple example of how a normally strategy works for historical and realtime.
              By default strategies start by calling OnBarUpdate for bar 0, then bar 1 etc until it moves into realtime. All of the data on the chart when the strategy starts are historical bars so it will process that data first. If we make a quick example of an entry condition that uses bar data:
              Code:
              if(Close[0] > Open[0])
              { 
                  EnterLong(); 
              }
              The strategy checks each historical bar for this condition and when it is true it will enter a historical order and enter a historical position. Once it is done processing the historical data and moves into realtime this same condition is used to provide realtime orders and positions. If you stop the strategy and then restart it the strategy again starts on bar 0 and moves forward until it reaches realtime all over again.

              If we assume that the strategy used this condition in realtime and you then stop the strategy and restart it then it will again re process historical data and move into realtime. The difference here is that the realtime entry that was submitted will now be on a historical bar because we are moving forward in time. The strategy would need to re submit the same order on the now historical bar to enter a historical position and then move into realtime. By doing that the strategy can resume that position because it re submitted it on the historical bar which is the same time that it had originally submitted it in realtime when taht was a realtime bar.

              If your strategy is getting signals from an outside source or something that only works in realtime that won't be happening again in historical when it reprocesses. You would have to figure out a way to store these realtime signal events from the custom queue with a timestamp so that when the strategy re processes historical data it sees those events again on those historical bars. Your existing logic to enter can be reused you mainly just need the conditions to become true on the same bars regardless if its realtime or historical processing.





              Comment


                #8
                Hi Jesse!

                Thanks a lot for your detailed answer. Now the puzzle is complete.
                Tanks again!

                Comment

                Latest Posts

                Collapse

                Topics Statistics Last Post
                Started by NullPointStrategies, Yesterday, 05:17 AM
                0 responses
                64 views
                0 likes
                Last Post NullPointStrategies  
                Started by argusthome, 03-08-2026, 10:06 AM
                0 responses
                139 views
                0 likes
                Last Post argusthome  
                Started by NabilKhattabi, 03-06-2026, 11:18 AM
                0 responses
                75 views
                0 likes
                Last Post NabilKhattabi  
                Started by Deep42, 03-06-2026, 12:28 AM
                0 responses
                45 views
                0 likes
                Last Post Deep42
                by Deep42
                 
                Started by TheRealMorford, 03-05-2026, 06:15 PM
                0 responses
                50 views
                0 likes
                Last Post TheRealMorford  
                Working...
                X