--
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 "jPOS Users" group.
Please see http://jpos.org/wiki/JPOS_Mailing_List_Readme_first
To post to this group, send email to jpos-...@googlegroups.com
To unsubscribe, send email to jpos-users+...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/jpos-users
>
> //unpack
> ISOMsg um = new ISOMsg();
> um.setPackager(packager);
> um.unpack(pack);
What data are you unpacking in this test code?
Has it been modified in *anyway* since the pack?
The Packager should be implicitly reversible, unless the data or
packager is different than that produced or used in the pack.
--
Mark
> I'm waiting for reply question 2
>
We have your question and no-one has taken the opportunity to answer,
perhaps you could try rephrasing it.
I have re-read it again and I'm still not at all sure what you are
asking, can you make your question much clearer?
If there is no answer forthcoming, then chasing one won't help, that is
the beauty of this and other open source mailing lists, people can pick
or choose what is important to them.
--
Mark
"
02. After doing IFB_LLLCHAR to IFB_LLLBINARY why I can't extract created
massage ?
"
What did you do?
What change did you make?
What was the result?
What does "can't extract" mean - an Exception, an error message, bad
data or result?
Can you present a small self-contained piece of code to show what is wrong?
I appreciate that some (if not all) of this information *might* have
been presented already, but I suspect that it is spread through three or
four postings, which makes it hard to find and gather.
My observation would be that if *I* have to try or am struggling to work
out and find all the parts of a question, I tend not to bother, like's
too short.
Other's might not share this view, but it might explain why no-one has
answered your question on a mailing list where it is not unusual for two
or more answers from different people to some questions.
--
Mark
Hi,
I’ll try to help out Mark in anwering your question.
Your question is unclear, but if i have to guess
You need something that process/treat field 63 differently depending on the transaction type ?
If thats correct then......
You either have to code a custom packager that does dynamic branching pack/unpack depending on a field type,
This is how I coded my Thales Keytypes.
OR
Create two xml packager definition, get the transaction type and unpack/repack the message to read field you want
Based on the transaction type.
Best Regards.
Hairi
<CLIP>
Actually above definition for 63 is only for one transaction (When keying card number and 4DBC value for amex transactions. It means doing manually transaction without card swapping )
But for settlement transaction field 63 definition should be default
First two byte = Length of value
The value = Settlement details
So I'm trying to use same iso8583B.xml file to both scenario
Qusions
01. Is it possible using same iso8583B.xml file ?
02. If not what is the solution that can be applied ?
03. I'm trying some testing with my packager but getting some error
</CLIP>
I think this is the right way, with perhaps dynamic Packagers being used
once the foundation of jPOS is clearer.
>
> I open a message with my finger 1mm away from the 'D' key, if
> the first *short* paragraph doesn't caught my attention, I hit it right
> away. I guess most people do the same, and that's the beauty of this kind of
> lists that we join for fun.
Agreed, although my finger hovers 2mm away, perhaps I should think about
reducing my distance 8).
--
Mark
Mark
Dear Kapilashanrtha,
Answering your question is like playing a guessing game.
It will be helpfull if you could provide a hexdump of the incoming message.
However, let me take a stab again.
Outer field should be LLBinary
Inner field should be LLChar
So 2Ls instead of 3.
Best Regards,
Hairi
From: jpos-...@googlegroups.com [mailto:jpos-...@googlegroups.com] On Behalf Of kapilashantha rajapaksha
Sent: 21 Juli 2011 10:03
To: jpos-...@googlegroups.com
Subject: Re: [jpos-users] Field 63 sub element issue for Iso87B Packager
I'm keeping two xml packagers according the transaction type as Hairi said. Now I am able to pack IsoMsg element data according their specification.
Can you share the resultant contents of field 63 in each case perhaps?
> But I am still unable to unpack the response massage from back-end properly.
> It means, I'm not getting any exception but I'm getting null value for field
> 63 only. But in the response packet it has field 63 with inner IsoMsg.
>
Then I would think you are not using the same/right Packager on unpack
as was used on pack.
Can you describe the exact steps you are taking (at each end) and back
this with minimal code snippets?
> Appreciate if someone tells me how to read inner massage and read its sub
> value ?
isomsg.getString("63.1")
is illustrative of a possible way, but not being sure about your set-up,
please revise/adjust to your needs?
--
Mark
Mark
Sent from my BlackBerry®
powered by Sinyal Kuat INDOSAT
System.out.println(i+"=["+um.getString(i)+"]" );
And show what output you get please?
>
> where packager definition as bellow for field 63 (Note : I'm using
> iso87binarry.xml)
>
> <isofieldpackager
> id="63"
> length="999"
> name="PRIVATE DATA"
> class="org.jpos.iso.IFB_LLLBINARY"
> packager="org.jpos.iso.packager.ISO87BPackager">
This packager looks wrong to me, I think it should be of type
XXXXSubfieldPackager?
>
>
> <isofield
> id="1"
> length="6"
> name="Customer Name"
> class="org.jpos.iso.IFB_LLLCHAR"/>
>
> </isofieldpackager>
>
So this is the definition that will always match the response given by
your back-end?
So your back-end echos 63.1 back and adds no other subfields to field 63?
--
Mark
Field |
Attribute |
Bytes |
Values |
Additional Data Length |
n 4 |
2 |
‘0LLL’ – BCD length of the data to follow |
Table Id |
ans 2 |
2 |
‘17’ – AMEX 4DBC |
Value |
an 4 |
4 |
The 4DBC figure as it is printed on the AMEX Card |
This packager looks wrong to me, I think it should be of type
XXXXSubfieldPackager?
Just I changed it like this "org.jpos.iso.packager.GenericSubFieldPackager"
Then I will get pack error while creating request
Then I change it back again org.jpos.iso.packager.ISO87BPackager as previous.
And show what output you get please?
when i change from um.setPackager(packager) um.setPackager(new ISO87BPackager()) (Note : just for testing)
It is as bellow
0=[0210]
11=[020011]
25=[00]
41=[22222222]
but when it is um.setPackager(packager)
I am getting error as bellow
error unpacking field 63
org.jpos.iso.ISOException: java.lang.NullPointerException (java.lang.NullPointerException)
at org.jpos.iso.ISOBasePackager.unpack(ISOBasePackager.java:293)
Regards
Mark
On 22/07/2011 05:02, kapilashantha rajapaksha wrote:
> This packager looks wrong to me, I think it should be of type
> XXXXSubfieldPackager?
>
> Just I changed it like this "org.jpos.iso.packager.GenericSubFieldPackager"
>
You picked a sub field packager at random and it didn't 'just work'...
> Then I will get pack error while creating request
.. but you still don't give us the exact 'error' or output?
>
> Then I change it back again org.jpos.iso.packager.ISO87BPackager as
> previous.
Well, it is still potentially wrong then?
>
>
> And show what output you get please?
>
> when i change from um.setPackager(packager) um.setPackager(new
> ISO87BPackager()) (Note : just for testing)
>
>
> It is as bellow
>
> 0=[0210]
> 11=[020011]
> 25=[00]
> 41=[22222222]
No field 63?
>
> but when it is um.setPackager(packager)
What is in this field packager? I don't know form the detail given, do I?
--
Mark
I'm out of this thread.
--