Issue while parsing ISO 8583 Response message.

1,005 views
Skip to first unread message

ccav tech

unread,
Jul 3, 2019, 7:26:38 AM7/3/19
to jPOS Users
Hi All,

I am having an issue while unpacking the ISO response which I got from the network.

Response;
013F30313130EFBFBD3E44EFBFBD0AEFBFBDEFBFBD00000000000000002231363432383936393736343839323837353930303030303330303030303030303030303030373033313634313538313035373932313634313538303332313234303730343139353639313031323038433030303030303030433030303030303030303634353438393939303835303731303537393031343030303530303431303237313734202020202020202020434F4D4D45524349414C38333630447562616941454145202020202020202020202020202020202037383430323030303533373834433030303030303030303030303031353130303033303130343030303030303030303036372400100400000000414459454E535243202020204D4243534E4B2020202020203130353739323130353739324D42435255414554472020203131323031393037303320
 here the first four digits (013F) are indicating response length.
I am getting below exception stack trace:

Exception in thread "main" org.jpos.iso.ISOException: org.jpos.iso.IFA_LLNUM: Problem unpacking field 2 (java.lang.NegativeArraySizeException) unpacking field=2, consumed=20
at org.jpos.iso.ISOBasePackager.unpack(ISOBasePackager.java:340)
at org.jpos.iso.ISOMsg.unpack(ISOMsg.java:468)
at com.isov2.TestISO.TestRespnse.main(TestRespnse.java:89)

Below are the JPOS Rules:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE isopackager PUBLIC
        "-//jPOS/jPOS Generic Packager DTD 1.0//EN"
        "http://jpos.org/dtd/generic-packager-1.0.dtd">
<isopackager>
  <isofield
      id="0"
      length="4"
      name="MESSAGE TYPE INDICATOR"
      class="org.jpos.iso.IFA_NUMERIC"/>
  <isofield
      id="1"
      length="16"
      name="BIT MAP"
      class="org.jpos.iso.IFB_BITMAP"/>
  <isofield
      id="2"
      length="19"
      name="PAN - PRIMARY ACCOUNT NUMBER"
      class="org.jpos.iso.IFA_LLNUM"/>
  <isofield
      id="3"
      length="6"
      name="PROCESSING CODE"
      class="org.jpos.iso.IFA_NUMERIC"/>
  <isofield
      id="4"
      length="12"
      name="AMOUNT, TRANSACTION"
      class="org.jpos.iso.IFA_NUMERIC"/>
  <isofield
      id="7"
      length="10"
      name="TRANSMISSION DATE AND TIME"
      class="org.jpos.iso.IFA_NUMERIC"/>
      <isofield id="8" length="8" name="AMOUNT, CARDHOLDER BILLING FEE" class="org.jpos.iso.IFA_NUMERIC"/>
          <isofield id="9" length="8" name="CONVERSION RATE, SETTLEMENT" class="org.jpos.iso.IFA_NUMERIC"/>
  <isofield
      id="11"
      length="6"
      name="SYSTEM TRACE AUDIT NUMBER"
      class="org.jpos.iso.IFA_NUMERIC"/>
  <isofield
      id="12"
      length="6"
      name="TIME, LOCAL TRANSACTION"
      class="org.jpos.iso.IFA_NUMERIC"/>
  <isofield
      id="13"
      length="4"
      name="DATE, LOCAL TRANSACTION"
      class="org.jpos.iso.IFA_NUMERIC"/>
  <isofield
      id="14"
      length="4"
      name="DATE, EXPIRATION"
      class="org.jpos.iso.IFA_NUMERIC"/>
  <isofield id="15" length="4" name="DATE, SETTLEMENT" class="org.jpos.iso.IFA_NUMERIC"/>
  <isofield id="17" length="4" name="DATE, CAPTURE" class="org.jpos.iso.IFA_NUMERIC"/>
  <isofield
      id="18"
      length="4"
      name="MERCHANTS TYPE"
      class="org.jpos.iso.IFA_NUMERIC"/>
  <isofield id="19" length="3" name="ACQUIRING INSTITUTION COUNTRY CODE" class="org.jpos.iso.IFA_NUMERIC"/>
  <isofield id="20" length="3" name="PAN EXTENDED COUNTRY CODE" class="org.jpos.iso.IFA_NUMERIC"/>
 
  <isofield id="21" length="3" name="FORWARDING INSTITUTION COUNTRY CODE" class="org.jpos.iso.IFA_NUMERIC"/>
  <isofield
      id="22"
      length="3"
      name="POINT OF SERVICE ENTRY MODE"
      class="org.jpos.iso.IFA_NUMERIC"/>
  <isofield id="23" length="3" name="CARD SEQUENCE NUMBER" class="org.jpos.iso.IFA_NUMERIC"/>
  <isofield id="24" length="3" name="NETWORK INTERNATIONAL IDENTIFIEER" class="org.jpos.iso.IFA_NUMERIC"/>
  <isofield
      id="25"
      length="2"
      name="POINT OF SERVICE CONDITION CODE"
      class="org.jpos.iso.IFA_NUMERIC"/>
      <isofield id="27" length="1" name="AUTHORIZATION IDENTIFICATION RESP LEN" class="org.jpos.iso.IFA_NUMERIC"/>
  <isofield id="28" length="9" name="AMOUNT, TRANSACTION FEE" class="org.jpos.iso.IFA_AMOUNT"/>
  <isofield id="29" length="9" name="AMOUNT, SETTLEMENT FEE" class="org.jpos.iso.IFA_AMOUNT"/>
  <isofield id="30" length="9" name="AMOUNT, TRANSACTION PROCESSING FEE" class="org.jpos.iso.IFA_AMOUNT"/>
   <isofield id="31" length="9" name="AMOUNT, SETTLEMENT PROCESSING FEE" class="org.jpos.iso.IFA_AMOUNT"/>
  <isofield
      id="32"
      length="11"
      name="ACQUIRING INSTITUTION IDENT CODE"
      class="org.jpos.iso.IFA_LLNUM"/>
  <isofield id="33" length="11" name="FORWARDING INSTITUTION IDENT CODE" class="org.jpos.iso.IFA_LLNUM"/>
  <isofield id="34" length="28" name="PAN EXTENDED" class="org.jpos.iso.IFA_LLCHAR"/>
  <isofield id="35" length="37" name="TRACK 2 DATA" class="org.jpos.iso.IFA_LLNUM"/>
  <isofield id="36" length="104" name="TRACK 3 DATA" class="org.jpos.iso.IFA_LLLCHAR"/>
  <isofield
      id="37"
      length="12"
      name="RETRIEVAL REFERENCE NUMBER"
      class="org.jpos.iso.IF_CHAR"/>
      <isofield id="38" length="6" name="AUTHORIZATION IDENTIFICATION RESPONSE" class="org.jpos.iso.IF_CHAR"/>
  <isofield id="39" length="2" name="RESPONSE CODE" class="org.jpos.iso.IF_CHAR"/>
  <isofield
      id="41"
      length="8"
      name="CARD ACCEPTOR TERMINAL IDENTIFICACION"
      class="org.jpos.iso.IF_CHAR"/>
     
  <isofield
      id="42"
      length="15"
      name="CARD ACCEPTOR IDENTIFICATION CODE"
      class="org.jpos.iso.IF_CHAR"/>
  <isofield
      id="43"
      length="40"
      name="CARD ACCEPTOR NAME/LOCATION"
      class="org.jpos.iso.IF_CHAR"/>
   <isofield id="44" length="25" name="ADITIONAL RESPONSE DATA" class="org.jpos.iso.IFA_LLCHAR"/>
  <isofield
      id="49"
      length="3"
      name="CURRENCY CODE, TRANSACTION"
      class="org.jpos.iso.IFA_NUMERIC"/>
   <isofield id="54" length="120" name="ADDITIONAL AMOUNTS" class="org.jpos.iso.IFA_LLLCHAR"/>
  <isofield
      id="123"
      length="999"
      name="RESERVED PRIVATE USE"
      class="org.jpos.iso.IFA_LLLCHAR"/>
 
  <isofieldpackager
      id="127"  
      length="999999"
      name="RESERVED PRIVATE USE"
      class="org.jpos.iso.IFA_LLLLLLBINARY"
      packager="org.jpos.iso.packager.GenericSubFieldPackager">
     <isofield
    id="0"
    length="0"
    name="Placeholder"
    class="org.jpos.iso.IF_NOP" />
<isofield
    id="1"
    length="16"
    name="Bit Map"
    class="org.jpos.iso.IFA_BITMAP" />
     <isofield
          id="38"
          length="99"
          name="Additional POS Data Code"
          class="org.jpos.iso.IFA_LLCHAR"/>    
     
  </isofieldpackager>

  </isopackager>

Java code for parsing the response:

GenericPackager packager = new GenericPackager("src/main/resources/basic.xml");
ISOMsg respMsg = new ISOMsg();
respMsg.setPackager(packager);
String isoMsg="30313130EFBFBD3E44EFBFBD0AEFBFBDEFBFBD00000000000000002231363432383936393736343839323837353930303030303330303030303030303030303030373033313634313538313035373932313634313538303332313234303730343139353639313031323038433030303030303030433030303030303030303634353438393939303835303731303537393031343030303530303431303237313734202020202020202020434F4D4D45524349414C38333630447562616941454145202020202020202020202020202020202037383430323030303533373834433030303030303030303030303031353130303033303130343030303030303030303036372400100400000000414459454E535243202020204D4243534E4B2020202020203130353739323130353739324D42435255414554472020203131323031393037303320".;
byte[] bytes = ISOUtil.hex2byte(isoMsg);
respMsg.unpack(bytes);
printISOMessage(respMsg);

printISOMessage method:

for (int i = 1; i <= isoMsg.getMaxField(); i++) {
if (isoMsg.hasField(i)) {
System.out.printf("Field (%s) = %s%n", i, isoMsg.getString(i));
}

Hex dump of the response message:

0000(0000)  30 31 31 30 f2 3e 44 95  0a e0 84 00 00 00 00 00   0110.>D.........
0016(0010)  00 00 00 22 31 36 34 32  38 39 36 39 37 36 34 38   ..."164289697648
0032(0020)  39 32 38 37 35 39 30 30  30 30 30 33 30 30 30 30   9287590000030000
0048(0030)  30 30 30 30 30 30 30 30  30 37 30 33 31 36 31 33   0000000007031613
0064(0040)  32 34 31 30 35 37 39 32  31 36 31 33 32 34 30 33   2410579216132403
0080(0050)  32 31 32 34 30 37 30 34  31 39 35 36 39 31 30 31   2124070419569101
0096(0060)  32 30 38 43 30 30 30 30  30 30 30 30 43 30 30 30   208C00000000C000
0112(0070)  30 30 30 30 30 30 36 34  35 34 38 39 39 39 30 38   0000006454899908
0128(0080)  35 30 37 31 30 35 37 39  30 31 34 30 30 30 35 30   5071057901400050
0144(0090)  30 34 31 30 32 37 31 37  34 20 20 20 20 20 20 20   041027174       
0160(00a0)  20 20 43 4f 4d 4d 45 52  43 49 41 4c 38 33 36 30     COMMERCIAL8360
0176(00b0)  44 75 62 61 69 41 45 41  45 20 20 20 20 20 20 20   DubaiAEAE       
0192(00c0)  20 20 20 20 20 20 20 20  20 20 37 38 34 30 32 30             784020
0208(00d0)  30 30 35 33 37 38 34 43  30 30 30 30 30 30 30 30   0053784C00000000
0224(00e0)  30 30 30 30 30 31 35 31  30 30 30 33 30 31 30 34   0000015100030104
0240(00f0)  30 30 30 30 30 30 30 30  30 30 36 37 24 00 10 04   000000000067$...
0256(0100)  00 00 00 00 41 44 59 45  4e 53 52 43 20 20 20 20   ....ADYENSRC    
0272(0110)  4d 42 43 53 4e 4b 20 20  20 20 20 20 31 30 35 37   MBCSNK      1057
0288(0120)  39 32 31 30 35 37 39 32  4d 42 43 52 55 41 45 54   92105792MBCRUAET

                        0304(0130)  47 20 20 20 31 31 32 30  31 39 30 37 30 33 20      G   1120190703


Please help.

chhil

unread,
Jul 3, 2019, 8:25:40 AM7/3/19
to jpos-...@googlegroups.com
In the bold text after Response;  you have a problems, there is a 013F30, so it wont parse at all. Usually you get a 3F which is a "?" when you dont obey the encopding / charset rules and do a string.getbytes or any api that takes a charset , you dont pass it in, java takes the default system charset and cannot fine the associated char for that byte and uses a ? or 3F. Or it just might be a copy paste error/ typo.
The message text string  in your java code won't parse and throw the exception because your bitmap format is not right.

 <unpack>
    30313130EFBFBD3E44EFBFBD0AEFBFBDEFBFBD00000000000000002231363432383936393736343839323837353930303030303330303030303030303030303030373033313634313538313035373932313634313538303332313234303730343139353639313031323038433030303030303030433030303030303030303634353438393939303835303731303537393031343030303530303431303237313734202020202020202020434F4D4D45524349414C38333630447562616941454145202020202020202020202020202020202037383430323030303533373834433030303030303030303030303031353130303033303130343030303030303030303036372400100400000000414459454E535243202020204D4243534E4B2020202020203130353739323130353739324D42435255414554472020203131323031393037303320
    <bitmap>{1, 2, 3, 5, 6, 7, 8, 9, 11, 12, 13, 14, 15, 16, 17, 19, 20, 21, 22, 24, 27, 28, 29, 30, 31, 34, 38, 41, 42, 43, 45, 46, 47, 48, 49, 51, 52, 53, 54, 55, 56, 57, 59, 60, 61, 62, 64, 69, 71, 73, 74, 75, 77, 78, 79, 80, 81, 83, 84, 85, 86, 87, 88, 89, 91, 92, 93, 94, 96, 97, 98, 99, 101, 102, 103, 104, 105, 107, 108, 109, 110, 111, 112, 113, 115, 116, 117, 118, 120}</bitmap>
    error unpacking field 2 consumed=20
    <iso-exception>
      org.jpos.iso.IFA_LLNUM: Problem unpacking field 2
      <nested-exception>
      java.lang.NegativeArraySizeException

Then you have a hexdump at the end, I dont know where that came from but its based on the packager you have so it parses correctly.

<isomsg direction="none">
  <!-- org.jpos.iso.packager.GenericPackager[C:\cfg\basic.xml] -->
  <field id="0" value="0110"/>
  <field id="bitmap" value="{1, 2, 3, 4, 7, 11, 12, 13, 14, 15, 18, 22, 25, 28, 30, 32, 37, 39, 41, 42, 43, 49, 54, 123, 127}" type="bitmap"/>
  <field id="2" value="4289697648928759"/>
  <field id="3" value="000003"/>
  <field id="4" value="000000000000"/>
  <field id="7" value="0703161324"/>
  <field id="11" value="105792"/>
  <field id="12" value="161324"/>
  <field id="13" value="0321"/>
  <field id="14" value="2407"/>
  <field id="15" value="0419"/>
  <field id="18" value="5691"/>
  <field id="22" value="012"/>
  <field id="25" value="08"/>
  <field id="28" value="C00000000"/>
  <field id="30" value="C00000000"/>
  <field id="32" value="454899"/>
  <field id="37" value="908507105790"/>
  <field id="39" value="14"/>
  <field id="41" value="00050041"/>
  <field id="42" value="027174         "/>
  <field id="43" value="COMMERCIAL8360DubaiAEAE                 "/>
  <field id="49" value="784"/>
  <field id="54" value="0053784C000000000000"/>
  <field id="123" value="100030104000000"/>
  <isomsg id="127">
    <!-- org.jpos.iso.packager.GenericSubFieldPackager -->
    <field id="38" value="5792105792"/>
  </isomsg>
</isomsg>
-chhil

--
--
jPOS is licensed under AGPL - free for community usage for your open-source project. Licenses are also available for commercial usage. Please support jPOS, contact: sa...@jpos.org
---
You received this message because you are subscribed to the Google Groups "jPOS Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jpos-users+...@googlegroups.com.
To post to this group, send email to jpos-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jpos-users/CAOfY%3Dj9ts3aso2FtdC7iyJqCK2ScaMPALAf436-MWWviUaMhRA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Victor Salaman

unread,
Jul 3, 2019, 8:28:30 AM7/3/19
to 'Ruchira Biyani' via jPOS Users
I really hope that the PAN and EXP are from a test card... :(

chhil

unread,
Jul 3, 2019, 8:30:23 AM7/3/19
to jpos-...@googlegroups.com
On Amazon trying it out :P

-chhil

ccav tech

unread,
Jul 3, 2019, 8:45:58 AM7/3/19
to jPOS Users
the hex dump is not with reference to the mentioned jpos rules its from client.
I just send you the actual response send from them with hex dump message.

chhil

unread,
Jul 3, 2019, 9:37:33 AM7/3/19
to jpos-...@googlegroups.com
The 013F is in all likelihood the 2 byte length header.
If you are using the nacchannel, then it comes to
byte b[] = { 0x01, 0x3F };
        int length = (((b[0]) & 0xFF) << 8) | ((b[1]) & 0xFF);
Thats comes to 319. That still doesn't match the size of the hex data that follows.


The actual response bitmap is different from the bitmap you have shown in the bold response that has the 3F.
Your hexdata (with the 3F) where did you get that from? How did you dump it?

-chhil


ccav tech

unread,
Jul 4, 2019, 12:08:06 AM7/4/19
to jPOS Users
Hi Chhil,

I don't think I am using the right code to retrieve the response from the network.

below is the sample java code which I am using to get the response from network.

Java code for getting response from network:

   Socket connection = new Socket("IP", Port);
   InputStream is = connection.getInputStream();
   byte[] buffer = new byte[1024];
   int read;
   
   while((read = is.read(buffer)) != -1) {
       String output = new String(buffer, 0, read);
       System.out.print(ISOUtil.hexString(output.getBytes()));
   };

Response which we are receiving:

013F30313130EFBFBD3E44EFBFBD0AEFBFBDEFBFBD00000000000000002231363432383936393736343839323837353930303030303330303030303030303030303030373033313634313538313035373932313634313538303332313234303730343139353639313031323038433030303030303030433030303030303030303634353438393939303835303731303537393031343030303530303431303237313734202020202020202020434F4D4D45524349414C38333630447562616941454145202020202020202020202020202020202037383430323030303533373834433030303030303030303030303031353130303033303130343030303030303030303036372400100400000000414459454E535243202020204D4243534E4B2020202020203130353739323130353739324D42435255414554472020203131323031393037303320

I tried with some other code as well but I am getting the exact response which was sent by my client (The Hex Dump Message Mentioned in the above mail ) which I supposed to get.

Socket connection = new Socket("IP", Port);
byte[] arrOutut = new byte[4096];
int count = connection.getInputStream().read(arrOutut, 0, 4096);

StringBuffer clientRequest = new StringBuffer();
for (int outputCount =4; outputCount < count; outputCount++)
{
char response = (char)arrOutut[outputCount];

clientRequest = clientRequest.append(response);
System.out.println("Each Char present in response :: "+clientRequest);
}
System.out.println(clientRequest);
connection.close();

Could you please help me with code that I can use to get the response from the network.



chhil

unread,
Jul 4, 2019, 2:17:37 AM7/4/19
to jpos-...@googlegroups.com
You are reinventing the wheel by implementing your own tcp data gathering, not realizing how it will impact your project when you want to multiplex multiple request responses and blocking. I suggest again, go through the jpos dev guide and use jpos to its potential.
There are jpos channels you should use. 
Your current problem is related to understanding that the messages have some header to indicate its length of the data to follow. There may be a 2 byte header that gives you the length (I believe you are talking to a postilion system, and postilion messages put a 2 byte length header).
Please pass the charset in the string constructor and string messages. JPOS uses StandardCharsets.ISO_8859_1 which I have found to be safe for the regions I interact with https://github.com/jpos/jPOS/blob/master/jpos/src/main/java/org/jpos/iso/ISOUtil.java#L74  
I had mentioned charset usage in my earlier response.

-chhil

ccav tech

unread,
Jul 11, 2019, 7:43:11 AM7/11/19
to jPOS Users
Hi Chhil ,

Here I am looking so many ways to read response string from socket connection but as we observed here we are not able to get proper data.

Here we are using Java technology and below snippet code to read data from socket stream.
Socket connection = new Socket("IP", Port);
   InputStream is = connection.getInputStream();
   byte[] buffer = new byte[1024];
   int read;
   
   while((read = is.read(buffer)) != -1) {
       String output = new String(buffer, 0, read);
       System.out.print(ISOUtil.hexString(output.getBytes()));
   };

As you suggested we have to use  <b>jpos channels </b> so we are trying to find out but not bale to understand which channel we can use here so if possible can you help me out for the same. here we are providing our JPOS rule xml that we are using to pack/unpack of data stream. I am also proving here my vendor specification details to get more information about the package.

"<b>In order to unpack a message received from the PostBridge interface it is necessary to check that
every field present in the message conforms to the relevant fields' content specifications i.e. each field
has pre-defined specifications for the length, format and type of packing that field content must have. If
the field conforms to the specification, it can be unpacked; else an exception should be raised.
The byte array that is received from a network device is unpacked by referring to the bitmap field that
indicates which fields are present in the message. Fields are unpacked sequentially, starting at the
first field in the byte array. The length indicator associated with a field, that precedes the field content
in the byte array, indicates whether a field is a fixed length field or a variable length field. A check
should be made as to whether the length indicator received in the byte array for a specific field,
corresponds to the one defined by the ISO 8583 standard. If this is the case, the number of bytes
equal to the length of the field can be extracted from the byte array, and these bytes can then be
checked against the format and packing specifications for the field in question.
The format and packing specifications are determined by the ISO 8583 standard. The standard
specifies that the format of the content of message fields must conform to the format class which is
PostBridge Interface Specification Version 8Implementation
8
pre-defined for each message field. Examples of ISO 8583 format classes are 'numeric',
'alphanumeric', 'binary' etc.
The packing specification specifies how a message field is packed (or encoded) into a byte array.
Examples of packing specifications are the Hexadecimal or Base64 packing methods (these methods
are typically used for the encoding of binary data into the ASCII text representation).
The following code shows how a byte array received from a network device could be processed:
for (all fields in message from postbridge as indicated in bitmap component(s))
{
if(isLengthIndicatorValid(msg_from_postbridge, offset, field_num))
{
field_length = getLength(msg_from_postbridge, offset, field_num)
if(isPackingValid(msg_from_postbridge, offset, field_num, field_length) &&
isFormatValid(msg_from_postbridge, offset, field_num, field_length))
{
message_fields[field_num++] = getField(msg_from_postbridge, offset, field_length)
offset += field_length
}
else
{
throw exception
}
}
else
{
throw exception
}
}
The 'msg_from_postbridge' variable holds a byte array with the message as received from the network
device. The 'offset' variable holds the index in the byte array where the next message field to be
processed starts. The 'field_num' variable holds the number of the field being processed as specified
by the ISO 8583 standard.
The code iterates through all the fields in the message. The code checks the length, format and
packing of each field. The length indicator is firstly checked for validity. If the indicator is valid, the field
length is extracted from the byte array, else an exception is thrown. Now that the field length is known,
the format and packing of the field can be checked. If both of these are valid, the field is extracted and
stored in an array, and the offset variable is incremented by the field length. If either the format or
packing of the field is invalid, an exception is thrown."</b>

Here we are providing the our JPOS Rule.
      <isofield id="5" length="12" name="AMOUNT, SETTLEMENT" class="org.jpos.iso.IFA_NUMERIC"/>
  <isofield id="16" length="4" name="DATE, CONVERSION" class="org.jpos.iso.IFA_NUMERIC"/>
    <!-- <isofield
    id="3"

    length="16"
    name="Bit Map"
    class="org.jpos.iso.IFA_BITMAP" />
    <isofield
    id="6"

    length="16"
    name="Bit Map"
    class="org.jpos.iso.IFA_BITMAP" />
    <isofield
    id="20"

    length="16"
    name="Bit Map"
    class="org.jpos.iso.IFA_BITMAP" />
    <isofield
    id="30"

    length="16"
    name="Bit Map"
    class="org.jpos.iso.IFA_BITMAP" /> -->

     <isofield
          id="38"
          length="99"
          name="Additional POS Data Code"
          class="org.jpos.iso.IFA_LLCHAR"/>    
     
  </isofieldpackager>

  </isopackager>

Looking forward your suggestion and help to get resolved my JPOS parsing issue.



chhil

unread,
Jul 11, 2019, 8:26:01 AM7/11/19
to jpos-...@googlegroups.com
Note: This is not the way to use JPOS.
I am simply trying to give you an idea. The right way is to deploy channel adaptors that replace the hard coded channels in java code.
package jpos.test;

import java.io.IOException;

import org.jpos.iso.ISOException;
import org.jpos.iso.ISOMsg;
import org.jpos.iso.ISOUtil;
import org.jpos.iso.channel.NACChannel;
import org.jpos.iso.packager.GenericPackager;
import org.jpos.util.Logger;
import org.jpos.util.SimpleLogListener;

public class Main {

    public static void main(String[] args) throws ISOException, IOException {

        Logger l = new Logger();
        l.addListener(new SimpleLogListener());
        GenericPackager postPackager = new GenericPackager("replace with path to packager");
        NACChannel channel = new NACChannel("put host IP here", put host port int here, postPackager, null);

        channel.connect();

        ISOMsg postBridgeISO = channel.receive();

        postBridgeISO.dump(System.out, "");
        System.out.println(ISOUtil.hexdump(postBridgeISO.getBytes()));

    }
}

-chhil

ccav tech

unread,
Jul 12, 2019, 2:37:46 AM7/12/19
to jPOS Users
Hi Chhil,

How would I know which channel I need to use to post the ISO message??
Is this depends on the JPOS rules which we define or what.
Bit confused on this .

For my case, we are sending the request to Postilion.

I have already searched about the HEXchannel which internally adds 4byte length (i.e the length of the request stream) which is the exact requirement of our vendor.
But while using the HEXChannel I am not receiving any response.

So could you please help me out in this

chhil

unread,
Jul 12, 2019, 3:48:00 AM7/12/19
to jpos-...@googlegroups.com
You have to read the spec  provided by Postilion for the interface you are connecting to and determine the channel to use. Either you will be able to pick one JPOS provides or you will need to extend JPOS' basechannel. Based on what I have seen, NACChannel which puts a 2 byte length header has worked.

Alternatively you can search this group for Postilion and find a wealth of already answered questions.

Alternatively, use netcat as a server and dump the data as hex and based on the data figure out the channel or use wireshark to trace the message to see what the header looks like and make an educated guess.

What you call rules the rest of us here call packager, lets stick with packager.
Packager defines how the bitmap and fields can be parsed correctly. 
Channel sends the packed message (bytes) and may add decorations like length headers, headers, trailers, tpdu to the message.

I refer you again to the JPOS programmers guide http://jpos.org/doc/proguide-draft.pdf

Chapter 4 talks about packagers.
Chapter 5 talks about channels.
-chhil

ccavforumrnd

unread,
Jul 12, 2019, 10:24:16 AM7/12/19
to jpos-...@googlegroups.com
Dear Team,

Here I am looking so many ways to read response string from socket
connection but as we observed here we are not able to get proper data.

Here we are using Java technology and below snippet code to read data from
socket stream.
Socket connection = new Socket("IP", Port);
InputStream is = connection.getInputStream();
byte[] buffer = new byte[1024];
int read;

while((read = is.read(buffer)) != -1) {
String output = new String(buffer, 0, read);
System.out.print(ISOUtil.hexString(output.getBytes()));
};

As you suggested we have to use *jpos channels * so we are trying to find
out but not bale to understand which channel we can use here so if possible
can you help me out for the same. here we are providing our JPOS rule xml
that we are using to pack/unpack of data stream. I am also proving here my
vendor specification details to get more information about the package.

"*In order to unpack a message received from the PostBridge interface it is
packing of the field is invalid, an exception is thrown."*

Here we are providing the our JPOS Rule.

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE isopackager PUBLIC
&quot;-//jPOS/jPOS Generic Packager DTD 1.0//EN&quot;
&quot;http://jpos.org/dtd/generic-packager-1.0.dtd&quot;>
<isofield id="5" length="12" name="AMOUNT, SETTLEMENT"
<isofield id="16" length="4" name="DATE, CONVERSION"
Looking forward your suggestion and help to get resolved my JPOS parsing
issue.






--
Sent from: http://jpos.1045706.n5.nabble.com/jPOS-Users-f2246022.html

chhil

unread,
Jul 12, 2019, 10:32:19 AM7/12/19
to jpos-...@googlegroups.com
You keep asking the same questions without taking into account solutions provided. Why don't you pass the charset as part of the String constructor so that your byte data does not get mangled?
Then provide hexdump and we can help you pick a channel.

Until then, I am done with this thread.

-chhil


--
--
jPOS is licensed under AGPL - free for community usage for your open-source project. Licenses are also available for commercial usage.  Please support jPOS, contact: sa...@jpos.org
---
You received this message because you are subscribed to the Google Groups "jPOS Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jpos-users+...@googlegroups.com.
To post to this group, send email to jpos-...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages