4D v16Servicios basados en los procedimientos almacenados (ejemplo) |
||||||||||
|
4D v16
Servicios basados en los procedimientos almacenados (ejemplo)
Servicios basados en los procedimientos almacenados (ejemplo)
En el ejemplo de la sección Importación con procedimientos almacenados (ejemplo), un procedimiento almacenado se inicia y termina cada vez que se solicita una operación de importación de datos. En este ejemplo, un procedimiento almacenado se lanza automáticamente cuando se inicia la base del servidor y puede iniciarse y detenerse a voluntad por cualquier 4D conectado a la base. Tan pronto como se ejecuta, el procedimiento almacenado puede responder de manera asincrónica a múltiples peticiones enviadas por los clientes conectados a la base. Mientras que la sección Importación con procedimientos almacenados (ejemplo), muestra cómo optimizar un servicio 4D Server existente, este ejemplo muestra cómo implementar servicios novedosos y personalizados disponibles para todos los equipos 4D client conectados. Además, este ejemplo puede utilizarse como modelo para la creación de sus propios servicios. El procedimiento almacenado es lanzado automaticamente por el Método base On Server Startup: ` Método de base On Server Startup Como el Método base On Server Startup lanza al método de proyecto SP SERVICES como un procedimiento almacenado, SP SERVICES comienza a correr tan pronto como la base se abre con 4D Server, bien sea que haya o no clientes conectados a la base. En la siguiente imagen, la ventana de administración de 4D Server muestra el procedimiento almacenado en ejecución cuando ningún cliente está conectado. Este es el método de proyecto START SP SERVICES: ` START SP SERVICES Project Method Como el comando Execute on server actúa como New process al llamarse en la máquina servidor, el mismo método (START SP SERVICES) puede utilizarse en el equipo servidor o en una máquina cliente para iniciar a voluntad el método SP SERVICES como un procedimiento almacenado en el equipo servidor. El método de proyecto STOP SP SERVICES “ordena” detenerse al método de proyecto SP SERVICES. ` Método de proyecto STOP SP SERVICES Cuando se inicia el método de proyecto SP SERVICES, da a la variable proceso vbStopSPServices el valor False y luego ejecuta un bucle hasta que esta variable Booleana se convierte en True. El comando , permite a todo proceso usuario ejecutado en el servidor o en un equipo cliente modificar el valor de la variable vbStopSPServices, y por lo tanto detener el procedimiento almacenado a voluntad. El procedimiento almacenado debe poder recibir peticiones de clientes y responder de manera asincrónica en cualquier momento y sin importar el orden. Una manera directa de asegurar esta comunicación es utilizar una tabla. La tabla [SP Requests] contiene los siguientes campos:
Nota: estos valores se eligen arbitrariamente para este ejemplo, no son impuestos por 4D.
La comunicación entre un proceso cliente y un procedimiento almacenado puede implementarse utilizando los comandos GET PROCESS VARIABLE, SET PROCESS VARIABLE y VARIABLE TO VARIABLE. Por ejemplo, esta solución utilizada en la sección Importación con procedimientos almacenados (ejemplo), como también en el método de proyecto STOP SP SERVICES listado anteriormente. Acá, el sistema debe permitir al procedimiento almacenado recibir y reenviar las cantidades variables de datos. Puede utilizar arrays, incluyendo arrays de texto e imagen), pero hay dos razones principales para preferir el empleo de una tabla:
El método de proyecto Client post request es un método genérico para enviar una petición: ` Método de proyecto Client post request El método devuelve el número de la petición, cuya unicidad está garantizada por el uso del comando Sequence number. Una vez añadido el registro a la tabla [SP Requests], el cliente no tiene que interrogar regularmente el campo [SP Requets]redStatus hasta que el procedimiento almacenado termine de procesar la petición. El método de proyecto Client get result es un método genérico para probar el estado de la petición. Como se explicó anteriormente, tan pronto como el campo [SP Requets]redStatus se vuelve diferente de 1, el cliente sabe que el procedimiento almacenado ha tratado (con éxito o no) la petición. ` Método de proyecto Client get result Si la petición fue administrada con éxito por el procedimiento almacenado, el método copia el resultado (si lo hay) del registro al BLOB cuyo puntero se pasó como parámetro. El método llamante luego analiza y utiliza los datos del BLOB en función del tipo de petición. Note que el cliente está encargado de borrar el registro [SP Requests] una vez termina la petición. El pequeño método de proyecto WAITING LOOP hace un bucle hasta un cierto número de tics: ` Método de proyecto WAITING LOOP Recordatorio: DELAY PROCESS no tiene efecto en el proceso principal. Si utiliza el método de proyecto WAITING LOOP, el proceso esperará la cantidad de tiempo necesaria, aunque la petición se origine desde el proceso del entorno usuario de un equipo cliente. El método de proyecto SP SERVICES es el método ejecutado como procedimiento almacenado en el equipo servidor. La estructura general de este método, a continuación, es muy simple: Inicialización de una variable “stop” Este es el código fuente real: ` Método de proyecto SP SERVICES El método de proyecto SP SERVICES puede utilizarse como modelo para implementar novedosos servicios en una base. En esta sección, detallamos las subrutinas SP DO SERVER INFORMATION y SP DO VOLUME LIST. La subrutina SP DO BROWSE DIRECTORY (que toma como parámetro un parámetro enviado por el cliente en el campo [SP Requests]reqParams) no se trata en este documento. Dependiendo del tipo de la petición, el método de proyecto SP SERVICES llama a una subrutina cuya tarea es guardar los datos resultantes en el campo [SP Requests]reqData. El almacenamiento del registro y el cambio del estado lo realizar el método de proyecto SP SERVICES. Esta es la subrutina SP DO SERVER INFORMATION que guarda la información relativa al servidor en el BLOB. Otro método de proyecto extraerá los datos del BLOB en función del equipo cliente. ` Método de proyecto SP DO SERVER INFORMATION Esta es la subrutina SP DO VOLUME LIST, que guarda la información relativa a los volúmenes en el BLOB. Otro método de proyecto extraerá los datos del BLOB en función del equipo cliente. ` Método de proyecto SP DO VOLUME LIST Con los métodos de proyecto genéricos Client post request y Client get result, el método de proyecto M_SERVER_INFORMATION muestra, en el equipo cliente, la información devuelta por el procedimiento almacenado. Este método puede estar asociado a un comando de menú o ser llamado, por ejemplo, desde el método de objeto de un botón: ` M_SERVER_INFORMATION Este es el formulario [SP Requests];"SERVER INFORMATION" en ejecución: Con los métodos de proyecto genéricos Client post request y Client get result, el método de proyecto M_SERVER_VOLUMES muestra, en el equipo cliente, la información en la lista de los volúmenes del servidor devuelta por el procedimiento almacenado. Este método puede estar asociado a un comando de menú o llamado, por ejemplo, desde el método de objeto de un botón: ` M_SERVER_VOLUMES Este es el formulario [SP Requests];"VOLUME LIST" en ejecución:
Ver también
Importación con procedimientos almacenados (ejemplo)
|
PROPIEDADES
Producto: 4D
HISTORIA
ARTICLE USAGE
Manual de 4D Server ( 4D v16) |
||||||||