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!!!