JPOS Channel

[SriEns]

Hi there,

I started working on JPOS since couple of weeks and now I am doing an
Integration testing with one of the Banks. I am using VAPChannel to
send the message and the message what they are receiving at their end
is something like below.

00000 00 16 01 01 00 32 00 00 00 00 00 00 00 00 00 00 | .....
2..........
00010 00 00 00 00 00 00 00 08 00 82 20 00 00 00 00 00
| .......... .....
00020 00 04 00 00 00 00 00 00 00 10 12 10 55 20 00 20
| ............U .
00030 84 00 01 00 32 00 00 16 01 01 00 32 00 00 00 00 | ....
2......2....
00040 00 00 00 00 00 00 00 00 00 00 00 00 00 08 00 82
| ................
00050 20 00 00 00 00 00 00 04 00 00 00 00 00 00 00 10
| ...............
00060 12 10 55 31 00 20 85 00 01 | ..U1. ...

In the above message first five digits are line numbers.

They say that they want the message in HEX format... Please suggest me
which channel I need to use to send the message in HEX-Format.

Thanks in advance.

rgds,
Sri

[Mark Salter]

SriEns wrote:
> Hi there,
>
> I started working on JPOS since couple of weeks and now I am doing an
> Integration testing with one of the Banks. I am using VAPChannel to
> send the message and the message what they are receiving at their end
> is something like below.

Are they expecting the Visa header, are you connecting to the 'Visa'
interface?

>
> 00000 00 16 01 01 00 32 00 00 00 00 00 00 00 00 00 00 | .....
> 2..........
> 00010 00 00 00 00 00 00 00 08 00 82 20 00 00 00 00 00
> | .......... .....
> 00020 00 04 00 00 00 00 00 00 00 10 12 10 55 20 00 20
> | ............U .
> 00030 84 00 01 00 32 00 00 16 01 01 00 32 00 00 00 00 | ....
> 2......2....
> 00040 00 00 00 00 00 00 00 00 00 00 00 00 00 08 00 82
> | ................
> 00050 20 00 00 00 00 00 00 04 00 00 00 00 00 00 00 10
> | ...............
> 00060 12 10 55 31 00 20 85 00 01 | ..U1. ...
>
> In the above message first five digits are line numbers.

No, they are actually the offset in the dump at which each line of data
starts.

>
> They say that they want the message in HEX format... Please suggest me
> which channel I need to use to send the message in HEX-Format.

This is far too vague to be a useful description to help pick a
packager, you need to ask them for more information, in fact ask them
for their interface specification.

--
Mark

[SriEns]

Hi Mark,

I think I am not very clear with my earlier message. I want to
rephrase it as below.

They asked me not to send the message header. So I configured it not
to send that.

We exchanged a Message Specs with a bank which says as below
Field Attr Format
Name values Remarks
Fixed N-4
Message Type 0800
Fixed B-16
Primary Bitmap
1 Fixed B-16
Secondary Bitmap Required if 65-128 are present
7 Fixed N-10
Transamission Dt & Tm
11 Fixed N-6 STAN
70 Fixed N-3 Network
id code 001 - sign-on; 002 - sign-off; 301
- Echo

So I used a VAP Channel and sent the message and below is the message
what it is being transmitted
08008220000000000000040000000000000010151313360136120001
So when separated it looks like this:
0800
8220000000000000
0400000000000000
1015131336 - Field 7
0136120 - Field 11
001 - Field 70

So i think I am sticking to the doc that is being exchanged.

They are able to read the message at their TCP layer as:

Message 1
Header (2 bytes) -->
00000 32 38 | 28
Data (28 bytes) -->
00000 08 00 82 20 00 00 00 00 00 00 04 00 00 00 00 00
| ... ............
00010 00 00 10 15 07 50 59 00 36 39 00 01
| .....PY.69..
#### End of the message dump (30 bytes) ####

But the bank says that they want the message as below.
30383030
38323230303030303030303030303030
30343030303030303030303030303030
31303135313332353034 - Field 7
303133363232 - Field 11
30303031 - Field 70

So now I want to know if I am sending correctly or not and also, if I
have to make changes at my end, then what I need to do to that in the
format they are expecting.

Thanks in advance.

Rgds,
Sri

[SriEns]

Hi Mark,

I actually want to add one more line to give you more details. The
Bank is using IST Switch.

Rgds,
Sri

On Oct 14, 8:20 pm, Mark Salter <marksal...@talktalk.net> wrote:

[Mark Salter]

SriEns wrote:
> They asked me not to send the message header. So I configured it not
> to send that.
>

This is why I wondered about you using VAPChannel - the header is
specific to a Visa interface. If you have stripped the header out of
VAPChannel, then you should probably be using one of the other ones
instead...

> We exchanged a Message Specs with a bank which says as below
> Field Attr Format
> Name values Remarks
> Fixed N-4
> Message Type 0800
> Fixed B-16
> Primary Bitmap
> 1 Fixed B-16
> Secondary Bitmap Required if 65-128 are present
> 7 Fixed N-10
> Transamission Dt & Tm
> 11 Fixed N-6 STAN
> 70 Fixed N-3 Network
> id code 001 - sign-on; 002 - sign-off; 301
> - Echo
>
> So I used a VAP Channel

You need to know that the Channel does not define the message structure
(field make up). The Packager does. A Channel just controls how the
message is wrapped for transmission over a network.

> and sent the message and below is the message
> what it is being transmitted
> 08008220000000000000040000000000000010151313360136120001

This should be :-

x'08008220000000000000040000000000000010151313360136120001'

> So when separated it looks like this:
> 0800
> 8220000000000000
> 0400000000000000
> 1015131336 - Field 7
> 0136120 - Field 11
> 001 - Field 70
>
> So i think I am sticking to the doc that is being exchanged.

Not truly; as I have indicated above (and you are about to show), you
are not sending character data, but a binary format.

>
> They are able to read the message at their TCP layer as:
>
> Message 1
> Header (2 bytes) -->
> 00000 32 38

The length in ASCII - 28 bytes follow, length is exclusive of length length.

| 28
> Data (28 bytes) -->
> 00000 08 00 82 20 00 00 00 00 00 00 04 00 00 00 00 00
> | ... ............
> 00010 00 00 10 15 07 50 59 00 36 39 00 01
> | .....PY.69..
> #### End of the message dump (30 bytes) ####
>
> But the bank says that they want the message as below.
> 30383030
> 38323230303030303030303030303030
> 30343030303030303030303030303030
> 31303135313332353034 - Field 7
> 303133363232 - Field 11
> 30303031 - Field 70
>
> So now I want to know if I am sending correctly or not and also, if I
> have to make changes at my end, then what I need to do to that in the
> format they are expecting.

You need to change or pick another Packager, as a starter, your MTI
(0800) should be using a field format of IFA_NUMERIC (or IF_CHAR), the
user guide (and this mailing list) hold the breakdown of the name
derivation/meaning...

If they like your 'network packet' then your Channel is correct (right
length format, structure and length value).

Your Packager selection/construction is where you need to focus.

--
Mark

[Mark Salter]

SriEns wrote:

> I actually want to add one more line to give you more details. The
> Bank is using IST Switch.

I'm not familiar with that, but it might be familiar to other people
here, thanks.

--
Mark

[enStage enStage]

Hi Mark,

Thanks for the prompt reply. I think I found out the issue and will surely update you if I could fix the problem. Let me give a try now...

Thanks & regards,
Sri

[SriEns]

Thanks a lot Mark... I followed your word to word and I could able to
see the message locally in the format what they are asking... I will
try to do the integration and see if more changes are required...
anyways, thanks a lot once again...

Cheers,
Sri

[Mark Salter]

SriEns wrote:
> Thanks a lot Mark... I followed your word to word and I could able to
> see the message locally in the format what they are asking... I will
> try to do the integration and see if more changes are required...
> anyways, thanks a lot once again...

Just wanted to ensure that you looked and adjust each field in your
messages - including the ones used in requests and responses?

I want to make sure you have not just done the MTI.

8)

--
Mark

[SriEns]

Hi Mark,

This is Sri again. The earlier solution worked fine but now when I am
trying to integrate with another bank switch I am doing everything
fine. the message is something like this...

30383030383232303030303030383030303030303034303030303030303030303030303031313235303930323435303339383431313132353039303234353034303031

Which is fine for the bank. Here the message length in decimal is 67.
As I am using ASCIIChannel, the message length is going as 0067. But
they are asking me to send the message length of (0067) base 10 as
(0043) base 16. Or message length could be sent as 3637. I tried all
channels but could not able to identify which one i have to use. Could
you please suggest me on this? Or am i going in wrong direction?

Thanks & regards,
Sri

[Mark Salter]

SriEns wrote:
> The earlier solution worked fine but now when I am
> trying to integrate with another bank switch I am doing everything
> fine. the message is something like this...
>
> 30383030383232303030303030383030303030303034303030303030303030303030303031313235303930323435303339383431313132353039303234353034303031
>
> Which is fine for the bank.

So they like your message content, but not the length format.

> Here the message length in decimal is 67.
> As I am using ASCIIChannel, the message length is going as 0067.

c'0067'?

> But
> they are asking me to send the message length of (0067) base 10 as
> (0043) base 16.

Still in character == c'0043'?

> Or message length could be sent as 3637.

This is the binary form of ascii c'67'.

So this bank can accept two length formats and you can choose? :-

1) a 4 byte ascii character length of the base 16 length - c'0043'
2) a 2 byte ascii character length of the base 10 length - c'67'

> I tried all
> channels but could not able to identify which one i have to use. Could
> you please suggest me on this?

I don't think either of these formats are available out of the box.

For either format, two simple modifications (copy into a new file first)
to the getMessageLength and sendMessageLength(int) methods in
ASCIIChannel.java should give you a Channel implementation that will
work for this bank.

Have a look at the ASCIIChannel.java source...
... if you can't work out what to modify then ask back here?

Please make sure you have both length formats clear in your mind - I
would like you to be sure that the 2 formats I numbered above accuratly
represent what you have told us?

--
Mark

[SriEns]

Hi Mark,

I did the following changes but looks like I am doing wrong:

1. Created a copy of ASCIIChannel.java as XYZChannel.java
2. In the file ISOUtil.java added two functions which convert
HexString to Decimal and Decimal to HexString
3. getMessageLength(Int) in XYZChannel.java has been modified as
below:
protected int getMessageLength() throws IOException, ISOException {
int finLen = 0;
String l = "";
byte[] b = new byte[4];
while (finLen == 0) {
serverIn.readFully(b,0,4);
l=new String(b);
finLen = ISOUtil.hex2decimal(l);
try {
if ((finLen=Integer.parseInt(finLen)) == 0) {
serverOut.write(b);
serverOut.flush();
}
} catch (NumberFormatException e) {
throw new ISOException ("Invalid header len "+new
String(b));
}
}
return finLen;
}
4. sendMessageLength(int) has been modified as below:
protected void sendMessageLength(int len) throws IOException {
String finLen = "";
if (len > 9999)
throw new IOException ("len exceeded");

finLen = ISOUtil.decimal2hex(len);

try {
serverOut.write(
ISOUtil.zeropad(finLen, 4).getBytes()
);
} catch (ISOException e) { }
}

Now the message length is 4 byte ascii character length of the base 16
length. But the actual message is also of same length and not of 67.
So the message is incomplete. Please let me know where I am doing
wrong.

Thanks & regards,
Sri

On Nov 25, 2:58 pm, Mark Salter <marksal...@talktalk.net> wrote:
> SriEns wrote:
> > The earlier solution worked fine but now when I am
> > trying to integrate with another bank switch I am doing everything
> > fine. the message is something like this...
>
> > 30383030383232303030303030383030303030303034303030303030303030303030303031313235303930323435303339383431313132353039303234353034303031
>
> > Which is fine for the bank.
>
> So they like your message content, but not the length format.
>
> > Here the message length in decimal is 67.
> > As I am using ASCIIChannel, the message length is going as 0067.
>
> c'0067'?
>
> > But
> > they are asking me to send the message length of (0067) base 10 as
> > (0043) base 16.
>

> Stillincharacter==c'0043'?

>
> > Or message length could be sent as 3637.
>
> This is the binary form of ascii c'67'.
>
> So this bank can accept two length formats and you can choose? :-
>

> 1) a 4 byte asciicharacterlength of the base 16 length -c'0043'
> 2) a 2 byte asciicharacterlength of the base 10 length - c'67'

[Mark Salter]

SriEns wrote:

> Now the message length is 4 byte ascii character length of the base 16
> length.

So you are happy with the length (and it's format)? I guess you are
happy with the code you posted then.

> But the actual message is also of same length and not of 67.
> So the message is incomplete.

We cannot see what you are now producing, nor can we seen what you think
it should look like, so...

> Please let me know where I am doing
> wrong.

How could we help?

I asked a number of question in my last reply, specifically about your
field definitions and packager, would you care to try and answer any of
them?

--
Mark

[Mark Salter]

Mark Salter wrote:
> I asked a number of question in my last reply,

Well this part is true!

> specifically about your field definitions and packager,

But this I confused with another thread.

--
Mark

[SriEns]

Hi Mark,

I couldn't make out that "?" are for questions for me. Sorry about
that. I am posting my answers to questions you posted.

SriEns wrote:
> The earlier solution worked fine but now when I am
> trying to integrate with another bank switch I am doing everything
> fine. the message is something like this...
>
> 30383030383232303030303030383030303030303034303030303030303030303030303031313235303930323435303339383431313132353039303234353034303031
>
> Which is fine for the bank.
>> So they like your message content, but not the length format.

Ans: Yes, they are happy with the message content but not the length

> Here the message length in decimal is 67.
> As I am using ASCIIChannel, the message length is going as 0067.
>> c'0067'?

Ans: Yes

> But
> they are asking me to send the message length of (0067) base 10 as
> (0043) base 16.

>> Still in character == c'0043'?

Ans: Yes, correct. But there will be problem if length in decimal
crosses 255. FF in Hex is 255 in Decimal. Then what?? I posted this
question to bank switch vendor and waiting for their reply.

> Or message length could be sent as 3637.
>> This is the binary form of ascii c'67'.

>> So this bank can accept two length formats and you can choose? :-

>> 1) a 4 byte ascii character length of the base 16 length - c'0043'

>> 2) a 2 byte ascii character length of the base 10 length - c'67'
Ans: Yes, but I would prefer the second format rather than the first
due to the above problem.

> I tried all
> channels but could not able to identify which one i have to use. Could
> you please suggest me on this?

>> I don't think either of these formats are available out of the box.

>> For either format, two simple modifications (copy into a new file first)
>> to the getMessageLength and sendMessageLength(int) methods in
>> ASCIIChannel.java should give you a Channel implementation that will
>> work for this bank.

>> Have a look at the ASCIIChannel.java source...
>> ... if you can't work out what to modify then ask back here?

>> Please make sure you have both length formats clear in your mind - I
>> would like you to be sure that the 2 formats I numbered above accuratly
>> represent what you have told us?

Ans: :) yes I looked at the ASCIIChannel and tried to modify it. But
could not make out what I am doing wrong.

Thanks & regards,

Sri

On Nov 30, 1:05 pm, Mark Salter <marksal...@talktalk.net> wrote:
> SriEnswrote:

[Mark Salter]

SriEns wrote:

> I couldn't make out that "?" are for questions for me. Sorry about
> that. I am posting my answers to questions you posted.

Great.

> SriEns wrote:
>> The earlier solution worked fine but now when I am
>> trying to integrate with another bank switch I am doing everything
>> fine. the message is something like this...
>>
>> 30383030383232303030303030383030303030303034303030303030303030303030303031313235303930323435303339383431313132353039303234353034303031
>>
>> Which is fine for the bank.
>>> So they like your message content, but not the length format.
> Ans: Yes, they are happy with the message content but not the length

Ok.

>
>
>> Here the message length in decimal is 67.
>> As I am using ASCIIChannel, the message length is going as 0067.
>>> c'0067'?
> Ans: Yes

Ok again.

>> But
>> they are asking me to send the message length of (0067) base 10 as
>> (0043) base 16.
>>> Still in character == c'0043'?
> Ans: Yes, correct. But there will be problem if length in decimal
> crosses 255. FF in Hex is 255 in Decimal. Then what?? I posted this
> question to bank switch vendor and waiting for their reply.

If you exceed FF - possibly unlikely - then you start using the other
place holder digits:-

Decimal c'xxxx' - x==hexadecimal==base16

255 00FF
256 0100
65535 FFFF

>
>> Or message length could be sent as 3637.
>>> This is the binary form of ascii c'67'.
>
>>> So this bank can accept two length formats and you can choose? :-
>
>>> 1) a 4 byte ascii character length of the base 16 length - c'0043'
>>> 2) a 2 byte ascii character length of the base 10 length - c'67'
> Ans: Yes, but I would prefer the second format rather than the first
> due to the above problem.

The first format gives you much greater message length support, the
second limits you to messages 99 bytes in length.

I suspect you would want format 1 - for future expansion - but imagine
that if the bank support the second format, then messages longer than 99
bytes are not currently expected (as they could not be supported).

>>> Have a look at the ASCIIChannel.java source...
>>> ... if you can't work out what to modify then ask back here?
>
>>> Please make sure you have both length formats clear in your mind - I
>>> would like you to be sure that the 2 formats I numbered above accuratly
>>> represent what you have told us?
>
> Ans: :) yes I looked at the ASCIIChannel and tried to modify it. But
> could not make out what I am doing wrong.

Some examples of what you are now producing will save me trying to
generate some test ones? A picture paints a thousand words.

8)

--
Mark

[SriEns]

Hi Mark,

Thanks a lot... I worked on the idea what you have provided in the
initial mail and I could get that worked locally. And I could achieve
4 byte ascii character length of the base 16 length. I hope that I
will be able to get this worked with the switch also. The procedure
what I used is already posted in one of my earlier mails and I am
posting it here once again.

1. made a copy of ASCIIChannel

2. In the file ISOUtil.java added two functions which convert
HexString to Decimal and Decimal to HexString

3. While sending and just after reading I am doing the conversion of
dec to hex and hex to decimal.

thanks once again for the suggestion. :)

Cheers Sri

[Mark Salter]

SriEns wrote:

> Thanks a lot... I worked on the idea what you have provided in the
> initial mail and I could get that worked locally. And I could achieve
> 4 byte ascii character length of the base 16 length. I hope that I
> will be able to get this worked with the switch also. The procedure
> what I used is already posted in one of my earlier mails and I am
> posting it here once again.

I'm not really interested in what you have done, I am interested in
knowing what you think is still wrong?

I'll respond to your previous reply to highlight what detail we need to
be able to help.

--
Mark

[Mark Salter]

SriEns wrote:

> I did the following changes but looks like I am doing wrong:
>
> 1. Created a copy of ASCIIChannel.java as XYZChannel.java

Ok.

> 2. In the file ISOUtil.java added two functions which convert
> HexString to Decimal and Decimal to HexString

Are you sure these new (invisible) functions are working correctly? How
would I know this?

> Now the message length is 4 byte ascii character length of the base
> 16 length.

Ok I think.

> But the actual message is also of same length and not of 67.

Sorry? What length does it have then? Should it be 67 *including* the
length bytes or without?

> So the message is incomplete.

Incomplete in what way please?

> Please let me know where I am doing wrong.

I can't see what is happening, so cannot let you know, I can only guess.
We are completely reliant on you providing detail of what you have
currently and what you want, highlighting where the problems are - and
perhaps how you know there is a problem?

Please note that few people will even look at posted code, let alone
look for bugs in it. The new methods you have added to ISOUtil are of
course invisible to me.

I'm holding off posting my favourite url...

... 8)

--
Mark

[SriEns]

Hi Mark,

Please find my answers below

> But the actual message is also of same length and not of 67.

Sorry? What length does it have then? Should it be 67 *including* the
length bytes or without?

Ans: I was not clear in my earlier post. Also I did a mistake and
thought that jpos is giving me trouble. When I converted the message
length from 67 to 43 and sent the message, the outgoing message is
fine. But while I was trying to read the message at the dummy switch
internally, I was not converting the length back properly, so it is
still getting 43 only and it was considering the message should be of
43 but it was receiving 67. So it was giving exception. I figured it
out and fixed and now it could able to read the message properly.

> So the message is incomplete.

Incomplete in what way please?

Ans: actually it isn't, as explained earlier it was my java coding
error

The new methods you have added to ISOUtil are of course invisible to
me.

Ans: ISOUtil methods added are here.
=================================================================
public static int hex2decimal(String s) {
String digits = "0123456789ABCDEF";
s = s.toUpperCase();
int val = 0;
for (int i = 0; i < s.length(); i++) {
char c = s.charAt(i);
int d = digits.indexOf(c);
val = 16*val + d;
}
return val;
}

// precondition: d is a nonnegative integer
public static String decimal2hex(int d) {
String digits = "0123456789ABCDEF";
if (d == 0) return "0";
String hex = "";
while (d > 0) {
int digit = d % 16; // rightmost digit
hex = digits.charAt(digit) + hex; // string concatenation
d = d / 16;
}
return hex;
}
public static String decimal2hex(String d) {
String digits = "0123456789ABCDEF";
int dd = Integer.parseInt(d);
if (dd == 0) return "0";
String hex = "";
while (dd > 0) {
int digit = dd % 16; // rightmost digit
hex = digits.charAt(digit) + hex; // string concatenation
dd = dd / 16;
}
return hex;
}
=================================================================

I am posting that code here of XYZChannel which is fixed now.
=================================================================

protected void sendMessageLength(int len) throws IOException {
String finLen = "";

if (len > 9999)
throw new IOException ("len exceeded");

finLen = ISOUtil.decimal2hex(""+len);

try {
if(finLen.length() < 4 ){
finLen = ISOUtil.zeropad(finLen, 4);
}
} catch (ISOException e) {}

System.out.println("finlen = "+finLen);
serverOut.write(finLen.getBytes());

}
/**
* @return the Message len
* @exception IOException, ISOException
*/

protected int getMessageLength() throws IOException, ISOException
{

int finLen = 0, len = 0;

String l = "";
byte[] b = new byte[4];
while (finLen == 0) {
serverIn.readFully(b,0,4);
l=new String(b);

System.out.println("length in Hex is: "+l);
finLen = ISOUtil.hex2decimal(l);
System.out.println("length in Decimal is: "+finLen);
try {
if ((len=ISOUtil.hex2decimal(l)) == 0) {

serverOut.write(b);
serverOut.flush();
}
} catch (NumberFormatException e) {
throw new ISOException ("Invalid header len "+new
String(b));
}
}
return finLen;
}

=================================================================

Please let me know if I am missing any info in this post.

cheers, sri

[Mark Salter]

SriEns wrote:
> Please let me know if I am missing any info in this post.
>

I think you are good, thanks for coming back.

Nice that you found and resolved your problem on the way.

Regards,

--
Mark