Algunos Links Utiles

La idea de esta sección es la de publicar utilidades, tips o cualquier cosa que sirva para algo... En este caso dejo dos sitio web que me resultan útiles. Es en esta seccion donde pido maxima colaboración.
http://www.diccionarios.com
Diccionarios en español, ingles y francés. Impresidible para traducir los mail de Quique Almeida
http://www.mapred.com
De la gente de AgeMap, ubica direcciones con mucha facilidad.

Alejandro Rinaldi. 

Para que sirven las colas, libre interpretación.

Para la nueva versión de GIA hemos tenido que estudiar una nueva tecnología que por lo menos para mi , me ha resultado muy interesante. Aunque no hemos puesto en producción nada aun que lo utilice, veo en estas tecnologías un potencial de desarrollo que quisiera compartir. Estas tecnologías son los colas de mensajes... En particular, MSMQ de microsoft y MQSeries de IBM, no tratare de dar ventajas de una u otra solución, sino de describir lo que se puede ganar si se tiene en cuenta esta tecnología para el desarrollo de una aplicación.
Programación asincrónica vs. sincrónicaTradicionalmente con GX y la mayoría de los lenguajes de programación se utiliza una metodología de desarrollo sincrónica, es decir, si un proceso debe ejecutar 4 fases, A, B, C y D, se programa de forma que cada etapa se ejecute una a continuación de la otra.
Inicio -> A -> B -> C -> D -> Fin
Pero, en algunos casos no es necesario realmente que alguna de esas etapas termine para que le siguiente pueda empezar, por ejemplo, pongamos un caso típico. El grabar un log de actividad, en muchas aplicaciones es necesario o preferible, que haya un log de todo lo que hagan los usuario, para eventualmente poder luego identificar quien y cuando realizo un cambio en alguna tabla critica, como puede ser las cotizaciones del día. O poder reproducir la evolución de un valor , por ejemplo el precio por kilo de la harina, cosa que obligaría tener una línea con el precio y la fecha que se modifico, complicando la búsqueda de valor vigente y aumentando la estructura necesaria para guardar esta información.
en tablas, sin log:
Producto*
Precio
en tablas, con log de cambios:
Producto*
Fecha de vigencia*
Precio
Usuario que modifico
Aunque en el primer caso es sencillo encontrar el valor vigente (el único que hay) no se sabe porque una liquidación de hace tres años dio lo que dio, (a menos que guardemos el precio en la propia liquidación), en el segundo caso aunque el histórico de los precios, es mas costoso encontrar el valor vigente y aumenta la cantidad de tablas y la de atributos.
Otra opción seria la de tener tablas de log, pero en algunos casos no es viable el de estar manteniendo estas tablas por el tiempo de ejecución es crítico en largos procesos y el tiempo que insume el tener que estar grabando tablas de log es demasiado. Otro problema podría ser que los datos se modifican muy frecuentemente y el volumen de log que se generaría sería demasiada para tenerla en la misma base de datos.
Para estos casos y otros, seria interesante el de contar con una cola de log, es decir, cuando se produce un evento que amerita el de tener una registro en una tabla de log, se podría enviar un mensaje a una cola con la información necesaria para registrar la modificación. La ventaja que tenemos con enviar un mensaje en vez de grabar una tabla son varias, una que es mas rápido, el mensaje queda en cola hasta que pueda ser procesado, por ejemplo por la noche cuando la actividad cae. Generalmente estos logs de actividad no son consultado inmediatamente luego de hacer la modificación, por lo que podrían estar disponibles a partir del otro día que se hizo la modificación. Con esto ganamos tiempo que en un proceso que requiere ser eficiente sin perder la propiedad de generar log de actividad.
Otra ventaja seria que si el log que se genera en muy grande, la base de datos donde se graba este log podría ser otra que la de producción ya que el proceso que lee de la cola grabaría un otra base distinta de la de producción, evitando así que la base de producción crezca en tamaño por los archivos de log. Otra ventaja mas, podría ser la seguridad, ya que al estar el log en otra base, que podría llegar a estar en otro sitio físico muy destino a la de la base de producción, en caso de accidentes en la base de producción (incendios, hackers, ladrones) la base de log podría estar en sitio seguro (las propias oficinas de CONCEPTO, por ejemplo)
Este sería el concepto de asincrónico, el de hacer una etapa del proceso cuando se pueda y no cuando se genera, en nuestro primer ejemplo, si la etapa C seria la de generar el log se los cambios que pasaron en las etapas A y B, pero no se puede esperar para ejecutar la etapa D, se puede enviar un mensaje a la cola de log con toda la información necesaria para realizar la etapa C, luego ejecutar la etapa D y cuando se pueda (a la noche o cuando sea) ejecutar todas las etapas C que se han generado ese día
Inicio -> A -> B - -> D -> Fin
|_ mensaje -> C
Otro ejemplo mas ambicioso podría ser la generación de los asientos de la facturación por cola de mensaje, cuando se hace una factura , se genera los asientos correspondientes, pero realmente estos asientos no son necesarios hasta fin de mes, se podría enviar un mensaje a una cola de asientos por generar, acelerando el proceso de facturación y dejando la generación de asientos para la noche... Bueno, creo que si uno lo piensa podría haber muchos ejemplos de cosas que realmente que se hacen a medida que se ejecutan un evento que realmente no son necesarias hacerlas en el momento y se podrían hacer asincrónicamente, mejorando los tiempos de respuesta de nuestras soluciones.
Bajando la pelota al pisoPor supuesto que desde GX no se puede manejar colas de mensajeria, se debería hacer con programas externos,
En Visual Fox serian algo asi:
oMsg = CreateObject("msmq.msmqmessage")
oMsg.Label = "Mi mensaje"
oMsg.Body = "Mi texto"
oMsg.Send(oSendQueue)
oMsg = oReadQueue.ReceiveCurrent(,,,0)
subject = oMsg.Label
body = oMsg.Body
En Java:
Send_msg.writeChar('Mi texto');
MQPutMessageOptions pmo = new MQPutMessageOptions();
Send_queue.put(Send_msg,pmo);
system_default_local_queue.get(retrievedMessage, gmo );
mensaje = retrievedMessage.readLine();
Para TerminarBueno, el objetivo de este articulo es el de crearles el interés y que tenga en cuenta utilizar colas de mensajes si es la mejor opción para su solución. Por mas información, no dude en consultar.
Referenciashttp://www.microsoft.com/msmq/
http://www-4.ibm.com/software/ts/mqseries/

ConsoliDarwin: Selección natural vs. Convivencia forzosa

Lo tienen a Darwin ¿ no ? El que postuló la teoría de la evolución de las especies...un gran observador con bastante de sentido común. Podemos resumir sus grandes ideas en algunos titulares (que esto nunca caiga en manos de un biólogo):

§ La vida es dura...Cada vez somos más y hay poco para comer, poco espacio para vivir, por lo tanto hay competencia entre los individuos que pueblan esta tierra.
§ Cambia todo cambia...Hay mutaciones que producen cambios en las especies, cambios que pueden ser beneficiosos o perjudiciales en la competencia por la vida.
§ Quedaremos los mejores...En esta competencia por la vida ganan los más fuertes, los mejor adaptados, los que se vieron beneficiados con mutaciones que dieron en el clavo .

¿ Qué tiene que ver esto con nosotros ? Si me permiten el abuso de imaginación, veo un paralelismo con la evolución de las soluciones en ambientes multi-cliente. En particular, atendiendo a un hecho que se ha acentuado en el año 2000: cada vez más clientes usan nuestros sistemas. Para la gente de oficinas es un hecho consumado, para la gente de aduanas es un hecho casi-consumado.Nuevo cliente: ¿ nuevo problema ? Nooo...mejores soluciones!!!El pasaje de un esquema mono-cliente con una solución totalmente a medida a un esquema multi-cliente, donde en muchos aspectos la medida de los nuevos clientes no encaja con la medida del cliente original es un problema (nuestro, no de los nuevos clientes). Hay soluciones que no se adaptan y tienen que mutar, y tienen que evolucionar. Las condiciones están dadas: antes la conciliación bancaria la hacía Pepito en Cousa, y ahora también la hacen Juancita en Sammel y Cachito en Jaume; por supuesto que cuando la programamos la hicimos como decía Pepito, por ese entonces nuestro gurú de la conciliación, pero resulta que Juancita y Cachito realmente la pensaron mejor, y se puede hacer mejor.
Excelente oportunidad para hacer evolucionar la solución a un problema. Tenemos ahora 3 cabezas pensando cómo mejorar...sólo nos resta hacer la tarea de la selección natural ¡ y que gane la mejor solución para alegría de todos ! Y para alegría nuestra, cuando en el próximo cliente alguien nos felicite porque el sistema le simplifica la vida en vez de mostrarse desconforme...y si se muestra desconforme encontremos una solución mejor para seguir enriqueciéndonos todos.
En el caso del SIGE, ¿ quiénes lo están usando ?

§ Cousa
§ Molinos San José
§ Molino Río Uruguay
§ Establecimiento San Aparicio
§ Precodata
§ Sammel
§ Jaume y Seré (a partir de enero)
§ Jauser Cargo
§ Cables, GPS
§ ¡Nosotros!

De los cuales la diversidad real está entre el Grupo Gard, Precodata, Sammel y el Grupo JS.
Quizás no valoremos en su total magnitud el semillero de soluciones que tenemos. Porque sin duda que todas estas empresas tienen gran cantidad de problemas comunes, sobre todo administrativo-contables. Y hasta tenemos diversidad de clientes en problemas más específicos, como gestión de materia prima y operativa de balanza.
En la Aduana sin duda se da un caso similar: una solución hecha tomando como referencia los problemas de la Aduana Uruguaya se ve contrastada con los problemas de las Aduanas Chilena y Costarricense. Seguramente algún problema común lo resuelven mejor las otras aduanas.
Igual podríamos decir de la operativa de compras, con cabezas pensantes en Alcan, Fanapel, Cousa y Molinos San José.
Tenemos la materia prima para evolucionar y brindar mejores soluciones. No es un camino optativo, ya que si no lo hacemos nuevos clientes serán nuevos problemas de implantación.
Tenemos más de una experiencia acertada en soluciones implementadas para un cliente y recibidas con mayor alegría por otro...en mi opinión lo único que nos falta es hacer un esfuerzo consciente para incentivar esto.
¿ Cómo asegurar esta evolución ? No es tan sencillo como decirlo...tarea de todos los que estamos en contacto con la gente, quienes deberemos asegurar las condiciones para que este proceso se dé naturalmente .

Alejandro Carballal

PETROGLIFO: La idea de este medio es la de ser un distribuidor de noticias internas de CONCEPTO

La idea de este medio es la de ser un distribuidor de noticias internas de CONCEPTO, ya desde el primer año que trabajé para CONCEPTO, el equipo de desarrollo estaba distribuido en varias oficinas. Algunos en las oficinas de COUSA, otros en ALCAN, y otros que nunca se supo bien donde estaban... Ahora, son las oficinas en la DNA, La Empresa en Buschental y otros que siguen sin saberse bien donde están... La cosa es que esta distribución geográfica complica la comunicación y provoca que los que están en un sitio no se enteren de que es lo que pasa en los otros... El fin de este medio entonces, es el de ayudar a mantener la comunicación entre esos grupos.Esta no es la primera versión de PETROGLIFO, pero si es la primero que yo edito. Como siempre tratare de que sea lo mejor que se pueda, pero todos sabemos que no será lo buena que todos quisiéramos. Por lo que pido a todos los que tengan aportes, ideas o cualquier forma de critica constructiva a hacérmelas llegar. Y a los que tengas de las otras, guardárselas.


Alejandro Rinaldi