Edit Strategy Messages

For the frontend client, the trade model library handles the processing of these messages. Streamlinkis used to send messages to the backend. For Edit Strategy there are three messages that the client can send:

For the backend adapters, the FXIntegrationAPI consumes the client messages. The request for Edit Strategy are handled by an adapter that instantiates the FXOrdersAdapter object and registers an EditStrategyListener (See the FX Integration API documentation for more information). The Edit Strategy is handled by the FX Integration API using the EditStrategyRequest object. The object contains the Responders and Events required to send messages from the server side, in order to transition the trade model to the final state.

Blue arrows denote client messages and timeout messages, green arrows denote messages sent by the server.

In addition to the states shown above, all thats that are not the initial and complete state, can transition to the error state (see common messages for the error message)

This is the message the client sends in order to submit a request to cancel an order

This is the message that the server sends to acknowledge that the EditOpen message has been received by the server

This is the message that the server sends to tell the client that they may start editing the strategy. Typically the server may have to obtain locks or mark a strategy as being edited or something similar to this effect before a client can start editing a strategy. This message is also used by the server to tell the clients which fields on the strategy can be edited, for example it is normal to be able to edit the target rate and amount but perhaps not the currency pair or order IDs.

This message also includes the strategy fields.

This is the message that client sends to tell the client that it no longer wants to edit the order, before the order has reached the Editable state. Typically a lock may take a while to obtain, by this time the client may no longer be interested in editing the order and may close the ticket.

This is the message that the server can send to the client if the strategy has changed whilst the client is editing an order. Note: if this scenario occurs you may want to simply terminate the edit operation by sending an Error transition instead of Refresh, because in many cases the edit operation is no longer valid. For example, if a user is attempting to change the target rate on a working order and it is filled, it is no longer possible to edit that order. A Refresh is therefore unhelpful to the client.

This message also includes the strategy fields.

This is the message that the client sends that contains all the edits made to the strategy that they would like to save.

This message also includes the strategy fields.

This is the message that the server sends which tells the client that the edits received on the Save message have been succesfully executed. It returns the trademodel to the Editable state to allow the client to make further edits.

This message also includes the strategy fields.

This is the message that the server sends which tells the client that the edits received on the Save message have been succesfully executed. It transitions the trade to the Completed state. The client will need to open a new edit order ticket to make further changes. This is an alternative to the SaveAccept message.

This message also includes the strategy fields.

This is the message that the client sends which tells the server that they no longer wish to make any more edits to the strategy. Typically the server will release any locks it has on strategies when it recieves this message.

This is the message that the server sends to tell the client that it has received the Complete message, and transitions the trade model to the final state Completed.

This is the message that the server sends which tells the client that the save request could not be processed. This message moves the client back to the Editable state, so they can try sending a new Save message once they have corrected the problems.

This message also includes the strategy fields.

This is not actually a message, you may have noticed that in some of the messages above you will be asked to add the strategy fields to the contents of the message. The table below contains all the fields that relate to the strategy and its constituent legs.

Fields that are not prefixed with L1_, belong to the strategy.

For each leg on the strategy you will need to provide an additional set of LX_ prefixed fields, where 'X' is number of the leg, L1_ is used in the example below.

See Common Messages Specifications

See also: