« Installing and Configuring the FIX Adapter for BizTalk | Main | FIX for BizTalk (The basics) »

RapidAddition’s ShortCut Architecture and Overview

This is part of a series on FIX-enabling BizTalk server.

  1. FIX for BizTalk (The basics)
  2. ShortCut Architecture and Overview
  3. Installing and Configuring ShortCut
  4. Basic Routing Application using ShortCut
  5. Mapping FIX Messages
  6. More complicated scenarios and patterns using a FIX-enabled BizTalk


First I want to give an overview of the ShortCut FIX Adapter, the components that get installed and give a bit more detail on what’s happening.

The diagram below gives an overview of the ShortCut adapter.

Shortcut Overview

BizTalk only ever sees the FIXML version of the messages. The conversion to and from FIX takes place in the pipelines that come with ShortCut.

The receive location not only receives FIX messages but it also sends them out. The send port just persists the converted messages into the RapidAddition database and the engine reads them and sends it over the wire. FIX is always two way communication, even if there is only one party sending application messages. Most if not all admin messages that make up the session layer are acknowledged and there are heartbeats back and forth.

A BizTalk send port only activates when a message is picked published for it. It wouldn’t be possible to have the send port be responsible for the outbound admin messages without BizTalk getting involved. Receive Ports on the other hand are always executing or polling. This then becomes the logical place to manage the session layer so it must also send out the application messages as they go over the same tcp/ip connection. Architecting the adapter this way enables the FIX engine to deal with all the FIX session layer and leaves BizTalk to only worry about the application messages.

From an Orchestration or send ports perspective it’s business as usual. They can route and send messages the same as using any other adapter. Due to some requirements of the FIX protocol the adapter has to be architected this way to save the BizTalk developer having to deal with the session layer, which is a good thing. A normal FIX session might have 6 or so different admin messages zipping back and forth, if you’re only interested in sending Orders then that’s all your application has to worry about.

Something to keep in mind though is that you’ll have to make sure the send and receive ports are running in the same host. The diagram above is actually a incorrect, but it keeps it simple for the initial explanation.

Another important FIX concept to know is that one of the parties is designated as the initiator of the session. That simply means one party always initiates the connection based on a predetermined schedule and the other is only ever listening. You configure this in the receive location which will be covered in another post.



As you’ve probably figured out ShortCut needs it own database. This is installed for you through a wizard which we’ll cover later. Most of the time this will be put on the SQL server that’s hosting the BizTalk databases.  If your processing a large number of messages then it might be worth putting this on a separate server. You don’t want BizTalk and ShortCut to fight for resources. Keep in mind that I’ve managed systems that process over 800,000 messages a day and it wasn’t an issue so much as an area of potential improvement if the budget was available.

For DR purposes I would consider adding the RapidAddition database to the BizTalk log shipping jobs. During a failover you’ll want the transactional state of this database to go with the whole BizTalk system. When FIX engines reconnect during the day they resync themselves based on the last processed sequence number which is stored in the database. Reconnecting from the DR site with a sequence number of 1 will cause all of the days messages to be resent which could be a nightmare.


On the actual adapter side it’s all just a bunch of assemblies nothing all that different from what you would expect. Some are BizTalk assemblies (schemas, promoted property schemas) that you’ll reference in your projects and the rest are standard .NET dll’s.

They also give you a handy FIX test harness for testing out your application without connecting to counterparties. It can do things like auto fill orders, reject all messages and even replay FIX logs in case you have some production logs you want to test with.

Reader Comments

There are no comments for this journal entry. To create a new comment, use the form below.

PostPost a New Comment

Enter your information below to add a new comment.

My response is on my own website »
Author Email (optional):
Author URL (optional):
Some HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>