Saltar al contenido principal
Versión: Siguiente

Cliente/Servidor

Las aplicaciones 4D Desktop pueden utilizarse en una configuración Cliente/Servidor, ya sea como aplicaciones combinadas cliente/servidor o como proyectos remotos.

  • Las aplicaciones cliente/servidor fusionadas son generadas por el gestor de creación de aplicaciones. Se utilizan para el despliegue de aplicaciones.

  • Los proyectos remotos son archivos .4DProject abiertos por 4D Server y a los que se accede con 4D en modo remoto. El servidor envía una versión .4dz del proyecto (formato comprimido) al 4D remoto, por lo que los archivos de estructura son de sólo lectura. Esta configuración se suele utilizar para probar la aplicación.

La conexión a un proyecto remoto desde la misma máquina que 4D Server permite modificar los archivos del proyecto. Esta funcionalidad específica permite desarrollar una aplicación cliente/servidor en el mismo contexto del despliegue.

Abrir una aplicación cliente/servidor fusionada​

Una aplicación cliente/servidor fusionada se personaliza y su puesta en marcha se simplifica:

  • Para lanzar la parte del servidor, el usuario simplemente hace doble clic en la aplicación servidor. No es necesario seleccionar el archivo proyecto.
  • Para lanzar la parte cliente, el usuario simplemente hace doble clic en la aplicación cliente, que se conecta directamente a la aplicación servidor.

Estos principios se detallan en la página Creación de aplicaciones.

Abrir un proyecto remoto​

La primera vez que se conecte a un proyecto 4D Server a través de un 4D remoto, normalmente utilizará la caja de diálogo de conexión estándar. Cada vez que 4D realiza una acción Guardar todo desde el entorno de diseño (explícitamente desde el menú Archivo o implícitamente al cambiar al modo aplicación, por ejemplo), 4D Server recarga sincronizadamente los archivos del proyecto.

Para conectarse remotamente a un proyecto 4D Server:

  1. Haga una de las siguientes cosas:
    • Seleccione Conectar a 4D Server en la caja de diálogo del asistente de bienvenida
    • Seleccione Abrir/Proyecto remoto... desde el menú Archivo o del botónAbrir de la barra de herramientas.

Aparece el diálogo de conexión de 4D Server. Este diálogo tiene tres pestañas: Reciente, Disponible y Personalizado.

Si 4D Server está conectado a la misma subred que el 4D remoto, seleccione Disponible. 4D Server incluye un sistema de difusión integrado que, por defecto, publica el nombre de los proyectos 4D Server disponibles en la red. La lista se ordena por orden de aparición y se actualiza dinámicamente.

Para conectarse a un servidor de la lista, haga doble clic en su nombre o selecciónelo y presione el botón Aceptar.

Si el proyecto publicado no aparece en la lista Disponible, seleccione Personalizado. La página Personalizada le permite conectarse a un servidor publicado en la red utilizando su dirección de red y asignándole un nombre personalizado.

  • Nombre del proyecto: define el nombre local del proyecto 4D Server. Este nombre se utilizará en la página Reciente cuando se haga referencia al proyecto.
  • Dirección red: la dirección IP de la máquina donde se lanzó el 4D Server.
    • Si dos servidores se ejecutan simultáneamente en la misma máquina, la dirección IP debe ir seguida de dos puntos y del número de puerto, por ejemplo: 192.168.92.104:19814.
    • Por defecto, el puerto de publicación de un 4D Server es el 19813. Este número puede modificarse en los parámetros del proyecto.

La opción Activar el modo desarrollo abre la conexión remota en un modo de lectura/escritura especial y requiere acceder a la carpeta del proyecto desde el 4D remoto.

Una vez que esta página asigna un servidor, al hacer clic en el botón Aceptar podrá conectarse al servidor.

Una vez establecida la conexión con el servidor, el proyecto remoto aparecerá en la pestaña Recientes.

Actualización de los archivos del proyecto en el servidor​

4D Server crea y envía automáticamente a las máquinas remotas una versión .4dz del archivo proyecto .4DProject (no comprimido) en modo interpretado.

  • Una versión .4dz actualizada del proyecto se produce automáticamente cuando es necesario, *es decir, *cuando el proyecto ha sido modificado y recargado por 4D Server. El proyecto se recarga:
    • automáticamente, cuando la ventana de la aplicación 4D Server pasa al frente del sistema operativo o cuando la aplicación 4D en la misma máquina guarda una modificación (ver abajo).
    • cuando el comando RELOAD PROJECT es ejecutado. Llamar a este comando es necesario cuando, por ejemplo, se ha sacado una nueva versión del proyecto desde la plataforma de control de fuentes.

Actualización de los archivos de proyecto en las máquinas remotas​

Cuando se ha producido una versión .4dz actualizada del proyecto en 4D Server, las máquinas 4D remotas conectadas deben cerrar la sesión y volver a conectarse a 4D Server para poder beneficiarse de la versión actualizada.

Modo desarrollo​

El modo Desarrollo en el servidor 4D es un modo especial de apertura de proyectos que permite el acceso de lectura/escritura para aplicaciones 4D remotas conectadas. El proyecto debe estar disponible en modo interpretado.

Este modo permite que uno o varios desarrolladores trabajen simultáneamente en el mismo proyecto en el entorno Diseño. Cuando se abre un proyecto en modo Desarrollo:

  • Los archivos de proyecto están disponibles en lectura/escritura para que pueda editar métodos, formularios, etc.
  • Varios desarrolladores 4D remotos pueden abrir simultáneamente los mismos archivos del proyecto interpretado y editarlos. Un sistema de bloqueo automático impide el acceso simultáneo a un mismo recurso.
  • Las modificaciones se ponen a disposición de todos los desarrolladores remotos. Tenga en cuenta, sin embargo, que no hay un envío automático a los desarrolladores remotos, sino que tienen que actualizar para obtener las últimas versiones de los archivos (se realiza una actualización cada vez que el desarrollador pasa del modo diseño al modo aplicación, por ejemplo, o selecciona Guardar todo en el menú Archivo).

Para utilizar este modo, seleccione la opción Activar modo de desarrollo en el cuadro de diálogo de conexión desde su 4D remoto. Se le pedirá Seleccionar el archivo de proyecto 4D: debe seleccionar el archivo.project que 4D Server ha abierto. Si selecciona un archivo diferente, un cuadro de diálogo de alerta le avisa de que el modo de desarrollo no está disponible. Esto significa que el 4D remoto debe tener acceso a la carpeta del proyecto a través de la red (toda la carpeta del proyecto debe ser compartida, es decir, la carpeta raíz del proyecto).

caution

Por razones de rendimiento con esta configuración, se recomienda encarecidamente que la carpeta del proyecto se almacene en un servidor de archivos dedicado (por ejemplo, un NAS) en una red local.

nota

Cuando tanto el servidor como el 4D remoto están en la misma máquina, se aplican reglas adicionales.

He aquí un resumen de la arquitectura del modo de desarrollo:

Compatibilidad

Esta funcionalidad está diseñada para equipos de desarrollo de tamaño pequeño acostumbrados a trabajar con bases de datos binarias y que desean beneficiarse de las funciones del proyecto manteniendo su organización actual. Sin embargo, para el desarrollo multiusuario en proyectos 4D, recomendamos utilizar una arquitectura estándar en la que los desarrolladores trabajen en su máquina y gestionen su trabajo utilizando herramientas de repositorio de control de código fuente (Git, SVN, etc.). Esta organización ofrece una gran flexibilidad al permitir a los desarrolladores trabajar en distintas ramas y comparar, fusionar o revertir modificaciones.

Entrada de blog relacionada

Desarrollo simultáneo en 4D Server en modo proyecto

Utilizar 4D y 4D Server en la misma máquina​

Cuando 4D se conecta a un 4D Server en la misma máquina, la aplicación se comporta como 4D en modo monopuesto y el entorno de diseño le permite editar los archivos del proyecto. Esta funcionalidad le permite desarrollar una aplicación cliente/servidor en el mismo contexto de despliegue.

Cuando 4D se conecta a un 4D Server en la misma máquina, el modo desarrollo se activa automáticamente, sea cual sea el estado del modo Desarrollo.

Cada vez que 4D realiza una acción Guardar todo desde el entorno de diseño (explícitamente desde el menú Archivo o implícitamente al cambiar al modo aplicación, por ejemplo), 4D Server recarga sincronizadamente los archivos del proyecto. 4D espera a que 4D Server termine de recargar los archivos del proyecto antes de continuar.

Sin embargo, debe prestar atención a las siguientes diferencias de comportamiento en comparación con la arquitectura proyecto estándar:

  • la carpeta userPreferences.{username} utilizada por 4D no es la misma carpeta utilizada por 4D Server en la carpeta proyecto. la carpeta userPreferences.{username} utilizada por 4D no es la misma carpeta utilizada por 4D Server en la carpeta proyecto.
  • la carpeta utilizada por 4D para los datos derivados no es la carpeta llamada "DerivedData" en la carpeta proyecto. En su lugar, se trata de una carpeta dedicada llamada "DerivedDataRemote" situada en la carpeta del sistema del proyecto.
  • el archivo catalog.4DCatalog no es editado por 4D sino por 4D Server. La información del catálogo se sincroniza mediante peticiones cliente/servidor
  • el archivo directory.json no es editado por 4D sino por 4D Server. La información del directorio se sincroniza mediante peticiones cliente/servidor
  • 4D utiliza sus propios componentes internos y plug-ins en lugar de los de 4D Server.

No se recomienda instalar plug-ins o componentes a nivel de la aplicación 4D o 4D Server.

Desarrollo cliente/servidor​

Lugar de ejecución del código​

En una aplicación cliente-servidor, es importante saber dónde se ejecutará realmente el código: del lado del servidor o del lado del cliente. La ubicación de la ejecución es crucial cuando se desea implementar código relacionado con la sesión del usuario, compartir información entre procesos, acceder a datos, etc.

La siguiente tabla resume dónde se ejecuta el código por defecto y cómo cambiar su ubicación de ejecución (si está permitido). Tenga en cuenta que local significa que el código será ejecutado en la máquina desde donde es realmente llamado.

CodeEjecución por defectoCómo cambiar
Funciones del modelo de datos ORDAserverutilizar la palabra clave local en la definición de la función
Funciones de atributo calculadas ORDA get(), set()serverutilizar la palabra clave local en la definición de la función
Funciones de atributo calculadas ORDA query(), orderBy()servern/a
Funciones del evento ORDA (general)servern/a
Función del evento ORDA constructor()localn/a
Función de evento ORDA event touched()serverutilizar la palabra clave local en la definición de la función
Funciones de clase usuariolocaln/a
Función singleton compartida o de sesiónlocalutilizar la palabra clave server en la definición de la función
Triggerservern/a
Método proyecto llamado desde un clienteclientmarcar la opción Ejecutar en el servidor. El código se ejecuta en el proceso gemelo del proceso de sesión del usuario
llamar al comando Execute on server. El código se ejecuta en la sesión de procedimientos almacenados
Método proyecto llamado desde un procedimiento almacenado en el servidorserverllame al comando EXECUTE ON CLIENT. El cliente destinatario debe estar registrado
Método objetolocaln/a
Métodos base de datos:servern/a
Métodos base de datos:clientn/a

Triggers​

Los triggers se ejecutan en la máquina donde está el motor de la base de datos. Con 4D Server, los triggers se ejecutan en el contexto de los procesos en ejecución en la máquina servidor, y no en la máquina cliente. Más específicamente, se ejecutan en el contexto de los procesos gemelos de los procesos de usuario que llaman a la operación de base de datos. Estos procesos gemelos comparten el contexto de la base de datos con el proceso de usuario en la máquina cliente (en particular, el estado de las transacciones y el bloqueo de registros), pero no comparten el contexto del lenguaje (variables, procesos, conjuntos, selecciones actuales). Sin embargo, note que el registro actual de la tabla asociada al trigger es el mismo en todos los contextos.

nota

En el servidor, un trigger se ejecuta en el proceso responsable de la acción asociada (crear/actualizar/eliminar). Si la acción se activó desde un proceso preventivo en el servidor (por ejemplo, un procedimiento almacenado, una solicitud HTTP en modo de sesión escalable), entonces el trigger se ejecutará en el mismo proceso preventivo. Pero si la acción se activó desde un 4D remoto, el trigger se ejecutará en el proceso gemelo, el cual está siempre en modo cooperativo (un proceso gemelo se comparte para todas las llamadas de un usuario).

Procedimientos almacenados​

Un procedimiento almacenado en 4D es un método de proyecto que lanza un método proceso en un proceso que se ejecuta en la máquina del servidor (o en cualquier máquina cliente registrada), en lugar de en la máquina cliente que ha iniciado el método.

Con 4D en modo local, cuando utiliza un comando, como New process, puede iniciar un proceso de usuario para ejecutar un método. Este método se llama método proceso. Puede hacer lo mismo con 4D Server, en una máquina cliente. Además, con el comando Execute on server puede iniciar un proceso de usuario en la máquina servidor para ejecutar un método. Además, al usar el comando EXECUTE ON CLIENT, puede ejecutar un método en otro proceso en un cliente diferente. En ambos casos, el método se llama procedimiento almacenado, y (por analogía) el proceso iniciado en la máquina servidor u otro cliente también se llama procedimiento almacenado.

nota

Todos los procedimientos almacenados en el servidor comparten la misma sesión de usuario virtual.

Arquitectura​

Como un proceso regular, un procedimiento almacenado tiene su propio entorno:

  • Una selección actual por tabla: cada procedimiento almacenado tiene una selección actual separada. Una tabla puede tener una selección actual diferente en diferentes procedimientos almacenados.
  • Un registro actual por tabla: cada tabla puede tener un registro actual diferente en cada procedimiento almacenado.
  • Variables: cada procedimiento almacenado tiene sus propias variables proceso. Las variables de proceso solo se reconocen dentro del dominio de su procedimiento almacenado nativo.
  • Tabla por defecto: cada procedimiento almacenado tiene su propia tabla por defecto.
  • Conjuntos de proceso: cada procedimiento almacenado tiene sus propios conjuntos de proceso.
  • On Error Call: cada procedimiento almacenado tiene su propio método de gestión de errores.
  • Ventana de depuración: cada procedimiento almacenado puede tener su propia ventana de depuración.

En términos de interfaz de usuario, un procedimiento almacenado puede abrir ventanas y mostrar datos (por ejemplo, DISPLAY RECORD). Un procedimiento almacenado ejecutado en una máquina cliente 4D permite la entrada de datos. Por otro lado, un procedimiento almacenado ejecutado en el servidor no puede invocar la interfaz de entrada de datos, ya que no existe un motor de entrada de datos en la máquina servidor.

Puede iniciar tantos procedimientos almacenados como permitan el hardware y la memoria del sistema. De hecho, la máquina servidor 4D debe verse como un equipo que no solo responde a clientes 4D y navegadores web, sino que también ejecuta procesos que interactúan con otros procesos en ejecución en el servidor y en máquinas 4D remotas.

nota

La propiedad de método Ejecutar en el servidor también se puede usar para ejecutar un método en un proceso en el servidor, pero en este caso el método utiliza el proceso gemelo del proceso cliente, lo que significa, en particular, que puede aprovechar el entorno de dicho proceso cliente. En este caso, no se trata de un procedimiento almacenado 4D.

¿Qué hace un procedimiento almacenado?​

A excepción de la entrada de datos para procedimientos almacenados ejecutados en el servidor, casi todas las capacidades de los procesos y del lenguaje 4D se aplican a los procedimientos almacenados.

Un procedimiento almacenado puede añadir, consultar, ordenar, actualizar o eliminar datos. Un procedimiento almacenado puede acceder a documentos en disco, trabajar con BLOBs, imprimir registros, entre otras funciones. Considere que, en lugar de realizar algo en una máquina 4D local, lo está haciendo en la máquina servidor o en una o varias máquinas cliente 4D.

Una ventaja evidente de los procedimientos almacenados ejecutados en el servidor es que se ejecutan localmente en la máquina servidor, la máquina donde se encuentra el motor de la base de datos. Por ejemplo, un comando APPLY TO SELECTION no resulta eficiente a través de la red, pero sí lo es cuando se ejecuta desde un procedimiento almacenado.

Los procedimientos almacenados ejecutados en una o varias máquinas cliente permiten optimizar la distribución de tareas y la comunicación entre los distintos clientes. Consulte el comando REGISTER CLIENT para un ejemplo de procedimientos almacenados ejecutados en varios clientes.

Sin embargo, la ventaja más importante de la arquitectura de procedimientos almacenados es la dimensión adicional que da a 4D Server. Gracias a los procedimientos almacenados, puede implementar sus propios servicios 4D Server. El único límite es su imaginación.

¿Qué no puede hacer un procedimiento almacenado?​

En general, los procedimientos almacenados ejecutados en el servidor no deberían tratar con elementos de interfaz (como menús, ventanas, formularios...). De hecho, la interfaz no se gestiona del lado del servidor.

Todos los comandos que puedan generar cuadros de diálogo modales en la máquina servidor (por ejemplo Open document con una cadena vacía como primer parámetro) se deben evitar. Tenga en cuenta que no siempre hay un usuario frente a la pantalla del servidor, por lo que la visualización de un cuadro de diálogo modal que requiere una acción del usuario puede hacer que la aplicación quede bloqueada.

Comandos no permitidos en el servidor​

Esta es la lista de los comandos que NO deben utilizarse en los procedimientos almacenados ejecutados en el servidor. Si uno de los siguientes comandos se utiliza en un procedimiento almacenado, se mostrará una alerta que indica que este comando no se puede ejecutar en 4D Server. Se devuelve el error #67; puede interceptarse mediante un método instalado con el comando ON ERR CALL.

ADD RECORD APPEND MENU ITEM POST OUTSIDE CALL CHANGE LICENSES Count menu items Count menus DELETE MENU ITEM DISABLE MENU ITEM DISPLAY SELECTION EDIT ACCESS ENABLE MENU ITEM FILTER EVENT Get menu item Get menu item key Get menu item mark Get menu item style Get menu title SET PICTURE TO LIBRARY INSERT MENU ITEM Menu selected MODIFY RECORD MODIFY SELECTION ON EVENT CALL QUERY BY EXAMPLE QR REPORT REMOVE PICTURE FROM LIBRARY SET MENU ITEM SET MENU ITEM SHORTCUT SET MENU ITEM MARK SET MENU ITEM STYLE SET PICTURE TO LIBRARY SET USER ALIAS SHOW MENU BAR

Comandos sin efecto en el servidor Los siguientes comandos no tienen efecto cuando se ejecutan en un procedimiento almacenado en el servidor. No se devuelve ningún código de error específico.

GRAPH MESSAGES OFF MESSAGES ON SET MENU BAR SHOW TOOL BAR

Cómo lanzar un procedimiento almacenado​

Desde 4D, puede lanzar manualmente un procedimiento almacenado en el cuadro de diálogo Ejecutar método:

Puede ejecutarlo en 4D Server o en otra máquina cliente 4D. Tenga en cuenta que para mostrar las máquinas cliente 4D en esta lista, deben haberse registradas previamente.

nota

No es posible usar los comandos de gestión de procesos DELAY PROCESS, PAUSE PROCESS y RESUME PROCESS desde un 4D remoto en procedimientos almacenados en el servidor.

Comunicación entre los procedimientos almacenados y los procesos usuario​

Los procedimientos almacenados se pueden comunicar entre ellos mediante:

Tenga en cuenta que los comandos 4D actúan en el entorno de la máquina que ejecuta el procedimiento almacenado (servidor o cliente) de la misma manera en que actúan en el entorno de una máquina cliente.

nota

El mecanismo POST OUTSIDE CALL y Outside call no tiene efecto en la máquina servidor, ya que los procedimientos almacenados no tienen una interfaz de usuario para la entrada de datos.

Los procesos de usuario de un cliente (procesos que se ejecutan en una máquina cliente) pueden leer y escribir las variables de proceso (*) de un procedimiento almacenado mediante los comandos GET PROCESS VARIABLE, SET PROCESS VARIABLE y VARIABLE TO VARIABLE.

(*) así como las variables interproceso del equipo servidor.

Importante: la comunicación de procesos "intermáquinas", proporcionada por los comandos GET PROCESS VARIABLE, SET PROCESS VARIABLE y VARIABLE TO VARIABLE, solo es posible del cliente al servidor. Siempre es un proceso cliente el que lee o escribe las variables de un procedimiento almacenado.

Stored procedures on client machines​

Stored procedures can be executed on one or several 4D client machines. Stored procedures on client machines are executed the same as way as stored procedures on the server, except that on the client they can invoke data entry with legacy commands such as ADD RECORD.

Any client machine executing stored procedures triggered by a server or another client machine, should explicitly be registered for this session. There are two ways to register a client: it can automatically be registered when connecting or through programming.

  • Registering automatically each 4D client machine connecting to 4D Server: check the Register Clients at Startup For Execute On Client box in the Settings dialog box. When this option is checked, each 4D client machine connecting to the application is automatically referenced with 4D Server as being able to execute stored procedures. A 4D Client type process named according to the client machine is created on the server. An equivalent process is also created on each client machine.
  • Registering 4D Client through programming: you can register one or several client machines using programming, allowing you to select the client machines that needs to be registered and to define their registration name. Use the REGISTER CLIENT command which allows you to register a client machine under any name.
  • Unregistering 4D Client: No matter how the client machines have been registered, you can unregister them for the current session using the UNREGISTER CLIENT command for a given client. El proceso de registro (nombrado según el cliente) desaparece del grupo de procesos de usuario tanto en la máquina servidor como en la máquina cliente.

Puede obtener la lista y la distribución de tareas (número de métodos por ejecutar) para los clientes registrados en una sesión específica utilizando el comando GET REGISTERED CLIENTS.

Variables​

Como todos los procesos, cada procedimiento almacenado, método base de datos y trigger tiene su propia tabla de variables de proceso. Estas variables de proceso se pueden crear y utilizar dinámicamente durante cada fase de ejecución.

4D Server mantiene una tabla de variables interproceso (obsoleto). El alcance de estas variables es la máquina servidor. Cuando se ejecuta una base compilada, la definición de la tabla de variables interproceso es común entre el servidor y todas las máquinas cliente, pero cada máquina tiene su propia instancia.

Conjuntos y selecciones temporales​

  • Conjuntos y selecciones temporales de proceso: a un objeto de proceso solo se puede acceder desde el proceso en el que fue creado y, si se creó en un proceso cliente, desde el proceso gemelo creado en el servidor. Los conjuntos proceso se borran en cuanto termina el método proceso. Los objetos de proceso no necesitan ningún prefijo especial en el nombre.
  • Conjuntos/Selecciones temporales interproceso (obsoleto): un objeto interproceso es visible para todos los procesos en la máquina (cliente o servidor) en la que fue creado. Un conjunto o selección temporal es un objeto interproceso si el nombre del conjunto está precedido por los símbolos (<>) — un signo "menor que" seguido de un signo "mayor que".
  • Conjuntos/Selecciones temporales locales/clientes: un objeto local/cliente solo es visible en el proceso donde se creó. El nombre de un objeto local/cliente está precedido por el signo de dólar ($). Nota: aunque su nombre no comienza por $, el sistema UserSet es un conjunto local/cliente.

La siguiente tabla indica los principios de visibilidad de las selecciones temporales y los conjuntos según donde se creen (la tabla es idéntica para ambos tipos de objetos):

Proceso clienteOtros procesos clienteProceso servidorOtros procesos servidor
Creado en un proceso cliente
$testx
testxx (Trigger)
<>testxx
Creado en un proceso servidor
$testx
testx
<>testxx

x = visible

Tenga en cuenta esta matriz de visibilidad dependiendo de las operaciones que vaya a realizar. Por ejemplo, si quiere hacer una operación de tipo DIFFERENCE, INTERSECTION o UNION, asegúrese de que todos los conjuntos sean visibles en la máquina que está ejecutando la operación.

Atributo Ejecutar en el servidor​

El atributo de método proyecto Ejecutar en el servidor se puede definir utilizando el cuadro de diálogo de configuración por lotes de atributos así como el cuadro de diálogo Propiedades de los métodos. Cuando esta opción está marcada, el método del proyecto se ejecuta siempre en el servidor, independientemente de cómo se llame.

Contexto de ejecución​

Cuando se marca este atributo, el contexto de ejecución del método proyecto es comparable al de los triggers: el método en el servidor comparte el mismo contexto de base de datos que el correspondiente del lado del cliente para el bloqueo de registros y transacciones, pero no el mismo contexto de lenguaje (variables de proceso, conjuntos, selecciones actuales). Sin embargo, a diferencia de un trigger, un método que se ejecuta en el servidor no comparte el registro actual con el contexto del cliente. Todos los parámetros del método se envían al servidor y el valor devuelto, si lo hay, se retorna al cliente.

A diferencia del comando Execute on server, esta opción no crea un proceso en el servidor. 4D Server utiliza el proceso gemelo del proceso cliente que solicitó la ejecución. Además, esta opción simplifica el principio de delegar la ejecución de un método en el servidor, ya que la transferencia de parámetros se realiza automáticamente en ambas direcciones, como en una llamada normal a un método. El comando Execute on server funciona de forma asíncrona; por lo tanto, requiere más programación y hace uso de semáforos para la lectura de resultados.

Comandos utilizables​

Los métodos con el atributo "Ejecutar en el servidor" están sujetos a las mismas reglas que los procedimientos almacenados en lo que se refiere al uso de comandos del lenguaje 4D.

Punteros​

Si pasa un puntero a una variable (variable simple, array o elemento de array), el valor referenciado también se envía al servidor. If the pointed value is modified on the server by the method, the modified value is returned to the client in order to update the corresponding variable on the client side. Pointers to a table or field are sent as references (table number, field number). The current record value is not automatically exchanged.

nota

This option works the same way in interpreted mode as in compiled mode.

Ejemplo​

Here is the code for the MyAppli project method which has the "Execute on Server" attribute:

 #DECLARE($table: Pointer; $field: Pointer; $array: Pointer; $search: Text) -> $result : Integer
 
  //Buscar y devolver valores para cada registro
 QUERY($table->;$field->=$search)
 While(Not(End selection($table->)))
    APPEND TO ARRAY($array->;myFormula($table))
    NEXT RECORD($table->)
 End while
 UNLOAD RECORD($table->)
 $result:=Records in selection($table->)

Del lado del cliente, el método se llama de la siguiente manera:

 ARRAY TEXT(myArray;0)
 var $vlnum:=MyAppli(->[Table_1] ;->[Table_1]Field_1 ;->myArray;"to find")

Carpeta Resources​

The Resources folder of a project can be used to share custom data (pictures, files, subfolders, etc.) between the server machine and all the client machines. On the server machine, the Resources folder is simply be located at the first level of the project root folder.

All referencing mechanisms associated with the Resources folder are supported in client/server mode (.lproj folder, XLIFF, pictures and so on).

Each client has a local copy of this folder. The contents of the local folder are automatically synchronized with that of the server each time the client connects.

Moreover, client machines can be dynamically "notified" during a session when the contents of the Resources folder of the server application are modified by a developer. This notification can be triggered:

  • either automatically by the server, two minutes after the last modification made by a client (this delay helps to avoid inopportune notification in the case where numerous files are being copied).
  • or manually via the Notify clients command in the action menu of the [Resources explorer]Using the Resources explorer on the Toolbox of the client machine at the origin of the modification.
  • or by programming, via a NOTIFY RESOURCES FOLDER MODIFICATION command. This command is useful when the contents of the Resources folder are modified on the server machine via a stored procedure.

On the client side, the way the notification of any modifications will be handled depending on the Update "Resources" folder during a session setting value. This can also be set individually via the Auto synchro resources folder selector of the SET DATABASE PARAMETER command. Three choices are available: no synchronization, auto synchronization or ask. For more information, please refer to the Network and Client-Server options section.

Lastly, each client machine can synchronize itself with the server at any time via the Update Local Resources command in the action menu of the Resources explorer.