channel-adaptor with ISORequestListener?

[Jaime Vizán González]

Hi, I wonder if it is possible to use ISORequestListener with channel-adaptor in order to pull messages off.
I can't use QMUX because the key never match in request and response ISOMsg.

Thanks in advance

[Mark Salter]

Jaime Viz�n Gonz�lez wrote:
> I wonder if it is possible to use ISORequestListener with
> channel-adaptor in order to pull messages off. I can't use QMUX
> because the key never match in request and response ISOMsg.

If the message do not have any field keys that tie a response to a
request, you cannot use a mux and thus will have to do you own matching,
taking message straight from the channel is fine.

How will your processing work though, don't you need to match a response
to a request?
Are you sure there are no field that can be used for matching
response/request pairs?

--
Mark

[Jaime Vizán González]

Thanks for your quick answer.

 

El 04/12/2009, a las 10:41, Mark Salter escribió:

Jaime Vizán González wrote:

I wonder if it is possible to use ISORequestListener with

channel-adaptor in order to pull messages off. I can't use QMUX

because the key never match in request and response ISOMsg.

If the message do not have any field keys that tie a response to a
request, you cannot use a mux and thus will have to do you own matching,
taking message straight from the channel is fine.

How will your processing work though, don't you need to match a response
to a request?

I use the fields contains in the header of request and response message.

Are you sure there are no field that can be used for matching
response/request pairs?

The problem is the fields in message are not sufficients to match a response to a request. If I will be able to add information contains in the header of message to the key I will get it. But, If I am not wrong, it is not support.

For that reason I need use space.out(my_own_key, request) and space.in(my_own_key)

--
Mark

--
You received this message because you are subscribed to the  "jPOS Users" group.
Please see http://jpos.org/wiki/JPOS_Mailing_List_Readme_first
To post to this group, send email to jpos-...@googlegroups.com
To unsubscribe, send email to jpos-users+...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/jpos-users

[Mark Salter]

Jaime Viz�n Gonz�lez wrote:

>> How will your processing work though, don't you need to match a
>> response to a request?
> I use the fields contains in the header of request and response
> message.

I see, the ability to match on header fields would be a useful function
for a mux to have wouldn't it.

>> Are you sure there are no field that can be used for matching
>> response/request pairs?
>
> The problem is the fields in message are not sufficients to match a
> response to a request. If I will be able to add information contains
> in the header of message to the key I will get it. But, If I am not
> wrong, it is not support.

So you need a mux that looks to the header content for matching?
Perhaps you could extend mux to include the code to match on header
content, so you can continue using a mux?


--
Mark

[Victor Salaman]

Hi:

All you need to do is to override QMUX.getKey(ISOMsg m) so that you call super.getKey(m) [which returns a string] and add whatever uniqueness you need from your header (obtained from m.getHeader())

On Fri, Dec 4, 2009 at 6:44 AM, Mark Salter <marks...@talktalk.net> wrote:

--
Mark

[Jaime Vizán González]

El 04/12/2009, a las 11:44, Mark Salter escribió:

> Jaime Vizán González wrote:
>
>>> How will your processing work though, don't you need to match a
>>> response to a request?
>> I use the fields contains in the header of request and response
>> message.
> I see, the ability to match on header fields would be a useful function
> for a mux to have wouldn't it.
>
>>> Are you sure there are no field that can be used for matching
>>> response/request pairs?
>>
>> The problem is the fields in message are not sufficients to match a
>> response to a request. If I will be able to add information contains
>> in the header of message to the key I will get it. But, If I am not
>> wrong, it is not support.
> So you need a mux that looks to the header content for matching?

Yes, it is.

> Perhaps you could extend mux to include the code to match on header
> content, so you can continue using a mux?

I promise to study this solution, but I will take a long time to do this. isn't there other solution?

[Mark Salter]

Jaime Viz�n Gonz�lez wrote:

>> So you need a mux that looks to the header content for matching?
> Yes, it is.
>> Perhaps you could extend mux to include the code to match on header
>> content, so you can continue using a mux?
> I promise to study this solution, but I will take a long time to do this. isn't there other solution?

You can go without a mux - if you want to.

But, as Victor kindly indicates, you need only to extend QMUX.java and
override the getKey(ISOMsg) method to combine the data from the header
with the super.getKey(ISOMsg) result to form the key that the mux will
match using.

I'm poor at estimating others effort, but I would think this should take
you no more than 5 minutes, as long as you know the header data you need
to match with, and you have the source to hand?


--
Mark