Exberry Order placement - Websocket responses

[brianweir-da]

When submitting orders or sending commands with Exberry via a websocket connection, the client is responsible for providing a SID along with any request. From the Exberry documentation, we have the following definition for this :

sid (int) : stream identifier, for each WebSocket connection. this is a unique identifier for the API call. Please note that as long as the sid was not ended (other by exchange or by consumer) this can’t be used again on the same WebSocket connection

A sample request to place an order at the exchange looks like the following :

{ "q":"v1/exchange.market/placeOrder", "sid": 1, "d":{ "mpOrderId": 123, "userId": "1", "orderType": "Limit", "side": "Buy", "instrument": "BTC", "quantity": 123, "price": 100.555, "timeInForce": "GTC" } }

In this example, the 'sid' is set to 1 and our client order reference is 123 (mpOrderId stands for 'Market Participant Order Id') is part of the order details submitted to Exberry.

When we receive a response to this message from Exberry, they use the sid to relate message used on the currently established websocket connection meaning we have to store this session identifier to link it to the order sent. For example, a successful response to the message above is :

{ "q":"v1/exchange.market/placeOrder", "sid":1, "d":{ "orderId":2345, "orderStatus":"Pending" } }

The orderId 2345 in the response above is Exberry's reference to our order submitted earlier. We can only reconcile this response using the session id. Having to use this as the link between our submitted order and Exberry's order id is an issue. This pattern of using the session id has leaked into the design implementation of the Marketplace and Exberry Integration as follows :

1. The daml model for order uses this sid as its key;
2. The Exberry Adapter manages the sid as an incremented counter which gets reset on each restart. The sid gets set and incremented as the mpOrderId field for each order request when creating the NewOrderRequest contact which the Exberry Integration listens to.
3. The Exberry Integration manages the websocket connection but not the sid. It listens for NewOrderRequests and uses the mpOrderId as both the mpOrderId and the sid in the message generated and sent to Exberry via an established websocket connection. It does not check if the sid has already been used.

This usage can cause :

1. a duplicate key issue on the ledger when creating the Order contract.
2. sid already used on the websocket connection with Exberry when the Exberry Adapter is restarted
3. mpOrderId is already in use from Exberry as an order already used this id

This means Eric has to manually set the sid using the ExberrySid contract before giving a demo to ensure this error doesn't occur when presenting to clients.

Resolution :

1. Strategic solution : Exberry to add the clients order id in the response and thus we wouldn't need to use the websocket session identifier to link back to our original order.
2. Tactical solution :

• Move the sid management into the Exberry Integration since it maintains the websocket connection with Exberry and avoids the issue when the Exberry adapter is restarted and resets the sid back to 1.
• Change the key on the Order template not to refer to the sid