FIX gateway logon question

, ,
1

Imported from previous forum

2

I am working on a project where we have a FIX gateway to an existing proprietary API. When a FIX connection logs in to the gateway, the gateway code then logs into the proprietary system. After the proprietary logon succeeds, we send a FIX logon back to the user and they are able to then proceed with their regular messaging.

The problem comes in because the proprietary logon can take some time (especially when all the users try to log on at once). What can happen is that a FIX user will try to logon, decide that the logon is taking too long, disconnect and try to log on again. Most of the time this just means that he is stepping on himself, since when the FIX connection drops, the proprietary system will be asked to logout the user as soon as the proprietary logon succeeds. Furthermore, the FIX gateway keeps track of the last FIX logon attempt for the user and will not allow them to log on too soon, so usually it takes these impatient guys much longer to log on than if they would just wait.

The reason for this post is to see what other ideas people have for this type of architecture, which I’d assume is somewhat common ( a FIX gateway in front of a proprietary API).

One thing we were thinking of was to send a LOGON ack on the FIX connection as soon as we get their FIX logon, and the proceed with the proprietary logon. But we would probably need to send them some type of message to let them know the backend logon succeeded (not sure what that would be, a custom message?) Anything we receive prior to us giving them the “all clear” we would reject with a BusinessMessageReject… This is a FIX 4.2 API btw.

Any ideas would be appreciated,

Thanks,
-Andy

3

I am working on a project where we have a FIX gateway to an existing proprietary API. When a FIX connection logs in to the gateway, the gateway code then logs into the proprietary system. After the proprietary logon succeeds, we send a FIX logon back to the user and they are able to then proceed with their regular messaging.

The problem comes in because the proprietary logon can take some time (especially when all the users try to log on at once). What can happen is that a FIX user will try to logon, decide that the logon is taking too long, disconnect and try to log on again. Most of the time this just means that he is stepping on himself, since when the FIX connection drops, the proprietary system will be asked to logout the user as soon as the proprietary logon succeeds. Furthermore, the FIX gateway keeps track of the last FIX logon attempt for the user and will not allow them to log on too soon, so usually it takes these impatient guys much longer to log on than if they would just wait.

The reason for this post is to see what other ideas people have for this type of architecture, which I’d assume is somewhat common ( a FIX gateway in front of a proprietary API).

One thing we were thinking of was to send a LOGON ack on the FIX connection as soon as we get their FIX logon, and the proceed with the proprietary logon. But we would probably need to send them some type of message to let them know the backend logon succeeded (not sure what that would be, a custom message?) Anything we receive prior to us giving them the “all clear” we would reject with a BusinessMessageReject… This is a FIX 4.2 API btw.

Any ideas would be appreciated,

Thanks,
-Andy

Hi Andy,

It sounds like you have the best solution already - the only other way to do this would be to maintain the session state for the logon operation in your gateway, whether or not the user disconnects after they initiate the logon, so that they can be logged in immediately if they reconnect within a certain period of time. That, coupled with a status / informational message of some sort while the logon is in progress, might make sense as well.

I would think it would make more sense to enforce the delay during the logon process, as opposed to “faking” the logon and then rejecting messages until the logon really completes, but I guess the end user would be the best judge of which method makes more sense.

Cheers,

Russ

4

Hi Andy,

You can use 35=A to immediately log on to the FIX gateway. Then you can use the User Request/Response (35=BE/BF) to log on to the API gateway.

Regards,
Xavier.

I am working on a project where we have a FIX gateway to an existing proprietary API. When a FIX connection logs in to the gateway, the gateway code then logs into the proprietary system. After the proprietary logon succeeds, we send a FIX logon back to the user and they are able to then proceed with their regular messaging.

The problem comes in because the proprietary logon can take some time (especially when all the users try to log on at once). What can happen is that a FIX user will try to logon, decide that the logon is taking too long, disconnect and try to log on again. Most of the time this just means that he is stepping on himself, since when the FIX connection drops, the proprietary system will be asked to logout the user as soon as the proprietary logon succeeds. Furthermore, the FIX gateway keeps track of the last FIX logon attempt for the user and will not allow them to log on too soon, so usually it takes these impatient guys much longer to log on than if they would just wait.

The reason for this post is to see what other ideas people have for this type of architecture, which I’d assume is somewhat common ( a FIX gateway in front of a proprietary API).

One thing we were thinking of was to send a LOGON ack on the FIX connection as soon as we get their FIX logon, and the proceed with the proprietary logon. But we would probably need to send them some type of message to let them know the backend logon succeeded (not sure what that would be, a custom message?) Anything we receive prior to us giving them the “all clear” we would reject with a BusinessMessageReject… This is a FIX 4.2 API btw.

Any ideas would be appreciated,

Thanks,
-Andy

5

That is often the best approach, especially if you want to use a single FIX session to access multiple execution venues where each of them needs an explicit logon, e.g. due to regulatory requirements. If you implicitly logon the user to the proprietary system(s) then you can use the UserNotification message (CB) with UserStatus (926) = 1 (Logged In). If you are on FIX 4.2. this may have to be done with a user-defined message (“UCB”)with a user-defined field (20926 UserStatus). That way it gets through the FIX Engine but is semantically identical to the standard message.

Hi Andy,

You can use 35=A to immediately log on to the FIX gateway. Then you can use the User Request/Response (35=BE/BF) to log on to the API gateway.

Regards,
Xavier.

I am working on a project where we have a FIX gateway to an existing proprietary API. When a FIX connection logs in to the gateway, the gateway code then logs into the proprietary system. After the proprietary logon succeeds, we send a FIX logon back to the user and they are able to then proceed with their regular messaging.

The problem comes in because the proprietary logon can take some time (especially when all the users try to log on at once). What can happen is that a FIX user will try to logon, decide that the logon is taking too long, disconnect and try to log on again. Most of the time this just means that he is stepping on himself, since when the FIX connection drops, the proprietary system will be asked to logout the user as soon as the proprietary logon succeeds. Furthermore, the FIX gateway keeps track of the last FIX logon attempt for the user and will not allow them to log on too soon, so usually it takes these impatient guys much longer to log on than if they would just wait.

The reason for this post is to see what other ideas people have for this type of architecture, which I’d assume is somewhat common ( a FIX gateway in front of a proprietary API).

One thing we were thinking of was to send a LOGON ack on the FIX connection as soon as we get their FIX logon, and the proceed with the proprietary logon. But we would probably need to send them some type of message to let them know the backend logon succeeded (not sure what that would be, a custom message?) Anything we receive prior to us giving them the “all clear” we would reject with a BusinessMessageReject… This is a FIX 4.2 API btw.

Any ideas would be appreciated,

Thanks,
-Andy