Copia de seguridad remota

Hace más de un año comenté cómo planeaba y ejecutaba las copias de seguridad en el vServer.

Dije además que enviaba las copias de seguridad a otros servidores remotos para salvaguardar la información de una forma más efectiva, hoy veremos cómo.

Supongamos el caso más sencillo; un vServer y una sola aplicación.

Supongamos también que en el servidor hemos programado una sola tarea de copia de seguridad de la aplicación que cada día a la misma hora machaca la copia del día anterior.

Para acabar de definir el escenario necesitaremos otro vServer en otro lugar que llamaremos remoto, con un recurso compartido (nombre asignado a una carpeta física en disco) al que tiene acceso y control total el usuario SDV.

Ya lo tenemos todo.

Veamos cómo conseguir que nuestra copia de seguridad diaria se copie también en el equipo remoto.

Soy muy amigo de las tablas de configuración y suelo tener en cada aplicación una tabla CFG con un sólo registro conteniendo datos redundantes como la ip-pública del servidor donde publico la aplicación, alias que le pongo a la aplicación, nombre del usuario SDV, su contraseña, etc. Siempre viene bien poder tenerlos a mano dentro de algún proceso y así parametrizo el proceso usando los datos de CFG en vez de tenerlos declarados dentro del proceso. Es mejor cambiar datos de una tabla que editar el proceso si alguno de estos datos cambian.

Así pues declaro una tabla CFG con los siguientes campos: ip pública del servidor remoto, nombre del usuario sdv remoto, contraseña del usuario sdv, nombre del recurso compartido remoto (donde voy a guardar la copia de seguridad remota), y senda completa (senda, nombre y extensión) del archivo vcs que voy a mandar.

Si estos datos suelen ser siempre los mismos, incluso podemos ponerlos como contenido inicial de los campos, en el proceso ONINIT-MAP-SERVER cargamos la tabla CFG por el índice Código, vemos si no hay registros (if !n) y hacemos un Alta directa en la tabla CFG.

Si la tabla CFG es de un sólo registro, para su edición lanzamos un proceso que carga la tabla CFG por el índice Código, selecciona ficha por posición 1, lee la ficha seleccionada y añade como retorno el formulario de edición de la tabla.

Para capturar la senda completa del archivo vcs que voy a mandar uso un proceso como el siguiente:

El proceso con origen una ficha de la tabla CFG, presenta el diálogo para seleccionar un fichero, si aceptan el diálogo y han indicado una ruta, me la guardo ( fAjustaSenda convierte las barras \ en dobles barras \\ ).

Como vamos a enviar periódicamente información entre servidores preparo una tabla de ENVIOS. En esta tabla anotaremos los datos de cada envío; servidor remoto a donde se envía, usuario y contraseña que usamos para ello, fecha y hora del envío, y su resultado como booleano, así como la fecha y hora de finalización para controlar cuánto tardamos.

Ahora sólo queda hacer un proceso no-privado para poder programarlo como tarea en vServer.

En este proceso sin origen cargamos la tabla CFG para tomar los datos que necesitamos del registro 1; ip pública del servidor remoto, nombre del usuario sdv, su contraseña, carpeta remota donde hacer el envío, y de la senda del archivo a enviar nos quedamos con su nombre y extensión (fExtraerNombreExtDeSenda) que luego usaremos añadiéndole un prefijo.

A continuación en el proceso damos un Alta directa en la tabla ENVIOS, anotando en el Pre los datos necesarios, y quedándonos en el Post con el Código del registro de envío.

Preparo además una variable local fecha para guardar la Fecha del envío formateada AAMMDD para añadirla como prefijo al nombre y extensión del archivo que mandamos en el servidor remoto, así no machacaré las copias de seguridad del servidor remoto cada día, si no que las iré guardando todas, todas, todas, con su fecha en el nombre.

Sólo queda componer en el proceso la vrl-destino, es decir, en qué carpeta del servidor remoto vamos a guardar y con qué nombre la copia de seguridad, en qué servidor y con qué usuario y contraseña, mandarlo, y en función del resultado apuntarlo en la tabla ENVIOS.

Y eso es todo amigos.

Sólo queda programar como tarea en el servidor este proceso para que se ejecute cada día tras la copia de seguridad y ya está. Nuestros datos doblemente a buen resguardo.

Os propondría variaciones sobre el tema como tener varios registros en la tabla de configuración, es decir, distintos servidores a los que mandar la copia, o bien todos los días a todos, o cada día a uno, e incluso mandar copias de diferentes carpetas origen (lunes, martes, miércoles, etc...).

Usando una táctica similar se puede mandar también el mapa relativo a la copia de seguridad, archivos de configuración de vServer, etc.

Life is soft!

Google & Velneo (ii)

Desarrollas aplicaciones web?

Usas bibliotecas javascript como jQuery, prototype, script.aculo.us, MooTools o dojo?

Si es así y no quieres perder la cabeza manteniendo las versiones usadas en todos tus proyectos, Google ha sacado un nuevo servicio en GoogleCode que sirve las últimas versiones de todas estas bibliotecas.

Sólo necesitas enlazar con ellas a través de tu APIkey y Google te las sirve, además comprimidas, de forma que su carga está optimizada, y tus páginas liberadas de un gran peso.

Aquí os dejo el enlace

http://code.google.com/apis/ajaxlibs/

Life is soft!!!

Google & Velneo

Hace tiempo que no posteo nada, y es que estoy tan ocupado desarrollando soluciones de gestión empresariales y web con Velneo V6 que no tengo casi tiempo para más.

Esta noche he sacado un hueco y me gustaría comentar mis últimas experiencias de desarrollo en Velneo V6 integrando soluciones Google.


Está claro que Velneo V6 deja bastante que desear a nivel gráfico, informes, conectividad, etc, pero he descubierto que se lleva muy bien con Google para paliar esas deficiencias.

A nivel de informes, la herramienta que incorpora Velneo V6 es bastante limitada, pocos objetos y poco configurables. Desde hace tiempo intento inculcar en la comunidad el concepto de informes html en Velneo. Son informes xhtml+css lanzados desde la aplicación.

Este tipo de informes son al fin y al cabo como cualquier página web lanzada desde Velneo; un proceso accesible web, que como tal tiene acceso a todas las tablas de la aplicación para componer un informe sin limitaciones impuestas por el origen del proceso; ningún origen, cabecera, líneas, da igual, estamos en un proceso y podemos hacer lo que queramos.

En el proceso podemos cargar datos de una tabla, de otra, de muchas..., componemos el html resultante a base de componentes html, y el resultado se devuelve como Añadir retorno texto.

La maquetación corre a cargo del css que da forma al xhtml generado, y ya tenemos un informe (página html) que se previsualiza siempre y se puede imprimir a gusto del usuario.

Los informes nativos Velneo disponen de gráficos, rejillas de histórico, etc, para su composición, y a nivel de gráficos encontré muy gratificante el API de GoogleCharts.

Es un API gratuita, sólo hay que tener una cuenta Google, y se ataca de forma muy sencilla:

1. Recopilas los datos a representar
2. Los escalas y trasladas en función del número de datos y la codificación correspondiente
3. Eliges el tipo de gráfico
   
4. Rellenas datos accesorios; ejes, rótulos, títulos, tipos de punto, línea, etc
5. Mandas la petición a GoogleCharts y te devuelve un png del gráfico solicitado
6. Este png se inserta como img dentro del informe html y a correr

Una de mis ocupaciones anteriores consistía en desarrollar soluciones GIS personalizadas usando MapInfo. Es un entorno muy profesional y especializado que necesita de técnicos formados para su mantenimiento.

Hace años integré MapInfo con Velneo, pero era una solución muy cara a nivel de licencias de desarrollo. Investigando GoogleCode encontré el API de GoogleMaps y GoogleEarth, gratuítas igualmente, que permiten mandar un formato KML a Google, que no es más que un formato XML con los datos a representar gráficamente en el mapa, y recibes un formáto gráfico mapa de GoogleMaps o GoogleEarth interactivo que muestra tus datos en el mapa.

Su uso es tan sencillo como el de GoogleMaps y no son necesarios técnicos especialistas para su mantenimiento ya que representa automáticamente lo que hay en la base de datos y para ello sólo es necesario rellenar un formulario de alta o modificación.

Y es todo gratuíto mientras sea público.

Así surgió mi primer GIS con Velneo. GoogleMaps se encarga de representar los datos de Velneo en el mapa, y si lo quieres más espectacular le encargas la tarea a GoogleEarth.

A nivel de conectividad a la hora de compartir documentación, GoogleDocs nos permite generar documentos "Word", "Excel", "PowerPoint" en la nube y compartirlos con los usuarios autorizados.

Hay API's disponibles para todo ello en GoogleCode, fáciles de estudiar e implementar en Velneo y que dotan a nuestras aplicaciones de nuevas funcionalidades con un costo realmente bajo: GRATIS.

Así sigo ampliando las capacidades de la herramienta de desarrollo que elegí hace años, Velneo, de la cual aún no he encontrado el techo (esto no lo puedo hacer), y sigo dando años de vida a soluciones V6, utilizado código abierto y gratuíto, en este caso el de Google.

Life is soft!!!

vTiger

Siempre se ha dicho que Velneo peca de una interfaz de usuario muy pobre y puede que sea así.

Disponemos de pocas posibilidades a la hora de hacer un interfaz vistoso, con muchos efectos y colores, pero si nos esmeramos usando esas pocas posibilidades podemos obtener algo bastante al gusto del usuario.

Cuando miro ahora alguna de mis primeras aplicaciones me parecen francamente horribles, en cuanto al interfaz de usuario al menos; fuentes poco acertadas, colores demasiado llamativos, disposición de elementos poco pensada, etc, en definitiva, una mala experiencia para el usuario.

El interfaz y la usuabilidad de las aplicaciones es un tema muy importante, y más ahora que viene la V7 multiplataforma y vamos a poder entrar en el mercado de usuarios acostumbrados a otro aspecto para sus aplicaciones; linux, mac, etc.

Si nos lo proponemos, con una cuidadosa preparación y unos pocos elementos podemos ir adaptando el aspecto de nuestras aplicaciones hacia ese nuevo mercado que se nos abre.

El siguiente ejemplo es un formulario V6 hecho a partir de una captura de pantalla del OSX-Tiger, tratado con mucho mimo con Photoshop para que no pese, y ejecutado con la V6 en un Windows 2000 Professional.


Usa los colores básicos del OSX-Tiger, fuentes similares, botones al estilo Mac y disposición de elementos similar al OSX-Tiger, para no despistar al usuario Mac.

Así que, aunque no podemos hacerlo todo, sí que podemos hacer bastantes cosas para que el usuario tenga una experiencia agradable y no se encuentre perdido en nuestras aplicaciones Velneo.

Life is Soft!!!

Errores en Velneo

Contrariamente a lo que puede sugerir el título de esta entrada del blog, no voy a denunciar un error o bug de Velneo como entorno de desarrollo, voy a exponer un error de programación en el que ya he caído más de una vez, así a vosotros os servirá de experiencia y a mí de recordatorio para no volver a repetirlo.

Un Cargar Lista por un índice de tipo Palabras o Trozos de palabras, resolviendo el índice por alguna de sus partes no funciona.

No es que no funcione, es que parte el motor.

Life is soft!

Copias de seguridad

En las aplicaciones Velneo que instalo en clientes siempre monto un sistema de copias de seguridad programado en el vServer de la siguiente forma.

Creo una carpeta CopiaSeguridad, a poder ser en un disco físico diferente de aquel donde reside la aplicación (una segunda unidad, una unidad mapeada, etc). Si no puede ser en otro disco, la creo en un directorio diferente al de la aplicación.

Dentro de esa carpeta creo esta serie de subcarpetas; 01-lunes, 02-martes, 03-miercoles, 04-jueves, 05-viernes, 06-sabado y 07-domingo. Le pongo ese nombre a las carpetas para que salgan ordenadas alfabéticamente por día de la semana.

Creo una serie de tareas programadas en el servidor para que semanalmente se realice una copia de seguridad en la carpeta correspondiente; una para los lunes en la carpeta 01-lunes, otra los martes en la carpeta 02-martes, etc.

Como hora de la copia elijo un horario libre de carga y enganches en el servidor, normalmente al finalizar la jornada laboral o por la noche.

Así planteado, el lunes por la noche se realiza copia de seguridad de los datos de la aplicación en la carpeta 01-lunes, el martes en la 02-martes, etc, de forma que si las cosas fuesen muy mal, y nadie se diese cuenta, podría tirar hasta de siete copias de seguridad con un día de diferencia entre cada una de ellas, es decir tengo un colchón de una semana de datos.

Como la copia que realiza vServer es sólo de datos (vcs) hay que ingeniarse un sistema para junto con los datos guardar también la versión del mapa, por si hay que restaurar y se ha modificado el código, así como los ficheros de variables y configuración por ser estrictos.

Adicionalmente, como Velneo nos da esa facilidad, en instalaciones críticas añado la funcionalidad de envío de la copia de seguridad a un servidor remoto mediante SDV, así dispongo de esas copias en otro servidor Velneo por si ocurre alguna hecatombe como que casquen todos los discos duros a la vez, se quemen en un incendio todos los ordenadores o algún informático avezado restaure el sistema a una fecha tres meses anterior.

Life is Soft!

Funciones remotas

Las funciones remotas son esas grandes desconocidas de Velneo, funciones normales y corrientes pero que tienen marcado el check accesible VRPC.

Este hecho permite que sean ejecutadas de forma remota desde otros servidores Velneo invocándolas con un simple

Set -> fr,fEjecutarFuncionRemota( servidor-remoto, alias-aplicacion, funcion-remota, pwd-fr, parametro1, parametro2, ... )

donde

• servidor-remoto es la ip-pública o nombre del servidor remoto donde se va a ejecutar la función remota
• alias-aplicación es el alias con el cual está publicada la aplicación que contiene la función remota que se va a ejecutar en el servidor remoto
• funcion-remota es el nombre de la función accesible VRPC a ejecutar
• pwd-fr es la contraseña de funciones remotas definida en el servidor remoto para la aplicación correspondiente
• parametro1, parametro2, ... son los diferentes parámetros que puede recibir la función remota separados por comas

Algo tan simple y sencillo como esto dota a nuestras aplicaciones Velneo de una potencia inusitada, permitiéndonos actualización de datos online desde sitios remotos, replicación de servidores en caliente, consolidación de datos de sucursales en una central en tiempo real, o el uso que realmente se nos ocurra.

Una función remota siempre se va a ejecutar en un servidor Velneo, pero su invocación puede ser desde una aplicación publicada en otro servidor Velneo o desde una aplicación cliente ejecutandose en monopuesto, así un portátil trabajando en local en el coche de un comercial puede comunicar al servidor Velneo de la central las ventas que está realizando, siempre que disponga de conexión a internet, y podría incluso bajarse a local las variaciones de tarifa que
necesitase.

Una función remota, como cualquier otra función en Velneo tiene un retorno. Ese retorno puede ser un simple 1 si se ha ejecutado, un parámetro resultado de un cálculo o extracción de la base de datos, o una ristra de parámetros separados por punto y coma por ejemplo para tener como respuesta un registro entero de una tabla de la base de datos.

Si la función remota no tiene definido un retorno explícito la variable local utilizada para su invocación contendrá un 1 en caso de haberse ejecutado y un 0 en caso contrario.

Un par de cosas a tener en cuenta: el alias-aplicacion y funcion-remota en mayúsculas tanto en su definición como en su invocación, y así nos evitamos problemas.

Condiciones a cumplir con las funciones remotas:

1. Una función remota entre servidores distintos que vaya a transaccionar, debe transaccionar ella misma.
2. Una función remota contra el propio servidor que la invoca que vaya a transaccionar, no debe transaccionar ella misma.

Aquí alguien se puede preguntar; una función remota contra el propio servidor?!! Pues sí. En entornos de desarrollo, para probar una aplicación que ejecuta funciones remotas contra un servidor, si sólo dispones de un servidor para pruebas deberás ejecutar las funciones remotas contra el propio servidor, y en entornos de producción reales yo me he encontrado varios casos donde la ejecución de una función remota contra el propio servidor me ha solucionado más de un problema; enlace gestión-contabilidad, mantenimiento unificado de tablas maestras, etc.

En estos casos hay que evitar que la función remota transaccione sacando la parte del proceso que transacciona a funciones que son llamadas desde la propia función remota.

Hasta aquí hemos visto superficialmente las funciones remotas, su uso y su potencial que vemos que es tremendamente esperanzador ya que nos permite hacer prácticamente todo lo que nos podamos imaginar entre dos aplicaciones Velneo.

Ahora la pega; dos servidores Velneo no pueden ejecutar funciones remotas simultáneas entre ellos, es decir, el servidor 1 no puede lanzar una función remota contra el servidor 2 y a su vez el servidor 2 sobre el servidor 1.

Puede parecer un caso raro y que no vaya a darse nunca, pero en la práctica se da, muy a nuestro pesar. La realidad supera con creces cualquier ficción.

Qué debemos hacer en este caso? Establecer un semáforo, una variable booleana global en disco que condicione la ejecución de las funciones remotas para evitar el "fuego cruzado" entre servidores.

En caso contrario nos encontraremos con dos servidores Velneo bloqueados hasta que uno de ellos se venga abajo. Al tirar abajo uno de los servidores, el otro se recupera y continúa su ejecución como si no hubiese pasado nada.

Como no existe una función específica para acceder al estado del semáforo propio de Velneo al ejecutar funciones remotas, debemos crear y gestionar el nuestro propio. Para acceder al estado del semáforo del servidor remoto lo más sencillo es diseñar un protocolo TCP que informe al otro servidor del estado del semáforo de funciones remotas.

Si la ejecución de la función remota consistiese en la simple petición de un parámetro al otro servidor, como ya tenemos un protocolo TCP establecido entre ambos servidores para la gestión del semáforo, podríamos utilizar el propio protocolo para la transmisión de ese parámetro entre servidores y ahorrarnos la función remota, y el posible problema del "fuego cruzado".

Life is soft!!!

vAccessForm

Hace poco surgió en el foro de Velneo una cuestión: "Cómo puedo poner en un formulario de edición de fichas los típicos botones de Access para ir a la primera y última ficha?"

Al principio me extrañó ya que en Velneo hay una y mil formas más eficaces de navegar por los registros de una tabla que con los botoncitos de Access.

En Velneo puede haber muchos primeros o últimos o anteriores o posteriores; por qué índices quieres que calcule el anterior?, la anterior factura del mismo cliente?, la siguiente factura más cara?, la anterior por fecha? o la siguiente por el segundo apellido del cliente?.

Pero luego me dije, y por qué no?, aunque sea por puro divertimento Velneano vamos a hacerlo.

Empecé a garabatear las diferentes posibilidades; por proceso, por puntero singular de plural, por puntero a hermano...

Defensor como soy de lo simple decidí que no debía ser por proceso y que la solución debería estar integrada en la parte de la bd. Lo comenté con Agustín e hicimos las primeras pruebas pero ocurrió lo de siempre, procesos...

Publicamos dos soluciones no óptimas en el foro y la maestría, buen hacer, serenidad y sencillez de Paco vino a despejar el campo.

En unos 2,5 segundos había pillado la idea, el mapa, lo modificó, lo dejó funcionando y lo dejó de vuelta en el foro, acompañado de unas sabias palabras:

La respuesta no esta 'ahí afuera', la respuesta está en los índices

Sé que me puedo poner pesado pero no me voy a cansar de repetirlo una y otra vez; estructura, relaciones, índices, triggers, ahí está la solución a todos nuestros problemas. Si hay algo que no haces ahí pregúntate por qué?; no sabes hacerlo? o no se te había ocurrido? o no puedes realmente?

Siempre que se pueda hacer en las tablas, ahí se debe hacer. Así independizas la funcionalidad de la apariencia.

No soy amigo de los procesos en formularios. No me gustan los procesos en pérdida o ganancia de foco, prefiero no usar procesos a la apertura o creación de un formulario, o procesos previos al aceptar, para hacer según qué cosas.

Cuando los uso tiendo a pensar que o mi estructura de bd no es óptima o no he exprimido a fondo la parte de definición de la bd.

Después del rollo filosófico vamos al grano y veamos cómo hacer una relación puntero a hermano que desde cualquier registro de una tabla nos lleve al primero o al último.

Lo primero es la estructura de la tabla.


Vemos que es una tabla cualquiera con los punteros a hermano anterior y siguiente que te crea Velneo cuando le dices Campos - Crear puntero a hermano,


tenemos un campo Extremo que es un booleano que dice si el registro es un extremo de la tabla, con contenido inicial a Sí,

y un proceso Anterior a un alta de ficha que fija el contenido de Extremo a Sí sólo para los extremos reales.


Además tenemos dos campos puntero a hermano más; Primero y Último.

Vemos que los punteros Primero y Último usan para su resolución el índice Extremo, y ese es el fundamento de toda esta historia; el índice.

Cómo es ese índice Extremo?

Es un índice acepta repetidas sobre el campo Código condicionado a que el booleano Extremo sea Sí.

Qué hace este índice? Como al dar de alta un registro el trigger vuelve a fijar los extremos sólo a Sí, la condición de indexación de este índice hace que cualquier registro de la tabla sólo tenga un hermano anterior extremo y sólo uno posterior extremo, así la resolución del puntero a hermano anterior y posterior por este índice nos lleva de forma directa al primer y último registro de la tabla respectívamente.


Simple y sencillo como Velneo.

Life is Soft!

Servidor parado, servidor trabajando...

Por una de esas casualidades el otro día me dí cuenta de que podemos hacer trabajar al vServer aún teniendolo parado.

En mi casa tengo configurado el servidor para que no se ponga a la escucha al ejecutar el programa, es decir, arranco el servidor pero está parado.


Y en un mapa experimental donde tenía seis tablas; tres con datos y tres vacías, me dió por en el ONINIT-MAPSERVER cargar secuencialmente cada una de las tres tablas por uno de sus índices y ejecutar un tubo de lista entre cada una de las tablas con datos y su respectiva homóloga sin datos. Además, luego apuntaba una serie de punteros entre las tablas recién rellenadas.

Para mi sorpresa, al abrir la aplicación en el servidor parado, este empezó a realizar el trasvase de datos entre las tablas, para finalizar teniendo las tablas llenas y con los punteros creados, todo ello estando el servidor parado.

Puede ser una tontería o puro desconocimiento del funcionamiento de vServer, pero me resultó ciertamente sorprendente y aquí lo comento por si alguno de vosotros le puede ver la utilidad.

Life is soft!