Paquetes genéricos en jPOS

Tags: , , ,

jPOSPackage

El empaquetado es una de las glorias de jPOS a mi parecer, hace un tiempo escribí como jPOS creaba el mapa de bits primario y sencudario.  Mucha gente que inicia con jPOS cree (me incluyo yo en mis inicios) que nosotros debemos setear el campo primario y el campo secundario, pero que quede claro, esto no es necesario con jPOS. Por eso vamos hablar hoy del empaquetado y el desempaquetado en jPOS, los diferentes tipos de empaquetados que el frameworks nos ofrece y el Empaquetado Genérico, para crear el empaquetado a la medida.

Existen 2 maneras de crear un empaquetador, primero implementando el Interfaz ISOPackager que se encuentra en el paquete org.jpos.iso y heredando los métodos de ISOBasePackager que trae int unpack y byte[] pack. Existen muchas clases empaquetadoras en esta ubicación /org/jpos/iso/packager para diferentes tipos de protocolos de comunicación.

public interface ISOPackager extends LogSource {
     public byte[] pack (ISOComponent m) throws ISOException;
     public int unpack (ISOComponent m, byte[] b) throws ISOException;
     public void unpack (ISOComponent m, InputStream in) throws IOException, ISOException;
     public String getFieldDescription(ISOComponent m, int fldNumber);
     public ISOMsg createISOMsg ();
}

La otra manera es crear un empaquetado genérico, que no es mas que crear una estructura en XML donde indicamos, el id, el largo del mensaje, el nombre, y el tipo de dato, en ese campo vamos agregar la clase del tipo de dato que nos ofrece jPOS.

<!DOCTYPE isopackager SYSTEM "genericpackager.dtd">
<!-- ISO 8583:1993 (BINARY) field descriptions for GenericPackager -->
<isopackager>
  <isofield
      id="0"
      length="4"
      name="Message Type Indicator"
      pad="false"
      class="org.jpos.iso.IFB_NUMERIC"/>
  <isofield
      id="1"
      length="16"
      name="Bitmap"
      class="org.jpos.iso.IFB_BITMAP"/>
    ...
    ...
    ...
  <isofield
        id="128"
        length="8"
        name="Message authentication code field"
       class="org.jpos.iso.IFB_BINARY"/>
 </isopackager>

Si descargas jPOS, podrás encontrar listos y para su uso algunos ejemplos en la ubicación cfg/packager.

Nota: Debes tener en cuenta que el genericpackager.dtd y el generic-validating-packager.dtd deben estar en el mismo directorio y tener permisos de lectura (linux) para que el paquete genérico pueda leer la configuración creada por vos.

Una vez listo tenemos nuestro xml para el empaquetador genérico, que se adapte a nuestras necesidades solo agregamos el PATH como parametro del constructor de la clase GenericPackager y listo para usarse como en el siguiente ejemplo.

GenericPackager packager = new GenericPackager("miPaquetePersonalizado.xml");

Una vez cargada la configuración, ya podemos empaquetar y tendremos lista nuestra trama para enviarla por el socket. o si desempaquetamos, el canal que usemos se encargará de converir la trama en un objeto ISOMsg.

//Para reempaquetar
iso.recalcBitMap();
//o usar los métodos para empaquetar
iso.pack();
//o
// Para desempaquetar
iso.unpack();

jPOS y el Echo Test 0800

Tags: , , ,

credit_cards

Continuando y aprendiendo mas sobre el Standard ISO8583 y jPOS, del cual hemos hablado anteriormente en otras entradas, hemos hablado de la mensajeria utilizada para el intercambio de transacciones entre sistemas por medio de un flujo de comunicacion. Hoy le toca el turno a otro tipo de mensaje que viene en este paquete del Standard como es el de manejo de red e intercambio de claves.

Este tipo de Mensaje, mejor conocido como 0800 es utilizado para mensajeria de Manejo de Red, siendo uno de los mas utilizados la mensajeria para enviar un Echo Test.

Una  vez que vez la terminal u origen de la transaccion basada en una tarjeta establezca comunicación con el emisor o procesador de la misma , es necesario cuidar esta linea que une ambos sistemas, siendo esto uno de  los puntos centrales e importantes, se requiere  que esta comunicación  siempre este disponible.

Y como hacemos esto cuando ambos sistemas se comunican por medio de mensajes y un standard?

Facil tambien se pensó en esto, y es por eso que existe la mensajeria 0800 en la cual podemos enviar constamente cada cierto periodo de tiempo un mensaje pequeño pero no menos importante cuya principal funcion es que ese canal que se ha abierto se mantenga asi las 24 horas y los 375 dias del año, que este habil y disponible para cuando una transaccion se desee realizar, y de esta manera nos evitariamos un sin numero de problemas.

Un ejemplo de un mensaje echo test seria lo siguiente:

ISOMsg msgiso = new ISOMsg();
//Importante el encabezado 800,
String mti = "0800";
//Si tu  mensaje lleva header aqui se pone la cadena de texto
String header = "tuHeader";
msgiso.setMTI(mti);
 
//Agregamos el Header del mensaje si lo necesitamos, el header se tiene que guardar en bytes
BaseHeader db = new BaseHeader(header .getBytes());
msgiso.setHeader(db);
 
//Campo 7, con ISODate obtenemos la fecha en formato ISO8583
msgiso.set(new ISOField(7, ISODate.getDateTime(new Date())));
 
//Campo 11, con ISOUtil.zeropad, rellenamos de ceros
msgiso.set(new ISOField(11, ISOUtil.zeropad(new Integer("555555").toString(), 6)));
 
//Campo 70, el 301 por defecto
msgiso.set(new ISOField(70, "301"));
 
//Lo empaquetamos, generico o echo a la medida, tu eliges.
GenericPackager packager = new GenericPackager("miPaquetePersonalizado.xml");
 
//Empaquetamos el mensake
msgiso.setPackager(packager);
 
//Construimos el BitMap
msgiso.recalcBitMap();

El Echo test utiliza 3 campos fundamentales del ISO 8583

  • Campo 7: Formato: MMDDhhmmss, MM para el Mes, DD para los Dias, hh las horas, mm minutos y ss segundos.
  • Campo 11: Número único generado por el sistema que envía el mensaje y es utilizado para hacer corresponder las respuestas con los mensajes originales
  • Campo 70: Este campo es por defecto 301. Tambíen se usa el 001 para Logon, y el 002 para Logoff, pero en nuestro caso es 301.

Conclusión, como pudiste ver, es bien sencillo construir un echo test, es un mensaje muy sencillo, que generalmente se envia cada cierto tiempo, suele ser una vez cada 30 o 45 minutos, depende la procesadora de tarjetas de crédito lo requiera, se puede usar un ciclo en el Q2 o construir tu propia interfaz externa que se comunique con el Q2 para canalizar los echo test.

Twitter con jPOS? Esto si que es innovación !!

Tags: ,

jPOSTwitter

Tal vez una de las fusiones más raras que he visto de una comunidad social con un framework sobre transacciones bancarias, esta clase la encontre en el grupo de jPOS y la verdad como Twittero, me dejo algo alucinado.

Actualización 18/06/09

La única utilidad que le veo es que los log del SysLog del Q2Server aparecen como nuevos mensajes en tu cuenta de Twitter , ha sido probado y funciona.

/*
 * jPOS Project [http://jpos.org]
 * Copyright (C) 2000-2008 Alejandro P. Revilla
 *
 * This program is free software: you can redistribute it and/or modify
 * it under the terms of the GNU Affero General Public License as
 * published by the Free Software Foundation, either version 3 of the
 * License, or (at your option) any later version.
 *
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 * GNU Affero General Public License for more details.
 *
 * You should have received a copy of the GNU Affero General Public License
 * along with this program.  If not, see <http://www.gnu.org/licenses/>.
 */
 
package org.jpos.util;
 
import java.util.Date;
import java.util.Locale;
import java.util.Iterator;
import java.io.IOException;
import java.text.SimpleDateFormat;
import org.jpos.core.Configurable;
import org.jpos.core.Configuration;
import org.jpos.core.ConfigurationException;
import org.jpos.q2.Q2;
import winterwell.jtwitter.*;
 
/**
 * Twitter Listener
 *
 *  requires jtwitter.jar from http://www.winterwell.com/software/jtwitter.php
 *
 *  Sample configuration:
 *
 *  <log-listener class="org.jpos.util.TwitterLogListener">
 *     <property name="twitterUsername" value="paymentsystems" />
 *     <property name="twitterPassword" value="SuperSecretPassword" />
 *     <property name="tags" value="twitter" />
 *     <property name="prefix" value="[jPOS]"/>
 *  </log-listener>
 *
 */
public class TwitterLogListener implements LogListener, Configurable {
    private Configuration   cfg;
    private String          twitterUsername;
    private String          twitterPassword;
    private String          prefix;
    private String          tags;
    private String          twitterMessage;
 
    private int             MAX_MESSAGE_SIZE = 140;
 
    public TwitterLogListener () {
        super();
    }
    public synchronized LogEvent log (LogEvent ev) {
        if (ev.tag != null && tags.indexOf(ev.tag) != -1) {
 
            Twitter twitter = new Twitter(twitterUsername,twitterPassword);
            StringBuilder sb = new StringBuilder();
            if (prefix != null) {
                sb.append (prefix);
                sb.append (' ');
            }
            Iterator iter = ev.payLoad.iterator();
            for (int i=0; iter.hasNext(); i++) {
                if (i>0)
                    sb.append (' ');
                    sb.append (iter.next().toString());
            }
            if (sb.toString().length()>MAX_MESSAGE_SIZE) {
                twitterMessage = sb.toString().substring(0,MAX_MESSAGE_SIZE);
            } else {
                twitterMessage = sb.toString();
            }
 
            try {
                twitter.updateStatus(twitterMessage);
            } catch (TwitterException e) {
                ev.addMessage ("--- TwitterLogListener error ---");
                ev.addMessage (e);
            }
        }
        return ev;
    }
    public void setConfiguration (Configuration cfg)
        throws ConfigurationException
    {
        this.cfg = cfg;
        try {
            twitterUsername = cfg.get ("twitterUsername");
            twitterPassword = cfg.get ("twitterPassword");
            tags     = cfg.get ("tags", "twitter");
            prefix = cfg.get ("prefix", null);
        } catch (Exception e) {
            throw new ConfigurationException (e);
        }
    }
}
  • Autor: admin
  • Publicado: Jun 12th, 2009
  • Categoria: Articulos
  • Comentarios: 1

Listeners en jPOS, el ISORequestListener con QMUX

Tags: , ,

Te preguntaras, que es jPOS?, aquí la respuesta. Cuando usas tu tarjeta de crédito, jPOS es usado en la mayoria de los interfaces para las transacciones de Tarjetas de Crédito, pues es un Framework muy usado y extendido para el protocolo ISO 8583, lo mejor, es gratis.

jPOS ofrece un servidor, llamado Q2 Server, donde podemos montar un proceso intermedio entre tu sistema y tu procesadora de tarjetas de crédito. Cuando estamos trabajando a nivel empresarial, donde las transacciones se hacen en segundos y es necesario dos caracteristicas que nos ofrece jPOS, el QMUX y el ISORequestListener.

El ISORequestListener, este interfaz sirve para construir nuestros propios Listeners y así poder integrarlos con un multiplexor QMUX, el Listener escuchará todas las peticiones de transacciones entrantes y salientes y las procesara según lo que necesites, en nuestro caso, las mandaremos a un multiplexor y esperara una respuesta, con esto podemos controlar errores o personalizar los mensajes de respuesta según nuestras necesidades.

El QMUX, el multiplexor, como su definición indica, se utiliza como dispositivo que puede recibir varias entradas y transmitirlas por un medio de transmisión compartido. Para ello lo que hace es dividir el medio de transmisión en múltiples canales, para que varios nodos puedan comunicarse al mismo tiempo.

IsoRequestListener

Vamos a explicar la figura, muchas aplicaciones se comunican con el Q2 server, el Q2 ejecuta la lógica del ISORequestListener personalizado y busca el QMUX e el jPOS Space, podemos tener muchos multiplexores, en nuestro caso solo tenemos uno y lo buscamos por el nombre identificador. El Adaptador ISO8583 se encarga de la conexión con la Empresa Procesadora de Tarjetas, esto lo veremos en otro artículo, cuando la primera parte del ciclo se concreta, la Empresa entrega una respuesta al Adaptador, el Adaptador al QMUX y el ISORequestListener espera la respuesta de la petición, el Listener buscará en el jPOS Space tu transacción por un campo clave, generalmente el campo 11 del ISO 8583, y así termina el ciclo.

El ISORequestListener se configura en el Q2Server de una manera muy sencilla.

<server name="xml-server" class="org.jpos.q2.iso.QServer" logger="Q2">
<attr name="port" type="java.lang.Integer">8000</attr>
<channel name="dummyclient.channel" class="org.jpos.iso.channel.BASE24Channel"
packager="org.jpos.iso.packager.GenericPackager" logger="Q2">
<property name="packager-config" value="cfg/packager/base24.xml" />
</channel>
<!-- Solo agregamos esta línea a la configuración de nuestro Q2 Server -->
<request-listener class="mipaquete.MiListenerPersonalizado" logger="Q2">
</server>

El ISORequestListener puede programarse de una manera básica de las siguiente manera

import org.jpos.iso.ISODate;
import org.jpos.iso.ISOException;
import org.jpos.iso.ISOField;
import org.jpos.iso.ISOMsg;
import org.jpos.iso.ISORequestListener;
import org.jpos.iso.ISOSource;
import org.jpos.iso.ISOUtil;
import org.jpos.iso.header.BaseHeader;
import org.jpos.q2.iso.QMUX;
import org.jpos.util.Log;
import org.jpos.util.NameRegistrar;
/**
* http://blog.jotadeveloper.com
*Creado por JotaDeveloper
*/
public class MiListenerPersonalizado extends Log implements ISORequestListener {
 
	@Override
	public boolean process(ISOSource source, ISOMsg m) {
		ISOMsg responseISOMsg = null;
		QMUX mux = null;
		try {
                        //Buscamos en el jPOS Space nuestro multiplextor, siempre se busca con el prefijo mux seguido por un punto
			mux = (QMUX) NameRegistrar.get("mux.mymux");
			mux.setLogger("mux");
                        //Se recupera la respuesta
			responseISOMsg = mux.request(m, 20000);
		} catch (NameRegistrar.NotFoundException ex) {
 
		} catch (ISOException ex) {
 
		}
		//Es importante siempre regresar true.
		return true;
	}
}

Y el multiplexor se configura con XML, pues el QMUX ya viene programador por defecto

<mux class="org.jpos.q2.iso.QMUX" logger="Q2" name="mymux">
<in>sample-receive</in>
<out>sample-send</out>
<!-- Este key, es la llave por la cual identificaras unicamente cada mensaje, es importante
poner el valor indicado, generalmente es el 11 o el 17 -->
<key>55</key>
</mux>

En el próximo artículo, veremos los adaptadores y los diferentes tipos de conexiones que podemos crear con jPOS.

© 2009 Jotadeveloper Blog. Nuestros contenidos están bajo licencia Creative Commons mientras no se indique lo contrario,
y pueden reproducirse libremente sin más que mencionar la fuente ("JotaDeveloper") y la URL concreta del artículo original. .

This blog is powered by Wordpress and JotaDeveloperTheme.