> We have this standard log :
Produced from an existing (non jPOS) system you are trying to send
messages to?
>
> MPOS_1_TCP : 10:32:17:14 |Dumping Hex Buffer Length = 2
> MPOS_1_TCP : 10:32:17:14 |00
> 2A
> MPOS_1_TCP : 10:32:17:14 |TCPLINKS: New Data on Socket. Events = 1
> MPOS_1_TCP : 10:32:17:14 |TCPLINKS: Received New [42] Bytes of Data.
> MPOS_1_TCP : 10:32:17:14 |TCPLINKS: Complete Message Data [42] Received.
> MPOS_1_TCP : 10:32:17:14 |TCPLINKS: Dump received Message Data:
> MPOS_1_TCP : 10:32:17:14 |Dumping Hex Buffer Length = 42
>
> *60 00 02 B7 20* 08 00 22 20 00 00 00 80 00 10 93 00 00 00 00
> 00 00 00 00 01 03 31 33 33 30 30 30 30 33 00 06 30 30 30 30
> 30 31
>
>
> This above message is sent from my POS to our system .
> It is standard for my clone .
>
> I understand that 002A is two bye header and "*60 00 02 B7 20"* is TPDU.
x'002A' (decimal 42) is the length of the message that has arrived into
this system. Calling it a header might confuse things later; perhaps
call it the message length?
> We use NCCChannel for sending TPDU but how to send header with this above
> value ?
The Channel will calculate and send the length for you.
>
> To code the client sending , i create the following step : is it okie and my
> understand is correct ?
>
> 1) Create custome package based on vendor specification
> 2) Create channel ( in my case is NCCChannel) for sending message from
> client .
> 3) We create message with key-in value , for example:
> m.setMTI("0800");
> m.set(3, "000000");
> m.set(11, "000001");
> m.set(41, "29110001");
> m.set(60, "test");
> m.set(70, "301");
>
>
> This value message is ASCII so when we need to send message with NCCChannel
> and custom package
> *(ISOChannel channel = new
> org.jpos.iso.channel.NCCChannel("10.36.10.73",9302,new
> way4POSPackager(),ISOUtil.hex2byte("600002B720"))*
>
> Is it field format converted based on defined custome package that named
> way4PosPackager and send out ?
Yes.
Your way4POSPackager will be asked by the NCCChannel to pack each
ISOMsg. This will result in a byte[] holding the message as it will
travel over the network. The NCCChannel will then preprend the message
length in the format it needs and place it onto the network connection,
followed by the message onto the network.
So in summary, the NCCChannel looks after the length, the
way4PosPackager looks after converting the String values you placed in
the fields into the raw representaion. This allows your code to just
handle Strings and passes the work of conversion to ASCII/EBCDIC/Binary
and length calculations to jPOS.
--
Mark
So now you have moved to NCCChannel and your packager to send messages
into MPOS_1 where before the trace was the non-jPOS systems?
OR
Is this trace from the jPOS based system (MPOS_2) you are putting
together, where the previous MPOS_1 is the existing software you seek to
replace?
>
> Log :
>
> MPOS_2_TCP : 15:16:08:11 |Change Message ID to [3] on Entry [1]
> MPOS_2_TCP : 15:16:08:11 |Insert Message Connection ID [3] and Entry [1]
> MPOS_2_TCP : 15:16:08:11 |New Data Received Length = 73
> MPOS_2_TCP : 15:16:08:11 |Just before ISO8583_ANALYSE
> MPOS_2_TCP : 15:16:08:11 |Received New Message, let dump it
> MPOS_2_TCP : 15:16:08:11 |Dumping Hex Buffer Length = 73
> MPOS_2_TCP : 15:16:08:11 |00 71 60 00 02 B7 20 30 38 30 30 41 30 32 30 30
> 30 30 30 30 .q`... 0800A02000000
> MPOS_2_TCP : 15:16:08:11 |30 38 30 30 30 31 30 30 34 30 30 30 30 30 30 30
> 30 30 30 30 08000100400000000000
> MPOS_2_TCP : 15:16:08:11 |30 30 30 30 30 30 30 30 30 30 30 30 30 30 31 32
> 39 31 31 30 00000000000000129110
> MPOS_2_TCP : 15:16:08:11 |30 30 31 30 30 34 74 65 73 74 33 30
> 31 001004test301
> MPOS_2_TCP : 15:16:08:11 |Message Format: POS ISO8583
> MPOS_2_TCP : 15:16:08:11 |Received Message Type is 0071
>
>
I'm going to assume your are developing a system to receive the messages
from your POS...
I think the x'0071' logged is the *decimal* message length and your
Channel has taken the network length of decimal 73 off of the network.
Hard to illustrate in text, but could you be receiving over the network
from your POS :-
2 bytes whole length + 2 byte message length + 71 byte of message
where the message starts with a TPDU that is 5 bytes long?
giving :-
x'
00730071600002B7 2030383030413032
3030303030303038 3030303130303430
3030303030303030 3030303030303030
3030303030303030 3132393131303030
3130303474657374 333031
'
?
Your code is not skipping over the 'extra' length or the TPDU bytes
(x'600002B720') to get to the x'30383030' (c'0800') that follows.
Does that make sense, within my assumption you a developing the receiver
of POS messages?
I would suggest you make a network trace (using wireshark or similar) to
see what the messages from your POS look like, and use that information
to start with?
--
Mark
> And we use message length ( not header ) , it is okie .
> So declare like this is message lenthe is shown by 2 bytes , it that right?
> ISOChannel channel = new
> org.jpos.iso.channel.NCCChannel("10.36.10.73",9302,new way4POSPackager(),*new
> byte[]{(byte)002}*)
You are mixing up a number of components of the flow I'm afraid.
The 4th parm is the TPDU, not a value indicating the number of bytes to
hold a length? If you have a TPDU then that goes as the 4th parm.
You don't need to worry about the length, the NCChannel will do that for
you.
I think your POS is sending more lengths than you expect - so get a
trace of a current network exchange first. I have stated two lengths in
my last reply, but to give more commentary...
>
> Log:
>
> MPOS_2_TCP : 15:47:46:45 |E[000]: Client IP Address [10.36.90.47] added to
> message
> MPOS_2_TCP : 15:47:46:45 |Change Message ID to [5] on Entry [0]
> MPOS_2_TCP : 15:47:46:45 |Insert Message Connection ID [5] and Entry [0]
> MPOS_2_TCP : 15:47:46:45 |New Data Received Length = 69
So on the network you found two bytes holding x'0069'. Note you are
treating this a decimal length when the original components held a
binary length - just beware.
> MPOS_2_TCP : 15:47:46:45 |Just before ISO8583_ANALYSE
> MPOS_2_TCP : 15:47:46:45 |Received New Message, let dump it
> MPOS_2_TCP : 15:47:46:45 |Dumping Hex Buffer Length = 69
> MPOS_2_TCP : 15:47:46:45 |00 67 02 30 38 30 30 41 30 32 30 30 30 30 30 30
> 30 38 30 30 .g.0800A020000000800
The part above starts with 'another length x'0067' which seems to be the
length of data that follows.
> MPOS_2_TCP : 15:47:46:45 |30 31 30 30 34 30 30 30 30 30 30 30 30 30 30 30
> 30 30 30 30 01004000000000000000
> MPOS_2_TCP : 15:47:46:45 |30 30 30 30 30 30 30 30 30 30 31 32 39 31 31 30
> 30 30 31 30 00000000001291100010
> MPOS_2_TCP : 15:47:46:45 |30 34 74 65 73 74 33 30
> 31 04test301
> MPOS_2_TCP : 15:47:46:45 |Message Format: POS ISO8583
> MPOS_2_TCP : 15:47:46:45 |Received Message Type is 0067
> MPOS_2_TCP : 15:47:46:45 |Invalid Message Type [0067] is requested
You are reporting the MTI as the first two bytes, which here hold the
message length x'0067', you need to align your Channel with the message
your POS system or device is sending, currently they are misaligned.
You might need a new Channel to deal with binary (not decimal lengths),
but also 'absorb' *two* length fields?
A network trace of existing and the detail of which component you are
replacing will help.
--
Mark
> Let i explain my scenario :
>
> I develop a client that simulates a POS using JPOS and send message to my
> host ( way4 host)
Ok, so my assumption was incorrect 8( !
>
> Our way 4 host have 2 channels ( mpos1 and mpos2 , it is the same , mpos2 is
> dulicated from mpos1) . Hope that you are not confused
Ok so far.
> I use real POS send message to mpos1 and got log ( Log is okie and return
> 0810)
Good, so the existing system works still 8).
> I use my client ( write by jpos ) send message to mpos2 and got log ( log
> has erros )
> (I use seperate channel for testing and develop only )
>
> I cannot know why it is errors so need your advise :
>
> *Log of mpos1 *:
>
> *MPOS_1_TCP : 10:32:17:14 |Dumping Hex Buffer Length = 2
> MPOS_1_TCP : 10:32:17:14 |00
> 2A .*
The existing POS is sending a 2 byte *binary* message length? You need
to as well, although I do suspect that MPOS_2 is has a *different* setup
to MPOS_1!
> MPOS_1_TCP : 10:32:17:14 |TCPLINKS: New Data on Socket. Events = 1
> MPOS_1_TCP : 10:32:17:14 |TCPLINKS: Received New [42] Bytes of Data.
> MPOS_1_TCP : 10:32:17:14 |TCPLINKS: Complete Message Data [42] Received.
> MPOS_1_TCP : 10:32:17:14 |TCPLINKS: Dump received Message Data:
> MPOS_1_TCP : 10:32:17:14 |Dumping Hex Buffer Length = 42
Note, decimal 42 is x'2A'
> MPOS_1_TCP : 10:32:17:14 |60 00 02 B7 20 08 00 22 20 00 00 00 80 00 10 93
> 00 00 00 00 `... .." ...........
Here is the TPDU, which I would choose to call a header. It is 5 bytes :-
x'600002B720'
In sending a message in, I would set the ISOMsg header to these bytes -
does there content change at all?
> MPOS_1_TCP : 10:32:17:14 |00 00 00 00 01 03 31 33 33 30 30 30 30 33 00 06
> 30 30 30 30 ......13300003..0000
> MPOS_1_TCP : 10:32:17:14 |30
> 31 01
> MPOS_1_TCP : 10:32:17:14 |TCPLINKS: Message received successfully, Length
> [42]
> MPOS_1_TCP : 10:32:17:14 |TCPLINKS: Dump Of Received Data:
> MPOS_1_TCP : 10:32:17:14 |Dumping Hex Buffer Length = 37
Note here that 37 = 42 - 5, so...
> MPOS_1_TCP : 10:32:17:14 |08 00 22 20 00 00 00 80 00 10 93 00 00 00 00 00
> 00 00 00 01 .." ................
By here, the header (or TPDU) is gone and we are at the x'0800' MTI, and
ready to deal with this message.
> MPOS_1_TCP : 10:32:17:14 |03 31 33 33 30 30 30 30 33 00 06 30 30 30 30 30
> 31 .13300003..000001
> MPOS_1_TCP : 10:32:17:14 |New Data Received Length = 37
> MPOS_1_TCP : 10:32:17:14 |Just before ISO8583_ANALYSE
> MPOS_1_TCP : 10:32:17:14 |Received New Message, let dump it
> MPOS_1_TCP : 10:32:17:14 |Dumping Hex Buffer Length = 37
> MPOS_1_TCP : 10:32:17:14 |08 00 22 20 00 00 00 80 00 10 93 00 00 00 00 00
> 00 00 00 01 .." ................
> MPOS_1_TCP : 10:32:17:14 |03 31 33 33 30 30 30 30 33 00 06 30 30 30 30 30
> 31 .13300003..000001
> MPOS_1_TCP : 10:32:17:14 |Message Format: POS ISO8583
> MPOS_1_TCP : 10:32:17:14 |Received Message Type is 0800
> MPOS_1_TCP : 10:32:17:14 |Type descriptor for [0800] is found
> MPOS_1_TCP : 10:32:17:14 |****** Bit [3] ON ******
> MPOS_1_TCP : 10:32:17:14 |Fixed Length Field with [6] Data Elements
> MPOS_1_TCP : 10:32:17:14 | Conversion from BCD
> MPOS_1_TCP : 10:32:17:14 |Field Content: [930000]*
>
Before we go further, are you absolutely certain MPOS_! and MPOS_2
connections are identical? The log entries look quite different to me!?!
For instance, where is the detail :-
"
*MPOS_1_TCP : 10:32:17:14 |Dumping Hex Buffer Length = 2
MPOS_1_TCP : 10:32:17:14 |00
2A
"
?
Can you get a POS to send to MPOS_2 to see if it works?
Are you seeking to replace a simulator solution with a jPOS solution?
I won't continue dissecting the MPOS_2 flow, I think it is handling the
traffic differently to MPOS_1 and I would like you to check if I am
right or not.
--
Mark
>
> I try to make transaction after that but still error .
I would hope it would be different with this configuration change?
> You understand about message lenth and TPDU is righ .
>
> Yes , TPDU is 5 bytes ... how do i send this value from Jpos ?
> this code is only declare ( i have just change this from 2 bytes to 5 bytes)
No, in fact you have made the TPDU 1 byte long containing x'05'
>
> *ISOChannel channel = new
> org.jpos.iso.channel.NCCChannel("10.36.10.73",9302,new
> way4POSPackager(),new byte[]{(byte)005});*
The 4th parameter is where you specify the *bytes* you want to send in
with the message as it's TPDU. It is *not* for specifying the length of
the TPDU at all. The above code will send a TPDU ox x'05', with the
MPOS_1 & 2 expecting a TPDU five bytes long, it will report a incorrect
MTI (perhaps 0000) and also complain about not enough data being
available or it might hang. I am only guessing of course.
I think this should be :-
ISOChannel channel = new
org.jpos.iso.channel.NCCChannel("10.36.10.73",9302,new
way4POSPackager(),new byte[]{(byte)0x60,(byte) 0x00,(byte) 0x02,(byte)
0xB7,(byte) 0x20});
Assuming the TPDU you want is x'600002B720' of course!
Does the content of the TPDU vary from connection to connection?
>
> Log after change mpos2 is exact same to mpos1:
>
> /MPOS_2_TCP : 16:47:57:45 |TCPLINKS: Set Socket to REUSE LOCAL ADDRESS MODE
> MPOS_2_TCP : 16:47:57:45 |E[001]: Waiting for new connect...
> MPOS_2_TCP : 16:47:57:49 |E[000]: Event on Socket [9]
> MPOS_2_TCP : 16:47:57:49 |E[000]: Received New [2] Bytes of Header on
> Socket [9].
> MPOS_2_TCP : 16:47:57:49 |E[000]: Complete Header [2] Received on
> Socket [9].
> MPOS_2_TCP : 16:47:57:49 |************* SOCKET DRIVER ACTIVE **********
> MPOS_2_TCP : 16:47:57:49 |TCPLINKS: RECEIVE Function Invoked
> MPOS_2_TCP : 16:47:57:49 |E[000]: New Event on Socket [9].
> MPOS_2_TCP : 16:47:57:49 |E[000]: Received New [67] Bytes of Data on
> Socket [9].
> MPOS_2_TCP : 16:47:57:49 |************* SOCKET DRIVER ACTIVE **********
> MPOS_2_TCP : 16:47:57:49 |TCPLINKS: RECEIVE Function Invoked
> MPOS_2_TCP : 16:47:57:54 |E[000]: New Event on Socket [9].
> MPOS_2_TCP : 16:47:57:54 |E[000]: Receive failed on msg data, Error = 131
> MPOS_2_TCP : 16:47:57:54 |Change Message ID to [2] on Entry [0]/
What does this "Error = 131" mean? Is it by chance indicating that the
length is greater than the bytes received?
Can you also confirm what you are seeking to replace with jPOS? Is it a
simulator you use in testing or the POS system/devices?
--
Mark
I try to make transaction after that but still error .
I would hope it would be different with this configuration change?
>
> I try the code but still error= 131 , i config the debug mode but log
> is no more .
Please check the message length format. I think your POS is sending
(and MPOS_2 is expecting) a binary length in two bytes, I think you are
sending a BCD length in two bytes.
This matters because...
If a message is 101 bytes long then the POS will send :-
x'0065600002B7200800....'
But, you would send :-
x'0101600002B7200800....'
The MPOS software will deal correctly with the length from POS, seeing
101 bytes and being able to read that many from the network.
Your message appears to MPOS to be x'0101' bytes long which if taken as
binary and converted to decimal is 257 bytes - much more than you are
sending. It will try and read 257 bytes from the network, get 101 and
then sit waiting for the rest to arrive.
This is probably why nothing is being logged as a whole message has not
arrived yet. To test this theory, keep sending messages down the MPOS_2
channel, eventually enough bytes will flow to fulfil the length
specified and logging will occur.
Using the 0800 message lengths shown so far, I calculate that you would
need to send two 0800 messages (without waiting for a response on the
first) through NCCChannel to MPOS_2 to generate enough bytes to satisfy
the number you have told MPOS_2 to expect.
Alternatively, do a trace (suggested a while ago), see what the POS
exchange looks like including the message length, then compare it to a
trace of your message.
Then change to NACChannel and see if things improve.
8)
>
> I try to write a EPOS for internal system that can do banlan inquiry ,
> ministament and fund tranfer with Jpos
I see, so interfacing with MPOS for other functions. I see, thanks.
--
Mark
The programmers guide has table 6.1 of Channels , on page 52 it gives
the details of both NACChannel and NCCChannel.
You may also have looked at the comments at the top of the source code:-
/**
* Talks with TCP based NCCs
* Sends [LEN][TPDU][ISOMSG]
* (len=2 bytes BCD)
*
* @author Alejandro P. Revilla
* @version $Revision: 2594 $ $Date: 2008-01-22 16:41:31 +0000 (Tue, 22
Jan 2008) $
* @see ISOMsg
* @see ISOException
* @see ISOChannel
*/
Whereas NACChannel has comments that read :-
/**
* Talks with TCP based NACs
* Sends [LEN][TPDU][ISOMSG]
* (len=2 bytes network byte order)
*
* @author Alejandro P. Revilla
* @version $Revision: 2667 $ $Date: 2008-11-06 10:13:44 +0000 (Thu, 06
Nov 2008) $
* @see ISOMsg
* @see ISOException
* @see ISOChannel
*/
Does that help you to make a choice?
What format does "MPOS_1" expect? How is your POS system specifying the
length into MPOS_1?
--
Mark