Designing a FIX based trade
capture feed
Design av loggningsapplikation för finansiell transaktion som använder FIX-protokollet
Sophia Ångström
Examensarbete inom information- och
programvarusystem, grundnivå
Kandidat
Degree Project in Information and Software System
Stockholm, Sweden 2012
Kurs II121X, 15hp
Kungliga Tekniska Högskolan
Kandidatexamensarbete
"Designing a FIX based trade capture feed"
Datum 2012-08-22 Författare Sophia Ångström, sopang@kth.se 900620-4888 Handledare
Robert Ångström, Erik Penser Bankaktiebolag Examinator
Sammanfattning
Varje dag omsätts aktier för ca 10 miljarder SEK på Stockholmsbör-sen. Detta sker via miljontals elektroniska meddelanden som processas på microsekund basis av olika aktörer. För att hantera och lagra denna infor-mation krävs komplexa system samt en standard för meddelandetrafiken. Hos bankerna finns det normalt sätt flera olika system som används vid orderläggning mot börsen. Varje system känner till sina egna ordrar och avslut. I vissa situationer finns det dock behov av att skapa ett system som känner till samtliga avslut och ordrar som banken gjort. Använd-ningsområdet är till exempel att mata ett backoffice-system på en bank med avslut men även möjliggöra övervakning samt avstämningsrapporter. Detta görs normalt sätt med hjälp av en så kallad Drop copy session som konsoliderar avslut från flera orderläggningssystem.
Projektet gick ut på att utveckla ett program som klarar av att koppla upp sig mot ett börssystem (tex NASDAQOMX alternativt Burgundy) via FIX-protokollet som är en industristandard för elektronisk handel och sedan prenumerera på avslut. Dessa avslut skall sedan sparas ned i ett lämpligt format (flatfile eller databas). Sessionen som skapas mot börsen skall vara av typ Drop copy.
En java baserad lösning som skriver ner ordrar och avslut i en SQL server databas utvecklades framgångsrikt och produktionsattes hos upp-dragsgivaren 2012-06-08
Abstract
Every day shares for about 10 billion SEK is traded on the Stock-holm Stock Exchange. This is accomplished through millions of electronic messages that are processed on micro seconds basis by different partici-pants. Complex systems and a message standard are required in order to handle and store this information. Banks normally use several different systems when interacting with the exchange. Each system is aware of its own orders and trades. However, in some situations there is a need to cre-ate a system which has an aggregcre-ated view of all trades and orders that the bank have created. Examples are Back office system as well as risk monitoring and different reconciliation reports. This is normally done by means of a so-called Dsrop copy sessions which consolidates trades and orders done via several different sessions into one.
The main task of the project was to develop a program that is able to connect to the exchange (i.e NASDAQOMX or Burgundy) via the FIX protocol which is an industry standard for electronic trading and then subscribe/process all messages regarding orders and trades. This informa-tion should then be stored into a suitable format (flat file or database). The session which is created towards the exchange should be of type Drop copy.
A java based solution which stores orders and trades into a SQL Server was successfully developed and installed in production at the customer 2012-06-08.
Nyckelord FIX-protokollet, Drop copy.
Förkortningar
FIX Financial Information eXchange
SWIFT Society for Worldwide Interbank Financial Telecommunication QucikFIX java - Free, Open Source Java FIX engine
INET Nordic FIX - Nasdaq OMX handelsplats för de nordiska marknaderna UAT - User Acceptance Testing Environment
Innehåll
1 Inledning 5 1.1 Bakgrund . . . 5 1.2 Syfte . . . 5 1.3 Projektmål . . . 6 1.4 Intressenter . . . 6 1.5 Avgränsningar . . . 6 2 Förstudie 7 2.1 FIX-protokollet . . . 7 3 Metod 8 3.1 Arbetsmetod . . . 8 3.2 QuickFIX Java . . . 9 3.3 Utvecklingsmiljö . . . 10 4 Systemspecifikation 10 4.1 Kravspecifikation . . . 10 4.2 Databasspecifikation . . . 11 5 Resultat 13 5.1 Systemarkitektur . . . 13 5.2 Implementation . . . 155.2.1 Use case 1: Ny order . . . 15
5.2.2 Use case 2: Nytt avslut . . . 19
5.3 Installationsbeskrivning . . . 20 5.4 Dokumentplan . . . 21 6 Diskussion 21 7 FAQ 23 A FIX specifikation 24 B Referenser 25
1
Inledning
Denna del beskriver bakgrunden och syftet till detta projekt.
1.1
Bakgrund
Hos bankerna finns det normalt sett flera olika system som används som order-läggning mot börsen där varje system känner till sina egna ordrar och avslut. I vissa situationer finns det dock behov av att skapa ett system som känner till samtliga ordrar och avslut som banken gjort. Användningsområdet är till exem-pel att mata ett backoffice-system på en bank med avslut men även möjliggöra övervakning samt avstämningsrapporter. Detta görs normalt sett med hjälp av en så kallad Drop copy session som konsoliderar avslut från flera system.
Figur 1: Exempel på relationen mellan tradingsystem, marknadsplats och Drop copy
1.2
Syfte
Projektet går ut på att utveckla ett program som klarar av att koppla upp sig mot en marknadsplats (tex NASDAQOMX alternativt Burgundy) via FIX-protokollet som är en industristandard för elektronisk handel och sedan pre-numerera på avslut. Dessa avslut skall sedan sparas ned i ett lämpligt format (flatfile eller databas). Sessionen som skapas mot börsen skall vara av typ Drop copy.
Figur 2: Exempel på hur FIX relationen mellan trading system, marknadsplats och Drop copy
1.3
Projektmål
Målet med projektet är att skapa en FIX baserad ’trade capture feed’ baserat på QuickFIX java engine som klarar av att initiera och logga på en FIX-session av version 4.2 mot given IP adress och port. Programmet skall processa och parsa FIX-meddelanden av typ ’executionreport’ och skriva ner fält listade i appen-dix A till en textfil avgränsad med semikolon alternativt spara informationen i en databas. Programmet skall även skicka så kallade heartbeats på sessionen enligt FIX standard samt vid konfiguerbar tidpunkt logga av samt avsluta FIX-sessionen enligt FIX standard.
1.4
Intressenter
Drop Copy används av företag inom den finansiella sektorn för övervakning, sam-manställning av rapporter och backoffice-system(clearing). Exempel på företag som använder sig av Drop Copys är till exempel NASDAQOMX (börsen samt leverantör av backoffice-system) samt i princip alla banker som är uppkopplade mot någon typ av marknadsplats.
1.5
Avgränsningar
Enbart de fält som specificerats i Appendix A skall lagras i fil/databas. Applika-tionen skall enbart ha stöd för FIX version 4.2 (standardversion för aktiehandel). Databas konfiguration är idag hårdkodad i javakoden. QuickFIX Java config är inkluderad i jar-fil.
2
Förstudie
Denna del beskriver kort FIX-protokollets uppbyggnad.
2.1
FIX-protokollet
Det var givet av den funktionella specifikationen att FIX-protokollet behövde användas. Nedan är en kort sammanfattning av FIX-protokollets uppbyggnad.
FIX-protokollet är ett elektroniskt kommunikationsprotokoll för real-tids utbyte av information relaterad till transaktioner och stöds idag av de flesta aktörer in-om den finansiella marknaden. FIX-protokollet kin-om till år 1992 med dåvarande syftet att möjliggöra elektronisk kommunikation av aktiehandeln mellan Fide-lity Investment och Salomon Brothers. Numera är FIX internationell standard när det gäller utbyte av information relaterad till värdepappershandel. [1] Man kan säga att medan SWIFT är en standard för back office system så är FIX standard för front office-meddelanden (det vill säga orderläggning). [2]
Följande är ett exempel på hur det kan se ut med användning av FIX-protokollet: Ett tradingsystem A lägger en köporder på 100st ABB aktier för 140kr. Detta kommer då representeras som FIX meddelandet nedan som skickas till börsen av tradingsystemet.
8=FIX.4.2| 9=247| 35=D| 49=tradingsystema| 56=börsen| 34=1477| 52=20120327-17:33:17| 116=trader1| 1=konto1| 11=Clientid1| 15=SEK| 21=1| 22=4| 38=100| 40=2| 44=140| 48=CH0012221716| 54=1| 55=ABB| 58=test1| 59=0| 60=20120327-17:33:16| 100=ST| 107=ABB Ltd| 109=Bunt21| 10=110|
FIX tag nummer FIX fältens innebörd
35 Message type. Specificerar typ av meddelande. 35=D innebär order. 55 Symbol. Specificerar aktien ordern gäller för i detta exempel ABB 44 Price. Specificerar priset.
38 OrderQty. Specificerar antalet aktier
54 Side. Specificerar i detta exempel att det är en köporder (2=sälj). 48 SecurityID. ISIN kod för en aktie. Unik identifierare.
Bodyn av meddelandet är helt beroende av meddelandetypen (FIX tag #35) definierad i headern. Headern i detta exempel sträcker sig från FIX tag #8 till och med #116. Bodyn sträcker sig från #1 till och med #109 och längst bak i meddelandet. Slutligen på tag #10 är trailern. När det blir ett avslut kommer börsen skicka ett FIX-meddelande av typen ‘executionreport‘ 35=8.
Figur 3: Exempel på FIX-meddelanden mellan en klient och börsen
När tradingsystem B lägger en säljorder på 300st Alfa aktier för 135.3kr kommer det representeras av FIX-meddelandet nedan.
8=FIX.4.2| 9=256| 35=D| 49=tradingsystemb| 56=börsen| 34=1518 | 52=20120327-17:53:04| 116=user2| 1=konto2| 11=clientorder2 | 15=SEK| 21=1| 22=4| 38=300| 40=2| 44=135.3| 48=SE0000695876 | 54= 2| 55=ALFA| 58=test2| 59=0| 60=20120327-17:53:04
| 100=ST| 107=Alfa Laval AB| 109=Bunt21| 10=230|
Samma sak som för tradingssystem A så kommer tradingsystemet B få ett FIX-meddelande av typ execution report (35=8) när ett avslut har skett. [3]
3
Metod
3.1
Arbetsmetod
Under projektets gång har den klassiska vattenfallsmetoden tillsammans med arbetssättet Agila metoder tillämpas. Detta innebär att projektet började med förstudie där projektet bröts ner i mindre delar där deadlines sattes för varje vec-ka. Därefter skrevs en projektdefinition där uppgiften definierades och klara mål sattes upp. Efter litteraturstudien började sedan impelementationen av mjuk-varan som gjordes iterativt. Själva utvecklingen bröts ner i delmål som sattes upp och prioriterades tillsammans med kunden vilket innebär att arbetssättet har följt Agila metoder. Det som först prioriterades tillsammans med kund var att alla avslut skulle skrivas till fil. Efter den första sprinten då kunden fick alla
avslut i fil var nästa prioritet att få ner all data i en databas istället. Detta prioriterades då det är lättare för kunden att analysera data i det formatet. Ytterligare ett krav som önskades från kund var även att ordrar skulle sparas ned och inte bara avslut. När stöd för databashantering implementerats var ap-plikationen klar och därefter påbörjades rapportskrivningen.
Figur 4: Work breakdown structure
Figur 4 beskriver arbetsgången där implementationen gjordes iterativt medan projektet som sin helhet följde vattenfallsmetoden.
3.2
QuickFIX Java
QuickFIX Java är ett meddelandehanteringssystem för FIX-protokollet. Quick-FIX Java består av 100 % öppen källkod, vilken levereras i form av jar-filer. För att importera QuickFIX paketet i java skriver man exempelvis import quickfix.*;.[4]
QuickFIX Java exempel på funktioner: 100 % öppen källkod
Stöd för FIX version 4.0 - 4,4, 5.0/FIXT1.1. Lätt att applicera på existerande java applikationer Kommunikations transporter för TCP sockets Support finns tillgänglig från flera källor
3.3
Utvecklingsmiljö
Programmet utvecklades i java i utvecklingsmiljön Eclipse. Tester av systemet utfördes i en UAT miljö innan systemet sedan installerades i den riktiga produk-tionsmiljön. Inga förändringar sker direkt i produktionsmiljön utan att det först testas i UAT miljön. Båda miljöerna underhålls med syftet att kunna möjliggöra tester av framtida förändringar.
4
Systemspecifikation
I denna del beskrivs hur systemet ska uppträda för de inblandade parterna, i detta fall användare och utvecklare. Detta för att få en gemensam bild om hur systemet ska se ut.
4.1
Kravspecifikation
De fält som ska skrivas ner i databasen är listade i Appendix A. Majoriteten av dessa fält är standard i FIX version 4.2 men det finns även ett antal så kallade Custom Tags som enbart finns på marknadsplatsen INET Nordic FIX.
Figur 12 nedan illustrerar ett exempel på en kommunikation mellan en tra-dingklient och börsen. Varje ordermeddelande och avslutsmeddelande kommer skrivas ned i databasen av EPBDrop. Om OrdStatus=1 eller OrdStatus=2 kan man säkerställa att det är en trade. Meddelandena skall då sparas ner i tradeta-bellen i databasen. I annat fall kan vi säkerställa att det är en order det handlar om och då sparas meddelandet ner i databastabellen orders.
Figur 5: Figuren illustrerar logiken som skall implementeras enligt kravspecifi-kationen
4.2
Databasspecifikation
Databasen består av två tabeller. En tabell orders där alla ordrar sparas ned. Den andra tabellen trades lagrar alla avslut. ER-diagrammet i figur 6 illustrerar databasens design. Execution reports (35=8) med orderstatus partially filled (39=1) eller orderstatus filled (39=2) skrivs ned i tabell trades. Alla andra meddelanden skrivs ned i tabell orders. Se exempel på kod i sektion 5.2.1.
5
Resultat
5.1
Systemarkitektur
Systemet följer strukturen enligt Figur 7. EPBDrop prenumererar på avslut från NASDAQOMX börsen enligt FIX protokollet som sedan lagras i en databas. Programmet importerar QuickFIX Java i form av jarfiler vilket finns att laddas ned på QucikFIX officiella hemsida.[4]
Figur 7: Övergripande systembeskrivning
Exempelkoden Banzai som levereras i QuickFIX java användes som baskod och modifierades grundligt för att lösa uppgiften. Följande UML diagram be-skriver banzaiApplikationens uppbyggnad.
Figur 9: UML diagram
EPBDrop applikationen körs på en Windows 2008 server. Datasen bastår av två tabeller (orders samt trades). Databasen är av typ Microsoft SQL server 2008.
5.2
Implementation
I klassen banzaiApplication görs bland annat följande importer: import quickfix.*;
import java.sql.*; import java.io.*;
Importen av QucikFIX görs för att få tillgång till hela QuickFIX biblioteket för att kunna hantera FIX-meddelanden. IO importen behövdes för till exempel möjligheten att kunna skriva meddelanden till fil. SQL importen gjordes för att kunna interagera via SQL mot databasen. Majoriteten av kod samt logik implementerades i metoden executionReport.
5.2.1 Use case 1: Ny order
Detta är en illustration på hur systemet fungerar när en order läggs. Användaren lägger en order via Trading system A .
Figur 10: Exempel på orderläggning
När detta sker så får class BanzaiApplication ett callback i metod fromApp där en input parameter är FIX-meddelandet. Vi initierar sedan ett MessagePro-cessor objekt som vi sedan vi sedan kör metoden run på. Utdrag från Banzai-Application.java
public void fromApp(quickfix.Message message, SessionID sessionID) throws FieldNotFound,
IncorrectDataFormat, IncorrectTagValue, UnsupportedMessageType { //denna metod kallas när vi får ett meddelande
System.out.println("fromapp"); try {
MessageProcessor myMessageProcessor= new MessageProcessor(message, sessionID); myMessageProcessor.run();
} catch (Exception e) { }
}
Metoden run (class MessageProcessor) kommer sedan om meddelandet är av typ executionreport (35=8) att kalla på metoden executionReport();
public void run() { try {
MsgType msgType = new MsgType();
// möjlighet att kolla status på applikationen if (isAvailable) {
// om execution report
if (message.getHeader().getField(msgType).valueEquals("8")) { executionReport(message, sessionID);
} else {
sendBusinessReject(message,
BusinessRejectReason.APPLICATION_NOT_AVAILABLE, "Application not available");
}
} catch (Exception e) { e.printStackTrace(); }
}
I metoden executionReport finns sedan logiken för att parsa de FIX-fält vi är intresserade av att spara ner samt att skriva ner de till databasen.
private void executionReport(Message message, SessionID sessionID) throws FieldNotFound { System.out.println("executionreport"); String senderCompIDStr = message.getHeader().isSetField(SenderCompID.FIELD) ? message.getHeader().getString(SenderCompID.FIELD) : null; String targetCompIDStr = message.getHeader().isSetField(TargetCompID.FIELD) ? message.getHeader().getString(TargetCompID.FIELD) : null; ... ...
Det är även i denna metod som vi specificerar huruvida meddelandet är typ trade eller order vilket görs via koden nedan. Som koden illustrerar så påverkar detta vilken tabell vi sparar ner meddelandet i.
if ( ordStatusStr.equals("1") || ordStatusStr.equals("2") ){
sql ="INSERT INTO trades";
}
else {
sql ="INSERT INTO orders";
}
I det här fallet så är meddelandet en order ( ordStatus != 1 ordStatus != 2 ) vilket resulterar att vi skriver ner meddelandet i tabell orders.
Figur 11: Ordertabell i databasen
Output från banzai.log
fromadmin
<20120810-14:09:22, FIX.4.2:EPB->INORD, incoming> (8=FIX.
4.29=028935=834=99349=INORD56=EPB52=20120810-14:09:22.24950=S128= EPB129=AOR0016=0.011=20120810-314=015=SEK17=EPB0X1-220=037=4729138= 10039=040=244=115.0000528=A22=448=CH001222171654=155=396659=060= 20120810-14:09:22.249150=0151=1005815=182109=EPB6209=499861=4976=BOOK10=206) fromapp executionreport toadmin
<20120810-14:09:23, FIX.4.2:EPB->INORD, outgoing> (8=FIX. 4.29=5335=034=98749=EPB52=20120810-14:09:23.57456=INORD10=157) msgINORD;EPB;null;EPB;993;S;null;AOR001;20120810-14:09:22.249;47291; 20120810-3;null;EPB;EPB0X1-2;0;null;0;0;null;3966;CH0012221716;4;null;
null;1;100;2;115.0000;SEK0;null;null;null100;0;0.0;null20120810-14:09:22.249; null;null;null;null;null;A;null;null;182;49;null;49;null;null;null;null
INSERT INTO orders
(senderCompID,targetCompID,onBehalfOfCompID,deliverToCompID,msgSeqNum, senderSubID,onBehalfOfSubID,deliverToSubID,sendingTime,orderID,clOrdID, origClOrdID,clientID,execID,execTransType,execRefID,execType,ordStatus, account,symbol,securityID,iDSource,securityType,securityDesc,side, orderQty,ordType,price,currency,timeInForce,lastShares,lastPx,lastMkt, leavesQty,cumQty,avgPx,tradeDate,transactTime,handlInst,noContraBroker, ContraBroker,ClearingFirm,ClearingFirmAccount,OrderCapacity,OrderRestrictions, tradeId,subMktId,clRefId,displayInt,brSeqNbr,liquidityFlag,secondaryExecID, secondaryOrderIDd) values(’INORD’,’EPB’,’null’,’EPB’,’993’,’S’,’null’,’AOR001’,’20120810-14:09:22.249’, ’47291’,’20120810-3’,’null’,’EPB’,’EPB0X1-2’,’0’,’null’,’0’,’0’,’null’,’3966’, ’CH0012221716’,’4’,’null’,’null’,’1’,100,’2’,115.0000,’SEK’,’0’,null,null,’null’, 100,0,0.0,’null’,’20120810-14:09:22.249’,’null’,’null’,’null’,’null’,’null’,’A’, ’null’,’null’,’182’,’49’,’null’,’49’,’null’,’null’,’null’);
Success, row inserted
Observera att figur 10 & 11 och outputen från banzai.log inte har samma värden då det är två olika ordrar.
5.2.2 Use case 2: Nytt avslut
Följande är en illustration på hur systemet fungerar när ett avslut sker. Logiken kommer att vara på exakt samma sätt i fallet med ordern ovan tills vi kommer in i metod ExecutionReport och nedan kod. I fallet med ett avslut kommer ordStatus vara satt till 1 eller 2 vilket resulterar i att vi skriver ner avslutet i tabell trades.
if ( ordStatusStr.equals("1") || ordStatusStr.equals("2") ){
sql ="INSERT INTO trades";
}
else {
sql ="INSERT INTO orders";
}
Figur 12: Tradingtabell i databasen
output från banzai.log <20120810-14:13:39, FIX.4.2:EPB->INORD, incoming> (8=FIX.4.29=036035=834=100549=INORD56=EPB52=20120810-14:13:39.62150=S128= EPB129=AOR0016=121.700011=20120810-714=10015=SEK17=B2453520=031=121.700032= 10037=4837138=10039=240=244=122.0000528=A22=448=CH001222171654=155=396659=060= 20120810-14:13:39.62175=20120810150=2151=05815=182109=EPB382=1375=MCF6209= 499861=499882=R76=BOOK1003=00002453510=188)msgINORD;EPB;null;EPB1003;S;null; AOR001;20120810-14:13:39.617;48003;20120810-6;20120810-5;EPB;EPB0X1-5;0;null; 4;4;null;3966;CH0012221716;4;null;null;1;100;2;119.0000;SEK;0;0;0.0;null; 0;0;0.0;null;20120810-14:13:39.617;null;null;null;null;null;A;null;null;182;49; null;49;null;null;null;null
INSERT INTO trades (senderCompID,targetCompID,onBehalfOfCompID,deliverToCompID, msgSeqNum,senderSubID,onBehalfOfSubID,deliverToSubID,sendingTime,orderID,clOrdID, origClOrdID,clientID,execID,execTransType,execRefID,execType,ordStatus,account,
symbol,securityID,iDSource,securityType,securityDesc,side,orderQty,ordType,price, currency,timeInForce,lastShares,lastPx,lastMkt,leavesQty,cumQty,avgPx,tradeDate, transactTime,handlInst,noContraBroker,ContraBroker,ClearingFirm,ClearingFirmAccount, OrderCapacity,OrderRestrictions,tradeId,subMktId,clRefId,displayInt,brSeqNbr, liquidityFlag,secondaryExecID,secondaryOrderIDd) values(’INORD’,’EPB’,’null’,’EPB’,’1005’,’S’,’null’,’AOR001’,’20120810-14:13:39.621’, ’48371’,’20120810-7’,’null’,’EPB’,’B24535’,’0’,’null’,’2’,’2’,’null’,’3966’, ’CH0012221716’,’4’,’null’,’null’,’1’,100,’2’,122.0000,’SEK’,’0’,100,121.7000,’null’, 0,100,121.7000,’20120810’,’20120810-14:13:39.621’,’null’,’1’,’null’,’null’,’null’,’A’, ’null’,’000024535’,’182’,’49’,’null’,’49’,’R’,’null’,’null’);
Success, row inserted
Observera att output i banzai.log inte stämmer överens med figur 12 då det är olika trades.
5.3
Installationsbeskrivning
Installationsbeskrivning:
Förutsättning: Java JRE installerad
kopiera EPBDrop.zip till C:\ och extrahera den
Filstruktur:
.\banzai #innehåller jar-fil för applikationen och configueringsfilerna .\bin #innehåller startup script
.\lib #innehåller de nödvändiga biblioteken .\log #innehåller log-filerna
Notera att databas config för närvarande sätts i
BanzaiApplication.java och IP config sätts i banzai.cfg
De följande jar-filerna måste vara i .\lib mina-core-1.1.7-sources.jar mina-core-1.1.7.jar quickfixj-all-1.5.2.jar slf4j-api-1.6.3.jar slf4j-jdk14-1.6.3.jar sqljdbc4.jar
För att starta programmet nedan från terminalen kör C:\EPBDrop\bin\epbdrop_start.bat
Följande är ett exempel på hur programmet startas: java -cp %CP% quickfix.dropcopy.banzai.uat.Banzai %1 %2 %3 %4 %5 %6 %7 %8 %9 >> ../log/banzai.log 2>&1
5.4
Dokumentplan
Hos kunden skapades en speciell wiki sida kring system EPBDrop där relevant info dokumenterades (tex konfigurations info angående produktions miljön samt info angående testmiljön).
6
Diskussion
Arbetssättet var en blandning mellan Agila metoder och vattenfallsmetoden. Enligt Gantt Schemat (Figur 13) som sattes upp i samband med projektdefi-nitionen skulle implementationen av mjukvaran göras parallellt med rapport-skrivningen. Utfallet avvek från det uppsatta Gantt Schemat. Istället följdes vattenmetoden rakt igenom för de olika milstolparna; förstudie, implementation och rapportskrivning. Den resulterade arbetsgången blev i och med detta Gantt Schema Figur 14.
Figur 14: Den resulterande arbetsgången
Vid implementationen av mjukvaran tillämpades däremot Agila metoder. Det hade varit tillräckligt att prenumerera på alla avslut och lagra det i en fil för att uppnå projektmålet. Kunden däremot tyckte att det var viktigt att få ner det i en databas för att på ett enklare sätt kunna bearbeta data. Efter första sprinten förändrades därmed kraven från kunden vilket är typiskt när man arbetar Agilt. Agilt arbetssätt handlar mycket om att man utvärderar varje sprint tillsammans med kund och därför är det lätt att det tillkommer krav eller förändringar. Detta är positivt då kunden får det system som efterfrågas. Vid vattenfallsmetoden är det lätt om inte projektmålet är väl definierat, att man som systemutvecklare drar egna slutsatser om till exempel hur databasen ska vara designad.
Agila metoder fungerar bäst för implementation av mjukvara och att blanda arbetssätten kan i vissa projekt vara fördelaktigt. Däremot i detta projekt hade det troligen varit lönsamt att arbeta mer iterativt genom hela projektet. Detta för att möta eventuella risker i ett projekt som till exempel i detta fall att implementationen av mjukvaran krävde längre tid än planerat vilket i sin tur ledde till mindre tid för rapportskrivande. Det är viktigt i projekt att fördela resurserna på rätt sätt och eftersom man aldrig i ett projekt kan förutse risker så kan det vara bra att iterativt arbeta med projektet. Detta för att se till att alla delmål blir uppnådda. I Figur 15 har vi de olika risker man kan utsättas för vid en systemutveckling. En risk är till exempel att projektet är för teknisk avancerad. Det kan även vara så att man inte har tillräckligt med funktionalitet för att lyckas med ett projekt.
Teknik
Tid
Funktion
Figur 15: Risker som kan uppstå vid systemutveckling
Ett annat exempel på risk kan vara om man inte har tillgång till viss pro-gramvara. En risk kan även vara tidsbrist vilket innebär att man kan klara uppgiften rent tekniskt men det är ont om tid. I detta projekt var en stor risk som nämnt innan tiden då det tog längre tid för kodningen än vad väntat vilket man kan se om man jämför det planerade Gantt schemat och Gantt schemt som visar på hur arbetsgången blev. (OBS: Egentligen används bara Gantt scheman för att sätta upp projekt och de används egentligen inte under projektets gång. Detta var mer för att på ett smidigt sätt visa hur det var planerat i projektde-finitionen och hur utfallet blev.)
När systemet testades i testmiljön upptäcktes en bugg i systemet. Börsen la nämligen in egna fält, deras så kallade Custom tags i Drop copyn. Detta lades sedan till i systemet enligt önskemål från kunden. Efter att programmet körts i produktionsmiljön så har vissa begränsningar upptäckts. Till exempel så ha-de ha-det varit bra om ordrar som inte accepterats av börsen (eng. ’reject’) haha-de skrivits ner i tabellen orders. Enligt nuvarande upplägg görs inte det.
En annan begränsning som upptäcktes var att konfigurationsfilen inte finns på filsystemet utan levereras i jar-filen. Detta innebär att om man vill ändra i konfigurationsfilen måste man först editera konfigurationsfilen och sedan bygga en ny jar-fil. Det hade varit smidigare om det fanns möjlighet att ändra direkt på filsystemet.
7
FAQ
Q1: Hur gör man för att återställa sekvensnummer(SeqNum)?
A1: Om man vill återställa SeqNum till 1 så stoppa applikationen och radera filen C:.seqnums. Om man vill ange en specifikt SeqNum för att börja skicka så ska man editera filen. Första siffran ska vara outbound SeqNum.
Q2: vart hamnar Dropcopy.txt filen? A2: I workspace under projektet.
A3: Exporterar jar filen från Eclipse.
A
FIX specifikation
FIX Tag Nr Namn
49 SenderCompID 56 TargetCompID 115 OnBehalfOfCompID 128 DeliverToCompID 34 MsgSeqNum 50 SenderSubID 116 OnBehalfOfSubID 129 DeliverToSubID 52 SendingTime 37 OrderID 11 ClOrdID 41 OrigClOrdID 109 ClientID 17 ExecID 20 ExecTransType 19 ExecRefID 150 ExecType 39 OrdStatus 1 Account 55 Symbol 48 SecurityID 22 IDSource 167 SecurityType 107 SecurityDesc 54 Side 38 OrderQty 40 OrdType 44 Price 15 Currency 59 TimeInForce 32 LastShares 31 LastPx 30 LastMkt 151 LeavesQty 14 CumQty 6 AvgPx 75 TradeDate 60 TransactTime 21 HandlInst
INET Nordic FIX Custom Tags Namn 382 noContraBroker 375 ContraBroker 439 ClearingFirm 440 ClearingFirmAccount 528 OrderCapacity 529 OrderRestrictions 1003 tradeId 5815 subMktId 6209 clRefId 9140 displayInt 9861 brSeqNbr 9882 liquidityFlag 527 secondaryExecID 198 secondaryOrderID
B
Referenser
Referenser
[1] Wikipedia R Financial Information eXchange. (Senast
upp-daterad maj 2012) Wikipedia, hämtad 23e maj 2012 från: http://en.wikipedia.org/wiki/FinancialInf ormationeXchange
[2] Wikipedia Society for Worldwide Interbank Financial Telecommunica-R
tion. (Senast uppdaterad maj 2012) Wikipedia, hämtad 23e maj 2012 från:
http://en.wikipedia.org/wiki/SocietyforWorldwideInterbankFinancialTelecommunication
[3] c 2012 FIX Protocol Limited FIX protocol, what is FIX?. (Senast uppdaterad 2012) FIX protocol, hämtad 24e maj 2012 från: http://fixprotocol.org/what-is-fix.shtml
[4] Copyright c quickfixj.org QuickFIX/J User Manual. (Senast uppdaterad 2012) quickfixj.org, hämtad 16e maj 2012 från: www.quickfixj.org/quickfixj/usermanual/1.5.0/usage/configuration.html
