You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@synapse.apache.org by indika kumara <in...@gmail.com> on 2009/06/30 19:55:32 UTC
Re: How to configure an endpoint for incoming FIX app-level messages
when Synapse is acting as a FIX initiator?
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
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 ">
<!--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>
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<mj...@hodginsmedia.com> 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
>
Re: How to configure an endpoint for incoming FIX app-level messages
when Synapse is acting as a FIX initiator?
Posted by Hiranya Jayathilaka <hi...@gmail.com>.
On Wed, Jul 1, 2009 at 10:09 AM, Hiranya Jayathilaka
<hi...@gmail.com>wrote:
> Hi Folks,
>
> On Tue, Jun 30, 2009 at 11:25 PM, indika kumara <in...@gmail.com>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<mj...@hodginsmedia.com>
>> 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: hiranya@wso2.com; Mobile: +94 77 633 3491
> Blog: http://techfeast-hiranya.blogspot.com
>
--
Hiranya Jayathilaka
Software Engineer;
WSO2 Inc.; http://wso2.org
E-mail: hiranya@wso2.com; Mobile: +94 77 633 3491
Blog: http://techfeast-hiranya.blogspot.com
Re: How to configure an endpoint for incoming FIX app-level messages
when Synapse is acting as a FIX initiator?
Posted by Hiranya Jayathilaka <hi...@gmail.com>.
Hi Folks,
On Tue, Jun 30, 2009 at 11:25 PM, indika kumara <in...@gmail.com>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 ">
> <!--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<mj...@hodginsmedia.com> 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: hiranya@wso2.com; Mobile: +94 77 633 3491
Blog: http://techfeast-hiranya.blogspot.com