Proceso
Es un objeto contenedor de instrucciones definible por el programador. Las instrucciones se ejecutarán de forma secuencial y harán uso de comandos de instrucción de proceso que pueden acceder a otros objetos de los proyectos incluyendo otros procesos.
El proceso tiene una entrada y una salida, es decir, un origen ficha, lista o ninguno y una tabla asociada, y un destino ficha, lista o ninguno y una tabla asociada. Esto permite trabajar con uno o varios registros de entrada y que el proceso devuelva uno o varios registros como salida. Cada una de las instrucciones tiene un origen y un destino condicionados por el origen y el comando anterior, el primero de ellos determinado por la entrada del proceso. De esta forma el flujo de datos es gestionado por el proceso, permitiendo una salida programada en función de la entrada.
Los procesos se pueden ejecutar en distintos planos, lo que permite que sean ejecutados en local o el servidor, en multi-tarea en local, y esperando respuesta o no por parte del proceso llamado. Para crear un objeto de este tipo seleccionar la opción nuevo objeto/proceso del menú objetos de Velneo vDevelop o a través de la galería de objetos.
El sistema nos pedirá, en primer lugar, el lenguaje en el cual programaremos el proceso: Velneo o Javascript.
Los procesos serán creados directamente en el editor de procesos que se abre al crear/editar un objeto de este tipo.
Los procesos Javascript requieren de la creación de un fichero de script, que será asignado al proceso en la propiedad fichero script. Consultar los siguientes capítulos para ampliar información al respecto: inspector de scripts y scripts.
Las propiedades de un proceso son:
Identificador
Etiqueta alfanumérica que identifica al objeto. Este identificador será el que se usa para referenciarlo en los inspectores y en las propiedades de otros objetos.
Nombre
Etiqueta alfanumérica que servirá como descriptor del objeto. Es el texto que se presentará al usuario final de la aplicación para referenciar al objeto. Podemos definir una etiqueta por cada idioma presente en el proyecto.
Estilos
Podemos definir los estilos:
Privado
Limita el acceso del usuario final al objeto desde puntos donde no se haya programado el acceso al mismo. Por ejemplo, si marcamos un proceso de un proyecto de datos como privado, dicho proceso no estará accesible al ejecutar la instancia de dicho proyecto con Velneo vDataClient.
Accesible web
Un proceso que tenga activado este estilo podrá ser ejecutado vía web. Ver el capítulo dedicado a Velneo vModApache para ampliar información al respecto.
Debug: punto de interrupción
Este estilo solamente estará disponible para los procesos javascript y lo que permitirá es que pueda depurarse el proceso cuando ejecutemos la solución en modo de depuración de procesos JavaScript.
Comentarios
Esta propiedad nos permite documentar el uso del proceso.
Tabla asociada
Esta propiedad nos permite establecer el origen del proceso. Podremos, o bien seleccionar una tabla de un proyecto de datos o bien seleccionar el valor ninguna en el caso de que el origen del proceso no tenga origen.
Origen
Esta propiedad aparecerá solamente en el caso de que en la propiedad tabla asociada hayamos seleccionado una tabla. Los valores posibles son:
Ficha
El origen del proceso será una ficha (registro) de la tabla seleccionada en la propiedad tabla asociada.
Lista
El origen del proceso será una lista de registros de la tabla seleccionada en la propiedad tabla asociada.
Tabla destino
Esta propiedad nos permite establecer la salida del proceso. Podremos, o bien seleccionar una tabla de un proyecto de datos heredado, o bien seleccionar el valor ninguna en el caso de que el proceso no tenga salida.
Destino
Esta propiedad aparecerá solamente en el caso de que en la propiedad tabla destino hayamos seleccionado una tabla. Los valores posibles son:
Ficha
La salida del proceso será una ficha (registro) de la tabla seleccionada en la propiedad tabla destino.
Lista
La salida del proceso será una lista de registros de la tabla seleccionada en la propiedad tabla destino.
Una vez establecidas las propiedades podremos pasar a crear las instrucciones que lo conformarán, para ello disponemos de un editor. Para abrirlo bastará con pulsar intro o hacer doble clic sobre el identificador del proceso que acabamos de crear en el panel de objetos de Velneo vDevelop.
Editor de procesos
El editor de procesos es el objeto que nos permite definir el conjunto de instrucciones que formarán parte del mismo. Las instrucciones de un proceso serán subobjetos del mismo y obtendrán su origen del propio proceso, pero, más importante aún, las variables locales del proceso también son subobjetos del mismo. Se crearán automáticamente cuando las usemos en las instrucciones, pero podremos acudir al proceso, haciendo doble clic, para poder cambiar su configuración.
El editor de procesos dispone de un asistente para la creación de cada línea:
En la parte superior de dicho asistente se informa sobre el origen de la línea del proceso seleccionada, que podrá ser:
Ninguno.
Ficha de una tabla concreta.
Lista de registros de una tabla concreta.
Los comandos disponibles en una línea dependerá del origen de la misma, que en primer lugar viene determinado por el origen del proceso y que podemos ir variando dependiendo de los comandos que empleemos. Algunos comandos generarán subramas cuyo origen vendrá determinado por el comando y se ejecutarán las instrucciones que cuelguen de la subrama en función de éste.
Para localizar un comando podremos hacerlo, o bien navegando a través de las carpetas y subcarpetas de la ventana de selección, o bien usando la opción Filtro. Al escribir una cadena en el filtro el sistema presentará todos los comandos que la contengan:
Estando el foco en el filtro, podremos hacer uso de las teclas de cursor arriba/abajo para navegar entre los comandos encontrados.
Una vez seleccionado el comando deseado pulsar el botón “Aceptar”. El comando será incluido en la línea del proceso donde estábamos posicionados.
Si modificamos el tamaño o cambiamos la ubicación de esta ventana de selección de comandos el sistema lo recordará en futuras sesiones de Velneo vDevelop.
Los comandos que no puedan ser usados en la línea debido a su origen serán mostrados en un color gris:
Si el comando seleccionado requiere parámetros, éstos serán mostrados a continuación.
La especificación de los parámetros de un comando será asistida. En unos casos el parámetro desplegará una lista con los valores posibles que pueden ser seleccionados y en otros casos se presentará el asistente para edición de fórmulas. Tal y como hemos dicho al comienzo del artículo, en aquellos parámetros cuyo contenido sea una variable local podremos, o bien, seleccionar una declarada previamente en el proceso, o bien crearla nueva.
Qué registros componen la salida del proceso vienen determinados por las instrucciones Añadir ficha a la salida y Añadir lista a la salida. La primera podemos usarla para generar la salida ficha de un proceso y la segunda para generar como salida una lista de registros, y ambas son válidas para generar la salida de un proceso.
En ambos casos, los comandos generan la salida a partir de la ficha o lista en cuyo origen esté situado el comando, que tiene que corresponder con el seleccionado en el proceso. En el caso de la lista, además de permitir generar la lista a partir de una ficha, permite hacerlo a partir de varias fichas y listas.
Planos de ejecución de procesos
Los procesos se dividen en cuatro planos de ejecución según el lugar y el modo en que se ejecutan:
1º Plano: local.
2º Plano: local multitarea (no espera retorno).
3º plano: servidor.
4º plano: servidor (no espera retorno).
Los procesos en 1º plano se ejecutan de forma local, bien sea en el cliente, bien sea en el servidor, y devuelven un retorno por el que espera el proceso llamador, hasta que finaliza el proceso llamado, o la acción que ha lanzado el proceso. Por tanto, son bloqueantes del proceso llamador o de la actividad del usuario que no puede seguir interaccionando con el interfaz de la aplicación hasta que éste haya finalizado.
De igual forma, los procesos en 2º plano se ejecutan de forma local en el cliente, pero el proceso llamador no espera retorno, por lo que pueden ejecutarse en paralelo con otros procesos multitarea. Estos procesos, por tanto, no bloquean el proceso llamador o la actividad del usuario que sí puede seguir interaccionando con el interfaz de la aplicación.
Para conocer el estado de estos procesos que se están ejecutando en segundo plano existe el Panel de procesos en 2º plano que nos muestra todos los procesos en segundo plano que se están ejecutando, indicando la cola a la que han sido asignados y que se encarga de gestionar el cliente. A este panel se puede acceder mediante el comando de acción Archivo: procesos en 2º plano.
En la información sobre los procesos se especifica el título de la transacción y el porcentaje del proceso realizado, datos que podemos definir en el proceso con los comandos de instrucción Cambiar título de la transacción y Cambiar porcentaje realizado del proceso.
La información relativa a los registros manejados en los procesos en 1º y 2º plano viaja entre el cliente y el servidor, por lo que debemos tener en cuenta este dato cuando trabajemos con rangos amplios de registros. De todos modos, debemos tener en cuenta que mientras trabajemos con listas y no con registros concretos, la información que viaja entre ambos no se trata del registro entero si no de la necesaria para apuntar al registro, por lo que el efecto en el tráfico es moderado.
Los procesos en 3º plano se ejecutan en el servidor, devolviendo un retorno por el que espera el proceso llamador. Por tanto bloquean la actividad del proceso llamador, que esperará el retorno para seguir con las operaciones programadas. Esto no implica en ningún momento un bloqueo en la actividad del usuario o del servidor. Todos los procesos ejecutados en el servidor son multitarea, y en el cliente tenemos la opción de lanzar el proceso desde otro proceso multitarea.
Los procesos en el servidor, 3º plano, frente a los procesos en 1º ó 2º plano, optimizan el tráfico de información entre cliente y servidor. Esto es porque no viaja entre uno y otro información alguna sobre los registros manejados en el proceso, ni siquiera de las listas manejadas, sino que únicamente se retorna el resultado del proceso. Sin embargo, debemos tener en cuenta que esto hace que sea el servidor el que tenga que atender todas las operaciones que se realice el proceso, por lo que debemos tener en cuenta el balance de la carga.
Los procesos en 4º plano se ejecutan en el servidor, pero el proceso llamador no espera retorno. Los procesos entrarán en una cola de 4º plano y serán ejecutados de forma secuencial según el orden de llegada. Cuando paramos el servidor, los procesos que estuviesen en cola pendiente de ser ejecutados son eliminados.
Un proceso en 4º plano se puede ejecutar desde procesos ejecutados en primer plano, en tercer plano, triggers y desde otros procesos ejecutados en 4º plano.
Nota |
Debemos tener en cuenta que, si en un proceso ejecutado en tercer plano, una instrucción del mismo dura más de 2 minutos, hará que el proceso no pueda reportar al llamador que continúa ejecutándose, por lo que de desenganchará y se deshará. |
Nota |
Solamente será posible usar comandos de instrucción de proceso que generen interfaz en aquellos procesos que ejecutamos en primer plano; en otros planos no pueden ser usados. Si se trata de procesos de Velneo, el sistema simplemente no los ejecutará, pero si se trata de procesos JavaScript, debemos evitarlo, ya que el sistema no lo controlará. Existe una excepción y es la del comando de instrucción Mensaje. Usado en procesos en 2º plano mostrará el mensaje en la barra de estado de Velneo vClient. Usado en tercer plano mostrará el mensaje directamente en el panel de Mensajes del sistema de Velneo vAdmin. |
Sobre la configuración regional del sistema y los procesos ejecutados en tercer y cuarto plano debemos tener en cuenta lo siguiente:
Los cambios que hacemos en la configuración regional del sistema operativo del servidor solamente afectan al usuario en cuya sesión se hace el cambio.
Si el servicio VATP está asociado a la cuenta local del sistema, no se tendrá en cuenta la configuración establecida en una sesión de usuario. Tendremos dos opciones:
Cambiar la configuración regional de la cuenta local (que sería la opción aconsejada). En algunos sistemas operativos, por ejemplo, se incluye una opción que permite aplicar la configuración establecida en una sesión de un usuario a la cuenta del sistema.
Asociar el servicio a la cuenta del usuario en cuya sesión se modifica la configuración regional.
Proceso: ON_INIT_SERVER
Es posible crear un proceso para que sea ejecutado cada vez que se declare o se reinicie una instancia de un proyecto. Es decir, cada vez que creemos o reiniciemos una instancia de un proyecto (tanto de datos como de aplicación , dicho proceso será ejecutado.
Dicho proceso será ejecutado en el servidor Velneo vServer.
El proceso deberá cumplir los siguientes requisitos:
Para que el sistema reconozca un proceso como tal ha de tener el identificador ON_INIT_SERVER.
El proceso no podrá tener ni origen ni destino.
El proceso no deberá incluir ningún comando de instrucción que requiera la intervención de un usuario (Pedir formulario, por ejemplo) o que genere interfaz ya que, tal y como hemos dicho anteriormente, el proceso es ejecutando en el servidor.
Posibles ejemplos de uso de este tipo de proceso: inicializar variables globales de un proyecto, iniciar un servicio TCP/IP, etc.
Debemos tener en cuenta que el proceso será ejecutado solamente cuando se instancie o se reinicie la instancia que lo contiene. Supongamos que tenemos un proyecto de aplicación que hereda uno de datos y que ambos proyectos contienen un proceso ON_INIT_SERVER. Dado que la instanciación de un proyecto implica la instanciación de todos los proyectos heredados por el mismo, la primera vez que instanciemos el proyecto de aplicación se creará también la instancia del proyecto de datos heredado, por lo que se ejecutará el proceso ON_INIT_SERVER de ambos. Si con posterioridad reiniciamos el proyecto de aplicación, se ejecutará el proceso ON_INIT_SERVER del mismo, pero no el del proyecto de datos heredado.
Nota |
Se desaconseja usar este proceso para escribir en la base de datos, ya que en el momento de su ejecución no se ha iniciado el control de transacciones. Solamente recomendamos su uso para operaciones que no generen transacción. |
Proceso ON_CLOSE_SERVER
Es posible crear un proceso para que sea ejecutado cada vez que se detenga o se reinicie una de un proyecto. Se lanza siempre que sea detenida la ejecución de la instancia en el servidor bien porque se reinicie la instancia o porque se detenga el servidor.
El proceso será ejecutado solamente cuando se detenga o se reinicie la instancia que lo contiene. Supongamos que tenemos un proyecto de aplicación que hereda uno de datos y el de datos contiene un proceso ON_CLOSE_SERVER.
Si detenemos la instancia del proyecto de aplicación, no se ejecutará el proceso. Solamente se ejecutará si detenemos la instancia del proyecto de datos.
Dicho proceso será ejecutado en el servidor Velneo vServer.
El proceso deberá cumplir los siguientes requisitos:
Para que el sistema reconozca un proceso como tal ha de tener el identificador ON_CLOSE_SERVER.
El proceso no podrá tener ni origen ni destino.
El proceso no deberá incluir ningún comando que tenga interacción con la interfaz, ni tampoco transacciones en la base de datos, ya que el servidor ya está detenido para esa instancia.
Si tenemos varias instancias con proyectos ON_CLOSE___SERVER tanto en proyectos de datos como de aplicación, primero se lanzarán todos los de los proyectos de datos y luego todos los de los proyectos de aplicación.
Comandos
Los comandos son las instrucciones con las que se construyen los procesos, eventos, funciones, demonios, etc. Pueden tener uno o varios parámetros dependiendo de cada comando. Los comandos pueden ser de lista, de ficha o de ambas. Al seleccionar una línea, aparece en la parte inferior la ventana Instrucción donde nos informa del origen del subproceso actual y de los comandos disponibles, los cuales dependen de que el origen sea ficha o lista.
Comandos propios de lista
Como su nombre indica son comandos aplicables a las listas. En la descripción de los parámetros se indica si los mismos son obligatorios u opcionales.
Comandos propios de ficha
Como su nombre indica son comandos aplicables a las fichas. En la descripción de los parámetros se indica si los mismos son obligatorios u opcionales.
Comandos sin origen
Como su nombre indica son los comandos que no están asociados a un origen fijo, pueden tener su origen tanto en una ficha, en una lista como “Ninguno”. En la descripción de los parámetros se indica si los mismos son obligatorios u opcionales.
En capítulos siguientes se explican los comandos agrupados por tipo.
En los capítulos siguientes explicaremos los comandos de instrucción de proceso que contempla Velneo.
Última actualización
