Kamal: Created page with "The Order Execution Server receives order submissions from clients, routes them to appropriate execution venues or brokers, and tracks the lifecycle of each order from submiss..."

2026-05-27T20:10:32Z

Created page with "The Order Execution Server receives order submissions from clients, routes them to appropriate execution venues or brokers, and tracks the lifecycle of each order from submiss..."

New page

The Order Execution Server receives order submissions from clients, routes them to appropriate execution venues or brokers, and tracks the lifecycle of each order from submission through completion. It publishes execution reports to subscribed clients, enforces compliance rules and risk parameters, and maintains a persistent record of all order activity. By centralizing order routing and monitoring, the server ensures consistent application of trading controls while providing real-time visibility into order status across the system.

The Order Execution Server integrates with the [[Service Locator]] for authentication, the [[Compliance Server]] for rule validation, the [[Risk Server]] for position and loss monitoring, the [[Administration Server]] for risk parameters, the [[Market Data Server]] for pricing and board lot checks, the [[Uid Server]] for unique order identifiers, and a MySQL database (with optional replication) to persist order records and execution reports.

== Configuration ==

The Order Execution Server is configured via a YAML file with three top-level sections: <code>server</code>, <code>service_locator</code>, and <code>data_store</code>. An optional <code>session_start_time</code> field may also be specified. Below is the structure of the configuration file with example values:

<pre>
server:
# Primary network interface and port the Order Execution Server binds to.
interface: "0.0.0.0:20700"
# List of addresses the server is reachable at (for registration with Service Locator).
# Typically includes both public-facing and local addresses.
addresses: ["198.51.100.5:20700", "10.0.0.5:20700"]

service_locator:
# The address of the Service Locator (host:port).
address: "10.0.0.5:20000"
# The account username used by the Order Execution Server to authenticate with the Service Locator.
username: order_execution_server
# The password for the Order Execution Server's Service Locator account.
password: [REQUIRED]

# Data store supports replication: provide either a single MySQL endpoint
# or a list of endpoints to replicate writes across.
data_store:
# The address of the MySQL server.
address: "127.0.0.1:3306"
# The username used to authenticate with MySQL.
username: spireadmin
# The password for the MySQL user.
password: [REQUIRED]
# The name of the database schema where data is stored.
schema: spire

# Optional start time of the trading session (default: +infinity, meaning no session boundary).
session_start_time: "2026-01-01 09:30:00"
</pre>

A <code>setup.py</code> script is provided to generate the final <code>config.yml</code> from the <code>config.default.yml</code> template. Usage:

<pre>
--local 0.0.0.0 # Local interface (default: auto-detected IP)
--world 198.51.100.5 # Global/public interface (optional)
--address 10.0.0.5:20000 # Service Locator address (default: local_interface:20000)
--password [REQUIRED] # Service password for authentication
--mysql_address 127.0.0.1:3306 # MySQL server address
--mysql_username spireadmin # MySQL username
--mysql_password secretpw # MySQL password (default: --password if omitted)
</pre>

== Order Submission ==

Before routing, each order passes through a series of submission checks:

* '''Board Lot Check''' - Validates that order quantities conform to the security's board lot size.
* '''Buying Power Check''' - Ensures the account has sufficient buying power for the order, accounting for current positions and exchange rate conversions.
* '''Risk State Check''' - Verifies the account is in a risk state that permits new orders.
* '''Compliance Rule Check''' - Validates the order against all active compliance rules for the account or group.

Orders that fail any check are immediately rejected with an appropriate error message.

== Order Routing ==

The server routes orders to their specified destinations based on:

* Destination configuration (venue, broker, or internal order type like MOE)
* Symbol resolution against the venue and trading session

Orders that violate compliance rules or risk limits are rejected before routing.

== Execution Reports ==

Clients can subscribe to receive execution reports for:

* Specific accounts
* Groups of accounts
* Their own orders

Subscriptions enable real-time tracking of order activity across portfolios or trading desks.

== Order Cancellation ==

Clients can request order cancellation. The server:

# Validates the cancellation request against permissions and order state
# Forwards the cancellation to the destination
# Updates order state based on destination response

=== Bulk Cancellation Utility ===

A utility for bulk order cancellation supporting multiple use cases:

<pre>
--config config.yml # Configuration file
--region CA # Country code, venue, or security
--connections 8 # Parallel connections for performance
</pre>

The script supports parallel processing using multiple service connections to efficiently cancel large numbers of orders.

== Data Store Replication ==

The Order Execution Server supports a replicated data store, allowing order records to be written across multiple MySQL endpoints for redundancy. When multiple endpoints are configured in the <code>data_store</code> section, writes are replicated to all configured stores while reads can be served from any available replica.

== Management ==

The Order Execution Server is controlled using three operational scripts: <code>start.sh</code>, <code>stop.sh</code>, and <code>check.sh</code>.

=== start.sh ===

* Exits immediately if the server is already running.
* Creates a <code>logs/</code> directory if necessary.
* Moves any existing <code>srv_*.log</code> files into <code>logs/</code>.
* Starts the <code>OrderExecutionServer</code> process in the background.
* Reads network interfaces from <code>config.yml</code> and waits until the server is listening on at least one configured address.

This ensures the server is fully initialized before the script exits.

=== stop.sh ===

* Sends <code>SIGINT</code> to request a graceful shutdown.
* Waits for termination using exponential backoff (up to 300 seconds).
* Sends <code>SIGKILL</code> if the server fails to stop cleanly.
* Appends a forced-termination message to the most recent log file (if applicable).

This guarantees consistent shutdown behavior across normal and exceptional conditions.

=== check.sh ===

The <code>check.sh</code> script verifies whether the server is currently running by inspecting the PID recorded in <code>pid.lock</code> and testing whether the associated process exists.

== Logging ==

Upon startup, older log files are moved into the <code>logs/</code> directory.

Order Execution Server - Revision history

Kamal: Created page with "The Order Execution Server receives order submissions from clients, routes them to appropriate execution venues or brokers, and tracks the lifecycle of each order from submiss..."