FSDMsg Usage

[JTO]

Hi Everyone,

I am stuck and need some guidance. My jPos implementation is going
exceptionally well and as such I have been asked to absorb
functionality that has never been considered.'

Basically I need to receive an async data stream (STX data FS data FS
data...ETX) which I have been able to capture (in byte form) by
customizing one of the existing jPos Channels. I then need to convert
this message into an ISOMsg, manipulate and forward on to our backend
processor using the same channel (STX-ETX) and format (FS).

I am able to do both sides of the equation (receive msg and send msg,
when I mock up my data)

serverOut.writeBytes("54490877 59948610100000014 0000043200 4.52900 0.00000 0.00000 TEST N");

and I was thinking of using the FSDISOMsg (FSDMsg) but that is where I
get lost. Since I can send /rec I am thinking that I just need to
create a custom packager and all will be well but I cant see which one
to base it off of.

The data is not packed, it is just delimited and wrapped with STX/ETX.

The other thought was to just use FSDISOMsg without customizing a
packager, but again I am lost.

Anyone help me with what I am so obviously missing

[Anthony Schexnaildre]

I would go the FSDISOMsg route. You can define STX/ETX as constant
fields and then choose the proper Channel for your application and
you should be all set. I don't see why you should even be concerned
about about any issues related to packing the message. If I missed
something let me know but I think you may be trying to over think this
one.

Best Regards,

Anthony

[David Bergert]

Agreed.

I had to do something similar with a constant header in a FSD Message: my
schema looks like:

<schema>
<field id="header" type="K" length="7" >ABCDEFG</field>
<field id="0" type="N" length="2" /> <!--
tran-type-->
<field id="41" type="A" length="8" /> <!--
store-number -->
<field id="46" type="N" length="19" /> <!-- id -->
<field id="39" type="A" length="2"/> <!--
response-code -->
..snip...
</schema>

you could do something like:

<schema>
<field id="header" type="K" length="3">STX</field>
<field id="41" type="AFS"/> <!-- John's fields -->
..snip...
<field id="trailer" type="K" length="3">ETX</field>
</schema>

and use type=AFS for the <FS> delimited fields that you have.

some small snippets to create the FSDISO message

...
protected ISOMsg createISOMsg(Context ctx) throws Exception {
...
FSDMsg fsd = new FSDMsg ("file:cfg/schema.xml)
fsd.set("41","value");
....
return new FSDISOMsg (fsd);

Regards,

David Bergert
www.paymentsystemsblog.com

[Alejandro Revilla]

BTW, I think we could do a simple addition to FSDMsg in order to deal
with a special constant "LRC" that would compute the LRC at pack time
and check it at unpack time.

[JTO]

I appreciate all the feedback but I still feel dumb as a rock.

The solution that I will need to implement will also (future) leverage
my Q2 environment. Today, I am running a JBoss server with Q2 running
as a managed bean (server). In my Q2 deploy directory I have various
configs (front end nodes) for all of my different incoming
connections, these pass all ISOMsgs to my transaction manager which
then logs, and enhances each message based on various logic decisions
before it passes it to an appropriate QMux which then sends the TXN to
our back-end host processing system.

All of this is working and in production today but routed through
other systems which I would like to take out of the picture. As I
mentioned in my earlier post I have created an STXETXChannel which
works perfectly by receiving incoming msgs as well as connecting and
sending STX/ETX msgs to my back-end system. What I am thinking might
work would be to create a packager with only one field like:

protected ISOFieldPackager fld[] = {
/*000*/ new IF_CHAR( 999, "ASCII Message Sting")
};

This would enable me to capture the message and then pass it into a
Transaction Mgr preprocessing function to convert the msg into my
standard (internally defined) msg package. At which point all other
(already defined / created) applications (participants) could be
leveraged and then a post-process function to turn it back into the
single packaged format before sending it along or back to the
requesting host.

This would be the future, for now I will just be logging and passing
through which I can do but it really would be a one off and a
duplication of effort.

Am I crazy for even thinking this way?

[Alejandro Revilla]

>
> I appreciate all the feedback but I still feel dumb as a rock.
>

Please have a look at r2635, I've added three new classes:

org.jpos.iso.FSDISOMsg
org.jpos.iso.channel.FSDChannel
org.jpos.iso.packager.DummyPackager

You can use something like:

<channel-adaptor name='yourchannel'
class="org.jpos.q2.iso.ChannelAdaptor" logger="Q2">
<channel class="org.jpos.iso.channel.FSDChannel" logger="Q2" realm="yourrealm"
packager="org.jpos.iso.packager.DummyPackager">
<property name="host" value="your.host" />
<property name="port" value="nnnn" />
<property name="schema" value="file:cfg/your-schema-" />
</channel>
<in>your-send</in>
<out>your-receive</out>
<reconnect-delay>10000</reconnect-delay>
</channel-adaptor>

The code is straight forward, you'll see that we need the DummyPackager
just to keep the channel adaptor happy.

You'll probably have to modify your STXETXChannel based on FSDChannel.

Please let us know if this works for you.

[Anthony Schexnaildre]

I think you may be over thinking this a bit. You don't need a custom
channel or packager. It seems ASCIIChannel should work fine for you
and FSDMsg does all the packaging you would need.

Best Regards,

Anthony

[JTO]

Alejandro,

You sir, are the coolest. I have updated to r2635 and I am working on
integrating into my environment.

Based on what you have provided I no longer feel dumb as a rock and
believe that I will be able to tie it all together now.

THANK YOU!!!

-John

[Alejandro Revilla]

>
> You sir, are the coolest. I have updated to r2635 and I am working on
> integrating into my environment.
>

I'm flattered but, actually the work on this FSD-to-ISO stuff is
something we came up after many iterations with Andy and many tests by
his team on one of his interchange requirements (I think the first use
was a link to Verizon).

>
> Based on what you have provided I no longer feel dumb as a rock and
> believe that I will be able to tie it all together now.
>

Great, I hope that was a jPOS Ah-ha! moment :)

[Andy Orrock]

Thanks, Alejandro.

To confirm: Yes, Alejandro designed & we tested and implemented FSDISOMsg
as part of requirement to establish a remote authorization connection to
Verizon (phone card activation). You can read about the project and some
follow-ups in a post I did here:

http://tinyurl.com/6pn48a

As Dave mentioned, he recently re-purposed the core FSDISOMsg work for our
MethCheck requirements. You can read about Dave's experiences here:

http://tinyurl.com/5ctbyz

FSDISOMsg has proven to be very adaptable and reliable.

Andy Orrock

-----Original Message-----
From: jpos-...@googlegroups.com [mailto:jpos-...@googlegroups.com] On

[JTO]

Thanks to everyone, I have been able to work through all of the pieces
and I have almost tied it together, I just have one exception that
maybe someone here as run into before.

FSD Data >>>> incoming msg ( I am able to turn into standard ISOmsg
via FSDIsoMsg )
ISOMsg ---- Is logged and passed along as needed
*** Problem *** No Msg Keys, so I create my own upon creation into
the system.
>>>> TXNMgr,QMux, All is fine

I am using what I will call a MuxPool which is a spacelet that does
round robining of 10 back-end nodes (this functionality is working
beutifully in production today). Since the host that I am connecting
to does not allow me to pass (or will it return) any keys, or data
even in the same format, I am thinking of using the space for the Msg
key and the BE node that the TXN is being sent to. Then when the TXN
comes back, I will check the space for the node and put the key back
into the message before returning back, ultimately stripping out the
key before sending back to the requestor.

--- MuxPool ---
<spacelet name="pooledmux">
<space>tspace:default</space>
<run>
int lastChannel = 1;
while (spacelet.running()) {
Object obj = sp.rd ("STXETX.send", 3000);
if (obj != null) {
if (sp.rdp ("IPX.550"+lastChannel+".ready") != null)
{
// Somehow need to tie this msg (Key) to this channel
sp.out ("IPX.550"+lastChannel+".send",
sp.in("STXETX.send"));
}
lastChannel++;
if (lastChannel >10)
lastChannel=1;
}
}
</run>


Does this make sense? Anyone know of a better way to accomplish this?

[Alejandro Revilla]

I'm not sure I understand your requirement.

Wouldn't our MUXPool implementation work for you using the existing keys?

[Andy Orrock]

Johnny -

Have you looked at the little 'keys' trick implemented as discussed in my
blog entry on this matter:

http://tinyurl.com/6pn48a

We name two of the response fields '11' and '41', which allows us to
leverage the default keys.

As I mention in my post:

"Here's the linchpin of the approach: The QMUX key fields have to be named
with their ISO equivalents. You can see below that we have two fields that
equate directly to 41 and 11 (QMUX's default key - the TID and STAN
respectively), so we named them as such in the XML structure. Anything you
put in the mux key you need to tie in here."

Is this what you're asking? (I'm agreeing with Alejandro's comment.)

Andy Orrock

-----Original Message-----
From: jpos-...@googlegroups.com [mailto:jpos-...@googlegroups.com] On
Behalf Of Alejandro Revilla
Sent: Tuesday, June 24, 2008 4:57 PM
To: jpos-...@googlegroups.com
Subject: Re: FSDMsg Usage

[JTO]

Hey Guys,

Alejandro - I will look into the MUXPool again, but the last time it
did not work the way I needed (see
http://groups.google.com/group/jpos-users/browse_thread/thread/96ee7fae22101a1/118cbffed96f871e?hl=en&lnk=gst&q=robin#118cbffed96f871e
).

Andy - I had previously read your document (excellent btw) and when I
receive the msg I do create keys but the back-end system does not
maintain them. For example - The host can return just one field (short
error msg) and that is it.

Basically I am in the process of migrating to a new back-end host
processing system and I am using jPos to assist me in that task. The
current back-end is not an ISO8583 switch but it has a custom ISO8583
switch which converts various ISO msgs into the aforementioned FSD
format. The new back-end system will only support ISO8583 msgs and
during this migration process we are using jPos to route accounts
based on various factors. So, jPos is basically being used to convert
all incoming traffic into our (internally defined) ISO8583 msg format
and then where possible log and route to either our new system or to
our existing ISO8583 switch. The new requirement is to take the
existing ISO8583 switch out of the equation because we do not want to
continue to pay for development that will be obsolete and to implement
jPos as our only switching solution. For the situation that I am
trying to resolve, the POS devices are sending in TXN's in an FSD
format that the back-end host understands so that our existing ISO
switch just passes them through (manages port traffic and logs it).

If I can accomplish this conversion then we will have all of the
pieces in place to remove the existing switcing equipment with the
added capability of routing to the appropriate back-end system as we
migrate accounts over.

After thinking about this some more I may just need to hard-code a few
of the pieces to compensate for the lack of data returned from our
existing back-end processor.

So, long story short - I know I need to use keys for the QMUX to
locate it but the host does not return that info. I am thinking that
I can put the key and the Back-end node into the space and when that
channel returns data I can first look in the space to get the key,
merge it back to the msg and then return it to the space where it will
get picked up like everything else. As a side note, when I send the
TXN to a back-end node, the node can not get another TXN until it
responds so I will be flaging the Back-end node as busy (if needed)
and reseting it (dropping the connection) if it times out.

Sorry for the long response but it is complicated and not very
straightforward, but it will be extremely powerful if I can get it
tied together.

Thanks again and if you have any suggestions, I am all ears....

-John

[Alejandro Revilla]

>
> Alejandro - I will look into the MUXPool again, but the last time it
> did not work the way I needed (see
> http://groups.google.com/group/jpos-users/browse_thread/thread/96ee7fae22101a1/118cbffed96f871e?hl=en&lnk=gst&q=robin#118cbffed96f871e
> ).
>

Oh, you need a stack-type behavior, I wonder if the PRIMARY_SECONDARY
strategy of the MUXPool would work for you.

>
> So, long story short - I know I need to use keys for the QMUX to
> locate it but the host does not return that info.
>

The ISOMsg keeps a weak reference to the ISOSource (see
ISOMsg.getSource()), if you use stuff like that in the FSDISOMsg you may
be able to create a suitable key based on an unique endpoing socket
identifier (wild guessing here but could be food for thought).

>
> I am thinking that I can put the key and the Back-end node into the
> space and when that channel returns data I can first look in the space
> to get the key, merge it back to the msg and then return it to the
> space where it will get picked up like everything else. As a side
> note, when I send the TXN to a back-end node, the node can not get
> another TXN until it responds so I will be flaging the Back-end node
> as busy (if needed) and reseting it (dropping the connection) if it
> times out.
>

If carrying that reference around through the ISOMsg.setSource/getSource
is not an option, then the Space is always a good solution.

>
> Sorry for the long response but it is complicated and not very
> straightforward, but it will be extremely powerful if I can get it
> tied together.
>

It's sad that the people that design these proprietary protocols doesn't
think about situations like this that could be solved with just a simple
handback field. In our ISO-8583 based internal message format we have
assorted handback fields of several sizes to make programmer's life
easier.

In one of our ISO-8583 v87 to v2003 converters (SS implementation as
described in the blog) we use a handback binary field to place a binary
copy of the request in packed format, which comes very handy to populate
the responses.

--Alejandro

[David Bergert]

Hi John:

>
> Andy - I had previously read your document (excellent btw) and when I
> receive the msg I do create keys but the back-end system does not
> maintain them. For example - The host can return just one field (short
> error msg) and that is it.>

The keys do not have to be plural -- it can be a single field, as long it is
unique -- Do you not have a unique value that lives in both the request and
response messages ? Does the other host have a "echo" or user data type
field that could be used ?

> So, long story short - I know I need to use keys for the QMUX to
> locate it but the host does not return that info. I am thinking that
> I can put the key and the Back-end node into the space and when that
> channel returns data I can first look in the space to get the key,
> merge it back to the msg and then return it to the space where it will
> get picked up like everything else. As a side note, when I send the
> TXN to a back-end node, the node can not get another TXN until it
> responds so I will be flaging the Back-end node as busy (if needed)
> and reseting it (dropping the connection) if it times out.

This sounds reasonable, given if there is no "key" that you can use.

--Dave
www.paymentsystemsblog.com

[JTO]

Thanks again for all of the responses, I will sleep on it and try to
come up with a workable solution.

As much as I want to make it fit the model I think that it may be more
effort then it is worth since the goal is to deprecate the old FSD
format it may be better to hardcode to the old environment for the
short term.

Again, I really appreciate all of your thoughts and assistance in this
matter.

-John

[z!†™]

> http://tinyurl.com/6pn48a 

if i may ask...

what does the type stand for here?

type="K"
type="N"

[aaor...@gmail.com]

"K" is a Constant. "N" is numeric.

Andy Orrock

-----Original Message-----
From: z!†™ <muymo...@yahoo.com.ph>

Date: Wed, 25 Jun 2008 00:48:43
To:jPOS Users <jpos-...@googlegroups.com>
Subject: Re: FSDMsg Usage

[David Bergert]

Also:

"B" is Binary
"A" is Alpha/Numeric/String

see line 171: in modules/jpos/src/org/jpos/util/FSDMSG.java to see how they
are handled.

--Dave
www.paymentsystemsblog.com

> -----Original Message-----

> From: jpos-...@googlegroups.com [mailto:jpos-...@googlegroups.com] On

[Shin]

Hi all,

Does FSDMsg only supports fixed length field?
Can FSDMsg supports variable length field? let say 2 bytes of length.

--Shin

[Mark Salter]

Shin wrote:

> Does FSDMsg only supports fixed length field?

No

> Can FSDMsg supports variable length field? let say 2 bytes of length.

Yes, I think you are missing an important point?

In an FSDMsg, the field length is determined via the field separators
which mark the end of one field and the start of the next.
--
Mark

[Shin]

Thanks, Mark.

i got other problem. i create a schema below. And set the Mac value =
"47189B7AA08E6B1B" but when i send out this message
the client side received the value is ="47183F7AA03F6B1B".

<schema>
<field id="MAC" type="B" length="8"/>
</schema>

-- Shin

[Mark Salter]

Shin wrote:
> Thanks, Mark.
>
> i got other problem. i create a schema below. And set the Mac value =
> "47189B7AA08E6B1B" but when i send out this message
> the client side received the value is ="47183F7AA03F6B1B".
>
> <schema>
> <field id="MAC" type="B" length="8"/>
> </schema>

Is 47183F7AA03F6B1B the value you see leaving your system even though
your code places the 47189B7AA08E6B1B?

Do you control the client side as well, can you confirm this is the data
being received or is a third party describing what they see?

If you can add a Logger to your Channel and packager, perhaps that will
give some clues.

If nothing is obvious, then as you appear to be using the windows
operating system, can you try using wireshark (
http://www.wireshark.org/ )- or similar to see the packets that are
actually being sent out of your network?

We can at least eliminate jPOS as the culprit if what you place as a MAC
goes out on the network message.

--
Mark

[Shin]

Hi Mark,

i change pack（） function fsd.pack().getBytes(); to
fsd.pack().getBytes("ISO8859_1");
Then i get the correct value. I read the FSDMsg code. It use
"ISO8859_1" pack the message.
I'm not sure whether the encoding problem but this is the result what
test just now.
Pls tell me if i did wrong. Thanks.

public byte[] pack() throws ISOException {
try {
// return fsd.pack().getBytes();
return fsd.pack().getBytes("ISO8859_1");
} catch (Exception e) {
throw new ISOException (e);
}
}

--Shin

On Jun 27, 7:07 pm, Mark Salter <marksal...@dsl.pipex.com> wrote:
> Shin wrote:
> > Thanks, Mark.
>
> > i got other problem. i create a schema below. And set the Mac value =
> > "47189B7AA08E6B1B" but when i send out this message
> > the client side received the value is ="47183F7AA03F6B1B".
>
> > <schema>
> > <field id="MAC" type="B" length="8"/>
> > </schema>
>
> Is 47183F7AA03F6B1B the value you see leaving your system even though
> your code places the 47189B7AA08E6B1B?
>
> Do you control the client side as well, can you confirm this is the data
> being received or is a third party describing what they see?
>
> If you can add a Logger to your Channel and packager, perhaps that will
> give some clues.
>
> If nothing is obvious, then as you appear to be using the windows

> operating system, can you try using wireshark (http://www.wireshark.org/)- or similar to see the packets that are

[Alejandro Revilla]

> test just now.
> Pls tell me if i did wrong. Thanks.
>

You did the right thing. I've added a packToBytes() method to FSDMsg
(r2639) as a reminder because this is a very easy to hit bug.

[Shin]

Hi Alejandro,

i suggest FSDISOMsg need to change to packToBytes ().

public byte[] pack() throws ISOException {
try {

return fsd.packToBytes ();
//return fsd.pack().getBytes();

} catch (Exception e) {
throw new ISOException (e);
}
}

--Shin

[Alejandro Revilla]

Good point! - done in r2640.

[JTO]

Alejandro,

Okay I am back....

I have been working through the formats and have come across another
killer issue which I thought I could get around but I need some
further guidance.

First let me explain the situation as clearly as possible and then I
will state the problem.

The FSD format I am working on begins with an STX (char 02) has fixed
length and field delimted data, finally ending with an ETX (char 03).
I have been able to successfully send and receive messages in this
format after many head scratchings. Once I was able to decode and
manipulate the messages I passed them along to the existing back-end
where the transaction was completed correctly. I was very happy!!!
Then I realized that the data coming back from the host was formatted
differently (and if the msg fails different from that as well,
although insignificant).

My Incoming FSD definitions (3)

<schema id='base'>
<field id="mti" type="A" length="2" key="true" />
</schema>

When mti = 31

<schema id='31'>
<field id="merchant" type="A" length="6" />
<field id="term-type" type="AFS" length="3" key="true" />
</schema>

When term-type = 100

<schema id='100'>
<field id="soh" type="A" length="1" />
<field id="card-data" type="AFS" length="31" />
<field id="prod-code1" type="NFS" length="3" />
<field id="units1" type="NFS" length="8" />
<field id="ppu1" type="NFS" length="7" />
<field id="purchase1" type="NFS" length="7" />
<field id="prod-code2" type="NFS" length="3" />
<field id="units2" type="NFS" length="8" />
<field id="ppu2" type="NFS" length="7" />
<field id="purchase2" type="NFS" length="7" />
<field id="prod-code3" type="NFS" length="3" />
<field id="units3" type="NFS" length="8" />
<field id="ppu3" type="NFS" length="7" />
<field id="purchase3" type="NFS" length="7" />
<field id="po-number" type="AFS" length="15" />
<field id="inv-number" type="AFS" length="10" />
<field id="inv-total" type="N" length="7" />
</schema>

Here is the response FSD schema

<schema>
<field id="1" length="20" type="AFS"/> <!-- Response Code & Auth
Number or Short Error -->
<field id="2" length="20" type="AFS"/> <!-- Message1-->
<field id="3" length="20" type="AFS"/> <!-- Message2 -->
<field id="4" length="20" type="AFS"/> <!-- Message3 -->
<field id="5" length="20" type="AFS"/> <!-- Message4 -->
<field id="6" length="20" type="AFS"/> <!-- Message5 -->
</schema>

I am able to resolve by hardcoding base & schema in my StxEtx channel
(override receive in BaseChannel) when I run it outside of Q2. Inside
of Q2 the only way I can come up with is to create 2 opposite
StxEtxChannels (in / out) depending upon if the node is front-end or
back-end (as jPos is just passing the data through).

Am I on the right path or have I missed something very obvious?

Thanks in advance,

-John

[Alejandro Revilla]

Can't you specify a different schema base name for in versus out?

[JTO]

I thought that I could but was not able to get it to work with both
sides because the data on the incoming msg is not delimited (fixed
length) for the first couple of fields. The return data is sort of
delimited but if successful it basically contains the auth number, if
unsuccessful it contains numerous errors codes (120 or so) and text
data.

I have been thinking about this for the past few days while on
vacation and I am thinking of merging the 2 previous formats into one
(below) and then have the incoming channel add field fill data to the
incoming bytes before creating the FSD message. On the response data I
may (or may not) need append the original data to the response. I
think that doing it this way will allow me to create one format and
only a slight amount of logic to move / manipulate the message as
needed.

<schema id='100'>
<field id="1" length="20" type="AFS"/> <!-- Auth Number or Short

Error -->
<field id="2" length="20" type="AFS"/> <!-- Message1-->
<field id="3" length="20" type="AFS"/> <!-- Message2 -->
<field id="4" length="20" type="AFS"/> <!-- Message3 -->
<field id="5" length="20" type="AFS"/> <!-- Message4 -->
<field id="6" length="20" type="AFS"/> <!-- Message5 -->

<field id="soh" type="A" length="1" />
<field id="card-data" type="AFS" length="31" />
<field id="prod-code1" type="NFS" length="3" />
<field id="units1" type="NFS" length="8" />
<field id="ppu1" type="NFS" length="7" />
<field id="purchase1" type="NFS" length="7" />
<field id="prod-code2" type="NFS" length="3" />
<field id="units2" type="NFS" length="8" />
<field id="ppu2" type="NFS" length="7" />
<field id="purchase2" type="NFS" length="7" />
<field id="prod-code3" type="NFS" length="3" />
<field id="units3" type="NFS" length="8" />
<field id="ppu3" type="NFS" length="7" />
<field id="purchase3" type="NFS" length="7" />
<field id="po-number" type="AFS" length="15" />
<field id="inv-number" type="AFS" length="10" />
<field id="inv-total" type="N" length="7" />
</schema>

Does this seem reasonable to you?

[Alejandro Revilla]

FSDMsg has two unpack methods:

unpack (byte[])

and

unpack (InputStream)

you should be able to use the latter and unpack the message on the fly,
problem is I'm not sure you can use the first field as a key without
some hacking at the FSDMsg level (probably extending FSDMsg).

Please let us know if FSDMsg needs any change to allow that kind of
extension (i.e. at FSDMsg line 300 we may have to call a protected
method that you could override).

[JTO]

Alejandro,

After numerous attempts I finally figured it out and I have uploaded
my solution (StxEtxChannel) to the file area. Please take a look when
you get a chance and let me know if what I did seems appropriate
(correct) as I am NOT a developer.

Basically I am using FSDMsg and FSDISOMsg with schemas as described in
earlier posts but what I needed to do was to have different incoming
and outgoing formats, as well as both a front-end node with one format
and a back-end node with the opposite format. Add to this the need to
unwrap the incoming text message from STX(char 02) and ETX (char 03)
and wrap the response with the same STX/ETX combination. I was able to
accomplish all of the above by creating the custom StxEtxChannel taht
I uploaded for your review.

The below is an example of my QServer and Channel-Adapter XML
configurations

<server class="org.jpos.q2.iso.QServer" logger="Q2" name="QServer">
<attr name="port" type="java.lang.Integer">9101</attr>
<channel class="org.jpos.iso.channel.StxEtxChannel" logger="Q2"
packager="org.jpos.iso.packager.DummyPackager">
<property name="requestbase" value="file:cfg/schemas/REQ-" />
<property name="requestschema" value="base" />
<property name="responsebase" value="file:cfg/schemas/RSP-" />
<property name="responseschema" value="base" />
<property name="base" value="file:cfg/schemas/STX-" />
<property name="schema" value="base" />
</channel>
<request-listener class="org.jpos.XXX.CustomListener" logger="Q2">
<property name="destination-mux" value="IPGateMux"/>
<property name="destination-channel" value="channel-adaptor"/>
<property name="timeout" value="60000"/>
</request-listener>
</server>

-----------ChannelAdaptor-------------

<channel-adaptor name='IPG.XXXX'
class="org.jpos.q2.iso.ChannelAdaptor">
<property name="debug" value="true"/>
<channel class="org.jpos.iso.channel.StxEtxChannel" logger="Q2"
packager="org.jpos.iso.packager.DummyPackager">
<property name="requestbase" value="file:cfg/schemas/RSP-" />
<property name="requestschema" value="base" />
<property name="responsebase" value="file:cfg/schemas/REQ-" />
<property name="responseschema" value="base" />
<property name="host" value="127.0.0.1"/>
<property name="port" value="1234"/>
</channel>
<in>IPGATE.send</in>
<out>IPGATE.receive</out>
<ready>IPGATE.ready</ready>
<reconnect-delay>5000</reconnect-delay>
</channel-adaptor>

[Alejandro Revilla]

Unfortunately I don't have the time to go over all your files, but after
an express read your approach looks perfect, and if it works for you,
then you're all set!