On Wed, Jul 1, 2009 at 10:09 AM, Hiranya Jayathilaka <[email protected]>wrote:
> Hi Folks, > > On Tue, Jun 30, 2009 at 11:25 PM, indika kumara <[email protected]>wrote: > >> Hi Marc >> >> I really don’t know about FIX or how it works. I just went through the >> code for few minutes. I can only give you some suggestions ...hope >> will work. >> >> First you have to tell Fix Incoming Message Hander to avoid dropping >> extra responses. Seems, by default it does it - i.e doesn’t drop extra >> response messages but try to handle as a request. BTW, it can be done >> adding the following parameter to the proxy service with value equal >> to false. >> >> transport.fix.DropExtraResponses > > > The default behavior is to NOT drop extra response messages. Such messages > will be handled as requests to the ESB. So you don't really have to set the > above parameter to false or anything. > > >> >> >> Now, extra responses will comes as requests …so those will flow though >> proxy service in sequence … Therefore you need a filter mediator in >> the in sequence. >> I am attaching a modified sample of 258 >> >> <definitions xmlns="http://ws.apache.org/ns/synapse";> >> <proxy name="FIXProxy"> >> >> <parameter name="transport.fix.InitiatorConfigURL"> >> file:/home/synapse_user/fix-config/synapse-sender.cfg >> </parameter> >> <parameter >> name="transport.fix.InitiatorMessageStore">file</parameter> >> <parameter >> name="transport.fix.SendAllToInSequence">false</parameter> >> <parameter >> name="transport.fix.DropExtraResponses">false</parameter> >> >> <target> >> <inSequence> >> <filter xpath="Some expression to differentiate >> request from response "> > > As for constructing the filter XPath you could test the value of the SenderCompID field of the message. I don't think messages coming to the ESB over HTTP has this field. But messages coming over FIX will always have it. Thanks, Hiranya > >> <!--Considering filter evaluates true for extra >> responses--> >> <then> >> <log level="full"/> >> <property action="set" name="OUT_ONLY" >> value="true"/> >> <send> >> <endpoint> >> <address uri="http://some endpoint"/> >> </endpoint> >> </send> >> <drop/> >> </then> >> <else> >> <property name="transport.fix.ServiceName" >> value="FIXProxy" >> scope="axis2-client"/> >> <log level="full"/> >> <send> >> <endpoint> >> <address >> >> >> uri="fix://localhost:19876?BeginString=FIX.4.0&SenderCompID=SYNAPSE&TargetCompID=EXEC"/> >> </endpoint> >> </send> >> </else> >> </filter> >> </inSequence> >> <outSequence> >> <log level="full"/> >> <send/> >> </outSequence> >> </target> >> </proxy> >> </definitions> > > > +1 to the configuration. This should do the trick at least in theory. > Please try this out and let us know how it worked. I'm really eager to know > the results :) > > Thanks, > Hiranya > > >> >> >> Note : I have checked the code in synapse trunk (Synapse SNAPSHOT)and >> I haven’t run FIX samples. >> >> Thanks >> Indika >> >> >> On Tue, Jun 30, 2009 at 8:45 AM, Marc Hodgins<[email protected]> >> wrote: >> > Hello there, >> > >> > I have a proxy endpoint setup with Synapse nearly identically to Sample >> 258 >> > - switching from HTTP to FIX. It works as expected when I request, via >> > HTTP, a FIX 4.2 Market Data Request (MsgType = W) with >> > SubscriptionRequestType = 0 -- meaning, that I want to receive a single >> > snapshot of a rate. Synapse proxies my HTTP request to my provider's >> FIX >> > server and then returns a MsgType = V as expected and then disconnects >> the >> > HTTP client. >> > >> > However, the provider I am working with has recently introduced a second >> > method whereby I can "subscribe" to a rate feed in that initial request >> by >> > setting SubscriptionRequestType = 1 instead of 0. The request and >> response >> > is identical to the previous request, except for the value of >> > SubscriptionRequestType. The initial HTTP request is proxied to the FIX >> > server and a snapshot of a rate is returned via HTTP (MsgType = V). >> > >> > However, by "subscribing" to the feed, the FIX server that Synapse is >> > maintaining the session to then begins to send Incremental Refresh >> (MsgType >> > = X) messages every time there is a rate change. Since Synapse >> disconnected >> > the HTTP client after sending back the initial snapshot, I think that >> > Synapse (under the same configuration as Sample 258) will simply discard >> any >> > subsequent "Update" messages (MsgType = X) from the FIX server since it >> has >> > nowhere to route them to. >> > >> > So, my question is, is there any way to configure Synapse to route these >> > subsequent messages to another HTTP endpoint? >> > >> > Obviously, Synapse is acting as a FIX initiator in this scenario and not >> an >> > acceptor - so, the "Update" messages are coming through on the same >> session >> > that was initiated earlier by my initial HTTP request for a Market Data >> > Request. So, I'm not clear on how to provide configuration instructions >> to >> > Synapse for how to route these messages that it otherwise does not know >> how >> > to route under Sample 258. >> > >> > Any suggestions would be appreciated. >> > >> > Marc >> > >> > > > > -- > Hiranya Jayathilaka > Software Engineer; > WSO2 Inc.; http://wso2.org > E-mail: [email protected]; Mobile: +94 77 633 3491 > Blog: http://techfeast-hiranya.blogspot.com > -- Hiranya Jayathilaka Software Engineer; WSO2 Inc.; http://wso2.org E-mail: [email protected]; Mobile: +94 77 633 3491 Blog: http://techfeast-hiranya.blogspot.com
