Using NACChannel

[JPractitioner]

Hello guys, I'm back :)

Currently we're going to have direct connection to NAC. I knew that NAC
packet is having ip header (which i didnt found on the msg), tcp header
(which i didnt found on the msg neither), packet length in msb/lsb,
tpdu header and the isomessage (encoded in hex).

Based on these information, I can snip all other details (i.e. tcp
header, ..tpdu header, etc) upon processing the packet. When sending
the response i also can append these headers as necessarily back to
their locations.

However, I had a thought that using NACChannel, things might be much
easier and cleaner. I already handled the ServerSocket connection and
threading part of the codes, can i still use NACChannel?

Thanks in advance.

[JPractitioner]

btw, is there any part in jPOS the handles reconcilation for pos
terminals or for NAC?
thx again...

[Mark Salter]

JPractitioner wrote:
> However, I had a thought that using NACChannel, things might be much
> easier and cleaner. I already handled the ServerSocket connection and
> threading part of the codes, can i still use NACChannel?

I guess you could, however in order for your 'ISOServer' to use the
NACChannel in the same way that a jPOS ISOServer would both 'servers'
have to interface to the NACChannel in the same way.

Might using base jPOS completely (and extending where you need to) be a
better way of using the various components?

Trying to reuse components in isolation means you are a bit stranded
should NACChannel not work as expected with your Server code, we don't
have your code to find out why 'our' code isn't working with it.

It is obviously your choice, but I wonder why you seek selective use of
jPOS components?

--
Mark

[Mark Salter]

A similar question was asked about Visa Base 2 recently.

To my knowledge there is no base support for settlement in jPOS, it
focuses on the on-line processing only.

I have little knowledge of the settlement exchange as like many others I
settled in the on-line rather than the batch processing environments.

In my simplistic view of settlement, I would think a log could easily be
selectively translated into a settlement file of most kinds.

I wonder how others deal with the production of settlement files from jPOS?

--
Mark

[JPractitioner]

Hello Mark.
Thanks for both replies (which i found are very good).
I will look into the suggestion regarding settlement.

The reasons why i have not been using jPOS all the way are because of
I'm lack of knowledge of what options i might have with jPOS during the
earlier stages.
I'm also lacking the knowledge of what feature will be ammended (i.e.
only now NAC is put in to the big picture).

As for now, I will try jPOS server in parallel.. see for better
results.

Thanks Mark.

[JPractitioner]

I do some testing on isoserver Test.java

and the outcome is as the followings
<log realm="iso-server" at="Mon Feb 27 13:53:09 GMT+08:00 2006.937">
<iso-server>
listening on port 8801
</iso-server>
</log>
<log realm="iso-server.session/192.168.0.151" at="Mon Feb 27 13:53:59
GMT+08:00
2006.46">
<session-start/>
</log>
<log realm="iso-server.channel/192.168.0.151:1664" at="Mon Feb 27
13:53:59 GMT+0
8:00 2006.62">
<receive>
<iso-exception>
receive length 12336 seems strange
org.jpos.iso.ISOException: receive length 12336 seems strange
at org.jpos.iso.BaseChannel.receive(BaseChannel.java:525)
at org.jpos.iso.ISOServer$Session.run(ISOServer.java:123)
at
org.jpos.util.ThreadPool$PooledThread.run(ThreadPool.java:100)
</iso-exception>
</receive>
</log>

I modified the original code a bit to be like the followings
package isoserver;

import org.jpos.iso.ISOMsg;
import org.jpos.iso.ISOField;
import org.jpos.iso.ISOServer;
import org.jpos.iso.ISOSource;
import org.jpos.iso.ISOChannel;
import org.jpos.iso.ServerChannel;
import org.jpos.iso.ISORequestListener;
import org.jpos.iso.channel.NACChannel;
import org.jpos.iso.channel.LoopbackChannel;
import org.jpos.iso.packager.ISO87BPackager;

import org.jpos.util.Logger;
import org.jpos.util.LogSource;
import org.jpos.util.SimpleLogListener;
import org.jpos.util.ThreadPool;

public class Test implements ISORequestListener {

public boolean process (ISOSource source, ISOMsg m) {
try {
m = (ISOMsg) m.clone ();
m.setResponseMTI();
m.set (new ISOField(39, "99"));
source.send(m);
} catch (Exception e) {
return false;
}
return true;
}

public static void main(String args[]) {

byte b[] = new byte[14];
String s="s";

try {
Logger logger = new Logger();
logger.addListener (new SimpleLogListener (System.out));

ISOChannel clientSideChannel = new NACChannel
(s,1,new ISO87BPackager(),b); /*i changed the port*/

// (new ISO87BPackager(),b); // see jpos.cfg

ThreadPool pool = new ThreadPool (5, 30);
pool.setLogger (logger, "iso-server-pool");

ISOServer server =
new ISOServer (
1, (ServerChannel) clientSideChannel, pool); /*i
changed the port*/

server.setLogger (logger, "iso-server");
server.addISORequestListener (new Test());
new Thread (server).start();
} catch (Exception e) {
e.printStackTrace();
}
}
}

This is the part which i concern about
receive length 12336 seems strange
org.jpos.iso.ISOException: receive length 12336 seems strange

what length should not be strange?

Please advice, Thanks in advance :)

[JPractitioner]

I wonder if when i configure the codes as above, will it be possible
now to handle packets from NAC?
If not, suggestions and ideas from u guys are much needed and
appreciated..
Thanks.

[JPractitioner]

Or is there any example on ISO server handling for NACChannel
of which i can refer?

Thanks.

[JPractitioner]

sorrry ,, theres a typo,
what i meant was...
is there any example on ISO server that handles NAC messages

[Alejandro Revilla]

You need to setup your TPDU correctly,

>
> byte b[] = new byte[14];
>

Please try

byte b[] = new byte[5];

--Alejandro

[Mark Salter]

JPractitioner wrote:
> receive length 12336 seems strange

12336 is x'3030' the channel is reading the first two bytes out of the
network which in this case are two ASCII bytes c'00'.

BaseChannel sanity checks the length and if it is less than 10 or
greater than 4096 is is considered 'strange'. Have you already
stripped anything out of the Channel?

Could you include :-

clientSideChannel.setLogger(logger);

which should provide you with a NACChannel log.

As food for thought, the NACChannel is expecting :-
[2 byte length][TPDU]{message]

is your message coming over the wire in this structure?

--
Mark

[Alejandro Revilla]

>
> As food for thought, the NACChannel is expecting :-
> [2 byte length][TPDU]{message]
>
> is your message coming over the wire in this structure?
>

Based on that initial 3030, I guess ASCIIChannel could do better ...

[JPractitioner]

Hello Mark, Alejandro,,

Hello guys..
I had a succesfull use of NACChannel today. Anyway for the sake of
learning, I have to add this thread.

It seems that to connect with NAC, there are more details to be handled
instead of only interchanging the destination and source address in
tpdu header and handling the 2 bytes length. Can you guys please tell
me what else that the NACChannel did. I wonder why, when sending
packets (which only send out string) via OutputStream, i had the
"receive length xxxx seems strange" exception. The only time its not
"seems strange" is when the string is empty.

To connect with NAC, is there any NAC protocol that should be
considered? Is there anything like sending ACK (acknowledgement), and
REQ (request) strings along the communication?

Thanks.
p/s: I am verry grateful for all the support u guys provided (so far,,
hehe).
Hence, we just paid for the jPOS developers manual.

[Matias Crespillo]

Getting that manual seems to be a huge step towards the right choice, i
recommend you take the time to go over it a bit more than a couple times,
when I got started with Jpos I had a lot of luck to have the best possible
advisor by my side and that little manual, it can help you setting up a Jpos
beyond you could imagine, give it a shot and you wont be dissapointed.

[JPractitioner]

Thanks for your comment Matias,
I am looking forward to get the best out of it and to increase my
knowledge as well along the way.

[JPractitioner]

Hello guys,
I'm trying the isoserver(as the server) and simplegui (as the
client)example.
In the *public boolean process (ISOSource source, ISOMsg m) {}* part
of isoserver, I want to read the message original value such as
*080080380000008000000400000000000000000006224723030130303030303030310301*.
So i try to get it by doing m.toString(). However, I only got the
value to be *<-- 0800 000003 00000001*. Please help.

Thanks.

[Mark Salter]

Did you include channel.setLogger(logger)?

I am not sure if you are trying to diagnose a problem, you could :-

m.dump(System.out,"diag"); // An 'xml' dump of the message
(field,value...)

or call System.out.print(ISOUtil.hexdump(m.pack())); // hex dump of
packed message - less useful perhaps.

[JPractitioner]

Mark, using your suggestion to use ISOUtil.hexdump(m.pack())), I got
the followings. (Actually i am trying to keep a log of incoming and
outgoing messages in their original hex form. I save this log on a
dbms).

0000 08 00 80 38 00 00 00 80 00 00 04 00 00 00 00 00
...8............
0010 00 00 00 00 04 01 08 44 03 02 30 30 30 30 30 30
.......D..000000
0020 30 31 03 01 01..

This is very cool. and i also tried to use m.getBytes() when i noticed
that it "fits" to get the same result.
Do u know why *...8............* and * .......D..000000* is on the dump
as well?
same question goes with (seems to be running) id 0000 0010 0020. I
would appreciate some explanation on this. I noticed this pattern
whenever hex values are being displayed on my computer but i never knew
why its there.

The dump for the message in iso 8583 format is as the following
<log realm="channel/127.0.0.1:8801" at="Thu Mar 02 01:25:25 GMT+08:00
2006.218">

<send>
<isomsg direction="outgoing">
<field id="0" value="0800"/>
<field id="11" value="000003"/>
<field id="12" value="012525"/>
<field id="13" value="0302"/>
<field id="41" value="00000001"/>
<field id="70" value="301"/>
</isomsg>
</send>
</log>

I never did the logger. its already there in the example code. However,
there is no channel.setLogger(logger). I will try this. However, I
still wonder how the message becomes in **<-- 0800 000003 00000001**
form. and yet when being dumped, it can be seen as the dump pasted
above... hmm.

After all, this problem is solved. Thanks a lot Mark!

[Mark Salter]

JPractitioner wrote:

> 0000 08 00 80 38 00 00 00 80 00 00 04 00 00 00 00 00

offset<---------------- hex values ------------------>
> ...8............
These are the ASCII characters representing the bytes, not too much use
in this this header portion.

> 0010 00 00 00 00 04 01 08 44 03 02 30 30 30 30 30 30

offset<---------------- hex values ------------------>
> .......D..000000
<----ASCII----->

> 0020 30 31 03 01 01..

offset<---------------- hex values ------------------> <ASCII>
But more use as the ASCII bytes come into view (x'30' is ASCII 0)
> same question goes with (seems to be running) id 0000 0010 0020.This is the hexadecimal offset into the 'dump' so in the last block the
first two bytes at offset x'0020' - 32 decimal are x'3031' or ASCII 01

>
> The dump for the message in iso 8583 format is as the following
> <log realm="channel/127.0.0.1:8801" at="Thu Mar 02 01:25:25 GMT+08:00
> 2006.218">
>
> <send>
> <isomsg direction="outgoing">
> <field id="0" value="0800"/>
> <field id="11" value="000003"/>
> <field id="12" value="012525"/>
> <field id="13" value="0302"/>
> <field id="41" value="00000001"/>
> <field id="70" value="301"/>
> </isomsg>
> </send>
> </log>
>

> still wonder how the message becomes in **<-- 0800 000003 00000001**This is not the message but a shorthand representation. The
m.toString() method gives a short string version *not* the whole message
as a String. All you get is MTI+DE11+DE41, which is probably enough to
find the transaction in a log for a single interface.

These are just three ways in which you can view the messages your
interface sees. Use the most useful.

Watch what you save in your database (which could get big) there are
rules around the length of time and what you can save logs, particularly
if you are the acquirer and not the issuer. All sensitive data should
probably be overwritten to avoid unnecessary exposure.

--
Mark

[JPractitioner]

Thanks mark, now its really making more sense to me. So there are these
three message representations! Thanks.

However i still don't understand the functionality of the offsets. Can
u please explain what do u mean by...
*first two bytes at offset x'0020' - 32 decimal are x'3031' or ASCII
01*

I tried to decode the hex and i can find the values you stated, however
I failed to see the relation of the offset and the hex (x30 31 03 01).

Please do not reply to this request if it will cause trouble for you.
:)

p/s: what is DE stands for? (i know that you are refering to the iso
fields, but maybe i could use your terms as well).

[chhil]

Hi,

All unprintable ascii character are represented as "."

0000  08 00 80 38 00 00 00 80  00 00 04 00 00 00 00 00  ...8............

0010  00 00 00 00 04 01 08 44  03 02 30 30 30 30 30 30  .......D..000000

0020  30 31 03 01                                       0 1..

The values in red are the offsets or byte counts.

First row runs from hex 0 to hex F (decimal 15) to hex 1F (decimal 31)

Second row runs from hex 10 (decimal 16) to hex

third row runs from hex 20 (decimal 32) .... see the pattern/

 

Consider row 3 , 0020 is the starting offset

0x20 -> 0x30  is ascii value of 0

0x21 -> 0x31 is the ascii value of 1

 

Hope this helps...

 

-chhil
 

[chhil]

Sorry I messed up a little bit.. ;-)...

 

the text has been edited below..

 

On 3/1/06, chhil <chi...@gmail.com> wrote:

Hi,

All unprintable ascii character are represented as "."

0000  08 00 80 38 00 00 00 80  00 00 04 00 00 00 00 00  ...8............

0010  00 00 00 00 04 01 08 44  03 02 30 30 30 30 30 30  .......D..000000

0020  30 31 03 01                                                         0 1..

The values in red are the offsets or byte counts.

First row runs from hex 0 to hex F (decimal 15)

Second row runs from hex 10 (decimal 16) to hex 1F (decimal 31)

third row runs from hex 20 (decimal 32) .... see the pattern

 

Consider row 3 , 0020 is the starting offset

0x20 -> 0x30  is ascii value of 0

0x21 -> 0x31 is the ascii value of 1

 

Hope this helps...

[Mark Salter]

JPractitioner wrote:
> p/s: what is DE stands for? (i know that you are refering to the iso
> fields, but maybe i could use your terms as well).

Sorry DE is my abbreviation for Data Element.

--
Mark

[JPractitioner]

Hello chhil... thanks a lot. It really helps :)

[JPractitioner]

i see..
ok, thanks Mark.

[JPractitioner]

Hello guys,
how do i configure timeout on ISOServer?
I'm still using the isoserver example but instead of using ASCIIChannel
(as originally written),
i'm using NACChannel.

please help.. thanks.

[Mark Salter]

Isn't the timeout set on the Channel.setTimeout(millisec) rather than
the ISOServer?

--
Mark

[JPractitioner]

yeah Mark.. thanks.
I'll do more homework next time.