Support Board
Date/Time: Mon, 27 Apr 2026 21:21:25 +0000
[Programming Help] - Custom DTC bridge to TT — best practices for position sync from server-originated closes
View Count: 17
| [2026-04-27 15:55:08] |
| User871634 - Posts: 3 |
|
Long-time Sierra Chart user here. The firm I trade for routes through Trading Technologies, so I'm required to send orders via TT.NET SDK. I built a custom DTC Protocol Server that bridges Sierra Chart to TT so I can keep using Sierra's chart, hotkeys, studies and Trade DOM while orders execute at TT. Most of the integration works correctly. I have a specific architectural question about position synchronization when my bridge originates closing orders. Setup: - Sierra connects via Global Settings → Data/Trade Service Settings → DTC Service - I'm running this on a sub-instance — main instance is on SC Data (Denali + Level 12), sub-instance points at the bridge on 127.0.0.1:11099, JSON encoding - Bridge LOGON_RESPONSE advertises: TradingIsSupported=1, OCOOrdersSupported=0, OrderCancelReplaceSupported=1, MarketDataSupported=1, MarketDepthIsSupported=1, SymbolExchangeDelimiter="." - Sierra sends Symbol="" and Exchange="" on submits; bridge mirrors that format on responses - Trade Account: real TT account name (no "SIM" substring) Bracket flow: - Parent SUBMIT_NEW_SINGLE_ORDER → bridge submits to TT, returns PendingOpen → Open → Filled ack chain - After parent fills, Sierra emits two SL/TP children as separate SUBMIT_NEW_SINGLE_ORDER messages, each tagged in FreeFormText as "Attached order. Parent: NNN. Tag: ..." - Bridge intercepts these "Attached" orders and keeps them as local fakes — they never reach TT. Bridge fake-acks PendingOpen → Open and emits 2-second heartbeats with OrderStatus=4 Open so Sierra's UI continues to render and hotkey-modify them - A trigger engine in the bridge watches market data; when the live last-trade price hits a local SL trigger or TP fill condition, the bridge submits its own market close order to TT Problem After my bridge-originated close fills at TT, Sierra's internal position state appears not to update. The user pressing Sierra's Flatten All button at this point fires a market order opposite to what Sierra still thinks the position is — opening a fresh opposite position at TT instead of being a no-op. We've also seen Sierra's automatic "close on bracket cancel" behavior fire a wrong-direction market a few seconds later for the same reason. After the bridge-originated close fill, the bridge emits all three of: 1. ORDER_UPDATE (Type 301) for the real TT-side close order: real ServerOrderID, the bridge-issued ClientOrderID (e.g. "TRG…"), OrderStatus=7 Filled, OrderUpdateReason=5 OrderFilled, correct FilledQuantity / LastFillPrice / AverageFillPrice, Symbol="" Exchange="NQM26-CME", TradeAccount set 2. ORDER_UPDATE for the local fake SL/TP: OrderStatus=8 Canceled, OrderUpdateReason=6 OrderCanceled (so the chart bracket lines clear) 3. Unsolicited POSITION_UPDATE (Type 306): Quantity=0, AveragePrice=0, OpenPL=0, Symbol="", Exchange="NQM26-CME", TradeAccount, Unsolicited=1, PositionIdentifier="acct|symbol" Despite all three, Sierra's position model in the sub-instance UI remains as if the close didn't happen. POSITION_UPDATE in response to an explicit CURRENT_POSITIONS_REQUEST does seem to be respected; it's the unsolicited push that doesn't appear to land. Questions 1 . Authoritative position source: does Sierra Chart reconstruct its internal position purely from ORDER_UPDATE chains where the originating SUBMIT was issued by Sierra itself, or is unsolicited POSITION_UPDATE accepted as authoritative? If neither, what's the correct way to reconcile? 2. Server-originated fills: when an ORDER_UPDATE Filled arrives with a ClientOrderID Sierra didn't issue (i.e., the bridge generated it for a server-side trigger close), does Sierra include that fill in its position math? If not, what marker would attribute it correctly — ParentServerOrderID? OpenOrClose on the ORDER_UPDATE? A specific OrderUpdateReason? 3. Unsolicited POSITION_UPDATE: what fields are mandatory and what's the correct format for PositionIdentifier? Is IsFinalMessage=1 required? Are there conditions under which Sierra ignores unsolicited position updates entirely? 4. Local-only attached orders: is there a documented or recommended pattern for a DTC server that wants Sierra to display and locally manage SL/TP without registering them at the broker, and then have Sierra's bracket UI clear cleanly when the server closes the position? 5. Flatten button semantics: when the user presses Flatten All (or Shift+, flatten hotkey), what does Sierra use as its source of truth for current position size and side — and how can a DTC server ensure that source stays in sync after server-originated activity? 6. Is there a better way to integrate these two systems that will allow me to keep all Sierra Chart functionality in execution? Any reference docs covering position-state semantics for custom DTC server implementations would be a huge help. The DTC documentation on sierrachart.com covers wire format thoroughly but I haven't found anything on the position-state-machine expectations. If Sierra has any plans for or recommendations regarding TT integration as a supported trading service in the future, I'd be interested to hear that as well. |
To post a message in this thread, you need to log in with your Sierra Chart account: