Tratamiento de datos remotos

Velneo
1

Hola a todos,

Como es el funcionamiento de tratamiento de cajas de datos remotas? Me explicaré con un par de ejemplos.

1.- Una aplicación que requiere tener x tablas en local, y x tablas en un servidor (puede darse el caso perfectamente, que quiera tener la aplicación en local con tablas de configuración y demás, y ciertos datos compartidos en un servidor con otros puestos por ejemplo)

2.- Una aplicación que se encuentra en un servidor, que requiere conectarse a una caja de datos que se encuentra en otro vServer en otro servidor. (por ejemplo, replicación de datos con un servidor central, centrales espejos, high availability).

Estoy mirando, y la verdad, no se me ocurre como hacer ésto (sin usar TCPIP y depender que exista una aplicación que haga de server, quiero acceder directamente a los datos sin intermediarios) , porque, las cajas de aplicación sólo veo que se comuniquen, con cajas de datos que se encuentran en ese mismo vServer, y no veo la posibilidad de cómo comunicarse con otras.

Esto es una limitación actual pero subsanable en próximas versiones? Es algo que no se podrá hacer?

Un saludo.

--
Giuseppe Luigi
http://www.lordzealon.com

 

 

2

Eso seria fenomenal y lo logico, de hecho creo  que se comento que se podría hacer mas adelante, ya veremos.......??????

pero hasta donde yo se, de momento nasti de plasti

un saludo

Miguel

3

Pues sí, estaría de lujo, a ver si lo implementan pronto..

4

Tienes las funciones remotas, que ya se que no es lo mismo, pero son muy potentes.

 

Un saludo

5

Supongo que estamos acostumbrándonos a que la herramienta suple muchas de nuestras necesidades sin necesidad de hacer aquello que, en cierta manera, es lo que mas nos fascina: programar.

 

Ningún sistema suplirá (afortunadamente) la necesidad de personas capaces y motivadas por ir mas allá de las limitaciones aparentes, por personas capaces e ilusionadas por ofrecer soluciones que supongan, además de lo económico, un motivo para seguir contratándolos: soluciones.

6

 @Innovadb

No hablo a corto plazo. No es algo que necesite ya, pero como ya he dicho en alguna ocasión, si me gustaría saber si está en planning por lo menos, o si no se piensa hacer algo así. Las funciones remotas, hasta donde yo entiendo, requieren de otra aplicación que "escuche", y lo que yo quiero, es conectarme a una caja de datos de un vServer, sin depender de otra aplicación.

Comenzar un proyecto grande, requiere de un análisis previo. Si tengo cierta información, puede que enfoque de una manera, pero, si sé, que en un futuro, ciertas carencias serán resueltas, puedo enfocarlo encarándolo al futuro hacia esas carencias por entonces resueltas. Mi propyecto, tengo que enfocarlo en necesidades del cliente, no en carencias de una herramienta.

Pero para todo ésto, Velneo tendría que ser transparente en la información . Que exista un Roadmap, un planning, (que existe, pero es interno de ellos) que se comunique qué es lo que está pensado hacerse, aunque no se comprometa en tiempos a corto plazo. Pero que se sepa algo, información es poder. Hace un año y algo me equivoqué comprando Windev, y precisamente, mi error, fué provocado por información mal transmitida (miento, la información fué bien transmitida, pero a medias..PCSOFT tiene un buen departamente de marketing)

Como comento, si Velneo hiciera acto de presencia en este hilo, y comentara "ésto se hará para el año que viene seguramente" (por ejemplo), pues yo puedo enfocar mi proyecto de una manera, porque quizás, lo que necesito, lo necesitaré dentro de un año igualmente, pero al menos, en la toma de decisiones, tengo información al respecto. Como digo, poder mirar un planning sobre qué cosas habrán, las que están en desarrollo, las que están aplazadas, las que están en proceso de análisis para su implantación etc... De esa manera, cualquier nuevo que llegue como yo, puede ver qué tiene en la cabeza Velneo, y si elige Velneo como plataforma, al menos hacerlo con información.

Si un director de proyecto, me pregunta:
"y como accedes a los datos en otro servidor?", y le contesto "pues hay que hacer una aplicación intermedia que recoja las peticiones", entonces, me tira la grapadora a la cabeza y me contesta que para eso se inventaron las RDBMS C/S,
"y no se puede acceder a los datos directamente?" --- "ahora mismo no"
"ah, pero en un futuro sí, no?"  --- "pues no lo sé"

Siento ser pesado con éste tema, pero es la realidad.

7

Hola.

Para acceder a los datos de un vServer remoto, puedes:

- Usar funciones remotas: vale, necesitas una aplicación que "reciba"... pero tener un vServer sólo con datos y sin ninguna aplicación no parece algo muy habitual. Lo puedes tener, pero seguro que tendrás una mínima caja de aplicación para poder consultar esos datos (sí, existe vDataClient, pero seguro que necesitas algo más)

- Usar protocolos TCP: lo mismo que lo anterior

- Usar acceso ODBC: quizá no es lo más rápido, pero ahora mismo es ya posible acceder a una caja de datos remota mediante ODBC (sólo desde un cliente en Windows, de momento).

Dadas las características de Velneo y cómo es su estructura interna, no *parece* (pero quién sabe) que en un futuro haya la posibilidad de acceder *directamente* a cajas de datos remotas de forma integrada... aunque Juan dejó caer en la presentación del año pasado que quizá se pueda hacer algo en este sentido (en concreto, lo que comentó es la posibilidad de visualizar datos de bases de datos externas directamente en objetos -rejillas- de Velneo, sin necesidad de importarlos previamente... si lo entendí bien, claro). No hay más datos de momento.

Saludos,

Fran Varona

 

image

image

8

Hola Fran

- Usar funciones remotas: vale, necesitas una aplicación que "reciba"...
pero tener un vServer sólo con datos y sin ninguna aplicación no parece
algo muy habitual. Lo puedes tener, pero seguro que tendrás una mínima
caja de aplicación para poder consultar esos datos (sí, existe
vDataClient, pero seguro que necesitas algo más)

Siento discrepar. Puede que necesite tener un vServer que sólo sirva datos, y las aplicaciones funcionen en local. Un servidor Linux rara vez dispone de las X instaladas, y sin las X, no hay vClient, ni caja de aplicación que valga. Además, tener una aplicación sólo en escucha, me obligaría a mantener una sesión abierta en el servidor. vServer debe funcionar de manera autónoma como un demonio/servicio sin depender de X ni nada (para administrarlo, para eso tenemos vAdmin).

- Usar protocolos TCP: lo mismo que lo anterior

No sé como funciona todo lo referente a comunicación TCP de Velneo, soy un profano con esta herramienta, pero me remito a mi anterior párrafo. Precsiamente, por la existencia de vClient, vAdmin, cloud computing, etc... en un servidor, puede que no tenga porqué tener una aplicación lanzada, deberiá poder interactuar con los datos y/o aplicaciones de un vServer atacando a él directamente. Ojo, es como opino que tendría que ser, que lo mismo, es distinto a como piensan sus desarrolladores que debe ser.

Dadas las características de Velneo y cómo es su estructura interna, no
*parece* (pero quién sabe) que en un futuro haya la posibilidad de
acceder *directamente* a cajas de datos remotas de forma integrada...
aunque Juan dejó caer en la presentación del año pasado que quizá se
pueda hacer algo en este sentido (en concreto, lo que comentó es la
posibilidad de visualizar datos de bases de datos externas directamente
en objetos -rejillas- de Velneo, sin necesidad de importarlos
previamente... si lo entendí bien, claro). No hay más datos de momento.

Precisamente, dado el diseño C/S de Velneo, debería ser posible lo que comento, por razones anteriormente mencionadas. Como comento, puedo necesitar un vServer sirviendo datos exclusivamente. MySql, Oracle, Firebrd, SQLServer, HyperFile... con cualquier lenguaje y BBDD es posible.

La potencía de Velneo radica en la compenetración Datos/aplicación, y sobre todo, en la potencia de la BBDD, pero precisamente, dada su "perfecta" abstracción, para una aplicación, debería ser irrelevante si los datos están en ese servidor, o en otro. Como sugerencia. La aplicación debería tener una especie de vinculación de datos, donde, digamos, en local (a nivel de servidor) tengo definida una tabla clientes, y trabajo con ella, pero esta tabla, realmente, quien la sirve es otro vServer. Puede darse el caso que los datos estén distribuidos en 3 localizaciones distintas, y de alguna manera vServer debe poder lidiar con éso. Si no, las aplicaciones Velneo no son escalables.

Quizás no sea el mejor ejemplo, pero mi intención es sólo lanzar la idea. Imagina que el sistema de "El Corte Inglés" estuviera montado en Velneo. Las aplicaciones tendrían que trabajar en LAN, pero el vServer tendría que replicar a servidores centrales por WAN. Mantener una aplicación exclusivamente para "escuchar" peticiones de 70 sedes exclusivamente, es un gasto de recursos innecesarios, pudiendo acceder directamente a la BBDD.

Un saludo.
--
Giuseppe Luigi
http://www.lordzealon.com

9

Hola.

Me parece bien tu planteamiento. Sólo un pequeño apunte: NO necesitas tener una sesión abierta en el servidor para poder utilizar funciones remotas o protocolos TCP o driver ODBC. Las dos primeras se conectan a una instancia de aplicación que esté instalada en vServer, y la tercera a una instancia de datos. Pero no tiene que haber ninguna sesión abierta. Esto resolvería una de las dificultades que comentas.

Por otro lado: dices que es un gasto de recursos innecesarios tener una aplicación sólo para "escuchar"... pero eso lo que tienes si pudieras acceder directamente a la BBDD, un interfaz/API/llámalo como quieras es, justamente, eso: una aplicación que escucha y responde. Ya existe uno (vServer responde a peticiones por ODBC) y te da la posibilidad de configurarte el tuyo particular (mediante funciones remotas / protocolos TCP).

Por supuesto que sería interesante poder acceder directamente a cajas de datos remotas en tiempo de desarrollo (aunque, si lo piensas, verías que en vDevelop tendrías que saber perfectamente la estructura de esas cajas... vamos, que tiene sus complicaciones). Simplemente, creo que hay otros acercamientos a la solución a ese problema que pueden ser válidos en algunas circunstancias.

Saludos,

Fran Varona

 

 

10

Hola de nuevo fran

NO necesitas tener una sesión abierta en el servidor para poder utilizar
funciones remotas o protocolos TCP o driver ODBC. Las dos primeras se
conectan a una instancia de aplicación que esté instalada en vServer, y
la tercera a una instancia de datos. Pero no tiene que haber ninguna
sesión abierta. Esto resolvería una de las dificultades que comentas.

Como dices, Funciones Remotas y TCp trabajan sobre una caja de aplicación, pero esta caja de aplicación, tendrá que estar abierta con un vClient, y para ello, es necesario tener la sesión abierta...o no es así? ODBC es lento, y por WAN, tendrá que ser lentísimo....

Por otro lado: dices que es un gasto de recursos innecesarios tener una
aplicación sólo para "escuchar"... pero eso lo que tienes si pudieras
acceder directamente a la BBDD, un interfaz/API/llámalo como quieras es,
justamente, eso: una aplicación que escucha y responde. Ya existe uno
(vServer responde a peticiones por ODBC) y te da la posibilidad de
configurarte el tuyo particular (mediante funciones remotas / protocolos
TCP).

Si, pero, por poner un ejemplo, no es lo mismo, acceder directamente a MySql, que tener que acceder a una aplicación, que transcriba las aplicaciones, que consulte a MySql, y me devuelva la respuesta. Con MySql accedes directamente y sería más rápido, además de ahorrarte el desarrollar una capa que traduzca todas las peticiones que podrías hacer directamente.

Por supuesto que sería interesante poder acceder directamente a cajas de
datos remotas en tiempo de desarrollo (aunque, si lo piensas, verías
que en vDevelop tendrías que saber perfectamente la estructura de esas
cajas... vamos, que tiene sus complicaciones). Simplemente, creo que hay
otros acercamientos a la solución a ese problema que pueden ser válidos
en algunas circunstancias.

Claro, pero siempre tienes que saber la estructura de las cajas al fin y al cabo, y vDevelop ya está preparado para recoger esa información. Si deseas conectarte con SAP, tienes que saber a qué te conectas, y qué quieres recuperar. Una cosa es la representación gráfica de la arquitectura de la tabla que perfectamente puede mostrarse en vDevelop, e internamente, a vDevelop le tiene que dar igual, si realmente la tabla está en ese vServer, o en un ordenador escondido en lo más profundo de Shangai. vDevelop no es el que trabaja con esa tabla, si no vClient<->vServer

Un saludo.

--
Giuseppe Luigi
http://www.lordzealon.com

11

Una pregunta, ¿por qué dices que te has equivocado con Windev?.

12

@glpunzi

 

No necesitas ningun vClient abierto, y las funciones pueden estar en la caja de datos o en la de aplicación.

 

Si te fijas es lo mismo hacer una consulta a un servidor remoto con sql, que ejecutar una funcion remota en velneo. Tu pides datos y la BBDD te los da. Incluso me atreveria a decir que las funciones remotas son mucho mas potentes, ya que en una función puedo hacer de todo, consultas, altas, bajas, modificaciones, filtrados etc...

 

Por otra parte no necesitas conocer la estructura de tablas, si yo hago una funcion que le paso como parámetro un DNI y me devuelve una cadena como esta: |nombre|apellidos|direccion|telefono|, tu no necesitas conocer la estructura, solo saber en que orden te devuelvo los datos.

 

Un saludo

13

@sonovision

Lo siento sonovisión, pero no me gustaría desvirtuar el hilo. Lo explico en mi blog: Desarrollo y toma de decisiones (Windev y Velneo) si te queda alguna duda házmelo saber por mail y encantado te responderé...

@innovadb

Eso no lo sabía. Como digo, soy nuevo por Velneo, y desconozco como trabaja, por eso preguntaba. Recuerdo, hace unos 5 años aprox.., cuando trabajaba en una consultora en Madrid, que uno de nuestros clientes, tenían una aplicación hecha en Velazquez Visual (de hecho fué la primera vez que oí ese nombre) y el servidor (no recuerdo si Windows 2000 o 2003) siempre debía mantener una sesión (y no recuerdo si lo que sería el vMotor, o una aplicación) abierta para que la aplicación funcionara en los puestos de trabajo.

Un saludo
--
Giuseppe Luigi
http://www.lordzealon.com

14

Hola.

Como bien te dice InnovaDb, no hace falta tener una sesión abierta. En la versión 6.x tenías que tener una sesión abierta en el equipo servidor, pero eso era porque vServer no era un servicio. Eso, afortunadamente, se acabó.

Saludos,

Fran Varona

 

15

Un aporte referente a lo del Roadmap es demasiado importante y necesario, si se esta comercializando la herramienta este punto es clave para apostar por un entorno de desarrollo.

Respecto a la replicacion de bd de forma transparente independiente de las funciones remotas, es el plus para los dbas, por q todo el proceso de mirror es controlado por los mismos servicios y me asegura una copia fiel en ambos servidores o cajas de datos y tener la posibilidad de cambiar rapidamente en caso ocurriese un desastre que no falta. Todo el control de la consistencia de bd es manejado directamente por los servicios, que hacer un backup es la solucion de momento es valida pero las necesidades de high available son por no decirlo impresindibles en un entorno saas y totalmente transparente para todos.

Atte.

Julio