Primero una apología por mi español, cortesía del babelfish. Éste es
sobre todo una lista de personas a quienes se mandan propaganda basada
inglesa, pero let' intento de s…
Fabio Arias wrote:
> Muy Buenos Dias amigos, tengo un problema deseo realizar una
> implementacion con jPos pero debo implementar un protocolo ya
> existente, he intentado varias cosas pero aun no me ha funcionado del
> todo correcto.
>
> El protocolo tiene las siguientes bases
>
> Incomming
> Longitud ( 1 Byte Valor Hexadecimal incluye este primer byte)
> Tipo de Transaccion ( 1 Byte Valor Hexadecimal )
> Data Request ( ASCII longitud variable dependiendo de la longitud-2)
>
> Outgoing
> Longitud ( 1 Byte Valor Hexadecimal incluye este primer byte)
> Tipo de Transaccion ( 1 Byte Valor Hexadecimal )
> Data response ( ASCII longitud variable dependiendo de la longitud-2)
Is the Data portion in each direction an ISO8583 structure?
¿Es la porción de los datos en cada dirección una estructura ISO8583?
>
> Como hago para implementar esto con jPos, les agradezco todo la ayuda
> que me puede dar.
Depending on the answers to the above questions, you might take a look
at FSDMsg instead of the ISO8583 Packager(s) or variants.
Dependiendo de las respuestas a las preguntas antedichas, usted puede
ser que heche una ojeada FSDMsg en vez de los embaladores ISO8583 o de
las variantes.
>
> Gracias
You are welcome.
Usted es agradable.
--
http://babelfish.yahoo.com/
Mark
>
> Dependiendo de las respuestas a las preguntas antedichas, usted puede
> ser que heche una ojeada FSDMsg en vez de los embaladores ISO8583 o de
> las variantes.
>
Your protocol looks like something that could be handled by
org.jpos.util.FSDMsg.
Ok, so FSDMsg or FSDISOMsg are probably going to be your thing.
You still need to construct the configuration files to define the
structure. Do you have a document that defines the fields that are
present in each direction, their formats and their meanings? If not get
one as soon as possible.
The length byte you will handle in a Channel, reading and returning the
correct number of bytes, for subsequent unpacking.
>
> For Example:
>
> Request.
>
> 42 04 30 34 7C 33 7C 35 31 35 36 7C 34 39 34 7C | B.04|3|5156|494|
> 34 33 37 7C 32 30 30 37 31 32 30 37 30 35 30 34 | 437|200712070504
> 34 31 7C 31 32 33 34 35 36 7C 32 36 36 7C 31 30 | 41|123456|266|10
> 30 30 30 2E 30 30 7C 33 31 31 38 34 34 34 35 37 | 000.00|311844457
> 36 7C | 6|
>
> Response.
>
> 4D 04 31 30 31 7C 31 30 30 30 30 2E 30 30 7C 31 | M.101|10000.00|1
> 37 31 30 35 31 7C 33 37 35 39 30 39 7C 31 30 2F | 71051|375909|10/
> 31 32 2F 30 37 20 30 39 3A 32 30 3A 31 30 7C 30 | 12/07 09:20:10|0
> 30 30 33 37 30 32 7C 33 30 35 32 37 31 34 39 35 | 003702|305271495
> 30 7C 32 30 30 38 2F 30 31 2F 30 39 7C | 0|2008/01/09|
>
> As u see, the first byte have a value of long or data including self,
> the next byte have a transaction type, and the rest of bytes is the
> data message, i need a way for create a ISOServer that receive and
> response this kind of data.
Shame the dump uses '|' as a divider between hex and character areas, it
confused me for a bit 8).
Once you have your message specification to hand, search this mailing
list for FSDMsg and FSDISOMsg there have been many discussions parts of
which will be relevant.
One link I found points to an entry within Andy's ever useful and often
referenced blog:-
http://www.andyorrock.com/2007/07/as-may-you-know.html
This talks through a use of FSDMsg - for a different message structure,
and it might give you the idea.
My use of FSDMsg and it's hierarchical config files always take me a
little while to get into, but if you do need advice, this is the place
to find it.
>
> Thanks a lot
Thanks for moving to English, was my BabelSpanish that bad?
8)
--
Mark
Wow, I even forgot I had written those other ones. Thanks, Murtuza.
Andy
From: jpos-...@googlegroups.com
[mailto:jpos-...@googlegroups.com] On Behalf Of chhil
Sent: Tuesday, March 24, 2009 2:21 PM
To: jpos-...@googlegroups.com
Subject: Re: Packager Propio como?
2 things, search the mailing list for FSDMsg and you will see examples.
> i made this and works, but with the POS disconnect, the server
> continue receive a data zero all time.
Calling serverIn.available() is - I fear - counter productive.
Better I think that the serverIn.read(b,0,2) blocks until data arrives.
If nothing is available then won't your code fall through to the
finally, which builds a two byte[] of :-
byte[] {0x30,0x30)
into r for the return?
Are these the ASCII c'00' you are seeing? I would have thought you
would see c'00' arriving whenever the server was not receiving data
though, not just after the POS disconnects as the isConnected would
start returning false if the connection was severed?
--
Mark
I have to admit I am lost...
> the ISOField is IFA_LLCHAR thats mean two
> first bytes got the long of data, because i convert the original data
> to the format ISOField. But the problem isnt that, else, when the
> response is sending for POS the server, i dont know how, receive data
> zero.
Ok, I think there is more to the exchange of messages than I can
currently see from your postings. You are presenting a lot of
information, but it is hard to see what might be pertinent to your
problem, or what your problem actually is.
Can you state what the problem is please?
Can you also describe the POS devices activities step by step, including
making and breaking the connection to your server? Collating the
relevant trace data from your debugging output for each step might also
help.
Does the POS device see any of your response at all? Does it like what
it sees or not? It does look like the connection might be being severed
after or during your response write, but do you have two Exception
overlaying each other in your output - the write failing and a read
falling as the connection is severed?
--
Mark