Tras comprobar ayer que el lector funciona con las nuevas tarjetas, me dispongo a probar sobre las mismas. Para ello he utilizado el código de acceso a registros que había comentado para poder reducir el tamaño del fichero .cap, que dependiendo del mismo, se podrá o no importar un proyecto en una tarjeta.
Desde el servlet Lector, se escriben los datos a enviar en el fichero de identificador 0x4F99, que es un fichero con estructura de registros (130 registros de 250 bytes/registro). La creación de este fichero, se ha logrado (o eso parece) con un script de extensión ATF debidamente lanzado desde la aplicación JCardManager. Aunque los comandos de creación y/o acceso no devolvían 90 00, según el File System Editor probado sobre la tarjeta, sí están creados.
Puesto que los registros están disponibles, he querido probar el sistema declarando manualmente un fichero xml con las etiquetas necesarias para que el receptor pueda hacer las operaciones pertinentes con los datos. Si una operación de acceso, lectura o escritura fallase, saltaría una excepción y se lanzaría en el navegador una página que indique que un error ha sucedido.
Escritura: Se ha escrito en 3 ficheros. En el primero se indica el número de registros que se han utilizado para datos. En este ejemplo, como los datos tienen un tamaño de 250 bytes, únicamente se ha utilizado un registro para datos. En el segundo, irán los datos. Y en el último el DNI del usuario.
Lo comentado anteriormente sigue la siguiente estructura:
----------------------------------------------
| Nº regs datos | D1 | D2 | ............. | Dn | DNI |
----------------------------------------------
El motivo de incluir el DNI del usuario, es para que el sistema final tenga un identificador único con el que guardar el pedido del cliente. Este identificador único se compone del DNI y de la fecha y hora actual del sistema.
Volviendo a las pruebas, el servlet encargado de grabar los datos en los 3 registros del fichero 0x49FF no presenta ninguna anomalía. No salta ninguna excepción y la ejecución sigue con normalidad.
Al conectar el lector y darle a start, se ve que el applet responde a la selección de su AID pero al pedirle datos (que debería obtener del fichero) se obtiene un código de respuesta de 6F 00.
Normalmente esto ocurre cuando no se están enviando bien los datos de vuelta. No he podido hoy mirar si realmente está leyendo bien de fichero (no se puede depurar una vez está en la tarjeta, ni existen los println) o es algo más grave e irreconocible. Así que será la tarea a resolver mañana.
El SIMagine se acerca, y yo con estos pelos :/
| Nº regs datos | D1 | D2 | ............. | Dn | DNI |
----------------------------------------------
El motivo de incluir el DNI del usuario, es para que el sistema final tenga un identificador único con el que guardar el pedido del cliente. Este identificador único se compone del DNI y de la fecha y hora actual del sistema.
Volviendo a las pruebas, el servlet encargado de grabar los datos en los 3 registros del fichero 0x49FF no presenta ninguna anomalía. No salta ninguna excepción y la ejecución sigue con normalidad.
Al conectar el lector y darle a start, se ve que el applet responde a la selección de su AID pero al pedirle datos (que debería obtener del fichero) se obtiene un código de respuesta de 6F 00.
Normalmente esto ocurre cuando no se están enviando bien los datos de vuelta. No he podido hoy mirar si realmente está leyendo bien de fichero (no se puede depurar una vez está en la tarjeta, ni existen los println) o es algo más grave e irreconocible. Así que será la tarea a resolver mañana.
El SIMagine se acerca, y yo con estos pelos :/
0 comentarios:
Publicar un comentario