my jpos ISO8583 implementation keeps prefixing "1" to the message length

Question

My ISO JPOS client implementation prints message length output correctly but when I do tcpdump i see the message length prefixed with "1". So the tcpdump shows the message header as "10000431804003001000000000084946520200922160158801" instead of "0000431804003001000000000084946520200922160158801"

Any idea what could be the issue.

Below is my client print out of the message length and the unpack ISO: 0000431804003001000000000084946520200922160158801

<log realm="post-channel/xx.xx.xx.x:xxxx" at="Tue Sep 22 16:01:58 WAT 2020.579" lifespan="1ms">
  <send>
    <isomsg direction="outgoing">
      <!-- org.jpos.iso.packager.GenericPackager[deploy/cfg/customizedPackager.xml] -->
      <header>303030303433</header>
      <field id="0" value="1804"/>
      <field id="11" value="849465"/>
      <field id="12" value="20200922160158"/>
      <field id="24" value="801"/>
    </isomsg>
  </send>
</log>

my code implementation below:

            Date currDate = new Date();
            SimpleDateFormat lda = new SimpleDateFormat("yyyyMMddHHmmss", Locale.getDefault());
            String d = lda.format(currDate);
        
            QMUX mux1 = (QMUX) NameRegistrar.getIfExists("mux.pesa-link-mux");
            LoggingUtil.logDebugInfo("SIGNON MUX: " + mux1.getName());
            Random randomGenerator = new Random();
            int randomInt = randomGenerator.nextInt(1000000);
            String formatedInt;
            formatedInt = String.format("%06d", randomInt);
            ISOMsg m = new ISOMsg();
            //m.setHeader("000043".getBytes());
            ISOPackager p = new GenericPackager("/usr/app/customized.xml");
            byte[] b = new byte[1];
            m.setPackager(p);
            m.setMTI("1804");
            m.set(11, formatedInt);
            m.set(12, d);
            m.set(24, "801");

            byte[] data = m.pack();
            short messageLength = (short) data.length;
            String msglen = String.format("%6s", String.valueOf(messageLength)).replace(' ', '0');
            String message = msglen + new String(data);
            LoggingUtil.logDebugInfo(":: message length :: " + message + " :: len: " + msglen);
            ISOMsg resp = mux1.request(m, 30 * 1000);

channel config here

<channel-adaptor name="pd-channel-adaptor" class="org.jpos.q2.iso.ChannelAdaptor" logger="Q2">
     <channel class="org.jpos.iso.channel.PostChannel" type="client" connect="yes" logger="Q2"
             realm="post-channel" packager="org.jpos.iso.packager.GenericPackager">
            <property name="packager-config" value="deploy/cfg/customized.xml" />
<property name="host" value="1111.11.11.11" />
<property name="port" value="3322" />


    </channel>
    <in>pd_link_send</in>
    <out>pd_link_receive</out>
    <reconnect-delay>1000</reconnect-delay>
        <keep-alive>yes</keep-alive>
</channel-adaptor>

If you show the code that is generating that, there are more chances someone will be able to help with this — Andrés Alcarraz, Sep 22 '20 at 15:28
i have updated my question with the java client implementation . thanks for your concern Andrés — Daniel Ameyaw, Sep 22 '20 at 15:35
Where are you seeing (or how are you getting) that hex dump? the definition of the channel as would be of help too. — Andrés Alcarraz, Sep 22 '20 at 15:38
Take into account that you don't need to put the length as a header, the proper channel will do that for you. The jpos header concept is something that comes at the beginning of the message, and it comes right after the length — Andrés Alcarraz, Sep 22 '20 at 15:47
i have updated my question to include the channel config. thanks in advance... — Daniel Ameyaw, Sep 22 '20 at 15:48
The Postchannel is the one that prepends the length, if you are seeing 1 is because you are seeing the ascii for hexa 31 which is 49, so your channel is correctly pretending the length of your header (5) + the length of your message (43), you need to look at the hex dump not the ascii representation, PLease show how are you capturing the dump — Andrés Alcarraz, Sep 22 '20 at 15:55
this is well noted. per my source code i have commented the section that puts the length in the header. Is there any any other observation ? — Daniel Ameyaw, Sep 22 '20 at 15:56
the message dumped you show in your question has the header set, and the dump info you showed also match that, so the question doesn't seem to be updated with that commented change — Andrés Alcarraz, Sep 22 '20 at 16:00
i'm capturing the dump using this syntax: sudo tcpdump -i any -c100 -nn -A port 3322. So i'm actually trying to achieve sign-on with another server and it's failing because of the 1 prefixed the message. I manually formatted the message without the 1 prefixed and got the correct server response when i used java socket — Daniel Ameyaw, Sep 22 '20 at 16:10
how do i remove the 1 as that's the only way the server will response with successful sign-on response — Daniel Ameyaw, Sep 22 '20 at 16:12
See my answer, you don't need to remove that you need to use the proper channel and not set the length as the header. — Andrés Alcarraz, Sep 22 '20 at 16:18
Let us [continue this discussion in chat](https://chat.stackoverflow.com/rooms/221889/discussion-between-andres-alcarraz-and-daniel-ameyaw). — Andrés Alcarraz, Sep 22 '20 at 16:42

score 1 · Accepted Answer · answered Sep 22 '20 at 16:17

1

It seems your server is expecting the length as 6 ASCII digits, so you need to use ASCIIChannel with property length-digits set to 6

<channel-adaptor name="pd-channel-adaptor" class="org.jpos.q2.iso.ChannelAdaptor" logger="Q2">
     <channel class="org.jpos.iso.channel.ASCIIChannel" type="client" connect="yes" logger="Q2"
             realm="post-channel" packager="org.jpos.iso.packager.GenericPackager">
            <property name="packager-config" value="deploy/cfg/customized.xml" />
<property name="host" value="1111.11.11.11" />
<property name="port" value="3322" />
<property name="length-digits" value="6"/>

    </channel>
    <in>pd_link_send</in>
    <out>pd_link_receive</out>
    <reconnect-delay>1000</reconnect-delay>
        <keep-alive>yes</keep-alive>
</channel-adaptor>

And you don't have to put the length in the header.

answered Sep 22 '20 at 16:17

Andrés Alcarraz

1,570
1
12
21

thanks Andres. after the change to conform to the above. i got below as the message 00431804003001000000000016271920200922172955801 the message length is now showing : "0043" instead of "000043". Any suggestion – Daniel Ameyaw Sep 22 '20 at 16:30
Maybe you have an old version of jpos, that property (`header-length`) is a recent addition – Andrés Alcarraz Sep 22 '20 at 16:42
ok.. will update my jpos library now and try again. thanks alot. – Daniel Ameyaw Sep 22 '20 at 16:44
well not so recent, it should be there since version `2.1.0` see https://github.com/jpos/jPOS/wiki/ChangeLog#jpos-210----released-2017-05-27 – Andrés Alcarraz Sep 22 '20 at 16:46
i can't seems to get the jar file for the 2.1.0+ when i navigate the above jpos URL..... Currently to start the service, it's either i use nohup or do "java -jar jpos.jar" to start it on the terminal. is there a way to share the link for the new jar for jpos. – Daniel Ameyaw Sep 22 '20 at 19:18
here is the maven link, there you can download the jar, but it would be better if you use some dependency manager such as maven or gradle (the later is the jpos way :)) I can't assure you won't have dependency problems if your current setup is based in a really old jpos jar. https://mvnrepository.com/artifact/org.jpos/jpos/2.1.4 – Andrés Alcarraz Sep 22 '20 at 21:43
do you know which version are you currently using? where did you get it from? – Andrés Alcarraz Sep 22 '20 at 21:44
everything worked after i updated my jar. thanks so much Andres. – Daniel Ameyaw Sep 29 '20 at 01:30
btw do you know what could use this error: org.jpos.iso.ISOException: Key fields not found - not sending pd-channel-send.120 at org.jpos.q2.iso.QMUX.getKey(QMUX.java:274) at org.jpos.q2.iso.QMUX.request(QMUX.java:133) – Daniel Ameyaw Sep 29 '20 at 01:33
this is my code which generates the above error: ISOMsg m = new ISOMsg(); try { m.setMTI("1200"); m.set(2, transferRequest.getPrimaryAccountNo()); m.set(3, transferRequest.getProcessingCode()); m.set(4, transferRequest.getAmountTransaction()); m.set(11, transferRequest.getStan()); m.set(12, transferRequest.getDatetime()); ISOMsg isoResponse = qmux.request(m, 30 * 1000); if (isoResponse != null) { val resp = new String(isoResponse.pack()); } – Daniel Ameyaw Sep 29 '20 at 01:34
Alcarraz, i'm back again :). thanks for the assist so far. My implementation is actually in 2 ways(ie. i send and also receive request from the other remote server). With my channel configuration above, i am able to send request and receive response successfully with no issue. However, i noticed my packager throws an error whenever the remote partner sends requests to me. So i decided to create another customized packager for receiving request from the partner but noticed partner requests are still pointing to the earlier(old) packager. Any clue...see my configuration below – Daniel Ameyaw Oct 15 '20 at 09:36

my jpos ISO8583 implementation keeps prefixing "1" to the message length

1 Answers1