Refresco remoto - Señales remotas.


(ame) #1

Hola a todos,

 

No sé si el título del post es el más adecuado, o refleja con precisión lo que quiero hacer. El tema es el siguiente:

Partimos de dos proyectos de aplicación que heredan un proyecto de datos, es decir, ambas aplicaciones comparten datos. Hasta ahí bien, ¿verdad? De momento fácil. Ahora vamos a complicarlo algo más.

Como tengo dos aplicaciones, puedo ejecutarlas ambas por separado y simultáneamente, ¿no? Una aplicación desde un equipo, y la otra desde otro puesto, terminal, equipo, o como queráis. Las dos atacando a un servidor con vServer.

Pues bien, aquí ya empieza a complicarse la cosa y a aparecer el problema que tengo, el cual algunos estarán intuyendo ya.

Si desde un equipo realizo un alta de una ficha, y desde el otro equipo con la otra aplicación abierta, tengo por ejemplo en pantalla una rejilla visualizando todas las fichas de esa tabla, lógicamente el nuevo alta no se verá reflejado a menos que volvamos a lanzar la rejilla nuevamente. Esto en principio tiene fácil solución: si en lugar de lanzar la rejilla con el típico esquema "acción - disparar objetos - búsqueda - rejilla", dispararamos un formulario con un control objeto conteniendo una rejilla, y configurándole un timer, a cada período del timer ejecutaríamos un evento que hiciera un simple "interfaz: recalcular control", y ya lo tendríamos solucionado. Cada X segundos la rejilla se refrescaría apareciendo la nueva ficha.

Pero lo que no me gusta es tener que echar mano del timer por una sencilla razón: el valor del período no siempre resulta fácil de calcular, ya que conceptos como rendimiento y comodidad se ven enfrentados en este contexto. Lo ideal sería coger un valor bajo para el timer, de manera que a cada pocos instantes se refrescara la rejilla, el problema es que esto carga mucho el sistema y la red (peor aún si es en la nube). Si elegimos un valor más alto, podemos resolver el problema de rendimiento pero sin embargo, podríamos encontrarnos en situaciones en que el usuario que ejecuta la aplicación, vamos a llamarla "monitor", podría no estar viendo los datos actualizados en un determinado intervalo de tiempo que no fuera aceptable por exigencias del Sistema de Información. Pensad por un momento en una tienda en la que un cliente llama para preguntar si tienen un pantalón de la marca "X" y talla "Y", al que le responden "sí" cuando hace 5 minutos se vendió la última unidad de este pantalón.

Por consiguiente, mi pregunta es: ¿existe alguna forma de enviar señales entre aplicaciones? ¿O cómo podría refrescarse la rejilla de otra forma que no sea con un timer?

 

Un saludo.

 

José Luis.

 


([N1] Pepeto) #2

 

Haber si te vale esta solucion, por que realmente es complicado lo que planteas.

Crear una tabla intermedia donde podriamos grabar un unico registro por cada tabla que neceistaramos refrescar y que fuera comun a las 2 aplicaciones.

En dicha tabla, podriamos actualizar fecha y hora del ultimo registro grabado o modificado en cualquiera de las tablas comunes (las que necesiten refresco o todas incluso)

Con el timer, solo debes comprobar cada breve periodo de tiempo la fecha y la hora de la ultima actualizacion en la tabla que estas examinando en ese momento y comprobar con la fecha de la ultima actualizacion/refresco de la pantalla.

Si ha habido cambios posteriores en la tabla , refrescas la rejilla y si no , precisndes del refresco.

De esta forma el timer solo carga 1 registro en cada ejecucion y compurebas la fecha/hora de la ultima actualizacion.

Y solo si hay cambios , necesitaras volver a cargar la lista completa.

Espero haberme explicado bien, aunque no se si te servira como posible solucion

Un saludo.

Jose Luis.

P.D.

De todas formas, quiza seria bueno que Velneo incorporase una fucion que permitiese saber si ha habido cambios en una tabla posteriores a una fecha y hora.

La funcion podria ser tal que: HaHabidoCambiosEnLaTabla( Id-Tabla, Fecha, Hora )

Tela con el nombrecito de la funcion, solo es una parida mia.

:D

 


([N1] wikan) #3

Te podría valer jugar con el protocolo tcp. Con ello podrías avisar a la aplicación que han habido cambios y actualizar.

Sería poner un puerto a la escuche y que el servidor envie una señal cuando ha habido cambio en la tabla, mediante el proceso del tcp, modificas una variable, "Cambios", y con el timer compruebas esa variable, si está a uno, recálculas y la vuelves a poner a 0.


([N1] Albert Aixendri) #4

Tal como dice manuel.rd yo también pienso que la clave está en los objetos TCP. Estos son fáciles de usar y permiten procesar "inputs" externos. La única pequeña pega que puede haber es con el tema de los firewalls.

Albert.


(ame) #5

Buenos días,

 

Muchas gracias a los 3 por las ideas. Implementaré las dos y veré cuál de ellas me viene mejor. No obstante, veo que en ambas propuestas seguimos usando el timer, por lo que deduzco que de momento no hay manera de que una aplicación avise a otra en un determinado instante dado. De todas formas aunque se siga usando el timer, se añade la mejora de que no es lo mismo refrescar una tabla entera que puede tener una cantidad considerable de registros que mirar cada cierto tiempo una variable si ha sido modificada o no, y en tal caso, volver a leer la tabla.

 

Por último, os diré que probé una alternativa que hubiera sido la solución ideal si no fuera por una cuestión que os comento ahora. Lo que hice fue crear una acción que disparaba una señal, y a raíz de aquí, dos cosas:

1.- En el formulario donde se creaba el nuevo registro, al botón correspondiente al alta le cambié de "ejecutar evento" a "ejecutar acción" y puse la acción que dispara la señal. En este mismo formulario añadí la conexión a evento asociada a la señal disparada por dicha acción, y el evento a ejecutar era el evento que antes ejecutaba directamente el botón. Hasta aquí sigo teniendo la misma funcionalidad de dar un alta pero por otra vía distinta. Sin problemas.

2.- El problema viene aquí. En el formulario donde se muestra la rejilla que tiene que refrescarse para mostrar el nuevo alta, hago casi el mismo proceso. Recordad, como dije en mi primer post, que este formulario pertenece a otro proyecto de aplicación, y que se ejecuta en otro puesto que es digamos el que "monitoriza" lo que se hace en el otro puesto.

Pues bien, creo el enganche a evento asociándolo a la misma acción (esto es posible porque hereda del proyecto donde he creado la acción que dispara la señal), y como evento ejecuto uno que simplemente hace el "interfaz recalcular control".

Y he aquí la pega, las señales disparadas, por lo que he podido comprobar, son conocidas sólo en el ámbito de ejecución donde son disparadas. Algo parecido ocurre con las variables globales, que son globales para cualquier punto de la aplicación, pero no se comparten entre por ejemplo 5 instancias de una misma aplicación que tengamos corriendo simultáneamente. No digo que esté mal, que me parece obvio que sea así, sino que lo que quiero decir es que no estaría mal disponer de un mecanismo de señales que se pudieran enviar entre varias instancias, ya que nos sería muy útil si queremos desarrollar sistemas que monitorizan procesos.

 

Un saludo.

 

José Luis.

 

 

 


([N3] blavan) #6

Sobre el comentario HA HABIDO CAMBIOS EN LA TABLA.. pienso que se puede resolver con una tabla maestra de un único registro donde se guarda la fecha y hora del último cambio en una tabla y más información que consideremos necesaria

Chequeando con un timer la información de esa tabla maestra tanto una aplicación como la otra puede actuar en consecuencia. apoyado  con un campo e indice SIN CHEQUEAR

Lo que no entiendo es que el usuario de una aplicación tenga la necesidad de ver la información actualizada en la rejilla sin manipular para nada la rejilla, eso podría darse con muy pocos registros, pero normalmente haya que desplazarse, reordenar, buscar.. y ahí se puede activar un evento Simple Click etc.. ¿no?

Perdón no me las doy de listo es para generar coloquio y aprender 

Es válido?


(ame) #7

Hola,

 

Imagínate que la aplicación se ejecuta en una terminal que carece de dispositivos de entrada como el ratón o el teclado, y simplemente consta de una pantalla para monitorizar una serie de procesos. Esa es la cuestión.

 

Un saludo.


([N1] wikan) #8

No habia caído en eso.

Se supone que ambas aplicaciones tiran del mismo proyecto de datos. Por lo que si comparten tablas también deberían compartir variables globales en disco.

Si activas una variable booleana cuando hay un cambio, con el timer puedes comprobar esa variable.

¿Es verdad que no se comparten esas variables?


(ame) #9

Hola Manuel,

 

Pues lo tengo que probar, pero me pareció leer por ahí que si las instancias lo ejecutan usuarios distintos, entonces cada usuario tiene sus variables globales propias.

 

Saludos.

 

José Luis.


([N1] wikan) #10

Siendo en disco debe ser compartida por todos los usuarios.

De no ser así, cosa que vería mal, como han dicho, con una tabla con un solo registro consigues el mismo efecto.


(ame) #11

Venga, lo voy a probar y ya os cuento, gracias.