MultiContext in Order Manager

OrderManager now supports MultiContext behaviour. To enable the MultiContext behaviour you must set the SessionConfig parameter OrderManager.MultiContext to true. You can add/remove contexts dynamically. The user can set up the MultiContext behaviour by either using the MultiContext Helper Utility or it can send the SetupContext request. The creation of the context is the responsibility of the user.

MultiContextAPI

The following events are available:

event SetupContext {
string marketId;
string requestId;
context ctx;
}

Used to register/initialize a context. This event should be sent to the Main Context. Parameters are as follows:

requestId. A unique identifier for this request. A SetupContextResponse will be received with the same id.

ctx. The context user wants to register.

Once the context is registered, the API will respond with a SetupContextResponse.

event SetupContextResponse {
string marketId;
string requestId;
context mainCtx;
}

A response event that will be received in the newly created context once the context is successfully registered. The requestId will be the same as the one passed in the SetupContext event. A reference to the main context is sent in this response.

event ClearContext {
string marketId;
string requestId;
context ctx;
}

Used to unregister/uninitialize a context. This event should be sent to the Main Context. The API will respond with a clear context response.

event ClearContextResponse {
string marketId;
string requestId;
string success;
}

A response event that will be received in the context that was cleared, once the context has been removed. The parameter success will be true only when there are no pending orders in this context.

Example usage:

context mainContext;

action onload(){
mainContext := context.current();

//create the context
context c := context("dummy", false);
spawn setup to c;
}

action setup(){
string id := "request1";

//register this context with the API.
enqueue com.apama.fix.SetupContext(marketId, id, context.current()) to mainContext;

on com.apama.fix.SetupContextResponse(marketId=marketId, requestId=id){
//context registered succesfully
//send orders
}
}

MultiContextHelper

A set of actions user that can use to add/remove contexts. The following actions are available:

action init(string marketId, context refContext)

Used to register a context with the MutliContext API. You must call this action from the newly created context. The parameters are as follows:

marketId. The transport name.

refContext. Should be the Main Context.

Note:
refContext should be an already existing context, otherwise this context will not be registered. When the context is getting registered, you can send Orders to this context. These orders will be queued and will be sent once the initialization is successful. Upon successful creation of the context, a SetupContextResponse event will be sent to the newly created context.

action deInit(string marketId, context refContext)

Used to unregister a context. Should be called only after init. refContext should be the Main Context.

Example usage:

context mainContext;

action onload() {
mainContext := context.current();

//create a new context
context c := context("dummy", false);
spawn setup to c;
}

action setup(){

//register this context
(new com.apama.fix.MultiContextHelper).init(marketId, mainContext);

//send orders
}

You can set up the MultiContext behaviour by either sending the SetupContext event or by using the helper utility. The helper utility also enables queuing of orders, that is you do not have to wait for a SetupContextResponse. It can send orders as soon as it calls the init.

As part of the multi-context implementation, the order manager design is moved to use the modular interfaces and callbacks so that the multi-context implementation for the support monitors can be easily extended.

Advantages:

Easily provide multi-context support for the venue specific monitors.

Performance improvement by replacing “route event” (if applicable) with callbacks.

User can provide own implementation by overriding the interface actions.

Performance improvements due to replacement of nested listener by global listeners.

Can be easily plugged to other module (multi context, support monitor ).