Egeasy - Contribuciones del usuario [es]

Despliegue de la plataforma de gestión egeasy

2009-08-05T07:58:31Z

Imhernandez: /* Instalación de egRouter */

En este artículo detallaremos el proceso de instalación de la plataforma de gestión de egeasy, aunque, previo a meternos en materia, recomendamos estudiar la [[Arquitectura_de_la_plataforma|arquitectura de la plataforma egeasy]], donde se detallan las conexiones que se producen entre las distintas aplicaciones, así como las funciones de cada una de ellas.
===Instalación del software===
Para la instalación del software en el servidor de aplicaciones, se proporcionará un fichero comprimido con todas las aplicaciones, ficheros de configuración y librerías necesarias. Este fichero comprimido tendrá la siguiente estructura de directorios:
*Carpeta '''Aplicaciones''':
**Carpeta '''egServices''': contendrá las aplicaciones egRouter, egSystem y egServer, así como las DLL necesarias. Las aplicaciones egRouter y egServer deben instalarse como servicios. Las especificaciones de esta instalación se detallan en el apartado Instalación de servicios de este anexo.
**Carpeta '''egAdmin''': contendrá la aplicación de administración egAdmin. Aunque no es imprescindible que esta aplicación resida en el servidor, se incluye en la instalación para el caso en que la administración se haga directamente desde el servidor de aplicaciones.
**Carpeta '''egExplorer''': contendrá la aplicación cliente del egExplorer. Al igual que con el egAdmin, esta aplicación no es imprescindible que resida en el servidor.
**Carpeta '''egImportExport''': contendrá la herramienta de importación de datos que será necesaria en el arranque del Sistema.
**Carpeta '''egTaskEditor''': contendrá la herramienta para la gestión del motor de workflow de la plataforma.
**Carpeta '''egTaskUpdater''': contendrá la herramienta para la actualización de los modelos de procesos implementados en la plataforma.
**Carpeta '''egTools''': contendrá la herramienta de acceso y administración del tablespace del sistema de gestión.
*Carpeta '''Modelos''': contendrá la descripción del sistema de gestión.
*Carpeta '''Registro''': contendrá el registro de operaciones que se realicen sobre el sistema de gestión.

Es importante que tanto el usuario de Windows que se nos proporcione para la administración como el usuario que inicie el egSystem tengan permisos de lectura y escritura sobre los directorios que han sido generados a raíz del fichero comprimido. Los directorios generados por el fichero comprimido pueden ser descomprimidos en cualquier ruta del servidor.

===Instalación de servicios===
Para que un centro funcione correctamente, es necesario instalar como servicios las aplicaciones egRouter y egServer. Esto quiere decir que las aplicaciones serán automáticamente arrancadas por el sistema operativo, y residirán en la memoria RAM del servidor. Pero para que esto ocurra, habrá que elaborar una serie de ficheros .bat.
====Instalación de egRouter====
Para la instalación del egRouter como servicio, se incluye en la carpeta egRouter un fichero por lotes "'''Instalar Router.bat'''" con el siguiente contenido:

<pre>
copy srvany.exe "[RUTA_APLICACIONES]\egServices\"
instsrv egRouter2002 "[RUTA_APLICACIONES]\egServices\srvany.exe"
egRouter.reg
</pre>

Para instalarlo deben seguirse las siguientes instrucciones:
#En la carpeta ''egServices'' se proporciona una clave de registro con la ruta del egRouter: "'''egRouter.reg'''". Hay que editar este fichero para modificar y especificar la ruta correcta del "'''egRouter.exe'''" (debe ser una carpeta del equipo local).
#Modificar [RUTA_APLICACIONES] en el fichero "Instalar router.bat" para especificar la ruta correcta donde se va a ubicar la aplicación '''srvany''' (esta aplicación se proporciona en la carpeta egServices).
#Ejecutar el fichero "Instalar router.bat". En el proceso se instala la aplicación egRouter como servicio mediante las utilidades INSTSRV y SRVANY, y se añade la información pertinente en el registro.
#Una vez instalado el servicio se ha de configurar éste en Windows. En particular, debe especificarse que el usuario con el que se ejecuta es "Cuenta del sistema local" y el tipo de inicio "Automático". Para ello, habrá que acceder a '''Herramientas administrativas''' del ''Panel de Control'' de Windows. Una vez dentro, veremos un icono llamado '''Servicios'''. Al acceder, veremos todos los servicios instalados en el sistema. Seleccionamos el servicio perteneciente al egRouter y seleccionaremos las propiedades donde podremos configurar el servicio.

<center>
{|
|align="center" |[[Imagen:servicios0.jpg|border|250px]]
|}
</center>

<center>
{|
|align="center" |[[Imagen:servicios1.jpg|border|250px]]
|align="center" |[[Imagen:servicios2.jpg|border|250px]]
|}
</center>

====Instalación de egServer====
La instalación del egServer es muy similar. Para ello se proporciona el fichero por lotes "'''Instalar egServer.bat'''":

<pre>
copy srvany.exe "[RUTA_APLICACIONES]\egServices\"
instsrv egServer "[RUTA_APLICACIONES]\egServices\srvany.exe"
egServer.reg
</pre>

Las instrucciones son las mismas que para instalar el egRouter, sólo que esta vez se instala el servicio egServer con la clave de registro egServer.reg.
Estas operaciones debe realizarlas un usuario con permisos para instalar y administrar servicios.

===Instalación de la aplicación cliente===
La aplicación cliente '''egExplorer''' puede instalarse de dos formas:
#Se puede instalar una instancia de la aplicación en cada uno de los ordenadores de los usuarios finales.
#Se puede compartir en red con permisos de lectura la carpeta egExplorer, de modo que se puede crear un acceso directo a la aplicación en cada uno de los ordenadores finales.
Aunque los dos esquemas funcionan y la aplicación está preparada para actualizarse automáticamente, la experiencia nos ha demostrado que el segundo esquema es más efectivo, por lo que sería preferible.

Una vez instalado el paquete de aplicaciones que nos permitirán trabajar con un centro y desarrollado nuestro sistema de información en ODL, el siguiente paso es instalar nuestro centro. Para ello, existe un artículo que muestra los pasos a seguir para esta tarea, que se hará mediante la aplicación egAdmin. [[Cómo_instalar_un_centro_desde_cero|Ir al artículo]]

[[Categoría:Tutoriales]]

Despliegue de la plataforma de gestión egeasy

2009-08-05T07:53:59Z

Imhernandez: /* Instalación del software */

En este artículo detallaremos el proceso de instalación de la plataforma de gestión de egeasy, aunque, previo a meternos en materia, recomendamos estudiar la [[Arquitectura_de_la_plataforma|arquitectura de la plataforma egeasy]], donde se detallan las conexiones que se producen entre las distintas aplicaciones, así como las funciones de cada una de ellas.
===Instalación del software===
Para la instalación del software en el servidor de aplicaciones, se proporcionará un fichero comprimido con todas las aplicaciones, ficheros de configuración y librerías necesarias. Este fichero comprimido tendrá la siguiente estructura de directorios:
*Carpeta '''Aplicaciones''':
**Carpeta '''egServices''': contendrá las aplicaciones egRouter, egSystem y egServer, así como las DLL necesarias. Las aplicaciones egRouter y egServer deben instalarse como servicios. Las especificaciones de esta instalación se detallan en el apartado Instalación de servicios de este anexo.
**Carpeta '''egAdmin''': contendrá la aplicación de administración egAdmin. Aunque no es imprescindible que esta aplicación resida en el servidor, se incluye en la instalación para el caso en que la administración se haga directamente desde el servidor de aplicaciones.
**Carpeta '''egExplorer''': contendrá la aplicación cliente del egExplorer. Al igual que con el egAdmin, esta aplicación no es imprescindible que resida en el servidor.
**Carpeta '''egImportExport''': contendrá la herramienta de importación de datos que será necesaria en el arranque del Sistema.
**Carpeta '''egTaskEditor''': contendrá la herramienta para la gestión del motor de workflow de la plataforma.
**Carpeta '''egTaskUpdater''': contendrá la herramienta para la actualización de los modelos de procesos implementados en la plataforma.
**Carpeta '''egTools''': contendrá la herramienta de acceso y administración del tablespace del sistema de gestión.
*Carpeta '''Modelos''': contendrá la descripción del sistema de gestión.
*Carpeta '''Registro''': contendrá el registro de operaciones que se realicen sobre el sistema de gestión.

Es importante que tanto el usuario de Windows que se nos proporcione para la administración como el usuario que inicie el egSystem tengan permisos de lectura y escritura sobre los directorios que han sido generados a raíz del fichero comprimido. Los directorios generados por el fichero comprimido pueden ser descomprimidos en cualquier ruta del servidor.

===Instalación de servicios===
Para que un centro funcione correctamente, es necesario instalar como servicios las aplicaciones egRouter y egServer. Esto quiere decir que las aplicaciones serán automáticamente arrancadas por el sistema operativo, y residirán en la memoria RAM del servidor. Pero para que esto ocurra, habrá que elaborar una serie de ficheros .bat.
====Instalación de egRouter====
Para la instalación del egRouter como servicio se incluye en la carpeta egRouter un fichero por lotes "'''Instalar Router.bat'''" con el siguiente contenido:

<pre>
copy srvany.exe "[RUTA_APLICACIONES]\egServices\"
instsrv egRouter2002 "[RUTA_APLICACIONES]\egServices\srvany.exe"
egRouter.reg
</pre>

Para instalarlo deben seguirse las siguientes instrucciones:
#En la carpeta ''egServices'' se proporciona una clave de registro con la ruta del egRouter: "'''egRouter.reg'''". Hay que editar este fichero para modificar y especificar la ruta correcta del "'''egRouter.exe'''" (debe ser una carpeta del equipo local).
#Modificar [RUTA_APLICACIONES] en el fichero "Instalar router.bat" para especificar la ruta correcta donde se va a ubicar la aplicación '''srvany''' (esta aplicación se proporciona en la carpeta egServices).
#Ejecutar el fichero "Instalar router.bat". En el proceso se instala la aplicación egRouter como servicio mediante las utilidades INSTSRV y SRVANY, y se añade la información pertinente en el registro.
#Una vez instalado el servicio se ha de configurar éste en Windows. En particular, debe especificarse que el usuario con el que se ejecuta es "Cuenta del sistema local" y el tipo de inicio "Automático". Para ello, habrá que acceder a '''Herramientas administrativas''' del ''Panel de Control'' de Windows. Una vez dentro, veremos un icono llamado '''Servicios'''. Al acceder, veremos todos los servicios instalados en el sistema. Seleccionamos el servicio perteneciente al egRouter y seleccionaremos las propiedades donde podremos configurar el servicio.

<center>
{|
|align="center" |[[Imagen:servicios0.jpg|border|250px]]
|}
</center>

<center>
{|
|align="center" |[[Imagen:servicios1.jpg|border|250px]]
|align="center" |[[Imagen:servicios2.jpg|border|250px]]
|}
</center>

====Instalación de egServer====
La instalación del egServer es muy similar. Para ello se proporciona el fichero por lotes "'''Instalar egServer.bat'''":

<pre>
copy srvany.exe "[RUTA_APLICACIONES]\egServices\"
instsrv egServer "[RUTA_APLICACIONES]\egServices\srvany.exe"
egServer.reg
</pre>

Las instrucciones son las mismas que para instalar el egRouter, sólo que esta vez se instala el servicio egServer con la clave de registro egServer.reg.
Estas operaciones debe realizarlas un usuario con permisos para instalar y administrar servicios.

===Instalación de la aplicación cliente===
La aplicación cliente '''egExplorer''' puede instalarse de dos formas:
#Se puede instalar una instancia de la aplicación en cada uno de los ordenadores de los usuarios finales.
#Se puede compartir en red con permisos de lectura la carpeta egExplorer, de modo que se puede crear un acceso directo a la aplicación en cada uno de los ordenadores finales.
Aunque los dos esquemas funcionan y la aplicación está preparada para actualizarse automáticamente, la experiencia nos ha demostrado que el segundo esquema es más efectivo, por lo que sería preferible.

Una vez instalado el paquete de aplicaciones que nos permitirán trabajar con un centro y desarrollado nuestro sistema de información en ODL, el siguiente paso es instalar nuestro centro. Para ello, existe un artículo que muestra los pasos a seguir para esta tarea, que se hará mediante la aplicación egAdmin. [[Cómo_instalar_un_centro_desde_cero|Ir al artículo]]

[[Categoría:Tutoriales]]

Cómo instalar un centro desde cero

2009-08-04T11:29:56Z

Imhernandez: /* Crear una base de datos en SQL Server */

Una vez compilado nuestro sistema de información en '''egeasy''', el siguiente paso es instalar nuestro centro. Como ya explicamos en el artículo [[Cómo compilar paso a paso|"Cómo compilar paso a paso"]], el compilador genera dos ficheros: un fichero comprimido .nmc que corresponde al modelo de centro y un fichero .ndc que corresponde al diccionario de definiciones que, como ya sabemos, está incluído dentro del fichero .ndc.
De estos dos ficheros, necesitamos el .nmc para instalar nuestro centro mediante la aplicación '''egAdmin''', pero además del modelo, necesitamos crear un servicio de base de datos que el centro necesitará para almacenar la información que se genere.
A continuación, dedicaremos dos secciones para la creación de una base de datos en SQL Server o un ''tablespace'' en el caso de Oracle.

__TOC__

==Crear un tablespace en Oracle==

:*Abriremos la aplicación '''"Enterprise Manager Console"''' desde el menú '''Inicio''' y nos conectaremos a la consola Oracle en modo autónomo:

<center>
{|
|align="center" |[[Imagen:oracle01.jpg|border|250px]]
|}
</center>

:*En Oracle, lo que generalmente se suele entender por base de datos (tablas, índices, etc.) se denomina esquema. Durante la instalación de la plataforma Oracle se crea una base de datos, que incluirá todos aquellos esquemas, tablespaces y usuarios que se creen. Para entrar en la base de datos, utilizaremos el usuario system que viene creado por defecto, con la contraseña que se le asignó durante la instalación, y que nos aparecerá si desplegamos el menú de la base de datos:

<center>
{|
|align="center" |[[Imagen:oracle02.jpg|border|250px]]
|}
</center>

:*Una vez dentro, crearemos un tablespace para obtener una estructura de almacenamiento lógico. Desplegaremos el menú de la base de datos y seleccionaremos '''Almacenamiento'''. Si observas, a la derecha hay un panel de opciones para la gestión del almacenamiento. Seleccionaremos haciendo click en el enlace '''"tablespaces"''' que vemos subrayado en azul:

<center>
{|
|align="center" |[[Imagen:oracle03.jpg|border|250px]]
|}
</center>

:*Nos aparecerá una ventana con dos pestañas: '''General''' y '''Almacenamiento'''. En la pestaña '''General''' indicaremos el nombre del tablespace en el campo '''Nombre''' y en la tabla '''Archivos de datos''' estableceremos un tamaño para el archivo del tablespace en la columna '''Tamaño''', bien en kilobytes o en megabytes. En la pestaña '''Almacenamiento''' no hará falta cambiar nada. Picaremos en '''Aplicar''' para crear el tablespace:

<center>
{|
|[[Imagen:oracle04.jpg|border|250px]]
|}
</center>

:*Si el tablespace se ha creado con éxito, aparecerá la siguiente ventana de confirmación:

<center>
{|
|align="center" |[[Imagen:oracle06.jpg|border|250px]]
|}
</center>

:*Para corroborar la creación de nuestro tablespace, desplegamos la carpeta '''Tablespaces''' incluída en '''Almacenamiento''' y comprobamos que el tablespace '''MITABLESPACE''' está creado. Si también desplegamos el menú de nuestro tablespace, veremos que en la carpeta '''Archivos de datos''' aparece el archivo .ORA creado.Es posible que nos interese aumentar el tablespace una vez se alcance la capacidad que le hemos asignado al archivo de datos en el paso anterior. Para ello, seleccionaremos el archivo .ORA, y a la derecha nos aparecerán dos pestañas: '''General''' y '''Almacenamiento'''. En '''General''' observaremos que se refleja el tamaño del archivo de datos que indicamos anteriormente. Para gestionar la extensión de almacenamiento de nuestro tablespace, abriremos la pestaña '''Almacenamiento'''. En ella activaremos la opción '''Ampliar automáticamente el archivo de datos cuando esté lleno''' y estableceremos un tamaño de almacenamiento que será la extensión que se producirá una vez se alcance el tamaño del archivo de datos. Además, en '''Tamaño máximo''' indicaremos en cuánto tamaño podremos extender el archivo de datos. O lo que es lo mismo, cuánto tamaño puede crecer nuestro archivo de datos. Si tenemos un archivo de datos de 100 Mb y nuestro tamaño máximo de extensión es de 50 Mb, el archivo de datos podrá tener una capacidad, como máximo, de 150 Mb. Si nuestra extensión fuera de 10Mb, sólo podríamos extender la capacidad del archivo de datos cinco veces:

<center>
{|
|align="center" |[[Imagen:oracleanexo2.jpg|border|250px]]
|}
</center>

:*A continuación, vamos a crear un usuario que pueda acceder a nuestro tablespace. Seleccionaremos el apartado '''Seguridad''' del desplegable. Al igual que en el tablespace, nos fijamos en el panel de la derecha '''Gestión de seguridad'''. Haremos click en el enlace '''"usuarios"''':

<center>
{|
|align="center" |[[Imagen:oracle07.jpg|border|250px]]
|}
</center>

:*Nos aparecerá una ventana con varias pestañas, en las cuales podremos configurar aspectos del usuario. En la primera pestaña, '''General''', daremos nombre al usuario y le asignaremos una contraseña. En la sección "Tablespaces" seleccionaremos en la opción "Por defecto" el tablespace que hemos creado utilizando el desplegable. Las demás opciones las dejaremos como están:

<center>
{|
|align="center" |[[Imagen:oracle08.jpg|border|250px]]
|}
</center>

:*En la pestaña '''Rol''' debe aparecer el rol CONNECT ya asignado. De no ser así, lo añadimos:

<center>
{|
|align="center" |[[Imagen:oracle09.jpg|border|250px]]
|}
</center>

:*La siguiente pestaña a tratar es '''Sistema'''. En ella seleccionaremos los privilegios del usuario de la lista que aparece en la parte superior de la ventana. En la siguiente imagen podremos observar los privilegios seleccionados más usuales para trabajar. En caso de necesitar alguno más, los seleccionaremos de la lista:

<center>
{|
|align="center" |[[Imagen:oracle10.jpg|border|250px]]
|}
</center>

:*Finalmente, en la pestaña '''Cuota''' seleccionaremos en el tablespace que hemos creado la cuota que queremos asignar a dicho usuario. En nuestro caso hemos seleccionado no limitado. También se podrá asignar un valor concreto en el botón '''Valor''' en la parte inferior de la ventana.En las demás pestañas no es necesario modificar nada, de modo que las dejaremos tal cual. Una vez hemos configurado al usuario, hacemos click en '''Crear''':

<center>
{|
|align="center" |[[Imagen:oracle11.jpg|border|250px]]
|}
</center>

==Crear una base de datos en SQL Server==
:*Abriremos la aplicación '''"Administrador Corporativo"''' desde el menú '''Inicio'''. Una vez abierto, seleccionamos el servidor (en este caso local) donde queremos crear nuestra base de datos. Hacemos click en el icono que se destaca en la siguiente imagen:

<center>
{|
|align="center" |[[Imagen:Sqlserver01.jpg|border|250px]]
|}
</center>

:*Aparecerá una ventana con tres pestañas. En la pestaña '''General''' incluiremos el nombre que queramos dar a nuestra base de datos rellenando el campo '''Nombre'''. En las demás pestañas dejaremos los valores por defecto:

<center>
{|
|align="center" |[[Imagen:Sqlserver02.jpg|border|250px]]
|}
</center>

:*Una vez creada la base de datos, podremos verla en el directorio desplegable '''Bases de datos'''. A continuación, para crear un usuario, haremos click en el siguiente icono '''Nuevo inicio de sesión''' que se destaca en la imagen:

<center>
{|
|align="center" |[[Imagen:Sqlserver03.jpg|border|250px]]
|}
</center>

:*En la ventana que aparece, indicaremos, en la pestaña '''General''', el nombre del usuario e introduciremos una contraseña como '''Autenticación de SQL Server'''.

<center>
{|
|align="center" |[[Imagen:Sqlserver04.jpg|border|250px]]
|}
</center>

:*Y, finalmente, en la pestaña '''Acceso a base de datos''' seleccionaremos las bases de datos a las que queramos que acceda el usuario que estamos creando. Activamos la casilla de la base de datos que hemos creado '''nuevabasededatos'''. Debajo de esa lista, aparece otra para asignar los permisos que queramos que tenga ese usuario sobre la base de datos que esté seleccionada en ese momento. Una vez aceptemos, el usuario '''nuevousuario''' podrá acceder a la base de datos '''nuevabasededatos''':

<center>
{|
|align="center" |[[Imagen:Sqlserver05.jpg|border|250px]]
|}
</center>

==Instalar un centro mediante egAdmin==

:*Una vez creada la base de datos que va a necesitar nuestro centro, ya estamos en disposición de poder instalarlo, y para ello, '''egeasy''' ofrece la herramienta de administración '''egAdmin'''. Por tanto, abriremos el egAdmin, y la primera operación que debemos hacer es conectarnos al servidor donde vamos a instalar nuestro centro:

<center>
{|
|align="center" |[[Imagen:eg_admin10.jpg|250px]]
|}
</center>

:*Si ya nos hemos conectado al servidor, antes de nada, deberemos instalar el modelo en el cuál se va a basar nuestro centro. Para ello, seleccionaremos la carpeta '''Modelos''' y haremos click en el icono de la parte superior '''Nuevo''':

<center>
{|
|[[Imagen:eg_admin03.jpg|250px]]
|}
</center>

:*El '''egAdmin''' nos pregunta si queremos actualizar el modelo; si le damos a "sí" nos aparecerá una ventana para indicar el fichero .nmc:

<center>
{|
|align="center" |[[Imagen:eg_admin04.jpg|250px]]
|align="center" |[[Imagen:eg_admin05.jpg|250px]]
|}
</center>

:*Una vez seleccionado el modelo y si no ha habido ningún error, nos saldrá un mensaje informativo indicando que el modelo se ha actualizado con éxito:

<center>
{|
|align="center" |[[Imagen:eg_admin06.jpg|250px]]
|}
</center>

:*Para terminar de instalar el modelo, le daremos un nombre, ya que si no se especifica la aplicación le asignará un nombre por defecto. En este caso, lo vamos a llamar '''Mi modelo'''. Además en la pestaña '''Definiciones''' podremos ver las definiciones en dos formatos distintos (modo árbol, modo lista) que tiene declaradas el modelo instalado, así como los DRC y demás datos de cada una de ellas:

<center>
{|
|align="center" |[[Imagen:eg_admin07.jpg|250px]]
|align="center" |[[Imagen:eg_admin08.jpg|250px]]
|align="center" |[[Imagen:eg_admin09.jpg|250px]]
|}
</center>

:*Teniendo ya nuestro modelo instalado, procederemos a crear nuestro centro. Seleccionaremos la carpeta '''Centros''' y, al igual que para la instalación de un modelo, haremos click en el icono de la parte superior '''Nuevo'''. Se nos creará un centro con un nombre por defecto:

<center>
{|
|align="center" |[[Imagen:eg_admin11.jpg|250px]]
|align="center" |[[Imagen:eg_admin12.jpg|250px]]
|}
</center>

:*Habrás observado que hay varias pestañas al seleccionar el centro. En la pestaña '''General''' renombraremos el centro e indicaremos un puerto por el cual acceder a la base de datos en el servidor donde está instalada:

<center>
{|
|align="center" |[[Imagen:eg_admin13.jpg|250px]]
|}
</center>

:*En la pestaña '''Configuración''' hay dos aspectos a configurar. Por un lado, en el apartado '''Modelo''' hay un desplegable donde aparecerán los modelos que tenemos instalados en el egAdmin, y por tanto, aparecerá nuestro modelo '''Mi modelo''', que lo seleccionaremos. Por otro lado, en la sección '''Base de datos''' introduciremos los datos necesarios para comunicarnos con la base de datos con la que va a trabajar el centro. Indicaremos el nombre del usuario que hemos creado para acceder a esa base de datos así como su contraseña. El siguiente dato a rellenar es el '''Nombre del servicio'''. Este dato varía en función del sistema de base de datos utilizado. En SQL Server tendremos que introducir el nombre del servidor, el símbolo '''#''', seguido del nombre de la base de datos creada. En el caso de Oracle, introduciremos el nombre del servicio de Oracle. Éste indica el nombre del servidor y el puerto donde está creada la base de datos. No es necesario indicar el ''tablespace'' que vamos a utilizar ya que el nombre de usuario ya tiene un tablespace asociado. En '''tipo de base de datos''' seleccionaremos el sistema de gestión de base de datos que utilizaremos e indicaremos también el '''número de conexiones máximas''' a la base de datos (no permite menos de 5 conexiones):

<center>
{|
|align="center" |[[Imagen:eg_admin14.jpg|250px]]
|}
</center>

:*En la siguiente pestaña, '''Documentos''', seleccionaremos la opción '''Almacenamiento en sistema de ficheros''', donde introduciremos una localización en el servidor para almacenar los documentos que se generen en el centro:

<center>
{|
|align="center" |[[Imagen:eg_admin15.jpg|250px]]
|}
</center>

:*A la hora de instalar un centro, se crean una serie de ficheros de texto donde se almacenan los mensajes generados por las distintas aplicaciones que intervienen en el arranque de un centro (llamados logs). De manera que podríamos acceder a estos ficheros para investigar un posible error que haya ocurrido al manipular un centro. Para ello, es necesario indicar un directorio donde se crearán el conjunto de carpetas y ficheros destinados a dicho fin. Lo añadiremos en el cuadro de texto '''Localización del registro''' de la pestaña '''Registro'''. Al instalar un centro, se crearán dichas carpetas y ficheros en el directorio especificado.Además, es posible activar una auditoría a nivel de usuarios, donde se registren aquellos accesos y modificaciones a ciertos recursos del centro que realicen los usuarios. A continuación, detallaremos qué aspectos hay que tener en cuenta a la hora de querer activar una auditoría en nuestro centro.Como vemos, hay una sección en la misma pestaña '''Registro''' llamada '''Auditoría''', donde configuraremos todo lo relacionado con la auditoría. Vemos que podemos auditar tres tipos de acceso, '''Inicio y fin de sesión''', '''Acceso a contenedores''' y '''Acceso a tareas'''. En principio nos saldrá la opción ''Ninguno'', es decir, que cualquiera de las tres auditorías estarán desactivadas. Para activarla, seleccionaremos '''Básico''' en el desplegable de cada una de las auditorías.Hasta ahora hemos dicho que los mensajes que se generan tanto a nivel de centro como a nivel de auditoría de usuarios se almacenan en ficheros. En el caso de las auditorías de usuarios, es posible además almacenar la información generada en la base de datos del centro. Vemos que para esto hay dos casillas llamadas '''Almacenar auditoría en ficheros''' y '''Almacenar auditoría en la base de datos''' que podremos activar. En caso de activar la auditoría en la base de datos, la información generada se almacenará en la tabla '''EG$LOG_SESSIONS''' para los accesos y salidas de sesión, y en la tabla '''EG$LOG_RESOURCES''' para los contenedores y tareas.Para acceder a la auditoría de la base de datos utilizaremos el '''egSQL''' o bien podremos realizar peticiones sobre las tablas nombradas con la opción '''Sentencia SQL''' del egAdmin. Para acceder a los ficheros, utilizaremos el menú ''Herramientas'' del egAdmin, y en la opción '''Ver logs''', podremos seleccionar el fichero que nos interese. Los tres últimos (contenedores, tareas y sesiones) corresponden a la auditoría de los usuarios. El resto está relacionado con las aplicaciones servidoras, intalación del centro, etc:

<center>
{|
|align="center" |[[Imagen:eg_admin16.jpg|250px]]
|align="center" |[[Imagen:eg_admin18.jpg|250px]]
|}
</center>

<center>
{|
|align="center" |[[Imagen:eg_admin58.jpg|thumb|250px|Tabla EG$LOG_SESSIONS]]
|align="center" |[[Imagen:eg_admin59.jpg|thumb|250px|Tabla EG$LOG_RESOURCES]]
|}
</center>

<blockquote style="background: #ffffcc; border: 1px solid black; padding: 1em;">
'''NOTA:''' Además de lo comentado anteriormente sobre la auditoría de acceso a recursos de un centro por parte de los usuarios, hay que añadir un elemento más. Para el caso de los contenedores y las tareas, hay que añadir a nivel de ODL un atributo llamado {{AT|registrar_accesos}} en aquellas definiciones que queramos se auditen. Este atributo, de tipo entero, admitirá tres valores: '''0''', para no realizar ningún tipo de auditría; '''1''', para auditar los accesos de lectura; y '''2''', para auditar los accesos de modificación (incluídos los de lectura evidentemente).
</blockquote>

:*En la pestaña '''Variables''' se crearán las variables globales que se podrán utilizar en todo el conjunto del centro. Se podrá acceder a ellas desde código ODL, y serán de tipo texto, aunque le pasemos un valor numérico. Podremos crear o eliminar las variables en función de nuestras necesidades utilizando los botones '''Añadir fila''' y '''Eliminar fila'''.

<center>
{|
|align="center" |[[Imagen:eg_admin17.jpg|250px]]
|}
</center>

:*En la pestaña '''Formato firmas''', nos encontramos con tres secciones: '''Campos disponibles''', '''Nuevo formato de firma''' y '''Formato actual de la firma'''. Los campos que disponemos son el nombre del usuario, la firma en sí, el cargo y la delegación. Hay un formato preestablecido, pero es posible que nos interese variar el orden entre ellos o eliminar alguno. Para ello, seleccionaremos los campos que nos interesen en el orden que elijamos y haremos click en el botón '''Añadir'''. Cuando tengamos el formato deseado, haremos click en '''Guardar''' y veremos que aparecerá el formato elegido en la sección '''Formato actual de la firma''':

<center>
{|
|align="center" |[[Imagen:eg_admin19.jpg|250px]]
|align="center" |[[Imagen:eg_admin20.jpg|250px]]
|}
</center>

:*Terminando con las pestañas de configuración, nos queda hacer mención a las pestañas '''Grupos''' e '''Indexado'''. En '''Grupos''' indicaremos si el centro será público, o estará agrupado en algún grupo que previamente habremos creado. En caso de existir grupos, éstos aparecerán en el cuadro inferior, de manera que seleccionando '''Centro restringido a grupos''' podremos elegir los grupos a los que pertenecerá el centro.En la pestaña indexado '''Indexado''' podremos activar la opción de indexar nuestra base de datos. En caso de querer hacerlo, indicaremos los mismos datos que en la pestaña '''Configuración'''.

<center>
{|
|align="center" |[[Imagen:eg_admin21.jpg|250px]]
|align="center" |[[Imagen:eg_admin22.jpg|250px]]
|}
</center>

:*Una vez configurado todos aquellos parámetros necesarios para el correcto funcionamiento del centro, seleccionaremos el centro y haremos click en el menú ''Herramientas'' en la opción ''Instalar'' para realizar la instalación del centro. Una vez instalado, se crearán una serie de carpetas en el directorio donde se ha instalado el modelo, necesarias para la explotación de un centro.Es posible que te estés preguntando en qué momento configuraste ese directorio donde el modelo ha sido instalado. Y es que aún no hemos hablado de ello. Existe un fichero asociado a la aplicación '''egServer''' llamado '''egServer.ini''', donde introduciremos la ruta de instalación de modelos, bien local, bien servidora, en un parámetro llamado '''DIRECTORY_MODELS=ruta'''. Además de esto, existe una carpeta '''Default''' que contiene una serie de carpetas necesarias para la instalación. Estas carpetas son aquellas a las que hemos hecho mención en este párrafo. Por tanto, si hemos escrito la ruta en el fichero ''egServer.ini'' y hemos copiado la carpeta ''Default'' en la misma ruta, no debería dar ningún problema de instalación (en caso de error, se miraría el log del egServer en el menú ''Herramientas''->''Logs''->''egServer''). Si la instalación se realiza correctamente nos saldrá un mensaje de confirmación:

<center>
{|
|align="center" |[[Imagen:eg_admin23.jpg|250px]]
|align="center" |[[Imagen:eg_admin25.jpg|250px]]
|align="center" |[[Imagen:eg_admin24.jpg|250px]]
|}
</center>

===Creación de usuarios en un centro===
:*Para crear usuarios en un centro, también utilizaremos la herramienta '''egAdmin'''. Crearemos usuarios y le asignaremos a cada uno de ellos los roles que hayamos definido en nuestro código ODL.Para empezar, debemos seleccionar el centro donde queremos crear un usuario. Abriremos el desplegable y veremos una carpeta llamada '''Usuarios''' (encontrarás un usuario ya creado llamado "Administrador" que habrá sido creado por defecto). Seleccionaremos dicha carpeta, y haremos click en el icono '''Nuevo''' que se encuentra en la parte superior izquierda de la ventana del '''egAdmin''':

<center>
{|
|align="center" |[[Imagen:eg_admin32.jpg|250px]]
|align="center" |[[Imagen:eg_admin33.jpg|250px]]
|}
</center>

:*Veremos que en el usuario que hemos creado, podemos desplegar un menú. Si lo despliegas, aparecerá una carpeta llamada '''Roles'''. Para asignarle roles a un usuario, seleccionaremos esta carpeta y haremos click en '''Nuevo''' otra vez.Aparecerán los roles que se encuentran definidos en ODL, de manera que seleccionaremos los roles que nos interese asignar al usuario creado. En '''Buscar roles''' podremos encontrar rápidamente un rol determinado filtrando con una palabra clave:

<center>
{|
|align="center" |[[Imagen:eg_admin34.jpg|250px]]
|align="center" |[[Imagen:eg_admin35.jpg|250px]]
|}
</center>

:*Hemos puesto una fecha de caducidad que se aplicará a todos los roles que escojamos. Lo mismo ocurre con el pie de firma y los comentarios, que se asignarán a todos aquellos que seleccionemos:

<center>
{|
|align="center" |[[Imagen:eg_admin37.jpg|250px]]
|}
</center>

:*Una vez creado el usuario, veremos que se crea otro desplegable que nace de la carpeta '''Roles''' de nuestro usuario con cada uno de los roles elegidos. Si seleccionamos uno de ellos, en el panel de la derecha aparecerá una sección con aspectos relacionados con ese rol. Por ejemplo, en la pestaña '''General''' podremos modificar la fecha de caducidad, el pie de firma o el comentario, pero esta vez de una forma particular para cada rol. También aparece la casilla '''"Activo"''' para activar o desactivar un rol (no se pueden eliminar roles asociados a un usuario). Si desactivos esta casilla y guardamos en el botón '''Guardar''', veremos que el rol queda inactivo:

<center>
{|
|align="center" |[[Imagen:eg_admin38.jpg|250px]]
|}
</center>

:*En la pestaña '''Permisos efectivos''' aparecerán los permisos asociados al rol seleccionado, pero concretando sobre qué definiciones de ODL actúan. Para ello, se distinguen tres pestañas: una para accesos a contenedores, otra para realización de tareas, y una última para los permisos de firmas. En la pestaña '''Histórico''' se registrarán todos los cambios que se produzcan sobre dicho rol (cambios en la fecha de caducidad, cambios en la activación, etc.). Podremos mostrar vistas personalizadas sobre el histórico haciendo click con el botón derecho del ratón en el panel. Aparecerá un menú (ya visto anteriormente) para configurar dichas vistas o filtros de datos:

<center>
{|
|align="center" |[[Imagen:eg_admin39.jpg|250px]]
|align="center" |[[Imagen:eg_admin40.jpg|250px]]
|}
</center>

:*Volvamos a seleccionar nuevamente al usuario creado. En la pestaña '''General''' podremos personalizar diferentes datos del usuario (nombre, nombre completo, iniciales y contraseña). Además, en esta pestaña podemos controlar otros aspectos del usuario. Como podrás ver en la imagen que viene a continuación, hay tres casillas que podemos activar o desactivar. La primera casilla, '''Activo''', se utiliza para inhabilitar o habilitar a un usuario. En caso de estar marcada, el usuario podrá acceder al centro. En la casilla '''Firmar mediante certificado digital''' activaremos esta opción si el usuario tuviese este servicio activado. Y finalmente, la casilla '''Contraseña obligatoria''' que en caso de marcarla obligará al usuario a tener en todo momento una palabra de paso para su acceso al sistema de información:

<center>
{|
|align="center" |[[Imagen:eg_admin41.jpg|250px]]
|}
</center>

:*En la pestaña '''Localización''' podremos introducir datos más concretos sobre el usuario. Algunos de ellos, como por ejemplo '''Sede''', '''Departamento''' y '''Cargo''', son utilizados en el firmado de documentos como información adicional a la firma:

<center>
{|
|align="center" |[[Imagen:eg_admin42.jpg|250px]]
|}
</center>

:*La pestaña '''Política''' sirve para configurar aspectos relacionados con la cuenta de usuario, principalmente para ofrecer cierta seguridad sobre la misma. Por ejemplo, podremos configurar la caducidad de la contraseña o la longitud mínima de la contraseña. También podremos bloquear una cuenta si se realizan equis intentos fallidos en su acceso, o si bien lleva un cierto tiempo sin utilizarse:

<center>
{|
|align="center" |[[Imagen:eg_admin43.jpg|250px]]
|}
</center>

:*Finalmente, en la pestaña '''Imágenes''' podremos insertar una imagen del usuario, así como la de su firma (formato .bmp). En '''Formato firma''' podremos configurar el formato de la firma, como ya explicamos anteriormente, y en Permisos efectivos aparecerán la suma de todos los permisos de los diferentes roles que pueda tener asociado el usuario.

[[Categoría:Tutoriales]]

Cómo instalar un centro desde cero

2009-08-04T11:26:14Z

Imhernandez: /* Crear un tablespace en Oracle */

Una vez compilado nuestro sistema de información en '''egeasy''', el siguiente paso es instalar nuestro centro. Como ya explicamos en el artículo [[Cómo compilar paso a paso|"Cómo compilar paso a paso"]], el compilador genera dos ficheros: un fichero comprimido .nmc que corresponde al modelo de centro y un fichero .ndc que corresponde al diccionario de definiciones que, como ya sabemos, está incluído dentro del fichero .ndc.
De estos dos ficheros, necesitamos el .nmc para instalar nuestro centro mediante la aplicación '''egAdmin''', pero además del modelo, necesitamos crear un servicio de base de datos que el centro necesitará para almacenar la información que se genere.
A continuación, dedicaremos dos secciones para la creación de una base de datos en SQL Server o un ''tablespace'' en el caso de Oracle.

__TOC__

==Crear un tablespace en Oracle==

:*Abriremos la aplicación '''"Enterprise Manager Console"''' desde el menú '''Inicio''' y nos conectaremos a la consola Oracle en modo autónomo:

<center>
{|
|align="center" |[[Imagen:oracle01.jpg|border|250px]]
|}
</center>

:*En Oracle, lo que generalmente se suele entender por base de datos (tablas, índices, etc.) se denomina esquema. Durante la instalación de la plataforma Oracle se crea una base de datos, que incluirá todos aquellos esquemas, tablespaces y usuarios que se creen. Para entrar en la base de datos, utilizaremos el usuario system que viene creado por defecto, con la contraseña que se le asignó durante la instalación, y que nos aparecerá si desplegamos el menú de la base de datos:

<center>
{|
|align="center" |[[Imagen:oracle02.jpg|border|250px]]
|}
</center>

:*Una vez dentro, crearemos un tablespace para obtener una estructura de almacenamiento lógico. Desplegaremos el menú de la base de datos y seleccionaremos '''Almacenamiento'''. Si observas, a la derecha hay un panel de opciones para la gestión del almacenamiento. Seleccionaremos haciendo click en el enlace '''"tablespaces"''' que vemos subrayado en azul:

<center>
{|
|align="center" |[[Imagen:oracle03.jpg|border|250px]]
|}
</center>

:*Nos aparecerá una ventana con dos pestañas: '''General''' y '''Almacenamiento'''. En la pestaña '''General''' indicaremos el nombre del tablespace en el campo '''Nombre''' y en la tabla '''Archivos de datos''' estableceremos un tamaño para el archivo del tablespace en la columna '''Tamaño''', bien en kilobytes o en megabytes. En la pestaña '''Almacenamiento''' no hará falta cambiar nada. Picaremos en '''Aplicar''' para crear el tablespace:

<center>
{|
|[[Imagen:oracle04.jpg|border|250px]]
|}
</center>

:*Si el tablespace se ha creado con éxito, aparecerá la siguiente ventana de confirmación:

<center>
{|
|align="center" |[[Imagen:oracle06.jpg|border|250px]]
|}
</center>

:*Para corroborar la creación de nuestro tablespace, desplegamos la carpeta '''Tablespaces''' incluída en '''Almacenamiento''' y comprobamos que el tablespace '''MITABLESPACE''' está creado. Si también desplegamos el menú de nuestro tablespace, veremos que en la carpeta '''Archivos de datos''' aparece el archivo .ORA creado.Es posible que nos interese aumentar el tablespace una vez se alcance la capacidad que le hemos asignado al archivo de datos en el paso anterior. Para ello, seleccionaremos el archivo .ORA, y a la derecha nos aparecerán dos pestañas: '''General''' y '''Almacenamiento'''. En '''General''' observaremos que se refleja el tamaño del archivo de datos que indicamos anteriormente. Para gestionar la extensión de almacenamiento de nuestro tablespace, abriremos la pestaña '''Almacenamiento'''. En ella activaremos la opción '''Ampliar automáticamente el archivo de datos cuando esté lleno''' y estableceremos un tamaño de almacenamiento que será la extensión que se producirá una vez se alcance el tamaño del archivo de datos. Además, en '''Tamaño máximo''' indicaremos en cuánto tamaño podremos extender el archivo de datos. O lo que es lo mismo, cuánto tamaño puede crecer nuestro archivo de datos. Si tenemos un archivo de datos de 100 Mb y nuestro tamaño máximo de extensión es de 50 Mb, el archivo de datos podrá tener una capacidad, como máximo, de 150 Mb. Si nuestra extensión fuera de 10Mb, sólo podríamos extender la capacidad del archivo de datos cinco veces:

<center>
{|
|align="center" |[[Imagen:oracleanexo2.jpg|border|250px]]
|}
</center>

:*A continuación, vamos a crear un usuario que pueda acceder a nuestro tablespace. Seleccionaremos el apartado '''Seguridad''' del desplegable. Al igual que en el tablespace, nos fijamos en el panel de la derecha '''Gestión de seguridad'''. Haremos click en el enlace '''"usuarios"''':

<center>
{|
|align="center" |[[Imagen:oracle07.jpg|border|250px]]
|}
</center>

:*Nos aparecerá una ventana con varias pestañas, en las cuales podremos configurar aspectos del usuario. En la primera pestaña, '''General''', daremos nombre al usuario y le asignaremos una contraseña. En la sección "Tablespaces" seleccionaremos en la opción "Por defecto" el tablespace que hemos creado utilizando el desplegable. Las demás opciones las dejaremos como están:

<center>
{|
|align="center" |[[Imagen:oracle08.jpg|border|250px]]
|}
</center>

:*En la pestaña '''Rol''' debe aparecer el rol CONNECT ya asignado. De no ser así, lo añadimos:

<center>
{|
|align="center" |[[Imagen:oracle09.jpg|border|250px]]
|}
</center>

:*La siguiente pestaña a tratar es '''Sistema'''. En ella seleccionaremos los privilegios del usuario de la lista que aparece en la parte superior de la ventana. En la siguiente imagen podremos observar los privilegios seleccionados más usuales para trabajar. En caso de necesitar alguno más, los seleccionaremos de la lista:

<center>
{|
|align="center" |[[Imagen:oracle10.jpg|border|250px]]
|}
</center>

:*Finalmente, en la pestaña '''Cuota''' seleccionaremos en el tablespace que hemos creado la cuota que queremos asignar a dicho usuario. En nuestro caso hemos seleccionado no limitado. También se podrá asignar un valor concreto en el botón '''Valor''' en la parte inferior de la ventana.En las demás pestañas no es necesario modificar nada, de modo que las dejaremos tal cual. Una vez hemos configurado al usuario, hacemos click en '''Crear''':

<center>
{|
|align="center" |[[Imagen:oracle11.jpg|border|250px]]
|}
</center>

==Crear una base de datos en SQL Server==
:*Abriremos la aplicación '''"Administrador Corporativo"''' desde el menú '''Inicio'''. Una vez abierto, seleccionaremos el servidor (en este caso local) donde queremos crear nuestra base de datos. Haremos click en el icono que se destaca en la siguiente imagen:

<center>
{|
|align="center" |[[Imagen:Sqlserver01.jpg|border|250px]]
|}
</center>

:*Aparecerá una ventana con tres pestañas. En la pestaña '''General''', incluiremos el nombre que queramos dar a nuestra base de datos rellenando el campo '''Nombre'''. Las demás pestañas dejaremos sus valores por defecto:

<center>
{|
|align="center" |[[Imagen:Sqlserver02.jpg|border|250px]]
|}
</center>

:*Una vez creada la base de datos, podremos verla en el directorio desplegable '''Bases de datos'''. A continuación, para crear un usuario, haremos click en el siguiente icono '''Nuevo inicio de sesión''' que se destaca en la imagen:

<center>
{|
|align="center" |[[Imagen:Sqlserver03.jpg|border|250px]]
|}
</center>

:*En la ventana que aparece, indicaremos en la pestaña '''General''' el nombre del usuario e introduciremos una contraseña como '''Autenticación de SQL Server'''.

<center>
{|
|align="center" |[[Imagen:Sqlserver04.jpg|border|250px]]
|}
</center>

:*Y finalmente, en la pestaña '''Acceso a base de datos''' seleccionaremos las bases de datos a las que queramos que acceda el usuario que estamos creando. Activamos la casilla de la base de datos que hemos creado '''nuevabasededatos''' y debajo de esa lista, aparece otra para asignar los permisos que queramos tenga ese usuario sobre la base de datos que esté seleccionada en ese momento. Una vez aceptado, el usuario '''nuevousuario''' podrá acceder a la base de datos '''nuevabasededatos''':

<center>
{|
|align="center" |[[Imagen:Sqlserver05.jpg|border|250px]]
|}
</center>

==Instalar un centro mediante egAdmin==

:*Una vez creada la base de datos que va a necesitar nuestro centro, ya estamos en disposición de poder instalarlo, y para ello, '''egeasy''' ofrece la herramienta de administración '''egAdmin'''. Por tanto, abriremos el egAdmin, y la primera operación que debemos hacer es conectarnos al servidor donde vamos a instalar nuestro centro:

<center>
{|
|align="center" |[[Imagen:eg_admin10.jpg|250px]]
|}
</center>

:*Si ya nos hemos conectado al servidor, antes de nada, deberemos instalar el modelo en el cuál se va a basar nuestro centro. Para ello, seleccionaremos la carpeta '''Modelos''' y haremos click en el icono de la parte superior '''Nuevo''':

<center>
{|
|[[Imagen:eg_admin03.jpg|250px]]
|}
</center>

:*El '''egAdmin''' nos pregunta si queremos actualizar el modelo; si le damos a "sí" nos aparecerá una ventana para indicar el fichero .nmc:

<center>
{|
|align="center" |[[Imagen:eg_admin04.jpg|250px]]
|align="center" |[[Imagen:eg_admin05.jpg|250px]]
|}
</center>

:*Una vez seleccionado el modelo y si no ha habido ningún error, nos saldrá un mensaje informativo indicando que el modelo se ha actualizado con éxito:

<center>
{|
|align="center" |[[Imagen:eg_admin06.jpg|250px]]
|}
</center>

:*Para terminar de instalar el modelo, le daremos un nombre, ya que si no se especifica la aplicación le asignará un nombre por defecto. En este caso, lo vamos a llamar '''Mi modelo'''. Además en la pestaña '''Definiciones''' podremos ver las definiciones en dos formatos distintos (modo árbol, modo lista) que tiene declaradas el modelo instalado, así como los DRC y demás datos de cada una de ellas:

<center>
{|
|align="center" |[[Imagen:eg_admin07.jpg|250px]]
|align="center" |[[Imagen:eg_admin08.jpg|250px]]
|align="center" |[[Imagen:eg_admin09.jpg|250px]]
|}
</center>

:*Teniendo ya nuestro modelo instalado, procederemos a crear nuestro centro. Seleccionaremos la carpeta '''Centros''' y, al igual que para la instalación de un modelo, haremos click en el icono de la parte superior '''Nuevo'''. Se nos creará un centro con un nombre por defecto:

<center>
{|
|align="center" |[[Imagen:eg_admin11.jpg|250px]]
|align="center" |[[Imagen:eg_admin12.jpg|250px]]
|}
</center>

:*Habrás observado que hay varias pestañas al seleccionar el centro. En la pestaña '''General''' renombraremos el centro e indicaremos un puerto por el cual acceder a la base de datos en el servidor donde está instalada:

<center>
{|
|align="center" |[[Imagen:eg_admin13.jpg|250px]]
|}
</center>

:*En la pestaña '''Configuración''' hay dos aspectos a configurar. Por un lado, en el apartado '''Modelo''' hay un desplegable donde aparecerán los modelos que tenemos instalados en el egAdmin, y por tanto, aparecerá nuestro modelo '''Mi modelo''', que lo seleccionaremos. Por otro lado, en la sección '''Base de datos''' introduciremos los datos necesarios para comunicarnos con la base de datos con la que va a trabajar el centro. Indicaremos el nombre del usuario que hemos creado para acceder a esa base de datos así como su contraseña. El siguiente dato a rellenar es el '''Nombre del servicio'''. Este dato varía en función del sistema de base de datos utilizado. En SQL Server tendremos que introducir el nombre del servidor, el símbolo '''#''', seguido del nombre de la base de datos creada. En el caso de Oracle, introduciremos el nombre del servicio de Oracle. Éste indica el nombre del servidor y el puerto donde está creada la base de datos. No es necesario indicar el ''tablespace'' que vamos a utilizar ya que el nombre de usuario ya tiene un tablespace asociado. En '''tipo de base de datos''' seleccionaremos el sistema de gestión de base de datos que utilizaremos e indicaremos también el '''número de conexiones máximas''' a la base de datos (no permite menos de 5 conexiones):

<center>
{|
|align="center" |[[Imagen:eg_admin14.jpg|250px]]
|}
</center>

:*En la siguiente pestaña, '''Documentos''', seleccionaremos la opción '''Almacenamiento en sistema de ficheros''', donde introduciremos una localización en el servidor para almacenar los documentos que se generen en el centro:

<center>
{|
|align="center" |[[Imagen:eg_admin15.jpg|250px]]
|}
</center>

:*A la hora de instalar un centro, se crean una serie de ficheros de texto donde se almacenan los mensajes generados por las distintas aplicaciones que intervienen en el arranque de un centro (llamados logs). De manera que podríamos acceder a estos ficheros para investigar un posible error que haya ocurrido al manipular un centro. Para ello, es necesario indicar un directorio donde se crearán el conjunto de carpetas y ficheros destinados a dicho fin. Lo añadiremos en el cuadro de texto '''Localización del registro''' de la pestaña '''Registro'''. Al instalar un centro, se crearán dichas carpetas y ficheros en el directorio especificado.Además, es posible activar una auditoría a nivel de usuarios, donde se registren aquellos accesos y modificaciones a ciertos recursos del centro que realicen los usuarios. A continuación, detallaremos qué aspectos hay que tener en cuenta a la hora de querer activar una auditoría en nuestro centro.Como vemos, hay una sección en la misma pestaña '''Registro''' llamada '''Auditoría''', donde configuraremos todo lo relacionado con la auditoría. Vemos que podemos auditar tres tipos de acceso, '''Inicio y fin de sesión''', '''Acceso a contenedores''' y '''Acceso a tareas'''. En principio nos saldrá la opción ''Ninguno'', es decir, que cualquiera de las tres auditorías estarán desactivadas. Para activarla, seleccionaremos '''Básico''' en el desplegable de cada una de las auditorías.Hasta ahora hemos dicho que los mensajes que se generan tanto a nivel de centro como a nivel de auditoría de usuarios se almacenan en ficheros. En el caso de las auditorías de usuarios, es posible además almacenar la información generada en la base de datos del centro. Vemos que para esto hay dos casillas llamadas '''Almacenar auditoría en ficheros''' y '''Almacenar auditoría en la base de datos''' que podremos activar. En caso de activar la auditoría en la base de datos, la información generada se almacenará en la tabla '''EG$LOG_SESSIONS''' para los accesos y salidas de sesión, y en la tabla '''EG$LOG_RESOURCES''' para los contenedores y tareas.Para acceder a la auditoría de la base de datos utilizaremos el '''egSQL''' o bien podremos realizar peticiones sobre las tablas nombradas con la opción '''Sentencia SQL''' del egAdmin. Para acceder a los ficheros, utilizaremos el menú ''Herramientas'' del egAdmin, y en la opción '''Ver logs''', podremos seleccionar el fichero que nos interese. Los tres últimos (contenedores, tareas y sesiones) corresponden a la auditoría de los usuarios. El resto está relacionado con las aplicaciones servidoras, intalación del centro, etc:

<center>
{|
|align="center" |[[Imagen:eg_admin16.jpg|250px]]
|align="center" |[[Imagen:eg_admin18.jpg|250px]]
|}
</center>

<center>
{|
|align="center" |[[Imagen:eg_admin58.jpg|thumb|250px|Tabla EG$LOG_SESSIONS]]
|align="center" |[[Imagen:eg_admin59.jpg|thumb|250px|Tabla EG$LOG_RESOURCES]]
|}
</center>

<blockquote style="background: #ffffcc; border: 1px solid black; padding: 1em;">
'''NOTA:''' Además de lo comentado anteriormente sobre la auditoría de acceso a recursos de un centro por parte de los usuarios, hay que añadir un elemento más. Para el caso de los contenedores y las tareas, hay que añadir a nivel de ODL un atributo llamado {{AT|registrar_accesos}} en aquellas definiciones que queramos se auditen. Este atributo, de tipo entero, admitirá tres valores: '''0''', para no realizar ningún tipo de auditría; '''1''', para auditar los accesos de lectura; y '''2''', para auditar los accesos de modificación (incluídos los de lectura evidentemente).
</blockquote>

:*En la pestaña '''Variables''' se crearán las variables globales que se podrán utilizar en todo el conjunto del centro. Se podrá acceder a ellas desde código ODL, y serán de tipo texto, aunque le pasemos un valor numérico. Podremos crear o eliminar las variables en función de nuestras necesidades utilizando los botones '''Añadir fila''' y '''Eliminar fila'''.

<center>
{|
|align="center" |[[Imagen:eg_admin17.jpg|250px]]
|}
</center>

:*En la pestaña '''Formato firmas''', nos encontramos con tres secciones: '''Campos disponibles''', '''Nuevo formato de firma''' y '''Formato actual de la firma'''. Los campos que disponemos son el nombre del usuario, la firma en sí, el cargo y la delegación. Hay un formato preestablecido, pero es posible que nos interese variar el orden entre ellos o eliminar alguno. Para ello, seleccionaremos los campos que nos interesen en el orden que elijamos y haremos click en el botón '''Añadir'''. Cuando tengamos el formato deseado, haremos click en '''Guardar''' y veremos que aparecerá el formato elegido en la sección '''Formato actual de la firma''':

<center>
{|
|align="center" |[[Imagen:eg_admin19.jpg|250px]]
|align="center" |[[Imagen:eg_admin20.jpg|250px]]
|}
</center>

:*Terminando con las pestañas de configuración, nos queda hacer mención a las pestañas '''Grupos''' e '''Indexado'''. En '''Grupos''' indicaremos si el centro será público, o estará agrupado en algún grupo que previamente habremos creado. En caso de existir grupos, éstos aparecerán en el cuadro inferior, de manera que seleccionando '''Centro restringido a grupos''' podremos elegir los grupos a los que pertenecerá el centro.En la pestaña indexado '''Indexado''' podremos activar la opción de indexar nuestra base de datos. En caso de querer hacerlo, indicaremos los mismos datos que en la pestaña '''Configuración'''.

<center>
{|
|align="center" |[[Imagen:eg_admin21.jpg|250px]]
|align="center" |[[Imagen:eg_admin22.jpg|250px]]
|}
</center>

:*Una vez configurado todos aquellos parámetros necesarios para el correcto funcionamiento del centro, seleccionaremos el centro y haremos click en el menú ''Herramientas'' en la opción ''Instalar'' para realizar la instalación del centro. Una vez instalado, se crearán una serie de carpetas en el directorio donde se ha instalado el modelo, necesarias para la explotación de un centro.Es posible que te estés preguntando en qué momento configuraste ese directorio donde el modelo ha sido instalado. Y es que aún no hemos hablado de ello. Existe un fichero asociado a la aplicación '''egServer''' llamado '''egServer.ini''', donde introduciremos la ruta de instalación de modelos, bien local, bien servidora, en un parámetro llamado '''DIRECTORY_MODELS=ruta'''. Además de esto, existe una carpeta '''Default''' que contiene una serie de carpetas necesarias para la instalación. Estas carpetas son aquellas a las que hemos hecho mención en este párrafo. Por tanto, si hemos escrito la ruta en el fichero ''egServer.ini'' y hemos copiado la carpeta ''Default'' en la misma ruta, no debería dar ningún problema de instalación (en caso de error, se miraría el log del egServer en el menú ''Herramientas''->''Logs''->''egServer''). Si la instalación se realiza correctamente nos saldrá un mensaje de confirmación:

<center>
{|
|align="center" |[[Imagen:eg_admin23.jpg|250px]]
|align="center" |[[Imagen:eg_admin25.jpg|250px]]
|align="center" |[[Imagen:eg_admin24.jpg|250px]]
|}
</center>

===Creación de usuarios en un centro===
:*Para crear usuarios en un centro, también utilizaremos la herramienta '''egAdmin'''. Crearemos usuarios y le asignaremos a cada uno de ellos los roles que hayamos definido en nuestro código ODL.Para empezar, debemos seleccionar el centro donde queremos crear un usuario. Abriremos el desplegable y veremos una carpeta llamada '''Usuarios''' (encontrarás un usuario ya creado llamado "Administrador" que habrá sido creado por defecto). Seleccionaremos dicha carpeta, y haremos click en el icono '''Nuevo''' que se encuentra en la parte superior izquierda de la ventana del '''egAdmin''':

<center>
{|
|align="center" |[[Imagen:eg_admin32.jpg|250px]]
|align="center" |[[Imagen:eg_admin33.jpg|250px]]
|}
</center>

:*Veremos que en el usuario que hemos creado, podemos desplegar un menú. Si lo despliegas, aparecerá una carpeta llamada '''Roles'''. Para asignarle roles a un usuario, seleccionaremos esta carpeta y haremos click en '''Nuevo''' otra vez.Aparecerán los roles que se encuentran definidos en ODL, de manera que seleccionaremos los roles que nos interese asignar al usuario creado. En '''Buscar roles''' podremos encontrar rápidamente un rol determinado filtrando con una palabra clave:

<center>
{|
|align="center" |[[Imagen:eg_admin34.jpg|250px]]
|align="center" |[[Imagen:eg_admin35.jpg|250px]]
|}
</center>

:*Hemos puesto una fecha de caducidad que se aplicará a todos los roles que escojamos. Lo mismo ocurre con el pie de firma y los comentarios, que se asignarán a todos aquellos que seleccionemos:

<center>
{|
|align="center" |[[Imagen:eg_admin37.jpg|250px]]
|}
</center>

:*Una vez creado el usuario, veremos que se crea otro desplegable que nace de la carpeta '''Roles''' de nuestro usuario con cada uno de los roles elegidos. Si seleccionamos uno de ellos, en el panel de la derecha aparecerá una sección con aspectos relacionados con ese rol. Por ejemplo, en la pestaña '''General''' podremos modificar la fecha de caducidad, el pie de firma o el comentario, pero esta vez de una forma particular para cada rol. También aparece la casilla '''"Activo"''' para activar o desactivar un rol (no se pueden eliminar roles asociados a un usuario). Si desactivos esta casilla y guardamos en el botón '''Guardar''', veremos que el rol queda inactivo:

<center>
{|
|align="center" |[[Imagen:eg_admin38.jpg|250px]]
|}
</center>

:*En la pestaña '''Permisos efectivos''' aparecerán los permisos asociados al rol seleccionado, pero concretando sobre qué definiciones de ODL actúan. Para ello, se distinguen tres pestañas: una para accesos a contenedores, otra para realización de tareas, y una última para los permisos de firmas. En la pestaña '''Histórico''' se registrarán todos los cambios que se produzcan sobre dicho rol (cambios en la fecha de caducidad, cambios en la activación, etc.). Podremos mostrar vistas personalizadas sobre el histórico haciendo click con el botón derecho del ratón en el panel. Aparecerá un menú (ya visto anteriormente) para configurar dichas vistas o filtros de datos:

<center>
{|
|align="center" |[[Imagen:eg_admin39.jpg|250px]]
|align="center" |[[Imagen:eg_admin40.jpg|250px]]
|}
</center>

:*Volvamos a seleccionar nuevamente al usuario creado. En la pestaña '''General''' podremos personalizar diferentes datos del usuario (nombre, nombre completo, iniciales y contraseña). Además, en esta pestaña podemos controlar otros aspectos del usuario. Como podrás ver en la imagen que viene a continuación, hay tres casillas que podemos activar o desactivar. La primera casilla, '''Activo''', se utiliza para inhabilitar o habilitar a un usuario. En caso de estar marcada, el usuario podrá acceder al centro. En la casilla '''Firmar mediante certificado digital''' activaremos esta opción si el usuario tuviese este servicio activado. Y finalmente, la casilla '''Contraseña obligatoria''' que en caso de marcarla obligará al usuario a tener en todo momento una palabra de paso para su acceso al sistema de información:

<center>
{|
|align="center" |[[Imagen:eg_admin41.jpg|250px]]
|}
</center>

:*En la pestaña '''Localización''' podremos introducir datos más concretos sobre el usuario. Algunos de ellos, como por ejemplo '''Sede''', '''Departamento''' y '''Cargo''', son utilizados en el firmado de documentos como información adicional a la firma:

<center>
{|
|align="center" |[[Imagen:eg_admin42.jpg|250px]]
|}
</center>

:*La pestaña '''Política''' sirve para configurar aspectos relacionados con la cuenta de usuario, principalmente para ofrecer cierta seguridad sobre la misma. Por ejemplo, podremos configurar la caducidad de la contraseña o la longitud mínima de la contraseña. También podremos bloquear una cuenta si se realizan equis intentos fallidos en su acceso, o si bien lleva un cierto tiempo sin utilizarse:

<center>
{|
|align="center" |[[Imagen:eg_admin43.jpg|250px]]
|}
</center>

:*Finalmente, en la pestaña '''Imágenes''' podremos insertar una imagen del usuario, así como la de su firma (formato .bmp). En '''Formato firma''' podremos configurar el formato de la firma, como ya explicamos anteriormente, y en Permisos efectivos aparecerán la suma de todos los permisos de los diferentes roles que pueda tener asociado el usuario.

[[Categoría:Tutoriales]]

Tarea I: Creando una oficina sin papeles

2009-08-04T11:12:45Z

Imhernandez: /* ¿Cómo funciona el motor de ''workflow''? */

[[Desarrollar_con_egeasy_paso_a_paso|Desarrollar con egeasy paso a paso]]
[[Imagen:Tarea_I_Figura_1_Diagrama_procedimiento.jpg|thumb|250px|Procedimiento de concesión de becas]]
 
Hasta ahora, los usuarios del Registro utilizan el software sólo para introducir o consultar datos, sin realizar ningún trámite ni llevar a cabo un procedimiento administrativo.
Supongamos que la organización ofrece becas para la realización de estudios en el extranjero. Estas becas las gestiona el Servicio de Ayudas y Subvenciones. Los interesados deben presentar las solicitudes en el Registro de Entrada y Salida. Un auxiliar del Registro revisa la documentación y, en caso de faltar algo, elabora un requerimiento para el interesado. Este requerimiento debe firmarlo el jefe de servicio del Registro.
Una vez la documentación esté completa, se remite al Servicio de Ayudas y Subvenciones quien resuelve la beca por el procedimiento de concurrencia sin concurso; es decir, que todos aquellos interesados que cumplan con los requisitos recibirán la beca.
Al recibir la documentación, un técnico del Servicio de Ayudas y Subvenciones comprueba la documentación para ver si el interesado cumple con los requisitos. A continuación, procede a elaborar resolución positiva (o negativa). La resolución la deben firmar el jefe del Servicio de Ayudas y Subvenciones y el director de la organización.
Una vez firmada, la resolución se remite al Registro, donde un auxiliar se encarga de darle salida.
El procedimiento se puede resumir en el siguiente diagrama.

__TOC__

==¿Qué nos hace falta?==
Para implementar este ''workflow'', primero debemos identificar los ítems de información y, a continuación, definirlos en el sistema. Analizando, vemos que necesitamos cuatro objetos diferentes:
*'''Entrada''', para las tareas de Registrar entrada de documentación y Comprobar documentación. Este tipo ya lo tenemos definido.
*'''Requerimiento''', para las tareas de Elaborar requerimiento y Firmar requerimiento.
*'''Resolución positiva''' y '''Resolución negativa''', para las tareas de Elaborar resolución positiva/negativa, Firmar propuesta de resolución, Firmar resolución y Registrar salida de documentación.

Además, todos los documentos relacionados con una solicitud deben almacenarse en alguna parte. Para ello, definiremos también el tipo '''Expediente de beca'''.

Por último, debemos definir dos nuevas habitaciones, donde se enviarán sus tareas específicas: la '''Oficina de Ayudas y Subvenciones''' y la '''Oficina de dirección'''.

==Definir los escritos==

Definimos el requerimiento de documentación con dos componentes: una componente [[Escritos|escrito]], para la plantilla del documento, y una componente formulario, para los campos firma.

{{PR|tipo}} [Requerimiento de documentación] {{PR|es}} {{RE|contenedor}}
[Escrito] {{PR|es}} {{T|documento}}
-{{AT|plantilla_documento}} = {{STR|"Req 001.rtf"}};
{{PR|fin}}

[Datos generales] {{PR|es}} {{T|formulario}}
[Firma del escrito] {{PR|es}} {{T|firma}}
{{PR|fin}}
{{PR|fin}}

Hacemos lo mismo para las resoluciones. En este caso, como las resoluciones la firman dos personas, debemos incluir dos campos firma, uno para la propuesta y otro para la resolución.

{{PR|tipo}} [Resolución positiva] {{PR|es}} {{RE|contenedor}}
[Escrito] {{PR|es}} {{T|documento}}
-{{AT|plantilla_documento}} = {{STR|"Res 001.rtf"}};
{{PR|fin}}

[Datos generales] {{PR|es}} {{T|formulario}}
[Firma de la propuesta] {{PR|es}} {{T|firma}}
[Firma de la resolución] {{PR|es}} {{T|firma}}
{{PR|fin}}
{{PR|fin}}

{{PR|tipo}} [Resolución negativa] {{PR|es}} {{RE|contenedor}}
[Escrito] {{PR|es}} {{T|documento}}
-{{AT|plantilla_documento}} = {{STR|"Res 002.rtf"}};
{{PR|fin}}

[Datos generales] {{PR|es}} {{T|formulario}}
[Firma de la propuesta] {{PR|es}} {{T|firma}}
[Firma de la resolución] {{PR|es}} {{T|firma}}
{{PR|fin}}
{{PR|fin}}

==Definir el Expediente de beca==
Cada vez que se inicie un trámite de beca, abriremos un expediente en el que se recogerá toda la documentación relacionada con el trámite. Este expediente tendrá un número (asignado automáticamente), que identificará el trámite, y una fecha de alta, que indicará la fecha en la que se inició el trámite. Asimismo, tendrá un vínculo a la '''Entrada''' que dio lugar al trámite.
Crearemos el expediente con dos componentes: una componente para el formulario de datos y otra para la colección en la que se almacenarán todos los documentos.
{{PR|tipo}} [Expediente de beca] {{PR|es}} {{RE|contenedor}}
[Datos generales] {{PR|es}} {{T|formulario}}
[Nº de expediente] {{PR|es}} {{T|timbre}}
-{{AT|certificado.valor}} = [&Valor_secuencia];
-{{AT|certificado.secuencia.nombre}} = {{STR|"STR$EXPEDIENTE"}};
-{{AT|certificado.secuencia.longitud}} = 5;
[Fecha de alta] {{PR|es}} {{T|fecha}}
[Solicitud] {{PR|es}} {{T|vinculo}}
-{{AT|vinculo.definicion}} = [Entrada];
-{{AT|vinculo.etiqueta}} = [Datos generales].[Número] + {{STR|" ("}}
+ [Datos generales].[Remitente]->[Datos generales].[Nombre/Razón social]
+ {{STR|" "}} + [Datos generales].[Remitente]->[Datos generales].[Apellidos]
+ {{STR|")"}};
-{{AT|vinculo.valores}} = $matriz([Libro de entrada].[Contenido]);
{{PR|fin}}

[Documentos] {{PR|es}} {{T|coleccion}}
-{{AT|nombre_tabla}} = {{STR|"TC$EXPEDIENTE_BECA"}};

{{PR|contiene}} [Requerimiento de documentación]
{{PR|contiene}} [Resolución positiva]
{{PR|contiene}} [Resolución negativa]

{{PR|columna}} [Nombre]
-{{AT|columna_bd.nombre}} = {{STR|"DOCUMENTO"}};
-{{AT|origen}} = [&Nombre];
{{PR|fin}}
{{PR|fin}}

Por último, necesitamos almacenar los expedientes en alguna parte. Para ello, crearemos un objeto del sistema en el que almacenarlos.

[Expedientes de beca] {{PR|es}} {{RE|contenedor}}
[Contenido] {{PR|es}} {{T|coleccion}}
-{{AT|nombre_tabla}} = {{STR|"TC$EXPEDIENTES"}};

{{PR|contiene}} [Expediente de beca]

{{PR|columna}} [Nº de expediente]
-{{AT|columna_bd.nombre}} = {{STR|"NUMERO"}};
-{{AT|origen}} = [Datos generales].[Nº de expediente];
{{PR|columna}} [Fecha de alta]
-{{AT|columna_bd.nombre}} = {{STR|"FECHA_ALTA"}};
-{{AT|origen}} = [Datos generales].[Fecha de alta];
{{PR|fin}}
{{PR|fin}}

==Definir las oficinas==
Tan sólo nos queda definir las oficinas y ubicar los recursos necesarios en cada una. En nuestro caso, se reduce sólo al estante de expedientes, ya que es el único recurso común a las tres oficinas.

[Oficina de Ayudas y Subvenciones] {{PR|es}} {{RE|habitacion}}
-{{AT|publico}} = falso;

{{PR|ubicado}} [Expedientes de beca]
-{{AT|lugar}} = {{STR|"Estantes"}};
{{PR|fin}}

[Oficina de la dirección] {{PR|es}} {{RE|habitacion}}
-{{AT|publico}} = falso;

{{PR|ubicado}} [Expedientes de beca]
-{{AT|lugar}} = {{STR|"Estantes"}};
{{PR|fin}}

==¿Cómo funciona el motor de ''workflow''?==
Hasta ahora nos hemos centrado en definir los ítems de información que nos iban a hacer falta para llevar a cabo el procedimiento de concesión de beca. En los próximos apartados veremos cómo implementar el flujo de trabajo, pero primero explicaremos cómo funciona el motor de ''workflow'' de la plataforma.
En egeasy, los procedimientos administrativos se definen en dos pasos. En primer lugar, debe definirse el flujo de tareas. Esta definición se hace en un fichero con extensión nmt. Los ficheros nmt son ficheros de texto plano que se crean en la carpeta Data del proyecto. Una vez definido el flujo de tareas, procederemos a definir los atributos de cada tarea: ítem de trabajo, código que se ejecuta al terminar la tareas, ... Estas definiciones se realizan en ficheros ndf, como hemos hecho con el resto de los recursos.
Comenzaremos con el flujo de tareas. Lo primero que debemos hacer es crear, en la carpeta Data, el fichero '''concesion_beca.nmt'''. A continuación, abrimos el fichero con el editplus.
Los ficheros nmt se componen de '''métodos'''. Por hacer un símil, un método sería equivalente a un procedimiento de PASCAL. Cada método lanza tareas, invoca a otros métodos y ejecuta sentencias en ODL. Adicionalmente, puede tener parámetros de E/S y variables locales.
Aquí tenemos un ejemplo.
{{PR|metodo}} RegistrarEntrada();
{{PR|var}}
TareaRegistro: {{RE|tarea}};
{{PR|inicio}}
TareaRegistro = {{T|$lanzar}}({{STR|"Registrar entrada"}});
TareaRegistro.[&Destino]->[Datos generales].[Asunto] = {{STR|"Esto es una prueba"}};
$guardar(TareaRegistro.[&Destino]);
{{PR|fin}}
En este segmento de código hemos definido el método RegistrarEntrada. A continuación, hemos definido la variable TareaRegistro de tipo {{RE|tarea}}. Después hemos definido la secuencia de tareas.
Cuando comienza la ejecución de un método, el motor de ''workflow'' posiciona el cursor en la primera línea del método que está justo después de '''inicio'''. Comienza a ejecutar línea por línea hasta que alguna de las sentencias lanza una tarea. Entonces, el sistema crea una nueva tarea, le asigna un ítem de trabajo y establece el estado de la tarea a '''pendiente'''. La ejecución del método queda detenida hasta que se finalice la tarea. En nuestro ejemplo, al iniciarse la ejecución del método se lanzaría la tarea '''Registrar entrada'''.
Cualquier usuario con los permisos suficientes puede ir a la bandeja de '''Tareas disponibles''' y '''comenzar la tarea'''. Cuando lo hace, la plataforma abre el ítem de trabajo asignado y cambia el estado de la tarea a '''realizándose'''.
Cuando el usuario finaliza la tarea, el sistema cambia el estado a '''terminada''' y retoma la ejecución del método que invocó a la tarea. En nuestro ejemplo, asignaría a la variable TareaRegistro la tarea que se acaba de terminar. A continuación, ejecutaría las siguientes líneas de código, que modifican el ítem de trabajo de la tarea para después almacenarlo.
Un método termina de ejecutarse cuando el cursor alcanza la palabra fin.

===¿Cómo comienza a ejecutarse un método?===
Todo proceso tiene un punto de entrada que lanza a ejecutar la primera línea del primer método. Este punto de entrada es un tipo de tarea que se define como raíz en los ficheros de definiciones ndf.Para cada proceso que exista en nuestro sistema de información, tendremos que definir una tarea, llamémosla ''inicializadora'' del proceso.Veamos a continuación la definición de esta tarea, que se corresponde con el proceso '''Solicitud de beca''':

{{PR|tipo}} [Solicitud de beca] {{PR|es}} {{RE|tarea}}
-{{AT|descripcion}} = {{STR|"Proceso que se encarga de realizar la resolución de una solicitud de beca"}};
-{{AT|fuente.definicion}} = [Registro de entrada y salida];
-{{AT|destino.definicion}} = [Expediente de beca];
-{{AT|destino.valor}} = $crear([Expedientes de beca].[Contenido]);
-{{AT|Al_Comenzar.Nombre}} = {{STR|"Metodos\concesion_beca.RegistrarEntrada"}};
-{{AT|es_raiz}} = verdadero;
{{PR|fin}}

La forma de indicar que la tarea '''Solicitud de beca''' inicia un proceso de nuestro sistema de información es mediante el atributo lógico '''es_raiz'''. Dicho atributo tiene asignado por defecto el valor falso, de forma que, poniéndolo a verdadero, conseguiremos que dicha tarea inicie un proceso que será lanzado por un usuario.Ahora bien, ¿sobre qué [[Contenedores|contenedor]] queremos que se lance la tarea?Siempre que lanzamos una tarea es necesario indicar sobre qué contenedor podremos lanzarla. Para ello, ODL proporciona un atributo llamado '''fuente.definicion'''. En el caso de una tarea raíz, se indicarán aquellas habitaciones a las que habrá que acceder para poder iniciar la tarea raíz. Por eso hemos indicado una habitación en vez de un contenedor en la definición de Solicitud de beca.Esto significa que el usuario podrá lanzar la tarea Solicitud de beca una vez haya accedido a la habitación Registro de entrada y salida. En posteriores definiciones de tareas, veremos que especificaremos un contenedor en vez de una habitación en el atributo fuente.definicion.El método a ejecutar una vez se lance la tarea, lo indicaremos en el atributo '''Al_Comenzar.Nombre''', que como vemos, tiene asignado el método creado anteriormente RegistrarEntrada. La manera de indicar el método es añadiendo la ruta del fichero donde está incluído a partir de la carpeta '''Data''' del modelo, seguido de un punto y el nombre del método.Por último, indicaremos en el atributo '''destino.definicion''' lo que se conoce como ''maintarget'' de un proceso, es decir, aquel contenedor que se asociará al proceso durante su ejecución.El ''maintarget'' de Solicitud de beca será un contenedor de tipo '''Expediente de beca'''. ¿Por qué? Porque las tareas que se lancen dentro de este proceso y la información que se genere se almacenará en un Expediente de beca.Además, no sólo queremos indicar el ''maintarget'' del proceso Solicitud de beca, sino que también queremos crear el expediente una vez se inicie el proceso. Para ello, utilizaremos la función '''$crear''' definida en la librería de funciones de ODL, que nos permite crear un objeto, indicándole la colección donde se va a almacenar. El tipo de objeto será el definido en destino.definicion. El objeto devuelto por $crear se asignará al atributo '''destino.valor'''.

===Interpretación del diagrama de flujo===
Antes de meternos de lleno a desarrollar el ''workflow'', vamos a estudiar el diagrama de flujo de información de concesión de becas facilitado al comienzo de este artículo.Es recomendable que abramos el diagrama ampliado en una pestaña nueva del navegador y lo mantengamos hasta el final de este artículo, de manera que podamos ir fijándonos en él a medida que vamos avanzando en el desarrollo del ''workflow''.Fijándonos en el diagrama, vemos que el flujo de trabajo está dividido en tres secciones, donde cada una de ellas equivale a una oficina de la organización. Dentro de cada oficina existen una serie de estados, que equivalen a las diferentes tareas que se pueden lanzar. Por tanto, habrá que implementar una tarea por cada estado que aparece en el diagrama.Si las tareas equivalen a los estados, el flujo de trabajo equivaldría a las líneas de transición que nos permiten cambiar de estado. En nuestro método RegistrarEntrada tendremos que implementar este flujo de trabajo.Podemos ver que para lanzar ciertas tareas, habrá que evaluar una condición. Por ejemplo, para lanzar la tarea ComprobarDocumentacion será necesario evaluar si la documentación necesaria está completa. De no ser así, se lanzaría la tarea ElaborarRequerimiento.Por tanto, en la implementación de nuestro método tendremos que plasmar el camino de datos que observamos en el diagrama.Además, el diagrama nos indica a qué oficina debe acceder un usuario para realizar cada una de las tareas, teniendolo en cuenta a la hora de definir los roles.

===Evolucionando el ''workflow''===
Antes de meternos de lleno en la elaboración del ''workflow'', hagamos un resumen de aquellos ficheros y nuevas definiciones que hemos creado.Por un lado, para poder desarrollar una concesión de beca, hemos definido un expediente de beca, un registro de expedientes de beca, un requerimiento de documentación y una resolución positiva y negativa de la concesión de una beca con la elaboración de sus respectivos documentos. Todas ellas son definiciones de tipo {{RE|contenedor}}, y serán los ítems con los que trabajaremos a lo largo de todo el flujo de información. Además, hemos definido una Oficina de Ayudas y Subvenciones y una Oficina de Dirección. Todas estas definiciones las hemos realizado en el fichero '''Main.ndf''' de la carpeta #Source.En esta misma carpeta, se encuentra el fichero '''tareas.ndf''' donde ya hemos definido la tarea raíz Solicitud de beca y donde vamos a definir el resto de tareas.Por último, en la carpeta Data\Metodos hemos creado el fichero '''concecion_beca.nmt''', donde hemos incluído un ejemplo del método RegistroEntrada.Una vez hecho este resumen, ahora sí que vamos a desarrollar nuestro proceso '''Solicitud de beca'''. Mostraremos paso a paso el código a introducir siguiendo el diagrama de flujo de información. Iremos alternando la implementación del método y de las tareas según lo vayamos necesitando.
 
Cuando se produce una '''Entrada''' para solicitar una beca, el sistema de información generará un '''Expediente de beca''' único y se registrará la entrada, que además estará asociada al expediente mediante el campo vínculo '''[Solicitud]'''. A partir de este momento, toda la información que genere el proceso tendrá asociado un Expediente de beca, por lo que el ''maintarget'' del proceso Solicitud de beca es el expediente creado.Por tanto, una vez lanzada la tarea raíz y empezada la ejecución el método RegistrarEntrada, habrá que crear un expediente de beca y registrar la entrada recibida lanzando las tareas correspondientes desde el método y definiéndolas:

{{PR|metodo}} RegistrarEntrada();
{{PR|var}}
{{PR|inicio}}
{{T|$lanzar}}({{STR|"Registrar expediente de beca"}});
{{T|$lanzar}}({{STR|"Registrar entrada"}});
{{PR|fin}}

La función '''$lanzar''', lanza una tarea cuyo nombre debemos pasar por parámetro, como vemos en el código. En este caso, no pasamos por parámetro ningún ítem (''target'') a la tarea, ya que será creado por la propia tarea, aunque veremos que en posteriores definiciones sí tendremos que incluir un ''target'' como parámetro de entrada. Además, también es posible indicar la habitación en la cuál un usuario podrá realizar la tarea. En caso de no especificarla, se tomará como habitación la definida en la tarea raíz, que en nuestro caso es '''Registro de entrada y salida'''.Definamos entonces dichas tareas en nuestro fichero ''tareas.ndf'':

{{PR|tipo}} [Registrar expediente de beca] {{PR|es}} {{RE|tarea}}
-{{AT|fuente.definicion}} = [Expediente de beca];
-{{AT|Al_finalizar.Codigo}} = {{STR|"$sellar([&Destino]->[Datos generales].[Nº de expediente]); $guardar([&Destino]); "}};
{{PR|fin}}

{{PR|tipo}} [Registrar entrada] {{PR|es}} {{RE|tarea}}
-{{AT|fuente.definicion}} = [Expediente de beca];
-{{AT|destino.definicion}} = [Entrada];
-{{AT|destino.valor}} = $crear([Libro de entrada].[Contenido]);
-{{AT|Al_finalizar.Codigo}} = {{STR|"$sellar([&Destino]->[Datos generales].[Número]); $guardar([&Destino]); "}};
{{PR|fin}}

En la tarea '''Registrar expediente de beca''', el atributo {{AT|fuente.definicion}} que hay definido ya lo conocemos. En él indicamos el objeto de referencia de la tarea. En el atributo {{AT|destino.definicion}}, que no aparece, deberíamos indicar el contenedor (''target'', ítem) con el que va a trabajar la tarea, pero este atributo, si no se especifica, asumirá como destino el contenedor definido en fuente.definicion. Equivaldría a poner <code>destino.definicion = [Expediente de beca]</code>.Por tanto, al arrancar esta tarea se creará un expediente nuevo. El atributo {{AT|Al_finalizar.Codigo}} nos permite invocar un método o directamente asignarle instrucciones en forma de ristra, que se ejecutarán en tiempo de ejecución una vez se finalice la tarea. En nuestro caso, se sellará el campo timbre que existe en el expediente y además se guardará el objeto. Para que entendamos bien las instrucciones empleadas en el atributo Al_finalizar.Codigo, es necesario conocer la propiedad '''[&Destino]''' de una tarea.Esta propiedad permite acceder al ''target'' actual de una tarea, que en el caso de Registrar expediente de beca, es un '''Expediente de beca'''. Una vez accedido al ''target'', podremos acceder a otros componentes que estén definidos en él, como, por ejemplo, a un campo timbre incluído en la definición de un formulario, que es exactamente lo que se realiza en nuestro caso. Con la función '''$sellar''', sellamos el campo timbre, y con la función '''$guardar''', guardamos el objeto.Una vez registrado un nuevo expediente, procederemos a registrar la entrada de petición de beca mediante la tarea '''Registrar entrada'''. La diferencia que podemos observar respecto a la tarea anterior es la inclusión de los atributos {{AT|destino.definicion}} y {{AT|destino.valor}}.¿Y por qué ahora sí están incluídos? Esto es debido a que esta tarea no va a registrar un Expediente de beca, sino que registrará una Entrada, aunque el objeto referencia de la tarea sí seguirá siendo el Expediente de beca creado anteriormente.Además, al finalizar la tarea ejecutaremos el mismo código que la tarea anterior, con la diferencia de que, en esta ocasión, la propiedad [&Destino] accederá a un objeto de tipo Entrada, que es el ''target'' de esta tarea. ¿Y el atributo {{AT|destino.valor}}?Como ya explicamos en la definición de la tarea raíz '''Solicitud de beca''', utilizaremos la función '''$crear''' en este atributo, para indicar la colección donde se va a guardar el objeto del tipo definido en el atributo {{AT|destino.definicion}}, es decir, un objeto de tipo Entrada.
 
Una vez realizada esta primera fase, volvemos a fijarnos en el diagrama, y vemos que una vez la Entrada es recibida, registrada, y creado su Expediente de beca, el siguiente paso sería comprobar la documentación. Para ello, es necesario que la documentación entregada por la persona que realiza la petición de la beca esté completa. En caso de no ser así, se generará un documento de requerimiento, que deberá ser firmado, dando lugar a posibles nuevas entradas en el proceso, pero con un Expediente de beca ya creado. Esto se producirá tantas veces como requerimientos de documentación se puedan dar. Una vez no falte ningún tipo de documentación, se lanzará la tarea '''Comprobar documentación'''.Pero, ¿y cómo podemos saber si en la solicitud de una beca falta documentación?Para ello, hemos modificado la definición del contenedor '''Entrada''', añadiendo simplemente un campo tabla para registrar la documentación y un campo de tipo texto llamado '''[Documentación completa]'''.Veamos primero los cambios introducidos, tanto en el contenedor '''Entrada''' como en el método, para comentarlos posteriormente:

[Sí o No] {{PR|es}} {{RE|enumerado}}
{{AT|valores}}
{{STR|"Sí"}},
{{STR|"No"}}
{{PR|fin}}

{{PR|tipo}} [Entrada] {{PR|es}} {{RE|contenedor}}
[Datos generales] {{PR|es}} {{T|formulario}}
...
...
...
[Documentación presentada] {{PR|es}} {{T|tabla}}
[Documento] {{PR|es}} {{T|texto}}
{{PR|fin}}
[Documentación completa] {{PR|es}} {{T|texto}}
-{{AT|apariencia.desplegable}} = verdadero;
-{{AT|edicion.seleccion}} = verdadero;
-{{AT|edicion.valores}} = $matriz([Sí o No]);
{{PR|fin}}
{{PR|fin}}

{{PR|metodo}} RegistrarEntrada();
{{PR|var}}
TareaRegistroBeca: tarea;
TareaRegistroEntrada: tarea;
ElaborarRequerimiento: tarea;
ElaborarResolucion: tarea;
documentacion_incompleta: logico;
{{PR|inicio}}
documentacion_incompleta = verdadero;
TareaRegistroBeca = {{T|$lanzar}}({{STR|"Registrar expediente de beca}}");
{{PR|mientras}} documentacion_incompleta
TareaRegistroEntrada = {{T|$lanzar}}({{STR|"Registrar entrada"}});
TareaRegistroBeca.[&Destino]->[Datos generales].[Solicitud] = TareaRegistroEntrada.[&Destino];
$guardar(TareaRegistroBeca.[&Destino]);
{{PR|si}} (TareaRegistroEntrada.[&Destino]->[Datos generales].[Documentación completa] = {{STR|"Sí"}})
documentacion_incompleta = falso;
{{PR|sino}}
ElaborarRequerimiento = {{T|$lanzar}}({{STR|"Elaborar requerimiento"}});
{{T|$lanzar}}({{STR|"Firmar requerimiento"}}, ElaborarRequerimiento.[&Destino]);
{{PR|fin}}
{{PR|fin}}
{{PR|fin}}

Vemos que en la definición de Entrada hemos incluído los campos que comentamos para comprobar la documentación.También podemos observar que hay una serie de variables declaradas en la implementación de nuestro método, las cuales nos permitirán almacenar en ellas un recurso del mismo tipo que el definido para la variable. La variable lógica '''documentacion_incompleta''', que inicializamos a "verdadero", la utilizaremos para controlar la salida del bucle que se ocupa de los requerimientos de documentación, y como consecuencia de nuevas entradas. Dicha salida se producirá cuando el campo [Documentación completa] de la Entrada actual tenga valor "Sí", asignándole "falso" a documentacion_incompleta.¿Y cómo consultamos dicho campo?Al lanzar la tarea '''Registrar entrada''', la almacenamos en la variable de tipo tarea '''TareaRegistroEntrada'''. Esto nos va a permitir acceder al ''target'' de la tarea mediante la propiedad [&Destino] en cualquier momento del código, ya que la tarea quedará almacenada en la variable. En este caso, el objeto es de tipo Entrada, por lo que podremos acceder al campo [Documentación completa] y realizar la consulta.Una vez la documentación esté completa, el usuario modificará el campo [Documentación completa] asignándole el valor "Sí", de manera que saldremos del bucle. En caso contrario, lanzaremos la tarea encargada de elaborar un requerimiento, que a su vez tendrá que ser firmada, lanzando la tarea correspondiente para dicha firma.Respecto a las tareas '''Elaborar requerimiento''' y '''Firmar requerimiento''', es necesario tener en cuenta lo siguiente:Al igual que en el lanzamiento de las demás tareas, la tarea Elaborar requerimiento también es asignada a una variable, en este caso, llamada '''ElaborarRequerimiento'''. A continuación, se lanza la tarea Firmar requerimiento, pero esta vez con un nuevo parámetro. Este parámetro corresponde al ''target'' de la tarea anterior, y lo indicamos como parámetro utilizando la variable ElaborarRequerimiento para acceder a la tarea junto con la propiedad [&Destino] para acceder a su ''target''. Esto lo realizamos porque la tarea Firmar requerimiento no va a crear ningún ''target'', sino que firmará el campo firma que se encuentra en el objeto '''Requerimiento de documentación''' creado en la tarea anterior. Por tanto, este objeto o ''target'' tendrá que ser pasado como parámetro a la tarea Firmar requerimiento.
Hay dos instrucciones que no hemos comentado aún. Son exactamente las dos instrucciones anteriores a la consulta del campo [Documentación completa].Como ya sabemos, nuestra definición de tipo contenedor Expediente de beca tiene un campo vínculo que referencia a la última Entrada que se haya almacenado en el expediente. Para que esto suceda, es necesario que después de registrar una nueva entrada se modifique este campo vínculo para que referencie al último objeto de tipo Entrada. Esto lo conseguimos utilizando dos variables de tipo tarea, una para la tarea Registrar expediente de beca y otra para Registrar entrada. En cada variable almacenamos cada una de las dos tareas, de manera que nos permitan acceder al ''target'' de cada una de ellas. Al campo vínculo '''TareaRegistroBeca.[&Destino]->[Datos generales].[Solicitud]''' le asignaremos el ''target'' de la tarea Registrar entrada, '''TareaRegistroEntrada.[&Destino]'''. Una vez asignada la Entrada al campo vínculo, se guardará el objeto para aplicar los cambios realizados en el objeto.Es necesario realizar estas dos acciones dentro del bucle y antes de realizar la comprobación del campo [Documentación completa] del objeto Entrada, ya que, en caso de no hacerlo, no se estará verificando el campo [Documentación completa] de la nueva Entrada, sino de la anterior, o de ninguna, en caso de que estemos tratando una primera entrada.Una vez analizado el nuevo código introducido en el método, veamos la definición de las nuevas tareas que aparecen; Elaborar requerimiento y Firmar requerimiento:

{{PR|tipo}} [Elaborar requerimiento] {{PR|es}} {{RE|tarea}}
-{{AT|fuente.definicion}} = [Expediente de beca];
-{{AT|destino.definicion}} = [Requerimiento de documentación];
-{{AT|destino.valor}} = $crear([Documentos]);
{{PR|fin}}

{{PR|tipo}} [Firmar requerimiento] {{PR|es}} {{RE|tarea}}
-{{AT|fuente.definicion}} = [Expediente de beca];
-{{AT|destino.definicion}} = [Requerimiento de documentación];
-{{AT|localizacion}} = [Datos generales];
-{{AT|Al_finalizar.Codigo}} = {{STR|"$firmar([&Destino]->[Datos generales].[Firma del escrito]); $guardar([&Destino]); "}};
{{PR|fin}}

Cabe comentar un atributo que hasta ahora no hemos tenido que utilizar. Se trata del atributo {{AT|localizacion}}. En él indicaremos una componente que queramos activar al iniciar la tarea, en principio, para su edición. En este caso, activamos la componente [Datos generales] del contenedor Requerimiento de documentación, que es donde está incluído el campo firma que vamos a editar en esta tarea. En caso de no hacerlo, no podríamos realizar la firma al ejecutar el código <code>{{STR|"$firmar([&Destino]->[Datos generales].[Firma del escrito])</code>.

Una vez hemos analizado ya varias definiciones de tareas, nos damos cuenta que el aspecto más importante a la hora de definir una tarea es tener muy claro el ''target'' con el que va a trabajar. Es decir, saber si el ''target'' será creado por la propia tarea o si, por el contrario, trabajará con un ''target'' ya creado.En caso de crear uno nuevo utilizaremos los atributos destino.definicion y destino.valor para especificar el tipo del objeto y el lugar donde se almacenará. En caso de utilizar uno creado por tareas anteriores, tendremos que incluir el ''target'' de la tarea anterior como parámetro de la nueva tarea. Esto lo conseguimos, como ya hemos visto, utilizando una variable en la cual almacenamos la tarea que nos interese, y con la propiedad [&Destino] referenciamos a su ''target''.

===Finalizando el ''workflow''===
Siguiendo con el flujo de trabajo, pasamos ahora a la siguiente oficina de nuestra organización: '''Servicio de Ayudas y Subvenciones'''.Una vez hemos verificado que la documentación de una solicitud está completa, pasamos a lanzar la tarea '''Comprobar documentación'''. Esta tarea abrirá la última Entrada que referencia el campo vínculo '''[Solicitud]''' de un expediente concreto y analizará la documentación entregada para elaborar una resolución positiva, en caso de cumplir los requisitos, o negativa, en caso de no cumplirlos. El ''target'' de esta tarea, tendrá que ser pasado como parámetro, que al ser la última Entrada registrada, podremos acceder a él utilizando la variable '''TareaRegistroEntrada'''. Pero hay que tener en cuenta otro aspecto a la hora de lanzar esta tarea.Hasta ahora, no nos hemos preocupado de la oficina en la cual podíamos realizar las tareas. Esto ha sido así debido a que las tareas hasta ahora lanzadas compartían la oficina de la tarea raíz (Registro de entrada y salida), y, por tanto, no se especificaba como parámetro al lanzar una tarea. Pero ahora sí es necesario especificarlo, ya que hemos cambiado de oficina. La sintaxis para hacerlo es la siguiente:

{{T|$lanzar}}({{STR|"nombre"}},target,[oficina])

Veamos el código a añadir en nuestro método y la implementación de la tarea '''Comprobar documentación''':

{{PR|metodo}} RegistrarEntrada();
{{PR|var}}
TareaRegistroBeca: tarea;
TareaRegistroEntrada: tarea;
ElaborarRequerimiento: tarea;
ElaborarResolucion: tarea;
DocumentacionComprobada: tarea;
documentacion_incompleta: logico;
{{PR|inicio}}
documentacion_incompleta = verdadero;
TareaRegistroBeca = {{T|$lanzar}}({{STR|"Registrar expediente de beca}}");
{{PR|mientras}} documentacion_incompleta
...
... {{COM|//Bucle}}
...
{{PR|fin}}
DocumentacionComprobada = {{T|$lanzar}}({{STR|"Comprobar documentación"}},TareaRegistroEntrada.[&Destino],[Oficina de Ayudas y Becas]);
{{PR|fin}}

{{PR|tipo}} [Comprobar documentación] {{PR|es}} {{RE|tarea}}
-{{AT|fuente.definicion}} = [Expediente de beca];
-{{AT|destino.definicion}} = [Entrada];
{{PR|fin}}

En este caso, el usuario de la Oficina de Ayudas y Subvenciones analizará la documentación presentada y dejará constancia de dicho análisis especificando si es un caso favorable o desfavorable para la concesión de una beca.Pero, ¿dónde deja constancia?Para ello, hemos definido otro campo de tipo texto en la definición de contenedor Entrada llamado '''[Cumple los requisitos]'''. Este será el campo donde se concretará si un solicitante cumple los requisitos. Veamos el código a incluir en la definición de Entrada:

{{PR|tipo}} [Entrada] {{PR|es}} {{RE|contenedor}}
[Datos generales] {{PR|es}} {{T|formulario}}
...
...
...
[Cumple los requisitos] {{PR|es}} {{T|texto}}
-{{AT|apariencia.desplegable}} = verdadero;
-{{AT|edicion.seleccion}} = verdadero;
-{{AT|edicion.valores}} = $matriz([Sí o No]);
{{PR|fin}}
{{PR|fin}}

Siguiendo con el flujo de trabajo del diagrama, las siguientes tareas a lanzar tratarían la elaboración de una resolución de beca, positiva o negativa, en función del valor que contenga el campo [Cumple los requisitos]. Por tanto, habrá que consultar dicho campo para saber cuál de las tareas lanzar:

{{PR|metodo}} RegistrarEntrada();
{{PR|var}}
TareaRegistroBeca: tarea;
TareaRegistroEntrada: tarea;
ElaborarRequerimiento: tarea;
ElaborarResolucion: tarea;
DocumentacionComprobada: tarea;
documentacion_incompleta: logico;
{{PR|inicio}}
documentacion_incompleta = verdadero;
TareaRegistroBeca = {{T|$lanzar}}({{STR|"Registrar expediente de beca}}");
{{PR|mientras}} documentacion_incompleta
...
... {{COM|//Bucle}}
...
{{PR|fin}} 
DocumentacionComprobada = {{T|$lanzar}}({{STR|"Comprobar documentación"}},TareaRegistroEntrada.[&Destino],[Oficina de Ayudas y Becas]); 
{{PR|si}} (DocumentacionComprobada.[&Destino]->[Datos generales].[Cumple los requisitos] = {{STR|"Sí"}}) 
ElaborarResolucion = {{T|$lanzar}}({{STR|"Elaborar resolución positiva"}},[Oficina de Ayudas y Subvenciones]); 
{{PR|sino}} 
ElaborarResolucion = {{T|$lanzar}}({{STR|"Elaborar resolución negativa"}},[Oficina de Ayudas y Subvenciones]); 
{{PR|fin}} 
{{PR|fin}}

Consultamos el campo [Cumple los requisitos] y en función de su valor se lanzará o bien la tarea '''Elaborar resolución positiva''' o '''Elaborar resolución negativa'''.Ambas tareas crearán un ''target'' nuevo, que será o bien un objeto de tipo Resolución positiva o Resolución negativa. Dicho objeto será posteriormente utilizado como ''target'' por las tareas '''Firmar propuesta de resolución''' y '''Firmar resolución''', de forma que tendrán que ser pasados por parámetro en dichas tareas. Una vez realizadas las dos firmas del documento generado, se creará un objeto de tipo Salida que se registrará en el Registro de Entrada y Salida:

{{PR|tipo}} [Elaborar resolución positiva] {{PR|es}} {{RE|tarea}}
-{{AT|fuente.definicion}} = [Expediente de beca];
-{{AT|destino.definicion}} = [Resolución positiva];
-{{AT|destino.valor}} = $crear([Documentos]);
{{PR|fin}}

{{PR|tipo}} [Elaborar resolución negativa] {{PR|es}} {{RE|tarea}}
-{{AT|fuente.definicion}} = [Expediente de beca];
-{{AT|destino.definicion}} = [Resolución negativa];
-{{AT|destino.valor}} = $crear([Documentos]);
{{PR|fin}}

{{PR|metodo}} RegistrarEntrada();
{{PR|var}}
TareaRegistroBeca: tarea;
TareaRegistroEntrada: tarea;
ElaborarRequerimiento: tarea;
ElaborarResolucion: tarea;
DocumentacionComprobada: tarea;
documentacion_incompleta: logico;
{{PR|inicio}}
documentacion_incompleta = verdadero;
TareaRegistroBeca = {{T|$lanzar}}({{STR|"Registrar expediente de beca}}");
{{PR|mientras}} documentacion_incompleta
...
... {{COM|//Bucle}}
...
{{PR|fin}} 
DocumentacionComprobada = {{T|$lanzar}}({{STR|"Comprobar documentación"}},TareaRegistroEntrada.[&Destino],[Oficina de Ayudas y Becas]); 
{{PR|si}} (DocumentacionComprobada.[&Destino]->[Datos generales].[Cumple los requisitos] = {{STR|"Sí"}}) 
ElaborarResolucion = {{T|$lanzar}}({{STR|"Elaborar resolución positiva"}},[Oficina de Ayudas y Subvenciones]); 
{{PR|sino}} 
ElaborarResolucion = {{T|$lanzar}}({{STR|"Elaborar resolución negativa"}},[Oficina de Ayudas y Subvenciones]); 
{{PR|fin}} 
{{T|$lanzar}}({{STR|"Firmar propuesta de resolución"}},ElaborarResolucion.[&Destino],[Oficina de Ayudas y Subvenciones]); 
{{T|$lanzar}}({{STR|"Firmar resolución"}},ElaborarResolucion.[&Destino],[Oficina de la dirección]); 
{{T|$lanzar}}({{STR|"Registrar salida de documentación"}}); 
{{PR|fin}}

{{PR|tipo}} [Firmar propuesta de resolución] {{PR|es}} {{RE|tarea}}
-{{AT|fuente.definicion}} = [Expediente de beca];
-{{AT|localizacion}} = [Datos generales];
-{{AT|Al_finalizar.Codigo}} = {{STR|"$firmar([&Destino]->[Datos generales].[Firma de la propuesta]); $guardar([&Destino]); "}};
{{PR|fin}}

{{PR|tipo}} [Firmar resolución] {{PR|es}} {{RE|tarea}}
-{{AT|fuente.definicion}} = [Expediente de beca];
-{{AT|localizacion}} = [Datos generales];
-{{AT|Al_finalizar.Codigo}} = {{STR|"$firmar([&Destino]->[Datos generales].[Firma de la resolución]); $guardar([&Destino]); "}};
{{PR|fin}}

{{PR|tipo}} [Registrar salida de documentación] {{PR|es}} {{RE|tarea}}
-{{AT|fuente.definicion}} = [Libro de salida];
-{{AT|destino.definicion}} = [Salida];
-{{AT|destino.valor}} = $crear([Contenido]);
{{PR|fin}}

==Crear nuevos perfiles de usuario==
Una vez tenemos implementado nuestro ''workflow'', necesitamos definir nuevos roles puesto que los que teníamos definidos anteriormente han quedado desfasados.Definiremos un tipo de rol por cada oficina de nuestra organización:

{{PR|tipo}} [Permisos comunes] {{PR|es}} {{RE|rol}}
{{PR|accede}} [Libro de entrada]: abrir;
{{PR|accede}} [Libro de salida]: abrir;
{{PR|accede}} [Fichero de terceros]: abrir;
{{PR|accede}} [Registro de documentación]: abrir;
{{PR|accede}} [Expedientes de beca]: abrir;
{{PR|accede}} [Fichero de trabajadores]: abrir;
{{PR|accede}} [Oficina de recursos comunes]: entrar;
{{PR|accede}} [Registro de entrada y salida]: entrar;
{{PR|fin}}

{{PR|tipo}} [Usuario Oficina del Registro] {{PR|es}} [Permisos comunes]
{{PR|accede}} [Entrada]: crear;
{{PR|accede}} [Expediente de beca]: crear;
{{PR|accede}} [Salida]: crear;
{{PR|accede}} [Tercero]: crear;
{{PR|accede}} [Trabajador]: crear;
{{PR|accede}} [Requerimiento de documentación]: crear;
realiza [Registrar entrada]
realiza [Elaborar requerimiento]
realiza [Firmar requerimiento]
realiza [Registrar salida de documentación]
{{T|firma}} [Requerimiento de documentación]: [Datos generales].[Firma del escrito];
{{PR|fin}}

{{PR|tipo}} [Usuario Oficina de Servicio de Ayudas y Subvenciones] {{PR|es}} [Permisos comunes]
{{PR|accede}} [Entrada]: modificar;
{{PR|accede}} [Expediente de beca]: abrir;
{{PR|accede}} [Tercero]: abrir;
{{PR|accede}} [Trabajador]: abrir;
{{PR|accede}} [Resolución positiva]: modificar;
{{PR|accede}} [Resolución negativa]: modificar;
{{PR|accede}} [Oficina de Ayudas y Becas]: entrar;
realiza [Comprobar documentación]
realiza [Elaborar resolución positiva]
realiza [Elaborar resolución negativa]
realiza [Firmar propuesta de resolución]
{{T|firma}} [Resolución positiva]: [Datos generales].[Firma de la propuesta];
{{T|firma}} [Resolución negativa]: [Datos generales].[Firma de la propuesta];
{{PR|fin}}

{{PR|tipo}} [Usuario Oficina de la Dirección] {{PR|es}} {{RE|rol}}
{{PR|accede}} [Resolución positiva]: modificar;
{{PR|accede}} [Resolución negativa]: modificar;
{{PR|accede}} [Oficina de la Dirección]: entrar;
realiza [Firmar resolución]
{{T|firma}} [Resolución positiva]: [Datos generales].[Firma de la resolución];
{{T|firma}} [Resolución negativa]: [Datos generales].[Firma de la resolución];
{{PR|fin}}

Una vez definidos, probaremos el proceso creado utilizando el egExplorer. Pero para ello, tendremos que crear los usuarios correspondientes para poder acceder al centro. Esto lo haremos mediante la herramienta egAdmin, cuyos pasos podemos seguir en el siguiente [[Cómo_instalar_un_centro_desde_cero#Creación_de_usuarios_en_un_centro|tutorial]].Cuando tengamos los usuarios creados, sería interesante crear un proceso '''Solicitud de beca''' e ir lanzando sus correspondientes tareas. En el momento que sea necesario cambiar de usuario para que una tarea pueda ser lanzada, cerraremos el egExplorer y accederemos nuevamente a él pero esta vez con un usuario que nos permita lanzar la siguiente tarea.En caso de necesitar documentación sobre los roles, podemos acceder a la [[Tarea F: Abriendo el registro al resto de las oficinas|tarea F]] realizada anteriormente.

==Siguiente tarea==
:*[[Tarea_J:_Importar_la_base_de_datos_de_terceros_de_otra_aplicación|Tarea J: Importar la base de datos de terceros de otra aplicación]]

==Véase también==
:*[[Tarea_A:_Libros_y_registro_de_entrada_y_salida|Tarea A: Libros y registro de entrada y salida]]
:*[[Tarea_B:_Mejorando_la_numeración_del_registro|Tarea B: Mejorando la numeración del registro]]
:*[[Tarea_C:_Evolucionando_la_arquitectura_del_registro|Tarea C: Evolucionando la introducción de datos]]
:*[[Tarea_D:_Validar_la_introducción_de_datos|Tarea D: Validar la introducción de datos]]
:*[[Tarea_E:_Utilizar_el_registro_como_un_almacén_de_documentación|Tarea E: Utilizar el registro como un almacén de documentación]]
:*[[Tarea_F:_Abriendo_el_registro_al_resto_de_las_oficinas|Tarea F: Abriendo el registro al resto de las oficinas]]
:*[[Tarea_G:_Evitando_la_replicación_de_código|Tarea G: Evitando la replicación de código]]
:*[[Tarea_H:_Emitir_certificados_de_documentación|Tarea H: Emitir certificados de documentación]]

Tarea I: Creando una oficina sin papeles

2009-08-04T10:07:40Z

Imhernandez: /* Definir las oficinas */

[[Construir_una_aplicación_paso_a_paso|Construir una aplicación paso a paso]]
[[Imagen:Tarea_I_Figura_1_Diagrama_procedimiento.jpg|thumb|250px|Procedimiento de concesión de becas]]
 
Hasta ahora, los usuarios del Registro utilizan el software sólo para introducir o consultar datos, sin realizar ningún trámite ni llevar a cabo un procedimiento administrativo.
Supongamos que la organización ofrece becas para la realización de estudios en el extranjero. Estas becas las gestiona el Servicio de Ayudas y Subvenciones. Los interesados deben presentar las solicitudes en el Registro de Entrada y Salida. Un auxiliar del Registro revisa la documentación y, en caso de faltar algo, elabora un requerimiento para el interesado. Este requerimiento debe firmarlo el jefe de servicio del Registro.
Una vez la documentación esté completa, se remite al Servicio de Ayudas y Subvenciones quien resuelve la beca por el procedimiento de concurrencia sin concurso; es decir, que todos aquellos interesados que cumplan con los requisitos recibirán la beca.
Al recibir la documentación, un técnico del Servicio de Ayudas y Subvenciones comprueba la documentación para ver si el interesado cumple con los requisitos. A continuación, procede a elaborar resolución positiva (o negativa). La resolución la deben firmar el jefe del Servicio de Ayudas y Subvenciones y el director de la organización.
Una vez firmada, la resolución se remite al Registro, donde un auxiliar se encarga de darle salida.
El procedimiento se puede resumir en el siguiente diagrama.

__TOC__

==¿Qué nos hace falta?==
Para implementar este ''workflow'', primero debemos identificar los ítems de información y, a continuación, definirlos en el sistema. Analizando, vemos que necesitamos cuatro objetos diferentes:
*'''Entrada''', para las tareas de Registrar entrada de documentación y Comprobar documentación. Este tipo ya lo tenemos definido.
*'''Requerimiento''', para las tareas de Elaborar requerimiento y Firmar requerimiento.
*'''Resolución positiva''' y '''Resolución negativa''', para las tareas de Elaborar resolución positiva/negativa, Firmar propuesta de resolución, Firmar resolución y Registrar salida de documentación.

Además, todos los documentos relacionados con una solicitud deben almacenarse en alguna parte. Para ello, definiremos también el tipo '''Expediente de beca'''.

Por último, debemos definir dos nuevas habitaciones, donde se enviarán sus tareas específicas: la '''Oficina de Ayudas y Subvenciones''' y la '''Oficina de dirección'''.

==Definir los escritos==

Definimos el requerimiento de documentación con dos componentes: una componente [[Escritos|escrito]], para la plantilla del documento, y una componente formulario, para los campos firma.

{{PR|tipo}} [Requerimiento de documentación] {{PR|es}} {{RE|contenedor}}
[Escrito] {{PR|es}} {{T|documento}}
-{{AT|plantilla_documento}} = {{STR|"Req 001.rtf"}};
{{PR|fin}}

[Datos generales] {{PR|es}} {{T|formulario}}
[Firma del escrito] {{PR|es}} {{T|firma}}
{{PR|fin}}
{{PR|fin}}

Hacemos lo mismo para las resoluciones. En este caso, como las resoluciones la firman dos personas, debemos incluir dos campos firma, uno para la propuesta y otro para la resolución.

{{PR|tipo}} [Resolución positiva] {{PR|es}} {{RE|contenedor}}
[Escrito] {{PR|es}} {{T|documento}}
-{{AT|plantilla_documento}} = {{STR|"Res 001.rtf"}};
{{PR|fin}}

[Datos generales] {{PR|es}} {{T|formulario}}
[Firma de la propuesta] {{PR|es}} {{T|firma}}
[Firma de la resolución] {{PR|es}} {{T|firma}}
{{PR|fin}}
{{PR|fin}}

{{PR|tipo}} [Resolución negativa] {{PR|es}} {{RE|contenedor}}
[Escrito] {{PR|es}} {{T|documento}}
-{{AT|plantilla_documento}} = {{STR|"Res 002.rtf"}};
{{PR|fin}}

[Datos generales] {{PR|es}} {{T|formulario}}
[Firma de la propuesta] {{PR|es}} {{T|firma}}
[Firma de la resolución] {{PR|es}} {{T|firma}}
{{PR|fin}}
{{PR|fin}}

==Definir el Expediente de beca==
Cada vez que se inicie un trámite de beca, abriremos un expediente en el que se recogerá toda la documentación relacionada con el trámite. Este expediente tendrá un número (asignado automáticamente), que identificará el trámite, y una fecha de alta, que indicará la fecha en la que se inició el trámite. Asimismo, tendrá un vínculo a la '''Entrada''' que dio lugar al trámite.
Crearemos el expediente con dos componentes: una componente para el formulario de datos y otra para la colección en la que se almacenarán todos los documentos.
{{PR|tipo}} [Expediente de beca] {{PR|es}} {{RE|contenedor}}
[Datos generales] {{PR|es}} {{T|formulario}}
[Nº de expediente] {{PR|es}} {{T|timbre}}
-{{AT|certificado.valor}} = [&Valor_secuencia];
-{{AT|certificado.secuencia.nombre}} = {{STR|"STR$EXPEDIENTE"}};
-{{AT|certificado.secuencia.longitud}} = 5;
[Fecha de alta] {{PR|es}} {{T|fecha}}
[Solicitud] {{PR|es}} {{T|vinculo}}
-{{AT|vinculo.definicion}} = [Entrada];
-{{AT|vinculo.etiqueta}} = [Datos generales].[Número] + {{STR|" ("}}
+ [Datos generales].[Remitente]->[Datos generales].[Nombre/Razón social]
+ {{STR|" "}} + [Datos generales].[Remitente]->[Datos generales].[Apellidos]
+ {{STR|")"}};
-{{AT|vinculo.valores}} = $matriz([Libro de entrada].[Contenido]);
{{PR|fin}}

[Documentos] {{PR|es}} {{T|coleccion}}
-{{AT|nombre_tabla}} = {{STR|"TC$EXPEDIENTE_BECA"}};

{{PR|contiene}} [Requerimiento de documentación]
{{PR|contiene}} [Resolución positiva]
{{PR|contiene}} [Resolución negativa]

{{PR|columna}} [Nombre]
-{{AT|columna_bd.nombre}} = {{STR|"DOCUMENTO"}};
-{{AT|origen}} = [&Nombre];
{{PR|fin}}
{{PR|fin}}

Por último, necesitamos almacenar los expedientes en alguna parte. Para ello, crearemos un objeto del sistema en el que almacenarlos.

[Expedientes de beca] {{PR|es}} {{RE|contenedor}}
[Contenido] {{PR|es}} {{T|coleccion}}
-{{AT|nombre_tabla}} = {{STR|"TC$EXPEDIENTES"}};

{{PR|contiene}} [Expediente de beca]

{{PR|columna}} [Nº de expediente]
-{{AT|columna_bd.nombre}} = {{STR|"NUMERO"}};
-{{AT|origen}} = [Datos generales].[Nº de expediente];
{{PR|columna}} [Fecha de alta]
-{{AT|columna_bd.nombre}} = {{STR|"FECHA_ALTA"}};
-{{AT|origen}} = [Datos generales].[Fecha de alta];
{{PR|fin}}
{{PR|fin}}

==Definir las oficinas==
Tan sólo nos queda definir las oficinas y ubicar los recursos necesarios en cada una. En nuestro caso, se reduce sólo al estante de expedientes, ya que es el único recurso común a las tres oficinas.

[Oficina de Ayudas y Subvenciones] {{PR|es}} {{RE|habitacion}}
-{{AT|publico}} = falso;

{{PR|ubicado}} [Expedientes de beca]
-{{AT|lugar}} = {{STR|"Estantes"}};
{{PR|fin}}

[Oficina de la dirección] {{PR|es}} {{RE|habitacion}}
-{{AT|publico}} = falso;

{{PR|ubicado}} [Expedientes de beca]
-{{AT|lugar}} = {{STR|"Estantes"}};
{{PR|fin}}

==¿Cómo funciona el motor de ''workflow''?==
Hasta ahora nos hemos centrado en definir los ítems de información que nos iban a hacer falta para llevar a cabo el procedimiento de concesión de beca. En los próximos apartados veremos cómo implementar el flujo de trabajo, pero primero explicaremos cómo funciona el motor de ''workflow'' de la plataforma.
En egeasy, los procedimientos administrativos se definen en dos pasos. En primer lugar, debe definirse el flujo de tareas. Esta definición se hace en un fichero con extensión nmt. Los ficheros nmt son ficheros de texto plano que se crean en la carpeta Data del proyecto. Una vez definido el flujo de tareas, procederemos a definir los atributos de cada tarea: ítem de trabajo, código que se ejecuta al terminar la tareas, ... Estas definiciones se realizan en ficheros ndf, como hemos hecho con el resto de los recursos.
Comenzaremos con el flujo de tareas. Lo primero que debemos hacer es crear, en la carpeta Data, el fichero '''concesion_beca.nmt'''. A continuación, abrimos el fichero con el editplus.
Los ficheros nmt se componen de '''métodos'''. Por hacer un símil, un método sería equivalente a un procedimiento de PASCAL. Cada método lanza tareas, invoca a otros métodos y ejecuta sentencias en ODL. Adicionalmente, puede tener parámetros de E/S y variables locales.
Aquí tenemos un ejemplo.
{{PR|metodo}} RegistrarEntrada();
{{PR|var}}
TareaRegistro: {{RE|tarea}};
{{PR|inicio}}
TareaRegistro = {{T|$lanzar}}({{STR|"Registrar entrada"}});
TareaRegistro.[&Destino]->[Datos generales].[Asunto] = {{STR|"Esto es una prueba"}};
$guardar(TareaRegistro.[&Destino]);
{{PR|fin}}
En este segmento de código hemos definido el método RegistrarEntrada. A continuación, hemos definido la variable TareaRegistro de tipo {{RE|tarea}}. Después hemos definido la secuencia de tareas.
Cuando comienza la ejecución de un método, el motor de ''workflow'' posiciona el cursor en la primera línea del método que está justo después de '''inicio'''. Comienza a ejecutar línea por línea hasta que alguna de las sentencias lanza una tarea. Entonces, el sistema crea una nueva tarea, le asigna un ítem de trabajo y establece el estado de la tarea a '''pendiente'''. La ejecución del método queda detenida hasta que se finalice la tarea. En nuestro ejemplo, al iniciarse la ejecución del método se lanzaría la tarea '''Registrar entrada'''.
Cualquier usuario con los permisos suficientes puede ir a la bandeja de '''Tareas disponibles''' y '''comenzar la tarea'''. Cuando lo hace, la plataforma abre el ítem de trabajo asignado y cambia el estado de la tarea a '''realizándose'''.
Cuando el usuario finaliza la tarea, el sistema cambia el estado a '''terminada''' y retoma la ejecución del método que invocó a la tarea. En nuestro ejemplo, asignaría a la variable TareaRegistro la tarea que se acaba de terminar. A continuación ejecutaría las siguientes líneas de código, que modifican el ítem de trabajo de la tarea para después almacenarlo.
Un método termina de ejecutarse cuando el cursor alcanza la palabra fin.

===¿Cómo comienza a ejecutarse un método?===
Todo proceso tiene un punto de entrada que lanza a ejecutar la primera línea del primer método. Este punto de entrada es un tipo de tarea que se define como raíz en los ficheros de definiciones ndf.Para cada proceso que exista en nuestro sistema de información, tendremos que definir una tarea, llamémosla ''inicializadora'' del proceso.Veamos a continuación la definición de esta tarea, que se corresponde con el proceso '''Solicitud de beca''':

{{PR|tipo}} [Solicitud de beca] {{PR|es}} {{RE|tarea}}
-{{AT|descripcion}} = {{STR|"Proceso que se encarga de realizar la resolución de una solicitud de beca"}};
-{{AT|fuente.definicion}} = [Registro de entrada y salida];
-{{AT|destino.definicion}} = [Expediente de beca];
-{{AT|destino.valor}} = $crear([Expedientes de beca].[Contenido]);
-{{AT|Al_Comenzar.Nombre}} = {{STR|"Metodos\concesion_beca.RegistrarEntrada"}};
-{{AT|es_raiz}} = verdadero;
{{PR|fin}}

La forma de indicar que la tarea '''Solicitud de beca''' inicia un proceso de nuestro sistema de información es mediante el atributo lógico '''es_raiz'''. Dicho atributo tiene asignado por defecto el valor falso, de forma que poniéndolo a verdadero, conseguiremos que dicha tarea inicie un proceso que será lanzado por un usuario.Ahora bien, ¿sobre qué [[Contenedores|contenedor]] queremos que se lance la tarea?Siempre que lanzamos una tarea, es necesario indicar sobre qué contenedor podremos lanzarla. Para ello, ODL proporciona un atributo llamado '''fuente.definicion'''. En el caso de una tarea raíz, se indicarán aquellas habitaciones a las que habrá que acceder para poder iniciar la tarea raíz. Por eso hemos indicado una habitacion en vez de un contenedor en la definición de Solicitud de beca.Esto significa que el usuario podrá lanzar la tarea Solicitud de beca una vez haya accedido a la habitación Registro de entrada y salida. En posteriores definiciones de tareas, veremos que especificaremos un contenedor en vez de una habitación en el atributo fuente.definicion.El método a ejecutar una vez se lance la tarea, lo indicaremos en el atributo '''Al_Comenzar.Nombre''', que como vemos, tiene asignado el método creado anteriormente RegistrarEntrada. La manera de indicar el método es añadiendo la ruta del fichero donde está incluído a partir de la carpeta '''Data''' del modelo, seguido de un punto y el nombre del método.Por último, indicaremos en el atributo '''destino.definicion''' lo que se conoce como ''maintarget'' de un proceso, es decir, aquel contenedor que se asociará al proceso durante su ejecución.El ''maintarget'' de Solicitud de beca será un contenedor de tipo '''Expediente de beca'''. ¿Por qué? Porque las tareas que se lancen dentro de este proceso y la información que se genere se almacenará en un Expediente de beca.Además, no sólo queremos indicar el ''maintarget'' del proceso Solicitud de beca, sino que también queremos crear el expediente una vez se inicie el proceso. Para ello, utilizaremos la función '''$crear''' definida en la librería de funciones de ODL, que nos permite crear un objeto, indicándole la colección donde se va a almacenar. El tipo de objeto será el definido en destino.definicion. El objeto devuelto por $crear se asignará al atributo '''destino.valor'''.

===Interpretación del diagrama de flujo===
Antes de meternos de lleno a desarrollar el ''workflow'', vamos a estudiar el diagrama de flujo de información de concesión de becas facilitado al comienzo de este artículo.Es recomendable que abramos el diagrama ampliado en una pestaña nueva del navegador y lo mantengamos hasta el final de este artículo, de manera que podamos ir fijándonos en él a medida que vamos avanzando en el desarrollo del ''workflow''.Fijándonos en el diagrama, vemos que el flujo de trabajo está dividido en tres secciones, donde cada una de ellas equivale a una oficina de la organización. Dentro de cada oficina existen una serie de estados, que equivalen a las diferentes tareas que se pueden lanzar. Por tanto, habrá que implementar una tarea por cada estado que aparece en el diagrama.Si las tareas equivalen a los estados, el flujo de trabajo equivaldría a las líneas de transición que nos permiten cambiar de estado. En nuestro método RegistrarEntrada tendremos que implementar este flujo de trabajo.Podemos ver que para lanzar ciertas tareas, habrá que evaluar una condición. Por ejemplo, para lanzar la tarea ComprobarDocumentacion será necesario evaluar si la documentación necesaria está completa. De no ser así, se lanzaría la tarea ElaborarRequerimiento.Por tanto, en la implementación de nuestro método tendremos que plasmar el camino de datos que observamos en el diagrama.Además, el diagrama nos indica a qué oficina debe acceder un usuario para realizar cada una de las tareas, teniendolo en cuenta a la hora de definir los roles.

===Evolucionando el ''workflow''===
Antes de meternos de lleno en la elaboración del ''workflow'', hagamos un resumen de aquellos ficheros y nuevas definiciones que hemos creado.Por un lado, para poder desarrollar una concesión de beca, hemos definido un expediente de beca, un registro de expedientes de beca, un requerimiento de documentación y una resolución positiva y negativa de la concesión de una beca con la elaboración de sus respectivos documentos. Todas ellas son definiciones de tipo {{RE|contenedor}}, y serán los ítems con los que trabajaremos a lo largo de todo el flujo de información. Además, hemos definido una Oficina de Ayudas y Subvenciones y una Oficina de Dirección. Todas estas definiciones las hemos realizado en el fichero '''Main.ndf''' de la carpeta #Source.En esta misma carpeta, se encuentra el fichero '''tareas.ndf''' donde ya hemos definido la tarea raíz Solicitud de beca y donde vamos a definir el resto de tareas.Por último, en la carpeta Data\Metodos hemos creado el fichero '''concecion_beca.nmt''' donde hemos incluído un ejemplo del método RegistroEntrada.Una vez hecho este resumen, ahora sí que vamos a desarrollar nuestro proceso '''Solicitud de beca'''. Mostraremos paso a paso el código a introducir siguiendo el diagrama de flujo de información. Iremos alternando la implementación del método y de las tareas según lo vayamos necesitando.
 
Cuando se produce una '''Entrada''' para solicitar una beca, el sistema de información generará un '''Expediente de beca''' único y se registrará la entrada que además estará asociada al expediente mediante el campo vínculo '''[Solicitud]'''. A partir de este momento, toda la información que genere el proceso tendrá asociado un Expediente de beca, por ello el ''maintarget'' del proceso Solicitud de beca es el expediente creado.Por tanto, una vez lanzada la tarea raíz y se empeciece a ejecutar el método RegistrarEntrada, habrá que crear un expediente de beca y registrar la entrada recibida lanzando las tareas correspondientes desde el método y definiéndolas:

{{PR|metodo}} RegistrarEntrada();
{{PR|var}}
{{PR|inicio}}
{{T|$lanzar}}({{STR|"Registrar expediente de beca"}});
{{T|$lanzar}}({{STR|"Registrar entrada"}});
{{PR|fin}}

La función '''$lanzar''', lanza una tarea cuyo nombre debemos pasar por parámetro, como vemos en el código. En este caso, no pasamos por parámetro ningún ítem (''target'') a la tarea, ya que será creado por la propia tarea, aunque veremos que en posteriores definiciones sí tendremos que incluir un ''target'' como parámetro de entrada. Además, también es posible indicar la habitación en la cuál un usuario podrá realizar la tarea. En caso de no especificarla, se tomará como habitación la definida en la tarea raíz, que en nuestro caso es '''Registro de entrada y salida'''.Definamos entonces dichas tareas en nuestro fichero ''tareas.ndf'':

{{PR|tipo}} [Registrar expediente de beca] {{PR|es}} {{RE|tarea}}
-{{AT|fuente.definicion}} = [Expediente de beca];
-{{AT|Al_finalizar.Codigo}} = {{STR|"$sellar([&Destino]->[Datos generales].[Nº de expediente]); $guardar([&Destino]); "}};
{{PR|fin}}

{{PR|tipo}} [Registrar entrada] {{PR|es}} {{RE|tarea}}
-{{AT|fuente.definicion}} = [Expediente de beca];
-{{AT|destino.definicion}} = [Entrada];
-{{AT|destino.valor}} = $crear([Libro de entrada].[Contenido]);
-{{AT|Al_finalizar.Codigo}} = {{STR|"$sellar([&Destino]->[Datos generales].[Número]); $guardar([&Destino]); "}};
{{PR|fin}}

En la tarea '''Registrar expediente de beca''', el atributo {{AT|fuente.definicion}} que hay definido ya lo conocemos. En él indicamos el objeto de referencia de la tarea. En el atributo {{AT|destino.definicion}}, que no aparece, deberíamos indicar el contenedor (''target'', ítem) con el que va a trabajar la tarea, pero este atributo, si no se especifica, asumirá como destino el contenedor definido en fuente.definicion. Equivaldría a poner <code>destino.definicion = [Expediente de beca]</code>.Por tanto, al arrancar esta tarea, se creará un expediente nuevo. El atributo {{AT|Al_finalizar.Codigo}} nos permite invocar un método o directamente asignarle instrucciones en forma de ristra, que se ejecutarán en tiempo de ejecución una vez se finalice la tarea. En nuestro caso, se sellará el campo timbre que existe en el expediente y además se guardará el objeto. Para que entendamos bien las instrucciones empleadas en el atributo Al_finalizar.Codigo, es necesario conocer la propiedad '''[&Destino]''' de una tarea.Esta propiedad permite acceder al ''target'' actual de una tarea, que en el caso de Registrar expediente de beca, es un '''Expediente de beca'''. Una vez accedido al ''target'', podremos acceder a otros componentes que estén definidos en él, como por ejemplo, a un campo timbre incluído en la definición de un formulario, que es exactamente lo que se realiza en nuestro caso. Con la función '''$sellar''', sellamos el campo timbre, y con la función '''$guardar''', guardamos el objeto.Una vez registrado un nuevo expediente, procederemos a registrar la entrada de petición de beca mediante la tarea '''Registrar entrada'''. La diferencia que podemos observar respecto a la tarea anterior es la inclusión de los atributos {{AT|destino.definicion}} y {{AT|destino.valor}}.¿Y por qué ahora sí están incluídos? Esto es debido a que esta tarea no va a registrar un Expediente de beca, sino que registrará una Entrada, aunque el objeto referencia de la tarea sí seguirá siendo el Expediente de beca creado anteriormente.Además, al finalizar la tarea, ejecutaremos el mismo código que la tarea anterior, con la diferencia de que en esta ocasión, la propiedad [&Destino] accederá a un objeto de tipo Entrada, que es el ''target'' de esta tarea. ¿Y el atributo {{AT|destino.valor}}?Como ya explicamos en la definición de la tarea raíz '''Solicitud de beca''', utilizaremos la función '''$crear''' en este atributo, para indicar la colección donde se va a guardar el objeto del tipo definido en el atributo {{AT|destino.definicion}}, es decir, un objeto de tipo Entrada.
 
Una vez realizada esta primera fase, volvemos a fijarnos en el diagrama, y vemos que una vez la Entrada es recibida, registrada, y creado su Expediente de beca, el siguiente paso, sería comprobar la documentación. Para ello, es necesario que la documentación entregada por la persona que realiza la petición de la beca esté completa. En caso de no ser así, se generará un documento de requerimiento, que deberá ser firmado, dando lugar a posibles nuevas entradas en el proceso, pero con un Expediente de beca ya creado. Esto se producirá tantas veces como requerimientos de documentación se puedan dar. Una vez no falte ningún tipo de documentación, se lanzará la tarea '''Comprobar documentación'''.Pero, ¿y cómo podemos saber si en la solicitud de una beca falta documentación?Para ello, hemos modificado la definición del contenedor '''Entrada''', añadiendo simplemente un campo tabla para registrar la documentación y un campo de tipo texto llamado '''[Documentación completa]'''.Veamos primero los cambios introducidos, tanto en el contenedor '''Entrada''' como en el método, para comentarlos posteriormente:

[Sí o No] {{PR|es}} {{RE|enumerado}}
{{AT|valores}}
{{STR|"Sí"}},
{{STR|"No"}}
{{PR|fin}}

{{PR|tipo}} [Entrada] {{PR|es}} {{RE|contenedor}}
[Datos generales] {{PR|es}} {{T|formulario}}
...
...
...
[Documentación presentada] {{PR|es}} {{T|tabla}}
[Documento] {{PR|es}} {{T|texto}}
{{PR|fin}}
[Documentación completa] {{PR|es}} {{T|texto}}
-{{AT|apariencia.desplegable}} = verdadero;
-{{AT|edicion.seleccion}} = verdadero;
-{{AT|edicion.valores}} = $matriz([Sí o No]);
{{PR|fin}}
{{PR|fin}}

{{PR|metodo}} RegistrarEntrada();
{{PR|var}}
TareaRegistroBeca: tarea;
TareaRegistroEntrada: tarea;
ElaborarRequerimiento: tarea;
ElaborarResolucion: tarea;
documentacion_incompleta: logico;
{{PR|inicio}}
documentacion_incompleta = verdadero;
TareaRegistroBeca = {{T|$lanzar}}({{STR|"Registrar expediente de beca}}");
{{PR|mientras}} documentacion_incompleta
TareaRegistroEntrada = {{T|$lanzar}}({{STR|"Registrar entrada"}});
TareaRegistroBeca.[&Destino]->[Datos generales].[Solicitud] = TareaRegistroEntrada.[&Destino];
$guardar(TareaRegistroBeca.[&Destino]);
{{PR|si}} (TareaRegistroEntrada.[&Destino]->[Datos generales].[Documentación completa] = {{STR|"Sí"}})
documentacion_incompleta = falso;
{{PR|sino}}
ElaborarRequerimiento = {{T|$lanzar}}({{STR|"Elaborar requerimiento"}});
{{T|$lanzar}}({{STR|"Firmar requerimiento"}}, ElaborarRequerimiento.[&Destino]);
{{PR|fin}}
{{PR|fin}}
{{PR|fin}}

Vemos que en la definición de Entrada hemos incluído los campos que comentamos para comprobar la documentación.También podemos observar que hay una serie de variables declaradas en la implementación de nuestro método, que nos permitirán almacenar en ellas un recurso del mismo tipo que el definido para la variable. La variable lógica '''documentacion_incompleta''', que inicializamos a "verdadero", la utilizaremos para controlar la salida del bucle que se ocupa de los requerimientos de documentación, y como consecuencia, de nuevas entradas. Dicha salida se producirá cuando el campo [Documentación completa] de la Entrada actual tenga valor "Sí", asignándole "falso" a documentacion_incompleta.¿Y cómo consultamos dicho campo?Al lanzar la tarea '''Registrar entrada''', ésta la almacenamos en la variable de tipo tarea '''TareaRegistroEntrada'''. Esto nos va a permitir acceder al ''target'' de la tarea mediante la propiedad [&Destino] en cualquier momento del código, ya que la tarea quedará almacenada en la variable. En este caso, el objeto es de tipo Entrada, por lo que podremos acceder al campo [Documentación completa] y realizar la consulta.Una vez la documentación esté completa, el usuario modificará el campo [Documentación completa] asignándole el valor "Sí", de manera que saldremos del bucle. En caso contrario, lanzaremos la tarea encargada de elaborar un requerimiento, que a su vez tendrá que ser firmada, lanzando la tarea correspondiente para ficha firma.Respecto a las tareas '''Elaborar requerimiento''' y '''Firmar requerimiento''' es necesario tener en cuenta lo siguiente.Al igual que en el lanzamiento de las demás tareas, la tarea Elaborar requerimiento también es asignada a una variable, en este caso, llamada '''ElaborarRequerimiento'''. A continuación, se lanza la tarea Firmar requerimiento, pero esta vez con un nuevo parámetro. Este parámetro corresponde al ''target'' de la tarea anterior, y lo indicamos como parámetro utilizando la variable ElaborarRequerimiento para acceder a la tarea, junto con la propiedad [&Destino] para acceder a su ''target''. Esto lo realizamos porque la tarea Firmar requerimiento no va a crear ningún ''target'', sino que firmará el campo firma que se encuentra en el objeto '''Requerimiento de documentación''' creado en la tarea anterior. Por tanto, este objeto o ''target'' tendrá que ser pasado como parámetro a la tarea Firmar requerimiento.
Hay dos instrucciones que no hemos comentado aún. Son exactamente las dos instrucciones anteriores a la consulta del campo [Documentación completa].Como ya sabemos, nuestra definición de tipo contenedor Expediente de beca tiene un campo vínculo, que referencia a la última Entrada que se haya almacenado en el expediente. Para que esto suceda, es necesario que después de registrar una nueva entrada se modifique este campo vínculo, para que referencie al último objeto de tipo Entrada. Esto lo conseguimos utilizando dos variables de tipo tarea, una para la tarea Registrar expediente de beca y otra para Registrar entrada. En cada variable almacenamos cada una de las dos tareas, de manera que nos permitan acceder al ''target'' de cada una de ellas. Al campo vínculo '''TareaRegistroBeca.[&Destino]->[Datos generales].[Solicitud]''' le asignaremos el ''target'' de la tarea Registrar entrada, '''TareaRegistroEntrada.[&Destino]'''. Una vez asignada la Entrada al campo vínculo, se guardará el objeto para aplicar los cambios realizados en el objeto.Es necesario realizar estas dos acciones dentro del bucle y antes de realizar la comprobación del campo [Documentación completa] del objeto Entrada, ya que, en caso de no hacerlo, no se estará verificando el campo [Documentación completa] de la nueva Entrada, sino de la anterior, o de ninguna, en caso de que estemos tratando una primera entrada.Una vez analizado el nuevo código introducido en el método, veamos la definición de las nuevas tareas que aparecen; Elaborar requerimiento y Firmar requerimiento:

{{PR|tipo}} [Elaborar requerimiento] {{PR|es}} {{RE|tarea}}
-{{AT|fuente.definicion}} = [Expediente de beca];
-{{AT|destino.definicion}} = [Requerimiento de documentación];
-{{AT|destino.valor}} = $crear([Documentos]);
{{PR|fin}}

{{PR|tipo}} [Firmar requerimiento] {{PR|es}} {{RE|tarea}}
-{{AT|fuente.definicion}} = [Expediente de beca];
-{{AT|destino.definicion}} = [Requerimiento de documentación];
-{{AT|localizacion}} = [Datos generales];
-{{AT|Al_finalizar.Codigo}} = {{STR|"$firmar([&Destino]->[Datos generales].[Firma del escrito]); $guardar([&Destino]); "}};
{{PR|fin}}

Cabe comentar un atributo que hasta ahora no hemos tenido que utilizar. Se trata del atributo {{AT|localizacion}}. En él, indicaremos una componente que queramos activar al iniciar la tarea, en principio, para su edición. En este caso, activamos la componente [Datos generales] del contenedor Requerimiento de documentación, que es donde está incluído el campo firma que vamos a editar en esta tarea. En caso de no hacerlo, no podríamos realizar la firma al ejecutar el código <code>{{STR|"$firmar([&Destino]->[Datos generales].[Firma del escrito])</code>.

Una vez hemos analizado ya varias definiciones de tareas, nos damos cuenta que el aspecto más importante a la hora de definir una tarea es tener muy claro el ''target'' con el que va a trabajar la tarea. Es decir, saber si el ''target'' será creado por la propia tarea o si por el contrario, trabajará con un ''target'' ya creado.En caso de crear uno nuevo utilizaremos los atributos destino.definicion y destino.valor para especificar el tipo del objeto y el lugar donde se almacenará. En caso de utilizar uno creado por tareas anteriores, tendremos que incluir el ''target'' de la tarea anterior como parámetro de la nueva tarea. Esto lo conseguimos, como ya hemos visto, utilizando una variable en la cual almacenamos la tarea que nos interese, y con la propiedad [&Destino] referenciamos a su ''target''.

===Finalizando el ''workflow''===
Siguiendo con el flujo de trabajo, pasamos ahora a la siguiente oficina de nuestra organización, '''Servicio de Ayudas y Subvenciones'''.Una vez hemos verificado que la documentación de una solicitud está completa, pasamos a lanzar la tarea '''Comprobar documentación'''. Esta tarea abrirá la última Entrada que referencia el campo vínculo '''[Solicitud]''' de un expediente concreto y analizará la documentación entregada para elaborar una resolución positiva, en caso de cumplir los requisitos, o negativa, en caso de no cumplirlos. El ''target'' de esta tarea, tendrá que ser pasado como parámetro, que al ser la última Entrada registrada, podremos acceder a él utilizando la variable '''TareaRegistroEntrada'''. Pero, hay que tener en cuenta otro aspecto a la hora de lanzar esta tarea.Hasta ahora, no nos hemos preocupado de la oficina en la cual podíamos realizar las tareas. Esto ha sido así debido a que las tareas hasta ahora lanzadas compartían la oficina de la tarea raíz (Registro de entrada y salida), y por tanto, no se especificaba como parámetro al lanzar una tarea. Pero ahora sí es necesario especificarlo, ya que hemos cambiado de oficina. La sintaxis para hacerlo es la siguiente:

{{T|$lanzar}}({{STR|"nombre"}},target,[oficina])

Veamos el código a añadir en nuestro método y la implementación de la tarea '''Comprobar documentación''':

{{PR|metodo}} RegistrarEntrada();
{{PR|var}}
TareaRegistroBeca: tarea;
TareaRegistroEntrada: tarea;
ElaborarRequerimiento: tarea;
ElaborarResolucion: tarea;
DocumentacionComprobada: tarea;
documentacion_incompleta: logico;
{{PR|inicio}}
documentacion_incompleta = verdadero;
TareaRegistroBeca = {{T|$lanzar}}({{STR|"Registrar expediente de beca}}");
{{PR|mientras}} documentacion_incompleta
...
... {{COM|//Bucle}}
...
{{PR|fin}}
DocumentacionComprobada = {{T|$lanzar}}({{STR|"Comprobar documentación"}},TareaRegistroEntrada.[&Destino],[Oficina de Ayudas y Becas]);
{{PR|fin}}

{{PR|tipo}} [Comprobar documentación] {{PR|es}} {{RE|tarea}}
-{{AT|fuente.definicion}} = [Expediente de beca];
-{{AT|destino.definicion}} = [Entrada];
{{PR|fin}}

En este caso, el usuario de la Oficina de Ayudas y Subvenciones analizará la documentación presentada y dejará constancia de dicho análisis especificando si es un caso favorable o desfavorable para la concesión de una beca.Pero, ¿dónde deja constancia?Para ello, hemos definido otro campo de tipo texto en la definición de contenedor Entrada llamado '''[Cumple los requisitos]'''. Este será el campo donde se concretará si un solicitante cumple los requisitos. Veamos el código a incluir en la definición de Entrada:

{{PR|tipo}} [Entrada] {{PR|es}} {{RE|contenedor}}
[Datos generales] {{PR|es}} {{T|formulario}}
...
...
...
[Cumple los requisitos] {{PR|es}} {{T|texto}}
-{{AT|apariencia.desplegable}} = verdadero;
-{{AT|edicion.seleccion}} = verdadero;
-{{AT|edicion.valores}} = $matriz([Sí o No]);
{{PR|fin}}
{{PR|fin}}

Siguiendo con el flujo de trabajo del diagrama, las siguientes tareas a lanzar tratarían la elaboración de una resolución de beca, positiva o negativa, en función del valor que contenga el campo [Cumple los requisitos]. Por tanto, habrá que consultar dicho campo para saber cuál de las tareas lanzar:

{{PR|metodo}} RegistrarEntrada();
{{PR|var}}
TareaRegistroBeca: tarea;
TareaRegistroEntrada: tarea;
ElaborarRequerimiento: tarea;
ElaborarResolucion: tarea;
DocumentacionComprobada: tarea;
documentacion_incompleta: logico;
{{PR|inicio}}
documentacion_incompleta = verdadero;
TareaRegistroBeca = {{T|$lanzar}}({{STR|"Registrar expediente de beca}}");
{{PR|mientras}} documentacion_incompleta
...
... {{COM|//Bucle}}
...
{{PR|fin}} 
DocumentacionComprobada = {{T|$lanzar}}({{STR|"Comprobar documentación"}},TareaRegistroEntrada.[&Destino],[Oficina de Ayudas y Becas]); 
{{PR|si}} (DocumentacionComprobada.[&Destino]->[Datos generales].[Cumple los requisitos] = {{STR|"Sí"}}) 
ElaborarResolucion = {{T|$lanzar}}({{STR|"Elaborar resolución positiva"}},[Oficina de Ayudas y Subvenciones]); 
{{PR|sino}} 
ElaborarResolucion = {{T|$lanzar}}({{STR|"Elaborar resolución negativa"}},[Oficina de Ayudas y Subvenciones]); 
{{PR|fin}} 
{{PR|fin}}

Consultamos el campo [Cumple los requisitos] y en función de su valor se lanzará o bien la tarea '''Elaborar resolución positiva''' o '''Elaborar resolución negativa'''.Ambas tareas crearán un ''target'' nuevo, que será o bien un objeto de tipo Resolución positiva o Resolución negativa. Dicho objeto será posteriormente utilizado como ''target'' por las tareas '''Firmar propuesta de resolución''' y '''Firmar resolución''', de forma que tendrán que ser pasados por parámetro en dichas tareas. Una vez realizadas las dos firmas del documento generado, se creará un objeto de tipo Salida que se registrará en el Registro de Entrada y Salida:

{{PR|tipo}} [Elaborar resolución positiva] {{PR|es}} {{RE|tarea}}
-{{AT|fuente.definicion}} = [Expediente de beca];
-{{AT|destino.definicion}} = [Resolución positiva];
-{{AT|destino.valor}} = $crear([Documentos]);
{{PR|fin}}

{{PR|tipo}} [Elaborar resolución negativa] {{PR|es}} {{RE|tarea}}
-{{AT|fuente.definicion}} = [Expediente de beca];
-{{AT|destino.definicion}} = [Resolución negativa];
-{{AT|destino.valor}} = $crear([Documentos]);
{{PR|fin}}

{{PR|metodo}} RegistrarEntrada();
{{PR|var}}
TareaRegistroBeca: tarea;
TareaRegistroEntrada: tarea;
ElaborarRequerimiento: tarea;
ElaborarResolucion: tarea;
DocumentacionComprobada: tarea;
documentacion_incompleta: logico;
{{PR|inicio}}
documentacion_incompleta = verdadero;
TareaRegistroBeca = {{T|$lanzar}}({{STR|"Registrar expediente de beca}}");
{{PR|mientras}} documentacion_incompleta
...
... {{COM|//Bucle}}
...
{{PR|fin}} 
DocumentacionComprobada = {{T|$lanzar}}({{STR|"Comprobar documentación"}},TareaRegistroEntrada.[&Destino],[Oficina de Ayudas y Becas]); 
{{PR|si}} (DocumentacionComprobada.[&Destino]->[Datos generales].[Cumple los requisitos] = {{STR|"Sí"}}) 
ElaborarResolucion = {{T|$lanzar}}({{STR|"Elaborar resolución positiva"}},[Oficina de Ayudas y Subvenciones]); 
{{PR|sino}} 
ElaborarResolucion = {{T|$lanzar}}({{STR|"Elaborar resolución negativa"}},[Oficina de Ayudas y Subvenciones]); 
{{PR|fin}} 
{{T|$lanzar}}({{STR|"Firmar propuesta de resolución"}},ElaborarResolucion.[&Destino],[Oficina de Ayudas y Subvenciones]); 
{{T|$lanzar}}({{STR|"Firmar resolución"}},ElaborarResolucion.[&Destino],[Oficina de la dirección]); 
{{T|$lanzar}}({{STR|"Registrar salida de documentación"}}); 
{{PR|fin}}

{{PR|tipo}} [Firmar propuesta de resolución] {{PR|es}} {{RE|tarea}}
-{{AT|fuente.definicion}} = [Expediente de beca];
-{{AT|localizacion}} = [Datos generales];
-{{AT|Al_finalizar.Codigo}} = {{STR|"$firmar([&Destino]->[Datos generales].[Firma de la propuesta]); $guardar([&Destino]); "}};
{{PR|fin}}

{{PR|tipo}} [Firmar resolución] {{PR|es}} {{RE|tarea}}
-{{AT|fuente.definicion}} = [Expediente de beca];
-{{AT|localizacion}} = [Datos generales];
-{{AT|Al_finalizar.Codigo}} = {{STR|"$firmar([&Destino]->[Datos generales].[Firma de la resolución]); $guardar([&Destino]); "}};
{{PR|fin}}

{{PR|tipo}} [Registrar salida de documentación] {{PR|es}} {{RE|tarea}}
-{{AT|fuente.definicion}} = [Libro de salida];
-{{AT|destino.definicion}} = [Salida];
-{{AT|destino.valor}} = $crear([Contenido]);
{{PR|fin}}

==Crear nuevos perfiles de usuario==
Una vez tenemos implementado nuestro ''workflow'', necesitamos definir nuevos roles puesto que los que teníamos definidos anteriormente han quedado desfasados.Definiremos un tipo de rol por cada oficina de nuestra organización:

{{PR|tipo}} [Permisos comunes] {{PR|es}} {{RE|rol}}
{{PR|accede}} [Libro de entrada]: abrir;
{{PR|accede}} [Libro de salida]: abrir;
{{PR|accede}} [Fichero de terceros]: abrir;
{{PR|accede}} [Registro de documentación]: abrir;
{{PR|accede}} [Expedientes de beca]: abrir;
{{PR|accede}} [Fichero de trabajadores]: abrir;
{{PR|accede}} [Oficina de recursos comunes]: entrar;
{{PR|accede}} [Registro de entrada y salida]: entrar;
{{PR|fin}}

{{PR|tipo}} [Usuario Oficina del Registro] {{PR|es}} [Permisos comunes]
{{PR|accede}} [Entrada]: crear;
{{PR|accede}} [Expediente de beca]: crear;
{{PR|accede}} [Salida]: crear;
{{PR|accede}} [Tercero]: crear;
{{PR|accede}} [Trabajador]: crear;
{{PR|accede}} [Requerimiento de documentación]: crear;
realiza [Registrar entrada]
realiza [Elaborar requerimiento]
realiza [Firmar requerimiento]
realiza [Registrar salida de documentación]
{{T|firma}} [Requerimiento de documentación]: [Datos generales].[Firma del escrito];
{{PR|fin}}

{{PR|tipo}} [Usuario Oficina de Servicio de Ayudas y Subvenciones] {{PR|es}} [Permisos comunes]
{{PR|accede}} [Entrada]: modificar;
{{PR|accede}} [Expediente de beca]: abrir;
{{PR|accede}} [Tercero]: abrir;
{{PR|accede}} [Trabajador]: abrir;
{{PR|accede}} [Resolución positiva]: modificar;
{{PR|accede}} [Resolución negativa]: modificar;
{{PR|accede}} [Oficina de Ayudas y Becas]: entrar;
realiza [Comprobar documentación]
realiza [Elaborar resolución positiva]
realiza [Elaborar resolución negativa]
realiza [Firmar propuesta de resolución]
{{T|firma}} [Resolución positiva]: [Datos generales].[Firma de la propuesta];
{{T|firma}} [Resolución negativa]: [Datos generales].[Firma de la propuesta];
{{PR|fin}}

{{PR|tipo}} [Usuario Oficina de la Dirección] {{PR|es}} {{RE|rol}}
{{PR|accede}} [Resolución positiva]: modificar;
{{PR|accede}} [Resolución negativa]: modificar;
{{PR|accede}} [Oficina de la Dirección]: entrar;
realiza [Firmar resolución]
{{T|firma}} [Resolución positiva]: [Datos generales].[Firma de la resolución];
{{T|firma}} [Resolución negativa]: [Datos generales].[Firma de la resolución];
{{PR|fin}}

Una vez definidos, probaremos el proceso creado utilizando el egExplorer. Pero para ello, tendremos que crear los usuarios correspondientes para poder acceder al centro. Esto lo haremos mediante la herramienta egAdmin, cuyos pasos podemos seguir en el siguiente [[Cómo_instalar_un_centro_desde_cero#Creación_de_usuarios_en_un_centro|tutorial]].Cuando tengamos los usuarios creados, sería interesante crear un proceso '''Solicitud de beca''' e ir lanzando sus correspondientes tareas. En el momento que sea necesario cambiar de usuario para que una tarea pueda ser lanzada, cerraremos el egExplorer y accederemos nuevamente a él pero esta vez con un usuario que nos permita lanzar la siguiente tarea.En caso de necesitar documentación sobre los roles, podemos acceder a la [[Tarea F: Abriendo el registro al resto de las oficinas|tarea F]] realizada anteriormente.

==Siguiente tarea==
:*[[Tarea_J:_Importar_la_base_de_datos_de_terceros_de_otra_aplicación|Tarea J: Importar la base de datos de terceros de otra aplicación]]

==Véase también==
:*[[Tarea_A:_Libros_y_registro_de_entrada_y_salida|Tarea A: Libros y registro de entrada y salida]]
:*[[Tarea_B:_Mejorando_la_numeración_del_registro|Tarea B: Mejorando la numeración del registro]]
:*[[Tarea_C:_Evolucionando_la_arquitectura_del_registro|Tarea C: Evolucionando la introducción de datos]]
:*[[Tarea_D:_Validar_la_introducción_de_datos|Tarea D: Validar la introducción de datos]]
:*[[Tarea_E:_Utilizar_el_registro_como_un_almacén_de_documentación|Tarea E: Utilizar el registro como un almacén de documentación]]
:*[[Tarea_F:_Abriendo_el_registro_al_resto_de_las_oficinas|Tarea F: Abriendo el registro al resto de las oficinas]]
:*[[Tarea_G:_Evitando_la_repliación_de_código|Tarea G: Evitando la repliación de código]]
:*[[Tarea_H:_Emitir_certificados_de_documentación|Tarea H: Emitir certificados de documentación]]

Tarea I: Creando una oficina sin papeles

2009-08-04T10:06:48Z

Imhernandez: /* Definir el Expediente de beca */

[[Construir_una_aplicación_paso_a_paso|Construir una aplicación paso a paso]]
[[Imagen:Tarea_I_Figura_1_Diagrama_procedimiento.jpg|thumb|250px|Procedimiento de concesión de becas]]
 
Hasta ahora, los usuarios del Registro utilizan el software sólo para introducir o consultar datos, sin realizar ningún trámite ni llevar a cabo un procedimiento administrativo.
Supongamos que la organización ofrece becas para la realización de estudios en el extranjero. Estas becas las gestiona el Servicio de Ayudas y Subvenciones. Los interesados deben presentar las solicitudes en el Registro de Entrada y Salida. Un auxiliar del Registro revisa la documentación y, en caso de faltar algo, elabora un requerimiento para el interesado. Este requerimiento debe firmarlo el jefe de servicio del Registro.
Una vez la documentación esté completa, se remite al Servicio de Ayudas y Subvenciones quien resuelve la beca por el procedimiento de concurrencia sin concurso; es decir, que todos aquellos interesados que cumplan con los requisitos recibirán la beca.
Al recibir la documentación, un técnico del Servicio de Ayudas y Subvenciones comprueba la documentación para ver si el interesado cumple con los requisitos. A continuación, procede a elaborar resolución positiva (o negativa). La resolución la deben firmar el jefe del Servicio de Ayudas y Subvenciones y el director de la organización.
Una vez firmada, la resolución se remite al Registro, donde un auxiliar se encarga de darle salida.
El procedimiento se puede resumir en el siguiente diagrama.

__TOC__

==¿Qué nos hace falta?==
Para implementar este ''workflow'', primero debemos identificar los ítems de información y, a continuación, definirlos en el sistema. Analizando, vemos que necesitamos cuatro objetos diferentes:
*'''Entrada''', para las tareas de Registrar entrada de documentación y Comprobar documentación. Este tipo ya lo tenemos definido.
*'''Requerimiento''', para las tareas de Elaborar requerimiento y Firmar requerimiento.
*'''Resolución positiva''' y '''Resolución negativa''', para las tareas de Elaborar resolución positiva/negativa, Firmar propuesta de resolución, Firmar resolución y Registrar salida de documentación.

Además, todos los documentos relacionados con una solicitud deben almacenarse en alguna parte. Para ello, definiremos también el tipo '''Expediente de beca'''.

Por último, debemos definir dos nuevas habitaciones, donde se enviarán sus tareas específicas: la '''Oficina de Ayudas y Subvenciones''' y la '''Oficina de dirección'''.

==Definir los escritos==

Definimos el requerimiento de documentación con dos componentes: una componente [[Escritos|escrito]], para la plantilla del documento, y una componente formulario, para los campos firma.

{{PR|tipo}} [Requerimiento de documentación] {{PR|es}} {{RE|contenedor}}
[Escrito] {{PR|es}} {{T|documento}}
-{{AT|plantilla_documento}} = {{STR|"Req 001.rtf"}};
{{PR|fin}}

[Datos generales] {{PR|es}} {{T|formulario}}
[Firma del escrito] {{PR|es}} {{T|firma}}
{{PR|fin}}
{{PR|fin}}

Hacemos lo mismo para las resoluciones. En este caso, como las resoluciones la firman dos personas, debemos incluir dos campos firma, uno para la propuesta y otro para la resolución.

{{PR|tipo}} [Resolución positiva] {{PR|es}} {{RE|contenedor}}
[Escrito] {{PR|es}} {{T|documento}}
-{{AT|plantilla_documento}} = {{STR|"Res 001.rtf"}};
{{PR|fin}}

[Datos generales] {{PR|es}} {{T|formulario}}
[Firma de la propuesta] {{PR|es}} {{T|firma}}
[Firma de la resolución] {{PR|es}} {{T|firma}}
{{PR|fin}}
{{PR|fin}}

{{PR|tipo}} [Resolución negativa] {{PR|es}} {{RE|contenedor}}
[Escrito] {{PR|es}} {{T|documento}}
-{{AT|plantilla_documento}} = {{STR|"Res 002.rtf"}};
{{PR|fin}}

[Datos generales] {{PR|es}} {{T|formulario}}
[Firma de la propuesta] {{PR|es}} {{T|firma}}
[Firma de la resolución] {{PR|es}} {{T|firma}}
{{PR|fin}}
{{PR|fin}}

==Definir el Expediente de beca==
Cada vez que se inicie un trámite de beca, abriremos un expediente en el que se recogerá toda la documentación relacionada con el trámite. Este expediente tendrá un número (asignado automáticamente), que identificará el trámite, y una fecha de alta, que indicará la fecha en la que se inició el trámite. Asimismo, tendrá un vínculo a la '''Entrada''' que dio lugar al trámite.
Crearemos el expediente con dos componentes: una componente para el formulario de datos y otra para la colección en la que se almacenarán todos los documentos.
{{PR|tipo}} [Expediente de beca] {{PR|es}} {{RE|contenedor}}
[Datos generales] {{PR|es}} {{T|formulario}}
[Nº de expediente] {{PR|es}} {{T|timbre}}
-{{AT|certificado.valor}} = [&Valor_secuencia];
-{{AT|certificado.secuencia.nombre}} = {{STR|"STR$EXPEDIENTE"}};
-{{AT|certificado.secuencia.longitud}} = 5;
[Fecha de alta] {{PR|es}} {{T|fecha}}
[Solicitud] {{PR|es}} {{T|vinculo}}
-{{AT|vinculo.definicion}} = [Entrada];
-{{AT|vinculo.etiqueta}} = [Datos generales].[Número] + {{STR|" ("}}
+ [Datos generales].[Remitente]->[Datos generales].[Nombre/Razón social]
+ {{STR|" "}} + [Datos generales].[Remitente]->[Datos generales].[Apellidos]
+ {{STR|")"}};
-{{AT|vinculo.valores}} = $matriz([Libro de entrada].[Contenido]);
{{PR|fin}}

[Documentos] {{PR|es}} {{T|coleccion}}
-{{AT|nombre_tabla}} = {{STR|"TC$EXPEDIENTE_BECA"}};

{{PR|contiene}} [Requerimiento de documentación]
{{PR|contiene}} [Resolución positiva]
{{PR|contiene}} [Resolución negativa]

{{PR|columna}} [Nombre]
-{{AT|columna_bd.nombre}} = {{STR|"DOCUMENTO"}};
-{{AT|origen}} = [&Nombre];
{{PR|fin}}
{{PR|fin}}

Por último, necesitamos almacenar los expedientes en alguna parte. Para ello, crearemos un objeto del sistema en el que almacenarlos.

[Expedientes de beca] {{PR|es}} {{RE|contenedor}}
[Contenido] {{PR|es}} {{T|coleccion}}
-{{AT|nombre_tabla}} = {{STR|"TC$EXPEDIENTES"}};

{{PR|contiene}} [Expediente de beca]

{{PR|columna}} [Nº de expediente]
-{{AT|columna_bd.nombre}} = {{STR|"NUMERO"}};
-{{AT|origen}} = [Datos generales].[Nº de expediente];
{{PR|columna}} [Fecha de alta]
-{{AT|columna_bd.nombre}} = {{STR|"FECHA_ALTA"}};
-{{AT|origen}} = [Datos generales].[Fecha de alta];
{{PR|fin}}
{{PR|fin}}

==Definir las oficinas==
Tan sólo nos queda definir la oficinas y ubicar los recursos necesarios en cada una. En nuestro caso, se reduce sólo al estante de expedientes, ya que es el único recurso común a las tres oficinas.

[Oficina de Ayudas y Subvenciones] {{PR|es}} {{RE|habitacion}}
-{{AT|publico}} = falso;

{{PR|ubicado}} [Expedientes de beca]
-{{AT|lugar}} = {{STR|"Estantes"}};
{{PR|fin}}

[Oficina de la dirección] {{PR|es}} {{RE|habitacion}}
-{{AT|publico}} = falso;

{{PR|ubicado}} [Expedientes de beca]
-{{AT|lugar}} = {{STR|"Estantes"}};
{{PR|fin}}

==¿Cómo funciona el motor de ''workflow''?==
Hasta ahora nos hemos centrado en definir los ítems de información que nos iban a hacer falta para llevar a cabo el procedimiento de concesión de beca. En los próximos apartados veremos cómo implementar el flujo de trabajo, pero primero explicaremos cómo funciona el motor de ''workflow'' de la plataforma.
En egeasy, los procedimientos administrativos se definen en dos pasos. En primer lugar, debe definirse el flujo de tareas. Esta definición se hace en un fichero con extensión nmt. Los ficheros nmt son ficheros de texto plano que se crean en la carpeta Data del proyecto. Una vez definido el flujo de tareas, procederemos a definir los atributos de cada tarea: ítem de trabajo, código que se ejecuta al terminar la tareas, ... Estas definiciones se realizan en ficheros ndf, como hemos hecho con el resto de los recursos.
Comenzaremos con el flujo de tareas. Lo primero que debemos hacer es crear, en la carpeta Data, el fichero '''concesion_beca.nmt'''. A continuación, abrimos el fichero con el editplus.
Los ficheros nmt se componen de '''métodos'''. Por hacer un símil, un método sería equivalente a un procedimiento de PASCAL. Cada método lanza tareas, invoca a otros métodos y ejecuta sentencias en ODL. Adicionalmente, puede tener parámetros de E/S y variables locales.
Aquí tenemos un ejemplo.
{{PR|metodo}} RegistrarEntrada();
{{PR|var}}
TareaRegistro: {{RE|tarea}};
{{PR|inicio}}
TareaRegistro = {{T|$lanzar}}({{STR|"Registrar entrada"}});
TareaRegistro.[&Destino]->[Datos generales].[Asunto] = {{STR|"Esto es una prueba"}};
$guardar(TareaRegistro.[&Destino]);
{{PR|fin}}
En este segmento de código hemos definido el método RegistrarEntrada. A continuación, hemos definido la variable TareaRegistro de tipo {{RE|tarea}}. Después hemos definido la secuencia de tareas.
Cuando comienza la ejecución de un método, el motor de ''workflow'' posiciona el cursor en la primera línea del método que está justo después de '''inicio'''. Comienza a ejecutar línea por línea hasta que alguna de las sentencias lanza una tarea. Entonces, el sistema crea una nueva tarea, le asigna un ítem de trabajo y establece el estado de la tarea a '''pendiente'''. La ejecución del método queda detenida hasta que se finalice la tarea. En nuestro ejemplo, al iniciarse la ejecución del método se lanzaría la tarea '''Registrar entrada'''.
Cualquier usuario con los permisos suficientes puede ir a la bandeja de '''Tareas disponibles''' y '''comenzar la tarea'''. Cuando lo hace, la plataforma abre el ítem de trabajo asignado y cambia el estado de la tarea a '''realizándose'''.
Cuando el usuario finaliza la tarea, el sistema cambia el estado a '''terminada''' y retoma la ejecución del método que invocó a la tarea. En nuestro ejemplo, asignaría a la variable TareaRegistro la tarea que se acaba de terminar. A continuación ejecutaría las siguientes líneas de código, que modifican el ítem de trabajo de la tarea para después almacenarlo.
Un método termina de ejecutarse cuando el cursor alcanza la palabra fin.

===¿Cómo comienza a ejecutarse un método?===
Todo proceso tiene un punto de entrada que lanza a ejecutar la primera línea del primer método. Este punto de entrada es un tipo de tarea que se define como raíz en los ficheros de definiciones ndf.Para cada proceso que exista en nuestro sistema de información, tendremos que definir una tarea, llamémosla ''inicializadora'' del proceso.Veamos a continuación la definición de esta tarea, que se corresponde con el proceso '''Solicitud de beca''':

{{PR|tipo}} [Solicitud de beca] {{PR|es}} {{RE|tarea}}
-{{AT|descripcion}} = {{STR|"Proceso que se encarga de realizar la resolución de una solicitud de beca"}};
-{{AT|fuente.definicion}} = [Registro de entrada y salida];
-{{AT|destino.definicion}} = [Expediente de beca];
-{{AT|destino.valor}} = $crear([Expedientes de beca].[Contenido]);
-{{AT|Al_Comenzar.Nombre}} = {{STR|"Metodos\concesion_beca.RegistrarEntrada"}};
-{{AT|es_raiz}} = verdadero;
{{PR|fin}}

La forma de indicar que la tarea '''Solicitud de beca''' inicia un proceso de nuestro sistema de información es mediante el atributo lógico '''es_raiz'''. Dicho atributo tiene asignado por defecto el valor falso, de forma que poniéndolo a verdadero, conseguiremos que dicha tarea inicie un proceso que será lanzado por un usuario.Ahora bien, ¿sobre qué [[Contenedores|contenedor]] queremos que se lance la tarea?Siempre que lanzamos una tarea, es necesario indicar sobre qué contenedor podremos lanzarla. Para ello, ODL proporciona un atributo llamado '''fuente.definicion'''. En el caso de una tarea raíz, se indicarán aquellas habitaciones a las que habrá que acceder para poder iniciar la tarea raíz. Por eso hemos indicado una habitacion en vez de un contenedor en la definición de Solicitud de beca.Esto significa que el usuario podrá lanzar la tarea Solicitud de beca una vez haya accedido a la habitación Registro de entrada y salida. En posteriores definiciones de tareas, veremos que especificaremos un contenedor en vez de una habitación en el atributo fuente.definicion.El método a ejecutar una vez se lance la tarea, lo indicaremos en el atributo '''Al_Comenzar.Nombre''', que como vemos, tiene asignado el método creado anteriormente RegistrarEntrada. La manera de indicar el método es añadiendo la ruta del fichero donde está incluído a partir de la carpeta '''Data''' del modelo, seguido de un punto y el nombre del método.Por último, indicaremos en el atributo '''destino.definicion''' lo que se conoce como ''maintarget'' de un proceso, es decir, aquel contenedor que se asociará al proceso durante su ejecución.El ''maintarget'' de Solicitud de beca será un contenedor de tipo '''Expediente de beca'''. ¿Por qué? Porque las tareas que se lancen dentro de este proceso y la información que se genere se almacenará en un Expediente de beca.Además, no sólo queremos indicar el ''maintarget'' del proceso Solicitud de beca, sino que también queremos crear el expediente una vez se inicie el proceso. Para ello, utilizaremos la función '''$crear''' definida en la librería de funciones de ODL, que nos permite crear un objeto, indicándole la colección donde se va a almacenar. El tipo de objeto será el definido en destino.definicion. El objeto devuelto por $crear se asignará al atributo '''destino.valor'''.

===Interpretación del diagrama de flujo===
Antes de meternos de lleno a desarrollar el ''workflow'', vamos a estudiar el diagrama de flujo de información de concesión de becas facilitado al comienzo de este artículo.Es recomendable que abramos el diagrama ampliado en una pestaña nueva del navegador y lo mantengamos hasta el final de este artículo, de manera que podamos ir fijándonos en él a medida que vamos avanzando en el desarrollo del ''workflow''.Fijándonos en el diagrama, vemos que el flujo de trabajo está dividido en tres secciones, donde cada una de ellas equivale a una oficina de la organización. Dentro de cada oficina existen una serie de estados, que equivalen a las diferentes tareas que se pueden lanzar. Por tanto, habrá que implementar una tarea por cada estado que aparece en el diagrama.Si las tareas equivalen a los estados, el flujo de trabajo equivaldría a las líneas de transición que nos permiten cambiar de estado. En nuestro método RegistrarEntrada tendremos que implementar este flujo de trabajo.Podemos ver que para lanzar ciertas tareas, habrá que evaluar una condición. Por ejemplo, para lanzar la tarea ComprobarDocumentacion será necesario evaluar si la documentación necesaria está completa. De no ser así, se lanzaría la tarea ElaborarRequerimiento.Por tanto, en la implementación de nuestro método tendremos que plasmar el camino de datos que observamos en el diagrama.Además, el diagrama nos indica a qué oficina debe acceder un usuario para realizar cada una de las tareas, teniendolo en cuenta a la hora de definir los roles.

===Evolucionando el ''workflow''===
Antes de meternos de lleno en la elaboración del ''workflow'', hagamos un resumen de aquellos ficheros y nuevas definiciones que hemos creado.Por un lado, para poder desarrollar una concesión de beca, hemos definido un expediente de beca, un registro de expedientes de beca, un requerimiento de documentación y una resolución positiva y negativa de la concesión de una beca con la elaboración de sus respectivos documentos. Todas ellas son definiciones de tipo {{RE|contenedor}}, y serán los ítems con los que trabajaremos a lo largo de todo el flujo de información. Además, hemos definido una Oficina de Ayudas y Subvenciones y una Oficina de Dirección. Todas estas definiciones las hemos realizado en el fichero '''Main.ndf''' de la carpeta #Source.En esta misma carpeta, se encuentra el fichero '''tareas.ndf''' donde ya hemos definido la tarea raíz Solicitud de beca y donde vamos a definir el resto de tareas.Por último, en la carpeta Data\Metodos hemos creado el fichero '''concecion_beca.nmt''' donde hemos incluído un ejemplo del método RegistroEntrada.Una vez hecho este resumen, ahora sí que vamos a desarrollar nuestro proceso '''Solicitud de beca'''. Mostraremos paso a paso el código a introducir siguiendo el diagrama de flujo de información. Iremos alternando la implementación del método y de las tareas según lo vayamos necesitando.
 
Cuando se produce una '''Entrada''' para solicitar una beca, el sistema de información generará un '''Expediente de beca''' único y se registrará la entrada que además estará asociada al expediente mediante el campo vínculo '''[Solicitud]'''. A partir de este momento, toda la información que genere el proceso tendrá asociado un Expediente de beca, por ello el ''maintarget'' del proceso Solicitud de beca es el expediente creado.Por tanto, una vez lanzada la tarea raíz y se empeciece a ejecutar el método RegistrarEntrada, habrá que crear un expediente de beca y registrar la entrada recibida lanzando las tareas correspondientes desde el método y definiéndolas:

{{PR|metodo}} RegistrarEntrada();
{{PR|var}}
{{PR|inicio}}
{{T|$lanzar}}({{STR|"Registrar expediente de beca"}});
{{T|$lanzar}}({{STR|"Registrar entrada"}});
{{PR|fin}}

La función '''$lanzar''', lanza una tarea cuyo nombre debemos pasar por parámetro, como vemos en el código. En este caso, no pasamos por parámetro ningún ítem (''target'') a la tarea, ya que será creado por la propia tarea, aunque veremos que en posteriores definiciones sí tendremos que incluir un ''target'' como parámetro de entrada. Además, también es posible indicar la habitación en la cuál un usuario podrá realizar la tarea. En caso de no especificarla, se tomará como habitación la definida en la tarea raíz, que en nuestro caso es '''Registro de entrada y salida'''.Definamos entonces dichas tareas en nuestro fichero ''tareas.ndf'':

{{PR|tipo}} [Registrar expediente de beca] {{PR|es}} {{RE|tarea}}
-{{AT|fuente.definicion}} = [Expediente de beca];
-{{AT|Al_finalizar.Codigo}} = {{STR|"$sellar([&Destino]->[Datos generales].[Nº de expediente]); $guardar([&Destino]); "}};
{{PR|fin}}

{{PR|tipo}} [Registrar entrada] {{PR|es}} {{RE|tarea}}
-{{AT|fuente.definicion}} = [Expediente de beca];
-{{AT|destino.definicion}} = [Entrada];
-{{AT|destino.valor}} = $crear([Libro de entrada].[Contenido]);
-{{AT|Al_finalizar.Codigo}} = {{STR|"$sellar([&Destino]->[Datos generales].[Número]); $guardar([&Destino]); "}};
{{PR|fin}}

En la tarea '''Registrar expediente de beca''', el atributo {{AT|fuente.definicion}} que hay definido ya lo conocemos. En él indicamos el objeto de referencia de la tarea. En el atributo {{AT|destino.definicion}}, que no aparece, deberíamos indicar el contenedor (''target'', ítem) con el que va a trabajar la tarea, pero este atributo, si no se especifica, asumirá como destino el contenedor definido en fuente.definicion. Equivaldría a poner <code>destino.definicion = [Expediente de beca]</code>.Por tanto, al arrancar esta tarea, se creará un expediente nuevo. El atributo {{AT|Al_finalizar.Codigo}} nos permite invocar un método o directamente asignarle instrucciones en forma de ristra, que se ejecutarán en tiempo de ejecución una vez se finalice la tarea. En nuestro caso, se sellará el campo timbre que existe en el expediente y además se guardará el objeto. Para que entendamos bien las instrucciones empleadas en el atributo Al_finalizar.Codigo, es necesario conocer la propiedad '''[&Destino]''' de una tarea.Esta propiedad permite acceder al ''target'' actual de una tarea, que en el caso de Registrar expediente de beca, es un '''Expediente de beca'''. Una vez accedido al ''target'', podremos acceder a otros componentes que estén definidos en él, como por ejemplo, a un campo timbre incluído en la definición de un formulario, que es exactamente lo que se realiza en nuestro caso. Con la función '''$sellar''', sellamos el campo timbre, y con la función '''$guardar''', guardamos el objeto.Una vez registrado un nuevo expediente, procederemos a registrar la entrada de petición de beca mediante la tarea '''Registrar entrada'''. La diferencia que podemos observar respecto a la tarea anterior es la inclusión de los atributos {{AT|destino.definicion}} y {{AT|destino.valor}}.¿Y por qué ahora sí están incluídos? Esto es debido a que esta tarea no va a registrar un Expediente de beca, sino que registrará una Entrada, aunque el objeto referencia de la tarea sí seguirá siendo el Expediente de beca creado anteriormente.Además, al finalizar la tarea, ejecutaremos el mismo código que la tarea anterior, con la diferencia de que en esta ocasión, la propiedad [&Destino] accederá a un objeto de tipo Entrada, que es el ''target'' de esta tarea. ¿Y el atributo {{AT|destino.valor}}?Como ya explicamos en la definición de la tarea raíz '''Solicitud de beca''', utilizaremos la función '''$crear''' en este atributo, para indicar la colección donde se va a guardar el objeto del tipo definido en el atributo {{AT|destino.definicion}}, es decir, un objeto de tipo Entrada.
 
Una vez realizada esta primera fase, volvemos a fijarnos en el diagrama, y vemos que una vez la Entrada es recibida, registrada, y creado su Expediente de beca, el siguiente paso, sería comprobar la documentación. Para ello, es necesario que la documentación entregada por la persona que realiza la petición de la beca esté completa. En caso de no ser así, se generará un documento de requerimiento, que deberá ser firmado, dando lugar a posibles nuevas entradas en el proceso, pero con un Expediente de beca ya creado. Esto se producirá tantas veces como requerimientos de documentación se puedan dar. Una vez no falte ningún tipo de documentación, se lanzará la tarea '''Comprobar documentación'''.Pero, ¿y cómo podemos saber si en la solicitud de una beca falta documentación?Para ello, hemos modificado la definición del contenedor '''Entrada''', añadiendo simplemente un campo tabla para registrar la documentación y un campo de tipo texto llamado '''[Documentación completa]'''.Veamos primero los cambios introducidos, tanto en el contenedor '''Entrada''' como en el método, para comentarlos posteriormente:

[Sí o No] {{PR|es}} {{RE|enumerado}}
{{AT|valores}}
{{STR|"Sí"}},
{{STR|"No"}}
{{PR|fin}}

{{PR|tipo}} [Entrada] {{PR|es}} {{RE|contenedor}}
[Datos generales] {{PR|es}} {{T|formulario}}
...
...
...
[Documentación presentada] {{PR|es}} {{T|tabla}}
[Documento] {{PR|es}} {{T|texto}}
{{PR|fin}}
[Documentación completa] {{PR|es}} {{T|texto}}
-{{AT|apariencia.desplegable}} = verdadero;
-{{AT|edicion.seleccion}} = verdadero;
-{{AT|edicion.valores}} = $matriz([Sí o No]);
{{PR|fin}}
{{PR|fin}}

{{PR|metodo}} RegistrarEntrada();
{{PR|var}}
TareaRegistroBeca: tarea;
TareaRegistroEntrada: tarea;
ElaborarRequerimiento: tarea;
ElaborarResolucion: tarea;
documentacion_incompleta: logico;
{{PR|inicio}}
documentacion_incompleta = verdadero;
TareaRegistroBeca = {{T|$lanzar}}({{STR|"Registrar expediente de beca}}");
{{PR|mientras}} documentacion_incompleta
TareaRegistroEntrada = {{T|$lanzar}}({{STR|"Registrar entrada"}});
TareaRegistroBeca.[&Destino]->[Datos generales].[Solicitud] = TareaRegistroEntrada.[&Destino];
$guardar(TareaRegistroBeca.[&Destino]);
{{PR|si}} (TareaRegistroEntrada.[&Destino]->[Datos generales].[Documentación completa] = {{STR|"Sí"}})
documentacion_incompleta = falso;
{{PR|sino}}
ElaborarRequerimiento = {{T|$lanzar}}({{STR|"Elaborar requerimiento"}});
{{T|$lanzar}}({{STR|"Firmar requerimiento"}}, ElaborarRequerimiento.[&Destino]);
{{PR|fin}}
{{PR|fin}}
{{PR|fin}}

Vemos que en la definición de Entrada hemos incluído los campos que comentamos para comprobar la documentación.También podemos observar que hay una serie de variables declaradas en la implementación de nuestro método, que nos permitirán almacenar en ellas un recurso del mismo tipo que el definido para la variable. La variable lógica '''documentacion_incompleta''', que inicializamos a "verdadero", la utilizaremos para controlar la salida del bucle que se ocupa de los requerimientos de documentación, y como consecuencia, de nuevas entradas. Dicha salida se producirá cuando el campo [Documentación completa] de la Entrada actual tenga valor "Sí", asignándole "falso" a documentacion_incompleta.¿Y cómo consultamos dicho campo?Al lanzar la tarea '''Registrar entrada''', ésta la almacenamos en la variable de tipo tarea '''TareaRegistroEntrada'''. Esto nos va a permitir acceder al ''target'' de la tarea mediante la propiedad [&Destino] en cualquier momento del código, ya que la tarea quedará almacenada en la variable. En este caso, el objeto es de tipo Entrada, por lo que podremos acceder al campo [Documentación completa] y realizar la consulta.Una vez la documentación esté completa, el usuario modificará el campo [Documentación completa] asignándole el valor "Sí", de manera que saldremos del bucle. En caso contrario, lanzaremos la tarea encargada de elaborar un requerimiento, que a su vez tendrá que ser firmada, lanzando la tarea correspondiente para ficha firma.Respecto a las tareas '''Elaborar requerimiento''' y '''Firmar requerimiento''' es necesario tener en cuenta lo siguiente.Al igual que en el lanzamiento de las demás tareas, la tarea Elaborar requerimiento también es asignada a una variable, en este caso, llamada '''ElaborarRequerimiento'''. A continuación, se lanza la tarea Firmar requerimiento, pero esta vez con un nuevo parámetro. Este parámetro corresponde al ''target'' de la tarea anterior, y lo indicamos como parámetro utilizando la variable ElaborarRequerimiento para acceder a la tarea, junto con la propiedad [&Destino] para acceder a su ''target''. Esto lo realizamos porque la tarea Firmar requerimiento no va a crear ningún ''target'', sino que firmará el campo firma que se encuentra en el objeto '''Requerimiento de documentación''' creado en la tarea anterior. Por tanto, este objeto o ''target'' tendrá que ser pasado como parámetro a la tarea Firmar requerimiento.
Hay dos instrucciones que no hemos comentado aún. Son exactamente las dos instrucciones anteriores a la consulta del campo [Documentación completa].Como ya sabemos, nuestra definición de tipo contenedor Expediente de beca tiene un campo vínculo, que referencia a la última Entrada que se haya almacenado en el expediente. Para que esto suceda, es necesario que después de registrar una nueva entrada se modifique este campo vínculo, para que referencie al último objeto de tipo Entrada. Esto lo conseguimos utilizando dos variables de tipo tarea, una para la tarea Registrar expediente de beca y otra para Registrar entrada. En cada variable almacenamos cada una de las dos tareas, de manera que nos permitan acceder al ''target'' de cada una de ellas. Al campo vínculo '''TareaRegistroBeca.[&Destino]->[Datos generales].[Solicitud]''' le asignaremos el ''target'' de la tarea Registrar entrada, '''TareaRegistroEntrada.[&Destino]'''. Una vez asignada la Entrada al campo vínculo, se guardará el objeto para aplicar los cambios realizados en el objeto.Es necesario realizar estas dos acciones dentro del bucle y antes de realizar la comprobación del campo [Documentación completa] del objeto Entrada, ya que, en caso de no hacerlo, no se estará verificando el campo [Documentación completa] de la nueva Entrada, sino de la anterior, o de ninguna, en caso de que estemos tratando una primera entrada.Una vez analizado el nuevo código introducido en el método, veamos la definición de las nuevas tareas que aparecen; Elaborar requerimiento y Firmar requerimiento:

{{PR|tipo}} [Elaborar requerimiento] {{PR|es}} {{RE|tarea}}
-{{AT|fuente.definicion}} = [Expediente de beca];
-{{AT|destino.definicion}} = [Requerimiento de documentación];
-{{AT|destino.valor}} = $crear([Documentos]);
{{PR|fin}}

{{PR|tipo}} [Firmar requerimiento] {{PR|es}} {{RE|tarea}}
-{{AT|fuente.definicion}} = [Expediente de beca];
-{{AT|destino.definicion}} = [Requerimiento de documentación];
-{{AT|localizacion}} = [Datos generales];
-{{AT|Al_finalizar.Codigo}} = {{STR|"$firmar([&Destino]->[Datos generales].[Firma del escrito]); $guardar([&Destino]); "}};
{{PR|fin}}

Cabe comentar un atributo que hasta ahora no hemos tenido que utilizar. Se trata del atributo {{AT|localizacion}}. En él, indicaremos una componente que queramos activar al iniciar la tarea, en principio, para su edición. En este caso, activamos la componente [Datos generales] del contenedor Requerimiento de documentación, que es donde está incluído el campo firma que vamos a editar en esta tarea. En caso de no hacerlo, no podríamos realizar la firma al ejecutar el código <code>{{STR|"$firmar([&Destino]->[Datos generales].[Firma del escrito])</code>.

Una vez hemos analizado ya varias definiciones de tareas, nos damos cuenta que el aspecto más importante a la hora de definir una tarea es tener muy claro el ''target'' con el que va a trabajar la tarea. Es decir, saber si el ''target'' será creado por la propia tarea o si por el contrario, trabajará con un ''target'' ya creado.En caso de crear uno nuevo utilizaremos los atributos destino.definicion y destino.valor para especificar el tipo del objeto y el lugar donde se almacenará. En caso de utilizar uno creado por tareas anteriores, tendremos que incluir el ''target'' de la tarea anterior como parámetro de la nueva tarea. Esto lo conseguimos, como ya hemos visto, utilizando una variable en la cual almacenamos la tarea que nos interese, y con la propiedad [&Destino] referenciamos a su ''target''.

===Finalizando el ''workflow''===
Siguiendo con el flujo de trabajo, pasamos ahora a la siguiente oficina de nuestra organización, '''Servicio de Ayudas y Subvenciones'''.Una vez hemos verificado que la documentación de una solicitud está completa, pasamos a lanzar la tarea '''Comprobar documentación'''. Esta tarea abrirá la última Entrada que referencia el campo vínculo '''[Solicitud]''' de un expediente concreto y analizará la documentación entregada para elaborar una resolución positiva, en caso de cumplir los requisitos, o negativa, en caso de no cumplirlos. El ''target'' de esta tarea, tendrá que ser pasado como parámetro, que al ser la última Entrada registrada, podremos acceder a él utilizando la variable '''TareaRegistroEntrada'''. Pero, hay que tener en cuenta otro aspecto a la hora de lanzar esta tarea.Hasta ahora, no nos hemos preocupado de la oficina en la cual podíamos realizar las tareas. Esto ha sido así debido a que las tareas hasta ahora lanzadas compartían la oficina de la tarea raíz (Registro de entrada y salida), y por tanto, no se especificaba como parámetro al lanzar una tarea. Pero ahora sí es necesario especificarlo, ya que hemos cambiado de oficina. La sintaxis para hacerlo es la siguiente:

{{T|$lanzar}}({{STR|"nombre"}},target,[oficina])

Veamos el código a añadir en nuestro método y la implementación de la tarea '''Comprobar documentación''':

{{PR|metodo}} RegistrarEntrada();
{{PR|var}}
TareaRegistroBeca: tarea;
TareaRegistroEntrada: tarea;
ElaborarRequerimiento: tarea;
ElaborarResolucion: tarea;
DocumentacionComprobada: tarea;
documentacion_incompleta: logico;
{{PR|inicio}}
documentacion_incompleta = verdadero;
TareaRegistroBeca = {{T|$lanzar}}({{STR|"Registrar expediente de beca}}");
{{PR|mientras}} documentacion_incompleta
...
... {{COM|//Bucle}}
...
{{PR|fin}}
DocumentacionComprobada = {{T|$lanzar}}({{STR|"Comprobar documentación"}},TareaRegistroEntrada.[&Destino],[Oficina de Ayudas y Becas]);
{{PR|fin}}

{{PR|tipo}} [Comprobar documentación] {{PR|es}} {{RE|tarea}}
-{{AT|fuente.definicion}} = [Expediente de beca];
-{{AT|destino.definicion}} = [Entrada];
{{PR|fin}}

En este caso, el usuario de la Oficina de Ayudas y Subvenciones analizará la documentación presentada y dejará constancia de dicho análisis especificando si es un caso favorable o desfavorable para la concesión de una beca.Pero, ¿dónde deja constancia?Para ello, hemos definido otro campo de tipo texto en la definición de contenedor Entrada llamado '''[Cumple los requisitos]'''. Este será el campo donde se concretará si un solicitante cumple los requisitos. Veamos el código a incluir en la definición de Entrada:

{{PR|tipo}} [Entrada] {{PR|es}} {{RE|contenedor}}
[Datos generales] {{PR|es}} {{T|formulario}}
...
...
...
[Cumple los requisitos] {{PR|es}} {{T|texto}}
-{{AT|apariencia.desplegable}} = verdadero;
-{{AT|edicion.seleccion}} = verdadero;
-{{AT|edicion.valores}} = $matriz([Sí o No]);
{{PR|fin}}
{{PR|fin}}

Siguiendo con el flujo de trabajo del diagrama, las siguientes tareas a lanzar tratarían la elaboración de una resolución de beca, positiva o negativa, en función del valor que contenga el campo [Cumple los requisitos]. Por tanto, habrá que consultar dicho campo para saber cuál de las tareas lanzar:

{{PR|metodo}} RegistrarEntrada();
{{PR|var}}
TareaRegistroBeca: tarea;
TareaRegistroEntrada: tarea;
ElaborarRequerimiento: tarea;
ElaborarResolucion: tarea;
DocumentacionComprobada: tarea;
documentacion_incompleta: logico;
{{PR|inicio}}
documentacion_incompleta = verdadero;
TareaRegistroBeca = {{T|$lanzar}}({{STR|"Registrar expediente de beca}}");
{{PR|mientras}} documentacion_incompleta
...
... {{COM|//Bucle}}
...
{{PR|fin}} 
DocumentacionComprobada = {{T|$lanzar}}({{STR|"Comprobar documentación"}},TareaRegistroEntrada.[&Destino],[Oficina de Ayudas y Becas]); 
{{PR|si}} (DocumentacionComprobada.[&Destino]->[Datos generales].[Cumple los requisitos] = {{STR|"Sí"}}) 
ElaborarResolucion = {{T|$lanzar}}({{STR|"Elaborar resolución positiva"}},[Oficina de Ayudas y Subvenciones]); 
{{PR|sino}} 
ElaborarResolucion = {{T|$lanzar}}({{STR|"Elaborar resolución negativa"}},[Oficina de Ayudas y Subvenciones]); 
{{PR|fin}} 
{{PR|fin}}

Consultamos el campo [Cumple los requisitos] y en función de su valor se lanzará o bien la tarea '''Elaborar resolución positiva''' o '''Elaborar resolución negativa'''.Ambas tareas crearán un ''target'' nuevo, que será o bien un objeto de tipo Resolución positiva o Resolución negativa. Dicho objeto será posteriormente utilizado como ''target'' por las tareas '''Firmar propuesta de resolución''' y '''Firmar resolución''', de forma que tendrán que ser pasados por parámetro en dichas tareas. Una vez realizadas las dos firmas del documento generado, se creará un objeto de tipo Salida que se registrará en el Registro de Entrada y Salida:

{{PR|tipo}} [Elaborar resolución positiva] {{PR|es}} {{RE|tarea}}
-{{AT|fuente.definicion}} = [Expediente de beca];
-{{AT|destino.definicion}} = [Resolución positiva];
-{{AT|destino.valor}} = $crear([Documentos]);
{{PR|fin}}

{{PR|tipo}} [Elaborar resolución negativa] {{PR|es}} {{RE|tarea}}
-{{AT|fuente.definicion}} = [Expediente de beca];
-{{AT|destino.definicion}} = [Resolución negativa];
-{{AT|destino.valor}} = $crear([Documentos]);
{{PR|fin}}

{{PR|metodo}} RegistrarEntrada();
{{PR|var}}
TareaRegistroBeca: tarea;
TareaRegistroEntrada: tarea;
ElaborarRequerimiento: tarea;
ElaborarResolucion: tarea;
DocumentacionComprobada: tarea;
documentacion_incompleta: logico;
{{PR|inicio}}
documentacion_incompleta = verdadero;
TareaRegistroBeca = {{T|$lanzar}}({{STR|"Registrar expediente de beca}}");
{{PR|mientras}} documentacion_incompleta
...
... {{COM|//Bucle}}
...
{{PR|fin}} 
DocumentacionComprobada = {{T|$lanzar}}({{STR|"Comprobar documentación"}},TareaRegistroEntrada.[&Destino],[Oficina de Ayudas y Becas]); 
{{PR|si}} (DocumentacionComprobada.[&Destino]->[Datos generales].[Cumple los requisitos] = {{STR|"Sí"}}) 
ElaborarResolucion = {{T|$lanzar}}({{STR|"Elaborar resolución positiva"}},[Oficina de Ayudas y Subvenciones]); 
{{PR|sino}} 
ElaborarResolucion = {{T|$lanzar}}({{STR|"Elaborar resolución negativa"}},[Oficina de Ayudas y Subvenciones]); 
{{PR|fin}} 
{{T|$lanzar}}({{STR|"Firmar propuesta de resolución"}},ElaborarResolucion.[&Destino],[Oficina de Ayudas y Subvenciones]); 
{{T|$lanzar}}({{STR|"Firmar resolución"}},ElaborarResolucion.[&Destino],[Oficina de la dirección]); 
{{T|$lanzar}}({{STR|"Registrar salida de documentación"}}); 
{{PR|fin}}

{{PR|tipo}} [Firmar propuesta de resolución] {{PR|es}} {{RE|tarea}}
-{{AT|fuente.definicion}} = [Expediente de beca];
-{{AT|localizacion}} = [Datos generales];
-{{AT|Al_finalizar.Codigo}} = {{STR|"$firmar([&Destino]->[Datos generales].[Firma de la propuesta]); $guardar([&Destino]); "}};
{{PR|fin}}

{{PR|tipo}} [Firmar resolución] {{PR|es}} {{RE|tarea}}
-{{AT|fuente.definicion}} = [Expediente de beca];
-{{AT|localizacion}} = [Datos generales];
-{{AT|Al_finalizar.Codigo}} = {{STR|"$firmar([&Destino]->[Datos generales].[Firma de la resolución]); $guardar([&Destino]); "}};
{{PR|fin}}

{{PR|tipo}} [Registrar salida de documentación] {{PR|es}} {{RE|tarea}}
-{{AT|fuente.definicion}} = [Libro de salida];
-{{AT|destino.definicion}} = [Salida];
-{{AT|destino.valor}} = $crear([Contenido]);
{{PR|fin}}

==Crear nuevos perfiles de usuario==
Una vez tenemos implementado nuestro ''workflow'', necesitamos definir nuevos roles puesto que los que teníamos definidos anteriormente han quedado desfasados.Definiremos un tipo de rol por cada oficina de nuestra organización:

{{PR|tipo}} [Permisos comunes] {{PR|es}} {{RE|rol}}
{{PR|accede}} [Libro de entrada]: abrir;
{{PR|accede}} [Libro de salida]: abrir;
{{PR|accede}} [Fichero de terceros]: abrir;
{{PR|accede}} [Registro de documentación]: abrir;
{{PR|accede}} [Expedientes de beca]: abrir;
{{PR|accede}} [Fichero de trabajadores]: abrir;
{{PR|accede}} [Oficina de recursos comunes]: entrar;
{{PR|accede}} [Registro de entrada y salida]: entrar;
{{PR|fin}}

{{PR|tipo}} [Usuario Oficina del Registro] {{PR|es}} [Permisos comunes]
{{PR|accede}} [Entrada]: crear;
{{PR|accede}} [Expediente de beca]: crear;
{{PR|accede}} [Salida]: crear;
{{PR|accede}} [Tercero]: crear;
{{PR|accede}} [Trabajador]: crear;
{{PR|accede}} [Requerimiento de documentación]: crear;
realiza [Registrar entrada]
realiza [Elaborar requerimiento]
realiza [Firmar requerimiento]
realiza [Registrar salida de documentación]
{{T|firma}} [Requerimiento de documentación]: [Datos generales].[Firma del escrito];
{{PR|fin}}

{{PR|tipo}} [Usuario Oficina de Servicio de Ayudas y Subvenciones] {{PR|es}} [Permisos comunes]
{{PR|accede}} [Entrada]: modificar;
{{PR|accede}} [Expediente de beca]: abrir;
{{PR|accede}} [Tercero]: abrir;
{{PR|accede}} [Trabajador]: abrir;
{{PR|accede}} [Resolución positiva]: modificar;
{{PR|accede}} [Resolución negativa]: modificar;
{{PR|accede}} [Oficina de Ayudas y Becas]: entrar;
realiza [Comprobar documentación]
realiza [Elaborar resolución positiva]
realiza [Elaborar resolución negativa]
realiza [Firmar propuesta de resolución]
{{T|firma}} [Resolución positiva]: [Datos generales].[Firma de la propuesta];
{{T|firma}} [Resolución negativa]: [Datos generales].[Firma de la propuesta];
{{PR|fin}}

{{PR|tipo}} [Usuario Oficina de la Dirección] {{PR|es}} {{RE|rol}}
{{PR|accede}} [Resolución positiva]: modificar;
{{PR|accede}} [Resolución negativa]: modificar;
{{PR|accede}} [Oficina de la Dirección]: entrar;
realiza [Firmar resolución]
{{T|firma}} [Resolución positiva]: [Datos generales].[Firma de la resolución];
{{T|firma}} [Resolución negativa]: [Datos generales].[Firma de la resolución];
{{PR|fin}}

Una vez definidos, probaremos el proceso creado utilizando el egExplorer. Pero para ello, tendremos que crear los usuarios correspondientes para poder acceder al centro. Esto lo haremos mediante la herramienta egAdmin, cuyos pasos podemos seguir en el siguiente [[Cómo_instalar_un_centro_desde_cero#Creación_de_usuarios_en_un_centro|tutorial]].Cuando tengamos los usuarios creados, sería interesante crear un proceso '''Solicitud de beca''' e ir lanzando sus correspondientes tareas. En el momento que sea necesario cambiar de usuario para que una tarea pueda ser lanzada, cerraremos el egExplorer y accederemos nuevamente a él pero esta vez con un usuario que nos permita lanzar la siguiente tarea.En caso de necesitar documentación sobre los roles, podemos acceder a la [[Tarea F: Abriendo el registro al resto de las oficinas|tarea F]] realizada anteriormente.

==Siguiente tarea==
:*[[Tarea_J:_Importar_la_base_de_datos_de_terceros_de_otra_aplicación|Tarea J: Importar la base de datos de terceros de otra aplicación]]

==Véase también==
:*[[Tarea_A:_Libros_y_registro_de_entrada_y_salida|Tarea A: Libros y registro de entrada y salida]]
:*[[Tarea_B:_Mejorando_la_numeración_del_registro|Tarea B: Mejorando la numeración del registro]]
:*[[Tarea_C:_Evolucionando_la_arquitectura_del_registro|Tarea C: Evolucionando la introducción de datos]]
:*[[Tarea_D:_Validar_la_introducción_de_datos|Tarea D: Validar la introducción de datos]]
:*[[Tarea_E:_Utilizar_el_registro_como_un_almacén_de_documentación|Tarea E: Utilizar el registro como un almacén de documentación]]
:*[[Tarea_F:_Abriendo_el_registro_al_resto_de_las_oficinas|Tarea F: Abriendo el registro al resto de las oficinas]]
:*[[Tarea_G:_Evitando_la_repliación_de_código|Tarea G: Evitando la repliación de código]]
:*[[Tarea_H:_Emitir_certificados_de_documentación|Tarea H: Emitir certificados de documentación]]

Tarea F: Abriendo el registro al resto de las oficinas

2009-08-04T10:00:33Z

Imhernandez: /* Limitar el acceso a la oficina */

[[Construir_una_aplicación_paso_a_paso|Construir una aplicación paso a paso]]

En esta tarea modificaremos el sistema para permitir que usuarios de otros departamentos puedan acceder a la oficina del registro para consultar datos de la base de terceros y del registro. Para garantizar que el acceso es sólo de lectura, de forma que no puedan modificar ninguna información del registro, limitaremos sus permisos.

Para garantizar estos requisitos introduciremos el uso de los roles y cambiaremos los objetos actuales del sistema para que sean privados.

==¿Qué es un rol?==
En todas los sistemas de información existe la necesidad de limitar el acceso de los usuarios a los distintos elementos del sistema. Para lograr este objetivo, ODL proporciona un tipo de '''recurso''': los roles.

Mediante los roles, es posible asignar tres tipos de permisos:
*El grado de acceso a los diferentes objetos del sistema (creación, modificación o sólo acceso).
*Las tareas del ''workflow'' que un determinado perfil puede realizar.
*Los escritos que puede firmar.

En tu sistema, debes crear tantos tipos de roles como perfiles de acceso diferentes existan en la organización.
En nuestro ejemplo del registro de entrada y salida, vamos a definir dos perfiles:
*'''Personal del registro''': identifica a todos aquellos usuarios que pertenecen al registro de entrada y salida y tienen permisos para modificar todos sus elementos.
*'''Personal externo''': identifica a todos aquellos usuarios de otros departamentos que acceden al registro para consultar datos, pero que no tienen capacidad para modificar ningún elemento.

==Convertir las definiciones en privadas==
Hasta ahora, hemos trabajado sin preocuparnos de los roles y no hemos tenido ningún problema para acceder a la habitación, ni para crear entradas o salidas. ¿Por qué? Por defecto, en ODL todos los objetos que se definen son '''públicos'''. Esto significa que cualquiera puede crearlos o modificarlos.
Lo primero que debemos hacer es cambiar las definiciones para hacer los objetos privados. ¿Cómo? Poniendo el atributo {{{A|publico}}} a {{{T|falso}}} al comienzo de cada definición.

{{PR|tipo}} [Entrada] {{PR|es}} {{RE|contenedor}}
-{{AT|publico}} = falso;
{{COM|//...}}
{{PR|fin}}

Compila y actualiza. Abre el egExplorer e intenta crear una Entrada. Te saldrá un mensaje diciendo que no tienes permisos para crear entradas.
[[Image:No_tiene_permisos.jpg|center|thumb|300px|No dispones de permisos]]

Hacemos lo mismo con las Salidas.

{{PR|tipo}} [Salida] {{PR|es}} {{RE|contenedor}}
-{{AT|publico}} = falso;
{{COM|//...}}
{{PR|fin}}

Y con las fichas de Tercero.

{{PR|tipo}} [Tercero] {{PR|es}} {{RE|contenedor}}
-{{AT|publico}} = falso;
{{COM|//...}}
{{PR|fin}}

Ahora nadie puede crear, abrir ni modificar ninguno de los objetos definidos en el sistema. ¿Y los Libros de entrada y salida? ¿Y el Fichero de terceros? Como estos objetos son sólo de consulta, no hay ningún problema en que continúen siendo públicos.

==Definir el rol Usuario del registro==
Lo siguiente que tenemos que hacer es definir un rol para que los usuarios del registro puedan trabajar con el sistema. Este rol debe permitir crear y modificar los objetos que hemos definidos como privados en el paso anterior.

{{PR|tipo}} [Usuario del registro] {{PR|es}} {{RE|rol}}
-{{AT|publico}} = falso;

{{PR|accede}} [Entrada]: crear;
{{PR|accede}} [Salida]: crear;
{{PR|accede}} [Tercero]: crear;
{{PR|fin}}

Como puedes observar, para dar permisos sobre un objeto se realizan declaraciones de la forma '''accede <definicion>: <grado de acceso>'''. Se pueden definir tres grados de acceso:
*'''abrir''': sólo puede abrir los objetos de ese tipo, pero no modificarlo ni crear nuevos. Tampoco puede eliminar.
*'''modificar''': puede abrir los objetos existentes y modificarlos, pero no crear nuevos. Tampoco puede eliminar.
*'''crear''': tiene todos los permisos sobre los objetos de ese tipo. Puede crear, modificar, abrir y eliminar.

Por lo tanto, al rol [Usuario del registro] le hemos dado todos los permisos sobre los objetos [Entrada], [Salida] y [Tercero].
Además, como podrás observar, también indicamos que este rol no es público. ¿Para qué? Desde el egExplorer es posible que un usuario asigne roles a otro usuario. Esto sólo se puede hacer con roles públicos. Haciéndolo privado logramos que este rol sólo se pueda asignar desde el área de administración.
Compilamos y actualizamos. A continuación, [[Cómo_instalar_un_centro_desde_cero#Creación_de_usuarios_en_un_centro|asignamos el rol [Usuario del registro] a nuestro usuario]].
Ya dispones de todos los permisos. Puedes volver a crear entradas, salidas y terceros.

==Definir el rol Usuario de la organización==
En este paso crearemos el rol necesario para que un usuario pueda entrar al sistema para realizar consultas. Para ello, definimos el rol [Usuario de la organización] con el nivel de acceso '''abrir''' sobre los tres tipos de objetos del sistema.

{{PR|tipo}} [Usuario de la organización] {{PR|es}} {{RE|rol}}
{{PR|accede}} [Entrada]: abrir;
{{PR|accede}} [Salida]: abrir;
{{PR|accede}} [Tercero]: abrir;
{{PR|fin}}

No es necesario dar permisos para abrir los libros porque son públicos de forma predeterminada.
Compilamos y actualizamos. A continuación, le quitamos a nuestro usuario el rol [Usuario del registro] y le agregamos el rol de [Usuario de la organización]. En '''egeasy''' la asignación de roles es acumulativa; es decir, que si un usuario tiene asignados dos roles, tiene todos los permisos de los dos roles. Por lo tanto, si no eliminamos el rol de [Usuario del registro] no podremos comprobar los cambios.
Abrimos el egExplorer e intentamos abrir una entrada. El sistema nos muestra la entrada con todos sus datos. Sin embargo, si intentamos modificarlo nos dirá que no disponemos de permisos. Lo mismo ocurre con el resto de objetos (salida y tercero).

'''Objetivo conseguido'''. Nuestro sistema ya permite crear usuarios que puedan trabajar con la Oficina de registro y usuarios que entren sólo para realizar consultas.

==Limitar el acceso a los libros==

Supongamos que deseamos ofrecer la base de datos de terceros para toda la organización, pero que el acceso a los libros esté limitado a los usuarios con el rol [Usuario de la organización] o con el rol [Usuario del registro].

Lo primero que debemos hacer es convertir los libros en privados.

[Libro de entrada] {{PR|es}} {{RE|contenedor}}
-{{AT|publico}} = falso;
{{COM|//...}}
{{PR|es}}

[Libro de salida] {{PR|es}} {{RE|contenedor}}
-{{AT|publico}} = falso;
{{COM|//...}}
{{PR|es}}

A continuación, modificar los roles anteriormente definidos para darles permisos para acceder a los libros.

{{PR|tipo}} [Usuario del registro] {{PR|es}} {{RE|rol}}
-{{AT|publico}} = falso;

{{PR|accede}} [Entrada]: crear;
{{PR|accede}} [Salida]: crear;
{{PR|accede}} [Tercero]: crear;

{{COM|//Agregamos estas declaraciones}}
{{PR|accede}} [Libro de entrada]: abrir;
{{PR|accede}} [Libro de salida]: abrir;
{{PR|fin}}

{{PR|tipo}} [Usuario de la organización] {{PR|es}} {{RE|rol}}
-{{AT|publico}} = falso;

{{PR|accede}} [Entrada]: abrir;
{{PR|accede}} [Salida]: abrir;
{{PR|accede}} [Tercero]: abrir;

{{COM|//Agregamos estas declaraciones}}
{{PR|accede}} [Libro de entrada]: abrir;
{{PR|accede}} [Libro de salida]: abrir;
{{PR|fin}}

Observa que asignamos el nivel de acceso '''abrir''', ya que es el único nivel que tiene sentido para los libros, porque no vamos a modificarlos ni a crear uno nuevo (es un objeto de sistema).
Con estas declaraciones garantizamos que los usuarios con los roles [Usuario del registro] y [Usuario de la organización] puedan continuar accediendo a los libros.
Por último, tenemos que crear un nuevo rol que sólo tenga permisos de lectura sobre el Fichero de terceros.

{{PR|tipo}} [Usuario de consulta de terceros] {{PR|es}} {{RE|rol}}
-{{AT|publico}} = falso;

{{PR|accede}} [Tercero]: abrir;
{{PR|fin}}

Listo. Compila, actualiza y prueba. Cualquier usuario con el rol [Usuario de consulta de terceros] sólo podrá acceder al fichero de terceros en modo lectura.

==Limitar el acceso a la oficina==
Podemos ir un paso más allá definiendo los niveles de acceso a nuestro sistema y plantearnos la siguiente cuestión: Si un usuario sólo tiene permisos para leer la base de terceros, ¿para qué va a acceder a la Oficina del registro? ¿Acaso necesita conocer la existencia de los Libros de entrada y salida si no los puede abrir? Parece que no, ¿verdad? Por lo tanto, vamos a crear una nueva habitación en la que ubicaremos los recursos que sean comunes para toda la organización.

[Oficina de recursos comunes] {{PR|es}} {{RE|habitacion}}
-{{AT|publico}} = falso;

{{PR|ubicado}} [Fichero de terceros]
-{{AT|lugar}} = {{STR|"Ficheros"}};
{{PR|fin}}

Como habrás observado, hemos puesto que la oficina no es pública. Por lo tanto, debemos habilitar algún mecanismo para que los usuarios puedan '''entrar''' a esa habitación. Lo que haremos será crear un nuevo rol que sólo tenga permisos para acceder a la '''Oficina de recursos comunes'''. Después, haremos que el rol de [Usuario de consulta de terceros] herede de él.

{{PR|tipo}} [Usuario de la oficina de recursos comunes] {{PR|es}} {{RE|rol}}
-{{AT|publico}} = falso;

{{PR|accede}} [Oficina de recursos comunes]: entrar;
{{PR|fin}}

{{PR|tipo}} [Usuario de consulta de terceros] {{PR|es}} [Usuario de la oficina de recursos comunes]
-{{AT|publico}} = falso;

{{PR|accede}} [Tercero]: abrir;
{{PR|fin}}

Con esto ya tenemos la nueva oficina y la jerarquía de roles necesaria para acceder a ella. Lo siguiente sería hacer la Oficina del registro privada y modificar el rol de Usuario del registro para que pueda acceder.

[Registro de entrada y salida] {{PR|es}} {{RE|habitacion}}
-{{AT|publico}} = falso;
{{COM|//...}}
{{PR|fin}}

{{PR|tipo}} [Usuario de la oficina del registro] {{PR|es}} {{RE|rol}}
-{{AT|publico}} = falso;

{{PR|accede}} [Registro de entrada y salida]: entrar;
{{PR|fin}}

{{PR|tipo}} [Usuario del registro] {{PR|es}} [Usuario de la oficina del registro]
-{{AT|publico}} = falso;
{{COM|//...}}
{{PR|fin}}

{{PR|tipo}} [Usuario de la organización] {{PR|es}} [Usuario de la oficina del registro]
-{{AT|publico}} = falso;
{{COM|//...}}
{{PR|fin}}

Para aclarar un poco lo que hemos hecho, en la siguiente figura puedes ver la jerarquía final de roles.
[[Image:Tare_f_jerarquia_roles.jpg|center|thumb|300px|No dispones de permisos]]
*'''Usuario de la oficina del registro''': tiene permisos para entrar en la habitación '''Registro de entrada y salida'''
**'''Usuario del registro''': además de poder entrar en el '''Registro de entrada y salida''', puede crear, modificar y eliminar Entradas, Salidas y Terceros.
**[Usuario de la organización]: además de poder entrar en el '''Registro de entrada y salida''', puede consultar los Libros de entrada y salida, y el Fichero de terceros.
*'''Usuario de la oficina de recursos comunes''': tiene permisos para entrar en la habitación '''Oficina de recursos comunes'''.
**'''Usuario de consulta de terceros''': además de poder entrar en el '''Oficina de recursos comunes''', puede consultar el fichero de terceros.

==¿Qué hemos aprendido?==
*Es posible controlar el nivel de acceso a todos los recursos del sistema ([[Contenedores|contenedores]], habitaciones, tareas) mediante el uso de roles. Para controlar el nivel de acceso sobre un recurso, primero hay que hacerlo '''privado''' mediante el uso del atributo {{AT|publico}}.
*Un rol contiene declaraciones de la forma {{PR|accede}} '''<nombre_recurso>: <nivel de acceso>'''.
*Para los [[Contenedores|contenedores]], se pueden definir tres niveles de acceso:
**'''Abrir''': puede abrir el [[Contenedores|contenedor]] en modo de sólo lectura.
**'''Modificar''': puede abrir y modificar el [[Contenedores|contenedor]], pero no crear nuevos ni eliminar.
**'''Crear''': puede crear/eliminar, abrir y modificar [[Contenedores|contenedores]].
*Para permitir el acceso a una {{RE|habitacion}} con el atributo {{AT|publico}} puesto a falso, se utiliza el nivel de acceso '''entrar'''.

==Siguiente tarea==
:*[[Tarea_G:_Evitando_la_repliación_de_código|Tarea G: Evitando la repliación de código]]

==Véase también==
:*[[Tarea_A:_Libros_y_registro_de_entrada_y_salida|Tarea A: Libros y registro de entrada y salida]]
:*[[Tarea_B:_Mejorando_la_numeración_del_registro|Tarea B: Mejorando la numeración del registro]]
:*[[Tarea_C:_Evolucionando_la_arquitectura_del_registro|Tarea C: Evolucionando la introducción de datos]]
:*[[Tarea_D:_Validar_la_introducción_de_datos|Tarea D: Validar la introducción de datos]]
:*[[Tarea_E:_Utilizar_el_registro_como_un_almacén_de_documentación|Tarea E: Utilizar el registro como un almacén de documentación]]
:*[[Tarea_H:_Emitir_certificados_de_documentación|Tarea H: Emitir certificados de documentación]]
:*[[Tarea_I:_Creando_una_oficina_sin_papeles|Tarea I: Creando una oficina sin papeles]]
:*[[Tarea_J:_Importar_la_base_de_datos_de_terceros_de_otra_aplicación|Tarea J: Importar la base de datos de terceros de otra aplicación]]

Tarea F: Abriendo el registro al resto de las oficinas

2009-08-04T09:53:34Z

Imhernandez: /* Definir el rol Usuario del registro */

[[Construir_una_aplicación_paso_a_paso|Construir una aplicación paso a paso]]

En esta tarea modificaremos el sistema para permitir que usuarios de otros departamentos puedan acceder a la oficina del registro para consultar datos de la base de terceros y del registro. Para garantizar que el acceso es sólo de lectura, de forma que no puedan modificar ninguna información del registro, limitaremos sus permisos.

Para garantizar estos requisitos introduciremos el uso de los roles y cambiaremos los objetos actuales del sistema para que sean privados.

==¿Qué es un rol?==
En todas los sistemas de información existe la necesidad de limitar el acceso de los usuarios a los distintos elementos del sistema. Para lograr este objetivo, ODL proporciona un tipo de '''recurso''': los roles.

Mediante los roles, es posible asignar tres tipos de permisos:
*El grado de acceso a los diferentes objetos del sistema (creación, modificación o sólo acceso).
*Las tareas del ''workflow'' que un determinado perfil puede realizar.
*Los escritos que puede firmar.

En tu sistema, debes crear tantos tipos de roles como perfiles de acceso diferentes existan en la organización.
En nuestro ejemplo del registro de entrada y salida, vamos a definir dos perfiles:
*'''Personal del registro''': identifica a todos aquellos usuarios que pertenecen al registro de entrada y salida y tienen permisos para modificar todos sus elementos.
*'''Personal externo''': identifica a todos aquellos usuarios de otros departamentos que acceden al registro para consultar datos, pero que no tienen capacidad para modificar ningún elemento.

==Convertir las definiciones en privadas==
Hasta ahora, hemos trabajado sin preocuparnos de los roles y no hemos tenido ningún problema para acceder a la habitación, ni para crear entradas o salidas. ¿Por qué? Por defecto, en ODL todos los objetos que se definen son '''públicos'''. Esto significa que cualquiera puede crearlos o modificarlos.
Lo primero que debemos hacer es cambiar las definiciones para hacer los objetos privados. ¿Cómo? Poniendo el atributo {{{A|publico}}} a {{{T|falso}}} al comienzo de cada definición.

{{PR|tipo}} [Entrada] {{PR|es}} {{RE|contenedor}}
-{{AT|publico}} = falso;
{{COM|//...}}
{{PR|fin}}

Compila y actualiza. Abre el egExplorer e intenta crear una Entrada. Te saldrá un mensaje diciendo que no tienes permisos para crear entradas.
[[Image:No_tiene_permisos.jpg|center|thumb|300px|No dispones de permisos]]

Hacemos lo mismo con las Salidas.

{{PR|tipo}} [Salida] {{PR|es}} {{RE|contenedor}}
-{{AT|publico}} = falso;
{{COM|//...}}
{{PR|fin}}

Y con las fichas de Tercero.

{{PR|tipo}} [Tercero] {{PR|es}} {{RE|contenedor}}
-{{AT|publico}} = falso;
{{COM|//...}}
{{PR|fin}}

Ahora nadie puede crear, abrir ni modificar ninguno de los objetos definidos en el sistema. ¿Y los Libros de entrada y salida? ¿Y el Fichero de terceros? Como estos objetos son sólo de consulta, no hay ningún problema en que continúen siendo públicos.

==Definir el rol Usuario del registro==
Lo siguiente que tenemos que hacer es definir un rol para que los usuarios del registro puedan trabajar con el sistema. Este rol debe permitir crear y modificar los objetos que hemos definidos como privados en el paso anterior.

{{PR|tipo}} [Usuario del registro] {{PR|es}} {{RE|rol}}
-{{AT|publico}} = falso;

{{PR|accede}} [Entrada]: crear;
{{PR|accede}} [Salida]: crear;
{{PR|accede}} [Tercero]: crear;
{{PR|fin}}

Como puedes observar, para dar permisos sobre un objeto se realizan declaraciones de la forma '''accede <definicion>: <grado de acceso>'''. Se pueden definir tres grados de acceso:
*'''abrir''': sólo puede abrir los objetos de ese tipo, pero no modificarlo ni crear nuevos. Tampoco puede eliminar.
*'''modificar''': puede abrir los objetos existentes y modificarlos, pero no crear nuevos. Tampoco puede eliminar.
*'''crear''': tiene todos los permisos sobre los objetos de ese tipo. Puede crear, modificar, abrir y eliminar.

Por lo tanto, al rol [Usuario del registro] le hemos dado todos los permisos sobre los objetos [Entrada], [Salida] y [Tercero].
Además, como podrás observar, también indicamos que este rol no es público. ¿Para qué? Desde el egExplorer es posible que un usuario asigne roles a otro usuario. Esto sólo se puede hacer con roles públicos. Haciéndolo privado logramos que este rol sólo se pueda asignar desde el área de administración.
Compilamos y actualizamos. A continuación, [[Cómo_instalar_un_centro_desde_cero#Creación_de_usuarios_en_un_centro|asignamos el rol [Usuario del registro] a nuestro usuario]].
Ya dispones de todos los permisos. Puedes volver a crear entradas, salidas y terceros.

==Definir el rol Usuario de la organización==
En este paso crearemos el rol necesario para que un usuario pueda entrar al sistema para realizar consultas. Para ello, definimos el rol [Usuario de la organización] con el nivel de acceso '''abrir''' sobre los tres tipos de objetos del sistema.

{{PR|tipo}} [Usuario de la organización] {{PR|es}} {{RE|rol}}
{{PR|accede}} [Entrada]: abrir;
{{PR|accede}} [Salida]: abrir;
{{PR|accede}} [Tercero]: abrir;
{{PR|fin}}

No es necesario dar permisos para abrir los libros porque son públicos de forma predeterminada.
Compilamos y actualizamos. A continuación, le quitamos a nuestro usuario el rol [Usuario del registro] y le agregamos el rol de [Usuario de la organización]. En '''egeasy''' la asignación de roles es acumulativa; es decir, que si un usuario tiene asignados dos roles, tiene todos los permisos de los dos roles. Por lo tanto, si no eliminamos el rol de [Usuario del registro] no podremos comprobar los cambios.
Abrimos el egExplorer e intentamos abrir una entrada. El sistema nos muestra la entrada con todos sus datos. Sin embargo, si intentamos modificarlo nos dirá que no disponemos de permisos. Lo mismo ocurre con el resto de objetos (salida y tercero).

'''Objetivo conseguido'''. Nuestro sistema ya permite crear usuarios que puedan trabajar con la Oficina de registro y usuarios que entren sólo para realizar consultas.

==Limitar el acceso a los libros==

Supongamos que deseamos ofrecer la base de datos de terceros para toda la organización, pero que el acceso a los libros esté limitado a los usuarios con el rol [Usuario de la organización] o con el rol [Usuario del registro].

Lo primero que debemos hacer es convertir los libros en privados.

[Libro de entrada] {{PR|es}} {{RE|contenedor}}
-{{AT|publico}} = falso;
{{COM|//...}}
{{PR|es}}

[Libro de salida] {{PR|es}} {{RE|contenedor}}
-{{AT|publico}} = falso;
{{COM|//...}}
{{PR|es}}

A continuación, modificar los roles anteriormente definidos para darles permisos para acceder a los libros.

{{PR|tipo}} [Usuario del registro] {{PR|es}} {{RE|rol}}
-{{AT|publico}} = falso;

{{PR|accede}} [Entrada]: crear;
{{PR|accede}} [Salida]: crear;
{{PR|accede}} [Tercero]: crear;

{{COM|//Agregamos estas declaraciones}}
{{PR|accede}} [Libro de entrada]: abrir;
{{PR|accede}} [Libro de salida]: abrir;
{{PR|fin}}

{{PR|tipo}} [Usuario de la organización] {{PR|es}} {{RE|rol}}
-{{AT|publico}} = falso;

{{PR|accede}} [Entrada]: abrir;
{{PR|accede}} [Salida]: abrir;
{{PR|accede}} [Tercero]: abrir;

{{COM|//Agregamos estas declaraciones}}
{{PR|accede}} [Libro de entrada]: abrir;
{{PR|accede}} [Libro de salida]: abrir;
{{PR|fin}}

Observa que asignamos el nivel de acceso '''abrir''', ya que es el único nivel que tiene sentido para los libros, porque no vamos a modificarlos ni a crear uno nuevo (es un objeto de sistema).
Con estas declaraciones garantizamos que los usuarios con los roles [Usuario del registro] y [Usuario de la organización] puedan continuar accediendo a los libros.
Por último, tenemos que crear un nuevo rol que sólo tenga permisos de lectura sobre el Fichero de terceros.

{{PR|tipo}} [Usuario de consulta de terceros] {{PR|es}} {{RE|rol}}
-{{AT|publico}} = falso;

{{PR|accede}} [Tercero]: abrir;
{{PR|fin}}

Listo. Compila, actualiza y prueba. Cualquier usuario con el rol [Usuario de consulta de terceros] sólo podrá acceder al fichero de terceros en modo lectura.

==Limitar el acceso a la oficina==
Podemos ir un paso más allá definiendo los niveles de acceso a nuestro sistema y plantearnos la siguiente cuestión: Si un usuario sólo tiene permisos para leer la base de terceros, ¿para qué va a acceder a la Oficina del registro? ¿Acaso necesita conocer la existencia de los Libros de entrada y salida si no los puede abrir? Parece que no, ¿verdad? Por lo tanto, vamos a crear una nueva habitación en la que ubicaremos los recursos que sean comunes para toda la organización.

[Oficina de recursos comunes] {{PR|es}} {{RE|habitacion}}
-{{AT|publico}} = falso;

{{PR|ubicado}} [Fichero de terceros]
-{{AT|lugar}} = {{STR|"Ficheros"}};
{{PR|fin}}

Como habrás observado, hemos puesto que la oficina no es pública. Por lo tanto, debemos habilitar algún mecanismo para que los usuarios puedan '''entrar''' a esa habitación. Lo que haremos será crear un nuevo rol que sólo tenga permisos para acceder a la '''Oficina de recursos comunes'''. Después, haremos que el rol de [Usuario de consulta de terceros] herede de él.

{{PR|tipo}} [Usuario de la oficina de recursos comunes] {{PR|es}} {{RE|rol}}
-{{AT|publico}} = falso;

{{PR|accede}} [Oficina de recursos comunes]: entrar;
{{PR|fin}}

{{PR|tipo}} [Usuario de consulta de terceros] {{PR|es}} [Usuario de la oficina de recursos comunes]
-{{AT|publico}} = falso;

{{PR|accede}} [Tercero]: abrir;
{{PR|fin}}

Con esto ya tenemos la nueva oficina y la jerarquía de roles necesaria para acceder a ella. Lo siguiente sería hacer la Oficina del registro privada y modificar el rol de Usuario del registro para que pueda acceder.

[Registro de entrada y salida] {{PR|es}} {{RE|habitacion}}
-{{AT|publico}} = falso;
{{COM|//...}}
{{PR|fin}}

{{PR|tipo}} [Usuario de la oficina del registro] {{PR|es}} {{RE|rol}}
-{{AT|publico}} = falso;

{{PR|accede}} [Registro de entrada y salida]: entrar;
{{PR|fin}}

{{PR|tipo}} [Usuario del registro] {{PR|es}} [Usuario de la oficina del registro]
-{{AT|publico}} = falso;
{{COM|//...}}
{{PR|fin}}

{{PR|tipo}} [Usuario de la organización] {{PR|es}} [Usuario de la oficina del registro]
-{{AT|publico}} = falso;
{{COM|//...}}
{{PR|fin}}

Para aclarar un poco lo que hemos hecho, en la siguiente figura puedes ver la jerarquía final de roles.
[[Image:Tare_f_jerarquia_roles.jpg|center|thumb|300px|No dispones de permisos]]
*'''Usuario de la oficina del registro''': tiene permisos para entrar en la habitación '''Registro de entrada y salida'''
**'''Usuario del registro''': además de poder entrar en el '''Registro de entrada y salida''', puede crear, modificar y eliminar Entradas, Salidas y Terceros.
**[Usuario de la organización]: además de poder entrar en el '''Registro de entrada y salida''', puede consultar los Libros de entrada y salida, y el Fichero de terceros.
*'''Usuario de la oficina de recursos comunes''': tiene permisos para entrar en la habitación '''Oficina de recursos comunes'''.
**'''Usuario de consulta de terceros''': además de poder entrar en el '''Oficina de recursos comunes'''.

==¿Qué hemos aprendido?==
*Es posible controlar el nivel de acceso a todos los recursos del sistema ([[Contenedores|contenedores]], habitaciones, tareas) mediante el uso de roles. Para controlar el nivel de acceso sobre un recurso, primero hay que hacerlo '''privado''' mediante el uso del atributo {{AT|publico}}.
*Un rol contiene declaraciones de la forma {{PR|accede}} '''<nombre_recurso>: <nivel de acceso>'''.
*Para los [[Contenedores|contenedores]], se pueden definir tres niveles de acceso:
**'''Abrir''': puede abrir el [[Contenedores|contenedor]] en modo de sólo lectura.
**'''Modificar''': puede abrir y modificar el [[Contenedores|contenedor]], pero no crear nuevos ni eliminar.
**'''Crear''': puede crear/eliminar, abrir y modificar [[Contenedores|contenedores]].
*Para permitir el acceso a una {{RE|habitacion}} con el atributo {{AT|publico}} puesto a falso, se utiliza el nivel de acceso '''entrar'''.

==Siguiente tarea==
:*[[Tarea_G:_Evitando_la_repliación_de_código|Tarea G: Evitando la repliación de código]]

==Véase también==
:*[[Tarea_A:_Libros_y_registro_de_entrada_y_salida|Tarea A: Libros y registro de entrada y salida]]
:*[[Tarea_B:_Mejorando_la_numeración_del_registro|Tarea B: Mejorando la numeración del registro]]
:*[[Tarea_C:_Evolucionando_la_arquitectura_del_registro|Tarea C: Evolucionando la introducción de datos]]
:*[[Tarea_D:_Validar_la_introducción_de_datos|Tarea D: Validar la introducción de datos]]
:*[[Tarea_E:_Utilizar_el_registro_como_un_almacén_de_documentación|Tarea E: Utilizar el registro como un almacén de documentación]]
:*[[Tarea_H:_Emitir_certificados_de_documentación|Tarea H: Emitir certificados de documentación]]
:*[[Tarea_I:_Creando_una_oficina_sin_papeles|Tarea I: Creando una oficina sin papeles]]
:*[[Tarea_J:_Importar_la_base_de_datos_de_terceros_de_otra_aplicación|Tarea J: Importar la base de datos de terceros de otra aplicación]]

Tarea E: Utilizar el registro como un almacén de documentación

2009-08-04T09:46:28Z

Imhernandez: /* ¿Qué hemos aprendido? */

[[Construir_una_aplicación_paso_a_paso|Construir una aplicación paso a paso]]

Es muy habitual en la Administración Pública tener que presentar una fotocopia del DNI siempre que deseamos iniciar un trámite administrativo. Y siempre nos ha parecido absurdo (desde el punto de vista del administrado) tener que presentar una y otra vez la misma documentación.

Siendo conscientes de este problema, el '''Registro de entrada y salida''' ha decidido proporcionar un servicio al resto de los departamentos para conocer cuál es la documentación que una persona ha presentado durante toda la vida del registro, de modo que si ya ha presentado un documento no tenga que volver a hacerlo.

Para cubrir este requisito haremos uso de dos nuevos conceptos de ODL:
:*La operación {{RE|exportacion}}
:*El componente {{T|catalogo}}

Como vimos en la [[:Tarea_A:_Libros_y_registro_de_entrada_y_salida|Tarea A]], la plataforma egEasy utiliza una arquitectura de base de datos orientada a objetos. Con este esquema, no podemos hacer una sentencia contra la base de datos para conocer todos los documentos presentados en todas las entradas, ya que los objetos se encuentran serializados.

También vimos que una {{T|coleccion}} nos permite deserializar los objetos, pero no nos sirve para este caso: el objetivo de la {{T|coleccion}} es mostrar una lista de objetos y ahora lo que queremos es obtener una lista de los documentos presentados, que actualmente se encuentran en las filas de la tabla de '''Documentación presentada'''. En su lugar, utilizaremos una {{RE|exportacion}}.

==¿Qué es una exportación?==
Una {{RE|exportacion}} es una operación que se ejecuta cuando un [[Contenedores|contenedor]] se almacena. Cuando este evento se produce, se rellena la tabla de la exportación con los datos indicados en su definición. Veamos un ejemplo.

[Exportación de entradas] {{PR|es}} {{RE|exportacion}}
-{{AT|nombre_tabla}} = {{STR|"TR$ENTRADAS"}};
-{{AT|universo}} = [Entrada]; 
{{PR|columna}} [Remitente]
-{{AT|columna_bd}}.{{AT|nombre}} = {{STR|"REMITENTE"}};
-{{AT|columna_bd}}.{{AT|tipo}} = vinculo;
-{{AT|origen}} = [Datos generales].[Remitente];
{{PR|columna}} [Fecha de presentación]
-{{AT|columna_bd}}.{{AT|nombre}} = {{STR|"FECHA_PRESENTACION"}};
-{{AT|origen}} = [Datos generales].[Fecha];
{{PR|columna}} [Documento]
-{{AT|columna_bd}}.{{AT|nombre}} = {{STR|"TR$ENTRADAS#DOCUMENTOS.NOMBRE"}};
-{{AT|origen}} = [Datos generales].[Documentación presentada].[Documento];
{{PR|fin}}

Al igual que en la definición de una colección, en el atributo {{AT|nombre_tabla}} indicamos la tabla de la base de datos a la que se exportarán los datos.

En el atributo {{AT|universo}} especificamos sobre qué definición de {{RE|contenedor}} se ejecuta la {{RE|exportacion}}. Al poner '''Entrada''', estamos diciendo que la {{RE|exportacion}} debe ejecutarse siempre que una '''Entrada''' se almacena.

A continuación, indicamos los datos que deseamos exportar de forma similar a como hicimos para las colecciones. En este caso, la diferencia la encontramos en la definición de la columna '''Documento'''. En el atributo {{AT|columna_bd.nombre}}, en vez de poner un nombre para la columna, hemos puesto '''TR$ENTRADAS#DOCUMENTOS.NOMBRE'''. ¿Por qué? Si creásemos una fila en la tabla '''TR$ENTRADAS''' por cada documento que hubiese en una entrada, estaríamos repitiendo el resto de los datos que exportásemos y, además, estaríamos desvirtuando la tabla, ya que cada fila no representaría una entrada, sino datos de una entrada mezclados con datos del documento. Para evitar esto, creamos una nueva tabla ('''TR$ENTRADAS#DOCUMENTOS''') y, en esa tabla, almacenamos el documento presentado en la columna '''NOMBRE'''.

Al actualizar, la plataforma entiende la definición y, automáticamente, asocia la tabla '''TR$ENTRADAS''' con la tabla '''TR$ENTRADAS#DOCUMENTOS'''. Además, cuando se guarde una entrada, exportará la fecha a la columna '''FECHA_PRESENTACION''' y creará una fila en la tabla '''TR$ENTRADAS#DOCUMENTOS''' por cada documento que figure en la tabla '''Documentación presentada''', cumplimentando la columna '''NOMBRE''' con el valor del campo '''Documento'''.

==Ciclo de eventos de un contenedor==
Con las exportaciones, cerramos el ciclo de eventos que se producen al guardar un [[Contenedores|contenedor]]:
:*Primero se comprueban las validaciones (si las hubiera).
:*Después, se almacena el [[Contenedores|contenedor]].
:*A continuación, se rellenan las tablas de {{T|coleccion}}.
:*Por último, se ejecutan las exportaciones definidas sobre el [[Contenedores|contenedor]] (si las hubiera).

==Crear un catálogo como "Registro de documentación"==
Una vez definida la {{RE|exportacion}}, tenemos que mostrar la lista de documentos a los usuarios del registro. Para ello crearemos un nuevo objeto de sistema:

[Registro de documentación] {{PR|es}} {{RE|contenedor}}
[Documentación] {{PR|es}} {{T|catalogo}}
-{{AT|sentencia}} = {{STR|"SELECT ENTRADAS.RRC, ENTRADAS.DRC, ENTRADAS.NAME, ENTRADAS.REMITENTE AS ""Remitente"",}}
{{STR|ENTRADAS.FECHA_PRESENTACION AS ""Fecha de presentación"",}}
{{STR|DOCUMENTOS.NOMBRE AS ""Documento"" FROM TR$ENTRADAS ENTRADAS,}}
'''TR$ENTRADAS#DOCUMENTOS DOCUMENTOS WHERE ENTRADAS.RRC = DOCUMENTOS.RRC"''';
{{PR|fin}}
{{PR|fin}}

En el código anterior, definimos un {{RE|contenedor}}, '''Registro de documentación''', y dentro definimos la componente '''Documentación''' de tipo {{T|catalogo}}. Un {{T|catalogo}} sirve para mostrar una lista de objetos. La diferencia con la {{T|coleccion}} radica en que en un {{T|catalogo}} sólo se muestran objetos, pero no se pueden crear nuevos [[Contenedores|contenedores]].

Normalmente, para este tipo de componente definimos un solo atributo: {{AT|sentencia}}. A este atributo se le asigna una cadena de texto con la sentencia SQL que se ejecutará cuando el usuario de la aplicación abra el {{T|catalogo}}. En la sentencia del ejemplo, recuperamos las tres columnas que definimos en la exportación haciendo un ''join'' de la tabla '''TR$ENTRADAS''' con la tabla '''TR$ENTRADAS#DOCUMENTOS''' mediante la columna RRC.

¿Qué es la columna RRC?

==Valores de un recurso. RRC, DRC y NAME==
En la plataforma egEasy, cualquier recurso, siempre que figure en una tabla de la base de datos, aparecerá con tres valores:
:*'''RRC''': es un valor entero que actúa como identificador único del recurso en el sistema.
:*'''DRC''': es un valor entero que proporciona el identificador de la definición del recurso (por ejemplo, cuando se almacene una '''Entrada''' esta columna contendrá un número que nos dirá que el objeto almacenado es de tipo '''Entrada''').
:*'''NAME''': propiedad Nombre del recurso. Todos los recursos, cuando se crean, inicializan esta propiedad con el nombre de la definición a la que pertenecen (por ejemplo, para una '''Entrada''' esta columna almacenará el texto “Entrada”).
Por lo tanto, en la cláusula WHERE de la sentencia indicamos que haga un ''join'' entre una entrada y los documentos de esa entrada.

También observarás que al comienzo de la sentencia seleccionamos las columnas RRC, DRC y NAME. De esta forma, cuando se ejecute la sentencia, la plataforma entenderá que estamos recuperando una lista de objetos y no una simple lista de datos, de modo que podremos abrir las '''Entradas''' asociadas a los documentos.

==Ubicar el "Registro de documentación"==
Por último, antes de comprobar cómo funciona, debemos ubicarlo en la habitación. En esta ocasión lo ubicaremos en '''Catálogos'''.

[Registro de entrada y salida] {{PR|es}} {{RE|habitacion}}
{{PR|ubicado}} [Fichero de terceros]
-{{AT|lugar}} = {{STR|"Ficheros"}};
{{PR|ubicado}} [Libro de entrada]
-{{AT|lugar}} = {{STR|"Libros"}};
{{PR|ubicado}} [Libro de salida]
-{{AT|lugar}} = {{STR|"Libros"}};
{{PR|ubicado}} [Registro de documentación]
-{{AT|lugar}} = {{STR|"Catálogos"}};
{{PR|fin}}

Compila y actualiza. Crea una nueva entrada, introduce documentos y guárdala. A continuación, abre el '''Registro de documentación'''. Verás algo parecido a la siguiente figura.

<center>
{|
|align="center" |[[Imagen:Figura 16.jpg|thumb|250px|Registro de documentación]]
|}
</center>

Se mostrará una lista mostrando el Remitente, la fecha en la que presentó el documento y la denominación del documento. Si haces doble clic en cualquiera de las filas, se abrirá la entrada en la que se presentó el documento. Esta asociación automática entre el documento y la entrada es lo que conseguimos al incluir las columnas RRC, DRC y NAME en la sentencia del catálogo.

==¿Qué hemos aprendido?==
:*La operación {{RE|exportacion}} nos permite desglosar los datos almacenados en un {{RE|contenedor}}.
:*Para desglosar una tabla en una {{RE|exportacion}}, en el atributo {{AT|columna_bd.nombre}} debemos poner la ruta completa de la tabla y la columna (TR$ENTRADAS#DOCUMENTOS.NOMBRE).
:*El ciclo de eventos al almacenar un [[Contenedores|contenedor]] es: Validación -> Almacenamiento -> Colección -> Exportación.
:*Un {{T|catalogo}} permite recuperar una lista de objetos lanzando una sentencia SQL contra la base de datos.
:*El RRC es el identificador único de un recurso dentro del sistema y el DRC es el identificador de su definición.

==Siguiente tarea==

:*[[Tarea_F:_Abriendo_el_registro_al_resto_de_las_oficinas|Tarea F: Abriendo el registro al resto de las oficinas]]

==Véase también==

:*[[Tarea_A:_Libros_y_registro_de_entrada_y_salida|Tarea A: Libros y registro de entrada y salida]]
:*[[Tarea_B:_Mejorando_la_numeración_del_registro|Tarea B: Mejorando la numeración del registro]]
:*[[Tarea_C:_Evolucionando_la_arquitectura_del_registro|Tarea C: Evolucionando la introducción de datos]]
:*[[Tarea_D:_Validar_la_introducción_de_datos|Tarea D: Validar la introducción de datos]]
:*[[Tarea_G:_Evitando_la_repliación_de_código|Tarea G: Evitando la repliación de código]]
:*[[Tarea_H:_Emitir_certificados_de_documentación|Tarea H: Emitir certificados de documentación]]
:*[[Tarea_I:_Creando_una_oficina_sin_papeles|Tarea I: Creando una oficina sin papeles]]
:*[[Tarea_J:_Importar_la_base_de_datos_de_terceros_de_otra_aplicación|Tarea J: Importar la base de datos de terceros de otra aplicación]]

Tarea E: Utilizar el registro como un almacén de documentación

2009-08-04T09:40:45Z

Imhernandez: /* Ubicar el "Registro de documentación" */

[[Construir_una_aplicación_paso_a_paso|Construir una aplicación paso a paso]]

Es muy habitual en la Administración Pública tener que presentar una fotocopia del DNI siempre que deseamos iniciar un trámite administrativo. Y siempre nos ha parecido absurdo (desde el punto de vista del administrado) tener que presentar una y otra vez la misma documentación.

Siendo conscientes de este problema, el '''Registro de entrada y salida''' ha decidido proporcionar un servicio al resto de los departamentos para conocer cuál es la documentación que una persona ha presentado durante toda la vida del registro, de modo que si ya ha presentado un documento no tenga que volver a hacerlo.

Para cubrir este requisito haremos uso de dos nuevos conceptos de ODL:
:*La operación {{RE|exportacion}}
:*El componente {{T|catalogo}}

Como vimos en la [[:Tarea_A:_Libros_y_registro_de_entrada_y_salida|Tarea A]], la plataforma egEasy utiliza una arquitectura de base de datos orientada a objetos. Con este esquema, no podemos hacer una sentencia contra la base de datos para conocer todos los documentos presentados en todas las entradas, ya que los objetos se encuentran serializados.

También vimos que una {{T|coleccion}} nos permite deserializar los objetos, pero no nos sirve para este caso: el objetivo de la {{T|coleccion}} es mostrar una lista de objetos y ahora lo que queremos es obtener una lista de los documentos presentados, que actualmente se encuentran en las filas de la tabla de '''Documentación presentada'''. En su lugar, utilizaremos una {{RE|exportacion}}.

==¿Qué es una exportación?==
Una {{RE|exportacion}} es una operación que se ejecuta cuando un [[Contenedores|contenedor]] se almacena. Cuando este evento se produce, se rellena la tabla de la exportación con los datos indicados en su definición. Veamos un ejemplo.

[Exportación de entradas] {{PR|es}} {{RE|exportacion}}
-{{AT|nombre_tabla}} = {{STR|"TR$ENTRADAS"}};
-{{AT|universo}} = [Entrada]; 
{{PR|columna}} [Remitente]
-{{AT|columna_bd}}.{{AT|nombre}} = {{STR|"REMITENTE"}};
-{{AT|columna_bd}}.{{AT|tipo}} = vinculo;
-{{AT|origen}} = [Datos generales].[Remitente];
{{PR|columna}} [Fecha de presentación]
-{{AT|columna_bd}}.{{AT|nombre}} = {{STR|"FECHA_PRESENTACION"}};
-{{AT|origen}} = [Datos generales].[Fecha];
{{PR|columna}} [Documento]
-{{AT|columna_bd}}.{{AT|nombre}} = {{STR|"TR$ENTRADAS#DOCUMENTOS.NOMBRE"}};
-{{AT|origen}} = [Datos generales].[Documentación presentada].[Documento];
{{PR|fin}}

Al igual que en la definición de una colección, en el atributo {{AT|nombre_tabla}} indicamos la tabla de la base de datos a la que se exportarán los datos.

En el atributo {{AT|universo}} especificamos sobre qué definición de {{RE|contenedor}} se ejecuta la {{RE|exportacion}}. Al poner '''Entrada''', estamos diciendo que la {{RE|exportacion}} debe ejecutarse siempre que una '''Entrada''' se almacena.

A continuación, indicamos los datos que deseamos exportar de forma similar a como hicimos para las colecciones. En este caso, la diferencia la encontramos en la definición de la columna '''Documento'''. En el atributo {{AT|columna_bd.nombre}}, en vez de poner un nombre para la columna, hemos puesto '''TR$ENTRADAS#DOCUMENTOS.NOMBRE'''. ¿Por qué? Si creásemos una fila en la tabla '''TR$ENTRADAS''' por cada documento que hubiese en una entrada, estaríamos repitiendo el resto de los datos que exportásemos y, además, estaríamos desvirtuando la tabla, ya que cada fila no representaría una entrada, sino datos de una entrada mezclados con datos del documento. Para evitar esto, creamos una nueva tabla ('''TR$ENTRADAS#DOCUMENTOS''') y, en esa tabla, almacenamos el documento presentado en la columna '''NOMBRE'''.

Al actualizar, la plataforma entiende la definición y, automáticamente, asocia la tabla '''TR$ENTRADAS''' con la tabla '''TR$ENTRADAS#DOCUMENTOS'''. Además, cuando se guarde una entrada, exportará la fecha a la columna '''FECHA_PRESENTACION''' y creará una fila en la tabla '''TR$ENTRADAS#DOCUMENTOS''' por cada documento que figure en la tabla '''Documentación presentada''', cumplimentando la columna '''NOMBRE''' con el valor del campo '''Documento'''.

==Ciclo de eventos de un contenedor==
Con las exportaciones, cerramos el ciclo de eventos que se producen al guardar un [[Contenedores|contenedor]]:
:*Primero se comprueban las validaciones (si las hubiera).
:*Después, se almacena el [[Contenedores|contenedor]].
:*A continuación, se rellenan las tablas de {{T|coleccion}}.
:*Por último, se ejecutan las exportaciones definidas sobre el [[Contenedores|contenedor]] (si las hubiera).

==Crear un catálogo como "Registro de documentación"==
Una vez definida la {{RE|exportacion}}, tenemos que mostrar la lista de documentos a los usuarios del registro. Para ello crearemos un nuevo objeto de sistema:

[Registro de documentación] {{PR|es}} {{RE|contenedor}}
[Documentación] {{PR|es}} {{T|catalogo}}
-{{AT|sentencia}} = {{STR|"SELECT ENTRADAS.RRC, ENTRADAS.DRC, ENTRADAS.NAME, ENTRADAS.REMITENTE AS ""Remitente"",}}
{{STR|ENTRADAS.FECHA_PRESENTACION AS ""Fecha de presentación"",}}
{{STR|DOCUMENTOS.NOMBRE AS ""Documento"" FROM TR$ENTRADAS ENTRADAS,}}
'''TR$ENTRADAS#DOCUMENTOS DOCUMENTOS WHERE ENTRADAS.RRC = DOCUMENTOS.RRC"''';
{{PR|fin}}
{{PR|fin}}

En el código anterior, definimos un {{RE|contenedor}}, '''Registro de documentación''', y dentro definimos la componente '''Documentación''' de tipo {{T|catalogo}}. Un {{T|catalogo}} sirve para mostrar una lista de objetos. La diferencia con la {{T|coleccion}} radica en que en un {{T|catalogo}} sólo se muestran objetos, pero no se pueden crear nuevos [[Contenedores|contenedores]].

Normalmente, para este tipo de componente definimos un solo atributo: {{AT|sentencia}}. A este atributo se le asigna una cadena de texto con la sentencia SQL que se ejecutará cuando el usuario de la aplicación abra el {{T|catalogo}}. En la sentencia del ejemplo, recuperamos las tres columnas que definimos en la exportación haciendo un ''join'' de la tabla '''TR$ENTRADAS''' con la tabla '''TR$ENTRADAS#DOCUMENTOS''' mediante la columna RRC.

¿Qué es la columna RRC?

==Valores de un recurso. RRC, DRC y NAME==
En la plataforma egEasy, cualquier recurso, siempre que figure en una tabla de la base de datos, aparecerá con tres valores:
:*'''RRC''': es un valor entero que actúa como identificador único del recurso en el sistema.
:*'''DRC''': es un valor entero que proporciona el identificador de la definición del recurso (por ejemplo, cuando se almacene una '''Entrada''' esta columna contendrá un número que nos dirá que el objeto almacenado es de tipo '''Entrada''').
:*'''NAME''': propiedad Nombre del recurso. Todos los recursos, cuando se crean, inicializan esta propiedad con el nombre de la definición a la que pertenecen (por ejemplo, para una '''Entrada''' esta columna almacenará el texto “Entrada”).
Por lo tanto, en la cláusula WHERE de la sentencia indicamos que haga un ''join'' entre una entrada y los documentos de esa entrada.

También observarás que al comienzo de la sentencia seleccionamos las columnas RRC, DRC y NAME. De esta forma, cuando se ejecute la sentencia, la plataforma entenderá que estamos recuperando una lista de objetos y no una simple lista de datos, de modo que podremos abrir las '''Entradas''' asociadas a los documentos.

==Ubicar el "Registro de documentación"==
Por último, antes de comprobar cómo funciona, debemos ubicarlo en la habitación. En esta ocasión lo ubicaremos en '''Catálogos'''.

[Registro de entrada y salida] {{PR|es}} {{RE|habitacion}}
{{PR|ubicado}} [Fichero de terceros]
-{{AT|lugar}} = {{STR|"Ficheros"}};
{{PR|ubicado}} [Libro de entrada]
-{{AT|lugar}} = {{STR|"Libros"}};
{{PR|ubicado}} [Libro de salida]
-{{AT|lugar}} = {{STR|"Libros"}};
{{PR|ubicado}} [Registro de documentación]
-{{AT|lugar}} = {{STR|"Catálogos"}};
{{PR|fin}}

Compila y actualiza. Crea una nueva entrada, introduce documentos y guárdala. A continuación, abre el '''Registro de documentación'''. Verás algo parecido a la siguiente figura.

<center>
{|
|align="center" |[[Imagen:Figura 16.jpg|thumb|250px|Registro de documentación]]
|}
</center>

Se mostrará una lista mostrando el Remitente, la fecha en la que presentó el documento y la denominación del documento. Si haces doble clic en cualquiera de las filas, se abrirá la entrada en la que se presentó el documento. Esta asociación automática entre el documento y la entrada es lo que conseguimos al incluir las columnas RRC, DRC y NAME en la sentencia del catálogo.

==¿Qué hemos aprendido?==
:*La operación {{RE|exportacion}} nos permite desglosar los datos almacenados en un {{RE|contenedor}}.
:*Para desglosar una tabla en una {{RE|exportacion}}, en el atributo {{AT|columna_bd.nombre}} debemos poner la ruta completa de la tabla y la columna (TR$ENTRADAS#DOCUMENTOS.NOMBRE).
:*El ciclo de eventos al almacenar un [[Contenedores|contenedor]] es: Validación -> Almacenamiento -> Colección -> Exportación.
:*Un {{T|catalogo}} permite recuperar una lista de objetos lanzando una sentencia SQL contra la base de datos.
:*El RRC es el identificador único de un recurso dentro del sistema y el DRC el identificador de su definición.

==Siguiente tarea==

:*[[Tarea_F:_Abriendo_el_registro_al_resto_de_las_oficinas|Tarea F: Abriendo el registro al resto de las oficinas]]

==Véase también==

:*[[Tarea_A:_Libros_y_registro_de_entrada_y_salida|Tarea A: Libros y registro de entrada y salida]]
:*[[Tarea_B:_Mejorando_la_numeración_del_registro|Tarea B: Mejorando la numeración del registro]]
:*[[Tarea_C:_Evolucionando_la_arquitectura_del_registro|Tarea C: Evolucionando la introducción de datos]]
:*[[Tarea_D:_Validar_la_introducción_de_datos|Tarea D: Validar la introducción de datos]]
:*[[Tarea_G:_Evitando_la_repliación_de_código|Tarea G: Evitando la repliación de código]]
:*[[Tarea_H:_Emitir_certificados_de_documentación|Tarea H: Emitir certificados de documentación]]
:*[[Tarea_I:_Creando_una_oficina_sin_papeles|Tarea I: Creando una oficina sin papeles]]
:*[[Tarea_J:_Importar_la_base_de_datos_de_terceros_de_otra_aplicación|Tarea J: Importar la base de datos de terceros de otra aplicación]]

Tarea C: Evolucionando la arquitectura del registro

2009-08-04T09:27:35Z

Imhernandez: /* ¿Qué hemos aprendido? */

[[Construir_una_aplicación_paso_a_paso|Construir una aplicación paso a paso]]

En nuestro registro, cada vez que un interesado presenta documentación, tenemos que escribir su nombre en el campo Remitente. Este sistema es válido, pero presenta algunas carencias. Si la misma persona presenta documentación en varias ocasiones, tendremos que estar repitiendo su nombre con el riesgo de equivocarnos, arriesgándonos a perder la coherencia de los datos. Además, tenemos muy poca información sobre esa persona. Si está iniciando un procedimiento administrativo y tenemos que ponernos en contacto con ella, no tenemos ni su DNI, ni su teléfono, ni su dirección. Tampoco podemos poner estos campos en el formulario del objeto '''Entrada''' ya que la introducción de datos sería muy tediosa. ¿Qué podemos hacer? Comencemos por abstraer el concepto de '''Tercero''' en el diagrama que propusimos al comienzo del tutorial.

[[Imagen:Figura 10.jpg|thumb|250px|Abstraemos el concepto Tercero y lo relacionamos con las entradas y las salidas]]En esta figura lo que decimos es:
:*Un '''Fichero de terceros''' se compone de muchos terceros. Un '''Tercero''' representa una persona (física o jurídica) y contiene los datos jurídicos y de contacto de dicha persona.
:*Un '''Libro de entrada''' se compone de muchas entradas. Cada '''Entrada''' tiene Número, Fecha y Destinatario (a qué departamento de la organización se dirige). También se relaciona con una ficha de '''Tercero'''; esta relación expresa que el Tercero es el Remitente de la documentación. Adicionalmente, puede tener uno o más documentos adjuntos.
:*Un '''Libro de salida''' se compone de muchas salidas. Cada '''Salida''' tiene Número, Fecha y Origen (departamento de la organización de donde sale el documento). También se relaciona con una ficha de '''Tercero'''; esta relación expresa que el Tercero es el Destinatario de la documentación de salida. Además, puede tener uno o más documentos adjuntos.

__TOC__

==Definiendo un tipo "Tercero"==
La definición del tipo '''Tercero es''' inmediata:

{{PR|tipo}} [Tercero] {{PR|es}} {{RE|contenedor}}
[Datos generales] {{PR|es}} {{T|formulario}}
[Nombre/Razón social] {{PR|es}} {{T|texto}}
[Apellidos] {{PR|es}} {{T|texto}}
[CIF/NIF] {{PR|es}} {{T|texto}}
[Dirección] {{PR|es}} {{T|texto}}
[Código postal] {{PR|es}} {{T|texto}}
[Municipio] {{PR|es}} {{T|texto}}
[Provincia] {{PR|es}} {{T|texto}}
[Teléfono 1] {{PR|es}} {{T|texto}}
[Teléfono 2] {{PR|es}} {{T|texto}}
[Fax] {{PR|es}} {{T|texto}}
[Email] {{PR|es}} {{T|texto}}
{{PR|fin}}
{{PR|fin}}

==Crear un "Fichero de terceros"==
Ahora tenemos que definir el '''Fichero de terceros''' como un objeto de sistema. La definición es muy parecida a la del '''Libro de entrada'''.

[Fichero de terceros] {{PR|es}} {{RE|contenedor}}
[Contenido] {{PR|es}} {{T|coleccion}}
-{{AT|nombre_tabla}} = {{STR|"TC$TERCEROS"}}; 
{{PR|contiene}} [Tercero] 
{{PR|columna}} [Denominación]
-{{AT|columna_bd}}.{{AT|nombre}} = {{STR|"DENOMINACION"}};
-{{AT|origen}} = [Datos generales].[Nombre/Razón social] + {{STR|" "}} + [Datos generales].[Apellidos];
{{PR|columna}} [CIF/NIF]
-{{AT|columna_bd}}.{{AT|nombre}} = {{STR|"CIF"}};
-{{AT|origen}} = [Datos generales].[CIF/NIF];
{{PR|columna}} [Teléfono principal]
-{{AT|columna_bd}}.{{AT|nombre}} = {{STR|"TELEFONO_1"}};
-{{AT|origen}} = [Datos generales].[Teléfono 1];
{{PR|columna}} [Email]
-{{AT|columna_bd}}.{{AT|nombre}} = {{STR|"EMAIL"}};
-{{AT|origen}} = [Datos generales].[Email];
{{PR|fin}}
{{PR|fin}}

Como ya explicamos en la [[:Tarea_A:_Libros_y_registro_de_entrada_y_salida|Tarea A]], las columnas de una {{T|coleccion}} no tienen por qué tener una correspondencia directa con los campos de los objetos que contiene. En esta ocasión, hemos definido la columna '''Denominación''' como una concatenación del '''Nombre''' y los '''Apellidos''', para no tener que diferenciar entre personas físicas y jurídicas (que no tendrían apellidos).

En ODL, todo recurso debe definirse antes de que se haga uso de él o de su definición. Como más adelante haremos uso tanto del tipo '''Tercero''' como del '''Fichero de terceros''' para establecer la relación, debemos asegurarnos de que las definiciones aparecen antes de que se definan los objetos Entrada o Salida.

==Ubicar nuestro "Fichero de terceros" en el "Registro"==
Por último, para hacer este fichero accesible para los usuarios, tenemos que ubicarlo en el '''Registro de entrada y salida'''. En este caso lo ubicaremos en '''Ficheros''', en vez de en '''Libros'''.

[Registro de entrada y salida] {{PR|es}} {{RE|habitacion}}
{{PR|ubicado}} [Fichero de terceros]
-{{AT|lugar}} = {{STR|"Ficheros"}};
{{PR|ubicado}} [Libro de entrada]
-{{AT|lugar}} = {{STR|"Libros"}};
{{PR|ubicado}} [Libro de salida]
-{{AT|lugar}} = {{STR|"Libros"}};
{{PR|fin}}

Si compilamos y actualizamos ya podremos comenzar a crear fichas de '''Tercero''' en nuestro sistema. Observa cómo en la barra de navegación lateral la plataforma crea un nuevo grupo con el nombre '''Ficheros'''.

<center>
{|
|align="center" |[[Imagen:Figura 11.jpg|thumb|250px|Ficha de Tercero]]
|}
</center>

==Establecer una relación entre "Entrada" y "Tercero" mediante un campo vínculo==
Ahora nos falta establecer la relación entre la ficha de '''Tercero''' y las '''Entradas''' y las '''Salidas'''. Esto lo logramos haciendo uso de los campos de tipo {{T|vinculo}}. Un {{T|vinculo}} representa una relación entre dos [[Contenedores|contenedores]] dentro del sistema. El siguiente código muestra cómo vincular una Entrada con una ficha de Tercero:

{{PR|tipo}} [Entrada] {{PR|es}} {{RE|contenedor}}
[Datos generales] {{PR|es}} {{T|formulario}}
[Número] {{PR|es}} {{T|timbre}}
-{{AT|certificado}}.{{AT|subsecuencia}}.{{AT|valor}} = $Copiartexto($texto($Año($Hoy)), 3, 2);
-{{AT|certificado}}.{{AT|valor}} = [&Valor_subsecuencia] + {{STR|"/"}} + [&Valor_secuencia];
-{{AT|certificado}}.{{AT|secuencia}}.{{AT|nombre}} = {{STR|"STR$ENTRADA"};
-{{AT|certificado}}.{{AT|secuencia}}.{{AT|longitud}} = 4;
[Fecha] {{PR|es}} {{T|fecha}}
-{{AT|edicion}}.{{AT|modo}} = copia;
-{{AT|edicion}}.{{AT|valor}} = [Número].[&Fecha];
[Remitente] {{PR|es}} {{T|vinculo}}
-{{AT|vinculo}}.{{AT|definicion}} = [Tercero];
-{{AT|vinculo}}.{{AT|etiqueta}} = [Datos generales].[Nombre/Razón social] + {{STR|" "}} + [Datos generales].[Apellidos];
-{{AT|vinculo}}.{{AT|valores}} = $matriz([Fichero de terceros].[Contenido]);
[Destinatario] {{PR|es}} {{T|texto}}
{{PR|fin}}
{{PR|fin}}

Como podrás observar, cambiamos el tipo del campo '''Remitente''' de {{T|texto}} a {{T|vinculo}}. Los tres atributos que vienen a continuación nos permiten configurar el comportamiento del {{T|vinculo}}:
:*El atributo {{AT|vinculo.definicion}} indica con qué tipo de [[Contenedores|contenedor]] puede establecerse el vínculo. En este caso indicamos que vincula con un objeto de tipo '''Tercero'''.
:*En el atributo {{AT|vinculo.etiqueta}} indicamos una expresión con el texto que debe aparecer en el campo cuando se establece el vínculo. En este caso, queremos que aparezca el nombre y los apellidos concatenados.
:*Por último, en el atributo {{AT|vinculo.valores}} indicamos la fuente de datos de la cuál obtendremos todos los [[Contenedores|contenedores]] con los que podremos vincular. En nuestro caso indicamos que es la colección '''Contenido''' del '''Fichero de terceros'''. Como este atributo espera una matriz, realizamos una conversión entre {{T|coleccion}} y {{T|matriz}} con la función '''$matriz'''.

Con estas seis líneas ya habremos establecido la relación entre '''Entrada''' y '''Tercero'''.

(Compila, actualiza y prueba ;).

<center>
{|
|align="center" |[[Imagen:Figura 12.jpg|thumb|250px|Cuadro de búsqueda para vincular. Este cuadro se abre al hacer clic en el icono vincular del campo Remitente.]]
|}
</center>

Como podrás observar, al final del campo '''Remitente''' aparece un triángulo. Si haces clic se abrirá un cuadro, similar al de la figura anterior, mostrando todas las fichas de '''Tercero''' que hay en la colección '''Contenido''' del '''Fichero de terceros'''. Si haces doble clic en alguna de las fichas que te muestra, podrás observar cómo queda el objeto vinculado.

==¿Qué es un enumerado? Añadiendo un "Destinatario" a las "Entradas"==
Ahora ya tenemos las entradas vinculadas con fichas de '''Tercero''', enriqueciendo el conjunto de la información almacenada y garantizando la coherencia en el sistema. ¿Podremos hacer algo con el campo '''Destinatario'''? La mayoría de las organizaciones tienen un conjunto de departamentos bien conocido y relativamente reducido. Siempre que se presente alguna documentación, ésta irá dirigida a un departamento concreto. Sería bastante cómodo disponer de la lista de departamentos para seleccionar uno, aunque quizás no merece la pena (al menos de momento) abstraerlos como un concepto del sistema. Los recursos de tipo {{RE|enumerado}} son una buena opción.

[Departamentos] {{PR|es}} {{RE|enumerado}}
{{AT|valores}}
{{STR|"Secretaría"}},
{{STR|"Administración"}},
{{STR|"Contabilidad"}},
{{STR|"Personal"}},
{{STR|"Dirección"}}
{{PR|fin}}

Un {{RE|enumerado}} es un recurso que actúa como una fuente de datos. Los valores que proporciona un enumerado pueden ponerse en una lista de cadenas separadas por comas (como en el ejemplo anterior) o bien pueden obtenerse de un fichero CSV (commasepareted values). En la declaración anterior, definidos el objeto de sistema '''Departamentos''' de tipo {{RE|enumerado}} y definimos cinco valores con los nombres (hipotéticos) de los departamentos de la organización.

Ahora debemos modificar la definición del campo '''Destinatario''' en el formulario de '''Entrada''' para hacer uso del enumerado:

{{PR|tipo}} [Entrada] {{PR|es}} {{RE|contenedor}}
[Datos generales] {{PR|es}} {{T|formulario}}
[Número] {{PR|es}} {{T|timbre}}
-{{AT|certificado}}.{{AT|subsecuencia}}.{{AT|valor}} = $Copiartexto($texto($Año($Hoy)), 3, 2);
-{{AT|certificado}}.{{AT|valor}} = [&Valor_subsecuencia] + {{STR|"/"}} + [&Valor_secuencia];
-{{AT|certificado}}.{{AT|secuencia}}.{{AT|nombre}} = {{STR|"STR$ENTRADA"};
-{{AT|certificado}}.{{AT|secuencia}}.{{AT|longitud}} = 4;
[Fecha] {{PR|es}} {{T|fecha}}
-{{AT|edicion}}.{{AT|modo}} = copia;
-{{AT|edicion}}.{{AT|valor}} = [Número].[&Fecha];
[Remitente] {{PR|es}} {{T|vinculo}}
-{{AT|vinculo}}.{{AT|definicion}} = [Tercero];
-{{AT|vinculo}}.{{AT|etiqueta}} = [Datos generales].[Nombre/Razón social] + {{STR|" "}} + [Datos generales].[Apellidos];
-{{AT|vinculo}}.{{AT|valores}} = $matriz([Fichero de terceros].[Contenido]);
[Destinatario] {{PR|es}} {{T|texto}}
-{{AT|edicion}}.{{AT|valores}} = $matriz([Departamentos]);
{{PR|fin}}
{{PR|fin}}

Al compilar y actualizar, observarás cómo al final del campo '''Destinatario''' aparece un cuadrado doble. Haciendo clic te aparecerá la lista de valores.

==¿Y la documentación presentada? Introducir un campo tabla al formulario==
Un asunto que dejamos pendiente en la [[:Tarea_A:_Libros_y_registro_de_entrada_y_salida|Tarea A]] fue incluir en la definición del tipo '''Entrada''' la documentación presentada. Ahora que ya tenemos algo más de experiencia con ODL, es un buen momento para abordarlo.

Para reflejar la documentación que el '''Remitente''' presenta utilizaremos los campos de tipo {{T|tabla}}. Este tipo de campo permite definir una tabla en el formulario. Dentro de la tabla se definen campos (al igual que en el formulario) que actuarán como las columnas de la tabla.

{{PR|tipo}} [Entrada] {{PR|es}} {{RE|contenedor}}
[Datos generales] {{PR|es}} {{T|formulario}}
[Número] {{PR|es}} {{T|timbre}}
-{{AT|certificado}}.{{AT|subsecuencia}}.{{AT|valor}} = $Copiartexto($texto($Año($Hoy)), 3, 2);
-{{AT|certificado}}.{{AT|valor}} = [&Valor_subsecuencia] + {{STR|"/"}} + [&Valor_secuencia];
-{{AT|certificado}}.{{AT|secuencia}}.{{AT|nombre}} = {{STR|"STR$ENTRADA"}};
-{{AT|certificado}}.{{AT|secuencia}}.{{AT|longitud}} = 4;
[Fecha] {{PR|es}} {{T|fecha}}
-{{AT|edicion}}.{{AT|modo}} = copia;
-{{AT|edicion}}.{{AT|valor}} = [Número].[&Fecha];
[Remitente] {{PR|es}} {{T|vinculo}}
-{{AT|vinculo}}.{{AT|definicion}} = [Tercero];
-{{AT|vinculo}}.{{AT|etiqueta}} = [Datos generales].[Nombre/Razón social] + {{STR|" "}} + [Datos generales].[Apellidos];
-{{AT|vinculo}}.{{AT|valores}} = $matriz([Fichero de terceros].[Contenido]);
[Destinatario] {{PR|es}} {{T|texto}}
-{{AT|edicion}}.{{AT|valores}} = $matriz([Departamentos]);
[Documentación presentada] {{PR|es}} {{T|tabla}}
[Documento] {{PR|es}} {{T|texto}}
{{PR|fin}}
{{PR|fin}}
{{PR|fin}}

En el código anterior, añadimos la tabla '''Documentación presentada''' con una columna de tipo texto '''Documento'''. Si compilamos y actualizamos, ya podremos reflejar en el objeto '''Entrada''' cuál ha sido la documentación presentada en el Registro.

<center>
{|
|align="center" |[[Imagen:Figura 13.jpg|thumb|250px|Entrada con la tabla de Documentación presentada]]
|}
</center>

==¿Qué hemos aprendido?==
:*En ODL todas las definiciones deben declararse antes de su uso.
:*Se pueden establecer vínculos entre [[Contenedores|contenedores]] haciendo uso de los campos de tipo vínculo.
:*Se pueden definir recursos de tipo enumerado, que actúan como fuentes de datos. Estos datos pueden especificarse en la definición o proporcionarse mediante un fichero CSV.
:*Los campos de tipo tabla permiten incrustar tablas en los formularios con el número de columnas que necesitemos.

==Ejercicios==
:*Traslada las modificaciones que hemos realizado sobre la definición de '''Entrada''' al tipo '''Salida'''. Ten en cuenta que, en este caso, el campo '''Origen''' hace referencia a un departamento de la organización y el '''Destinatario''' es un '''Tercero'''.
:*El atributo {{AT|apariencia.desplegable}} permite controlar que el conjunto de valores especificado en el atributo {{AT|edicion.valores}} se muestre como un desplegable en lugar de mostrar un cuadro. Prueba a agregar este atributo al campo '''Destinatario''' de la '''Entrada''' (debes poner apariencia.desplegable = verdadero).
:*El atributo {{AT|edicion.seleccion}} permite controlar que un campo de tipo {{T|texto}} sólo pueda tomar alguno de los valores especificados en el atributo {{AT|edicion.valores}}. Prueba a incluir este atributo al campo '''Destinatario''' de la '''Entrada''' (debes poner edicion.seleccion = verdadero) y comprueba que ya no puedes introducir texto libre en dicho campo.
:*Define una nueva ficha, '''Trabajador''', que represente a un trabajador de la organización. Esta ficha debe almacenar Nombre, Apellidos, Cargo, Sexo (a elegir entre Hombre y Mujer), Teléfono y Departamento del trabajador. Crea también un fichero de '''Trabajadores''' que contenga todas las fichas. Por último añade a la definición de Entrada un campo que sea '''Trabajador destinatario'''. Este campo debe vincular con alguna de las fichas de '''Trabajador'''.

==Siguiente tarea==

:*[[Tarea_D:_Validar_la_introducción_de_datos|Tarea D: Validar la introducción de datos]]

==Véase también==

:*[[Tarea_A:_Libros_y_registro_de_entrada_y_salida|Tarea A: Libros y registro de entrada y salida]]
:*[[Tarea_B:_Mejorando_la_numeración_del_registro|Tarea B: Mejorando la numeración del registro]]
:*[[Tarea_E:_Utilizar_el_registro_como_un_almacén_de_documentación|Tarea E: Utilizar el registro como un almacén de documentación]]
:*[[Tarea_F:_Abriendo_el_registro_al_resto_de_las_oficinas|Tarea F: Abriendo el registro al resto de las oficinas]]
:*[[Tarea_G:_Evitando_la_repliación_de_código|Tarea G: Evitando la repliación de código]]
:*[[Tarea_H:_Emitir_certificados_de_documentación|Tarea H: Emitir certificados de documentación]]
:*[[Tarea_I:_Creando_una_oficina_sin_papeles|Tarea I: Creando una oficina sin papeles]]
:*[[Tarea_J:_Importar_la_base_de_datos_de_terceros_de_otra_aplicación|Tarea J: Importar la base de datos de terceros de otra aplicación]]

Tarea C: Evolucionando la arquitectura del registro

2009-08-04T09:25:17Z

Imhernandez: /* ¿Qué es un enumerado? Añadiendo un "Destinatario" a las "Entradas" */

[[Construir_una_aplicación_paso_a_paso|Construir una aplicación paso a paso]]

En nuestro registro, cada vez que un interesado presenta documentación, tenemos que escribir su nombre en el campo Remitente. Este sistema es válido, pero presenta algunas carencias. Si la misma persona presenta documentación en varias ocasiones, tendremos que estar repitiendo su nombre con el riesgo de equivocarnos, arriesgándonos a perder la coherencia de los datos. Además, tenemos muy poca información sobre esa persona. Si está iniciando un procedimiento administrativo y tenemos que ponernos en contacto con ella, no tenemos ni su DNI, ni su teléfono, ni su dirección. Tampoco podemos poner estos campos en el formulario del objeto '''Entrada''' ya que la introducción de datos sería muy tediosa. ¿Qué podemos hacer? Comencemos por abstraer el concepto de '''Tercero''' en el diagrama que propusimos al comienzo del tutorial.

[[Imagen:Figura 10.jpg|thumb|250px|Abstraemos el concepto Tercero y lo relacionamos con las entradas y las salidas]]En esta figura lo que decimos es:
:*Un '''Fichero de terceros''' se compone de muchos terceros. Un '''Tercero''' representa una persona (física o jurídica) y contiene los datos jurídicos y de contacto de dicha persona.
:*Un '''Libro de entrada''' se compone de muchas entradas. Cada '''Entrada''' tiene Número, Fecha y Destinatario (a qué departamento de la organización se dirige). También se relaciona con una ficha de '''Tercero'''; esta relación expresa que el Tercero es el Remitente de la documentación. Adicionalmente, puede tener uno o más documentos adjuntos.
:*Un '''Libro de salida''' se compone de muchas salidas. Cada '''Salida''' tiene Número, Fecha y Origen (departamento de la organización de donde sale el documento). También se relaciona con una ficha de '''Tercero'''; esta relación expresa que el Tercero es el Destinatario de la documentación de salida. Además, puede tener uno o más documentos adjuntos.

__TOC__

==Definiendo un tipo "Tercero"==
La definición del tipo '''Tercero es''' inmediata:

{{PR|tipo}} [Tercero] {{PR|es}} {{RE|contenedor}}
[Datos generales] {{PR|es}} {{T|formulario}}
[Nombre/Razón social] {{PR|es}} {{T|texto}}
[Apellidos] {{PR|es}} {{T|texto}}
[CIF/NIF] {{PR|es}} {{T|texto}}
[Dirección] {{PR|es}} {{T|texto}}
[Código postal] {{PR|es}} {{T|texto}}
[Municipio] {{PR|es}} {{T|texto}}
[Provincia] {{PR|es}} {{T|texto}}
[Teléfono 1] {{PR|es}} {{T|texto}}
[Teléfono 2] {{PR|es}} {{T|texto}}
[Fax] {{PR|es}} {{T|texto}}
[Email] {{PR|es}} {{T|texto}}
{{PR|fin}}
{{PR|fin}}

==Crear un "Fichero de terceros"==
Ahora tenemos que definir el '''Fichero de terceros''' como un objeto de sistema. La definición es muy parecida a la del '''Libro de entrada'''.

[Fichero de terceros] {{PR|es}} {{RE|contenedor}}
[Contenido] {{PR|es}} {{T|coleccion}}
-{{AT|nombre_tabla}} = {{STR|"TC$TERCEROS"}}; 
{{PR|contiene}} [Tercero] 
{{PR|columna}} [Denominación]
-{{AT|columna_bd}}.{{AT|nombre}} = {{STR|"DENOMINACION"}};
-{{AT|origen}} = [Datos generales].[Nombre/Razón social] + {{STR|" "}} + [Datos generales].[Apellidos];
{{PR|columna}} [CIF/NIF]
-{{AT|columna_bd}}.{{AT|nombre}} = {{STR|"CIF"}};
-{{AT|origen}} = [Datos generales].[CIF/NIF];
{{PR|columna}} [Teléfono principal]
-{{AT|columna_bd}}.{{AT|nombre}} = {{STR|"TELEFONO_1"}};
-{{AT|origen}} = [Datos generales].[Teléfono 1];
{{PR|columna}} [Email]
-{{AT|columna_bd}}.{{AT|nombre}} = {{STR|"EMAIL"}};
-{{AT|origen}} = [Datos generales].[Email];
{{PR|fin}}
{{PR|fin}}

Como ya explicamos en la [[:Tarea_A:_Libros_y_registro_de_entrada_y_salida|Tarea A]], las columnas de una {{T|coleccion}} no tienen por qué tener una correspondencia directa con los campos de los objetos que contiene. En esta ocasión, hemos definido la columna '''Denominación''' como una concatenación del '''Nombre''' y los '''Apellidos''', para no tener que diferenciar entre personas físicas y jurídicas (que no tendrían apellidos).

En ODL, todo recurso debe definirse antes de que se haga uso de él o de su definición. Como más adelante haremos uso tanto del tipo '''Tercero''' como del '''Fichero de terceros''' para establecer la relación, debemos asegurarnos de que las definiciones aparecen antes de que se definan los objetos Entrada o Salida.

==Ubicar nuestro "Fichero de terceros" en el "Registro"==
Por último, para hacer este fichero accesible para los usuarios, tenemos que ubicarlo en el '''Registro de entrada y salida'''. En este caso lo ubicaremos en '''Ficheros''', en vez de en '''Libros'''.

[Registro de entrada y salida] {{PR|es}} {{RE|habitacion}}
{{PR|ubicado}} [Fichero de terceros]
-{{AT|lugar}} = {{STR|"Ficheros"}};
{{PR|ubicado}} [Libro de entrada]
-{{AT|lugar}} = {{STR|"Libros"}};
{{PR|ubicado}} [Libro de salida]
-{{AT|lugar}} = {{STR|"Libros"}};
{{PR|fin}}

Si compilamos y actualizamos ya podremos comenzar a crear fichas de '''Tercero''' en nuestro sistema. Observa cómo en la barra de navegación lateral la plataforma crea un nuevo grupo con el nombre '''Ficheros'''.

<center>
{|
|align="center" |[[Imagen:Figura 11.jpg|thumb|250px|Ficha de Tercero]]
|}
</center>

==Establecer una relación entre "Entrada" y "Tercero" mediante un campo vínculo==
Ahora nos falta establecer la relación entre la ficha de '''Tercero''' y las '''Entradas''' y las '''Salidas'''. Esto lo logramos haciendo uso de los campos de tipo {{T|vinculo}}. Un {{T|vinculo}} representa una relación entre dos [[Contenedores|contenedores]] dentro del sistema. El siguiente código muestra cómo vincular una Entrada con una ficha de Tercero:

{{PR|tipo}} [Entrada] {{PR|es}} {{RE|contenedor}}
[Datos generales] {{PR|es}} {{T|formulario}}
[Número] {{PR|es}} {{T|timbre}}
-{{AT|certificado}}.{{AT|subsecuencia}}.{{AT|valor}} = $Copiartexto($texto($Año($Hoy)), 3, 2);
-{{AT|certificado}}.{{AT|valor}} = [&Valor_subsecuencia] + {{STR|"/"}} + [&Valor_secuencia];
-{{AT|certificado}}.{{AT|secuencia}}.{{AT|nombre}} = {{STR|"STR$ENTRADA"};
-{{AT|certificado}}.{{AT|secuencia}}.{{AT|longitud}} = 4;
[Fecha] {{PR|es}} {{T|fecha}}
-{{AT|edicion}}.{{AT|modo}} = copia;
-{{AT|edicion}}.{{AT|valor}} = [Número].[&Fecha];
[Remitente] {{PR|es}} {{T|vinculo}}
-{{AT|vinculo}}.{{AT|definicion}} = [Tercero];
-{{AT|vinculo}}.{{AT|etiqueta}} = [Datos generales].[Nombre/Razón social] + {{STR|" "}} + [Datos generales].[Apellidos];
-{{AT|vinculo}}.{{AT|valores}} = $matriz([Fichero de terceros].[Contenido]);
[Destinatario] {{PR|es}} {{T|texto}}
{{PR|fin}}
{{PR|fin}}

Como podrás observar, cambiamos el tipo del campo '''Remitente''' de {{T|texto}} a {{T|vinculo}}. Los tres atributos que vienen a continuación nos permiten configurar el comportamiento del {{T|vinculo}}:
:*El atributo {{AT|vinculo.definicion}} indica con qué tipo de [[Contenedores|contenedor]] puede establecerse el vínculo. En este caso indicamos que vincula con un objeto de tipo '''Tercero'''.
:*En el atributo {{AT|vinculo.etiqueta}} indicamos una expresión con el texto que debe aparecer en el campo cuando se establece el vínculo. En este caso, queremos que aparezca el nombre y los apellidos concatenados.
:*Por último, en el atributo {{AT|vinculo.valores}} indicamos la fuente de datos de la cuál obtendremos todos los [[Contenedores|contenedores]] con los que podremos vincular. En nuestro caso indicamos que es la colección '''Contenido''' del '''Fichero de terceros'''. Como este atributo espera una matriz, realizamos una conversión entre {{T|coleccion}} y {{T|matriz}} con la función '''$matriz'''.

Con estas seis líneas ya habremos establecido la relación entre '''Entrada''' y '''Tercero'''.

(Compila, actualiza y prueba ;).

<center>
{|
|align="center" |[[Imagen:Figura 12.jpg|thumb|250px|Cuadro de búsqueda para vincular. Este cuadro se abre al hacer clic en el icono vincular del campo Remitente.]]
|}
</center>

Como podrás observar, al final del campo '''Remitente''' aparece un triángulo. Si haces clic se abrirá un cuadro, similar al de la figura anterior, mostrando todas las fichas de '''Tercero''' que hay en la colección '''Contenido''' del '''Fichero de terceros'''. Si haces doble clic en alguna de las fichas que te muestra, podrás observar cómo queda el objeto vinculado.

==¿Qué es un enumerado? Añadiendo un "Destinatario" a las "Entradas"==
Ahora ya tenemos las entradas vinculadas con fichas de '''Tercero''', enriqueciendo el conjunto de la información almacenada y garantizando la coherencia en el sistema. ¿Podremos hacer algo con el campo '''Destinatario'''? La mayoría de las organizaciones tienen un conjunto de departamentos bien conocido y relativamente reducido. Siempre que se presente alguna documentación, ésta irá dirigida a un departamento concreto. Sería bastante cómodo disponer de la lista de departamentos para seleccionar uno, aunque quizás no merece la pena (al menos de momento) abstraerlos como un concepto del sistema. Los recursos de tipo {{RE|enumerado}} son una buena opción.

[Departamentos] {{PR|es}} {{RE|enumerado}}
{{AT|valores}}
{{STR|"Secretaría"}},
{{STR|"Administración"}},
{{STR|"Contabilidad"}},
{{STR|"Personal"}},
{{STR|"Dirección"}}
{{PR|fin}}

Un {{RE|enumerado}} es un recurso que actúa como una fuente de datos. Los valores que proporciona un enumerado pueden ponerse en una lista de cadenas separadas por comas (como en el ejemplo anterior) o bien pueden obtenerse de un fichero CSV (commasepareted values). En la declaración anterior, definidos el objeto de sistema '''Departamentos''' de tipo {{RE|enumerado}} y definimos cinco valores con los nombres (hipotéticos) de los departamentos de la organización.

Ahora debemos modificar la definición del campo '''Destinatario''' en el formulario de '''Entrada''' para hacer uso del enumerado:

{{PR|tipo}} [Entrada] {{PR|es}} {{RE|contenedor}}
[Datos generales] {{PR|es}} {{T|formulario}}
[Número] {{PR|es}} {{T|timbre}}
-{{AT|certificado}}.{{AT|subsecuencia}}.{{AT|valor}} = $Copiartexto($texto($Año($Hoy)), 3, 2);
-{{AT|certificado}}.{{AT|valor}} = [&Valor_subsecuencia] + {{STR|"/"}} + [&Valor_secuencia];
-{{AT|certificado}}.{{AT|secuencia}}.{{AT|nombre}} = {{STR|"STR$ENTRADA"};
-{{AT|certificado}}.{{AT|secuencia}}.{{AT|longitud}} = 4;
[Fecha] {{PR|es}} {{T|fecha}}
-{{AT|edicion}}.{{AT|modo}} = copia;
-{{AT|edicion}}.{{AT|valor}} = [Número].[&Fecha];
[Remitente] {{PR|es}} {{T|vinculo}}
-{{AT|vinculo}}.{{AT|definicion}} = [Tercero];
-{{AT|vinculo}}.{{AT|etiqueta}} = [Datos generales].[Nombre/Razón social] + {{STR|" "}} + [Datos generales].[Apellidos];
-{{AT|vinculo}}.{{AT|valores}} = $matriz([Fichero de terceros].[Contenido]);
[Destinatario] {{PR|es}} {{T|texto}}
-{{AT|edicion}}.{{AT|valores}} = $matriz([Departamentos]);
{{PR|fin}}
{{PR|fin}}

Al compilar y actualizar, observarás cómo al final del campo '''Destinatario''' aparece un cuadrado doble. Haciendo clic te aparecerá la lista de valores.

==¿Y la documentación presentada? Introducir un campo tabla al formulario==
Un asunto que dejamos pendiente en la [[:Tarea_A:_Libros_y_registro_de_entrada_y_salida|Tarea A]] fue incluir en la definición del tipo '''Entrada''' la documentación presentada. Ahora que ya tenemos algo más de experiencia con ODL, es un buen momento para abordarlo.

Para reflejar la documentación que el '''Remitente''' presenta utilizaremos los campos de tipo {{T|tabla}}. Este tipo de campo permite definir una tabla en el formulario. Dentro de la tabla se definen campos (al igual que en el formulario) que actuarán como las columnas de la tabla.

{{PR|tipo}} [Entrada] {{PR|es}} {{RE|contenedor}}
[Datos generales] {{PR|es}} {{T|formulario}}
[Número] {{PR|es}} {{T|timbre}}
-{{AT|certificado}}.{{AT|subsecuencia}}.{{AT|valor}} = $Copiartexto($texto($Año($Hoy)), 3, 2);
-{{AT|certificado}}.{{AT|valor}} = [&Valor_subsecuencia] + {{STR|"/"}} + [&Valor_secuencia];
-{{AT|certificado}}.{{AT|secuencia}}.{{AT|nombre}} = {{STR|"STR$ENTRADA"}};
-{{AT|certificado}}.{{AT|secuencia}}.{{AT|longitud}} = 4;
[Fecha] {{PR|es}} {{T|fecha}}
-{{AT|edicion}}.{{AT|modo}} = copia;
-{{AT|edicion}}.{{AT|valor}} = [Número].[&Fecha];
[Remitente] {{PR|es}} {{T|vinculo}}
-{{AT|vinculo}}.{{AT|definicion}} = [Tercero];
-{{AT|vinculo}}.{{AT|etiqueta}} = [Datos generales].[Nombre/Razón social] + {{STR|" "}} + [Datos generales].[Apellidos];
-{{AT|vinculo}}.{{AT|valores}} = $matriz([Fichero de terceros].[Contenido]);
[Destinatario] {{PR|es}} {{T|texto}}
-{{AT|edicion}}.{{AT|valores}} = $matriz([Departamentos]);
[Documentación presentada] {{PR|es}} {{T|tabla}}
[Documento] {{PR|es}} {{T|texto}}
{{PR|fin}}
{{PR|fin}}
{{PR|fin}}

En el código anterior, añadimos la tabla '''Documentación presentada''' con una columna de tipo texto '''Documento'''. Si compilamos y actualizamos, ya podremos reflejar en el objeto '''Entrada''' cuál ha sido la documentación presentada en el Registro.

<center>
{|
|align="center" |[[Imagen:Figura 13.jpg|thumb|250px|Entrada con la tabla de Documentación presentada]]
|}
</center>

==¿Qué hemos aprendido?==
:*En ODL, todas las definiciones deben declararse antes de su uso.
:*Se pueden establecer vínculos entre [[Contenedores|contenedores]] haciendo uso de los campos de tipo vínculo.
:*Se pueden definir recursos de tipo enumerado, que actúan como fuentes de datos. Estos datos pueden especificarse en la definición o proporcionarse a través de un fichero CSV.
:*Los campos de tipo tabla permiten incrustar tablas en los formularios con el número de columnas que necesitemos.

==Ejercicios==
:*Traslada las modificaciones que hemos realizado sobre la definición de '''Entrada''' al tipo '''Salida'''. Ten en cuenta que, en este caso, el campo '''Origen''' hace referencia a un departamento de la organización y el '''Destinatario''' es un '''Tercero'''.
:*El atributo {{AT|apariencia.desplegable}} permite controlar que el conjunto de valores especificado en el atributo {{AT|edicion.valores}} se muestre como un desplegable en lugar de mostrar un cuadro. Prueba a agregar este atributo al campo '''Destinatario''' de la '''Entrada''' (debes poner apariencia.desplegable = verdadero).
:*El atributo {{AT|edicion.seleccion}} permite controlar que un campo de tipo {{T|texto}} sólo pueda tomar alguno de los valores especificados en el atributo {{AT|edicion.valores}}. Prueba a incluir este atributo al campo '''Destinatario''' de la '''Entrada''' (debes poner edicion.seleccion = verdadero) y comprueba que ya no puedes introducir texto libre en dicho campo.
:*Define una nueva ficha, '''Trabajador''', que represente a un trabajador de la organización. Esta ficha debe almacenar Nombre, Apellidos, Cargo, Sexo (a elegir entre Hombre y Mujer), Teléfono y Departamento del trabajador. Crea también un fichero de '''Trabajadores''' que contenga todas las fichas. Por último añade a la definición de Entrada un campo que sea '''Trabajador destinatario'''. Este campo debe vincular con alguna de las fichas de '''Trabajador'''.

==Siguiente tarea==

:*[[Tarea_D:_Validar_la_introducción_de_datos|Tarea D: Validar la introducción de datos]]

==Véase también==

:*[[Tarea_A:_Libros_y_registro_de_entrada_y_salida|Tarea A: Libros y registro de entrada y salida]]
:*[[Tarea_B:_Mejorando_la_numeración_del_registro|Tarea B: Mejorando la numeración del registro]]
:*[[Tarea_E:_Utilizar_el_registro_como_un_almacén_de_documentación|Tarea E: Utilizar el registro como un almacén de documentación]]
:*[[Tarea_F:_Abriendo_el_registro_al_resto_de_las_oficinas|Tarea F: Abriendo el registro al resto de las oficinas]]
:*[[Tarea_G:_Evitando_la_repliación_de_código|Tarea G: Evitando la repliación de código]]
:*[[Tarea_H:_Emitir_certificados_de_documentación|Tarea H: Emitir certificados de documentación]]
:*[[Tarea_I:_Creando_una_oficina_sin_papeles|Tarea I: Creando una oficina sin papeles]]
:*[[Tarea_J:_Importar_la_base_de_datos_de_terceros_de_otra_aplicación|Tarea J: Importar la base de datos de terceros de otra aplicación]]

Tarea C: Evolucionando la arquitectura del registro

2009-08-04T09:23:17Z

Imhernandez: /* Establecer una relación entre "Entrada" y "Tercero" mediante un campo vínculo */

[[Construir_una_aplicación_paso_a_paso|Construir una aplicación paso a paso]]

En nuestro registro, cada vez que un interesado presenta documentación, tenemos que escribir su nombre en el campo Remitente. Este sistema es válido, pero presenta algunas carencias. Si la misma persona presenta documentación en varias ocasiones, tendremos que estar repitiendo su nombre con el riesgo de equivocarnos, arriesgándonos a perder la coherencia de los datos. Además, tenemos muy poca información sobre esa persona. Si está iniciando un procedimiento administrativo y tenemos que ponernos en contacto con ella, no tenemos ni su DNI, ni su teléfono, ni su dirección. Tampoco podemos poner estos campos en el formulario del objeto '''Entrada''' ya que la introducción de datos sería muy tediosa. ¿Qué podemos hacer? Comencemos por abstraer el concepto de '''Tercero''' en el diagrama que propusimos al comienzo del tutorial.

[[Imagen:Figura 10.jpg|thumb|250px|Abstraemos el concepto Tercero y lo relacionamos con las entradas y las salidas]]En esta figura lo que decimos es:
:*Un '''Fichero de terceros''' se compone de muchos terceros. Un '''Tercero''' representa una persona (física o jurídica) y contiene los datos jurídicos y de contacto de dicha persona.
:*Un '''Libro de entrada''' se compone de muchas entradas. Cada '''Entrada''' tiene Número, Fecha y Destinatario (a qué departamento de la organización se dirige). También se relaciona con una ficha de '''Tercero'''; esta relación expresa que el Tercero es el Remitente de la documentación. Adicionalmente, puede tener uno o más documentos adjuntos.
:*Un '''Libro de salida''' se compone de muchas salidas. Cada '''Salida''' tiene Número, Fecha y Origen (departamento de la organización de donde sale el documento). También se relaciona con una ficha de '''Tercero'''; esta relación expresa que el Tercero es el Destinatario de la documentación de salida. Además, puede tener uno o más documentos adjuntos.

__TOC__

==Definiendo un tipo "Tercero"==
La definición del tipo '''Tercero es''' inmediata:

{{PR|tipo}} [Tercero] {{PR|es}} {{RE|contenedor}}
[Datos generales] {{PR|es}} {{T|formulario}}
[Nombre/Razón social] {{PR|es}} {{T|texto}}
[Apellidos] {{PR|es}} {{T|texto}}
[CIF/NIF] {{PR|es}} {{T|texto}}
[Dirección] {{PR|es}} {{T|texto}}
[Código postal] {{PR|es}} {{T|texto}}
[Municipio] {{PR|es}} {{T|texto}}
[Provincia] {{PR|es}} {{T|texto}}
[Teléfono 1] {{PR|es}} {{T|texto}}
[Teléfono 2] {{PR|es}} {{T|texto}}
[Fax] {{PR|es}} {{T|texto}}
[Email] {{PR|es}} {{T|texto}}
{{PR|fin}}
{{PR|fin}}

==Crear un "Fichero de terceros"==
Ahora tenemos que definir el '''Fichero de terceros''' como un objeto de sistema. La definición es muy parecida a la del '''Libro de entrada'''.

[Fichero de terceros] {{PR|es}} {{RE|contenedor}}
[Contenido] {{PR|es}} {{T|coleccion}}
-{{AT|nombre_tabla}} = {{STR|"TC$TERCEROS"}}; 
{{PR|contiene}} [Tercero] 
{{PR|columna}} [Denominación]
-{{AT|columna_bd}}.{{AT|nombre}} = {{STR|"DENOMINACION"}};
-{{AT|origen}} = [Datos generales].[Nombre/Razón social] + {{STR|" "}} + [Datos generales].[Apellidos];
{{PR|columna}} [CIF/NIF]
-{{AT|columna_bd}}.{{AT|nombre}} = {{STR|"CIF"}};
-{{AT|origen}} = [Datos generales].[CIF/NIF];
{{PR|columna}} [Teléfono principal]
-{{AT|columna_bd}}.{{AT|nombre}} = {{STR|"TELEFONO_1"}};
-{{AT|origen}} = [Datos generales].[Teléfono 1];
{{PR|columna}} [Email]
-{{AT|columna_bd}}.{{AT|nombre}} = {{STR|"EMAIL"}};
-{{AT|origen}} = [Datos generales].[Email];
{{PR|fin}}
{{PR|fin}}

Como ya explicamos en la [[:Tarea_A:_Libros_y_registro_de_entrada_y_salida|Tarea A]], las columnas de una {{T|coleccion}} no tienen por qué tener una correspondencia directa con los campos de los objetos que contiene. En esta ocasión, hemos definido la columna '''Denominación''' como una concatenación del '''Nombre''' y los '''Apellidos''', para no tener que diferenciar entre personas físicas y jurídicas (que no tendrían apellidos).

En ODL, todo recurso debe definirse antes de que se haga uso de él o de su definición. Como más adelante haremos uso tanto del tipo '''Tercero''' como del '''Fichero de terceros''' para establecer la relación, debemos asegurarnos de que las definiciones aparecen antes de que se definan los objetos Entrada o Salida.

==Ubicar nuestro "Fichero de terceros" en el "Registro"==
Por último, para hacer este fichero accesible para los usuarios, tenemos que ubicarlo en el '''Registro de entrada y salida'''. En este caso lo ubicaremos en '''Ficheros''', en vez de en '''Libros'''.

[Registro de entrada y salida] {{PR|es}} {{RE|habitacion}}
{{PR|ubicado}} [Fichero de terceros]
-{{AT|lugar}} = {{STR|"Ficheros"}};
{{PR|ubicado}} [Libro de entrada]
-{{AT|lugar}} = {{STR|"Libros"}};
{{PR|ubicado}} [Libro de salida]
-{{AT|lugar}} = {{STR|"Libros"}};
{{PR|fin}}

Si compilamos y actualizamos ya podremos comenzar a crear fichas de '''Tercero''' en nuestro sistema. Observa cómo en la barra de navegación lateral la plataforma crea un nuevo grupo con el nombre '''Ficheros'''.

<center>
{|
|align="center" |[[Imagen:Figura 11.jpg|thumb|250px|Ficha de Tercero]]
|}
</center>

==Establecer una relación entre "Entrada" y "Tercero" mediante un campo vínculo==
Ahora nos falta establecer la relación entre la ficha de '''Tercero''' y las '''Entradas''' y las '''Salidas'''. Esto lo logramos haciendo uso de los campos de tipo {{T|vinculo}}. Un {{T|vinculo}} representa una relación entre dos [[Contenedores|contenedores]] dentro del sistema. El siguiente código muestra cómo vincular una Entrada con una ficha de Tercero:

{{PR|tipo}} [Entrada] {{PR|es}} {{RE|contenedor}}
[Datos generales] {{PR|es}} {{T|formulario}}
[Número] {{PR|es}} {{T|timbre}}
-{{AT|certificado}}.{{AT|subsecuencia}}.{{AT|valor}} = $Copiartexto($texto($Año($Hoy)), 3, 2);
-{{AT|certificado}}.{{AT|valor}} = [&Valor_subsecuencia] + {{STR|"/"}} + [&Valor_secuencia];
-{{AT|certificado}}.{{AT|secuencia}}.{{AT|nombre}} = {{STR|"STR$ENTRADA"};
-{{AT|certificado}}.{{AT|secuencia}}.{{AT|longitud}} = 4;
[Fecha] {{PR|es}} {{T|fecha}}
-{{AT|edicion}}.{{AT|modo}} = copia;
-{{AT|edicion}}.{{AT|valor}} = [Número].[&Fecha];
[Remitente] {{PR|es}} {{T|vinculo}}
-{{AT|vinculo}}.{{AT|definicion}} = [Tercero];
-{{AT|vinculo}}.{{AT|etiqueta}} = [Datos generales].[Nombre/Razón social] + {{STR|" "}} + [Datos generales].[Apellidos];
-{{AT|vinculo}}.{{AT|valores}} = $matriz([Fichero de terceros].[Contenido]);
[Destinatario] {{PR|es}} {{T|texto}}
{{PR|fin}}
{{PR|fin}}

Como podrás observar, cambiamos el tipo del campo '''Remitente''' de {{T|texto}} a {{T|vinculo}}. Los tres atributos que vienen a continuación nos permiten configurar el comportamiento del {{T|vinculo}}:
:*El atributo {{AT|vinculo.definicion}} indica con qué tipo de [[Contenedores|contenedor]] puede establecerse el vínculo. En este caso indicamos que vincula con un objeto de tipo '''Tercero'''.
:*En el atributo {{AT|vinculo.etiqueta}} indicamos una expresión con el texto que debe aparecer en el campo cuando se establece el vínculo. En este caso, queremos que aparezca el nombre y los apellidos concatenados.
:*Por último, en el atributo {{AT|vinculo.valores}} indicamos la fuente de datos de la cuál obtendremos todos los [[Contenedores|contenedores]] con los que podremos vincular. En nuestro caso indicamos que es la colección '''Contenido''' del '''Fichero de terceros'''. Como este atributo espera una matriz, realizamos una conversión entre {{T|coleccion}} y {{T|matriz}} con la función '''$matriz'''.

Con estas seis líneas ya habremos establecido la relación entre '''Entrada''' y '''Tercero'''.

(Compila, actualiza y prueba ;).

<center>
{|
|align="center" |[[Imagen:Figura 12.jpg|thumb|250px|Cuadro de búsqueda para vincular. Este cuadro se abre al hacer clic en el icono vincular del campo Remitente.]]
|}
</center>

Como podrás observar, al final del campo '''Remitente''' aparece un triángulo. Si haces clic se abrirá un cuadro, similar al de la figura anterior, mostrando todas las fichas de '''Tercero''' que hay en la colección '''Contenido''' del '''Fichero de terceros'''. Si haces doble clic en alguna de las fichas que te muestra, podrás observar cómo queda el objeto vinculado.

==¿Qué es un enumerado? Añadiendo un "Destinatario" a las "Entradas"==
Ahora ya tenemos las entradas vinculadas con fichas de '''Tercero''', enriqueciendo el conjunto de la información almacenada y garantizando la coherencia en el sistema. ¿Podremos hacer algo con el campo '''Destinatario'''? La mayoría de las organizaciones tienen un conjunto de departamentos bien conocido y relativamente reducido. Siempre que se presente alguna documentación, ésta irá dirigida a un departamento concreto. Sería bastante cómodo disponer de la lista de departamentos para seleccionar uno, aunque quizás no merece la pena (al menos de momento) abstraerlos como un concepto del sistema. Los recursos de tipo {{RE|enumerado}} son una buena opción.

[Departamentos] {{PR|es}} {{RE|enumerado}}
{{AT|valores}}
{{STR|"Secretaría"}},
{{STR|"Administración"}},
{{STR|"Contabilidad"}},
{{STR|"Personal"}},
{{STR|"Dirección"}}
{{PR|fin}}

Un {{RE|enumerado}} es un recurso que actúa como una fuente de datos. Los valores que proporciona un enumerado pueden ponerse en una lista de cadenas separadas por comas (como en el ejemplo anterior) o bien se pueden obtenerse de un fichero CSV (commasepareted values). En la declaración anterior, definidos el objeto de sistema '''Departamentos''' de tipo {{RE|enumerado}} y definimos cinco valores con los nombres (hipotéticos) de los departamentos de la organización.

Ahora debemos modificar la definición del campo '''Destinatario''' en el formulario de '''Entrada''' para hacer uso del enumerado:

{{PR|tipo}} [Entrada] {{PR|es}} {{RE|contenedor}}
[Datos generales] {{PR|es}} {{T|formulario}}
[Número] {{PR|es}} {{T|timbre}}
-{{AT|certificado}}.{{AT|subsecuencia}}.{{AT|valor}} = $Copiartexto($texto($Año($Hoy)), 3, 2);
-{{AT|certificado}}.{{AT|valor}} = [&Valor_subsecuencia] + {{STR|"/"}} + [&Valor_secuencia];
-{{AT|certificado}}.{{AT|secuencia}}.{{AT|nombre}} = {{STR|"STR$ENTRADA"};
-{{AT|certificado}}.{{AT|secuencia}}.{{AT|longitud}} = 4;
[Fecha] {{PR|es}} {{T|fecha}}
-{{AT|edicion}}.{{AT|modo}} = copia;
-{{AT|edicion}}.{{AT|valor}} = [Número].[&Fecha];
[Remitente] {{PR|es}} {{T|vinculo}}
-{{AT|vinculo}}.{{AT|definicion}} = [Tercero];
-{{AT|vinculo}}.{{AT|etiqueta}} = [Datos generales].[Nombre/Razón social] + {{STR|" "}} + [Datos generales].[Apellidos];
-{{AT|vinculo}}.{{AT|valores}} = $matriz([Fichero de terceros].[Contenido]);
[Destinatario] {{PR|es}} {{T|texto}}
-{{AT|edicion}}.{{AT|valores}} = $matriz([Departamentos]);
{{PR|fin}}
{{PR|fin}}

Al compilar y actualizar, observarás cómo al final del campo '''Destinatario''' aparece un cuadrado doble. Haciendo clic te aparecerá la lista de valores.

==¿Y la documentación presentada? Introducir un campo tabla al formulario==
Un asunto que dejamos pendiente en la [[:Tarea_A:_Libros_y_registro_de_entrada_y_salida|Tarea A]] fue incluir en la definición del tipo '''Entrada''' la documentación presentada. Ahora que ya tenemos algo más de experiencia con ODL, es un buen momento para abordarlo.

Para reflejar la documentación que el '''Remitente''' presenta utilizaremos los campos de tipo {{T|tabla}}. Este tipo de campo permite definir una tabla en el formulario. Dentro de la tabla se definen campos (al igual que en el formulario) que actuarán como las columnas de la tabla.

{{PR|tipo}} [Entrada] {{PR|es}} {{RE|contenedor}}
[Datos generales] {{PR|es}} {{T|formulario}}
[Número] {{PR|es}} {{T|timbre}}
-{{AT|certificado}}.{{AT|subsecuencia}}.{{AT|valor}} = $Copiartexto($texto($Año($Hoy)), 3, 2);
-{{AT|certificado}}.{{AT|valor}} = [&Valor_subsecuencia] + {{STR|"/"}} + [&Valor_secuencia];
-{{AT|certificado}}.{{AT|secuencia}}.{{AT|nombre}} = {{STR|"STR$ENTRADA"}};
-{{AT|certificado}}.{{AT|secuencia}}.{{AT|longitud}} = 4;
[Fecha] {{PR|es}} {{T|fecha}}
-{{AT|edicion}}.{{AT|modo}} = copia;
-{{AT|edicion}}.{{AT|valor}} = [Número].[&Fecha];
[Remitente] {{PR|es}} {{T|vinculo}}
-{{AT|vinculo}}.{{AT|definicion}} = [Tercero];
-{{AT|vinculo}}.{{AT|etiqueta}} = [Datos generales].[Nombre/Razón social] + {{STR|" "}} + [Datos generales].[Apellidos];
-{{AT|vinculo}}.{{AT|valores}} = $matriz([Fichero de terceros].[Contenido]);
[Destinatario] {{PR|es}} {{T|texto}}
-{{AT|edicion}}.{{AT|valores}} = $matriz([Departamentos]);
[Documentación presentada] {{PR|es}} {{T|tabla}}
[Documento] {{PR|es}} {{T|texto}}
{{PR|fin}}
{{PR|fin}}
{{PR|fin}}

En el código anterior, añadimos la tabla '''Documentación presentada''' con una columna de tipo texto '''Documento'''. Si compilamos y actualizamos, ya podremos reflejar en el objeto '''Entrada''' cuál ha sido la documentación presentada en el Registro.

<center>
{|
|align="center" |[[Imagen:Figura 13.jpg|thumb|250px|Entrada con la tabla de Documentación presentada]]
|}
</center>

==¿Qué hemos aprendido?==
:*En ODL, todas las definiciones deben declararse antes de su uso.
:*Se pueden establecer vínculos entre [[Contenedores|contenedores]] haciendo uso de los campos de tipo vínculo.
:*Se pueden definir recursos de tipo enumerado, que actúan como fuentes de datos. Estos datos pueden especificarse en la definición o proporcionarse a través de un fichero CSV.
:*Los campos de tipo tabla permiten incrustar tablas en los formularios con el número de columnas que necesitemos.

==Ejercicios==
:*Traslada las modificaciones que hemos realizado sobre la definición de '''Entrada''' al tipo '''Salida'''. Ten en cuenta que, en este caso, el campo '''Origen''' hace referencia a un departamento de la organización y el '''Destinatario''' es un '''Tercero'''.
:*El atributo {{AT|apariencia.desplegable}} permite controlar que el conjunto de valores especificado en el atributo {{AT|edicion.valores}} se muestre como un desplegable en lugar de mostrar un cuadro. Prueba a agregar este atributo al campo '''Destinatario''' de la '''Entrada''' (debes poner apariencia.desplegable = verdadero).
:*El atributo {{AT|edicion.seleccion}} permite controlar que un campo de tipo {{T|texto}} sólo pueda tomar alguno de los valores especificados en el atributo {{AT|edicion.valores}}. Prueba a incluir este atributo al campo '''Destinatario''' de la '''Entrada''' (debes poner edicion.seleccion = verdadero) y comprueba que ya no puedes introducir texto libre en dicho campo.
:*Define una nueva ficha, '''Trabajador''', que represente a un trabajador de la organización. Esta ficha debe almacenar Nombre, Apellidos, Cargo, Sexo (a elegir entre Hombre y Mujer), Teléfono y Departamento del trabajador. Crea también un fichero de '''Trabajadores''' que contenga todas las fichas. Por último añade a la definición de Entrada un campo que sea '''Trabajador destinatario'''. Este campo debe vincular con alguna de las fichas de '''Trabajador'''.

==Siguiente tarea==

:*[[Tarea_D:_Validar_la_introducción_de_datos|Tarea D: Validar la introducción de datos]]

==Véase también==

:*[[Tarea_A:_Libros_y_registro_de_entrada_y_salida|Tarea A: Libros y registro de entrada y salida]]
:*[[Tarea_B:_Mejorando_la_numeración_del_registro|Tarea B: Mejorando la numeración del registro]]
:*[[Tarea_E:_Utilizar_el_registro_como_un_almacén_de_documentación|Tarea E: Utilizar el registro como un almacén de documentación]]
:*[[Tarea_F:_Abriendo_el_registro_al_resto_de_las_oficinas|Tarea F: Abriendo el registro al resto de las oficinas]]
:*[[Tarea_G:_Evitando_la_repliación_de_código|Tarea G: Evitando la repliación de código]]
:*[[Tarea_H:_Emitir_certificados_de_documentación|Tarea H: Emitir certificados de documentación]]
:*[[Tarea_I:_Creando_una_oficina_sin_papeles|Tarea I: Creando una oficina sin papeles]]
:*[[Tarea_J:_Importar_la_base_de_datos_de_terceros_de_otra_aplicación|Tarea J: Importar la base de datos de terceros de otra aplicación]]

Tarea B: Mejorando la numeración del registro

2009-08-04T09:18:03Z

Imhernandez: /* ¿Qué hemos aprendido? */

[[Construir_una_aplicación_paso_a_paso|Construir una aplicación paso a paso]]

El sistema anterior es suficiente para dar soporte para un Registro de entrada y salida, pero podemos mejorarlo bastante. Por ejemplo, ahora mismo tenemos que introducir el número de entrada a mano; por lo tanto, para cada vez que queramos hacer una nueva, tenemos que saber cuál era el último número. Parece un poco lioso, ¿no?. Lo mejor sería que la aplicación autonumerase la entrada cada vez que creásemos una nueva. Pues...¡manos a la obra!.

__TOC__

==Autonumerar "Entradas". Definición del campo timbre==
Como podrás ver, hemos cambiado el tipo del campo '''Número''' de {{T|texto}} a {{T|timbre}}. En ODL, un campo {{T|timbre}} es un tipo de campo que tiene la propiedad de ser autonumerado.

{{PR|tipo}} [Entrada] {{PR|es}} {{RE|contenedor}}
[Datos generales] {{PR|es}} {{T|formulario}}
[Número] {{PR|es}} {{T|timbre}}
-{{AT|certificado}}.{{AT|valor}} = [&Valor_secuencia];
-{{AT|certificado}}.{{AT|secuencia}}.{{AT|nombre}} = {{STR|"STR$ENTRADA"}};
-{{AT|certificado}}.{{AT|secuencia}}.{{AT|longitud}} = 4;
[Fecha] {{PR|es}} {{T|fecha}}
-{{AT|edicion}}.{{AT|modo}} = copia;
-{{AT|edicion}}.{{AT|valor}} = [Número].[&Fecha];
[Remitente] {{PR|es}} {{T|texto}}
[Destinatario] {{PR|es}} {{T|texto}}
{{PR|fin}}
{{PR|fin}}

En el atributo {{AT|certificado.valor}} especificamos el valor que aparecerá en el campo '''Número''' cuando la entrada se autonumere.

En el atributo {{AT|certificado.secuencia.nombre}} especificamos el nombre de la secuencia en la base de datos.

Por último, en el atributo {{AT|certificado.secuencia.longitud}} especificamos cuántos dígitos queremos que tenga la secuencia. En nuestro ejemplo, al poner longitud 4, el primer número será 0001, el segundo 0002, etc.

También, hemos cambiado el tipo del campo '''Fecha''' de {{T|texto}} a {{T|fecha}}. Además, hemos configurado este campo para que tome la fecha en que se numera el objeto. ¿Cómo? El atributo edicion permite configurar diversas opciones de comportamiento para los campos de un formulario (no importa de qué tipo sean). Al campo fecha le asignamos valor mediante las declaraciones {{AT|edicion.modo}} y {{AT|edicion.valor}}.

==Modos de edición de un campo==
En ODL, un campo de un formulario puede tener cuatro modos de edición:

:*'''normal''': es el modo de edición por defecto. Permite que los usuarios editen los campos libremente.
:*'''copia''': especifica que el valor del campo se recalcula cuando cambia el valor de otros campos, de acuerdo a la expresión indicada en el atributo {{AT|edicion.valor}}.
:*'''sugerencia''': especifica que el valor se calcula en base al valor de otros campos, de acuerdo a la expresión indicada en el atributo {{AT|edicion.valor}}, pero sólo cuando lo desea el usuario. El modo copia y sugerencia son muy parecidos; la diferencia radica en que el primero es automático y el segundo bajo petición del usuario.
:*'''referencia''': tiene el mismo comportamiento que un campo de copia, con la diferencia de que este campo es de sólo lectura y no se almacena en el sistema; se utiliza únicamente para mostrar datos dinámicos al usuario.

==Relación entre campo fecha y campo timbre==
En el ejemplo anterior, al campo '''Fecha''' se le asigna la fecha actual cuando cambia el valor del campo '''Número''' (la fecha la obtenemos a partir de la propiedad Fecha que tienen los campos timbres, que nos devuelven la fecha en la que fue emitido el timbre).

Compilamos, actualizamos y comprobamos los cambios.

Para ello hacemos clic en el '''Libro de entradas''' y, a continuación, clic en Nuevo.

<center>
{|
|align="center" |[[Imagen:Figura 7.jpg|thumb|250px|Formulario de entrada con el campo timbre]]
|}
</center>

Observa que el campo '''Número''' aparece ahora con un triángulo al final y que el campo '''Fecha''' aparece con dos botones. Uno con un cuadrado dentro de otro y otro con un desplegable. Haciendo clic en el triángulo al final del campo '''Número''' obtendrás un resultado similar al siguiente.

<center>
{|
|align="center" |[[Imagen:Figura 8.jpg|thumb|250px|Entrada numerada mediante el campo timbre]]
|}
</center>

El campo '''Fecha''' toma automáticamente la fecha actual y el campo '''Número''' aparece con el texto '''Numerado'''. '''Al guardar obtendrá el valor'''. Guardando la entrada, el sistema asignará un número definitivo a la entrada y hará el campo '''Número''' no editable, de modo que garantizará que ese número es único y no se puede cambiar.

==Añadir una subsecuencia al campo timbre==
Supongamos ahora que nuestro cliente quiere que las numeraciones de entrada y salida se reinicien cada año y que, además, los dos dígitos del año deben aparecer antes del número.

Para lograrlo, debemos definir una subsecuencia para el campo {{T|timbre}} y hacer que dependa del año actual. De esta forma, cada vez que cambie el valor de la subsecuencia, se reiniciará la numeración.

{{PR|tipo}} [Entrada] {{PR|es}} {{RE|contenedor}}
[Datos generales] {{PR|es}} {{T|formulario}}
[Número] {{PR|es}} {{T|timbre}}
-{{AT|certificado}}.{{AT|subsecuencia}}.{{AT|valor}} = $Copiartexto($texto($Año($Hoy)), 3, 2);
-{{AT|certificado}}.{{AT|valor}} = [&Valor_subsecuencia] + {{STR|"/"}} + [&Valor_secuencia];
-{{AT|certificado}}.{{AT|secuencia}}.{{AT|nombre}} = {{STR|"STR$ENTRADA"}};
-{{AT|certificado}}.{{AT|secuencia}}.{{AT|longitud}} = 4;
[Fecha] {{PR|es}} {{T|fecha}}
-{{AT|edicion}}.{{AT|modo}} = copia;
-{{AT|edicion}}.{{AT|valor}} = [Número].[&Fecha];
[Remitente] {{PR|es}} {{T|texto}}
[Destinatario] {{PR|es}} {{T|texto}}
{{PR|fin}}
{{PR|fin}}

Mediante la sentencia '''$Copiartexto($Texto($Año($Hoy)), 3, 2)''' obtenemos los dos últimos dígitos del año actual. Esta expresión se evaluará cada vez que se cree una nueva '''Entrada'''. Al cambiar el año, también cambiará el valor de la subsecuencia. Cuando esto ocurra, se reiniciará la numeración.

También hemos modificado el atributo {{AT|certificado.valor}} para que primero aparezca el valor de la subsecuencia (es decir, el año con dos dígitos), a continuación una barra (/) y, por último, el valor actual de la secuencia.

<blockquote style="background: #ffffcc; border: 1px solid black; padding: 1em;">

'''Funciones en ODL''' 

'''$Copiartexto''', '''$Texto''', '''$Año''' y '''$Hoy''' son funciones del lenguaje. '''$Hoy''' devuelve la fecha actual; '''$Año''' recibe como entrada una fecha y devuelve un entero con el año; la función '''$texto''' convierte el parámetro de entrada en una cadena de texto; por último, la función '''$Copiartexto''' recibe como entrada una texto y dos enteros, y devuelve una subcadena.

ODL ofrece una amplia biblioteca de funciones que permiten realizar diversas operaciones sobre el sistema de información que van de tareas simples, como la conversión de tipos, hasta operaciones más complejas, como lanzar sentencias SQL contra la base de datos y tratar el resultado devuelto.

En el documento Funciones de librería encontrarás una descripción detallada de todas las funciones que ofrece el lenguaje.</blockquote>

Compila y actualiza. Al crear y guardar una nueva entrada podrás ver cómo pone primero los dos dígitos del año. Prueba a cambiar la fecha del servidor para poner otro año. Verás cómo la numeración se reinicia.

<center>
{|
|align="center" |[[Imagen:Figura 9.jpg|thumb|250px|Entrada con subsecuencia]]
|}
</center>

==¿Qué hemos aprendido?==
:*En ODL existen cuatro modos de edición para los campos de un formulario: normal, copia, sugerencia y referencia. Estos modos de edición permiten automatizar la asignación de valores a los campos.
:*El modo referencia sólo sirve para mostrar datos dinámicos al usuario y no tiene persistencia en el sistema.
:*El campo {{T|timbre}} nos permite definir campos autonumerados. Mediante el campo {{AT|certificado.valor}} especificamos el texto que aparecerá cuando el campo se autonumere.
:*Para hacer que la numeración se reinicie en un campo timbre, debemos definir una subsecuencia a través del atributo {{AT|certificado.subsecuencia.valor}}.
:*ODL ofrece una amplia librería de funciones para manipular el sistema de información, y todas se invocan precedidas del carácter dólar ($).

==Ejercicios==
:*Realiza en el objeto '''Salida''' las mismas modificaciones que hemos realizado en '''Entrada'''. Ten en cuenta que el valor del atributo {{AT|certificado.secuencia.nombre}} tiene que ser diferente para que las numeraciones sean independientes.
:*El atributo {{AT|edicion.regla}} permite controlar cuando un campo es editable. Debes asignarle una expresión lógica. Si la expresión se evalúa a verdadero, el campo podrá editarse. Si la expresión se evalúa a falso, el campo no se podrá editar. Añade la sentencia edicion.regla = falso a la definición del campo '''Fecha''' y prueba a ver qué ocurre.
:*El atributo {{AT|certificado.estado}} de un campo timbre permite bloquear el objeto completo una vez el campo se haya numerado, de modo que el usuario no pueda modificar nada. Prueba añadir este atributo al campo '''Número''' de la '''Entrada''' (tienes que añadir certificado.estado = protegido) y comprueba qué es lo que ocurre.
:*¿Y si una vez protegido el objeto '''Entrada''' nos interesa editar alguno de los campos del formulario? El atributo {{AT|edicion.proteger}} nos permite indicar que un campo es editable. Este atributo tiene sentido cuando el campo timbre está protegido mediante el atributo {{AT|certificado.estado}}, y por consiguiente, la totalidad de los campos del objeto. Manteniendo el atributo certificado.estado = protegido del campo timbre , prueba a insertar edicion.proteger = falso en el campo '''Destinatario'''. Crea una nueva '''Entrada''', rellena sus campos y guarda el objeto. Vuelve a abrir el objeto creado, e intenta editar el campo '''Destinatario'''. Debería poder editarse.

==Siguiente tarea==

:*[[Tarea_C:_Evolucionando_la_arquitectura_del_registro|Tarea C: Evolucionando la introducción de datos]]

==Véase también==

:*[[Tarea_A:_Libros_y_registro_de_entrada_y_salida|Tarea A: Libros y registro de entrada y salida]]
:*[[Tarea_D:_Validar_la_introducción_de_datos|Tarea D: Validar la introducción de datos]]
:*[[Tarea_E:_Utilizar_el_registro_como_un_almacén_de_documentación|Tarea E: Utilizar el registro como un almacén de documentación]]
:*[[Tarea_F:_Abriendo_el_registro_al_resto_de_las_oficinas|Tarea F: Abriendo el registro al resto de las oficinas]]
:*[[Tarea_G:_Evitando_la_repliación_de_código|Tarea G: Evitando la repliación de código]]
:*[[Tarea_H:_Emitir_certificados_de_documentación|Tarea H: Emitir certificados de documentación]]
:*[[Tarea_I:_Creando_una_oficina_sin_papeles|Tarea I: Creando una oficina sin papeles]]
:*[[Tarea_J:_Importar_la_base_de_datos_de_terceros_de_otra_aplicación|Tarea J: Importar la base de datos de terceros de otra aplicación]]

Tarea B: Mejorando la numeración del registro

2009-08-04T09:16:56Z

Imhernandez: /* Añadir una subsecuencia al campo timbre */

[[Construir_una_aplicación_paso_a_paso|Construir una aplicación paso a paso]]

El sistema anterior es suficiente para dar soporte para un Registro de entrada y salida, pero podemos mejorarlo bastante. Por ejemplo, ahora mismo tenemos que introducir el número de entrada a mano; por lo tanto, para cada vez que queramos hacer una nueva, tenemos que saber cuál era el último número. Parece un poco lioso, ¿no?. Lo mejor sería que la aplicación autonumerase la entrada cada vez que creásemos una nueva. Pues...¡manos a la obra!.

__TOC__

==Autonumerar "Entradas". Definición del campo timbre==
Como podrás ver, hemos cambiado el tipo del campo '''Número''' de {{T|texto}} a {{T|timbre}}. En ODL, un campo {{T|timbre}} es un tipo de campo que tiene la propiedad de ser autonumerado.

{{PR|tipo}} [Entrada] {{PR|es}} {{RE|contenedor}}
[Datos generales] {{PR|es}} {{T|formulario}}
[Número] {{PR|es}} {{T|timbre}}
-{{AT|certificado}}.{{AT|valor}} = [&Valor_secuencia];
-{{AT|certificado}}.{{AT|secuencia}}.{{AT|nombre}} = {{STR|"STR$ENTRADA"}};
-{{AT|certificado}}.{{AT|secuencia}}.{{AT|longitud}} = 4;
[Fecha] {{PR|es}} {{T|fecha}}
-{{AT|edicion}}.{{AT|modo}} = copia;
-{{AT|edicion}}.{{AT|valor}} = [Número].[&Fecha];
[Remitente] {{PR|es}} {{T|texto}}
[Destinatario] {{PR|es}} {{T|texto}}
{{PR|fin}}
{{PR|fin}}

En el atributo {{AT|certificado.valor}} especificamos el valor que aparecerá en el campo '''Número''' cuando la entrada se autonumere.

En el atributo {{AT|certificado.secuencia.nombre}} especificamos el nombre de la secuencia en la base de datos.

Por último, en el atributo {{AT|certificado.secuencia.longitud}} especificamos cuántos dígitos queremos que tenga la secuencia. En nuestro ejemplo, al poner longitud 4, el primer número será 0001, el segundo 0002, etc.

También, hemos cambiado el tipo del campo '''Fecha''' de {{T|texto}} a {{T|fecha}}. Además, hemos configurado este campo para que tome la fecha en que se numera el objeto. ¿Cómo? El atributo edicion permite configurar diversas opciones de comportamiento para los campos de un formulario (no importa de qué tipo sean). Al campo fecha le asignamos valor mediante las declaraciones {{AT|edicion.modo}} y {{AT|edicion.valor}}.

==Modos de edición de un campo==
En ODL, un campo de un formulario puede tener cuatro modos de edición:

:*'''normal''': es el modo de edición por defecto. Permite que los usuarios editen los campos libremente.
:*'''copia''': especifica que el valor del campo se recalcula cuando cambia el valor de otros campos, de acuerdo a la expresión indicada en el atributo {{AT|edicion.valor}}.
:*'''sugerencia''': especifica que el valor se calcula en base al valor de otros campos, de acuerdo a la expresión indicada en el atributo {{AT|edicion.valor}}, pero sólo cuando lo desea el usuario. El modo copia y sugerencia son muy parecidos; la diferencia radica en que el primero es automático y el segundo bajo petición del usuario.
:*'''referencia''': tiene el mismo comportamiento que un campo de copia, con la diferencia de que este campo es de sólo lectura y no se almacena en el sistema; se utiliza únicamente para mostrar datos dinámicos al usuario.

==Relación entre campo fecha y campo timbre==
En el ejemplo anterior, al campo '''Fecha''' se le asigna la fecha actual cuando cambia el valor del campo '''Número''' (la fecha la obtenemos a partir de la propiedad Fecha que tienen los campos timbres, que nos devuelven la fecha en la que fue emitido el timbre).

Compilamos, actualizamos y comprobamos los cambios.

Para ello hacemos clic en el '''Libro de entradas''' y, a continuación, clic en Nuevo.

<center>
{|
|align="center" |[[Imagen:Figura 7.jpg|thumb|250px|Formulario de entrada con el campo timbre]]
|}
</center>

Observa que el campo '''Número''' aparece ahora con un triángulo al final y que el campo '''Fecha''' aparece con dos botones. Uno con un cuadrado dentro de otro y otro con un desplegable. Haciendo clic en el triángulo al final del campo '''Número''' obtendrás un resultado similar al siguiente.

<center>
{|
|align="center" |[[Imagen:Figura 8.jpg|thumb|250px|Entrada numerada mediante el campo timbre]]
|}
</center>

El campo '''Fecha''' toma automáticamente la fecha actual y el campo '''Número''' aparece con el texto '''Numerado'''. '''Al guardar obtendrá el valor'''. Guardando la entrada, el sistema asignará un número definitivo a la entrada y hará el campo '''Número''' no editable, de modo que garantizará que ese número es único y no se puede cambiar.

==Añadir una subsecuencia al campo timbre==
Supongamos ahora que nuestro cliente quiere que las numeraciones de entrada y salida se reinicien cada año y que, además, los dos dígitos del año deben aparecer antes del número.

Para lograrlo, debemos definir una subsecuencia para el campo {{T|timbre}} y hacer que dependa del año actual. De esta forma, cada vez que cambie el valor de la subsecuencia, se reiniciará la numeración.

{{PR|tipo}} [Entrada] {{PR|es}} {{RE|contenedor}}
[Datos generales] {{PR|es}} {{T|formulario}}
[Número] {{PR|es}} {{T|timbre}}
-{{AT|certificado}}.{{AT|subsecuencia}}.{{AT|valor}} = $Copiartexto($texto($Año($Hoy)), 3, 2);
-{{AT|certificado}}.{{AT|valor}} = [&Valor_subsecuencia] + {{STR|"/"}} + [&Valor_secuencia];
-{{AT|certificado}}.{{AT|secuencia}}.{{AT|nombre}} = {{STR|"STR$ENTRADA"}};
-{{AT|certificado}}.{{AT|secuencia}}.{{AT|longitud}} = 4;
[Fecha] {{PR|es}} {{T|fecha}}
-{{AT|edicion}}.{{AT|modo}} = copia;
-{{AT|edicion}}.{{AT|valor}} = [Número].[&Fecha];
[Remitente] {{PR|es}} {{T|texto}}
[Destinatario] {{PR|es}} {{T|texto}}
{{PR|fin}}
{{PR|fin}}

Mediante la sentencia '''$Copiartexto($Texto($Año($Hoy)), 3, 2)''' obtenemos los dos últimos dígitos del año actual. Esta expresión se evaluará cada vez que se cree una nueva '''Entrada'''. Al cambiar el año, también cambiará el valor de la subsecuencia. Cuando esto ocurra, se reiniciará la numeración.

También hemos modificado el atributo {{AT|certificado.valor}} para que primero aparezca el valor de la subsecuencia (es decir, el año con dos dígitos), a continuación una barra (/) y, por último, el valor actual de la secuencia.

<blockquote style="background: #ffffcc; border: 1px solid black; padding: 1em;">

'''Funciones en ODL''' 

'''$Copiartexto''', '''$Texto''', '''$Año''' y '''$Hoy''' son funciones del lenguaje. '''$Hoy''' devuelve la fecha actual; '''$Año''' recibe como entrada una fecha y devuelve un entero con el año; la función '''$texto''' convierte el parámetro de entrada en una cadena de texto; por último, la función '''$Copiartexto''' recibe como entrada una texto y dos enteros, y devuelve una subcadena.

ODL ofrece una amplia biblioteca de funciones que permiten realizar diversas operaciones sobre el sistema de información que van de tareas simples, como la conversión de tipos, hasta operaciones más complejas, como lanzar sentencias SQL contra la base de datos y tratar el resultado devuelto.

En el documento Funciones de librería encontrarás una descripción detallada de todas las funciones que ofrece el lenguaje.</blockquote>

Compila y actualiza. Al crear y guardar una nueva entrada podrás ver cómo pone primero los dos dígitos del año. Prueba a cambiar la fecha del servidor para poner otro año. Verás cómo la numeración se reinicia.

<center>
{|
|align="center" |[[Imagen:Figura 9.jpg|thumb|250px|Entrada con subsecuencia]]
|}
</center>

==¿Qué hemos aprendido?==
:*En ODL, existen cuatro modos de edición para los campos de un formulario: normal, copia, sugerencia y referencia. Estos modos de edición permiten automatizar la asignación de valores a los campos.
:*El modo referencia sólo sirve para mostrar datos dinámicos al usuario y no tiene persistencia en el sistema.
:*El campo {{T|timbre}} nos permite definir campos autonumerados. Mediante el campo {{AT|certificado.valor}} especificamos el texto que aparecerá cuando el campo se autonumere.
:*Para hacer que la numeración se reinicie en un campo timbre, debemos definir una subsecuencia a través del atributo {{AT|certificado.subsecuencia.valor}}.
:*ODL ofrece una amplia librería de funciones para manipular el sistema de información y todas se invocan precedidas del carácter dólar ($).

==Ejercicios==
:*Realiza en el objeto '''Salida''' las mismas modificaciones que hemos realizado en '''Entrada'''. Ten en cuenta que el valor del atributo {{AT|certificado.secuencia.nombre}} tiene que ser diferente para que las numeraciones sean independientes.
:*El atributo {{AT|edicion.regla}} permite controlar cuando un campo es editable. Debes asignarle una expresión lógica. Si la expresión se evalúa a verdadero, el campo podrá editarse. Si la expresión se evalúa a falso, el campo no se podrá editar. Añade la sentencia edicion.regla = falso a la definición del campo '''Fecha''' y prueba a ver qué ocurre.
:*El atributo {{AT|certificado.estado}} de un campo timbre permite bloquear el objeto completo una vez el campo se haya numerado, de modo que el usuario no pueda modificar nada. Prueba añadir este atributo al campo '''Número''' de la '''Entrada''' (tienes que añadir certificado.estado = protegido) y comprueba qué es lo que ocurre.
:*¿Y si una vez protegido el objeto '''Entrada''' nos interesa editar alguno de los campos del formulario? El atributo {{AT|edicion.proteger}} nos permite indicar que un campo es editable. Este atributo tiene sentido cuando el campo timbre está protegido mediante el atributo {{AT|certificado.estado}}, y por consiguiente, la totalidad de los campos del objeto. Manteniendo el atributo certificado.estado = protegido del campo timbre , prueba a insertar edicion.proteger = falso en el campo '''Destinatario'''. Crea una nueva '''Entrada''', rellena sus campos y guarda el objeto. Vuelve a abrir el objeto creado, e intenta editar el campo '''Destinatario'''. Debería poder editarse.

==Siguiente tarea==

:*[[Tarea_C:_Evolucionando_la_arquitectura_del_registro|Tarea C: Evolucionando la introducción de datos]]

==Véase también==

:*[[Tarea_A:_Libros_y_registro_de_entrada_y_salida|Tarea A: Libros y registro de entrada y salida]]
:*[[Tarea_D:_Validar_la_introducción_de_datos|Tarea D: Validar la introducción de datos]]
:*[[Tarea_E:_Utilizar_el_registro_como_un_almacén_de_documentación|Tarea E: Utilizar el registro como un almacén de documentación]]
:*[[Tarea_F:_Abriendo_el_registro_al_resto_de_las_oficinas|Tarea F: Abriendo el registro al resto de las oficinas]]
:*[[Tarea_G:_Evitando_la_repliación_de_código|Tarea G: Evitando la repliación de código]]
:*[[Tarea_H:_Emitir_certificados_de_documentación|Tarea H: Emitir certificados de documentación]]
:*[[Tarea_I:_Creando_una_oficina_sin_papeles|Tarea I: Creando una oficina sin papeles]]
:*[[Tarea_J:_Importar_la_base_de_datos_de_terceros_de_otra_aplicación|Tarea J: Importar la base de datos de terceros de otra aplicación]]

Tarea B: Mejorando la numeración del registro

2009-08-04T09:12:45Z

Imhernandez: /* Modos de edición de un campo */

[[Construir_una_aplicación_paso_a_paso|Construir una aplicación paso a paso]]

El sistema anterior es suficiente para dar soporte para un Registro de entrada y salida, pero podemos mejorarlo bastante. Por ejemplo, ahora mismo tenemos que introducir el número de entrada a mano; por lo tanto, para cada vez que queramos hacer una nueva, tenemos que saber cuál era el último número. Parece un poco lioso, ¿no?. Lo mejor sería que la aplicación autonumerase la entrada cada vez que creásemos una nueva. Pues...¡manos a la obra!.

__TOC__

==Autonumerar "Entradas". Definición del campo timbre==
Como podrás ver, hemos cambiado el tipo del campo '''Número''' de {{T|texto}} a {{T|timbre}}. En ODL, un campo {{T|timbre}} es un tipo de campo que tiene la propiedad de ser autonumerado.

{{PR|tipo}} [Entrada] {{PR|es}} {{RE|contenedor}}
[Datos generales] {{PR|es}} {{T|formulario}}
[Número] {{PR|es}} {{T|timbre}}
-{{AT|certificado}}.{{AT|valor}} = [&Valor_secuencia];
-{{AT|certificado}}.{{AT|secuencia}}.{{AT|nombre}} = {{STR|"STR$ENTRADA"}};
-{{AT|certificado}}.{{AT|secuencia}}.{{AT|longitud}} = 4;
[Fecha] {{PR|es}} {{T|fecha}}
-{{AT|edicion}}.{{AT|modo}} = copia;
-{{AT|edicion}}.{{AT|valor}} = [Número].[&Fecha];
[Remitente] {{PR|es}} {{T|texto}}
[Destinatario] {{PR|es}} {{T|texto}}
{{PR|fin}}
{{PR|fin}}

En el atributo {{AT|certificado.valor}} especificamos el valor que aparecerá en el campo '''Número''' cuando la entrada se autonumere.

En el atributo {{AT|certificado.secuencia.nombre}} especificamos el nombre de la secuencia en la base de datos.

Por último, en el atributo {{AT|certificado.secuencia.longitud}} especificamos cuántos dígitos queremos que tenga la secuencia. En nuestro ejemplo, al poner longitud 4, el primer número será 0001, el segundo 0002, etc.

También, hemos cambiado el tipo del campo '''Fecha''' de {{T|texto}} a {{T|fecha}}. Además, hemos configurado este campo para que tome la fecha en que se numera el objeto. ¿Cómo? El atributo edicion permite configurar diversas opciones de comportamiento para los campos de un formulario (no importa de qué tipo sean). Al campo fecha le asignamos valor mediante las declaraciones {{AT|edicion.modo}} y {{AT|edicion.valor}}.

==Modos de edición de un campo==
En ODL, un campo de un formulario puede tener cuatro modos de edición:

:*'''normal''': es el modo de edición por defecto. Permite que los usuarios editen los campos libremente.
:*'''copia''': especifica que el valor del campo se recalcula cuando cambia el valor de otros campos, de acuerdo a la expresión indicada en el atributo {{AT|edicion.valor}}.
:*'''sugerencia''': especifica que el valor se calcula en base al valor de otros campos, de acuerdo a la expresión indicada en el atributo {{AT|edicion.valor}}, pero sólo cuando lo desea el usuario. El modo copia y sugerencia son muy parecidos; la diferencia radica en que el primero es automático y el segundo bajo petición del usuario.
:*'''referencia''': tiene el mismo comportamiento que un campo de copia, con la diferencia de que este campo es de sólo lectura y no se almacena en el sistema; se utiliza únicamente para mostrar datos dinámicos al usuario.

==Relación entre campo fecha y campo timbre==
En el ejemplo anterior, al campo '''Fecha''' se le asigna la fecha actual cuando cambia el valor del campo '''Número''' (la fecha la obtenemos a partir de la propiedad Fecha que tienen los campos timbres, que nos devuelven la fecha en la que fue emitido el timbre).

Compilamos, actualizamos y comprobamos los cambios.

Para ello hacemos clic en el '''Libro de entradas''' y, a continuación, clic en Nuevo.

<center>
{|
|align="center" |[[Imagen:Figura 7.jpg|thumb|250px|Formulario de entrada con el campo timbre]]
|}
</center>

Observa que el campo '''Número''' aparece ahora con un triángulo al final y que el campo '''Fecha''' aparece con dos botones. Uno con un cuadrado dentro de otro y otro con un desplegable. Haciendo clic en el triángulo al final del campo '''Número''' obtendrás un resultado similar al siguiente.

<center>
{|
|align="center" |[[Imagen:Figura 8.jpg|thumb|250px|Entrada numerada mediante el campo timbre]]
|}
</center>

El campo '''Fecha''' toma automáticamente la fecha actual y el campo '''Número''' aparece con el texto '''Numerado'''. '''Al guardar obtendrá el valor'''. Guardando la entrada, el sistema asignará un número definitivo a la entrada y hará el campo '''Número''' no editable, de modo que garantizará que ese número es único y no se puede cambiar.

==Añadir una subsecuencia al campo timbre==
Supongamos ahora que nuestro cliente quiere que las numeraciones de entrada y salida se reinicien cada año y que, además, los dos dígitos del año deben aparecer antes del número.

Para lograrlo, debemos definir una subsecuencia para el campo {{T|timbre}} y hacer que dependa del año actual. De esta forma, cada vez que cambie el valor de la subsecuencia, se reiniciará la numeración.

{{PR|tipo}} [Entrada] {{PR|es}} {{RE|contenedor}}
[Datos generales] {{PR|es}} {{T|formulario}}
[Número] {{PR|es}} {{T|timbre}}
-{{AT|certificado}}.{{AT|subsecuencia}}.{{AT|valor}} = $Copiartexto($texto($Año($Hoy)), 3, 2);
-{{AT|certificado}}.{{AT|valor}} = [&Valor_subsecuencia] + {{STR|"/"}} + [&Valor_secuencia];
-{{AT|certificado}}.{{AT|secuencia}}.{{AT|nombre}} = {{STR|"STR$ENTRADA"}};
-{{AT|certificado}}.{{AT|secuencia}}.{{AT|longitud}} = 4;
[Fecha] {{PR|es}} {{T|fecha}}
-{{AT|edicion}}.{{AT|modo}} = copia;
-{{AT|edicion}}.{{AT|valor}} = [Número].[&Fecha];
[Remitente] {{PR|es}} {{T|texto}}
[Destinatario] {{PR|es}} {{T|texto}}
{{PR|fin}}
{{PR|fin}}

Mediante la sentencia '''$Copiartexto($Texto($Año($Hoy)), 3, 2)''' obtenemos los dos últimos dígitos del año actual. Esta expresión se evaluará cada vez que se cree una nueva '''Entrada'''. Al cambiar el año, también cambiará el valor de la subsecuencia. Cuando esto ocurra, se reiniciará la numeración.

También hemos modificado el atributo {{AT|certificado.valor}} para que primero aparezca el valor de la subsecuencia (es decir, el año con dos dígitos), a continuación una barra (/) y, por último, el valor actual de la secuencia.

<blockquote style="background: #ffffcc; border: 1px solid black; padding: 1em;">

'''Funciones en ODL''' 

'''$Copiartexto''', '''$Texto''', '''$Año''' y '''$Hoy''' son funciones del lenguaje. '''$Hoy''' devuelve la fecha actual; '''$Año''' recibe como entrada una fecha y devuelve un entero con el año; la función '''$texto''' convierte el parámetro de entrada en una cadena de texto; por último, la función '''$Copiartexto''' recibe como entrada una texto y dos enteros, y devuelve una subcadena.

ODL ofrece una amplia biblioteca de funciones que permiten realizar diversas operaciones sobre el sistema de información que van de tareas simples como la conversión de tipos hasta operaciones más complejas como lanzar sentencias SQL contra la base de datos y tratar el resultado devuelto.

En el documento Funciones de librería encontrarás una descripción detallada de todas las funciones que ofrece el lenguaje.</blockquote>

Compila y actualiza. Al crear y guardar una nueva entrada podrás ver cómo pone primero los dos dígitos del año. Prueba a cambiar la fecha del servidor para poner otro año. Verás cómo la numeración se reinicia.

<center>
{|
|align="center" |[[Imagen:Figura 9.jpg|thumb|250px|Entrada con subsecuencia]]
|}
</center>

==¿Qué hemos aprendido?==
:*En ODL, existen cuatro modos de edición para los campos de un formulario: normal, copia, sugerencia y referencia. Estos modos de edición permiten automatizar la asignación de valores a los campos.
:*El modo referencia sólo sirve para mostrar datos dinámicos al usuario y no tiene persistencia en el sistema.
:*El campo {{T|timbre}} nos permite definir campos autonumerados. Mediante el campo {{AT|certificado.valor}} especificamos el texto que aparecerá cuando el campo se autonumere.
:*Para hacer que la numeración se reinicie en un campo timbre, debemos definir una subsecuencia a través del atributo {{AT|certificado.subsecuencia.valor}}.
:*ODL ofrece una amplia librería de funciones para manipular el sistema de información y todas se invocan precedidas del carácter dólar ($).

==Ejercicios==
:*Realiza en el objeto '''Salida''' las mismas modificaciones que hemos realizado en '''Entrada'''. Ten en cuenta que el valor del atributo {{AT|certificado.secuencia.nombre}} tiene que ser diferente para que las numeraciones sean independientes.
:*El atributo {{AT|edicion.regla}} permite controlar cuando un campo es editable. Debes asignarle una expresión lógica. Si la expresión se evalúa a verdadero, el campo podrá editarse. Si la expresión se evalúa a falso, el campo no se podrá editar. Añade la sentencia edicion.regla = falso a la definición del campo '''Fecha''' y prueba a ver qué ocurre.
:*El atributo {{AT|certificado.estado}} de un campo timbre permite bloquear el objeto completo una vez el campo se haya numerado, de modo que el usuario no pueda modificar nada. Prueba añadir este atributo al campo '''Número''' de la '''Entrada''' (tienes que añadir certificado.estado = protegido) y comprueba qué es lo que ocurre.
:*¿Y si una vez protegido el objeto '''Entrada''' nos interesa editar alguno de los campos del formulario? El atributo {{AT|edicion.proteger}} nos permite indicar que un campo es editable. Este atributo tiene sentido cuando el campo timbre está protegido mediante el atributo {{AT|certificado.estado}}, y por consiguiente, la totalidad de los campos del objeto. Manteniendo el atributo certificado.estado = protegido del campo timbre , prueba a insertar edicion.proteger = falso en el campo '''Destinatario'''. Crea una nueva '''Entrada''', rellena sus campos y guarda el objeto. Vuelve a abrir el objeto creado, e intenta editar el campo '''Destinatario'''. Debería poder editarse.

==Siguiente tarea==

:*[[Tarea_C:_Evolucionando_la_arquitectura_del_registro|Tarea C: Evolucionando la introducción de datos]]

==Véase también==

:*[[Tarea_A:_Libros_y_registro_de_entrada_y_salida|Tarea A: Libros y registro de entrada y salida]]
:*[[Tarea_D:_Validar_la_introducción_de_datos|Tarea D: Validar la introducción de datos]]
:*[[Tarea_E:_Utilizar_el_registro_como_un_almacén_de_documentación|Tarea E: Utilizar el registro como un almacén de documentación]]
:*[[Tarea_F:_Abriendo_el_registro_al_resto_de_las_oficinas|Tarea F: Abriendo el registro al resto de las oficinas]]
:*[[Tarea_G:_Evitando_la_repliación_de_código|Tarea G: Evitando la repliación de código]]
:*[[Tarea_H:_Emitir_certificados_de_documentación|Tarea H: Emitir certificados de documentación]]
:*[[Tarea_I:_Creando_una_oficina_sin_papeles|Tarea I: Creando una oficina sin papeles]]
:*[[Tarea_J:_Importar_la_base_de_datos_de_terceros_de_otra_aplicación|Tarea J: Importar la base de datos de terceros de otra aplicación]]

Tarea A: Libros y registro de entrada y salida

2009-08-04T09:08:55Z

Imhernandez: /* Incluir la columna "Remitente" en el "Libro de Entrada" */

[[Construir_una_aplicación_paso_a_paso|Construir una aplicación paso a paso]]

En esta sección, vamos a implementar el registro de entrada y salida que acabamos de definir. Te recomendamos que trabajes en la máquina virtual que te hemos proporcionado. En caso de no tenerla, por favor, envía un correo a soporte@egeasy.es y te la haremos llegar.

__TOC__

==Contenedor, formulario y campos. Definiendo el concepto "Entrada"==
En el directorio '''#Source''', crea un fichero y llámalo '''Main.ndf'''. Ábrelo con tu editor favorito (te recomendamos EditPlus) y vamos a comenzar a trabajar.
Empezaremos definiendo el concepto '''Entrada''':

{{PR|unidad}} [Main]
{{PR|tipo}} [Entrada] {{PR|es}} {{RE|contenedor}}
[Datos generales] {{PR|es}} {{T|formulario}}
[Número] {{PR|es}} {{T|texto}}
[Fecha] {{PR|es}} {{T|texto}}
[Remitente] {{PR|es}} {{T|texto}}
[Destinatario] {{PR|es}} {{T|texto}}
{{PR|fin}}
{{PR|fin}}

¿Qué hemos hecho?

En primer lugar, hemos declarado el nombre de la unidad '''[Main]''' en la que estamos trabajando. Podemos definir nuestro sistema en cuantos ficheros queramos, pero, para que el compilador los analice, debemos darle un nombre de unidad a cada uno y, además, incluirlo en el fichero del proyecto, como veremos más adelante.

A continuación, hemos declarado el tipo Entrada diciendo que es un [[Contenedores|contenedor]]. [[Contenedores|Contenedor]] es un tipo nativo de la plataforma y una de las piezas fundamentales de ODL. Los [[Contenedores|contenedores]] nos permitirán definir, entre otros, formularios y colecciones de datos con gran facilidad.

Dentro del [[Contenedores|contenedor]] hemos definimos una componente formulario, indicando que vamos a declarar un formulario de datos. Seguidamente, decimos que este formulario tiene cuatro campos (de momento dejaremos fuera la documentación adjunta), todos de tipo texto.

Por último, cerramos la declaración de formulario y la declaración del [[Contenedores|contenedor]] Entrada.

==Crear un "Libro de entrada"==
Ya está. Ya podemos crear entradas en nuestro sistema. ¿Dónde? En el Libro de entrada:

[Libro de entrada] {{PR|es}} {{RE|contenedor}}
[Contenido] {{PR|es}} {{T|coleccion}}
-{{AT|nombre_tabla}} = {{STR|"TC$ENTRADAS"}}; 
{{PR|contiene}} [Entrada] 
{{PR|columna}} [Número]
-{{AT|columna_bd}}.{{AT|nombre}} = {{STR|"NUMERO"}};
-{{AT|origen}} = [Datos generales].[Número];
{{PR|columna}} [Fecha]
-{{AT|columna_bd}}.{{AT|nombre}} = {{STR|"FECHA"}};
-{{AT|origen}} = [Datos generales].[Fecha];
{{PR|fin}}
{{PR|fin}}

En este fragmento de código, definimos el '''Libro de entrada''' también como [[Contenedores|contenedor]]. Pero, ¿no ponemos {{PR|tipo}} antes de '''[Libro de entrada]'''? Antes de continuar es necesario aclarar un concepto.

==Declaraciones en ODL==
En ODL se pueden hacer dos clases de declaraciones:

:* Declaraciones de tipo
:* Declaraciones de sistema

Si se hace una declaración de tipo, estamos definiendo un objeto reutilizable y del que pueden existir varias instancias. Al hacer una declaración de sistema, estamos indicando que sólo existe una instancia. Por hacer un símil con la Programación Orientada a Objetos, las declaraciones de tipo serían las clases de las cuáles se crean instancias durante la vida de la aplicación y las declaraciones de sistema serían clases ''singleton''.

==¿Qué es una colección?==
El '''Libro de entrada''' es una definición de sistema; es decir, sólo existirá una instancia del libro en la aplicación. Por otro lado, podremos crear múltiples instancias de '''Entrada'''.

Dentro del Libro definimos una componente de tipo {{T|coleccion}}, a la cuál denominamos Contenido, indicando que este objeto tiene una colección de objetos. El tipo de objetos que puede contener se especifica mediante la sentencia contiene. En este caso, indicamos que la colección '''Contenido''' contiene objetos de tipo '''Entrada'''.

En la aplicación final, una colección se verá como una lista de objetos. Para generar dicha lista, el sistema crea una tabla en la base de datos con las columnas que se mostrarán en la vista. El nombre de esta tabla lo especificamos en el atributo {{AT|nombre_tabla}}. En el ejemplo, indicamos que, para esta colección, se cree la tabla '''TC$ENTRADAS'''.

Para añadir columnas a la vista utilizamos las declaraciones de columna. En nuestro libro, indicamos que queremos dos columnas: [Número] y [Fecha]. Para cada columna, deben indicarse al menos dos atributos:

:* Cómo se llamará la columna en la base de datos ({{AT|columna_bd.nombre}})
:* Qué dato se mostrará en la vista ({{AT|origen}})

Por ejemplo, para la columna [Número] decimos que en la base de datos se llamará '''NUMERO''' y que debe mostrar el campo '''[Datos generales].[Número]''' (es decir, el campo '''Número''' que está en el formulario '''[Datos generales]''' del objeto '''Entrada''').Aunque en nuestro ejemplo una columna muestra el valor de un solo campo, no
tenemos por qué limitarnos a este uso. Al atributo {{AT|origen}} se le puede asignar una expresión más compleja, como, por ejemplo, una concatenación de campos.

==¿Qué es una habitación?==
Lo único que falta para que nuestro libro sea operativo es hacerlo accesible para los usuarios. Para ello, debemos definir una habitación y ubicar en ella el '''Libro de entrada''':

[Registro de entrada y salida] {{PR|es}} {{RE|habitacion}}
{{PR|ubicado}} [Libro de entradas]
-{{AT|lugar}} = {{STR|"Libros"}};
{{PR|fin}}

Conceptualmente, una {{RE|habitacion}} representa una oficina o un departamento de la organización. Dentro de una {{RE|habitacion}} indicamos qué recursos de sistema van a estar disponibles para los usuarios de esa oficina. Esto nos ayuda a construir el sistema siguiendo la estructura organizativa de la corporación, pero, simultáneamente, a lograr que todos los recursos transversales sean accesibles allí donde sean necesarios. ¿Cómo? Realizando declaraciones de {{PR|ubicado}}, indicando qué recursos de sistema van a estar disponibles para los usuarios de dicha {{RE|habitacion}}.

Cada vez que ubiquemos un recurso, debemos indicar en el atributo lugar en qué grupo va a estar colocado. En nuestro ejemplo, decimos que queremos poner el '''Libro de entrada''' en el grupo '''Libros'''. No existe un conjunto de valores predefinidos para el atributo lugar. Se le puede asignar cualquier valor.

Ahora, sólo queda [[Cómo_compilar_paso_a_paso|'''generar el modelo''']], [[Cómo_instalar_un_centro_desde_cero|'''instalar e iniciar el centro''']].

Cuando lo hayamos hecho, arrancamos la aplicación egExplorer y lo que nos aparecerá será una lista con todas las habitaciones disponibles en el sistema, donde la única que aperecerá será '''Registro de entrada y salida'''.

<center>
{|
|align="center" |[[Imagen:Figura 2.jpg|thumb|250px|Habitaciones disponibles]]
|}
</center>

Si entramos en nuestra habitación, veremos a la izquierda el grupo Libros con el Libro de entrada ubicado y haciendo clic lo abriremos:

<center>
{|
|align="center" |[[Imagen:Figura 3.jpg|thumb|250px|Libro de entrada]]
|}
</center>

Haciendo clic en Nuevo crearemos una nueva entrada en el Libro. ¿Y qué aparece? El formulario que hemos definido:

<center>
{|
|align="center" |[[Imagen:Figura 4.jpg|thumb|250px|Formulario Datos generales del objeto Entrada]]
|}
</center>

Si creamos una entrada, la guardamos y volvemos al libro aparecerá el listado con un elemento mostrando el número y la fecha que hemos puesto:

<center>
{|
|align="center" |[[Imagen:Figura 5.jpg|thumb|250px|Libro de entradas con una Entrada creada]]
|}
</center>

==Incluir la columna "Remitente" en el "Libro de Entrada"==
¿Y si además queremos incluir el '''Remitente'''? Pues no tenemos más que volver a nuestro código y añadir la columna en la {{T|coleccion}}:

[Libro de entrada] {{PR|es}} {{RE|contenedor}}
[Contenido] {{PR|es}} {{T|coleccion}}
-{{AT|nombre_tabla}} = {{STR|"TC$ENTRADAS"}}; 
{{PR|contiene}} [Entrada] 
{{PR|columna}} [Número]
-{{AT|columna_bd}}.{{AT|nombre}} = {{STR|"NUMERO"}};
-{{AT|origen}} = [Datos generales].[Número];
{{PR|columna}} [Fecha]
-{{AT|columna_bd}}.{{AT|nombre}} = {{STR|"FECHA"}};
-{{AT|origen}} = [Datos generales].[Fecha];
{{PR|columna}} [Remitente]
-{{AT|columna_bd}}.{{AT|nombre}} = {{STR|"REMITENTE"}};
-{{AT|origen}} = [Datos generales].[Remitente];
{{PR|fin}}
{{PR|fin}}

Compilamos y actualizamos el modelo. Al hacerlo, en la tabla '''TC$ENTRADAS''' se añadirá la columna REMITENTE. Si volvemos al egExplorer y abrimos el '''Libro de entrada''' veremos la columna Remitente incorporada.

<center>
{|
|align="center" |[[Imagen:Figura 6.jpg|thumb|250px|Entrada con la columna remitente]]
|}
</center>

<blockquote style="background: #ffffcc; border: 1px solid black; padding: 1em;">
'''Y el campo Destinatario, ¿no lo ponemos como columna? Entonces, ¿dónde se almacena?''' Es el momento de explicar cómo se almacenan los objetos en la plataforma egEasy. egEasy utiliza una base de datos orientada a objetos, en vez de un esquema clásico de base de datos relacional. Con esta arquitectura no tenemos una tabla para cada objeto nuevo que se crea en la base de datos. En su lugar, hay una sola tabla (eg$resources) en la que se almacenan todos los recursos del sistema. La administración de esta tabla es completamente transparente para el desarrollador, y dentro de ella todos los campos y atributos de cada objeto se guardan serializados en un campo binario.

Entonces, ¿para qué nos sirve una colección? Con la definición de una colección logramos dos objetivos. En primer lugar, definimos el ámbito en el que se pueden crear los objetos (el objeto '''Entrada''' se puede crear en la componente '''Contenido''' del '''Libro de entrada'''). Por otro lado, proporcionamos un método rápido y eficiente para mostrar una lista de objetos; si no utilizásemos las colecciones, en el momento de mostrar una lista habría que deserializar uno por uno los objetos, una operación que podría resultar muy lenta.</blockquote>

==Definición del "Libro de salida"==
La definición del libro de salida es prácticamente igual al de entradas:

{{PR|tipo}} [Salida] {{PR|es}} {{RE|contenedor}}
[Datos generales] {{PR|es}} {{T|formulario}}
[Número] {{PR|es}} {{T|texto}}
[Fecha] {{PR|es}} {{T|texto}}
[Remitente] {{PR|es}} {{T|texto}}
[Destinatario] {{PR|es}} {{T|texto}}
{{PR|fin}}
{{PR|fin}} 
[Libro de salida] {{PR|es}} {{RE|contenedor}}
[Contenido] {{PR|es}} {{T|coleccion}}
-{{AT|nombre_tabla}} = {{STR|"TC$SALIDAS"}}; 
{{PR|contiene}} [Salida] 
{{PR|columna}} [Número]
-{{AT|columna_bd}}.{{AT|nombre}} = {{STR|"NUMERO"}};
-{{AT|origen}} = [Datos generales].[Número];
{{PR|columna}} [Fecha]
-{{AT|columna_bd}}.{{AT|nombre}} = {{STR|"FECHA"}};
-{{AT|origen}} = [Datos generales].[Fecha];
{{PR|columna}} [Remitente]
-{{AT|columna_bd}}.{{AT|nombre}} = {{STR|"REMITENTE"}};
-{{AT|origen}} = [Datos generales].[Remitente];
{{PR|fin}}
{{PR|fin}} 
[Registro de entrada y salida] {{PR|es}} {{RE|habitacion}}
{{PR|ubicado}} [Libro de entrada]
-{{AT|lugar}} = {{STR|"Libros"}};
{{PR|fin}}

Para hacerlo visible para los usuarios, debemos ubicarlo en la oficina:

[Registro de entrada y salida] {{PR|es}} {{RE|habitacion}}
{{PR|ubicado}} [Libro de entrada]
-{{AT|lugar}} = {{STR|"Libros"}};
{{PR|ubicado}} [Libro de salida]
-{{AT|lugar}} = {{STR|"Libros"}};
{{PR|fin}}

==¿Qué hemos aprendido?==

:* En ODL existen dos clases de declaraciones: de tipo (podemos crear instancias de ellas) y de sistema (sólo existe una intancia).
:* El [[Contenedores|contenedor]] es uno de los tipos fundamentales de ODL y nos permite definir en su contexto componentes tales como formularios y colecciones de datos.
:* Las colecciones se muestran en la aplicación final como listas de objetos en las que podemos crear [[Contenedores|contenedores]].
:* Podemos añadir columnas a una colección haciendo uso de la sentencia columna.
:* La declaraciones de habitación nos permiten ubicar los recursos para hacerlos visibles a los usuarios.

==Siguiente tarea==

:*[[Tarea_B:_Mejorando_la_numeración_del_registro|Tarea B: Mejorando la numeración del registro]]

==Véase también==

:*[[Tarea_C:_Evolucionando_la_arquitectura_del_registro|Tarea C: Evolucionando la introducción de datos]]
:*[[Tarea_D:_Validar_la_introducción_de_datos|Tarea D: Validar la introducción de datos]]
:*[[Tarea_E:_Utilizar_el_registro_como_un_almacén_de_documentación|Tarea E: Utilizar el registro como un almacén de documentación]]
:*[[Tarea_F:_Abriendo_el_registro_al_resto_de_las_oficinas|Tarea F: Abriendo el registro al resto de las oficinas]]
:*[[Tarea_G:_Evitando_la_repliación_de_código|Tarea G: Evitando la repliación de código]]
:*[[Tarea_H:_Emitir_certificados_de_documentación|Tarea H: Emitir certificados de documentación]]
:*[[Tarea_I:_Creando_una_oficina_sin_papeles|Tarea I: Creando una oficina sin papeles]]
:*[[Tarea_J:_Importar_la_base_de_datos_de_terceros_de_otra_aplicación|Tarea J: Importar la base de datos de terceros de otra aplicación]]

Tarea A: Libros y registro de entrada y salida

2009-08-04T09:01:19Z

Imhernandez: /* ¿Qué es una colección? */

[[Construir_una_aplicación_paso_a_paso|Construir una aplicación paso a paso]]

En esta sección, vamos a implementar el registro de entrada y salida que acabamos de definir. Te recomendamos que trabajes en la máquina virtual que te hemos proporcionado. En caso de no tenerla, por favor, envía un correo a soporte@egeasy.es y te la haremos llegar.

__TOC__

==Contenedor, formulario y campos. Definiendo el concepto "Entrada"==
En el directorio '''#Source''', crea un fichero y llámalo '''Main.ndf'''. Ábrelo con tu editor favorito (te recomendamos EditPlus) y vamos a comenzar a trabajar.
Empezaremos definiendo el concepto '''Entrada''':

{{PR|unidad}} [Main]
{{PR|tipo}} [Entrada] {{PR|es}} {{RE|contenedor}}
[Datos generales] {{PR|es}} {{T|formulario}}
[Número] {{PR|es}} {{T|texto}}
[Fecha] {{PR|es}} {{T|texto}}
[Remitente] {{PR|es}} {{T|texto}}
[Destinatario] {{PR|es}} {{T|texto}}
{{PR|fin}}
{{PR|fin}}

¿Qué hemos hecho?

En primer lugar, hemos declarado el nombre de la unidad '''[Main]''' en la que estamos trabajando. Podemos definir nuestro sistema en cuantos ficheros queramos, pero, para que el compilador los analice, debemos darle un nombre de unidad a cada uno y, además, incluirlo en el fichero del proyecto, como veremos más adelante.

A continuación, hemos declarado el tipo Entrada diciendo que es un [[Contenedores|contenedor]]. [[Contenedores|Contenedor]] es un tipo nativo de la plataforma y una de las piezas fundamentales de ODL. Los [[Contenedores|contenedores]] nos permitirán definir, entre otros, formularios y colecciones de datos con gran facilidad.

Dentro del [[Contenedores|contenedor]] hemos definimos una componente formulario, indicando que vamos a declarar un formulario de datos. Seguidamente, decimos que este formulario tiene cuatro campos (de momento dejaremos fuera la documentación adjunta), todos de tipo texto.

Por último, cerramos la declaración de formulario y la declaración del [[Contenedores|contenedor]] Entrada.

==Crear un "Libro de entrada"==
Ya está. Ya podemos crear entradas en nuestro sistema. ¿Dónde? En el Libro de entrada:

[Libro de entrada] {{PR|es}} {{RE|contenedor}}
[Contenido] {{PR|es}} {{T|coleccion}}
-{{AT|nombre_tabla}} = {{STR|"TC$ENTRADAS"}}; 
{{PR|contiene}} [Entrada] 
{{PR|columna}} [Número]
-{{AT|columna_bd}}.{{AT|nombre}} = {{STR|"NUMERO"}};
-{{AT|origen}} = [Datos generales].[Número];
{{PR|columna}} [Fecha]
-{{AT|columna_bd}}.{{AT|nombre}} = {{STR|"FECHA"}};
-{{AT|origen}} = [Datos generales].[Fecha];
{{PR|fin}}
{{PR|fin}}

En este fragmento de código, definimos el '''Libro de entrada''' también como [[Contenedores|contenedor]]. Pero, ¿no ponemos {{PR|tipo}} antes de '''[Libro de entrada]'''? Antes de continuar es necesario aclarar un concepto.

==Declaraciones en ODL==
En ODL se pueden hacer dos clases de declaraciones:

:* Declaraciones de tipo
:* Declaraciones de sistema

Si se hace una declaración de tipo, estamos definiendo un objeto reutilizable y del que pueden existir varias instancias. Al hacer una declaración de sistema, estamos indicando que sólo existe una instancia. Por hacer un símil con la Programación Orientada a Objetos, las declaraciones de tipo serían las clases de las cuáles se crean instancias durante la vida de la aplicación y las declaraciones de sistema serían clases ''singleton''.

==¿Qué es una colección?==
El '''Libro de entrada''' es una definición de sistema; es decir, sólo existirá una instancia del libro en la aplicación. Por otro lado, podremos crear múltiples instancias de '''Entrada'''.

Dentro del Libro definimos una componente de tipo {{T|coleccion}}, a la cuál denominamos Contenido, indicando que este objeto tiene una colección de objetos. El tipo de objetos que puede contener se especifica mediante la sentencia contiene. En este caso, indicamos que la colección '''Contenido''' contiene objetos de tipo '''Entrada'''.

En la aplicación final, una colección se verá como una lista de objetos. Para generar dicha lista, el sistema crea una tabla en la base de datos con las columnas que se mostrarán en la vista. El nombre de esta tabla lo especificamos en el atributo {{AT|nombre_tabla}}. En el ejemplo, indicamos que, para esta colección, se cree la tabla '''TC$ENTRADAS'''.

Para añadir columnas a la vista utilizamos las declaraciones de columna. En nuestro libro, indicamos que queremos dos columnas: [Número] y [Fecha]. Para cada columna, deben indicarse al menos dos atributos:

:* Cómo se llamará la columna en la base de datos ({{AT|columna_bd.nombre}})
:* Qué dato se mostrará en la vista ({{AT|origen}})

Por ejemplo, para la columna [Número] decimos que en la base de datos se llamará '''NUMERO''' y que debe mostrar el campo '''[Datos generales].[Número]''' (es decir, el campo '''Número''' que está en el formulario '''[Datos generales]''' del objeto '''Entrada''').Aunque en nuestro ejemplo una columna muestra el valor de un solo campo, no
tenemos por qué limitarnos a este uso. Al atributo {{AT|origen}} se le puede asignar una expresión más compleja, como, por ejemplo, una concatenación de campos.

==¿Qué es una habitación?==
Lo único que falta para que nuestro libro sea operativo es hacerlo accesible para los usuarios. Para ello, debemos definir una habitación y ubicar en ella el '''Libro de entrada''':

[Registro de entrada y salida] {{PR|es}} {{RE|habitacion}}
{{PR|ubicado}} [Libro de entradas]
-{{AT|lugar}} = {{STR|"Libros"}};
{{PR|fin}}

Conceptualmente, una {{RE|habitacion}} representa una oficina o un departamento de la organización. Dentro de una {{RE|habitacion}} indicamos qué recursos de sistema van a estar disponibles para los usuarios de esa oficina. Esto nos ayuda a construir el sistema siguiendo la estructura organizativa de la corporación, pero, simultáneamente, a lograr que todos los recursos transversales sean accesibles allí donde sean necesarios. ¿Cómo? Realizando declaraciones de {{PR|ubicado}}, indicando qué recursos de sistema van a estar disponibles para los usuarios de dicha {{RE|habitacion}}.

Cada vez que ubiquemos un recurso, debemos indicar en el atributo lugar en qué grupo va a estar colocado. En nuestro ejemplo, decimos que queremos poner el '''Libro de entrada''' en el grupo '''Libros'''. No existe un conjunto de valores predefinidos para el atributo lugar. Se le puede asignar cualquier valor.

Ahora, sólo queda [[Cómo_compilar_paso_a_paso|'''generar el modelo''']], [[Cómo_instalar_un_centro_desde_cero|'''instalar e iniciar el centro''']].

Cuando lo hayamos hecho, arrancamos la aplicación egExplorer y lo que nos aparecerá será una lista con todas las habitaciones disponibles en el sistema, donde la única que aperecerá será '''Registro de entrada y salida'''.

<center>
{|
|align="center" |[[Imagen:Figura 2.jpg|thumb|250px|Habitaciones disponibles]]
|}
</center>

Si entramos en nuestra habitación, veremos a la izquierda el grupo Libros con el Libro de entrada ubicado y haciendo clic lo abriremos:

<center>
{|
|align="center" |[[Imagen:Figura 3.jpg|thumb|250px|Libro de entrada]]
|}
</center>

Haciendo clic en Nuevo crearemos una nueva entrada en el Libro. ¿Y qué aparece? El formulario que hemos definido:

<center>
{|
|align="center" |[[Imagen:Figura 4.jpg|thumb|250px|Formulario Datos generales del objeto Entrada]]
|}
</center>

Si creamos una entrada, la guardamos y volvemos al libro aparecerá el listado con un elemento mostrando el número y la fecha que hemos puesto:

<center>
{|
|align="center" |[[Imagen:Figura 5.jpg|thumb|250px|Libro de entradas con una Entrada creada]]
|}
</center>

==Incluir la columna "Remitente" en el "Libro de Entrada"==
¿Y si además queremos incluir el '''Remitente'''? Pues no tenemos más que volver a nuestro código y añadir la columna en la {{T|coleccion}}:

[Libro de entrada] {{PR|es}} {{RE|contenedor}}
[Contenido] {{PR|es}} {{T|coleccion}}
-{{AT|nombre_tabla}} = {{STR|"TC$ENTRADAS"}}; 
{{PR|contiene}} [Entrada] 
{{PR|columna}} [Número]
-{{AT|columna_bd}}.{{AT|nombre}} = {{STR|"NUMERO"}};
-{{AT|origen}} = [Datos generales].[Número];
{{PR|columna}} [Fecha]
-{{AT|columna_bd}}.{{AT|nombre}} = {{STR|"FECHA"}};
-{{AT|origen}} = [Datos generales].[Fecha];
{{PR|columna}} [Remitente]
-{{AT|columna_bd}}.{{AT|nombre}} = {{STR|"REMITENTE"}};
-{{AT|origen}} = [Datos generales].[Remitente];
{{PR|fin}}
{{PR|fin}}

Compilamos y actualizamos el modelo. Al hacerlo, en la tabla '''TC$ENTRADAS''' se añadirá la columna REMITENTE. Si volvemos al egExplorer y abrimos el '''Libro de entrada''' veremos la columna Remitente incorporada.

<center>
{|
|align="center" |[[Imagen:Figura 6.jpg|thumb|250px|Entrada con la columna remitente]]
|}
</center>

<blockquote style="background: #ffffcc; border: 1px solid black; padding: 1em;">
'''Y el campo Destinatario, ¿no lo ponemos como columna? Entonces, ¿dónde se almacena?''' Es el momento de explicar cómo se almacenan los objetos en la plataforma egEasy. egEasy utiliza una base de datos orientada a objetos, en vez de un esquema clásico de base de datos relacional. Con esta arquitectura no tenemos una tabla para cada objeto nuevo que se crea en la base de datos. En su lugar, hay una sola tabla (eg$resources) en la que se almacenan todos los recursos del sistema. La administración de esta tabla es completamente transparente para el desarrollador y dentro de ella todos los campos y atributos de cada objeto se guardan serializados en un campo binario.

Entonces, ¿para qué nos sirve una colección? Con la definición de una colección logramos dos objetivos. En primer lugar, definimos el ámbito en el que se pueden crear los objetos (el objeto '''Entrada''' se puede crear en la componente '''Contenido''' del '''Libro de entrada'''). Por otro lado, proporcionamos un método rápido y eficiente para mostrar una lista de objetos; si no utilizásemos las colecciones, en el momento de mostrar una lista habría que deserializar uno por uno los objetos, una operación que podría resultar muy lenta.</blockquote>

==Definición del "Libro de salida"==
La definición del libro de salida es prácticamente igual al de entradas:

{{PR|tipo}} [Salida] {{PR|es}} {{RE|contenedor}}
[Datos generales] {{PR|es}} {{T|formulario}}
[Número] {{PR|es}} {{T|texto}}
[Fecha] {{PR|es}} {{T|texto}}
[Remitente] {{PR|es}} {{T|texto}}
[Destinatario] {{PR|es}} {{T|texto}}
{{PR|fin}}
{{PR|fin}} 
[Libro de salida] {{PR|es}} {{RE|contenedor}}
[Contenido] {{PR|es}} {{T|coleccion}}
-{{AT|nombre_tabla}} = {{STR|"TC$SALIDAS"}}; 
{{PR|contiene}} [Salida] 
{{PR|columna}} [Número]
-{{AT|columna_bd}}.{{AT|nombre}} = {{STR|"NUMERO"}};
-{{AT|origen}} = [Datos generales].[Número];
{{PR|columna}} [Fecha]
-{{AT|columna_bd}}.{{AT|nombre}} = {{STR|"FECHA"}};
-{{AT|origen}} = [Datos generales].[Fecha];
{{PR|columna}} [Remitente]
-{{AT|columna_bd}}.{{AT|nombre}} = {{STR|"REMITENTE"}};
-{{AT|origen}} = [Datos generales].[Remitente];
{{PR|fin}}
{{PR|fin}} 
[Registro de entrada y salida] {{PR|es}} {{RE|habitacion}}
{{PR|ubicado}} [Libro de entrada]
-{{AT|lugar}} = {{STR|"Libros"}};
{{PR|fin}}

Para hacerlo visible para los usuarios, debemos ubicarlo en la oficina:

[Registro de entrada y salida] {{PR|es}} {{RE|habitacion}}
{{PR|ubicado}} [Libro de entrada]
-{{AT|lugar}} = {{STR|"Libros"}};
{{PR|ubicado}} [Libro de salida]
-{{AT|lugar}} = {{STR|"Libros"}};
{{PR|fin}}

==¿Qué hemos aprendido?==

:* En ODL existen dos clases de declaraciones: de tipo (podemos crear instancias de ellas) y de sistema (sólo existe una intancia).
:* El [[Contenedores|contenedor]] es uno de los tipos fundamentales de ODL y nos permite definir en su contexto componentes tales como formularios y colecciones de datos.
:* Las colecciones se muestran en la aplicación final como listas de objetos en las que podemos crear [[Contenedores|contenedores]].
:* Podemos añadir columnas a una colección haciendo uso de la sentencia columna.
:* La declaraciones de habitación nos permiten ubicar los recursos para hacerlos visibles a los usuarios.

==Siguiente tarea==

:*[[Tarea_B:_Mejorando_la_numeración_del_registro|Tarea B: Mejorando la numeración del registro]]

==Véase también==

:*[[Tarea_C:_Evolucionando_la_arquitectura_del_registro|Tarea C: Evolucionando la introducción de datos]]
:*[[Tarea_D:_Validar_la_introducción_de_datos|Tarea D: Validar la introducción de datos]]
:*[[Tarea_E:_Utilizar_el_registro_como_un_almacén_de_documentación|Tarea E: Utilizar el registro como un almacén de documentación]]
:*[[Tarea_F:_Abriendo_el_registro_al_resto_de_las_oficinas|Tarea F: Abriendo el registro al resto de las oficinas]]
:*[[Tarea_G:_Evitando_la_repliación_de_código|Tarea G: Evitando la repliación de código]]
:*[[Tarea_H:_Emitir_certificados_de_documentación|Tarea H: Emitir certificados de documentación]]
:*[[Tarea_I:_Creando_una_oficina_sin_papeles|Tarea I: Creando una oficina sin papeles]]
:*[[Tarea_J:_Importar_la_base_de_datos_de_terceros_de_otra_aplicación|Tarea J: Importar la base de datos de terceros de otra aplicación]]

Tarea A: Libros y registro de entrada y salida

2009-08-04T08:57:12Z

Imhernandez: /* Contenedor, formulario y campos. Definiendo el concepto "Entrada" */

[[Construir_una_aplicación_paso_a_paso|Construir una aplicación paso a paso]]

En esta sección, vamos a implementar el registro de entrada y salida que acabamos de definir. Te recomendamos que trabajes en la máquina virtual que te hemos proporcionado. En caso de no tenerla, por favor, envía un correo a soporte@egeasy.es y te la haremos llegar.

__TOC__

==Contenedor, formulario y campos. Definiendo el concepto "Entrada"==
En el directorio '''#Source''', crea un fichero y llámalo '''Main.ndf'''. Ábrelo con tu editor favorito (te recomendamos EditPlus) y vamos a comenzar a trabajar.
Empezaremos definiendo el concepto '''Entrada''':

{{PR|unidad}} [Main]
{{PR|tipo}} [Entrada] {{PR|es}} {{RE|contenedor}}
[Datos generales] {{PR|es}} {{T|formulario}}
[Número] {{PR|es}} {{T|texto}}
[Fecha] {{PR|es}} {{T|texto}}
[Remitente] {{PR|es}} {{T|texto}}
[Destinatario] {{PR|es}} {{T|texto}}
{{PR|fin}}
{{PR|fin}}

¿Qué hemos hecho?

En primer lugar, hemos declarado el nombre de la unidad '''[Main]''' en la que estamos trabajando. Podemos definir nuestro sistema en cuantos ficheros queramos, pero, para que el compilador los analice, debemos darle un nombre de unidad a cada uno y, además, incluirlo en el fichero del proyecto, como veremos más adelante.

A continuación, hemos declarado el tipo Entrada diciendo que es un [[Contenedores|contenedor]]. [[Contenedores|Contenedor]] es un tipo nativo de la plataforma y una de las piezas fundamentales de ODL. Los [[Contenedores|contenedores]] nos permitirán definir, entre otros, formularios y colecciones de datos con gran facilidad.

Dentro del [[Contenedores|contenedor]] hemos definimos una componente formulario, indicando que vamos a declarar un formulario de datos. Seguidamente, decimos que este formulario tiene cuatro campos (de momento dejaremos fuera la documentación adjunta), todos de tipo texto.

Por último, cerramos la declaración de formulario y la declaración del [[Contenedores|contenedor]] Entrada.

==Crear un "Libro de entrada"==
Ya está. Ya podemos crear entradas en nuestro sistema. ¿Dónde? En el Libro de entrada:

[Libro de entrada] {{PR|es}} {{RE|contenedor}}
[Contenido] {{PR|es}} {{T|coleccion}}
-{{AT|nombre_tabla}} = {{STR|"TC$ENTRADAS"}}; 
{{PR|contiene}} [Entrada] 
{{PR|columna}} [Número]
-{{AT|columna_bd}}.{{AT|nombre}} = {{STR|"NUMERO"}};
-{{AT|origen}} = [Datos generales].[Número];
{{PR|columna}} [Fecha]
-{{AT|columna_bd}}.{{AT|nombre}} = {{STR|"FECHA"}};
-{{AT|origen}} = [Datos generales].[Fecha];
{{PR|fin}}
{{PR|fin}}

En este fragmento de código, definimos el '''Libro de entrada''' también como [[Contenedores|contenedor]]. Pero, ¿no ponemos {{PR|tipo}} antes de '''[Libro de entrada]'''? Antes de continuar es necesario aclarar un concepto.

==Declaraciones en ODL==
En ODL se pueden hacer dos clases de declaraciones:

:* Declaraciones de tipo
:* Declaraciones de sistema

Si se hace una declaración de tipo, estamos definiendo un objeto reutilizable y del que pueden existir varias instancias. Al hacer una declaración de sistema, estamos indicando que sólo existe una instancia. Por hacer un símil con la Programación Orientada a Objetos, las declaraciones de tipo serían las clases de las cuáles se crean instancias durante la vida de la aplicación y las declaraciones de sistema serían clases ''singleton''.

==¿Qué es una colección?==
El '''Libro de entrada''' es una definición de sistema; es decir, sólo existirá una instancia del libro en la aplicación. Por otro lado, podremos crear múltiples instancias de '''Entrada'''.

Dentro del Libro definimos una componente de tipo {{T|coleccion}} a la cuál denominamos Contenido, indicando que este objeto tiene una colección de objetos. El tipo de objetos que puede contener se especifica mediante la sentencia contiene. En este caso, indicamos que la colección '''Contenido''' contiene objetos de tipo '''Entrada'''.

En la aplicación final, una colección se verá como una lista de objetos. Para generar dicha lista, el sistema crea una tabla en la base de datos con las columnas que se mostrarán en la vista. El nombre de esta tabla lo especificamos en el atributo {{AT|nombre_tabla}}. En el ejemplo, indicamos que para esta colección se cree la tabla '''TC$ENTRADAS'''.

Para añadir columnas a la vista utilizamos las declaraciones de columna. En nuestro libro, indicamos que queremos dos columnas: [Número] y [Fecha]. Para cada columna, deben indicarse al menos dos atributos:

:* Cómo se llamará la columna en la base de datos ({{AT|columna_bd.nombre}})
:* Qué dato se mostrará en la vista ({{AT|origen}})

Por ejemplo, para la columna [Número] decimos que en la base de datos se llamará '''NUMERO''' y que debe mostrar el campo '''[Datos generales].[Número]''' (es decir, el campo '''Número''' que está en el formulario '''[Datos generales]''' del objeto '''Entrada''').Aunque en nuestro ejemplo una columna muestra el valor de un solo campo, no
tenemos por qué limitarnos a este uso. Al atributo {{AT|origen}} se le puede asignar una expresión más compleja, como por ejemplo una concatenación de campos.

==¿Qué es una habitación?==
Lo único que falta para que nuestro libro sea operativo es hacerlo accesible para los usuarios. Para ello, debemos definir una habitación y ubicar en ella el '''Libro de entrada''':

[Registro de entrada y salida] {{PR|es}} {{RE|habitacion}}
{{PR|ubicado}} [Libro de entradas]
-{{AT|lugar}} = {{STR|"Libros"}};
{{PR|fin}}

Conceptualmente, una {{RE|habitacion}} representa una oficina o un departamento de la organización. Dentro de una {{RE|habitacion}} indicamos qué recursos de sistema van a estar disponibles para los usuarios de esa oficina. Esto nos ayuda a construir el sistema siguiendo la estructura organizativa de la corporación, pero, simultáneamente, a lograr que todos los recursos transversales sean accesibles allí donde sean necesarios. ¿Cómo? Realizando declaraciones de {{PR|ubicado}}, indicando qué recursos de sistema van a estar disponibles para los usuarios de dicha {{RE|habitacion}}.

Cada vez que ubiquemos un recurso, debemos indicar en el atributo lugar en qué grupo va a estar colocado. En nuestro ejemplo, decimos que queremos poner el '''Libro de entrada''' en el grupo '''Libros'''. No existe un conjunto de valores predefinidos para el atributo lugar. Se le puede asignar cualquier valor.

Ahora, sólo queda [[Cómo_compilar_paso_a_paso|'''generar el modelo''']], [[Cómo_instalar_un_centro_desde_cero|'''instalar e iniciar el centro''']].

Cuando lo hayamos hecho, arrancamos la aplicación egExplorer y lo que nos aparecerá será una lista con todas las habitaciones disponibles en el sistema, donde la única que aperecerá será '''Registro de entrada y salida'''.

<center>
{|
|align="center" |[[Imagen:Figura 2.jpg|thumb|250px|Habitaciones disponibles]]
|}
</center>

Si entramos en nuestra habitación, veremos a la izquierda el grupo Libros con el Libro de entrada ubicado y haciendo clic lo abriremos:

<center>
{|
|align="center" |[[Imagen:Figura 3.jpg|thumb|250px|Libro de entrada]]
|}
</center>

Haciendo clic en Nuevo crearemos una nueva entrada en el Libro. ¿Y qué aparece? El formulario que hemos definido:

<center>
{|
|align="center" |[[Imagen:Figura 4.jpg|thumb|250px|Formulario Datos generales del objeto Entrada]]
|}
</center>

Si creamos una entrada, la guardamos y volvemos al libro aparecerá el listado con un elemento mostrando el número y la fecha que hemos puesto:

<center>
{|
|align="center" |[[Imagen:Figura 5.jpg|thumb|250px|Libro de entradas con una Entrada creada]]
|}
</center>

==Incluir la columna "Remitente" en el "Libro de Entrada"==
¿Y si además queremos incluir el '''Remitente'''? Pues no tenemos más que volver a nuestro código y añadir la columna en la {{T|coleccion}}:

[Libro de entrada] {{PR|es}} {{RE|contenedor}}
[Contenido] {{PR|es}} {{T|coleccion}}
-{{AT|nombre_tabla}} = {{STR|"TC$ENTRADAS"}}; 
{{PR|contiene}} [Entrada] 
{{PR|columna}} [Número]
-{{AT|columna_bd}}.{{AT|nombre}} = {{STR|"NUMERO"}};
-{{AT|origen}} = [Datos generales].[Número];
{{PR|columna}} [Fecha]
-{{AT|columna_bd}}.{{AT|nombre}} = {{STR|"FECHA"}};
-{{AT|origen}} = [Datos generales].[Fecha];
{{PR|columna}} [Remitente]
-{{AT|columna_bd}}.{{AT|nombre}} = {{STR|"REMITENTE"}};
-{{AT|origen}} = [Datos generales].[Remitente];
{{PR|fin}}
{{PR|fin}}

Compilamos y actualizamos el modelo. Al hacerlo, en la tabla '''TC$ENTRADAS''' se añadirá la columna REMITENTE. Si volvemos al egExplorer y abrimos el '''Libro de entrada''' veremos la columna Remitente incorporada.

<center>
{|
|align="center" |[[Imagen:Figura 6.jpg|thumb|250px|Entrada con la columna remitente]]
|}
</center>

<blockquote style="background: #ffffcc; border: 1px solid black; padding: 1em;">
'''Y el campo Destinatario, ¿no lo ponemos como columna? Entonces, ¿dónde se almacena?''' Es el momento de explicar cómo se almacenan los objetos en la plataforma egEasy. egEasy utiliza una base de datos orientada a objetos, en vez de un esquema clásico de base de datos relacional. Con esta arquitectura no tenemos una tabla para cada objeto nuevo que se crea en la base de datos. En su lugar, hay una sola tabla (eg$resources) en la que se almacenan todos los recursos del sistema. La administración de esta tabla es completamente transparente para el desarrollador y dentro de ella todos los campos y atributos de cada objeto se guardan serializados en un campo binario.

Entonces, ¿para qué nos sirve una colección? Con la definición de una colección logramos dos objetivos. En primer lugar, definimos el ámbito en el que se pueden crear los objetos (el objeto '''Entrada''' se puede crear en la componente '''Contenido''' del '''Libro de entrada'''). Por otro lado, proporcionamos un método rápido y eficiente para mostrar una lista de objetos; si no utilizásemos las colecciones, en el momento de mostrar una lista habría que deserializar uno por uno los objetos, una operación que podría resultar muy lenta.</blockquote>

==Definición del "Libro de salida"==
La definición del libro de salida es prácticamente igual al de entradas:

{{PR|tipo}} [Salida] {{PR|es}} {{RE|contenedor}}
[Datos generales] {{PR|es}} {{T|formulario}}
[Número] {{PR|es}} {{T|texto}}
[Fecha] {{PR|es}} {{T|texto}}
[Remitente] {{PR|es}} {{T|texto}}
[Destinatario] {{PR|es}} {{T|texto}}
{{PR|fin}}
{{PR|fin}} 
[Libro de salida] {{PR|es}} {{RE|contenedor}}
[Contenido] {{PR|es}} {{T|coleccion}}
-{{AT|nombre_tabla}} = {{STR|"TC$SALIDAS"}}; 
{{PR|contiene}} [Salida] 
{{PR|columna}} [Número]
-{{AT|columna_bd}}.{{AT|nombre}} = {{STR|"NUMERO"}};
-{{AT|origen}} = [Datos generales].[Número];
{{PR|columna}} [Fecha]
-{{AT|columna_bd}}.{{AT|nombre}} = {{STR|"FECHA"}};
-{{AT|origen}} = [Datos generales].[Fecha];
{{PR|columna}} [Remitente]
-{{AT|columna_bd}}.{{AT|nombre}} = {{STR|"REMITENTE"}};
-{{AT|origen}} = [Datos generales].[Remitente];
{{PR|fin}}
{{PR|fin}} 
[Registro de entrada y salida] {{PR|es}} {{RE|habitacion}}
{{PR|ubicado}} [Libro de entrada]
-{{AT|lugar}} = {{STR|"Libros"}};
{{PR|fin}}

Para hacerlo visible para los usuarios, debemos ubicarlo en la oficina:

[Registro de entrada y salida] {{PR|es}} {{RE|habitacion}}
{{PR|ubicado}} [Libro de entrada]
-{{AT|lugar}} = {{STR|"Libros"}};
{{PR|ubicado}} [Libro de salida]
-{{AT|lugar}} = {{STR|"Libros"}};
{{PR|fin}}

==¿Qué hemos aprendido?==

:* En ODL existen dos clases de declaraciones: de tipo (podemos crear instancias de ellas) y de sistema (sólo existe una intancia).
:* El [[Contenedores|contenedor]] es uno de los tipos fundamentales de ODL y nos permite definir en su contexto componentes tales como formularios y colecciones de datos.
:* Las colecciones se muestran en la aplicación final como listas de objetos en las que podemos crear [[Contenedores|contenedores]].
:* Podemos añadir columnas a una colección haciendo uso de la sentencia columna.
:* La declaraciones de habitación nos permiten ubicar los recursos para hacerlos visibles a los usuarios.

==Siguiente tarea==

:*[[Tarea_B:_Mejorando_la_numeración_del_registro|Tarea B: Mejorando la numeración del registro]]

==Véase también==

:*[[Tarea_C:_Evolucionando_la_arquitectura_del_registro|Tarea C: Evolucionando la introducción de datos]]
:*[[Tarea_D:_Validar_la_introducción_de_datos|Tarea D: Validar la introducción de datos]]
:*[[Tarea_E:_Utilizar_el_registro_como_un_almacén_de_documentación|Tarea E: Utilizar el registro como un almacén de documentación]]
:*[[Tarea_F:_Abriendo_el_registro_al_resto_de_las_oficinas|Tarea F: Abriendo el registro al resto de las oficinas]]
:*[[Tarea_G:_Evitando_la_repliación_de_código|Tarea G: Evitando la repliación de código]]
:*[[Tarea_H:_Emitir_certificados_de_documentación|Tarea H: Emitir certificados de documentación]]
:*[[Tarea_I:_Creando_una_oficina_sin_papeles|Tarea I: Creando una oficina sin papeles]]
:*[[Tarea_J:_Importar_la_base_de_datos_de_terceros_de_otra_aplicación|Tarea J: Importar la base de datos de terceros de otra aplicación]]

Cómo compilar paso a paso

2009-08-04T08:52:53Z

Imhernandez: /* ¿Actualizamos el diccionario, el modelo o el centro? */

Cuando un centro es modificado, bien sea mediante cambios en el diccionario o mediante cambios en el modelo, es necesario realizar una serie de operaciones para que los cambios realizados se vean reflejados en la aplicación egExplorer.
En este artículo abordaremos aquellos aspectos que influyen en dichas modificaciones, así como los pasos a seguir en función de qué elementos o ficheros del modelo se modifiquen. Para ello, es necesario conocer qué ficheros intervienen en el funcionamiento de un centro, y cómo afectan a éste.

__TOC__

==Ejecutando egCompiler==
Al crear un proyecto nuevo o modificar uno ya creado, la primera operación a realizar es compilar el proyecto. Si no se encuentran errores en la compilación, nuestro compilador, egCompiler, generará dos ficheros: un diccionario cuya extensión es '''.ndc''' y un modelo con extensión '''.nmc'''.
Pero, ¿y cómo ejecutamos el compilador?
Para ejecutar el compilador, hay que indicar ciertos parámetros de entrada, ya que el compilador necesita cierta información del proyecto para poder realizar el proceso de compilación.
En concreto, hay un parámetro de entrada fundamental para el compilador, que es el fichero .npc (código de proyecto).
En este fichero se indican, entre otras cosas, la correspondencia entre las definiciones realizadas en ODL, con los ficheros .ndf donde están declaradas. Cualquier definición o fichero .ndf nuevo que se genere deberá ser introducido por el programador en este fichero. Por tanto, deberemos indicar como primer parámetro la ruta de dicho fichero .npc.
Además de este parámetro, que es el único que realmente necesita el compilador, existen otros parámetros opcionales, de forma que podamos configurar ciertos aspectos del compilador. Veamos cuales son:

:*'''/O:''' --> Indicaremos el diccionario previo a la compilación para compararlo con el nuevo diccionario a generar.
:*'''/N:''' --> Indicaremos el directorio de definiciones.
:*'''/D:''' --> Indicaremos el directorio destino donde queramos que se generen el diccionario(.ndc) y el modelo(.nmc). En caso de no especifircarlo se almacenarán en el directorio donde se encuentre el fichero .npc.
:*'''/S:''' --> Su inclusión indica que solamente se genere el diccionario y no el modelo.

Una vez conocidos los parámetros que admite egCompiler, utilizaremos la consola del sistema para ejecutarlo. De esta manera podremos introducir los parámetros que nos interesen en cada ejecución. Veamos un ejemplo:

<center>
{|
|align="center" |[[Imagen:compilarconsola.jpg|thumb|250px|Compilación mediante la consola del sistema]]
|}
</center>

Como habrás visto, lo primero es indicar la ruta del ejecutable del compilador. A continuación, especificamos la ruta del fichero .npc y, seguidamente, añadimos los parámetros opcionales. En este caso, hemos indicado con el parámetro '''/O:''' la existencia de un diccionario previo con el que vamos a comparar el nuevo a generar. Con el parámetro '''/D:''' indicamos una ruta donde queremos guardar los ficheros de salida que generará el compilador, que en este caso será sólo el diccionario, ya que la inclusión del parámetro '''/S:''' así lo indica.
NOTA: En caso de incluir rutas con espacios en blanco en ellas, debemos acotar la ruta completa entre comillas dobles.

==Configuración de egCompiler en EditPlus==
Es probable que la persona que esté desarrollando en ODL tenga que realizar numerosas y repetitivas compilaciones en su proyecto. Por ello, facilitamos una forma de configurar el '''egCompiler''' en un editor de programación, que en este caso, hemos optado por el EditPlus. Sin más preámbulos, veamos cómo configurar dicho editor para ejecutar directamente el compilador desde él:

*Primer paso: ir a '''''Tools''''' -> '''''Preferences''''':

<center>
{|
|align="center" |[[Imagen:Paso0.jpg|thumb|250px|Tools -> Preferences]]
|}
</center>

*Segundo paso: dentro de '''''Preferences''''', ir a la etiqueta '''''User tools''''':

<center>
{|
|align="center" |[[Imagen:Paso1.jpg|thumb|250px|Entrar en User Tools]]
|}
</center>

*Tercer paso: una vez en '''''User tools''''', hay varias opciones y campos que debemos configurar. En primer lugar, vemos que existen varios grupos. Seleccionamos uno de ellos, y para cambiar el nombre haremos click en '''''Group Name...'''''. Estos grupos sirven para etiquetar conjuntos de herramientas que definamos en EditPlus, como por ejemplo, en nuestro caso, la configuración del compilador:

<center>
{|
|align="center" |[[Imagen:Paso2.jpg|thumb|250px|Editar el nombre de un grupo]]
|}
</center>

*Cuarto paso: ahora tenemos que crear una herramienta. Para ello, hacemos click en '''''Add Tool >>'''''. Nos aparecerá un desplegable, donde seleccionaremos '''''Program''''' para indicar que vamos a configurar una aplicación:

<center>
{|
|align="center" |[[Imagen:Paso3.jpg|thumb|250px|Añadimos una herramienta, en este caso, nuestro compilador]]
|}
</center>

*Quinto paso: vemos que hay ciertos campos como '''''Menu text''''', '''''Command''''', '''''Argument''''' o '''''Initial directory''''' además de ciertas opciones activables:

<center>
{|
|align="center" |[[Imagen:Paso4.jpg|thumb|250px|Introducir datos necesarios para la ejecución del compilador]]
|}
</center>

En '''''Menu text''''' pondremos el nombre que aparecerá en el menú de herramientas para ejecutar el compilador.
En '''''Command''''' introduciremos la ruta en donde está almacenado el ejecutable del egCompiler.
En el campo '''''Argument''''' podremos especificar los argumentos que acepta el egCompiler. En nuestro caso, añadiremos el parámetro '''/O:''' (además del fichero .npc como explicamos en el apartado anterior) para que al compilar compare el diccionario previo con el nuevo creado, de manera que pueda detectar los cambios.
A continuación, añadiremos en el campo '''''Initial directory''''' el directorio donde se encuentra el fichero .npc (si no indicamos el directorio destino con el parámetro /D: el compilador almacenará el diccionario y el modelo en este directorio).
Finalmente, activaremos las casillas '''''Capture output''''' para ver los mensajes de compilación en el propio EditPlus (en vez de en una ventana) y '''''Save open files''''' para que al compilar se guarden los ficheros abiertos del proyecto en cuestión. Los ficheros abiertos que no pertenezcan al proyecto no se guardarán.
Ahora veremos que la opción '''''Compilar''''' estará disponible en el menú '''''Tools''''' o '''''Herramientas''''':

<center>
{|
|align="center" |[[Imagen:Paso5.jpg|thumb|250px|El compilador ya se puede utilizar desde EditPlus]]
|}
</center>

==Compilando...==
Una vez hemos ejecutado nuestro compilador, bien mediante la consola del sistema, o bien mediante un editor, el compilador informará al programador de aquellas definiciones que, o bien son nuevas y puede generar un DRC en la base de datos para cada una de ellas, o bien detecta definiciones anteriores que ya no se encuentran en el código (en comparación con un modelo anterior) y, por tanto, es posible la liberación de su DRC. Existe otra operación, que es asignar el DRC de una definición que vamos a eliminar a una nueva que vamos a generar. De esta forma conservamos los valores que se han creado a partir de la definición que vamos a eliminar.
Como ya sabemos, una vez liberados, generados o asignados los DRCs, el compilador generará un diccionario y un modelo.
Veamos un ejemplo práctico:

:*En primer lugar, vamos a generar por primera vez nuestro modelo, de forma que se generará un DRC para todas las definiciones. Podemos ir generando las nuevas definiciones seleccionando de una en una con el botón '''''Generar''''', o bien utilizar el botón '''''Generar todos'''''.Nuestro sistema de información está constituído por dos definiciones de tipo ('''''Cliente''''' y '''''Expediente''''') con sus respectivas colecciones ('''''Clientes->Contenido)''''' y '''''Expedientes->Contenido'''''). Además también hay definida una habitación '''''Mi organización''''' para ubicar dichas colecciones y una definición de rol para acceder a los recursos definidos:

<center>
{|
|align="center" |[[Imagen:Generar_drc.jpg|thumb|250px|Generamos los DRC de las definiciones por primera vez]]
|}
</center>

:*Ahora, hemos decidido eliminar ciertas definiciones, de forma que, al compilar, se comparará el diccionario creado en el paso anterior con el nuevo, y detectará aquellas definiciones que ya no se encuentren en el código. Al igual que al generar DRCs, existe un botón para ir liberando uno a uno cada DRC mediante el botón '''''Liberar''''' o bien liberarlas todas automáticamente, sin tener que seleccionar ninguna, con el botón '''''Liberar todas''''':

<center>
{|
|align="center" |[[Imagen:Liberar_drc.jpg|thumb|250px|Eliminamos la definición de tipo '''''Expediente''''', así como todo aquello relacionado con dicha definición (colección, ubicación y permisos)]]
|}
</center>

:*La tercera posibilidad que nos podemos encontrar es la asignación de un DRC, correspondiente a una definición que vamos a eliminar, a una definición nueva que vamos a generar. En este caso debemos tener en cuenta las posibilidades que se nos pueden presentar, pues pueden ser varias.Normalmente, esta operación se suele realizar al cambiar el nombre de alguna definición, de forma que nos puede interesar asignar el DRC de la definición anterior a la nueva definición para que los valores generados anteriormente al cambio de nombre se mantengan en la nueva definición.Otra posibilidad es, por ejemplo, cambiar el tipo de un campo. En este caso, se podrá asignar el DRC del campo previo al nuevo campo, pero las consecuencias de dicho cambio tendrá que valorarlas el programador, pues puede no conseguirse el efecto deseado.Un nuevo caso, en el que vamos a basar nuestro ejemplo, puede ser el cambio de nombre de un formulario, junto con el cambio de nombre de un campo incluído en dicho formulario. En cuanto a los formularios, hay que tener en cuenta que deben tener el mismo número de campos, además, los campos deben tener el mismo nombre. Vayamos viendo los pasos a realizar uno a uno, de manera que los vayamos comentando:

<center>
{|
|align="center" |[[Imagen:Asignar_drc.jpg|thumb|250px|Relación de las definiciones a liberar o a generar]]
|}
</center>

:Vemos que el compilador ha detectado definiciones que, o bien pueden ser liberadas, o bien pueden ser generadas. Pero nuestra intención es asignar el DRC del formulario '''''Datos generales''''' al formulario '''''Datos generales del cliente'''''. Además, ha detectado que el campo '''''DNI''''' ha cambiado de nombre, detectando un nuevo campo denominado '''''NIF''''' así como el cambio de nombre de la columna '''''DNI''''' de la colección '''''Clientes''''' por '''''NIF''''':

<center>
{|
|align="center" |[[Imagen:Asignar_drc1.jpg|thumb|250px|Primero seleccionamos la definición del DRC que vamos a asignar]]
|align="center" |[[Imagen:Asignar_drc2.jpg|thumb|250px|Seleccionamos la definición nueva, indicando que el DRC será asignado a esa definición]]
|align="center" |[[Imagen:Asignar_drc3.jpg|thumb|250px|Y generamos la asignación con el botón '''''Asignar''''']]
|}
</center>

:Ya tenemos realizada la asignación de la columna que ha cambiado de nombre en la colección '''''Clientes'''''. Ahora vamos a asignar el formulario. Para ello, hay que tener en cuenta que un campo ha cambiado de nombre, y, por tanto, deberemos asignar dicho DRC antes de hacerlo con el formulario:

<center>
{|
|align="center" |[[Imagen:Asignar_drc4.jpg|thumb|250px|Seleccionamos el campo que contiene el DRC]]
|align="center" |[[Imagen:Asignar_drc5.jpg|thumb|250px|Seleccionamos el campo nuevo]]
|align="center" |[[Imagen:Asignar_drc6.jpg|thumb|250px|Y generamos la asignación, al igual que en el caso anterior]]
|}
</center>

:Una vez tratado el campo que ha cambiado de nombre, ya no hay restricciones para asignar el DRC del formulario '''''Datos generales''''' al formulario '''''Datos generales del cliente''''':

<center>
{|
|align="center" |[[Imagen:Asignar_drc7.jpg|thumb|250px|Seleccionamos el formulario que contiene el DRC]]
|align="center" |[[Imagen:Asignar_drc8.jpg|thumb|250px|Seleccionamos el formulario nuevo]]
|align="center" |[[Imagen:Asignar_drc9.jpg|thumb|250px|Y realizamos la asignación]]
|}
</center>

:'''¿Y qué pasa si introduzco, elimino o modifico un atributo en alguna definición?''' Los atributos no tienen asignado un DRC, por lo que cualquier edición que hagamos sobre ellos, el compilador no detectará posibles modificaciones en los DRC del sistema.

==Crear un fichero de proyecto (.npc)==
Como ya hemos comentado en este artículo, a la hora de compilar un proyecto en ODL es necesario especificar el fichero

.npc en el egCompiler.
Este fichero deberá ser creado manualmente por el desarrollador, por lo que vamos a explicar a continuación la información

que debe almacenar, la estructura que tiene que adoptar y las funciones para las cuales está destinado este fichero.
Cuando instalamos un centro, la estructura de directorios que tendrá el centro una vez instalado está predefinido en un

modelo por defecto llamado ('''Default'''), que tiene la siguiente estructura:

<center>
{|
|align="center" |[[Imagen:estructura_default.jpg|thumb|250px|Compilación mediante la consola del sistema]]
|}
</center>

En nuestro directorio de desarrollo, crearemos aquellas carpetas (que existan en el modelo '''Default''') que vayamos a

modificar. Por ejemplo, si nuestro centro tiene escritos, tendremos que crear una carpeta llamada '''Template documents''',

donde almacenaremos los ficheros .rtf de nuestro centro.

Una vez creado el modelo del centro, lo instalaremos mediante el egAdmin. Éste comparará el modelo '''Default''' con

nuestro modelo de centro, de manera que las carpetas que se encuentren en ambos modelos serán fusionadas. Es decir, que, por

ejemplo, la carpeta '''Template documents''', donde hemos añadido los ficheros rtf, aparecerá con los ficheros rtf en el

directorio de explotación del centro (y no vacío como aparece en el modelo Default).

Pero, ¿y cómo interviene el fichero .npc en todo este proceso de compilación e instalación de un centro?

El fichero .npc tiene varias funciones en todo este proceso.

Por un lado, informará al compilador de las definiciones que serán compiladas y de las cuales saldrá el diccionario

resultante. Por otro lado, informará al compilador de aquellas carpetas que se han creado en el directorio de desarrollo y

que se quieren incluir en el modelo de centro para su posterior instalación. Por ello, es un fichero fundamental para la

compilación de nuestro centro.

La estructura de un fichero .npc debe ser la siguiente:

<center>
{|
|align="center" |[[Imagen:estructura_npc.jpg|thumb|250px|Compilación mediante la consola del sistema]]
|}
</center>

Las palabras enmarcadas en verde son palabras clave que deben ir en el fichero.
Para el caso de la cabecera, añadiremos un campo donde añadiremos un nombre.
En todos los centros, es necesario crear al menos un fichero de constantes básicas. Este fichero .nc deberá ir

especificado en la palabra clave '''Constantes'''. En caso de existir más de un fichero, se especificarán uno debajo de

otro.
En caso de querer especificar una carpeta de plantillas de escritos, plantillas de impresión o plantillas de vistas, lo

haremos en las palabras clave '''Plantillas_documentos''' para la carpeta [Template documents],

'''Plantillas_visualizacion''' para la carpeta [Template views] o '''Plantillas_impresion''' para la carpeta [Template

prints].
Hay que tener en cuenta que el directorio de las carpetas se especifica a partir del directorio donde esté alojado el

fichero .npc. Si la carpeta [Template documents] está en la misma carpeta que el fichero .npc, no habrá que añadir ninguna

ruta.
Por último, tendremos que especificar las definiciones para generar el diccionario. Esto lo haremos bajo la palabra clave

'''Definiciones'''. Para ello, indicaremos el nombre de la unidad de cada fichero .ndf con el directorio donde se encuentra

el fichero .ndf, tal y como hemos podido ver en la imagen anterior.

==Crear un fichero de constantes (.nc)==
Otro tipo de fichero que tiene que ser creado por el desarrollador son los ficheros de constantes (.nc). Estos ficheros especifican las constantes que se utilizan en un centro.
Existen ciertas constantes básicas que deben ser incluidas en un fichero que tiene que llamarse '''CBasicas.nc'''. Estas constantes básicas coinciden en etiqueta con algunas palabras reservadas del propio lenguaje ODL. Esto es así porque en el proceso de compilación las definiciones se crearán en función de los valores de las constantes y no de sus etiquetas.
Por ejemplo, en el conjunto de estas constantes básicas, existe una cuya etiqueta es '''ENTERO''', que tiene valor '''1'''. Cuando en nuestro código ODL definimos un campo entero, en el proceso de compilación la definición del campo será creada con el valor de la constante y no de la etiqueta. A continuación, cuando ejecutemos la aplicación egExplorer, que cargará el diccionario generado por el compilador, leerá que existe una definición de campo con valor 1, que interpretará como un campo entero.
Para que este comportamiento se lleve a cabo, debe existir una referencia en el fichero .npc al fichero .nc de constantes básicas. Esto es debido a que el parámetro que se le pasa al compilador es el fichero .npc de nuestro proyecto.
Aparte de las constante básicas, es posible que el desarrollador quiera declarar nuevas constantes. Esto podrá hacerlo en el mismo fichero '''CBasicas.nc''' o crear otros ficheros .nc para agrupar estas constantes. En caso de crear nuevos ficheros .nc, debemos incluirlos siempre en el fichero .npc.
A continuación, mostramos todas aquellas constantes básicas que son necesarias en cualquier centro:

<center>
{|
|align="center" |[[Imagen:constantes_basicas.jpg|border|250px]]
|}
</center>

Para incluir nuevas constantes en el fichero, simplemente hay que seguir el formato visto en la imagen, pudiendo declararlas en cualquier parte del fichero. Únicamente habrá que tener cuidado de modificar las constantes básicas o declarar nuevas constantes con etiquetas ya utilizadas.

==¿Actualizamos el diccionario, el modelo o el centro?==
Cuando realizamos modificaciones en algunos de los elementos que constituyen el modelo de un sistema de información, es necesario utilizar la aplicación '''egAdmin''' para actualizar los cambios que hemos realizado y que se reflejen en la herramienta '''egExplorer'''. En función de los cambios realizados, será necesario actualizar el diccionario, el modelo o el centro.Por tanto:
:*'''¿Cuándo debo actualizar sólo el diccionario?'''Actualizaremos el diccionario cuando modifiquemos una definición de tipo o creemos una definición de tipo nueva en los ficheros .ndf que se encuentran en el directorio '''''#Source'''''

<center>
{|
|align="center" |[[Imagen:actualizardiccionario.jpg|thumb|250px|Actualizar diccionario en egAdmin]]
|}
</center>

:*'''¿Cuándo debo actualizar sólo el modelo?'''Si cambiamos o agregamos algún fichero .rtf (plantillas), .nmt (métodos), .csv (representación de datos), scripts SQL, etc. Es decir, todo aquello que no sea un fichero .ndf.

<center>
{|
|align="center" |[[Imagen:actualizarmodelo.jpg|thumb|250px|Actualizar modelo en egAdmin]]
|}
</center>

:*'''¿Cuándo debo actualizar el diccionario y el centro?'''Actualizaremos el diccionario y el centro cuando incluyamos nuevas definiciones de sistema. Además, cuando creamos tablas nuevas en la base de datos (por ejemplo, nuevas colecciones) o cualquier cambio que afecte a la base de datos. Este caso tiene una particularidad, y es que al tener que actualizar el centro, deberemos pararlo previamente, y una vez actualizado, arrancarlo nuevamente.

<center>
{|
|align="center" |[[Imagen:actualizarmodelo.jpg|thumb|250px|Actualizamos primero el modelo]]
|align="center" |[[Imagen:pararcentro.jpg|thumb|250px|A continuación paramos el centro en el botón '''''Parar''''']]
|align="center" |[[Imagen:actualizarcentro.jpg|thumb|250px|Lo actualizamos y arrancamos en el botón '''''Arrancar''''']]
|}
</center>

:*'''¿Cuándo debo actualizar el diccionario y reiniciar el centro?'''Cuando cambiamos el nombre a la definición de una tarea o definimos una nueva en nuestro código ODL, evidentemente tendremos que actualizar el diccionario. Pero, a diferencia del primer caso, en el que sólo tenemos que actualizar el diccionario, también es necesario parar el centro y volver a arrancarlo (reiniciarlo), pero sin actualizarlo.

[[Categoría:Tutoriales]]

Cómo compilar paso a paso

2009-08-04T08:50:26Z

Imhernandez: /* Crear un fichero de constantes (.nc) */

Cuando un centro es modificado, bien sea mediante cambios en el diccionario o mediante cambios en el modelo, es necesario realizar una serie de operaciones para que los cambios realizados se vean reflejados en la aplicación egExplorer.
En este artículo abordaremos aquellos aspectos que influyen en dichas modificaciones, así como los pasos a seguir en función de qué elementos o ficheros del modelo se modifiquen. Para ello, es necesario conocer qué ficheros intervienen en el funcionamiento de un centro, y cómo afectan a éste.

__TOC__

==Ejecutando egCompiler==
Al crear un proyecto nuevo o modificar uno ya creado, la primera operación a realizar es compilar el proyecto. Si no se encuentran errores en la compilación, nuestro compilador, egCompiler, generará dos ficheros: un diccionario cuya extensión es '''.ndc''' y un modelo con extensión '''.nmc'''.
Pero, ¿y cómo ejecutamos el compilador?
Para ejecutar el compilador, hay que indicar ciertos parámetros de entrada, ya que el compilador necesita cierta información del proyecto para poder realizar el proceso de compilación.
En concreto, hay un parámetro de entrada fundamental para el compilador, que es el fichero .npc (código de proyecto).
En este fichero se indican, entre otras cosas, la correspondencia entre las definiciones realizadas en ODL, con los ficheros .ndf donde están declaradas. Cualquier definición o fichero .ndf nuevo que se genere deberá ser introducido por el programador en este fichero. Por tanto, deberemos indicar como primer parámetro la ruta de dicho fichero .npc.
Además de este parámetro, que es el único que realmente necesita el compilador, existen otros parámetros opcionales, de forma que podamos configurar ciertos aspectos del compilador. Veamos cuales son:

:*'''/O:''' --> Indicaremos el diccionario previo a la compilación para compararlo con el nuevo diccionario a generar.
:*'''/N:''' --> Indicaremos el directorio de definiciones.
:*'''/D:''' --> Indicaremos el directorio destino donde queramos que se generen el diccionario(.ndc) y el modelo(.nmc). En caso de no especifircarlo se almacenarán en el directorio donde se encuentre el fichero .npc.
:*'''/S:''' --> Su inclusión indica que solamente se genere el diccionario y no el modelo.

Una vez conocidos los parámetros que admite egCompiler, utilizaremos la consola del sistema para ejecutarlo. De esta manera podremos introducir los parámetros que nos interesen en cada ejecución. Veamos un ejemplo:

<center>
{|
|align="center" |[[Imagen:compilarconsola.jpg|thumb|250px|Compilación mediante la consola del sistema]]
|}
</center>

Como habrás visto, lo primero es indicar la ruta del ejecutable del compilador. A continuación, especificamos la ruta del fichero .npc y, seguidamente, añadimos los parámetros opcionales. En este caso, hemos indicado con el parámetro '''/O:''' la existencia de un diccionario previo con el que vamos a comparar el nuevo a generar. Con el parámetro '''/D:''' indicamos una ruta donde queremos guardar los ficheros de salida que generará el compilador, que en este caso será sólo el diccionario, ya que la inclusión del parámetro '''/S:''' así lo indica.
NOTA: En caso de incluir rutas con espacios en blanco en ellas, debemos acotar la ruta completa entre comillas dobles.

==Configuración de egCompiler en EditPlus==
Es probable que la persona que esté desarrollando en ODL tenga que realizar numerosas y repetitivas compilaciones en su proyecto. Por ello, facilitamos una forma de configurar el '''egCompiler''' en un editor de programación, que en este caso, hemos optado por el EditPlus. Sin más preámbulos, veamos cómo configurar dicho editor para ejecutar directamente el compilador desde él:

*Primer paso: ir a '''''Tools''''' -> '''''Preferences''''':

<center>
{|
|align="center" |[[Imagen:Paso0.jpg|thumb|250px|Tools -> Preferences]]
|}
</center>

*Segundo paso: dentro de '''''Preferences''''', ir a la etiqueta '''''User tools''''':

<center>
{|
|align="center" |[[Imagen:Paso1.jpg|thumb|250px|Entrar en User Tools]]
|}
</center>

*Tercer paso: una vez en '''''User tools''''', hay varias opciones y campos que debemos configurar. En primer lugar, vemos que existen varios grupos. Seleccionamos uno de ellos, y para cambiar el nombre haremos click en '''''Group Name...'''''. Estos grupos sirven para etiquetar conjuntos de herramientas que definamos en EditPlus, como por ejemplo, en nuestro caso, la configuración del compilador:

<center>
{|
|align="center" |[[Imagen:Paso2.jpg|thumb|250px|Editar el nombre de un grupo]]
|}
</center>

*Cuarto paso: ahora tenemos que crear una herramienta. Para ello, hacemos click en '''''Add Tool >>'''''. Nos aparecerá un desplegable, donde seleccionaremos '''''Program''''' para indicar que vamos a configurar una aplicación:

<center>
{|
|align="center" |[[Imagen:Paso3.jpg|thumb|250px|Añadimos una herramienta, en este caso, nuestro compilador]]
|}
</center>

*Quinto paso: vemos que hay ciertos campos como '''''Menu text''''', '''''Command''''', '''''Argument''''' o '''''Initial directory''''' además de ciertas opciones activables:

<center>
{|
|align="center" |[[Imagen:Paso4.jpg|thumb|250px|Introducir datos necesarios para la ejecución del compilador]]
|}
</center>

En '''''Menu text''''' pondremos el nombre que aparecerá en el menú de herramientas para ejecutar el compilador.
En '''''Command''''' introduciremos la ruta en donde está almacenado el ejecutable del egCompiler.
En el campo '''''Argument''''' podremos especificar los argumentos que acepta el egCompiler. En nuestro caso, añadiremos el parámetro '''/O:''' (además del fichero .npc como explicamos en el apartado anterior) para que al compilar compare el diccionario previo con el nuevo creado, de manera que pueda detectar los cambios.
A continuación, añadiremos en el campo '''''Initial directory''''' el directorio donde se encuentra el fichero .npc (si no indicamos el directorio destino con el parámetro /D: el compilador almacenará el diccionario y el modelo en este directorio).
Finalmente, activaremos las casillas '''''Capture output''''' para ver los mensajes de compilación en el propio EditPlus (en vez de en una ventana) y '''''Save open files''''' para que al compilar se guarden los ficheros abiertos del proyecto en cuestión. Los ficheros abiertos que no pertenezcan al proyecto no se guardarán.
Ahora veremos que la opción '''''Compilar''''' estará disponible en el menú '''''Tools''''' o '''''Herramientas''''':

<center>
{|
|align="center" |[[Imagen:Paso5.jpg|thumb|250px|El compilador ya se puede utilizar desde EditPlus]]
|}
</center>

==Compilando...==
Una vez hemos ejecutado nuestro compilador, bien mediante la consola del sistema, o bien mediante un editor, el compilador informará al programador de aquellas definiciones que, o bien son nuevas y puede generar un DRC en la base de datos para cada una de ellas, o bien detecta definiciones anteriores que ya no se encuentran en el código (en comparación con un modelo anterior) y, por tanto, es posible la liberación de su DRC. Existe otra operación, que es asignar el DRC de una definición que vamos a eliminar a una nueva que vamos a generar. De esta forma conservamos los valores que se han creado a partir de la definición que vamos a eliminar.
Como ya sabemos, una vez liberados, generados o asignados los DRCs, el compilador generará un diccionario y un modelo.
Veamos un ejemplo práctico:

:*En primer lugar, vamos a generar por primera vez nuestro modelo, de forma que se generará un DRC para todas las definiciones. Podemos ir generando las nuevas definiciones seleccionando de una en una con el botón '''''Generar''''', o bien utilizar el botón '''''Generar todos'''''.Nuestro sistema de información está constituído por dos definiciones de tipo ('''''Cliente''''' y '''''Expediente''''') con sus respectivas colecciones ('''''Clientes->Contenido)''''' y '''''Expedientes->Contenido'''''). Además también hay definida una habitación '''''Mi organización''''' para ubicar dichas colecciones y una definición de rol para acceder a los recursos definidos:

<center>
{|
|align="center" |[[Imagen:Generar_drc.jpg|thumb|250px|Generamos los DRC de las definiciones por primera vez]]
|}
</center>

:*Ahora, hemos decidido eliminar ciertas definiciones, de forma que, al compilar, se comparará el diccionario creado en el paso anterior con el nuevo, y detectará aquellas definiciones que ya no se encuentren en el código. Al igual que al generar DRCs, existe un botón para ir liberando uno a uno cada DRC mediante el botón '''''Liberar''''' o bien liberarlas todas automáticamente, sin tener que seleccionar ninguna, con el botón '''''Liberar todas''''':

<center>
{|
|align="center" |[[Imagen:Liberar_drc.jpg|thumb|250px|Eliminamos la definición de tipo '''''Expediente''''', así como todo aquello relacionado con dicha definición (colección, ubicación y permisos)]]
|}
</center>

:*La tercera posibilidad que nos podemos encontrar es la asignación de un DRC, correspondiente a una definición que vamos a eliminar, a una definición nueva que vamos a generar. En este caso debemos tener en cuenta las posibilidades que se nos pueden presentar, pues pueden ser varias.Normalmente, esta operación se suele realizar al cambiar el nombre de alguna definición, de forma que nos puede interesar asignar el DRC de la definición anterior a la nueva definición para que los valores generados anteriormente al cambio de nombre se mantengan en la nueva definición.Otra posibilidad es, por ejemplo, cambiar el tipo de un campo. En este caso, se podrá asignar el DRC del campo previo al nuevo campo, pero las consecuencias de dicho cambio tendrá que valorarlas el programador, pues puede no conseguirse el efecto deseado.Un nuevo caso, en el que vamos a basar nuestro ejemplo, puede ser el cambio de nombre de un formulario, junto con el cambio de nombre de un campo incluído en dicho formulario. En cuanto a los formularios, hay que tener en cuenta que deben tener el mismo número de campos, además, los campos deben tener el mismo nombre. Vayamos viendo los pasos a realizar uno a uno, de manera que los vayamos comentando:

<center>
{|
|align="center" |[[Imagen:Asignar_drc.jpg|thumb|250px|Relación de las definiciones a liberar o a generar]]
|}
</center>

:Vemos que el compilador ha detectado definiciones que, o bien pueden ser liberadas, o bien pueden ser generadas. Pero nuestra intención es asignar el DRC del formulario '''''Datos generales''''' al formulario '''''Datos generales del cliente'''''. Además, ha detectado que el campo '''''DNI''''' ha cambiado de nombre, detectando un nuevo campo denominado '''''NIF''''' así como el cambio de nombre de la columna '''''DNI''''' de la colección '''''Clientes''''' por '''''NIF''''':

<center>
{|
|align="center" |[[Imagen:Asignar_drc1.jpg|thumb|250px|Primero seleccionamos la definición del DRC que vamos a asignar]]
|align="center" |[[Imagen:Asignar_drc2.jpg|thumb|250px|Seleccionamos la definición nueva, indicando que el DRC será asignado a esa definición]]
|align="center" |[[Imagen:Asignar_drc3.jpg|thumb|250px|Y generamos la asignación con el botón '''''Asignar''''']]
|}
</center>

:Ya tenemos realizada la asignación de la columna que ha cambiado de nombre en la colección '''''Clientes'''''. Ahora vamos a asignar el formulario. Para ello, hay que tener en cuenta que un campo ha cambiado de nombre, y, por tanto, deberemos asignar dicho DRC antes de hacerlo con el formulario:

<center>
{|
|align="center" |[[Imagen:Asignar_drc4.jpg|thumb|250px|Seleccionamos el campo que contiene el DRC]]
|align="center" |[[Imagen:Asignar_drc5.jpg|thumb|250px|Seleccionamos el campo nuevo]]
|align="center" |[[Imagen:Asignar_drc6.jpg|thumb|250px|Y generamos la asignación, al igual que en el caso anterior]]
|}
</center>

:Una vez tratado el campo que ha cambiado de nombre, ya no hay restricciones para asignar el DRC del formulario '''''Datos generales''''' al formulario '''''Datos generales del cliente''''':

<center>
{|
|align="center" |[[Imagen:Asignar_drc7.jpg|thumb|250px|Seleccionamos el formulario que contiene el DRC]]
|align="center" |[[Imagen:Asignar_drc8.jpg|thumb|250px|Seleccionamos el formulario nuevo]]
|align="center" |[[Imagen:Asignar_drc9.jpg|thumb|250px|Y realizamos la asignación]]
|}
</center>

:'''¿Y qué pasa si introduzco, elimino o modifico un atributo en alguna definición?''' Los atributos no tienen asignado un DRC, por lo que cualquier edición que hagamos sobre ellos, el compilador no detectará posibles modificaciones en los DRC del sistema.

==Crear un fichero de proyecto (.npc)==
Como ya hemos comentado en este artículo, a la hora de compilar un proyecto en ODL es necesario especificar el fichero

.npc en el egCompiler.
Este fichero deberá ser creado manualmente por el desarrollador, por lo que vamos a explicar a continuación la información

que debe almacenar, la estructura que tiene que adoptar y las funciones para las cuales está destinado este fichero.
Cuando instalamos un centro, la estructura de directorios que tendrá el centro una vez instalado está predefinido en un

modelo por defecto llamado ('''Default'''), que tiene la siguiente estructura:

<center>
{|
|align="center" |[[Imagen:estructura_default.jpg|thumb|250px|Compilación mediante la consola del sistema]]
|}
</center>

En nuestro directorio de desarrollo, crearemos aquellas carpetas (que existan en el modelo '''Default''') que vayamos a

modificar. Por ejemplo, si nuestro centro tiene escritos, tendremos que crear una carpeta llamada '''Template documents''',

donde almacenaremos los ficheros .rtf de nuestro centro.

Una vez creado el modelo del centro, lo instalaremos mediante el egAdmin. Éste comparará el modelo '''Default''' con

nuestro modelo de centro, de manera que las carpetas que se encuentren en ambos modelos serán fusionadas. Es decir, que, por

ejemplo, la carpeta '''Template documents''', donde hemos añadido los ficheros rtf, aparecerá con los ficheros rtf en el

directorio de explotación del centro (y no vacío como aparece en el modelo Default).

Pero, ¿y cómo interviene el fichero .npc en todo este proceso de compilación e instalación de un centro?

El fichero .npc tiene varias funciones en todo este proceso.

Por un lado, informará al compilador de las definiciones que serán compiladas y de las cuales saldrá el diccionario

resultante. Por otro lado, informará al compilador de aquellas carpetas que se han creado en el directorio de desarrollo y

que se quieren incluir en el modelo de centro para su posterior instalación. Por ello, es un fichero fundamental para la

compilación de nuestro centro.

La estructura de un fichero .npc debe ser la siguiente:

<center>
{|
|align="center" |[[Imagen:estructura_npc.jpg|thumb|250px|Compilación mediante la consola del sistema]]
|}
</center>

Las palabras enmarcadas en verde son palabras clave que deben ir en el fichero.
Para el caso de la cabecera, añadiremos un campo donde añadiremos un nombre.
En todos los centros, es necesario crear al menos un fichero de constantes básicas. Este fichero .nc deberá ir

especificado en la palabra clave '''Constantes'''. En caso de existir más de un fichero, se especificarán uno debajo de

otro.
En caso de querer especificar una carpeta de plantillas de escritos, plantillas de impresión o plantillas de vistas, lo

haremos en las palabras clave '''Plantillas_documentos''' para la carpeta [Template documents],

'''Plantillas_visualizacion''' para la carpeta [Template views] o '''Plantillas_impresion''' para la carpeta [Template

prints].
Hay que tener en cuenta que el directorio de las carpetas se especifica a partir del directorio donde esté alojado el

fichero .npc. Si la carpeta [Template documents] está en la misma carpeta que el fichero .npc, no habrá que añadir ninguna

ruta.
Por último, tendremos que especificar las definiciones para generar el diccionario. Esto lo haremos bajo la palabra clave

'''Definiciones'''. Para ello, indicaremos el nombre de la unidad de cada fichero .ndf con el directorio donde se encuentra

el fichero .ndf, tal y como hemos podido ver en la imagen anterior.

==Crear un fichero de constantes (.nc)==
Otro tipo de fichero que tiene que ser creado por el desarrollador son los ficheros de constantes (.nc). Estos ficheros especifican las constantes que se utilizan en un centro.
Existen ciertas constantes básicas que deben ser incluidas en un fichero que tiene que llamarse '''CBasicas.nc'''. Estas constantes básicas coinciden en etiqueta con algunas palabras reservadas del propio lenguaje ODL. Esto es así porque en el proceso de compilación las definiciones se crearán en función de los valores de las constantes y no de sus etiquetas.
Por ejemplo, en el conjunto de estas constantes básicas, existe una cuya etiqueta es '''ENTERO''', que tiene valor '''1'''. Cuando en nuestro código ODL definimos un campo entero, en el proceso de compilación la definición del campo será creada con el valor de la constante y no de la etiqueta. A continuación, cuando ejecutemos la aplicación egExplorer, que cargará el diccionario generado por el compilador, leerá que existe una definición de campo con valor 1, que interpretará como un campo entero.
Para que este comportamiento se lleve a cabo, debe existir una referencia en el fichero .npc al fichero .nc de constantes básicas. Esto es debido a que el parámetro que se le pasa al compilador es el fichero .npc de nuestro proyecto.
Aparte de las constante básicas, es posible que el desarrollador quiera declarar nuevas constantes. Esto podrá hacerlo en el mismo fichero '''CBasicas.nc''' o crear otros ficheros .nc para agrupar estas constantes. En caso de crear nuevos ficheros .nc, debemos incluirlos siempre en el fichero .npc.
A continuación, mostramos todas aquellas constantes básicas que son necesarias en cualquier centro:

<center>
{|
|align="center" |[[Imagen:constantes_basicas.jpg|border|250px]]
|}
</center>

Para incluir nuevas constantes en el fichero, simplemente hay que seguir el formato visto en la imagen, pudiendo declararlas en cualquier parte del fichero. Únicamente habrá que tener cuidado de modificar las constantes básicas o declarar nuevas constantes con etiquetas ya utilizadas.

==¿Actualizamos el diccionario, el modelo o el centro?==
Cuando realizamos modificaciones en algunos de los elementos que constituyen el modelo de un sistema de información, es necesario utilizar la aplicación '''egAdmin''' para actualizar los cambios que hemos realizado y que se reflejen en la herramienta '''egExplorer'''. En función de los cambios realizados, será necesario actualizar el diccionario, el modelo o el centro.Por tanto:
:*'''¿Cuándo debo actualizar sólo el diccionario?'''Actualizaremos el diccionario cuando modifiquemos una definición de tipo o creemos una definición de tipo nueva en los ficheros .ndf que se encuentran en el directorio '''''#Source'''''

<center>
{|
|align="center" |[[Imagen:actualizardiccionario.jpg|thumb|250px|Actualizar diccionario en egAdmin]]
|}
</center>

:*'''¿Cuándo debo actualizar sólo el modelo?'''Si cambiamos o agregamos algún fichero .rtf (plantillas), .nmt (métodos), .csv (representación de datos), scripts SQL, etc. Es decir, todo aquello que no sea un fichero .ndf.

<center>
{|
|align="center" |[[Imagen:actualizarmodelo.jpg|thumb|250px|Actualizar modelo en egAdmin]]
|}
</center>

:*'''¿Cuándo debo actualizar el diccionario y el centro?'''Actualizaremos el diccionario y el centro cuando incluyamos nuevas definiciones de sistema. Además, cuando creamos tablas nuevas en la base de datos (por ejemplo, nuevas colecciones) o cualquier cambio que afecte a la base de datos. Este caso tiene una particularidad, y es que al tener que actualizar el centro, deberemos pararlo previamente, y una vez actualizado, arrancarlo nuevamente.

<center>
{|
|align="center" |[[Imagen:actualizarmodelo.jpg|thumb|250px|Actualizamos primero el modelo]]
|align="center" |[[Imagen:pararcentro.jpg|thumb|250px|A continuación paramos el centro en el botón '''''Parar''''']]
|align="center" |[[Imagen:actualizarcentro.jpg|thumb|250px|Lo actualizamos y arrancamos en el botón '''''Arrancar''''']]
|}
</center>

:*'''¿Cuándo debo actualizar el diccionario y reiniciar el centro?'''Cuando cambiamos el nombre a la definición de una tarea o definimos una nueva en nuestro código ODL, evidentemente tendremos que actualizar el diccionario. Pero a diferencia del primer caso, en el que sólo tenemos que actualizar el diccionario, en este caso también es necesario parar el centro y volver a arrancarlo (reiniciarlo), pero sin actualizarlo.

[[Categoría:Tutoriales]]

Cómo compilar paso a paso

2009-08-04T08:47:07Z

Imhernandez: /* Crear un fichero de proyecto (.npc) */

Cuando un centro es modificado, bien sea mediante cambios en el diccionario o mediante cambios en el modelo, es necesario realizar una serie de operaciones para que los cambios realizados se vean reflejados en la aplicación egExplorer.
En este artículo abordaremos aquellos aspectos que influyen en dichas modificaciones, así como los pasos a seguir en función de qué elementos o ficheros del modelo se modifiquen. Para ello, es necesario conocer qué ficheros intervienen en el funcionamiento de un centro, y cómo afectan a éste.

__TOC__

==Ejecutando egCompiler==
Al crear un proyecto nuevo o modificar uno ya creado, la primera operación a realizar es compilar el proyecto. Si no se encuentran errores en la compilación, nuestro compilador, egCompiler, generará dos ficheros: un diccionario cuya extensión es '''.ndc''' y un modelo con extensión '''.nmc'''.
Pero, ¿y cómo ejecutamos el compilador?
Para ejecutar el compilador, hay que indicar ciertos parámetros de entrada, ya que el compilador necesita cierta información del proyecto para poder realizar el proceso de compilación.
En concreto, hay un parámetro de entrada fundamental para el compilador, que es el fichero .npc (código de proyecto).
En este fichero se indican, entre otras cosas, la correspondencia entre las definiciones realizadas en ODL, con los ficheros .ndf donde están declaradas. Cualquier definición o fichero .ndf nuevo que se genere deberá ser introducido por el programador en este fichero. Por tanto, deberemos indicar como primer parámetro la ruta de dicho fichero .npc.
Además de este parámetro, que es el único que realmente necesita el compilador, existen otros parámetros opcionales, de forma que podamos configurar ciertos aspectos del compilador. Veamos cuales son:

:*'''/O:''' --> Indicaremos el diccionario previo a la compilación para compararlo con el nuevo diccionario a generar.
:*'''/N:''' --> Indicaremos el directorio de definiciones.
:*'''/D:''' --> Indicaremos el directorio destino donde queramos que se generen el diccionario(.ndc) y el modelo(.nmc). En caso de no especifircarlo se almacenarán en el directorio donde se encuentre el fichero .npc.
:*'''/S:''' --> Su inclusión indica que solamente se genere el diccionario y no el modelo.

Una vez conocidos los parámetros que admite egCompiler, utilizaremos la consola del sistema para ejecutarlo. De esta manera podremos introducir los parámetros que nos interesen en cada ejecución. Veamos un ejemplo:

<center>
{|
|align="center" |[[Imagen:compilarconsola.jpg|thumb|250px|Compilación mediante la consola del sistema]]
|}
</center>

Como habrás visto, lo primero es indicar la ruta del ejecutable del compilador. A continuación, especificamos la ruta del fichero .npc y, seguidamente, añadimos los parámetros opcionales. En este caso, hemos indicado con el parámetro '''/O:''' la existencia de un diccionario previo con el que vamos a comparar el nuevo a generar. Con el parámetro '''/D:''' indicamos una ruta donde queremos guardar los ficheros de salida que generará el compilador, que en este caso será sólo el diccionario, ya que la inclusión del parámetro '''/S:''' así lo indica.
NOTA: En caso de incluir rutas con espacios en blanco en ellas, debemos acotar la ruta completa entre comillas dobles.

==Configuración de egCompiler en EditPlus==
Es probable que la persona que esté desarrollando en ODL tenga que realizar numerosas y repetitivas compilaciones en su proyecto. Por ello, facilitamos una forma de configurar el '''egCompiler''' en un editor de programación, que en este caso, hemos optado por el EditPlus. Sin más preámbulos, veamos cómo configurar dicho editor para ejecutar directamente el compilador desde él:

*Primer paso: ir a '''''Tools''''' -> '''''Preferences''''':

<center>
{|
|align="center" |[[Imagen:Paso0.jpg|thumb|250px|Tools -> Preferences]]
|}
</center>

*Segundo paso: dentro de '''''Preferences''''', ir a la etiqueta '''''User tools''''':

<center>
{|
|align="center" |[[Imagen:Paso1.jpg|thumb|250px|Entrar en User Tools]]
|}
</center>

*Tercer paso: una vez en '''''User tools''''', hay varias opciones y campos que debemos configurar. En primer lugar, vemos que existen varios grupos. Seleccionamos uno de ellos, y para cambiar el nombre haremos click en '''''Group Name...'''''. Estos grupos sirven para etiquetar conjuntos de herramientas que definamos en EditPlus, como por ejemplo, en nuestro caso, la configuración del compilador:

<center>
{|
|align="center" |[[Imagen:Paso2.jpg|thumb|250px|Editar el nombre de un grupo]]
|}
</center>

*Cuarto paso: ahora tenemos que crear una herramienta. Para ello, hacemos click en '''''Add Tool >>'''''. Nos aparecerá un desplegable, donde seleccionaremos '''''Program''''' para indicar que vamos a configurar una aplicación:

<center>
{|
|align="center" |[[Imagen:Paso3.jpg|thumb|250px|Añadimos una herramienta, en este caso, nuestro compilador]]
|}
</center>

*Quinto paso: vemos que hay ciertos campos como '''''Menu text''''', '''''Command''''', '''''Argument''''' o '''''Initial directory''''' además de ciertas opciones activables:

<center>
{|
|align="center" |[[Imagen:Paso4.jpg|thumb|250px|Introducir datos necesarios para la ejecución del compilador]]
|}
</center>

En '''''Menu text''''' pondremos el nombre que aparecerá en el menú de herramientas para ejecutar el compilador.
En '''''Command''''' introduciremos la ruta en donde está almacenado el ejecutable del egCompiler.
En el campo '''''Argument''''' podremos especificar los argumentos que acepta el egCompiler. En nuestro caso, añadiremos el parámetro '''/O:''' (además del fichero .npc como explicamos en el apartado anterior) para que al compilar compare el diccionario previo con el nuevo creado, de manera que pueda detectar los cambios.
A continuación, añadiremos en el campo '''''Initial directory''''' el directorio donde se encuentra el fichero .npc (si no indicamos el directorio destino con el parámetro /D: el compilador almacenará el diccionario y el modelo en este directorio).
Finalmente, activaremos las casillas '''''Capture output''''' para ver los mensajes de compilación en el propio EditPlus (en vez de en una ventana) y '''''Save open files''''' para que al compilar se guarden los ficheros abiertos del proyecto en cuestión. Los ficheros abiertos que no pertenezcan al proyecto no se guardarán.
Ahora veremos que la opción '''''Compilar''''' estará disponible en el menú '''''Tools''''' o '''''Herramientas''''':

<center>
{|
|align="center" |[[Imagen:Paso5.jpg|thumb|250px|El compilador ya se puede utilizar desde EditPlus]]
|}
</center>

==Compilando...==
Una vez hemos ejecutado nuestro compilador, bien mediante la consola del sistema, o bien mediante un editor, el compilador informará al programador de aquellas definiciones que, o bien son nuevas y puede generar un DRC en la base de datos para cada una de ellas, o bien detecta definiciones anteriores que ya no se encuentran en el código (en comparación con un modelo anterior) y, por tanto, es posible la liberación de su DRC. Existe otra operación, que es asignar el DRC de una definición que vamos a eliminar a una nueva que vamos a generar. De esta forma conservamos los valores que se han creado a partir de la definición que vamos a eliminar.
Como ya sabemos, una vez liberados, generados o asignados los DRCs, el compilador generará un diccionario y un modelo.
Veamos un ejemplo práctico:

:*En primer lugar, vamos a generar por primera vez nuestro modelo, de forma que se generará un DRC para todas las definiciones. Podemos ir generando las nuevas definiciones seleccionando de una en una con el botón '''''Generar''''', o bien utilizar el botón '''''Generar todos'''''.Nuestro sistema de información está constituído por dos definiciones de tipo ('''''Cliente''''' y '''''Expediente''''') con sus respectivas colecciones ('''''Clientes->Contenido)''''' y '''''Expedientes->Contenido'''''). Además también hay definida una habitación '''''Mi organización''''' para ubicar dichas colecciones y una definición de rol para acceder a los recursos definidos:

<center>
{|
|align="center" |[[Imagen:Generar_drc.jpg|thumb|250px|Generamos los DRC de las definiciones por primera vez]]
|}
</center>

:*Ahora, hemos decidido eliminar ciertas definiciones, de forma que, al compilar, se comparará el diccionario creado en el paso anterior con el nuevo, y detectará aquellas definiciones que ya no se encuentren en el código. Al igual que al generar DRCs, existe un botón para ir liberando uno a uno cada DRC mediante el botón '''''Liberar''''' o bien liberarlas todas automáticamente, sin tener que seleccionar ninguna, con el botón '''''Liberar todas''''':

<center>
{|
|align="center" |[[Imagen:Liberar_drc.jpg|thumb|250px|Eliminamos la definición de tipo '''''Expediente''''', así como todo aquello relacionado con dicha definición (colección, ubicación y permisos)]]
|}
</center>

:*La tercera posibilidad que nos podemos encontrar es la asignación de un DRC, correspondiente a una definición que vamos a eliminar, a una definición nueva que vamos a generar. En este caso debemos tener en cuenta las posibilidades que se nos pueden presentar, pues pueden ser varias.Normalmente, esta operación se suele realizar al cambiar el nombre de alguna definición, de forma que nos puede interesar asignar el DRC de la definición anterior a la nueva definición para que los valores generados anteriormente al cambio de nombre se mantengan en la nueva definición.Otra posibilidad es, por ejemplo, cambiar el tipo de un campo. En este caso, se podrá asignar el DRC del campo previo al nuevo campo, pero las consecuencias de dicho cambio tendrá que valorarlas el programador, pues puede no conseguirse el efecto deseado.Un nuevo caso, en el que vamos a basar nuestro ejemplo, puede ser el cambio de nombre de un formulario, junto con el cambio de nombre de un campo incluído en dicho formulario. En cuanto a los formularios, hay que tener en cuenta que deben tener el mismo número de campos, además, los campos deben tener el mismo nombre. Vayamos viendo los pasos a realizar uno a uno, de manera que los vayamos comentando:

<center>
{|
|align="center" |[[Imagen:Asignar_drc.jpg|thumb|250px|Relación de las definiciones a liberar o a generar]]
|}
</center>

:Vemos que el compilador ha detectado definiciones que, o bien pueden ser liberadas, o bien pueden ser generadas. Pero nuestra intención es asignar el DRC del formulario '''''Datos generales''''' al formulario '''''Datos generales del cliente'''''. Además, ha detectado que el campo '''''DNI''''' ha cambiado de nombre, detectando un nuevo campo denominado '''''NIF''''' así como el cambio de nombre de la columna '''''DNI''''' de la colección '''''Clientes''''' por '''''NIF''''':

<center>
{|
|align="center" |[[Imagen:Asignar_drc1.jpg|thumb|250px|Primero seleccionamos la definición del DRC que vamos a asignar]]
|align="center" |[[Imagen:Asignar_drc2.jpg|thumb|250px|Seleccionamos la definición nueva, indicando que el DRC será asignado a esa definición]]
|align="center" |[[Imagen:Asignar_drc3.jpg|thumb|250px|Y generamos la asignación con el botón '''''Asignar''''']]
|}
</center>

:Ya tenemos realizada la asignación de la columna que ha cambiado de nombre en la colección '''''Clientes'''''. Ahora vamos a asignar el formulario. Para ello, hay que tener en cuenta que un campo ha cambiado de nombre, y, por tanto, deberemos asignar dicho DRC antes de hacerlo con el formulario:

<center>
{|
|align="center" |[[Imagen:Asignar_drc4.jpg|thumb|250px|Seleccionamos el campo que contiene el DRC]]
|align="center" |[[Imagen:Asignar_drc5.jpg|thumb|250px|Seleccionamos el campo nuevo]]
|align="center" |[[Imagen:Asignar_drc6.jpg|thumb|250px|Y generamos la asignación, al igual que en el caso anterior]]
|}
</center>

:Una vez tratado el campo que ha cambiado de nombre, ya no hay restricciones para asignar el DRC del formulario '''''Datos generales''''' al formulario '''''Datos generales del cliente''''':

<center>
{|
|align="center" |[[Imagen:Asignar_drc7.jpg|thumb|250px|Seleccionamos el formulario que contiene el DRC]]
|align="center" |[[Imagen:Asignar_drc8.jpg|thumb|250px|Seleccionamos el formulario nuevo]]
|align="center" |[[Imagen:Asignar_drc9.jpg|thumb|250px|Y realizamos la asignación]]
|}
</center>

:'''¿Y qué pasa si introduzco, elimino o modifico un atributo en alguna definición?''' Los atributos no tienen asignado un DRC, por lo que cualquier edición que hagamos sobre ellos, el compilador no detectará posibles modificaciones en los DRC del sistema.

==Crear un fichero de proyecto (.npc)==
Como ya hemos comentado en este artículo, a la hora de compilar un proyecto en ODL es necesario especificar el fichero

.npc en el egCompiler.
Este fichero deberá ser creado manualmente por el desarrollador, por lo que vamos a explicar a continuación la información

que debe almacenar, la estructura que tiene que adoptar y las funciones para las cuales está destinado este fichero.
Cuando instalamos un centro, la estructura de directorios que tendrá el centro una vez instalado está predefinido en un

modelo por defecto llamado ('''Default'''), que tiene la siguiente estructura:

<center>
{|
|align="center" |[[Imagen:estructura_default.jpg|thumb|250px|Compilación mediante la consola del sistema]]
|}
</center>

En nuestro directorio de desarrollo, crearemos aquellas carpetas (que existan en el modelo '''Default''') que vayamos a

modificar. Por ejemplo, si nuestro centro tiene escritos, tendremos que crear una carpeta llamada '''Template documents''',

donde almacenaremos los ficheros .rtf de nuestro centro.

Una vez creado el modelo del centro, lo instalaremos mediante el egAdmin. Éste comparará el modelo '''Default''' con

nuestro modelo de centro, de manera que las carpetas que se encuentren en ambos modelos serán fusionadas. Es decir, que, por

ejemplo, la carpeta '''Template documents''', donde hemos añadido los ficheros rtf, aparecerá con los ficheros rtf en el

directorio de explotación del centro (y no vacío como aparece en el modelo Default).

Pero, ¿y cómo interviene el fichero .npc en todo este proceso de compilación e instalación de un centro?

El fichero .npc tiene varias funciones en todo este proceso.

Por un lado, informará al compilador de las definiciones que serán compiladas y de las cuales saldrá el diccionario

resultante. Por otro lado, informará al compilador de aquellas carpetas que se han creado en el directorio de desarrollo y

que se quieren incluir en el modelo de centro para su posterior instalación. Por ello, es un fichero fundamental para la

compilación de nuestro centro.

La estructura de un fichero .npc debe ser la siguiente:

<center>
{|
|align="center" |[[Imagen:estructura_npc.jpg|thumb|250px|Compilación mediante la consola del sistema]]
|}
</center>

Las palabras enmarcadas en verde son palabras clave que deben ir en el fichero.
Para el caso de la cabecera, añadiremos un campo donde añadiremos un nombre.
En todos los centros, es necesario crear al menos un fichero de constantes básicas. Este fichero .nc deberá ir

especificado en la palabra clave '''Constantes'''. En caso de existir más de un fichero, se especificarán uno debajo de

otro.
En caso de querer especificar una carpeta de plantillas de escritos, plantillas de impresión o plantillas de vistas, lo

haremos en las palabras clave '''Plantillas_documentos''' para la carpeta [Template documents],

'''Plantillas_visualizacion''' para la carpeta [Template views] o '''Plantillas_impresion''' para la carpeta [Template

prints].
Hay que tener en cuenta que el directorio de las carpetas se especifica a partir del directorio donde esté alojado el

fichero .npc. Si la carpeta [Template documents] está en la misma carpeta que el fichero .npc, no habrá que añadir ninguna

ruta.
Por último, tendremos que especificar las definiciones para generar el diccionario. Esto lo haremos bajo la palabra clave

'''Definiciones'''. Para ello, indicaremos el nombre de la unidad de cada fichero .ndf con el directorio donde se encuentra

el fichero .ndf, tal y como hemos podido ver en la imagen anterior.

==Crear un fichero de constantes (.nc)==
Otro tipo de fichero que tiene que ser creado por el desarrollador son los ficheros de constantes (.nc). Estos ficheros especifican las constantes que se utilizan en un centro.
Existen ciertas constantes básicas que deben ser incluidas en un fichero que tiene que llamarse '''CBasicas.nc'''. Estas constantes básicas, coinciden en etiqueta con algunas palabras reservadas del propio lenguaje ODL. Esto es así porque en el proceso de compilación, las definiciones se crearán en función de los valores de las constantes y no de sus etiquetas.
Por ejemplo, en el conjunto de estas constantes básicas, existe una cuya etiqueta es '''ENTERO''', que tiene valor '''1'''. Cuando en nuestro código ODL definimos un campo entero, en el proceso de compilación la definición del campo será creada con el valor de la constante y no de la etiqueta. A continuación, cuando ejecutemos la aplicación egExplorer, que cargará el diccionario generado por el compilador, leerá que existe una definición de campo con valor 1, que interpretará como un campo entero.
Para que este comportamiento se lleve a cabo, debe existir una referencia en el fichero .npc al fichero .nc de constantes básicas. Esto es debido a que el parámetro que se le pasa al compilador es el fichero .npc de nuestro proyecto.
Aparte de las constante básicas, es posible que el desarrollador quiera declarar nuevas constantes. Esto podrá hacerlo en el mismo fichero '''CBasicas.nc''' o crear otros ficheros .nc para agrupar estas constantes. En caso de crear nuevos ficheros .nc, debemos incluirlos siempre en el fichero .npc.
A continuación, mostramos todas aquellas constantes básicas que son necesarias en cualquier centro:

<center>
{|
|align="center" |[[Imagen:constantes_basicas.jpg|border|250px]]
|}
</center>

Para incluir nuevas constantes en el fichero, simplemente hay que seguir el formato visto en la imagen, pudiendo declararlas en cualquier parte del fichero. Únicamente habrá que tener cuidado de modificar las constantes básicas o declarar nuevas constantes con etiquetas ya utilizadas.

==¿Actualizamos el diccionario, el modelo o el centro?==
Cuando realizamos modificaciones en algunos de los elementos que constituyen el modelo de un sistema de información, es necesario utilizar la aplicación '''egAdmin''' para actualizar los cambios que hemos realizado y que se reflejen en la herramienta '''egExplorer'''. En función de los cambios realizados, será necesario actualizar el diccionario, el modelo o el centro.Por tanto:
:*'''¿Cuándo debo actualizar sólo el diccionario?'''Actualizaremos el diccionario cuando modifiquemos una definición de tipo o creemos una definición de tipo nueva en los ficheros .ndf que se encuentran en el directorio '''''#Source'''''

<center>
{|
|align="center" |[[Imagen:actualizardiccionario.jpg|thumb|250px|Actualizar diccionario en egAdmin]]
|}
</center>

:*'''¿Cuándo debo actualizar sólo el modelo?'''Si cambiamos o agregamos algún fichero .rtf (plantillas), .nmt (métodos), .csv (representación de datos), scripts SQL, etc. Es decir, todo aquello que no sea un fichero .ndf.

<center>
{|
|align="center" |[[Imagen:actualizarmodelo.jpg|thumb|250px|Actualizar modelo en egAdmin]]
|}
</center>

:*'''¿Cuándo debo actualizar el diccionario y el centro?'''Actualizaremos el diccionario y el centro cuando incluyamos nuevas definiciones de sistema. Además, cuando creamos tablas nuevas en la base de datos (por ejemplo, nuevas colecciones) o cualquier cambio que afecte a la base de datos. Este caso tiene una particularidad, y es que al tener que actualizar el centro, deberemos pararlo previamente, y una vez actualizado, arrancarlo nuevamente.

<center>
{|
|align="center" |[[Imagen:actualizarmodelo.jpg|thumb|250px|Actualizamos primero el modelo]]
|align="center" |[[Imagen:pararcentro.jpg|thumb|250px|A continuación paramos el centro en el botón '''''Parar''''']]
|align="center" |[[Imagen:actualizarcentro.jpg|thumb|250px|Lo actualizamos y arrancamos en el botón '''''Arrancar''''']]
|}
</center>

:*'''¿Cuándo debo actualizar el diccionario y reiniciar el centro?'''Cuando cambiamos el nombre a la definición de una tarea o definimos una nueva en nuestro código ODL, evidentemente tendremos que actualizar el diccionario. Pero a diferencia del primer caso, en el que sólo tenemos que actualizar el diccionario, en este caso también es necesario parar el centro y volver a arrancarlo (reiniciarlo), pero sin actualizarlo.

[[Categoría:Tutoriales]]

Cómo compilar paso a paso

2009-08-04T08:40:01Z

Imhernandez: /* Compilando... */

Cuando un centro es modificado, bien sea mediante cambios en el diccionario o mediante cambios en el modelo, es necesario realizar una serie de operaciones para que los cambios realizados se vean reflejados en la aplicación egExplorer.
En este artículo abordaremos aquellos aspectos que influyen en dichas modificaciones, así como los pasos a seguir en función de qué elementos o ficheros del modelo se modifiquen. Para ello, es necesario conocer qué ficheros intervienen en el funcionamiento de un centro, y cómo afectan a éste.

__TOC__

==Ejecutando egCompiler==
Al crear un proyecto nuevo o modificar uno ya creado, la primera operación a realizar es compilar el proyecto. Si no se encuentran errores en la compilación, nuestro compilador, egCompiler, generará dos ficheros: un diccionario cuya extensión es '''.ndc''' y un modelo con extensión '''.nmc'''.
Pero, ¿y cómo ejecutamos el compilador?
Para ejecutar el compilador, hay que indicar ciertos parámetros de entrada, ya que el compilador necesita cierta información del proyecto para poder realizar el proceso de compilación.
En concreto, hay un parámetro de entrada fundamental para el compilador, que es el fichero .npc (código de proyecto).
En este fichero se indican, entre otras cosas, la correspondencia entre las definiciones realizadas en ODL, con los ficheros .ndf donde están declaradas. Cualquier definición o fichero .ndf nuevo que se genere deberá ser introducido por el programador en este fichero. Por tanto, deberemos indicar como primer parámetro la ruta de dicho fichero .npc.
Además de este parámetro, que es el único que realmente necesita el compilador, existen otros parámetros opcionales, de forma que podamos configurar ciertos aspectos del compilador. Veamos cuales son:

:*'''/O:''' --> Indicaremos el diccionario previo a la compilación para compararlo con el nuevo diccionario a generar.
:*'''/N:''' --> Indicaremos el directorio de definiciones.
:*'''/D:''' --> Indicaremos el directorio destino donde queramos que se generen el diccionario(.ndc) y el modelo(.nmc). En caso de no especifircarlo se almacenarán en el directorio donde se encuentre el fichero .npc.
:*'''/S:''' --> Su inclusión indica que solamente se genere el diccionario y no el modelo.

Una vez conocidos los parámetros que admite egCompiler, utilizaremos la consola del sistema para ejecutarlo. De esta manera podremos introducir los parámetros que nos interesen en cada ejecución. Veamos un ejemplo:

<center>
{|
|align="center" |[[Imagen:compilarconsola.jpg|thumb|250px|Compilación mediante la consola del sistema]]
|}
</center>

Como habrás visto, lo primero es indicar la ruta del ejecutable del compilador. A continuación, especificamos la ruta del fichero .npc y, seguidamente, añadimos los parámetros opcionales. En este caso, hemos indicado con el parámetro '''/O:''' la existencia de un diccionario previo con el que vamos a comparar el nuevo a generar. Con el parámetro '''/D:''' indicamos una ruta donde queremos guardar los ficheros de salida que generará el compilador, que en este caso será sólo el diccionario, ya que la inclusión del parámetro '''/S:''' así lo indica.
NOTA: En caso de incluir rutas con espacios en blanco en ellas, debemos acotar la ruta completa entre comillas dobles.

==Configuración de egCompiler en EditPlus==
Es probable que la persona que esté desarrollando en ODL tenga que realizar numerosas y repetitivas compilaciones en su proyecto. Por ello, facilitamos una forma de configurar el '''egCompiler''' en un editor de programación, que en este caso, hemos optado por el EditPlus. Sin más preámbulos, veamos cómo configurar dicho editor para ejecutar directamente el compilador desde él:

*Primer paso: ir a '''''Tools''''' -> '''''Preferences''''':

<center>
{|
|align="center" |[[Imagen:Paso0.jpg|thumb|250px|Tools -> Preferences]]
|}
</center>

*Segundo paso: dentro de '''''Preferences''''', ir a la etiqueta '''''User tools''''':

<center>
{|
|align="center" |[[Imagen:Paso1.jpg|thumb|250px|Entrar en User Tools]]
|}
</center>

*Tercer paso: una vez en '''''User tools''''', hay varias opciones y campos que debemos configurar. En primer lugar, vemos que existen varios grupos. Seleccionamos uno de ellos, y para cambiar el nombre haremos click en '''''Group Name...'''''. Estos grupos sirven para etiquetar conjuntos de herramientas que definamos en EditPlus, como por ejemplo, en nuestro caso, la configuración del compilador:

<center>
{|
|align="center" |[[Imagen:Paso2.jpg|thumb|250px|Editar el nombre de un grupo]]
|}
</center>

*Cuarto paso: ahora tenemos que crear una herramienta. Para ello, hacemos click en '''''Add Tool >>'''''. Nos aparecerá un desplegable, donde seleccionaremos '''''Program''''' para indicar que vamos a configurar una aplicación:

<center>
{|
|align="center" |[[Imagen:Paso3.jpg|thumb|250px|Añadimos una herramienta, en este caso, nuestro compilador]]
|}
</center>

*Quinto paso: vemos que hay ciertos campos como '''''Menu text''''', '''''Command''''', '''''Argument''''' o '''''Initial directory''''' además de ciertas opciones activables:

<center>
{|
|align="center" |[[Imagen:Paso4.jpg|thumb|250px|Introducir datos necesarios para la ejecución del compilador]]
|}
</center>

En '''''Menu text''''' pondremos el nombre que aparecerá en el menú de herramientas para ejecutar el compilador.
En '''''Command''''' introduciremos la ruta en donde está almacenado el ejecutable del egCompiler.
En el campo '''''Argument''''' podremos especificar los argumentos que acepta el egCompiler. En nuestro caso, añadiremos el parámetro '''/O:''' (además del fichero .npc como explicamos en el apartado anterior) para que al compilar compare el diccionario previo con el nuevo creado, de manera que pueda detectar los cambios.
A continuación, añadiremos en el campo '''''Initial directory''''' el directorio donde se encuentra el fichero .npc (si no indicamos el directorio destino con el parámetro /D: el compilador almacenará el diccionario y el modelo en este directorio).
Finalmente, activaremos las casillas '''''Capture output''''' para ver los mensajes de compilación en el propio EditPlus (en vez de en una ventana) y '''''Save open files''''' para que al compilar se guarden los ficheros abiertos del proyecto en cuestión. Los ficheros abiertos que no pertenezcan al proyecto no se guardarán.
Ahora veremos que la opción '''''Compilar''''' estará disponible en el menú '''''Tools''''' o '''''Herramientas''''':

<center>
{|
|align="center" |[[Imagen:Paso5.jpg|thumb|250px|El compilador ya se puede utilizar desde EditPlus]]
|}
</center>

==Compilando...==
Una vez hemos ejecutado nuestro compilador, bien mediante la consola del sistema, o bien mediante un editor, el compilador informará al programador de aquellas definiciones que, o bien son nuevas y puede generar un DRC en la base de datos para cada una de ellas, o bien detecta definiciones anteriores que ya no se encuentran en el código (en comparación con un modelo anterior) y, por tanto, es posible la liberación de su DRC. Existe otra operación, que es asignar el DRC de una definición que vamos a eliminar a una nueva que vamos a generar. De esta forma conservamos los valores que se han creado a partir de la definición que vamos a eliminar.
Como ya sabemos, una vez liberados, generados o asignados los DRCs, el compilador generará un diccionario y un modelo.
Veamos un ejemplo práctico:

:*En primer lugar, vamos a generar por primera vez nuestro modelo, de forma que se generará un DRC para todas las definiciones. Podemos ir generando las nuevas definiciones seleccionando de una en una con el botón '''''Generar''''', o bien utilizar el botón '''''Generar todos'''''.Nuestro sistema de información está constituído por dos definiciones de tipo ('''''Cliente''''' y '''''Expediente''''') con sus respectivas colecciones ('''''Clientes->Contenido)''''' y '''''Expedientes->Contenido'''''). Además también hay definida una habitación '''''Mi organización''''' para ubicar dichas colecciones y una definición de rol para acceder a los recursos definidos:

<center>
{|
|align="center" |[[Imagen:Generar_drc.jpg|thumb|250px|Generamos los DRC de las definiciones por primera vez]]
|}
</center>

:*Ahora, hemos decidido eliminar ciertas definiciones, de forma que, al compilar, se comparará el diccionario creado en el paso anterior con el nuevo, y detectará aquellas definiciones que ya no se encuentren en el código. Al igual que al generar DRCs, existe un botón para ir liberando uno a uno cada DRC mediante el botón '''''Liberar''''' o bien liberarlas todas automáticamente, sin tener que seleccionar ninguna, con el botón '''''Liberar todas''''':

<center>
{|
|align="center" |[[Imagen:Liberar_drc.jpg|thumb|250px|Eliminamos la definición de tipo '''''Expediente''''', así como todo aquello relacionado con dicha definición (colección, ubicación y permisos)]]
|}
</center>

:*La tercera posibilidad que nos podemos encontrar es la asignación de un DRC, correspondiente a una definición que vamos a eliminar, a una definición nueva que vamos a generar. En este caso debemos tener en cuenta las posibilidades que se nos pueden presentar, pues pueden ser varias.Normalmente, esta operación se suele realizar al cambiar el nombre de alguna definición, de forma que nos puede interesar asignar el DRC de la definición anterior a la nueva definición para que los valores generados anteriormente al cambio de nombre se mantengan en la nueva definición.Otra posibilidad es, por ejemplo, cambiar el tipo de un campo. En este caso, se podrá asignar el DRC del campo previo al nuevo campo, pero las consecuencias de dicho cambio tendrá que valorarlas el programador, pues puede no conseguirse el efecto deseado.Un nuevo caso, en el que vamos a basar nuestro ejemplo, puede ser el cambio de nombre de un formulario, junto con el cambio de nombre de un campo incluído en dicho formulario. En cuanto a los formularios, hay que tener en cuenta que deben tener el mismo número de campos, además, los campos deben tener el mismo nombre. Vayamos viendo los pasos a realizar uno a uno, de manera que los vayamos comentando:

<center>
{|
|align="center" |[[Imagen:Asignar_drc.jpg|thumb|250px|Relación de las definiciones a liberar o a generar]]
|}
</center>

:Vemos que el compilador ha detectado definiciones que, o bien pueden ser liberadas, o bien pueden ser generadas. Pero nuestra intención es asignar el DRC del formulario '''''Datos generales''''' al formulario '''''Datos generales del cliente'''''. Además, ha detectado que el campo '''''DNI''''' ha cambiado de nombre, detectando un nuevo campo denominado '''''NIF''''' así como el cambio de nombre de la columna '''''DNI''''' de la colección '''''Clientes''''' por '''''NIF''''':

<center>
{|
|align="center" |[[Imagen:Asignar_drc1.jpg|thumb|250px|Primero seleccionamos la definición del DRC que vamos a asignar]]
|align="center" |[[Imagen:Asignar_drc2.jpg|thumb|250px|Seleccionamos la definición nueva, indicando que el DRC será asignado a esa definición]]
|align="center" |[[Imagen:Asignar_drc3.jpg|thumb|250px|Y generamos la asignación con el botón '''''Asignar''''']]
|}
</center>

:Ya tenemos realizada la asignación de la columna que ha cambiado de nombre en la colección '''''Clientes'''''. Ahora vamos a asignar el formulario. Para ello, hay que tener en cuenta que un campo ha cambiado de nombre, y, por tanto, deberemos asignar dicho DRC antes de hacerlo con el formulario:

<center>
{|
|align="center" |[[Imagen:Asignar_drc4.jpg|thumb|250px|Seleccionamos el campo que contiene el DRC]]
|align="center" |[[Imagen:Asignar_drc5.jpg|thumb|250px|Seleccionamos el campo nuevo]]
|align="center" |[[Imagen:Asignar_drc6.jpg|thumb|250px|Y generamos la asignación, al igual que en el caso anterior]]
|}
</center>

:Una vez tratado el campo que ha cambiado de nombre, ya no hay restricciones para asignar el DRC del formulario '''''Datos generales''''' al formulario '''''Datos generales del cliente''''':

<center>
{|
|align="center" |[[Imagen:Asignar_drc7.jpg|thumb|250px|Seleccionamos el formulario que contiene el DRC]]
|align="center" |[[Imagen:Asignar_drc8.jpg|thumb|250px|Seleccionamos el formulario nuevo]]
|align="center" |[[Imagen:Asignar_drc9.jpg|thumb|250px|Y realizamos la asignación]]
|}
</center>

:'''¿Y qué pasa si introduzco, elimino o modifico un atributo en alguna definición?''' Los atributos no tienen asignado un DRC, por lo que cualquier edición que hagamos sobre ellos, el compilador no detectará posibles modificaciones en los DRC del sistema.

==Crear un fichero de proyecto (.npc)==
Como ya hemos comentado en este artículo, a la hora de compilar un proyecto en ODL es necesario especificar el fichero

.npc en el egCompiler.
Este fichero deberá ser creado manualmente por el desarrollador y por ello vamos a explicar a continuación la información

que debe almacenar, la estructura que tiene que adoptar y las funciones para las cuales está destinado este fichero.
Cuando instalamos un centro, la estructura de directorios que tendrá el centro una vez instalado está predefinido en un

modelo por defecto llamado ('''Default'''), que tiene la siguiente estructura:

<center>
{|
|align="center" |[[Imagen:estructura_default.jpg|thumb|250px|Compilación mediante la consola del sistema]]
|}
</center>

En nuestro directorio de desarrollo, crearemos aquellas carpetas (que existan en el modelo '''Default''') que vayamos a

modificar. Por ejemplo, si nuestro centro tiene escritos, tendremos que crear una carpeta llamada '''Template documents'''

donde almacenaremos los ficheros .rtf de nuestro centro.

Una vez creado el modelo de centro, lo instalaremos mediante el egAdmin. Éste, comparará el modelo '''Default''' con

nuestro modelo de centro, de manera que las carpetas que se encuentren en ambos modelos, serán fusionadas. Es decir, que por

ejemplo, la carpeta '''Template documents''' donde hemos añadido los ficheros rtf, aparecerá con los ficheros rtf en el

directorio de explotación del centro (y no vacío como aparece en el modelo Default).

Pero, ¿y cómo interviene el fichero .npc en todo este proceso de compilación e instalación de un centro?

El fichero .npc tiene varias funciones en todo este proceso.

Por un lado, informará al compilador de las definiciones que serán compiladas y de las cuales saldrá el diccionario

resultante. Por otro lado, informará al compilador de aquellas carpetas que se han creado en el directorio de desarrollo y

que se quieren incluir en el modelo de centro para su posterior instalación. Por ello, es un fichero fundamental para la

compilación de nuestro centro.

La estructura de un fichero .npc debe ser la siguiente:

<center>
{|
|align="center" |[[Imagen:estructura_npc.jpg|thumb|250px|Compilación mediante la consola del sistema]]
|}
</center>

Las palabras enmarcadas en verde son palabras clave que deben ir en el fichero.
Para el caso de la cabecera, añadiremos un campo donde añadiremos un nombre.
En todos los centros, es necesario crear al menos un fichero de constantes básicas. Este fichero .nc deberá ir

especificado en la palabra clave '''Constantes'''. En caso de existir más de un fichero, se especificarán uno debajo de

otro.
En caso de querer especificar una carpeta de plantillas de escritos, plantillas de impresión o plantillas de vistas, lo

haremos en las palabras clave '''Plantillas_documentos''' para la carpeta [Template documents],

'''Plantillas_visualizacion''' para la carpeta [Template views] o '''Plantillas_impresion''' para la carpeta [Template

prints].
Hay que tener en cuenta que el directorio de las carpetas se especifica a partir del directorio donde esté alojado el

fichero .npc. Si la carpeta [Template documents] está en la misma carpeta que el fichero .npc, no habrá que añadir ninguna

ruta.
Por último, tendremos que especificar las definiciones para generar el diccionario. Esto lo haremos bajo la palabra clave

'''Definiciones'''. Para ello, indicaremos el nombre de la unidad de cada fichero .ndf con el directorio donde se encuentra

el fichero .ndf, tal y como hemos podido ver en la imagen anterior.

==Crear un fichero de constantes (.nc)==
Otro tipo de fichero que tiene que ser creado por el desarrollador son los ficheros de constantes (.nc). Estos ficheros especifican las constantes que se utilizan en un centro.
Existen ciertas constantes básicas que deben ser incluidas en un fichero que tiene que llamarse '''CBasicas.nc'''. Estas constantes básicas, coinciden en etiqueta con algunas palabras reservadas del propio lenguaje ODL. Esto es así porque en el proceso de compilación, las definiciones se crearán en función de los valores de las constantes y no de sus etiquetas.
Por ejemplo, en el conjunto de estas constantes básicas, existe una cuya etiqueta es '''ENTERO''', que tiene valor '''1'''. Cuando en nuestro código ODL definimos un campo entero, en el proceso de compilación la definición del campo será creada con el valor de la constante y no de la etiqueta. A continuación, cuando ejecutemos la aplicación egExplorer, que cargará el diccionario generado por el compilador, leerá que existe una definición de campo con valor 1, que interpretará como un campo entero.
Para que este comportamiento se lleve a cabo, debe existir una referencia en el fichero .npc al fichero .nc de constantes básicas. Esto es debido a que el parámetro que se le pasa al compilador es el fichero .npc de nuestro proyecto.
Aparte de las constante básicas, es posible que el desarrollador quiera declarar nuevas constantes. Esto podrá hacerlo en el mismo fichero '''CBasicas.nc''' o crear otros ficheros .nc para agrupar estas constantes. En caso de crear nuevos ficheros .nc, debemos incluirlos siempre en el fichero .npc.
A continuación, mostramos todas aquellas constantes básicas que son necesarias en cualquier centro:

<center>
{|
|align="center" |[[Imagen:constantes_basicas.jpg|border|250px]]
|}
</center>

Para incluir nuevas constantes en el fichero, simplemente hay que seguir el formato visto en la imagen, pudiendo declararlas en cualquier parte del fichero. Únicamente habrá que tener cuidado de modificar las constantes básicas o declarar nuevas constantes con etiquetas ya utilizadas.

==¿Actualizamos el diccionario, el modelo o el centro?==
Cuando realizamos modificaciones en algunos de los elementos que constituyen el modelo de un sistema de información, es necesario utilizar la aplicación '''egAdmin''' para actualizar los cambios que hemos realizado y que se reflejen en la herramienta '''egExplorer'''. En función de los cambios realizados, será necesario actualizar el diccionario, el modelo o el centro.Por tanto:
:*'''¿Cuándo debo actualizar sólo el diccionario?'''Actualizaremos el diccionario cuando modifiquemos una definición de tipo o creemos una definición de tipo nueva en los ficheros .ndf que se encuentran en el directorio '''''#Source'''''

<center>
{|
|align="center" |[[Imagen:actualizardiccionario.jpg|thumb|250px|Actualizar diccionario en egAdmin]]
|}
</center>

:*'''¿Cuándo debo actualizar sólo el modelo?'''Si cambiamos o agregamos algún fichero .rtf (plantillas), .nmt (métodos), .csv (representación de datos), scripts SQL, etc. Es decir, todo aquello que no sea un fichero .ndf.

<center>
{|
|align="center" |[[Imagen:actualizarmodelo.jpg|thumb|250px|Actualizar modelo en egAdmin]]
|}
</center>

:*'''¿Cuándo debo actualizar el diccionario y el centro?'''Actualizaremos el diccionario y el centro cuando incluyamos nuevas definiciones de sistema. Además, cuando creamos tablas nuevas en la base de datos (por ejemplo, nuevas colecciones) o cualquier cambio que afecte a la base de datos. Este caso tiene una particularidad, y es que al tener que actualizar el centro, deberemos pararlo previamente, y una vez actualizado, arrancarlo nuevamente.

<center>
{|
|align="center" |[[Imagen:actualizarmodelo.jpg|thumb|250px|Actualizamos primero el modelo]]
|align="center" |[[Imagen:pararcentro.jpg|thumb|250px|A continuación paramos el centro en el botón '''''Parar''''']]
|align="center" |[[Imagen:actualizarcentro.jpg|thumb|250px|Lo actualizamos y arrancamos en el botón '''''Arrancar''''']]
|}
</center>

:*'''¿Cuándo debo actualizar el diccionario y reiniciar el centro?'''Cuando cambiamos el nombre a la definición de una tarea o definimos una nueva en nuestro código ODL, evidentemente tendremos que actualizar el diccionario. Pero a diferencia del primer caso, en el que sólo tenemos que actualizar el diccionario, en este caso también es necesario parar el centro y volver a arrancarlo (reiniciarlo), pero sin actualizarlo.

[[Categoría:Tutoriales]]

Cómo compilar paso a paso

2009-08-04T08:30:13Z

Imhernandez: /* Ejecutando egCompiler */

Cuando un centro es modificado, bien sea mediante cambios en el diccionario o mediante cambios en el modelo, es necesario realizar una serie de operaciones para que los cambios realizados se vean reflejados en la aplicación egExplorer.
En este artículo abordaremos aquellos aspectos que influyen en dichas modificaciones, así como los pasos a seguir en función de qué elementos o ficheros del modelo se modifiquen. Para ello, es necesario conocer qué ficheros intervienen en el funcionamiento de un centro, y cómo afectan a éste.

__TOC__

==Ejecutando egCompiler==
Al crear un proyecto nuevo o modificar uno ya creado, la primera operación a realizar es compilar el proyecto. Si no se encuentran errores en la compilación, nuestro compilador, egCompiler, generará dos ficheros: un diccionario cuya extensión es '''.ndc''' y un modelo con extensión '''.nmc'''.
Pero, ¿y cómo ejecutamos el compilador?
Para ejecutar el compilador, hay que indicar ciertos parámetros de entrada, ya que el compilador necesita cierta información del proyecto para poder realizar el proceso de compilación.
En concreto, hay un parámetro de entrada fundamental para el compilador, que es el fichero .npc (código de proyecto).
En este fichero se indican, entre otras cosas, la correspondencia entre las definiciones realizadas en ODL, con los ficheros .ndf donde están declaradas. Cualquier definición o fichero .ndf nuevo que se genere deberá ser introducido por el programador en este fichero. Por tanto, deberemos indicar como primer parámetro la ruta de dicho fichero .npc.
Además de este parámetro, que es el único que realmente necesita el compilador, existen otros parámetros opcionales, de forma que podamos configurar ciertos aspectos del compilador. Veamos cuales son:

:*'''/O:''' --> Indicaremos el diccionario previo a la compilación para compararlo con el nuevo diccionario a generar.
:*'''/N:''' --> Indicaremos el directorio de definiciones.
:*'''/D:''' --> Indicaremos el directorio destino donde queramos que se generen el diccionario(.ndc) y el modelo(.nmc). En caso de no especifircarlo se almacenarán en el directorio donde se encuentre el fichero .npc.
:*'''/S:''' --> Su inclusión indica que solamente se genere el diccionario y no el modelo.

Una vez conocidos los parámetros que admite egCompiler, utilizaremos la consola del sistema para ejecutarlo. De esta manera podremos introducir los parámetros que nos interesen en cada ejecución. Veamos un ejemplo:

<center>
{|
|align="center" |[[Imagen:compilarconsola.jpg|thumb|250px|Compilación mediante la consola del sistema]]
|}
</center>

Como habrás visto, lo primero es indicar la ruta del ejecutable del compilador. A continuación, especificamos la ruta del fichero .npc y, seguidamente, añadimos los parámetros opcionales. En este caso, hemos indicado con el parámetro '''/O:''' la existencia de un diccionario previo con el que vamos a comparar el nuevo a generar. Con el parámetro '''/D:''' indicamos una ruta donde queremos guardar los ficheros de salida que generará el compilador, que en este caso será sólo el diccionario, ya que la inclusión del parámetro '''/S:''' así lo indica.
NOTA: En caso de incluir rutas con espacios en blanco en ellas, debemos acotar la ruta completa entre comillas dobles.

==Configuración de egCompiler en EditPlus==
Es probable que la persona que esté desarrollando en ODL tenga que realizar numerosas y repetitivas compilaciones en su proyecto. Por ello, facilitamos una forma de configurar el '''egCompiler''' en un editor de programación, que en este caso, hemos optado por el EditPlus. Sin más preámbulos, veamos cómo configurar dicho editor para ejecutar directamente el compilador desde él:

*Primer paso: ir a '''''Tools''''' -> '''''Preferences''''':

<center>
{|
|align="center" |[[Imagen:Paso0.jpg|thumb|250px|Tools -> Preferences]]
|}
</center>

*Segundo paso: dentro de '''''Preferences''''', ir a la etiqueta '''''User tools''''':

<center>
{|
|align="center" |[[Imagen:Paso1.jpg|thumb|250px|Entrar en User Tools]]
|}
</center>

*Tercer paso: una vez en '''''User tools''''', hay varias opciones y campos que debemos configurar. En primer lugar, vemos que existen varios grupos. Seleccionamos uno de ellos, y para cambiar el nombre haremos click en '''''Group Name...'''''. Estos grupos sirven para etiquetar conjuntos de herramientas que definamos en EditPlus, como por ejemplo, en nuestro caso, la configuración del compilador:

<center>
{|
|align="center" |[[Imagen:Paso2.jpg|thumb|250px|Editar el nombre de un grupo]]
|}
</center>

*Cuarto paso: ahora tenemos que crear una herramienta. Para ello, hacemos click en '''''Add Tool >>'''''. Nos aparecerá un desplegable, donde seleccionaremos '''''Program''''' para indicar que vamos a configurar una aplicación:

<center>
{|
|align="center" |[[Imagen:Paso3.jpg|thumb|250px|Añadimos una herramienta, en este caso, nuestro compilador]]
|}
</center>

*Quinto paso: vemos que hay ciertos campos como '''''Menu text''''', '''''Command''''', '''''Argument''''' o '''''Initial directory''''' además de ciertas opciones activables:

<center>
{|
|align="center" |[[Imagen:Paso4.jpg|thumb|250px|Introducir datos necesarios para la ejecución del compilador]]
|}
</center>

En '''''Menu text''''' pondremos el nombre que aparecerá en el menú de herramientas para ejecutar el compilador.
En '''''Command''''' introduciremos la ruta en donde está almacenado el ejecutable del egCompiler.
En el campo '''''Argument''''' podremos especificar los argumentos que acepta el egCompiler. En nuestro caso, añadiremos el parámetro '''/O:''' (además del fichero .npc como explicamos en el apartado anterior) para que al compilar compare el diccionario previo con el nuevo creado, de manera que pueda detectar los cambios.
A continuación, añadiremos en el campo '''''Initial directory''''' el directorio donde se encuentra el fichero .npc (si no indicamos el directorio destino con el parámetro /D: el compilador almacenará el diccionario y el modelo en este directorio).
Finalmente, activaremos las casillas '''''Capture output''''' para ver los mensajes de compilación en el propio EditPlus (en vez de en una ventana) y '''''Save open files''''' para que al compilar se guarden los ficheros abiertos del proyecto en cuestión. Los ficheros abiertos que no pertenezcan al proyecto no se guardarán.
Ahora veremos que la opción '''''Compilar''''' estará disponible en el menú '''''Tools''''' o '''''Herramientas''''':

<center>
{|
|align="center" |[[Imagen:Paso5.jpg|thumb|250px|El compilador ya se puede utilizar desde EditPlus]]
|}
</center>

==Compilando...==
Una vez hemos ejecutado nuestro compilador, bien mediante la consola del sistema, o bien mediante un editor, el compilador informará al programador de aquellas definiciones que, o bien son nuevas y puede generar un DRC en la base de datos para cada una de ellas, o bien detecta definiciones anteriores que ya no se encuentran en el código (en comparación con un modelo anterior) y por tanto es posible la liberación de su DRC. Existe otra operación, que es asignar el DRC de una definición que vamos a eliminar a una nueva que vamos a generar, para conservar los valores que se han creado a partir de la definición que vamos a eliminar.
Como ya sabemos, una vez liberados, generados o asignados los DRCs, el compilador generará un diccionario y un modelo.
Veamos un ejemplo práctico:

:*En primer lugar, vamos a generar por primera vez nuestro modelo, de forma que se generará un DRC para todas las definiciones. Podemos ir generando las nuevas definiciones seleccionando de una en una con el botón '''''Generar''''', o bien utilizar el botón '''''Generar todos'''''.Nuestro sistema de información está constuído por dos definiciones de tipo ('''''Cliente''''' y '''''Expediente''''') con sus respectivas colecciones ('''''Clientes->Contenido)''''' y '''''Expedientes->Contenido'''''). Además también hay definida una habitación '''''Mi organización''''' para ubicar dichas colecciones y una definición de rol para acceder a los recursos definidos:

<center>
{|
|align="center" |[[Imagen:Generar_drc.jpg|thumb|250px|Generamos los DRC de las definiciones por primera vez]]
|}
</center>

:*Ahora, hemos decidido eliminar ciertas definiciones, de forma que al compilar, se comparará el diccionario creado en el paso anterior con el nuevo, y detectará aquellas definiciones que ya no se encuentren en el código. Al igual que al generar DRCs, existe un botón para ir liberando uno a uno cada DRC mediante el botón '''''Liberar''''' o bien liberarlas todas automáticamente, sin tener que seleccionar ninguna, con el botón '''''Liberar todas''''':

<center>
{|
|align="center" |[[Imagen:Liberar_drc.jpg|thumb|250px|Eliminamos la definición de tipo '''''Expediente''''', así como todo aquello relacionado con dicha definición (colección, ubicación y permisos)]]
|}
</center>

:*La tercera posibilidad que nos podemos encontrar es la asignación de un DRC, correspondiente a una definición que vamos a eliminar, a una definición nueva que vamos a generar. En este caso debemos tener en cuenta las posibilidades que se nos pueden presentar, pues pueden ser varias.Normalmente, esta operación se suele realizar al cambiar el nombre de alguna definición, de forma que nos puede interesar asignar el DRC de la definición anterior a la nueva definición para que los valores generados anteriormente al cambio de nombre se mantengan en la nueva definición.Otra posibilidad es, por ejemplo, cambiar el tipo de un campo. En este caso, se podrá asignar el DRC del campo previo al nuevo campo, pero las consecuencias de dicho cambio tendrá que valorarlas el programador, pues puede no conseguirse el efecto deseado.Un nuevo caso, en el que vamos a basar nuestro ejemplo, puede ser el cambio de nombre de un formulario, junto con el cambio de nombre de un campo incluído en dicho formulario. En cuanto a los formularios hay que tener en cuenta que deben tener el mismo número de campos, además, los campos deben tener el mismo nombre. Vayamos viendo los pasos a realizar uno a uno, de manera que los vayamos comentando:

<center>
{|
|align="center" |[[Imagen:Asignar_drc.jpg|thumb|250px|Relación de las definiciones a liberar o a generar]]
|}
</center>

:Vemos que el compilador ha detectado definiciones que, o bien pueden ser liberadas, o bien pueden ser generadas. Pero nuestra intención es asignar el DRC del formulario '''''Datos generales''''' al formulario '''''Datos generales del cliente'''''. Además, ha detectado que el campo '''''DNI''''' ha cambiado de nombre, detectando un nuevo campo denominado '''''NIF''''' así como el cambio de nombre de la columna '''''DNI''''' de la colección '''''Clientes''''' por '''''NIF''''':

<center>
{|
|align="center" |[[Imagen:Asignar_drc1.jpg|thumb|250px|Primero seleccionamos la definición del DRC que vamos a asignar]]
|align="center" |[[Imagen:Asignar_drc2.jpg|thumb|250px|Seleccionamos la definición nueva, indicando que el DRC será asignado a esa definición]]
|align="center" |[[Imagen:Asignar_drc3.jpg|thumb|250px|Y generamos la asignación con el botón '''''Asignar''''']]
|}
</center>

:Ya tenemos realizada la asignación de la columna que ha cambiado de nombre en la colección '''''Clientes'''''. Ahora vamos a asignar el formulario, y para ello, hay que tener en cuenta que un campo ha cambiado de nombre, y por tanto deberemos asignar dicho DRC antes de hacerlo con el formulario:

<center>
{|
|align="center" |[[Imagen:Asignar_drc4.jpg|thumb|250px|Seleccionamos el campo que contiene el DRC]]
|align="center" |[[Imagen:Asignar_drc5.jpg|thumb|250px|Seleccionamos el campo nuevo]]
|align="center" |[[Imagen:Asignar_drc6.jpg|thumb|250px|Y generamos la asignación, al igual que en el caso anterior]]
|}
</center>

:Una vez tratado el campo que ha cambiado de nombre, ya no hay restricciones para asignar el DRC del formulario '''''Datos generales''''' al formulario '''''Datos generales del cliente''''':

<center>
{|
|align="center" |[[Imagen:Asignar_drc7.jpg|thumb|250px|Seleccionamos el formulario que contiene el DRC]]
|align="center" |[[Imagen:Asignar_drc8.jpg|thumb|250px|Seleccionamos el formulario nuevo]]
|align="center" |[[Imagen:Asignar_drc9.jpg|thumb|250px|Y realizamos la asignación]]
|}
</center>

:'''¿Y qué pasa si introduzco, elimino o modifico un atributo en alguna definición?''' Los atributos no tienen asignado un DRC, por lo que cualquier edición que hagamos sobre ellos, el compilador no detectará posibles modificaciones en los DRC del sistema.

==Crear un fichero de proyecto (.npc)==
Como ya hemos comentado en este artículo, a la hora de compilar un proyecto en ODL es necesario especificar el fichero

.npc en el egCompiler.
Este fichero deberá ser creado manualmente por el desarrollador y por ello vamos a explicar a continuación la información

que debe almacenar, la estructura que tiene que adoptar y las funciones para las cuales está destinado este fichero.
Cuando instalamos un centro, la estructura de directorios que tendrá el centro una vez instalado está predefinido en un

modelo por defecto llamado ('''Default'''), que tiene la siguiente estructura:

<center>
{|
|align="center" |[[Imagen:estructura_default.jpg|thumb|250px|Compilación mediante la consola del sistema]]
|}
</center>

En nuestro directorio de desarrollo, crearemos aquellas carpetas (que existan en el modelo '''Default''') que vayamos a

modificar. Por ejemplo, si nuestro centro tiene escritos, tendremos que crear una carpeta llamada '''Template documents'''

donde almacenaremos los ficheros .rtf de nuestro centro.

Una vez creado el modelo de centro, lo instalaremos mediante el egAdmin. Éste, comparará el modelo '''Default''' con

nuestro modelo de centro, de manera que las carpetas que se encuentren en ambos modelos, serán fusionadas. Es decir, que por

ejemplo, la carpeta '''Template documents''' donde hemos añadido los ficheros rtf, aparecerá con los ficheros rtf en el

directorio de explotación del centro (y no vacío como aparece en el modelo Default).

Pero, ¿y cómo interviene el fichero .npc en todo este proceso de compilación e instalación de un centro?

El fichero .npc tiene varias funciones en todo este proceso.

Por un lado, informará al compilador de las definiciones que serán compiladas y de las cuales saldrá el diccionario

resultante. Por otro lado, informará al compilador de aquellas carpetas que se han creado en el directorio de desarrollo y

que se quieren incluir en el modelo de centro para su posterior instalación. Por ello, es un fichero fundamental para la

compilación de nuestro centro.

La estructura de un fichero .npc debe ser la siguiente:

<center>
{|
|align="center" |[[Imagen:estructura_npc.jpg|thumb|250px|Compilación mediante la consola del sistema]]
|}
</center>

Las palabras enmarcadas en verde son palabras clave que deben ir en el fichero.
Para el caso de la cabecera, añadiremos un campo donde añadiremos un nombre.
En todos los centros, es necesario crear al menos un fichero de constantes básicas. Este fichero .nc deberá ir

especificado en la palabra clave '''Constantes'''. En caso de existir más de un fichero, se especificarán uno debajo de

otro.
En caso de querer especificar una carpeta de plantillas de escritos, plantillas de impresión o plantillas de vistas, lo

haremos en las palabras clave '''Plantillas_documentos''' para la carpeta [Template documents],

'''Plantillas_visualizacion''' para la carpeta [Template views] o '''Plantillas_impresion''' para la carpeta [Template

prints].
Hay que tener en cuenta que el directorio de las carpetas se especifica a partir del directorio donde esté alojado el

fichero .npc. Si la carpeta [Template documents] está en la misma carpeta que el fichero .npc, no habrá que añadir ninguna

ruta.
Por último, tendremos que especificar las definiciones para generar el diccionario. Esto lo haremos bajo la palabra clave

'''Definiciones'''. Para ello, indicaremos el nombre de la unidad de cada fichero .ndf con el directorio donde se encuentra

el fichero .ndf, tal y como hemos podido ver en la imagen anterior.

==Crear un fichero de constantes (.nc)==
Otro tipo de fichero que tiene que ser creado por el desarrollador son los ficheros de constantes (.nc). Estos ficheros especifican las constantes que se utilizan en un centro.
Existen ciertas constantes básicas que deben ser incluidas en un fichero que tiene que llamarse '''CBasicas.nc'''. Estas constantes básicas, coinciden en etiqueta con algunas palabras reservadas del propio lenguaje ODL. Esto es así porque en el proceso de compilación, las definiciones se crearán en función de los valores de las constantes y no de sus etiquetas.
Por ejemplo, en el conjunto de estas constantes básicas, existe una cuya etiqueta es '''ENTERO''', que tiene valor '''1'''. Cuando en nuestro código ODL definimos un campo entero, en el proceso de compilación la definición del campo será creada con el valor de la constante y no de la etiqueta. A continuación, cuando ejecutemos la aplicación egExplorer, que cargará el diccionario generado por el compilador, leerá que existe una definición de campo con valor 1, que interpretará como un campo entero.
Para que este comportamiento se lleve a cabo, debe existir una referencia en el fichero .npc al fichero .nc de constantes básicas. Esto es debido a que el parámetro que se le pasa al compilador es el fichero .npc de nuestro proyecto.
Aparte de las constante básicas, es posible que el desarrollador quiera declarar nuevas constantes. Esto podrá hacerlo en el mismo fichero '''CBasicas.nc''' o crear otros ficheros .nc para agrupar estas constantes. En caso de crear nuevos ficheros .nc, debemos incluirlos siempre en el fichero .npc.
A continuación, mostramos todas aquellas constantes básicas que son necesarias en cualquier centro:

<center>
{|
|align="center" |[[Imagen:constantes_basicas.jpg|border|250px]]
|}
</center>

Para incluir nuevas constantes en el fichero, simplemente hay que seguir el formato visto en la imagen, pudiendo declararlas en cualquier parte del fichero. Únicamente habrá que tener cuidado de modificar las constantes básicas o declarar nuevas constantes con etiquetas ya utilizadas.

==¿Actualizamos el diccionario, el modelo o el centro?==
Cuando realizamos modificaciones en algunos de los elementos que constituyen el modelo de un sistema de información, es necesario utilizar la aplicación '''egAdmin''' para actualizar los cambios que hemos realizado y que se reflejen en la herramienta '''egExplorer'''. En función de los cambios realizados, será necesario actualizar el diccionario, el modelo o el centro.Por tanto:
:*'''¿Cuándo debo actualizar sólo el diccionario?'''Actualizaremos el diccionario cuando modifiquemos una definición de tipo o creemos una definición de tipo nueva en los ficheros .ndf que se encuentran en el directorio '''''#Source'''''

<center>
{|
|align="center" |[[Imagen:actualizardiccionario.jpg|thumb|250px|Actualizar diccionario en egAdmin]]
|}
</center>

:*'''¿Cuándo debo actualizar sólo el modelo?'''Si cambiamos o agregamos algún fichero .rtf (plantillas), .nmt (métodos), .csv (representación de datos), scripts SQL, etc. Es decir, todo aquello que no sea un fichero .ndf.

<center>
{|
|align="center" |[[Imagen:actualizarmodelo.jpg|thumb|250px|Actualizar modelo en egAdmin]]
|}
</center>

:*'''¿Cuándo debo actualizar el diccionario y el centro?'''Actualizaremos el diccionario y el centro cuando incluyamos nuevas definiciones de sistema. Además, cuando creamos tablas nuevas en la base de datos (por ejemplo, nuevas colecciones) o cualquier cambio que afecte a la base de datos. Este caso tiene una particularidad, y es que al tener que actualizar el centro, deberemos pararlo previamente, y una vez actualizado, arrancarlo nuevamente.

<center>
{|
|align="center" |[[Imagen:actualizarmodelo.jpg|thumb|250px|Actualizamos primero el modelo]]
|align="center" |[[Imagen:pararcentro.jpg|thumb|250px|A continuación paramos el centro en el botón '''''Parar''''']]
|align="center" |[[Imagen:actualizarcentro.jpg|thumb|250px|Lo actualizamos y arrancamos en el botón '''''Arrancar''''']]
|}
</center>

:*'''¿Cuándo debo actualizar el diccionario y reiniciar el centro?'''Cuando cambiamos el nombre a la definición de una tarea o definimos una nueva en nuestro código ODL, evidentemente tendremos que actualizar el diccionario. Pero a diferencia del primer caso, en el que sólo tenemos que actualizar el diccionario, en este caso también es necesario parar el centro y volver a arrancarlo (reiniciarlo), pero sin actualizarlo.

[[Categoría:Tutoriales]]

Desarrollar con el STE

2009-08-04T08:21:17Z

Imhernandez: /* Estado de un trámite */

__TOC__
=¿Que es un trámite?=
Un trámite es la definición del conjunto de tareas, pertenecientes al ''workflow'', que van a interactuar con la aplicación web STE. Los trámites definidos están orientados a ser iniciados por el usuario desde la aplicación web, para que, a continuación, se inicie un proceso de ''workflow'' programado en ODL para la plataforma egeasy.
==Como se define un trámite==
Para definir un trámite tenemos que indicar el nombre del trámite y declararlo como tipo trámite. La sintaxis de un trámite sería la siguiente.

[Nombre del trámite] es tramite
-ATRIBUTOS
incluye TAREA
.
.
.
incluye TAREA
fin
==Atributos de un trámite==
Los atributos que podemos declarar para un trámite son los siguientes:
*'''descripcion''': Proporciona un texto descriptivo sobre el trámite que se muestra en la interfaz web al crear el trámite.
*'''grupo''': Indica a qué grupo de declaraciones pertenece el trámite.
*'''habitacion''': Indica en qué habitación de nuestro sistema de información queremos que esté disponible el trámite para su realización.
*'''estado''': Indica qué tabla y columna de una exportación va a almacenar el estado de un trámite.

==La clausula incluye==
Dentro de la definición del trámite, debemos especificar cuáles son las tareas del ''wordflow'' que queremos que interactúen con el STE. Para ello, disponemos de la cláusula '''incluye'''. Al utilizarla, debemos especificar, a continuación, el nombre de la tarea e indicar una serie de atributos que especifican varios aspectos del comportamiento de la tarea.

===Atributos de incluye===
Los atributos aplicables a las tareas que incluimos en un trámite pueden variar dependiendo del valor del atributo ''tipo'', por ejemplo, los atributos de respuesta sólo son aplicables a las tareas con el valor en el atributo tipo igual a REQUERIMIENTO. Dicho esto, pasamos a listar los distintos atributos aplicables a la clausula incluye:

*'''Etiqueta''': Atributo que permite establecer el nombre que va a tener la tarea en la aplicación web del STE.

*'''Tipo''': Atributo que indica qué tipo de comportamiento va a tener la tarea. Los distintos valores que acepta este atributo son: INICIO, REQUERIMIENTO, NOTIFICACION y ENVIO_DOCUMENTACION.

*'''respuesta.etiqueta''': Atributo que indica qué nombre va a tener la tarea respuesta correspondiente

*'''respuesta.descripcion''': Atributo para indicar una descripción sobre la tarea respuesta.

*'''respuesta.formulario''': Atributo para indicar el nombre del formulario, perteneciente al ''target'' de la tarea de tipo REQUERIMIENTO, que se va a mostrar en la tarea de respuesta.

*'''respuesta.clasificador''': Atributo para indicar el nombre del clasificador, perteneciente al ''target'' de la tarea de tipo REQUERIMIENTO, donde se van a guardar los documentos que se pueden adjuntar a una tarea respuesta, perteneciente a una tarea de tipo REQUERIMIENTO.

===Diferentes tipos de tareas===
En la aplicación web STE, una misma tarea de nuestro sistema de información se puede comportar de diferentes maneras, dependiendo de qué valor tenga el atributo ''tipo'' al incluirla en un trámite.

'''Tareas de INICIO'''
Es la tarea que va a iniciar el trámite. En un trámite solo puede haber una tarea de tipo inicio. Esta tarea debe ser definida íntegramente como un proceso en ODL.

incluye [Tramitación de solicitud de becas]
-{{AT|Tipo}}=INICIO;
-{{AT|Etiqueta}}='Tramitación de solicitud de becas universitarias';

'''Tareas de REQUERIMIENTO'''
Son aquellas tareas donde, además de mostrar información, queremos dar al usuario la posibilidad de responder a la tarea mostrada rellenando un formulario o adjuntando alguna documentación requerida.

incluye [Esperar respuesta de requerimiento de documentación]
-{{AT|Tipo}}=REQUERIMIENTO;
-{{AT|Etiqueta}}='Respuesta al requerimiento de solicitud de becas universitarias';
-{{AT|respuesta.etiqueta}} = {{STR|"Responder al requerimiento"}};
-{{AT|respuesta.descripcion}} = {{STR|"Adjunte todo lo solicitado en el documento enviado"}};
-{{AT|respuesta.formulario}} = [Respuesta];
-{{AT|respuesta.clasificador}} = [Documentos adjuntos];

'''Tareas de NOTIFICACION'''
Son aquellas tareas donde sólo se le va a permitir al usuario del STE observar la información que ha sido mandada desde la plataforma egeasy. No podrá ni enviar información, ni modificar la información mandada. Este tipo de tarea suele estar reservado para aquellos datos que son de notificación, como las resoluciones.

incluye [Notificar resolución de la solicitud de beca universitaria]
-{{AT|Tipo}}=NOTIFICACION;
-{{AT|Etiqueta}}='Darse por notificado de la resolución de la solicitud de beca universitaria';

'''Tareas de ENVIO_DOCUMENTACION'''
Son aquellas tareas fuera del ''workflow'' que permiten al usuario de la aplicación web STE enviar documentación. Este tipo de tarea se puede iniciar en cualquier momento durante la vida del trámite.

incluye [Registrar aporte de documentación al trámite]
-{{AT|Tipo}}=ENVIO_DOCUMENTACION;
-{{AT|Etiqueta}}='Aportar documentación adicional al trámite';

=Colecciones=
Para el desarrollo correcto de los trámites en la aplicación web STE, debemos crear al menos una colección para almacenar los contenedores que se crean al iniciar un trámite. Al definir un trámite su ''main target'' tiene que ser el contenedor que se mostrará en la web para que el usuario introduzca los datos iniciales para comenzar el ''workflow'', y no un expediente como se suele hacer cuando programamos un sistema de información en egeasy, de ahí la necesidad de crearnos una colección. (Véase [[Colecciones]]) Posteriormente se moverán esos contenedores creados a su lugar dentro de alguna colección dentro de un expediente.

=Estado de un trámite=
Los trámites en la aplicación web STE tienen estado. El estado de un trámite acabado de iniciar, pero no enviado, tiene el valor de ''borrador''. Una vez enviado a su primera tarea del trámite, éste pasa a tener el valor de ''En trámite''. Por último, cuando el trámite ha finalizado en la plataforma egeasy, pasa a tener el estado de ''finalizado''. Estos valores comentados para el estado de un trámite definen el comportamiento por defecto de la aplicación web STE. Si queremos cambiar el estado de un trámite debemos hacerlo mediante el atributo '''estado''' y su mecanismo para controlarlo, el cual vamos a proceder a explicar a continuación.

Para poder modificar el estado de un trámite durante la vida del ''workflow'' asociado al mismo, debemos crearnos un campo en el contenedor que es ''maintarget'' del ''workflow''. Una vez creado ese campo, debemos exportarlo a alguna colección de nuestra elección. Si hay alguna duda sobre como crear una exportación, véase [[Exportaciones]]. Con la exportación del campo creada, debemos poner en el atributo '''estado''' del trámite, una ristra con el nombre de la tabla en la base de datos seguida de un punto y a continuación el nombre de la columna que representa el campo en la exportación. Para que quede mas claro, vamos a ver un ejemplo:

Esto sería un ejemplo de la exportación creada, donde tenemos un campo en ODL llamado [Estado tramite], el cual se exporta a la tabla de nombre TR$SOLICITUD_TRAMITACION y en la columna ESTADO_TRAMITE.

[EP::Solicitudes de tramitación electrónica] {{PR|es}} exportacion
-{{AT|nombre_tabla}} = {{STR|"TR$SOLICITUD_TRAMITACION"}};
-{{AT|universo}} = [Solicitud de tramitación electrónica para acreditación del profesorado];
{{PR|columna}} [Denominación/Apellidos y nombre]
-{{AT|columna_bd.nombre}} = {{STR|"DENOMINACION"}};
-{{AT|columna_bd}}.{{PR|tipo}} = texto;
-{{AT|origen}} =[Datos generales].[Denominación/Apellidos y nombre];
{{PR|columna}} [C.I.F./N.I.F.]
-{{AT|columna_bd.nombre}} = {{STR|"CIF_NIF"}};
-{{AT|columna_bd}}.{{PR|tipo}} = texto;
-{{AT|origen}} = [Datos generales].[C.I.F./N.I.F.];
{{PR|columna}} [Estado tramite]
-{{AT|columna_bd.nombre}} = {{STR|"ESTADO_TRAMITE"}};
-{{AT|columna_bd}}.{{PR|tipo}} = texto;
-{{AT|origen}} = [Datos generales].[Estado tramite];
{{PR|fin}}

A continuación, un ejemplo de como se declararía un trámite utilizando el atributo '''estado'''.

[Trámite de Acreditación del profesorado] {{PR|es}} tramite
-{{AT|descripcion}}='Procedimiento de tramitación para la aceditación del profesorado para la ACECAU';
-{{AT|grupo}}='Trámites Acecau';
-{{AT|Habitacion}}=[Oficina de evaluación del profesorado];
-{{AT|estado}}={{STR|"TR$SOLTRAMI_ACRE_PROF.ESTADO_TRAMITE"}};

Una vez declarado el atributo estado en el trámite, ya podemos proceder a modificarlo mediante código de método del lenguaje ODL. Para ello, sólo debemos acceder, mediante código ODL, al campo que representa el estado y asignarle el valor deseado que queremos que se muestre en la aplicación web del STE.

metodo ejemplo()
var Contenedor1 : contenedor;
inicio
...
Contenedor1.[Estado] = "En trámite";
...
fin

=Atributos especiales para los campos de ODL=
En la aplicación web STE disponemos, para el lenguaje ODL, de unos atributos especiales aplicables a la definición de componentes para poder definir ciertos aspectos de su comportamiento al interactuar con la aplicación web STE. A continuación, listaremos y definiremos los atributos que ha añadido el STE al lenguage ODL.

'''tramitacion.visible'''

Atributo que permite ocultar un campo para que no se visualice en la aplicación web del STE, pero sí en la plataforma egeasy. Este atributo es aplicable a todos los campos de ODL. El valor por defecto para este atributo es verdadero.

'''tramitacion.requerida'''

Atributo que permite especificar qué campos son de obligada cumplimentación por parte del usuario. El valor por defecto es falso. Este atributo se puede usar en combinación con las validaciones de ODL para indicar cómo se debe cumplimentar un campo.

'''tramitacion.valor'''

Atributo que permite establecer el valor del campo al que se le aplica el atributo.

'''tramitacion.editable'''

Atributo que permite indicar si el campo es editable o no. El valor por defecto es verdadero.


=Formulario de registro de usuarios=
En la aplicación web STE, podemos crear a nuestra medida un formulario de registro de usuarios, pudiendo definir los campos que queremos que el usuario cumplimente al darse de alta en la aplicación web STE. El fichero donde se definen los campos del registro es un fichero XML y se llama '''registration.xml'''.

A continuación mostramos un ejemplo de un fichero de registro.
<?xml version="1.0" encoding="ISO-8859-1"?>
<registration_form>
<field_value Field_Name="Género" Field_Type="ftString">
<allowed_values>
<item>Masculino</item>
<item>Femenino</item>
</allowed_values>
</field_value>
<field_value Field_Name="Teléfono 1" Field_Type="ftString">
</field_value>
<field_value Field_Name="Teléfono 2" Field_Type="ftString">
</field_value>
<field_value Field_Name="Dirección" Field_Type="ftString">
</field_value>
<field_value Field_Name="Código postal" Field_Type="ftString">
</field_value>
<field_value Field_Name="Localidad" Field_Type="ftString">
</field_value>
<field_value Field_Name="Provincia" Field_Type="ftString">
</field_value>
<field_value Field_Name="Fax" Field_Type="ftString">
</field_value>
</registration_form>

[[Category:Tramitación electrónica]]

Desarrollar con el STE

2009-08-04T08:20:14Z

Imhernandez: /* Estado de un trámite */

__TOC__
=¿Que es un trámite?=
Un trámite es la definición del conjunto de tareas, pertenecientes al ''workflow'', que van a interactuar con la aplicación web STE. Los trámites definidos están orientados a ser iniciados por el usuario desde la aplicación web, para que, a continuación, se inicie un proceso de ''workflow'' programado en ODL para la plataforma egeasy.
==Como se define un trámite==
Para definir un trámite tenemos que indicar el nombre del trámite y declararlo como tipo trámite. La sintaxis de un trámite sería la siguiente.

[Nombre del trámite] es tramite
-ATRIBUTOS
incluye TAREA
.
.
.
incluye TAREA
fin
==Atributos de un trámite==
Los atributos que podemos declarar para un trámite son los siguientes:
*'''descripcion''': Proporciona un texto descriptivo sobre el trámite que se muestra en la interfaz web al crear el trámite.
*'''grupo''': Indica a qué grupo de declaraciones pertenece el trámite.
*'''habitacion''': Indica en qué habitación de nuestro sistema de información queremos que esté disponible el trámite para su realización.
*'''estado''': Indica qué tabla y columna de una exportación va a almacenar el estado de un trámite.

==La clausula incluye==
Dentro de la definición del trámite, debemos especificar cuáles son las tareas del ''wordflow'' que queremos que interactúen con el STE. Para ello, disponemos de la cláusula '''incluye'''. Al utilizarla, debemos especificar, a continuación, el nombre de la tarea e indicar una serie de atributos que especifican varios aspectos del comportamiento de la tarea.

===Atributos de incluye===
Los atributos aplicables a las tareas que incluimos en un trámite pueden variar dependiendo del valor del atributo ''tipo'', por ejemplo, los atributos de respuesta sólo son aplicables a las tareas con el valor en el atributo tipo igual a REQUERIMIENTO. Dicho esto, pasamos a listar los distintos atributos aplicables a la clausula incluye:

*'''Etiqueta''': Atributo que permite establecer el nombre que va a tener la tarea en la aplicación web del STE.

*'''Tipo''': Atributo que indica qué tipo de comportamiento va a tener la tarea. Los distintos valores que acepta este atributo son: INICIO, REQUERIMIENTO, NOTIFICACION y ENVIO_DOCUMENTACION.

*'''respuesta.etiqueta''': Atributo que indica qué nombre va a tener la tarea respuesta correspondiente

*'''respuesta.descripcion''': Atributo para indicar una descripción sobre la tarea respuesta.

*'''respuesta.formulario''': Atributo para indicar el nombre del formulario, perteneciente al ''target'' de la tarea de tipo REQUERIMIENTO, que se va a mostrar en la tarea de respuesta.

*'''respuesta.clasificador''': Atributo para indicar el nombre del clasificador, perteneciente al ''target'' de la tarea de tipo REQUERIMIENTO, donde se van a guardar los documentos que se pueden adjuntar a una tarea respuesta, perteneciente a una tarea de tipo REQUERIMIENTO.

===Diferentes tipos de tareas===
En la aplicación web STE, una misma tarea de nuestro sistema de información se puede comportar de diferentes maneras, dependiendo de qué valor tenga el atributo ''tipo'' al incluirla en un trámite.

'''Tareas de INICIO'''
Es la tarea que va a iniciar el trámite. En un trámite solo puede haber una tarea de tipo inicio. Esta tarea debe ser definida íntegramente como un proceso en ODL.

incluye [Tramitación de solicitud de becas]
-{{AT|Tipo}}=INICIO;
-{{AT|Etiqueta}}='Tramitación de solicitud de becas universitarias';

'''Tareas de REQUERIMIENTO'''
Son aquellas tareas donde, además de mostrar información, queremos dar al usuario la posibilidad de responder a la tarea mostrada rellenando un formulario o adjuntando alguna documentación requerida.

incluye [Esperar respuesta de requerimiento de documentación]
-{{AT|Tipo}}=REQUERIMIENTO;
-{{AT|Etiqueta}}='Respuesta al requerimiento de solicitud de becas universitarias';
-{{AT|respuesta.etiqueta}} = {{STR|"Responder al requerimiento"}};
-{{AT|respuesta.descripcion}} = {{STR|"Adjunte todo lo solicitado en el documento enviado"}};
-{{AT|respuesta.formulario}} = [Respuesta];
-{{AT|respuesta.clasificador}} = [Documentos adjuntos];

'''Tareas de NOTIFICACION'''
Son aquellas tareas donde sólo se le va a permitir al usuario del STE observar la información que ha sido mandada desde la plataforma egeasy. No podrá ni enviar información, ni modificar la información mandada. Este tipo de tarea suele estar reservado para aquellos datos que son de notificación, como las resoluciones.

incluye [Notificar resolución de la solicitud de beca universitaria]
-{{AT|Tipo}}=NOTIFICACION;
-{{AT|Etiqueta}}='Darse por notificado de la resolución de la solicitud de beca universitaria';

'''Tareas de ENVIO_DOCUMENTACION'''
Son aquellas tareas fuera del ''workflow'' que permiten al usuario de la aplicación web STE enviar documentación. Este tipo de tarea se puede iniciar en cualquier momento durante la vida del trámite.

incluye [Registrar aporte de documentación al trámite]
-{{AT|Tipo}}=ENVIO_DOCUMENTACION;
-{{AT|Etiqueta}}='Aportar documentación adicional al trámite';

=Colecciones=
Para el desarrollo correcto de los trámites en la aplicación web STE, debemos crear al menos una colección para almacenar los contenedores que se crean al iniciar un trámite. Al definir un trámite su ''main target'' tiene que ser el contenedor que se mostrará en la web para que el usuario introduzca los datos iniciales para comenzar el ''workflow'', y no un expediente como se suele hacer cuando programamos un sistema de información en egeasy, de ahí la necesidad de crearnos una colección. (Véase [[Colecciones]]) Posteriormente se moverán esos contenedores creados a su lugar dentro de alguna colección dentro de un expediente.

=Estado de un trámite=
Los trámites en la aplicación web STE tienen estado. El estado de un trámite acabado de iniciar, pero no enviado, tiene el valor de ''borrador''. Una vez enviado a su primera tarea del trámite, éste pasa a tener el valor de ''En trámite''. Por último, cuando el trámite ha finalizado en la plataforma egeasy, pasa a tener el estado de ''finalizado''. Estos valores comentados para el estado de un trámite definen el comportamiento por defecto de la aplicación web STE. Si queremos cambiar el estado de un trámite debemos hacerlo mediante el atributo '''estado''' y su mecanismo para controlarlo, el cual vamos a proceder a explicar a continuación.

Para poder modificar el estado de un trámite durante la vida del ''workflow'' asociado al mismo, debemos crearnos un campo en el contenedor que es ''maintarget'' del ''workflow''. Una vez creado ese campo, debemos exportarlo a alguna colección de nuestra elección. Si hay alguna duda sobre como crear una exportación, véase [[Exportaciones]]. Con la exportación del campo creada, debemos poner en el atributo '''estado''' del trámite, una ristra con el nombre de la tabla en la base de datos seguida de un punto y a continuación el nombre de la columna que representa el campo en la exportación. Para que quede mas claro, vamos a ver un ejemplo:

Esto sería un ejemplo de la exportación creada, donde tenemos un campo en ODL llamado [Estado tramite], el cual se exporta a la tabla de nombre TR$SOLICITUD_TRAMITACION y en la columna ESTADO_TRAMITE.

[EP::Solicitudes de tramitación electrónica] {{PR|es}} exportacion
-{{AT|nombre_tabla}} = {{STR|"TR$SOLICITUD_TRAMITACION"}};
-{{AT|universo}} = [Solicitud de tramitación electrónica para acreditación del profesorado];
{{PR|columna}} [Denominación/Apellidos y nombre]
-{{AT|columna_bd.nombre}} = {{STR|"DENOMINACION"}};
-{{AT|columna_bd}}.{{PR|tipo}} = texto;
-{{AT|origen}} =[Datos generales].[Denominación/Apellidos y nombre];
{{PR|columna}} [C.I.F./N.I.F.]
-{{AT|columna_bd.nombre}} = {{STR|"CIF_NIF"}};
-{{AT|columna_bd}}.{{PR|tipo}} = texto;
-{{AT|origen}} = [Datos generales].[C.I.F./N.I.F.];
{{PR|columna}} [Estado tramite]
-{{AT|columna_bd.nombre}} = {{STR|"ESTADO_TRAMITE"}};
-{{AT|columna_bd}}.{{PR|tipo}} = texto;
-{{AT|origen}} = [Datos generales].[Estado tramite];
{{PR|fin}}

A continuación, un ejemplo de como se declararía un trámite utilizando el atributo '''estado'''.

[Trámite de Acreditación del profesorado] {{PR|es}} tramite
-{{AT|descripcion}}='Procedimiento de tramitación para la aceditación del profesorado para la ACECAU';
-{{AT|grupo}}='Trámites Acecau';
-{{AT|Habitacion}}=[Oficina de evaluación del profesorado];
-{{AT|estado}}={{STR|"TR$SOLTRAMI_ACRE_PROF.ESTADO_TRAMITE"}};

Una vez declarado el atributo estado en el trámite, ya podemos proceder a modificarlo mediante código de método del lenguaje ODL. Para ello, sólo debemos acceder, mediante código ODL, al campo que representa el estado y asignarle el valor deseado que queremos que se muestre en la aplicación web del STE.

metodo ejemplo()
var Contenedor1 : contenedor;
inicio
...
Contenedor1.[Estado] = "trámite";

=Atributos especiales para los campos de ODL=
En la aplicación web STE disponemos, para el lenguaje ODL, de unos atributos especiales aplicables a la definición de componentes para poder definir ciertos aspectos de su comportamiento al interactuar con la aplicación web STE. A continuación, listaremos y definiremos los atributos que ha añadido el STE al lenguage ODL.

'''tramitacion.visible'''

Atributo que permite ocultar un campo para que no se visualice en la aplicación web del STE, pero sí en la plataforma egeasy. Este atributo es aplicable a todos los campos de ODL. El valor por defecto para este atributo es verdadero.

'''tramitacion.requerida'''

Atributo que permite especificar qué campos son de obligada cumplimentación por parte del usuario. El valor por defecto es falso. Este atributo se puede usar en combinación con las validaciones de ODL para indicar cómo se debe cumplimentar un campo.

'''tramitacion.valor'''

Atributo que permite establecer el valor del campo al que se le aplica el atributo.

'''tramitacion.editable'''

Atributo que permite indicar si el campo es editable o no. El valor por defecto es verdadero.


=Formulario de registro de usuarios=
En la aplicación web STE, podemos crear a nuestra medida un formulario de registro de usuarios, pudiendo definir los campos que queremos que el usuario cumplimente al darse de alta en la aplicación web STE. El fichero donde se definen los campos del registro es un fichero XML y se llama '''registration.xml'''.

A continuación mostramos un ejemplo de un fichero de registro.
<?xml version="1.0" encoding="ISO-8859-1"?>
<registration_form>
<field_value Field_Name="Género" Field_Type="ftString">
<allowed_values>
<item>Masculino</item>
<item>Femenino</item>
</allowed_values>
</field_value>
<field_value Field_Name="Teléfono 1" Field_Type="ftString">
</field_value>
<field_value Field_Name="Teléfono 2" Field_Type="ftString">
</field_value>
<field_value Field_Name="Dirección" Field_Type="ftString">
</field_value>
<field_value Field_Name="Código postal" Field_Type="ftString">
</field_value>
<field_value Field_Name="Localidad" Field_Type="ftString">
</field_value>
<field_value Field_Name="Provincia" Field_Type="ftString">
</field_value>
<field_value Field_Name="Fax" Field_Type="ftString">
</field_value>
</registration_form>

[[Category:Tramitación electrónica]]

Desarrollar con el STE

2009-08-04T08:11:24Z

Imhernandez: /* Formulario de registro de usuarios */

__TOC__
=¿Que es un trámite?=
Un trámite es la definición del conjunto de tareas, pertenecientes al ''workflow'', que van a interactuar con la aplicación web STE. Los trámites definidos están orientados a ser iniciados por el usuario desde la aplicación web, para que, a continuación, se inicie un proceso de ''workflow'' programado en ODL para la plataforma egeasy.
==Como se define un trámite==
Para definir un trámite tenemos que indicar el nombre del trámite y declararlo como tipo trámite. La sintaxis de un trámite sería la siguiente.

[Nombre del trámite] es tramite
-ATRIBUTOS
incluye TAREA
.
.
.
incluye TAREA
fin
==Atributos de un trámite==
Los atributos que podemos declarar para un trámite son los siguientes:
*'''descripcion''': Proporciona un texto descriptivo sobre el trámite que se muestra en la interfaz web al crear el trámite.
*'''grupo''': Indica a qué grupo de declaraciones pertenece el trámite.
*'''habitacion''': Indica en qué habitación de nuestro sistema de información queremos que esté disponible el trámite para su realización.
*'''estado''': Indica qué tabla y columna de una exportación va a almacenar el estado de un trámite.

==La clausula incluye==
Dentro de la definición del trámite, debemos especificar cuáles son las tareas del ''wordflow'' que queremos que interactúen con el STE. Para ello, disponemos de la cláusula '''incluye'''. Al utilizarla, debemos especificar, a continuación, el nombre de la tarea e indicar una serie de atributos que especifican varios aspectos del comportamiento de la tarea.

===Atributos de incluye===
Los atributos aplicables a las tareas que incluimos en un trámite pueden variar dependiendo del valor del atributo ''tipo'', por ejemplo, los atributos de respuesta sólo son aplicables a las tareas con el valor en el atributo tipo igual a REQUERIMIENTO. Dicho esto, pasamos a listar los distintos atributos aplicables a la clausula incluye:

*'''Etiqueta''': Atributo que permite establecer el nombre que va a tener la tarea en la aplicación web del STE.

*'''Tipo''': Atributo que indica qué tipo de comportamiento va a tener la tarea. Los distintos valores que acepta este atributo son: INICIO, REQUERIMIENTO, NOTIFICACION y ENVIO_DOCUMENTACION.

*'''respuesta.etiqueta''': Atributo que indica qué nombre va a tener la tarea respuesta correspondiente

*'''respuesta.descripcion''': Atributo para indicar una descripción sobre la tarea respuesta.

*'''respuesta.formulario''': Atributo para indicar el nombre del formulario, perteneciente al ''target'' de la tarea de tipo REQUERIMIENTO, que se va a mostrar en la tarea de respuesta.

*'''respuesta.clasificador''': Atributo para indicar el nombre del clasificador, perteneciente al ''target'' de la tarea de tipo REQUERIMIENTO, donde se van a guardar los documentos que se pueden adjuntar a una tarea respuesta, perteneciente a una tarea de tipo REQUERIMIENTO.

===Diferentes tipos de tareas===
En la aplicación web STE, una misma tarea de nuestro sistema de información se puede comportar de diferentes maneras, dependiendo de qué valor tenga el atributo ''tipo'' al incluirla en un trámite.

'''Tareas de INICIO'''
Es la tarea que va a iniciar el trámite. En un trámite solo puede haber una tarea de tipo inicio. Esta tarea debe ser definida íntegramente como un proceso en ODL.

incluye [Tramitación de solicitud de becas]
-{{AT|Tipo}}=INICIO;
-{{AT|Etiqueta}}='Tramitación de solicitud de becas universitarias';

'''Tareas de REQUERIMIENTO'''
Son aquellas tareas donde, además de mostrar información, queremos dar al usuario la posibilidad de responder a la tarea mostrada rellenando un formulario o adjuntando alguna documentación requerida.

incluye [Esperar respuesta de requerimiento de documentación]
-{{AT|Tipo}}=REQUERIMIENTO;
-{{AT|Etiqueta}}='Respuesta al requerimiento de solicitud de becas universitarias';
-{{AT|respuesta.etiqueta}} = {{STR|"Responder al requerimiento"}};
-{{AT|respuesta.descripcion}} = {{STR|"Adjunte todo lo solicitado en el documento enviado"}};
-{{AT|respuesta.formulario}} = [Respuesta];
-{{AT|respuesta.clasificador}} = [Documentos adjuntos];

'''Tareas de NOTIFICACION'''
Son aquellas tareas donde sólo se le va a permitir al usuario del STE observar la información que ha sido mandada desde la plataforma egeasy. No podrá ni enviar información, ni modificar la información mandada. Este tipo de tarea suele estar reservado para aquellos datos que son de notificación, como las resoluciones.

incluye [Notificar resolución de la solicitud de beca universitaria]
-{{AT|Tipo}}=NOTIFICACION;
-{{AT|Etiqueta}}='Darse por notificado de la resolución de la solicitud de beca universitaria';

'''Tareas de ENVIO_DOCUMENTACION'''
Son aquellas tareas fuera del ''workflow'' que permiten al usuario de la aplicación web STE enviar documentación. Este tipo de tarea se puede iniciar en cualquier momento durante la vida del trámite.

incluye [Registrar aporte de documentación al trámite]
-{{AT|Tipo}}=ENVIO_DOCUMENTACION;
-{{AT|Etiqueta}}='Aportar documentación adicional al trámite';

=Colecciones=
Para el desarrollo correcto de los trámites en la aplicación web STE, debemos crear al menos una colección para almacenar los contenedores que se crean al iniciar un trámite. Al definir un trámite su ''main target'' tiene que ser el contenedor que se mostrará en la web para que el usuario introduzca los datos iniciales para comenzar el ''workflow'', y no un expediente como se suele hacer cuando programamos un sistema de información en egeasy, de ahí la necesidad de crearnos una colección. (Véase [[Colecciones]]) Posteriormente se moverán esos contenedores creados a su lugar dentro de alguna colección dentro de un expediente.

=Estado de un trámite=
Los trámites en la aplicación web STE tienen estado. El estado de un trámite acabado de iniciar, pero no enviado, tiene el valor de ''borrador''. Una vez enviado a su primera tarea del trámite, éste pasa a tener el valor de ''En trámite''. Por último, cuando el trámite ha finalizado en la plataforma egeasy, pasa a tener el estado de ''finalizado''. Estos valores comentados para el estado de un trámite definen el comportamiento por defecto de la aplicación web STE. Si queremos cambiar el estado de un trámite debemos hacerlo mediante el atributo '''estado''' y su mecanismo para controlarlo, el cual vamos a proceder a explicar a continuación.

Para poder modificar el estado de un trámite durante la vida del ''workflow'' asociado al mismo, debemos crearnos un campo en el contenedor que es ''maintarget'' del ''workflow''. Una vez creado ese campo, debemos exportarlo a alguna colección de nuestra elección. Si hay alguna duda sobre como crear una exportación, véase [[Exportaciones]]. Con la exportación del campo creada, debemos poner en el atributo '''estado''' del trámite, una ristra con el nombre de la tabla en la base de datos seguida de un punto y a continuación el nombre de la columna que representa el campo en la exportación. Para que quede mas claro, vamos a ver un ejemplo:

Esto sería un ejemplo de la exportación creada, donde tenemos un campo en ODL llamado [Estado tramite], el cual se exporta a la tabla de nombre TR$SOLICITUD_TRAMITACION y en la columna ESTADO_TRAMITE.

[EP::Solicitudes de tramitación electrónica] {{PR|es}} exportacion
-{{AT|nombre_tabla}} = {{STR|"TR$SOLICITUD_TRAMITACION"}};
-{{AT|universo}} = [Solicitud de tramitación electrónica para acreditación del profesorado];
{{PR|columna}} [Denominación/Apellidos y nombre]
-{{AT|columna_bd.nombre}} = {{STR|"DENOMINACION"}};
-{{AT|columna_bd}}.{{PR|tipo}} = texto;
-{{AT|origen}} =[Datos generales].[Denominación/Apellidos y nombre];
{{PR|columna}} [C.I.F./N.I.F.]
-{{AT|columna_bd.nombre}} = {{STR|"CIF_NIF"}};
-{{AT|columna_bd}}.{{PR|tipo}} = texto;
-{{AT|origen}} = [Datos generales].[C.I.F./N.I.F.];
{{PR|columna}} [Estado tramite]
-{{AT|columna_bd.nombre}} = {{STR|"ESTADO_TRAMITE"}};
-{{AT|columna_bd}}.{{PR|tipo}} = texto;
-{{AT|origen}} = [Datos generales].[Estado tramite];
{{PR|fin}}

A continuación, un ejemplo de como se declararía un trámite utilizando el atributo '''estado'''.

[Trámite de Acreditación del profesorado] {{PR|es}} tramite
-{{AT|descripcion}}='Procedimiento de tramitación para la aceditación del profesorado para la ACECAU';
-{{AT|grupo}}='Trámites Acecau';
-{{AT|Habitacion}}=[Oficina de evaluación del profesorado];
-{{AT|estado}}={{STR|"TR$SOLTRAMI_ACRE_PROF.ESTADO_TRAMITE"}};

Una vez declarado el atributo estado en el trámite, ya podemos proceder a modificarlo mediante código de método del lenguaje ODL. Para ello, sólo debemos acceder, mediante código ODL, al campo que representa el estado y asignarle el valor deseado que queremos que se muestre en la aplicación web del STE.

NOTA: PONER EJEMPLO DE UN METODO ASIGNADOLE UN VALOR AL CAMPO ESTADO

=Atributos especiales para los campos de ODL=
En la aplicación web STE disponemos, para el lenguaje ODL, de unos atributos especiales aplicables a la definición de componentes para poder definir ciertos aspectos de su comportamiento al interactuar con la aplicación web STE. A continuación, listaremos y definiremos los atributos que ha añadido el STE al lenguage ODL.

'''tramitacion.visible'''

Atributo que permite ocultar un campo para que no se visualice en la aplicación web del STE, pero sí en la plataforma egeasy. Este atributo es aplicable a todos los campos de ODL. El valor por defecto para este atributo es verdadero.

'''tramitacion.requerida'''

Atributo que permite especificar qué campos son de obligada cumplimentación por parte del usuario. El valor por defecto es falso. Este atributo se puede usar en combinación con las validaciones de ODL para indicar cómo se debe cumplimentar un campo.

'''tramitacion.valor'''

Atributo que permite establecer el valor del campo al que se le aplica el atributo.

'''tramitacion.editable'''

Atributo que permite indicar si el campo es editable o no. El valor por defecto es verdadero.


=Formulario de registro de usuarios=
En la aplicación web STE, podemos crear a nuestra medida un formulario de registro de usuarios, pudiendo definir los campos que queremos que el usuario cumplimente al darse de alta en la aplicación web STE. El fichero donde se definen los campos del registro es un fichero XML y se llama '''registration.xml'''.

A continuación mostramos un ejemplo de un fichero de registro.
<?xml version="1.0" encoding="ISO-8859-1"?>
<registration_form>
<field_value Field_Name="Género" Field_Type="ftString">
<allowed_values>
<item>Masculino</item>
<item>Femenino</item>
</allowed_values>
</field_value>
<field_value Field_Name="Teléfono 1" Field_Type="ftString">
</field_value>
<field_value Field_Name="Teléfono 2" Field_Type="ftString">
</field_value>
<field_value Field_Name="Dirección" Field_Type="ftString">
</field_value>
<field_value Field_Name="Código postal" Field_Type="ftString">
</field_value>
<field_value Field_Name="Localidad" Field_Type="ftString">
</field_value>
<field_value Field_Name="Provincia" Field_Type="ftString">
</field_value>
<field_value Field_Name="Fax" Field_Type="ftString">
</field_value>
</registration_form>

[[Category:Tramitación electrónica]]

Desarrollar con el STE

2009-08-04T08:09:28Z

Imhernandez: /* Atributos especiales para los campos de ODL */

__TOC__
=¿Que es un trámite?=
Un trámite es la definición del conjunto de tareas, pertenecientes al ''workflow'', que van a interactuar con la aplicación web STE. Los trámites definidos están orientados a ser iniciados por el usuario desde la aplicación web, para que, a continuación, se inicie un proceso de ''workflow'' programado en ODL para la plataforma egeasy.
==Como se define un trámite==
Para definir un trámite tenemos que indicar el nombre del trámite y declararlo como tipo trámite. La sintaxis de un trámite sería la siguiente.

[Nombre del trámite] es tramite
-ATRIBUTOS
incluye TAREA
.
.
.
incluye TAREA
fin
==Atributos de un trámite==
Los atributos que podemos declarar para un trámite son los siguientes:
*'''descripcion''': Proporciona un texto descriptivo sobre el trámite que se muestra en la interfaz web al crear el trámite.
*'''grupo''': Indica a qué grupo de declaraciones pertenece el trámite.
*'''habitacion''': Indica en qué habitación de nuestro sistema de información queremos que esté disponible el trámite para su realización.
*'''estado''': Indica qué tabla y columna de una exportación va a almacenar el estado de un trámite.

==La clausula incluye==
Dentro de la definición del trámite, debemos especificar cuáles son las tareas del ''wordflow'' que queremos que interactúen con el STE. Para ello, disponemos de la cláusula '''incluye'''. Al utilizarla, debemos especificar, a continuación, el nombre de la tarea e indicar una serie de atributos que especifican varios aspectos del comportamiento de la tarea.

===Atributos de incluye===
Los atributos aplicables a las tareas que incluimos en un trámite pueden variar dependiendo del valor del atributo ''tipo'', por ejemplo, los atributos de respuesta sólo son aplicables a las tareas con el valor en el atributo tipo igual a REQUERIMIENTO. Dicho esto, pasamos a listar los distintos atributos aplicables a la clausula incluye:

*'''Etiqueta''': Atributo que permite establecer el nombre que va a tener la tarea en la aplicación web del STE.

*'''Tipo''': Atributo que indica qué tipo de comportamiento va a tener la tarea. Los distintos valores que acepta este atributo son: INICIO, REQUERIMIENTO, NOTIFICACION y ENVIO_DOCUMENTACION.

*'''respuesta.etiqueta''': Atributo que indica qué nombre va a tener la tarea respuesta correspondiente

*'''respuesta.descripcion''': Atributo para indicar una descripción sobre la tarea respuesta.

*'''respuesta.formulario''': Atributo para indicar el nombre del formulario, perteneciente al ''target'' de la tarea de tipo REQUERIMIENTO, que se va a mostrar en la tarea de respuesta.

*'''respuesta.clasificador''': Atributo para indicar el nombre del clasificador, perteneciente al ''target'' de la tarea de tipo REQUERIMIENTO, donde se van a guardar los documentos que se pueden adjuntar a una tarea respuesta, perteneciente a una tarea de tipo REQUERIMIENTO.

===Diferentes tipos de tareas===
En la aplicación web STE, una misma tarea de nuestro sistema de información se puede comportar de diferentes maneras, dependiendo de qué valor tenga el atributo ''tipo'' al incluirla en un trámite.

'''Tareas de INICIO'''
Es la tarea que va a iniciar el trámite. En un trámite solo puede haber una tarea de tipo inicio. Esta tarea debe ser definida íntegramente como un proceso en ODL.

incluye [Tramitación de solicitud de becas]
-{{AT|Tipo}}=INICIO;
-{{AT|Etiqueta}}='Tramitación de solicitud de becas universitarias';

'''Tareas de REQUERIMIENTO'''
Son aquellas tareas donde, además de mostrar información, queremos dar al usuario la posibilidad de responder a la tarea mostrada rellenando un formulario o adjuntando alguna documentación requerida.

incluye [Esperar respuesta de requerimiento de documentación]
-{{AT|Tipo}}=REQUERIMIENTO;
-{{AT|Etiqueta}}='Respuesta al requerimiento de solicitud de becas universitarias';
-{{AT|respuesta.etiqueta}} = {{STR|"Responder al requerimiento"}};
-{{AT|respuesta.descripcion}} = {{STR|"Adjunte todo lo solicitado en el documento enviado"}};
-{{AT|respuesta.formulario}} = [Respuesta];
-{{AT|respuesta.clasificador}} = [Documentos adjuntos];

'''Tareas de NOTIFICACION'''
Son aquellas tareas donde sólo se le va a permitir al usuario del STE observar la información que ha sido mandada desde la plataforma egeasy. No podrá ni enviar información, ni modificar la información mandada. Este tipo de tarea suele estar reservado para aquellos datos que son de notificación, como las resoluciones.

incluye [Notificar resolución de la solicitud de beca universitaria]
-{{AT|Tipo}}=NOTIFICACION;
-{{AT|Etiqueta}}='Darse por notificado de la resolución de la solicitud de beca universitaria';

'''Tareas de ENVIO_DOCUMENTACION'''
Son aquellas tareas fuera del ''workflow'' que permiten al usuario de la aplicación web STE enviar documentación. Este tipo de tarea se puede iniciar en cualquier momento durante la vida del trámite.

incluye [Registrar aporte de documentación al trámite]
-{{AT|Tipo}}=ENVIO_DOCUMENTACION;
-{{AT|Etiqueta}}='Aportar documentación adicional al trámite';

=Colecciones=
Para el desarrollo correcto de los trámites en la aplicación web STE, debemos crear al menos una colección para almacenar los contenedores que se crean al iniciar un trámite. Al definir un trámite su ''main target'' tiene que ser el contenedor que se mostrará en la web para que el usuario introduzca los datos iniciales para comenzar el ''workflow'', y no un expediente como se suele hacer cuando programamos un sistema de información en egeasy, de ahí la necesidad de crearnos una colección. (Véase [[Colecciones]]) Posteriormente se moverán esos contenedores creados a su lugar dentro de alguna colección dentro de un expediente.

=Estado de un trámite=
Los trámites en la aplicación web STE tienen estado. El estado de un trámite acabado de iniciar, pero no enviado, tiene el valor de ''borrador''. Una vez enviado a su primera tarea del trámite, éste pasa a tener el valor de ''En trámite''. Por último, cuando el trámite ha finalizado en la plataforma egeasy, pasa a tener el estado de ''finalizado''. Estos valores comentados para el estado de un trámite definen el comportamiento por defecto de la aplicación web STE. Si queremos cambiar el estado de un trámite debemos hacerlo mediante el atributo '''estado''' y su mecanismo para controlarlo, el cual vamos a proceder a explicar a continuación.

Para poder modificar el estado de un trámite durante la vida del ''workflow'' asociado al mismo, debemos crearnos un campo en el contenedor que es ''maintarget'' del ''workflow''. Una vez creado ese campo, debemos exportarlo a alguna colección de nuestra elección. Si hay alguna duda sobre como crear una exportación, véase [[Exportaciones]]. Con la exportación del campo creada, debemos poner en el atributo '''estado''' del trámite, una ristra con el nombre de la tabla en la base de datos seguida de un punto y a continuación el nombre de la columna que representa el campo en la exportación. Para que quede mas claro, vamos a ver un ejemplo:

Esto sería un ejemplo de la exportación creada, donde tenemos un campo en ODL llamado [Estado tramite], el cual se exporta a la tabla de nombre TR$SOLICITUD_TRAMITACION y en la columna ESTADO_TRAMITE.

[EP::Solicitudes de tramitación electrónica] {{PR|es}} exportacion
-{{AT|nombre_tabla}} = {{STR|"TR$SOLICITUD_TRAMITACION"}};
-{{AT|universo}} = [Solicitud de tramitación electrónica para acreditación del profesorado];
{{PR|columna}} [Denominación/Apellidos y nombre]
-{{AT|columna_bd.nombre}} = {{STR|"DENOMINACION"}};
-{{AT|columna_bd}}.{{PR|tipo}} = texto;
-{{AT|origen}} =[Datos generales].[Denominación/Apellidos y nombre];
{{PR|columna}} [C.I.F./N.I.F.]
-{{AT|columna_bd.nombre}} = {{STR|"CIF_NIF"}};
-{{AT|columna_bd}}.{{PR|tipo}} = texto;
-{{AT|origen}} = [Datos generales].[C.I.F./N.I.F.];
{{PR|columna}} [Estado tramite]
-{{AT|columna_bd.nombre}} = {{STR|"ESTADO_TRAMITE"}};
-{{AT|columna_bd}}.{{PR|tipo}} = texto;
-{{AT|origen}} = [Datos generales].[Estado tramite];
{{PR|fin}}

A continuación, un ejemplo de como se declararía un trámite utilizando el atributo '''estado'''.

[Trámite de Acreditación del profesorado] {{PR|es}} tramite
-{{AT|descripcion}}='Procedimiento de tramitación para la aceditación del profesorado para la ACECAU';
-{{AT|grupo}}='Trámites Acecau';
-{{AT|Habitacion}}=[Oficina de evaluación del profesorado];
-{{AT|estado}}={{STR|"TR$SOLTRAMI_ACRE_PROF.ESTADO_TRAMITE"}};

Una vez declarado el atributo estado en el trámite, ya podemos proceder a modificarlo mediante código de método del lenguaje ODL. Para ello, sólo debemos acceder, mediante código ODL, al campo que representa el estado y asignarle el valor deseado que queremos que se muestre en la aplicación web del STE.

NOTA: PONER EJEMPLO DE UN METODO ASIGNADOLE UN VALOR AL CAMPO ESTADO

=Atributos especiales para los campos de ODL=
En la aplicación web STE disponemos, para el lenguaje ODL, de unos atributos especiales aplicables a la definición de componentes para poder definir ciertos aspectos de su comportamiento al interactuar con la aplicación web STE. A continuación, listaremos y definiremos los atributos que ha añadido el STE al lenguage ODL.

'''tramitacion.visible'''

Atributo que permite ocultar un campo para que no se visualice en la aplicación web del STE, pero sí en la plataforma egeasy. Este atributo es aplicable a todos los campos de ODL. El valor por defecto para este atributo es verdadero.

'''tramitacion.requerida'''

Atributo que permite especificar qué campos son de obligada cumplimentación por parte del usuario. El valor por defecto es falso. Este atributo se puede usar en combinación con las validaciones de ODL para indicar cómo se debe cumplimentar un campo.

'''tramitacion.valor'''

Atributo que permite establecer el valor del campo al que se le aplica el atributo.

'''tramitacion.editable'''

Atributo que permite indicar si el campo es editable o no. El valor por defecto es verdadero.


=Formulario de registro de usuarios=
En la aplicación web STE, podemos crear a nuestra medida un formulario de registro de usuarios, donde podemos definir los campos que queremos que el usuario cumplimente al darse de alta para poder utilizar la aplicación web STE. El fichero donde se definen los campos del regostro es un fichero XML y se llama '''registration.xml'''.

A continuación mostramos un ejemplo de un fichero de registro.
<?xml version="1.0" encoding="ISO-8859-1"?>
<registration_form>
<field_value Field_Name="Género" Field_Type="ftString">
<allowed_values>
<item>Masculino</item>
<item>Femenino</item>
</allowed_values>
</field_value>
<field_value Field_Name="Teléfono 1" Field_Type="ftString">
</field_value>
<field_value Field_Name="Teléfono 2" Field_Type="ftString">
</field_value>
<field_value Field_Name="Dirección" Field_Type="ftString">
</field_value>
<field_value Field_Name="Código postal" Field_Type="ftString">
</field_value>
<field_value Field_Name="Localidad" Field_Type="ftString">
</field_value>
<field_value Field_Name="Provincia" Field_Type="ftString">
</field_value>
<field_value Field_Name="Fax" Field_Type="ftString">
</field_value>
</registration_form>

[[Category:Tramitación electrónica]]

Desarrollar con el STE

2009-08-04T08:04:01Z

Imhernandez: /* Estado de un trámite */

__TOC__
=¿Que es un trámite?=
Un trámite es la definición del conjunto de tareas, pertenecientes al ''workflow'', que van a interactuar con la aplicación web STE. Los trámites definidos están orientados a ser iniciados por el usuario desde la aplicación web, para que, a continuación, se inicie un proceso de ''workflow'' programado en ODL para la plataforma egeasy.
==Como se define un trámite==
Para definir un trámite tenemos que indicar el nombre del trámite y declararlo como tipo trámite. La sintaxis de un trámite sería la siguiente.

[Nombre del trámite] es tramite
-ATRIBUTOS
incluye TAREA
.
.
.
incluye TAREA
fin
==Atributos de un trámite==
Los atributos que podemos declarar para un trámite son los siguientes:
*'''descripcion''': Proporciona un texto descriptivo sobre el trámite que se muestra en la interfaz web al crear el trámite.
*'''grupo''': Indica a qué grupo de declaraciones pertenece el trámite.
*'''habitacion''': Indica en qué habitación de nuestro sistema de información queremos que esté disponible el trámite para su realización.
*'''estado''': Indica qué tabla y columna de una exportación va a almacenar el estado de un trámite.

==La clausula incluye==
Dentro de la definición del trámite, debemos especificar cuáles son las tareas del ''wordflow'' que queremos que interactúen con el STE. Para ello, disponemos de la cláusula '''incluye'''. Al utilizarla, debemos especificar, a continuación, el nombre de la tarea e indicar una serie de atributos que especifican varios aspectos del comportamiento de la tarea.

===Atributos de incluye===
Los atributos aplicables a las tareas que incluimos en un trámite pueden variar dependiendo del valor del atributo ''tipo'', por ejemplo, los atributos de respuesta sólo son aplicables a las tareas con el valor en el atributo tipo igual a REQUERIMIENTO. Dicho esto, pasamos a listar los distintos atributos aplicables a la clausula incluye:

*'''Etiqueta''': Atributo que permite establecer el nombre que va a tener la tarea en la aplicación web del STE.

*'''Tipo''': Atributo que indica qué tipo de comportamiento va a tener la tarea. Los distintos valores que acepta este atributo son: INICIO, REQUERIMIENTO, NOTIFICACION y ENVIO_DOCUMENTACION.

*'''respuesta.etiqueta''': Atributo que indica qué nombre va a tener la tarea respuesta correspondiente

*'''respuesta.descripcion''': Atributo para indicar una descripción sobre la tarea respuesta.

*'''respuesta.formulario''': Atributo para indicar el nombre del formulario, perteneciente al ''target'' de la tarea de tipo REQUERIMIENTO, que se va a mostrar en la tarea de respuesta.

*'''respuesta.clasificador''': Atributo para indicar el nombre del clasificador, perteneciente al ''target'' de la tarea de tipo REQUERIMIENTO, donde se van a guardar los documentos que se pueden adjuntar a una tarea respuesta, perteneciente a una tarea de tipo REQUERIMIENTO.

===Diferentes tipos de tareas===
En la aplicación web STE, una misma tarea de nuestro sistema de información se puede comportar de diferentes maneras, dependiendo de qué valor tenga el atributo ''tipo'' al incluirla en un trámite.

'''Tareas de INICIO'''
Es la tarea que va a iniciar el trámite. En un trámite solo puede haber una tarea de tipo inicio. Esta tarea debe ser definida íntegramente como un proceso en ODL.

incluye [Tramitación de solicitud de becas]
-{{AT|Tipo}}=INICIO;
-{{AT|Etiqueta}}='Tramitación de solicitud de becas universitarias';

'''Tareas de REQUERIMIENTO'''
Son aquellas tareas donde, además de mostrar información, queremos dar al usuario la posibilidad de responder a la tarea mostrada rellenando un formulario o adjuntando alguna documentación requerida.

incluye [Esperar respuesta de requerimiento de documentación]
-{{AT|Tipo}}=REQUERIMIENTO;
-{{AT|Etiqueta}}='Respuesta al requerimiento de solicitud de becas universitarias';
-{{AT|respuesta.etiqueta}} = {{STR|"Responder al requerimiento"}};
-{{AT|respuesta.descripcion}} = {{STR|"Adjunte todo lo solicitado en el documento enviado"}};
-{{AT|respuesta.formulario}} = [Respuesta];
-{{AT|respuesta.clasificador}} = [Documentos adjuntos];

'''Tareas de NOTIFICACION'''
Son aquellas tareas donde sólo se le va a permitir al usuario del STE observar la información que ha sido mandada desde la plataforma egeasy. No podrá ni enviar información, ni modificar la información mandada. Este tipo de tarea suele estar reservado para aquellos datos que son de notificación, como las resoluciones.

incluye [Notificar resolución de la solicitud de beca universitaria]
-{{AT|Tipo}}=NOTIFICACION;
-{{AT|Etiqueta}}='Darse por notificado de la resolución de la solicitud de beca universitaria';

'''Tareas de ENVIO_DOCUMENTACION'''
Son aquellas tareas fuera del ''workflow'' que permiten al usuario de la aplicación web STE enviar documentación. Este tipo de tarea se puede iniciar en cualquier momento durante la vida del trámite.

incluye [Registrar aporte de documentación al trámite]
-{{AT|Tipo}}=ENVIO_DOCUMENTACION;
-{{AT|Etiqueta}}='Aportar documentación adicional al trámite';

=Colecciones=
Para el desarrollo correcto de los trámites en la aplicación web STE, debemos crear al menos una colección para almacenar los contenedores que se crean al iniciar un trámite. Al definir un trámite su ''main target'' tiene que ser el contenedor que se mostrará en la web para que el usuario introduzca los datos iniciales para comenzar el ''workflow'', y no un expediente como se suele hacer cuando programamos un sistema de información en egeasy, de ahí la necesidad de crearnos una colección. (Véase [[Colecciones]]) Posteriormente se moverán esos contenedores creados a su lugar dentro de alguna colección dentro de un expediente.

=Estado de un trámite=
Los trámites en la aplicación web STE tienen estado. El estado de un trámite acabado de iniciar, pero no enviado, tiene el valor de ''borrador''. Una vez enviado a su primera tarea del trámite, éste pasa a tener el valor de ''En trámite''. Por último, cuando el trámite ha finalizado en la plataforma egeasy, pasa a tener el estado de ''finalizado''. Estos valores comentados para el estado de un trámite definen el comportamiento por defecto de la aplicación web STE. Si queremos cambiar el estado de un trámite debemos hacerlo mediante el atributo '''estado''' y su mecanismo para controlarlo, el cual vamos a proceder a explicar a continuación.

Para poder modificar el estado de un trámite durante la vida del ''workflow'' asociado al mismo, debemos crearnos un campo en el contenedor que es ''maintarget'' del ''workflow''. Una vez creado ese campo, debemos exportarlo a alguna colección de nuestra elección. Si hay alguna duda sobre como crear una exportación, véase [[Exportaciones]]. Con la exportación del campo creada, debemos poner en el atributo '''estado''' del trámite, una ristra con el nombre de la tabla en la base de datos seguida de un punto y a continuación el nombre de la columna que representa el campo en la exportación. Para que quede mas claro, vamos a ver un ejemplo:

Esto sería un ejemplo de la exportación creada, donde tenemos un campo en ODL llamado [Estado tramite], el cual se exporta a la tabla de nombre TR$SOLICITUD_TRAMITACION y en la columna ESTADO_TRAMITE.

[EP::Solicitudes de tramitación electrónica] {{PR|es}} exportacion
-{{AT|nombre_tabla}} = {{STR|"TR$SOLICITUD_TRAMITACION"}};
-{{AT|universo}} = [Solicitud de tramitación electrónica para acreditación del profesorado];
{{PR|columna}} [Denominación/Apellidos y nombre]
-{{AT|columna_bd.nombre}} = {{STR|"DENOMINACION"}};
-{{AT|columna_bd}}.{{PR|tipo}} = texto;
-{{AT|origen}} =[Datos generales].[Denominación/Apellidos y nombre];
{{PR|columna}} [C.I.F./N.I.F.]
-{{AT|columna_bd.nombre}} = {{STR|"CIF_NIF"}};
-{{AT|columna_bd}}.{{PR|tipo}} = texto;
-{{AT|origen}} = [Datos generales].[C.I.F./N.I.F.];
{{PR|columna}} [Estado tramite]
-{{AT|columna_bd.nombre}} = {{STR|"ESTADO_TRAMITE"}};
-{{AT|columna_bd}}.{{PR|tipo}} = texto;
-{{AT|origen}} = [Datos generales].[Estado tramite];
{{PR|fin}}

A continuación, un ejemplo de como se declararía un trámite utilizando el atributo '''estado'''.

[Trámite de Acreditación del profesorado] {{PR|es}} tramite
-{{AT|descripcion}}='Procedimiento de tramitación para la aceditación del profesorado para la ACECAU';
-{{AT|grupo}}='Trámites Acecau';
-{{AT|Habitacion}}=[Oficina de evaluación del profesorado];
-{{AT|estado}}={{STR|"TR$SOLTRAMI_ACRE_PROF.ESTADO_TRAMITE"}};

Una vez declarado el atributo estado en el trámite, ya podemos proceder a modificarlo mediante código de método del lenguaje ODL. Para ello, sólo debemos acceder, mediante código ODL, al campo que representa el estado y asignarle el valor deseado que queremos que se muestre en la aplicación web del STE.

NOTA: PONER EJEMPLO DE UN METODO ASIGNADOLE UN VALOR AL CAMPO ESTADO

=Atributos especiales para los campos de ODL=
Junto con la aplicación web STE disponemos para el lenguaje ODL, de unos atributos especiales aplicables a la definición de componentes para poder definir ciertos aspectos del comportamiento de los componentes que interactuan con la aplicación web STE. A continuación listaremos y definiremos los atributos que ha añadido el STE al lenguage ODL.

'''tramitacion.visible'''

Atributo que permite ocultar un campo para que no se visualice en la aplicación web del STE pero si en la plataforma egeasy. Este atributo es aplicable a todos los campos de ODL. El valor por defecto para este atributo es verdadero.

'''tramitacion.requerida'''

Atributo que permite especificar que campos son de obligada cumplimentación por parte del usuario
para la aplicación web del STE. El valor por defecto para este atributo es falso. Este atributo se puede usar en combinación con las validaciones de ODL para indicar como se debe cumplimentar un campo.

'''tramitacion.valor'''

Atributo que permite establecer el valor del campo al que se le aplica el atributo.

'''tramitacion.editable'''

Atributo que permite indicar si el campo es editable o no. El valor por defecto para este atributo es verdadero.


=Formulario de registro de usuarios=
En la aplicación web STE, podemos crear a nuestra medida un formulario de registro de usuarios, donde podemos definir los campos que queremos que el usuario cumplimente al darse de alta para poder utilizar la aplicación web STE. El fichero donde se definen los campos del regostro es un fichero XML y se llama '''registration.xml'''.

A continuación mostramos un ejemplo de un fichero de registro.
<?xml version="1.0" encoding="ISO-8859-1"?>
<registration_form>
<field_value Field_Name="Género" Field_Type="ftString">
<allowed_values>
<item>Masculino</item>
<item>Femenino</item>
</allowed_values>
</field_value>
<field_value Field_Name="Teléfono 1" Field_Type="ftString">
</field_value>
<field_value Field_Name="Teléfono 2" Field_Type="ftString">
</field_value>
<field_value Field_Name="Dirección" Field_Type="ftString">
</field_value>
<field_value Field_Name="Código postal" Field_Type="ftString">
</field_value>
<field_value Field_Name="Localidad" Field_Type="ftString">
</field_value>
<field_value Field_Name="Provincia" Field_Type="ftString">
</field_value>
<field_value Field_Name="Fax" Field_Type="ftString">
</field_value>
</registration_form>

[[Category:Tramitación electrónica]]

Desarrollar con el STE

2009-08-04T07:52:43Z

Imhernandez: /* Colecciones */

__TOC__
=¿Que es un trámite?=
Un trámite es la definición del conjunto de tareas, pertenecientes al ''workflow'', que van a interactuar con la aplicación web STE. Los trámites definidos están orientados a ser iniciados por el usuario desde la aplicación web, para que, a continuación, se inicie un proceso de ''workflow'' programado en ODL para la plataforma egeasy.
==Como se define un trámite==
Para definir un trámite tenemos que indicar el nombre del trámite y declararlo como tipo trámite. La sintaxis de un trámite sería la siguiente.

[Nombre del trámite] es tramite
-ATRIBUTOS
incluye TAREA
.
.
.
incluye TAREA
fin
==Atributos de un trámite==
Los atributos que podemos declarar para un trámite son los siguientes:
*'''descripcion''': Proporciona un texto descriptivo sobre el trámite que se muestra en la interfaz web al crear el trámite.
*'''grupo''': Indica a qué grupo de declaraciones pertenece el trámite.
*'''habitacion''': Indica en qué habitación de nuestro sistema de información queremos que esté disponible el trámite para su realización.
*'''estado''': Indica qué tabla y columna de una exportación va a almacenar el estado de un trámite.

==La clausula incluye==
Dentro de la definición del trámite, debemos especificar cuáles son las tareas del ''wordflow'' que queremos que interactúen con el STE. Para ello, disponemos de la cláusula '''incluye'''. Al utilizarla, debemos especificar, a continuación, el nombre de la tarea e indicar una serie de atributos que especifican varios aspectos del comportamiento de la tarea.

===Atributos de incluye===
Los atributos aplicables a las tareas que incluimos en un trámite pueden variar dependiendo del valor del atributo ''tipo'', por ejemplo, los atributos de respuesta sólo son aplicables a las tareas con el valor en el atributo tipo igual a REQUERIMIENTO. Dicho esto, pasamos a listar los distintos atributos aplicables a la clausula incluye:

*'''Etiqueta''': Atributo que permite establecer el nombre que va a tener la tarea en la aplicación web del STE.

*'''Tipo''': Atributo que indica qué tipo de comportamiento va a tener la tarea. Los distintos valores que acepta este atributo son: INICIO, REQUERIMIENTO, NOTIFICACION y ENVIO_DOCUMENTACION.

*'''respuesta.etiqueta''': Atributo que indica qué nombre va a tener la tarea respuesta correspondiente

*'''respuesta.descripcion''': Atributo para indicar una descripción sobre la tarea respuesta.

*'''respuesta.formulario''': Atributo para indicar el nombre del formulario, perteneciente al ''target'' de la tarea de tipo REQUERIMIENTO, que se va a mostrar en la tarea de respuesta.

*'''respuesta.clasificador''': Atributo para indicar el nombre del clasificador, perteneciente al ''target'' de la tarea de tipo REQUERIMIENTO, donde se van a guardar los documentos que se pueden adjuntar a una tarea respuesta, perteneciente a una tarea de tipo REQUERIMIENTO.

===Diferentes tipos de tareas===
En la aplicación web STE, una misma tarea de nuestro sistema de información se puede comportar de diferentes maneras, dependiendo de qué valor tenga el atributo ''tipo'' al incluirla en un trámite.

'''Tareas de INICIO'''
Es la tarea que va a iniciar el trámite. En un trámite solo puede haber una tarea de tipo inicio. Esta tarea debe ser definida íntegramente como un proceso en ODL.

incluye [Tramitación de solicitud de becas]
-{{AT|Tipo}}=INICIO;
-{{AT|Etiqueta}}='Tramitación de solicitud de becas universitarias';

'''Tareas de REQUERIMIENTO'''
Son aquellas tareas donde, además de mostrar información, queremos dar al usuario la posibilidad de responder a la tarea mostrada rellenando un formulario o adjuntando alguna documentación requerida.

incluye [Esperar respuesta de requerimiento de documentación]
-{{AT|Tipo}}=REQUERIMIENTO;
-{{AT|Etiqueta}}='Respuesta al requerimiento de solicitud de becas universitarias';
-{{AT|respuesta.etiqueta}} = {{STR|"Responder al requerimiento"}};
-{{AT|respuesta.descripcion}} = {{STR|"Adjunte todo lo solicitado en el documento enviado"}};
-{{AT|respuesta.formulario}} = [Respuesta];
-{{AT|respuesta.clasificador}} = [Documentos adjuntos];

'''Tareas de NOTIFICACION'''
Son aquellas tareas donde sólo se le va a permitir al usuario del STE observar la información que ha sido mandada desde la plataforma egeasy. No podrá ni enviar información, ni modificar la información mandada. Este tipo de tarea suele estar reservado para aquellos datos que son de notificación, como las resoluciones.

incluye [Notificar resolución de la solicitud de beca universitaria]
-{{AT|Tipo}}=NOTIFICACION;
-{{AT|Etiqueta}}='Darse por notificado de la resolución de la solicitud de beca universitaria';

'''Tareas de ENVIO_DOCUMENTACION'''
Son aquellas tareas fuera del ''workflow'' que permiten al usuario de la aplicación web STE enviar documentación. Este tipo de tarea se puede iniciar en cualquier momento durante la vida del trámite.

incluye [Registrar aporte de documentación al trámite]
-{{AT|Tipo}}=ENVIO_DOCUMENTACION;
-{{AT|Etiqueta}}='Aportar documentación adicional al trámite';

=Colecciones=
Para el desarrollo correcto de los trámites en la aplicación web STE, debemos crear al menos una colección para almacenar los contenedores que se crean al iniciar un trámite. Al definir un trámite su ''main target'' tiene que ser el contenedor que se mostrará en la web para que el usuario introduzca los datos iniciales para comenzar el ''workflow'', y no un expediente como se suele hacer cuando programamos un sistema de información en egeasy, de ahí la necesidad de crearnos una colección. (Véase [[Colecciones]]) Posteriormente se moverán esos contenedores creados a su lugar dentro de alguna colección dentro de un expediente.

=Estado de un trámite=
Los trámites en la aplicación web STE, tienen estado. El estado de un trámite acabado de iniciar pero no enviado, tiene el valor de ''borrador''. Una vez enviado su primera tarea del trámite, este pasa a tener el valor de ''En trámite''. Por último cuando el trámite ha finalizado en la plataforma egeasy, el trámite pasa a tener el estado de ''finalizado''. Estos valores comentados para el estado de un trámite, es el comportamiento por defecto de la aplicación web STE. Si queremos cambiar el estado de un trámite debemos hacerlo mediante el atributo '''estado''' y su mecanismo para controlarlo, el cual vamos a proceder a explicarlo a continuación.

Para poder modificar el estado de un tramite durante la vida del ''workflow'' asociado al trámite, debemos crearnos un campo en el contenedor que es ''maintarget'' del ''workflow''. Una vez creado ese campo, debemos hacer una exportación de ese campo en alguna colección de nuestra elección. Si hay alguna duda sobre como crear una exportación, véase [[Exportaciones]]. Con la exportación del campo creada, debemos poner en el atributo '''estado''' del trámite, una ristra con el nombre de la tabla en la base de datos seguida de un punto y a continuación el nombre de la columna que representa el campo en la exportación. Para que quede mas claro, vamos a ver un ejemplo:

Esto seria un ejemplo de la exportación creada, donde tenemos un campo llamado en ODL [Estado tramite], el cual se exporta a la tabla de nombre TR$SOLICITUD_TRAMITACION y en la columna ESTADO_TRAMITE.

[EP::Solicitudes de tramitación electrónica] {{PR|es}} exportacion
-{{AT|nombre_tabla}} = {{STR|"TR$SOLICITUD_TRAMITACION"}};
-{{AT|universo}} = [Solicitud de tramitación electrónica para acreditación del profesorado];
{{PR|columna}} [Denominación/Apellidos y nombre]
-{{AT|columna_bd.nombre}} = {{STR|"DENOMINACION"}};
-{{AT|columna_bd}}.{{PR|tipo}} = texto;
-{{AT|origen}} =[Datos generales].[Denominación/Apellidos y nombre];
{{PR|columna}} [C.I.F./N.I.F.]
-{{AT|columna_bd.nombre}} = {{STR|"CIF_NIF"}};
-{{AT|columna_bd}}.{{PR|tipo}} = texto;
-{{AT|origen}} = [Datos generales].[C.I.F./N.I.F.];
{{PR|columna}} [Estado tramite]
-{{AT|columna_bd.nombre}} = {{STR|"ESTADO_TRAMITE"}};
-{{AT|columna_bd}}.{{PR|tipo}} = texto;
-{{AT|origen}} = [Datos generales].[Estado tramite];
{{PR|fin}}

A continuación un ejemplo de como se declararía un trámite utilizando el atributo '''estado'''.

[Trámite de Acreditación del profesorado] {{PR|es}} tramite
-{{AT|descripcion}}='Procedimiento de tramitación para la aceditación del profesorado para la ACECAU';
-{{AT|grupo}}='Trámites Acecau';
-{{AT|Habitacion}}=[Oficina de evaluación del profesorado];
-{{AT|estado}}={{STR|"TR$SOLTRAMI_ACRE_PROF.ESTADO_TRAMITE"}};

Una vez declarado el atributo estado en el trámite, ya podemos proceder a modificar el estado de un trámite mediante código de método, del lenguaje ODL. Para ello solo debemos acceder al campo mediante código ODL, al campo que representa el estado en el contenedor que es ''maintarget'' del ''workflow'' asociado al trámite y asignarle el valor deseado que queremos que se muestre en la aplicación web del STE.

NOTA: PONER EJEMPLO DE UN METODO ASIGNADOLE UN VALOR AL CAMPO ESTADO

=Atributos especiales para los campos de ODL=
Junto con la aplicación web STE disponemos para el lenguaje ODL, de unos atributos especiales aplicables a la definición de componentes para poder definir ciertos aspectos del comportamiento de los componentes que interactuan con la aplicación web STE. A continuación listaremos y definiremos los atributos que ha añadido el STE al lenguage ODL.

'''tramitacion.visible'''

Atributo que permite ocultar un campo para que no se visualice en la aplicación web del STE pero si en la plataforma egeasy. Este atributo es aplicable a todos los campos de ODL. El valor por defecto para este atributo es verdadero.

'''tramitacion.requerida'''

Atributo que permite especificar que campos son de obligada cumplimentación por parte del usuario
para la aplicación web del STE. El valor por defecto para este atributo es falso. Este atributo se puede usar en combinación con las validaciones de ODL para indicar como se debe cumplimentar un campo.

'''tramitacion.valor'''

Atributo que permite establecer el valor del campo al que se le aplica el atributo.

'''tramitacion.editable'''

Atributo que permite indicar si el campo es editable o no. El valor por defecto para este atributo es verdadero.


=Formulario de registro de usuarios=
En la aplicación web STE, podemos crear a nuestra medida un formulario de registro de usuarios, donde podemos definir los campos que queremos que el usuario cumplimente al darse de alta para poder utilizar la aplicación web STE. El fichero donde se definen los campos del regostro es un fichero XML y se llama '''registration.xml'''.

A continuación mostramos un ejemplo de un fichero de registro.
<?xml version="1.0" encoding="ISO-8859-1"?>
<registration_form>
<field_value Field_Name="Género" Field_Type="ftString">
<allowed_values>
<item>Masculino</item>
<item>Femenino</item>
</allowed_values>
</field_value>
<field_value Field_Name="Teléfono 1" Field_Type="ftString">
</field_value>
<field_value Field_Name="Teléfono 2" Field_Type="ftString">
</field_value>
<field_value Field_Name="Dirección" Field_Type="ftString">
</field_value>
<field_value Field_Name="Código postal" Field_Type="ftString">
</field_value>
<field_value Field_Name="Localidad" Field_Type="ftString">
</field_value>
<field_value Field_Name="Provincia" Field_Type="ftString">
</field_value>
<field_value Field_Name="Fax" Field_Type="ftString">
</field_value>
</registration_form>

[[Category:Tramitación electrónica]]

Desarrollar con el STE

2009-08-04T07:42:08Z

Imhernandez: /* Diferentes tipos de tareas */

__TOC__
=¿Que es un trámite?=
Un trámite es la definición del conjunto de tareas, pertenecientes al ''workflow'', que van a interactuar con la aplicación web STE. Los trámites definidos están orientados a ser iniciados por el usuario desde la aplicación web, para que, a continuación, se inicie un proceso de ''workflow'' programado en ODL para la plataforma egeasy.
==Como se define un trámite==
Para definir un trámite tenemos que indicar el nombre del trámite y declararlo como tipo trámite. La sintaxis de un trámite sería la siguiente.

[Nombre del trámite] es tramite
-ATRIBUTOS
incluye TAREA
.
.
.
incluye TAREA
fin
==Atributos de un trámite==
Los atributos que podemos declarar para un trámite son los siguientes:
*'''descripcion''': Proporciona un texto descriptivo sobre el trámite que se muestra en la interfaz web al crear el trámite.
*'''grupo''': Indica a qué grupo de declaraciones pertenece el trámite.
*'''habitacion''': Indica en qué habitación de nuestro sistema de información queremos que esté disponible el trámite para su realización.
*'''estado''': Indica qué tabla y columna de una exportación va a almacenar el estado de un trámite.

==La clausula incluye==
Dentro de la definición del trámite, debemos especificar cuáles son las tareas del ''wordflow'' que queremos que interactúen con el STE. Para ello, disponemos de la cláusula '''incluye'''. Al utilizarla, debemos especificar, a continuación, el nombre de la tarea e indicar una serie de atributos que especifican varios aspectos del comportamiento de la tarea.

===Atributos de incluye===
Los atributos aplicables a las tareas que incluimos en un trámite pueden variar dependiendo del valor del atributo ''tipo'', por ejemplo, los atributos de respuesta sólo son aplicables a las tareas con el valor en el atributo tipo igual a REQUERIMIENTO. Dicho esto, pasamos a listar los distintos atributos aplicables a la clausula incluye:

*'''Etiqueta''': Atributo que permite establecer el nombre que va a tener la tarea en la aplicación web del STE.

*'''Tipo''': Atributo que indica qué tipo de comportamiento va a tener la tarea. Los distintos valores que acepta este atributo son: INICIO, REQUERIMIENTO, NOTIFICACION y ENVIO_DOCUMENTACION.

*'''respuesta.etiqueta''': Atributo que indica qué nombre va a tener la tarea respuesta correspondiente

*'''respuesta.descripcion''': Atributo para indicar una descripción sobre la tarea respuesta.

*'''respuesta.formulario''': Atributo para indicar el nombre del formulario, perteneciente al ''target'' de la tarea de tipo REQUERIMIENTO, que se va a mostrar en la tarea de respuesta.

*'''respuesta.clasificador''': Atributo para indicar el nombre del clasificador, perteneciente al ''target'' de la tarea de tipo REQUERIMIENTO, donde se van a guardar los documentos que se pueden adjuntar a una tarea respuesta, perteneciente a una tarea de tipo REQUERIMIENTO.

===Diferentes tipos de tareas===
En la aplicación web STE, una misma tarea de nuestro sistema de información se puede comportar de diferentes maneras, dependiendo de qué valor tenga el atributo ''tipo'' al incluirla en un trámite.

'''Tareas de INICIO'''
Es la tarea que va a iniciar el trámite. En un trámite solo puede haber una tarea de tipo inicio. Esta tarea debe ser definida íntegramente como un proceso en ODL.

incluye [Tramitación de solicitud de becas]
-{{AT|Tipo}}=INICIO;
-{{AT|Etiqueta}}='Tramitación de solicitud de becas universitarias';

'''Tareas de REQUERIMIENTO'''
Son aquellas tareas donde, además de mostrar información, queremos dar al usuario la posibilidad de responder a la tarea mostrada rellenando un formulario o adjuntando alguna documentación requerida.

incluye [Esperar respuesta de requerimiento de documentación]
-{{AT|Tipo}}=REQUERIMIENTO;
-{{AT|Etiqueta}}='Respuesta al requerimiento de solicitud de becas universitarias';
-{{AT|respuesta.etiqueta}} = {{STR|"Responder al requerimiento"}};
-{{AT|respuesta.descripcion}} = {{STR|"Adjunte todo lo solicitado en el documento enviado"}};
-{{AT|respuesta.formulario}} = [Respuesta];
-{{AT|respuesta.clasificador}} = [Documentos adjuntos];

'''Tareas de NOTIFICACION'''
Son aquellas tareas donde sólo se le va a permitir al usuario del STE observar la información que ha sido mandada desde la plataforma egeasy. No podrá ni enviar información, ni modificar la información mandada. Este tipo de tarea suele estar reservado para aquellos datos que son de notificación, como las resoluciones.

incluye [Notificar resolución de la solicitud de beca universitaria]
-{{AT|Tipo}}=NOTIFICACION;
-{{AT|Etiqueta}}='Darse por notificado de la resolución de la solicitud de beca universitaria';

'''Tareas de ENVIO_DOCUMENTACION'''
Son aquellas tareas fuera del ''workflow'' que permiten al usuario de la aplicación web STE enviar documentación. Este tipo de tarea se puede iniciar en cualquier momento durante la vida del trámite.

incluye [Registrar aporte de documentación al trámite]
-{{AT|Tipo}}=ENVIO_DOCUMENTACION;
-{{AT|Etiqueta}}='Aportar documentación adicional al trámite';

=Colecciones=
Para el desarrollo correcto de los tramites en la aplicación web STE, debemos crear al menos una colección para almacenar los contenedores que se crean al iniciar un trámite. Como al definir un tramite, su ''main target'' tiene que ser el contenedor que se mostrará en la web para que el usuario introduzca los datos iniciales para comenzar el ''workflow'' asociado a un trámite y no un expediente como se suele hacer cuando programamos un sistema de información en egeasy, tendremos que crearnos una colección (Véase [[Colecciones]]) para almacenar inicialmente los contenedores creados por la aplicación STE al iniciar un trámite, para luego posteriormente mover ese contenedor a su lugar dentro de alguna colección dentro de un expediente.

=Estado de un trámite=
Los trámites en la aplicación web STE, tienen estado. El estado de un trámite acabado de iniciar pero no enviado, tiene el valor de ''borrador''. Una vez enviado su primera tarea del trámite, este pasa a tener el valor de ''En trámite''. Por último cuando el trámite ha finalizado en la plataforma egeasy, el trámite pasa a tener el estado de ''finalizado''. Estos valores comentados para el estado de un trámite, es el comportamiento por defecto de la aplicación web STE. Si queremos cambiar el estado de un trámite debemos hacerlo mediante el atributo '''estado''' y su mecanismo para controlarlo, el cual vamos a proceder a explicarlo a continuación.

Para poder modificar el estado de un tramite durante la vida del ''workflow'' asociado al trámite, debemos crearnos un campo en el contenedor que es ''maintarget'' del ''workflow''. Una vez creado ese campo, debemos hacer una exportación de ese campo en alguna colección de nuestra elección. Si hay alguna duda sobre como crear una exportación, véase [[Exportaciones]]. Con la exportación del campo creada, debemos poner en el atributo '''estado''' del trámite, una ristra con el nombre de la tabla en la base de datos seguida de un punto y a continuación el nombre de la columna que representa el campo en la exportación. Para que quede mas claro, vamos a ver un ejemplo:

Esto seria un ejemplo de la exportación creada, donde tenemos un campo llamado en ODL [Estado tramite], el cual se exporta a la tabla de nombre TR$SOLICITUD_TRAMITACION y en la columna ESTADO_TRAMITE.

[EP::Solicitudes de tramitación electrónica] {{PR|es}} exportacion
-{{AT|nombre_tabla}} = {{STR|"TR$SOLICITUD_TRAMITACION"}};
-{{AT|universo}} = [Solicitud de tramitación electrónica para acreditación del profesorado];
{{PR|columna}} [Denominación/Apellidos y nombre]
-{{AT|columna_bd.nombre}} = {{STR|"DENOMINACION"}};
-{{AT|columna_bd}}.{{PR|tipo}} = texto;
-{{AT|origen}} =[Datos generales].[Denominación/Apellidos y nombre];
{{PR|columna}} [C.I.F./N.I.F.]
-{{AT|columna_bd.nombre}} = {{STR|"CIF_NIF"}};
-{{AT|columna_bd}}.{{PR|tipo}} = texto;
-{{AT|origen}} = [Datos generales].[C.I.F./N.I.F.];
{{PR|columna}} [Estado tramite]
-{{AT|columna_bd.nombre}} = {{STR|"ESTADO_TRAMITE"}};
-{{AT|columna_bd}}.{{PR|tipo}} = texto;
-{{AT|origen}} = [Datos generales].[Estado tramite];
{{PR|fin}}

A continuación un ejemplo de como se declararía un trámite utilizando el atributo '''estado'''.

[Trámite de Acreditación del profesorado] {{PR|es}} tramite
-{{AT|descripcion}}='Procedimiento de tramitación para la aceditación del profesorado para la ACECAU';
-{{AT|grupo}}='Trámites Acecau';
-{{AT|Habitacion}}=[Oficina de evaluación del profesorado];
-{{AT|estado}}={{STR|"TR$SOLTRAMI_ACRE_PROF.ESTADO_TRAMITE"}};

Una vez declarado el atributo estado en el trámite, ya podemos proceder a modificar el estado de un trámite mediante código de método, del lenguaje ODL. Para ello solo debemos acceder al campo mediante código ODL, al campo que representa el estado en el contenedor que es ''maintarget'' del ''workflow'' asociado al trámite y asignarle el valor deseado que queremos que se muestre en la aplicación web del STE.

NOTA: PONER EJEMPLO DE UN METODO ASIGNADOLE UN VALOR AL CAMPO ESTADO

=Atributos especiales para los campos de ODL=
Junto con la aplicación web STE disponemos para el lenguaje ODL, de unos atributos especiales aplicables a la definición de componentes para poder definir ciertos aspectos del comportamiento de los componentes que interactuan con la aplicación web STE. A continuación listaremos y definiremos los atributos que ha añadido el STE al lenguage ODL.

'''tramitacion.visible'''

Atributo que permite ocultar un campo para que no se visualice en la aplicación web del STE pero si en la plataforma egeasy. Este atributo es aplicable a todos los campos de ODL. El valor por defecto para este atributo es verdadero.

'''tramitacion.requerida'''

Atributo que permite especificar que campos son de obligada cumplimentación por parte del usuario
para la aplicación web del STE. El valor por defecto para este atributo es falso. Este atributo se puede usar en combinación con las validaciones de ODL para indicar como se debe cumplimentar un campo.

'''tramitacion.valor'''

Atributo que permite establecer el valor del campo al que se le aplica el atributo.

'''tramitacion.editable'''

Atributo que permite indicar si el campo es editable o no. El valor por defecto para este atributo es verdadero.


=Formulario de registro de usuarios=
En la aplicación web STE, podemos crear a nuestra medida un formulario de registro de usuarios, donde podemos definir los campos que queremos que el usuario cumplimente al darse de alta para poder utilizar la aplicación web STE. El fichero donde se definen los campos del regostro es un fichero XML y se llama '''registration.xml'''.

A continuación mostramos un ejemplo de un fichero de registro.
<?xml version="1.0" encoding="ISO-8859-1"?>
<registration_form>
<field_value Field_Name="Género" Field_Type="ftString">
<allowed_values>
<item>Masculino</item>
<item>Femenino</item>
</allowed_values>
</field_value>
<field_value Field_Name="Teléfono 1" Field_Type="ftString">
</field_value>
<field_value Field_Name="Teléfono 2" Field_Type="ftString">
</field_value>
<field_value Field_Name="Dirección" Field_Type="ftString">
</field_value>
<field_value Field_Name="Código postal" Field_Type="ftString">
</field_value>
<field_value Field_Name="Localidad" Field_Type="ftString">
</field_value>
<field_value Field_Name="Provincia" Field_Type="ftString">
</field_value>
<field_value Field_Name="Fax" Field_Type="ftString">
</field_value>
</registration_form>

[[Category:Tramitación electrónica]]

Desarrollar con el STE

2009-08-03T14:26:16Z

Imhernandez: /* La clausula incluye */

__TOC__
=¿Que es un trámite?=
Un trámite es la definición del conjunto de tareas, pertenecientes al ''workflow'', que van a interactuar con la aplicación web STE. Los trámites definidos están orientados a ser iniciados por el usuario desde la aplicación web, para que, a continuación, se inicie un proceso de ''workflow'' programado en ODL para la plataforma egeasy.
==Como se define un trámite==
Para definir un trámite tenemos que indicar el nombre del trámite y declararlo como tipo trámite. La sintaxis de un trámite sería la siguiente.

[Nombre del trámite] es tramite
-ATRIBUTOS
incluye TAREA
.
.
.
incluye TAREA
fin
==Atributos de un trámite==
Los atributos que podemos declarar para un trámite son los siguientes:
*'''descripcion''': Proporciona un texto descriptivo sobre el trámite que se muestra en la interfaz web al crear el trámite.
*'''grupo''': Indica a qué grupo de declaraciones pertenece el trámite.
*'''habitacion''': Indica en qué habitación de nuestro sistema de información queremos que esté disponible el trámite para su realización.
*'''estado''': Indica qué tabla y columna de una exportación va a almacenar el estado de un trámite.

==La clausula incluye==
Dentro de la definición del trámite, debemos especificar cuáles son las tareas del ''wordflow'' que queremos que interactúen con el STE. Para ello, disponemos de la cláusula '''incluye'''. Al utilizarla, debemos especificar, a continuación, el nombre de la tarea e indicar una serie de atributos que especifican varios aspectos del comportamiento de la tarea.

===Atributos de incluye===
Los atributos aplicables a las tareas que incluimos en un trámite pueden variar dependiendo del valor del atributo ''tipo'', por ejemplo, los atributos de respuesta sólo son aplicables a las tareas con el valor en el atributo tipo igual a REQUERIMIENTO. Dicho esto, pasamos a listar los distintos atributos aplicables a la clausula incluye:

*'''Etiqueta''': Atributo que permite establecer el nombre que va a tener la tarea en la aplicación web del STE.

*'''Tipo''': Atributo que indica qué tipo de comportamiento va a tener la tarea. Los distintos valores que acepta este atributo son: INICIO, REQUERIMIENTO, NOTIFICACION y ENVIO_DOCUMENTACION.

*'''respuesta.etiqueta''': Atributo que indica qué nombre va a tener la tarea respuesta correspondiente

*'''respuesta.descripcion''': Atributo para indicar una descripción sobre la tarea respuesta.

*'''respuesta.formulario''': Atributo para indicar el nombre del formulario, perteneciente al ''target'' de la tarea de tipo REQUERIMIENTO, que se va a mostrar en la tarea de respuesta.

*'''respuesta.clasificador''': Atributo para indicar el nombre del clasificador, perteneciente al ''target'' de la tarea de tipo REQUERIMIENTO, donde se van a guardar los documentos que se pueden adjuntar a una tarea respuesta, perteneciente a una tarea de tipo REQUERIMIENTO.

===Diferentes tipos de tareas===
En la aplicación web STE, una misma tarea de nuestro sistema de información se puede comportar de diferentes maneras, dependiendo de qué valor tenga el atributo ''tipo'' al incluirla en un trámite.

'''Tareas de INICIO'''
Es la tarea que va a iniciar el trámite. En un trámite solo puede haber una tarea de tipo inicio. Esta tarea debe ser definida íntegramente como un proceso en ODL.

incluye [Tramitación de solicitud de becas]
-{{AT|Tipo}}=INICIO;
-{{AT|Etiqueta}}='Tramitación de solicitud de becas universitarias';

'''Tareas de REQUERIMIENTO'''
Son aquellas tareas donde, además de mostrar información, queremos dar al usuario la posibilidad de responder a la tarea mostrada rellenando un formulario o adjuntando alguna documentación requerida.

incluye [Esperar respuesta de requerimiento de documentación]
-{{AT|Tipo}}=REQUERIMIENTO;
-{{AT|Etiqueta}}='Respuesta al requerimiento de solicitud de becas universitarias';
-{{AT|respuesta.etiqueta}} = {{STR|"Responder al requerimiento"}};
-{{AT|respuesta.descripcion}} = {{STR|"Adjunte todo lo solicitado en el documento enviado"}};
-{{AT|respuesta.formulario}} = [Respuesta];
-{{AT|respuesta.clasificador}} = [Documentos adjuntos];

'''Tareas de NOTIFICACION'''
Son aquellas tareas donde solo se le va a permitir al usuario del STE observar la información que ha sido mandada desde la plataforma egeasy, donde no podrá ni enviar información, ni modificar la información mandada. Este tipo de tareas suele estar reservados para aquellos datos que son de notificación, como las resoluciones.

incluye [Notificar resolución de la solicitud de beca universitaria]
-{{AT|Tipo}}=NOTIFICACION;
-{{AT|Etiqueta}}='Darse por notificado de la resolución de la solicitud de beca universitaria';

'''Tareas de ENVIO_DOCUMENTACION'''
Son aquellas tareas fuera del ''workflow'' que permiten al usuario de la aplicación web STE enviar documentación. Este tipo de tareas se pueden iniciar en cualquier momento durante la vida del trámite.

incluye [Registrar aporte de documentación al trámite]
-{{AT|Tipo}}=ENVIO_DOCUMENTACION;
-{{AT|Etiqueta}}='Aportar documentación adicional al trámite';

=Colecciones=
Para el desarrollo correcto de los tramites en la aplicación web STE, debemos crear al menos una colección para almacenar los contenedores que se crean al iniciar un trámite. Como al definir un tramite, su ''main target'' tiene que ser el contenedor que se mostrará en la web para que el usuario introduzca los datos iniciales para comenzar el ''workflow'' asociado a un trámite y no un expediente como se suele hacer cuando programamos un sistema de información en egeasy, tendremos que crearnos una colección (Véase [[Colecciones]]) para almacenar inicialmente los contenedores creados por la aplicación STE al iniciar un trámite, para luego posteriormente mover ese contenedor a su lugar dentro de alguna colección dentro de un expediente.

=Estado de un trámite=
Los trámites en la aplicación web STE, tienen estado. El estado de un trámite acabado de iniciar pero no enviado, tiene el valor de ''borrador''. Una vez enviado su primera tarea del trámite, este pasa a tener el valor de ''En trámite''. Por último cuando el trámite ha finalizado en la plataforma egeasy, el trámite pasa a tener el estado de ''finalizado''. Estos valores comentados para el estado de un trámite, es el comportamiento por defecto de la aplicación web STE. Si queremos cambiar el estado de un trámite debemos hacerlo mediante el atributo '''estado''' y su mecanismo para controlarlo, el cual vamos a proceder a explicarlo a continuación.

Para poder modificar el estado de un tramite durante la vida del ''workflow'' asociado al trámite, debemos crearnos un campo en el contenedor que es ''maintarget'' del ''workflow''. Una vez creado ese campo, debemos hacer una exportación de ese campo en alguna colección de nuestra elección. Si hay alguna duda sobre como crear una exportación, véase [[Exportaciones]]. Con la exportación del campo creada, debemos poner en el atributo '''estado''' del trámite, una ristra con el nombre de la tabla en la base de datos seguida de un punto y a continuación el nombre de la columna que representa el campo en la exportación. Para que quede mas claro, vamos a ver un ejemplo:

Esto seria un ejemplo de la exportación creada, donde tenemos un campo llamado en ODL [Estado tramite], el cual se exporta a la tabla de nombre TR$SOLICITUD_TRAMITACION y en la columna ESTADO_TRAMITE.

[EP::Solicitudes de tramitación electrónica] {{PR|es}} exportacion
-{{AT|nombre_tabla}} = {{STR|"TR$SOLICITUD_TRAMITACION"}};
-{{AT|universo}} = [Solicitud de tramitación electrónica para acreditación del profesorado];
{{PR|columna}} [Denominación/Apellidos y nombre]
-{{AT|columna_bd.nombre}} = {{STR|"DENOMINACION"}};
-{{AT|columna_bd}}.{{PR|tipo}} = texto;
-{{AT|origen}} =[Datos generales].[Denominación/Apellidos y nombre];
{{PR|columna}} [C.I.F./N.I.F.]
-{{AT|columna_bd.nombre}} = {{STR|"CIF_NIF"}};
-{{AT|columna_bd}}.{{PR|tipo}} = texto;
-{{AT|origen}} = [Datos generales].[C.I.F./N.I.F.];
{{PR|columna}} [Estado tramite]
-{{AT|columna_bd.nombre}} = {{STR|"ESTADO_TRAMITE"}};
-{{AT|columna_bd}}.{{PR|tipo}} = texto;
-{{AT|origen}} = [Datos generales].[Estado tramite];
{{PR|fin}}

A continuación un ejemplo de como se declararía un trámite utilizando el atributo '''estado'''.

[Trámite de Acreditación del profesorado] {{PR|es}} tramite
-{{AT|descripcion}}='Procedimiento de tramitación para la aceditación del profesorado para la ACECAU';
-{{AT|grupo}}='Trámites Acecau';
-{{AT|Habitacion}}=[Oficina de evaluación del profesorado];
-{{AT|estado}}={{STR|"TR$SOLTRAMI_ACRE_PROF.ESTADO_TRAMITE"}};

Una vez declarado el atributo estado en el trámite, ya podemos proceder a modificar el estado de un trámite mediante código de método, del lenguaje ODL. Para ello solo debemos acceder al campo mediante código ODL, al campo que representa el estado en el contenedor que es ''maintarget'' del ''workflow'' asociado al trámite y asignarle el valor deseado que queremos que se muestre en la aplicación web del STE.

NOTA: PONER EJEMPLO DE UN METODO ASIGNADOLE UN VALOR AL CAMPO ESTADO

=Atributos especiales para los campos de ODL=
Junto con la aplicación web STE disponemos para el lenguaje ODL, de unos atributos especiales aplicables a la definición de componentes para poder definir ciertos aspectos del comportamiento de los componentes que interactuan con la aplicación web STE. A continuación listaremos y definiremos los atributos que ha añadido el STE al lenguage ODL.

'''tramitacion.visible'''

Atributo que permite ocultar un campo para que no se visualice en la aplicación web del STE pero si en la plataforma egeasy. Este atributo es aplicable a todos los campos de ODL. El valor por defecto para este atributo es verdadero.

'''tramitacion.requerida'''

Atributo que permite especificar que campos son de obligada cumplimentación por parte del usuario
para la aplicación web del STE. El valor por defecto para este atributo es falso. Este atributo se puede usar en combinación con las validaciones de ODL para indicar como se debe cumplimentar un campo.

'''tramitacion.valor'''

Atributo que permite establecer el valor del campo al que se le aplica el atributo.

'''tramitacion.editable'''

Atributo que permite indicar si el campo es editable o no. El valor por defecto para este atributo es verdadero.


=Formulario de registro de usuarios=
En la aplicación web STE, podemos crear a nuestra medida un formulario de registro de usuarios, donde podemos definir los campos que queremos que el usuario cumplimente al darse de alta para poder utilizar la aplicación web STE. El fichero donde se definen los campos del regostro es un fichero XML y se llama '''registration.xml'''.

A continuación mostramos un ejemplo de un fichero de registro.
<?xml version="1.0" encoding="ISO-8859-1"?>
<registration_form>
<field_value Field_Name="Género" Field_Type="ftString">
<allowed_values>
<item>Masculino</item>
<item>Femenino</item>
</allowed_values>
</field_value>
<field_value Field_Name="Teléfono 1" Field_Type="ftString">
</field_value>
<field_value Field_Name="Teléfono 2" Field_Type="ftString">
</field_value>
<field_value Field_Name="Dirección" Field_Type="ftString">
</field_value>
<field_value Field_Name="Código postal" Field_Type="ftString">
</field_value>
<field_value Field_Name="Localidad" Field_Type="ftString">
</field_value>
<field_value Field_Name="Provincia" Field_Type="ftString">
</field_value>
<field_value Field_Name="Fax" Field_Type="ftString">
</field_value>
</registration_form>

[[Category:Tramitación electrónica]]

Desarrollar con el STE

2009-08-03T14:14:11Z

Imhernandez: /* ¿Que es un trámite? */

__TOC__
=¿Que es un trámite?=
Un trámite es la definición del conjunto de tareas, pertenecientes al ''workflow'', que van a interactuar con la aplicación web STE. Los trámites definidos están orientados a ser iniciados por el usuario desde la aplicación web, para que, a continuación, se inicie un proceso de ''workflow'' programado en ODL para la plataforma egeasy.
==Como se define un trámite==
Para definir un trámite tenemos que indicar el nombre del trámite y declararlo como tipo trámite. La sintaxis de un trámite sería la siguiente.

[Nombre del trámite] es tramite
-ATRIBUTOS
incluye TAREA
.
.
.
incluye TAREA
fin
==Atributos de un trámite==
Los atributos que podemos declarar para un trámite son los siguientes:
*'''descripcion''': Proporciona un texto descriptivo sobre el trámite que se muestra en la interfaz web al crear el trámite.
*'''grupo''': Indica a qué grupo de declaraciones pertenece el trámite.
*'''habitacion''': Indica en qué habitación de nuestro sistema de información queremos que esté disponible el trámite para su realización.
*'''estado''': Indica qué tabla y columna de una exportación va a almacenar el estado de un trámite.

==La clausula incluye==
Dentro de la definición del trámite, debemos especificar cuales son las tareas del ''wordflow'' que queremos que interactuen con el STE, para ello disponemos de la clausula '''incluye'''. Al utilizarla debemos especificar a continuación el nombre de la tarea e indicar una serie de atributos para especificar varios aspectos sobre el comportamiento de la tarea.

===Atributos de incluye===
Los atributos aplicables a las tareas que incluimos en un trámite pueden variar dependiendo del valor del atributo ''tipo'', por ejemplo los atributos de respuesta, solo son aplicables a las tareas con el valor en el atributo tipo igual a REQUERIMIENTO. Dicho esto, a continuación pasamos a listar los distintos atributos aplicables a la clausula incluye, que son los siguientes:

*'''Etiqueta''': Atributo que permite establecer el nombre que va a tener la tarea en la aplicación web del STE.

*'''Tipo''': Atributo que indica que tipo de comportamiento que va a tener la tarea. Los distintos valores que acepta este atributo son: INICIO, REQUERIMIENTO, NOTIFICACION y ENVIO_DOCUMENTACION.

*'''respuesta.etiqueta''': Atributo que indica que nombre va a tener la tarea respuesta correspondiente

*'''respuesta.descripcion''': Atributo para indicar una descripción sobre la tarea respuesta.

*'''respuesta.formulario''': Atributo para indicar el nombre del formulario, perteneciente al ''target'' de la tarea de tipo REQUERIMIENTO, que se va a mostrar en la tarea de respuesta.

*'''respuesta.clasificador''': Atributo para indicar el nombre del clasificador, perteneciente al ''target'' de la tarea de tipo REQUERIMIENTO, donde se van a guardar los documentos que se pueden adjuntar a una tarea respuesta, perteneciente a una tarea de tipo REQUERIMIENTO.

===Diferentes tipos de tareas===
En la aplicación web STE, una misma tarea de nuestro sistema de información se puede comportar de diferentes maneras, dependiendo de que valor tenga el atributo ''tipo'' al incluir una tarea al trámite.

'''Tareas de INICIO'''
Es aquella tarea que indica cual es la tarea que va a ser el inicio del trámite. En un trámite solo puede haber una tarea de tipo inicio. Esta tarea debe ser definida íntegramente como un proceso en ODL.

incluye [Tramitación de solicitud de becas]
-{{AT|Tipo}}=INICIO;
-{{AT|Etiqueta}}='Tramitación de solicitud de becas universitarias';

'''Tareas de REQUERIMIENTO'''
Son aquellas tareas donde ademas de mostrar información, queremos dar al usuario la posibilidad de responder a la tarea mostrada para rellenar un formulario o adjuntar alguna documentación requerida.

incluye [Esperar respuesta de requerimiento de documentación]
-{{AT|Tipo}}=REQUERIMIENTO;
-{{AT|Etiqueta}}='Respuesta al requerimiento de solicitud de becas universitarias';
-{{AT|respuesta.etiqueta}} = {{STR|"Responder al requerimiento"}};
-{{AT|respuesta.descripcion}} = {{STR|"Adjunte todo lo solicitado en el documento enviado"}};
-{{AT|respuesta.formulario}} = [Respuesta];
-{{AT|respuesta.clasificador}} = [Documentos adjuntos];

'''Tareas de NOTIFICACION'''
Son aquellas tareas donde solo se le va a permitir al usuario del STE observar la información que ha sido mandada desde la plataforma egeasy, donde no podrá ni enviar información, ni modificar la información mandada. Este tipo de tareas suele estar reservados para aquellos datos que son de notificación, como las resoluciones.

incluye [Notificar resolución de la solicitud de beca universitaria]
-{{AT|Tipo}}=NOTIFICACION;
-{{AT|Etiqueta}}='Darse por notificado de la resolución de la solicitud de beca universitaria';

'''Tareas de ENVIO_DOCUMENTACION'''
Son aquellas tareas fuera del ''workflow'' que permiten al usuario de la aplicación web STE enviar documentación. Este tipo de tareas se pueden iniciar en cualquier momento durante la vida del trámite.

incluye [Registrar aporte de documentación al trámite]
-{{AT|Tipo}}=ENVIO_DOCUMENTACION;
-{{AT|Etiqueta}}='Aportar documentación adicional al trámite';

=Colecciones=
Para el desarrollo correcto de los tramites en la aplicación web STE, debemos crear al menos una colección para almacenar los contenedores que se crean al iniciar un trámite. Como al definir un tramite, su ''main target'' tiene que ser el contenedor que se mostrará en la web para que el usuario introduzca los datos iniciales para comenzar el ''workflow'' asociado a un trámite y no un expediente como se suele hacer cuando programamos un sistema de información en egeasy, tendremos que crearnos una colección (Véase [[Colecciones]]) para almacenar inicialmente los contenedores creados por la aplicación STE al iniciar un trámite, para luego posteriormente mover ese contenedor a su lugar dentro de alguna colección dentro de un expediente.

=Estado de un trámite=
Los trámites en la aplicación web STE, tienen estado. El estado de un trámite acabado de iniciar pero no enviado, tiene el valor de ''borrador''. Una vez enviado su primera tarea del trámite, este pasa a tener el valor de ''En trámite''. Por último cuando el trámite ha finalizado en la plataforma egeasy, el trámite pasa a tener el estado de ''finalizado''. Estos valores comentados para el estado de un trámite, es el comportamiento por defecto de la aplicación web STE. Si queremos cambiar el estado de un trámite debemos hacerlo mediante el atributo '''estado''' y su mecanismo para controlarlo, el cual vamos a proceder a explicarlo a continuación.

Para poder modificar el estado de un tramite durante la vida del ''workflow'' asociado al trámite, debemos crearnos un campo en el contenedor que es ''maintarget'' del ''workflow''. Una vez creado ese campo, debemos hacer una exportación de ese campo en alguna colección de nuestra elección. Si hay alguna duda sobre como crear una exportación, véase [[Exportaciones]]. Con la exportación del campo creada, debemos poner en el atributo '''estado''' del trámite, una ristra con el nombre de la tabla en la base de datos seguida de un punto y a continuación el nombre de la columna que representa el campo en la exportación. Para que quede mas claro, vamos a ver un ejemplo:

Esto seria un ejemplo de la exportación creada, donde tenemos un campo llamado en ODL [Estado tramite], el cual se exporta a la tabla de nombre TR$SOLICITUD_TRAMITACION y en la columna ESTADO_TRAMITE.

[EP::Solicitudes de tramitación electrónica] {{PR|es}} exportacion
-{{AT|nombre_tabla}} = {{STR|"TR$SOLICITUD_TRAMITACION"}};
-{{AT|universo}} = [Solicitud de tramitación electrónica para acreditación del profesorado];
{{PR|columna}} [Denominación/Apellidos y nombre]
-{{AT|columna_bd.nombre}} = {{STR|"DENOMINACION"}};
-{{AT|columna_bd}}.{{PR|tipo}} = texto;
-{{AT|origen}} =[Datos generales].[Denominación/Apellidos y nombre];
{{PR|columna}} [C.I.F./N.I.F.]
-{{AT|columna_bd.nombre}} = {{STR|"CIF_NIF"}};
-{{AT|columna_bd}}.{{PR|tipo}} = texto;
-{{AT|origen}} = [Datos generales].[C.I.F./N.I.F.];
{{PR|columna}} [Estado tramite]
-{{AT|columna_bd.nombre}} = {{STR|"ESTADO_TRAMITE"}};
-{{AT|columna_bd}}.{{PR|tipo}} = texto;
-{{AT|origen}} = [Datos generales].[Estado tramite];
{{PR|fin}}

A continuación un ejemplo de como se declararía un trámite utilizando el atributo '''estado'''.

[Trámite de Acreditación del profesorado] {{PR|es}} tramite
-{{AT|descripcion}}='Procedimiento de tramitación para la aceditación del profesorado para la ACECAU';
-{{AT|grupo}}='Trámites Acecau';
-{{AT|Habitacion}}=[Oficina de evaluación del profesorado];
-{{AT|estado}}={{STR|"TR$SOLTRAMI_ACRE_PROF.ESTADO_TRAMITE"}};

Una vez declarado el atributo estado en el trámite, ya podemos proceder a modificar el estado de un trámite mediante código de método, del lenguaje ODL. Para ello solo debemos acceder al campo mediante código ODL, al campo que representa el estado en el contenedor que es ''maintarget'' del ''workflow'' asociado al trámite y asignarle el valor deseado que queremos que se muestre en la aplicación web del STE.

NOTA: PONER EJEMPLO DE UN METODO ASIGNADOLE UN VALOR AL CAMPO ESTADO

=Atributos especiales para los campos de ODL=
Junto con la aplicación web STE disponemos para el lenguaje ODL, de unos atributos especiales aplicables a la definición de componentes para poder definir ciertos aspectos del comportamiento de los componentes que interactuan con la aplicación web STE. A continuación listaremos y definiremos los atributos que ha añadido el STE al lenguage ODL.

'''tramitacion.visible'''

Atributo que permite ocultar un campo para que no se visualice en la aplicación web del STE pero si en la plataforma egeasy. Este atributo es aplicable a todos los campos de ODL. El valor por defecto para este atributo es verdadero.

'''tramitacion.requerida'''

Atributo que permite especificar que campos son de obligada cumplimentación por parte del usuario
para la aplicación web del STE. El valor por defecto para este atributo es falso. Este atributo se puede usar en combinación con las validaciones de ODL para indicar como se debe cumplimentar un campo.

'''tramitacion.valor'''

Atributo que permite establecer el valor del campo al que se le aplica el atributo.

'''tramitacion.editable'''

Atributo que permite indicar si el campo es editable o no. El valor por defecto para este atributo es verdadero.


=Formulario de registro de usuarios=
En la aplicación web STE, podemos crear a nuestra medida un formulario de registro de usuarios, donde podemos definir los campos que queremos que el usuario cumplimente al darse de alta para poder utilizar la aplicación web STE. El fichero donde se definen los campos del regostro es un fichero XML y se llama '''registration.xml'''.

A continuación mostramos un ejemplo de un fichero de registro.
<?xml version="1.0" encoding="ISO-8859-1"?>
<registration_form>
<field_value Field_Name="Género" Field_Type="ftString">
<allowed_values>
<item>Masculino</item>
<item>Femenino</item>
</allowed_values>
</field_value>
<field_value Field_Name="Teléfono 1" Field_Type="ftString">
</field_value>
<field_value Field_Name="Teléfono 2" Field_Type="ftString">
</field_value>
<field_value Field_Name="Dirección" Field_Type="ftString">
</field_value>
<field_value Field_Name="Código postal" Field_Type="ftString">
</field_value>
<field_value Field_Name="Localidad" Field_Type="ftString">
</field_value>
<field_value Field_Name="Provincia" Field_Type="ftString">
</field_value>
<field_value Field_Name="Fax" Field_Type="ftString">
</field_value>
</registration_form>

[[Category:Tramitación electrónica]]

Cómo integrar el Sistema de Tramitación Electrónica en egeasy

2009-08-03T14:10:46Z

Imhernandez: /* ¿Y ahora que? */

__TOC__
=Introducción=
Este manual sirve para explicar todos los pasos que hay que dar para integrar el Sistema de Tramitación Electrónica en la plataforma egeasy. Esta explicación no partirá de cero, sino que se supone que ya se tiene instalada la plataforma egeasy, con un centro configurado y desarrollado para su usu cotidiano.

=Requisitos=
Para una correcta integración del Sistema de Tramitación Electrónica vamos a necesitar:
*Servidor web (Apache)
*Servidor de base de datos
*Servidor de Tomcat

=Pasos a seguir=
Para la instalación de la aplicación web del Sistema de Tramitación Electrónica, vamos a disponer de una instalación de la aplicación XAMPP, que nos proporciona de una forma rápida y sencilla las aplicaciones requeridas para una puesta en marcha. Para que las explicaciones de los ficheros de configuración sean lo menos confusas posible, en este articulo vamos a instalar la aplicación XAMPP en ''C:\'', por lo tanto todas las rutas se explicarán desde dicha ruta. Ademas de instalar la aplicación XAMPP, tenemos que instalar el servicio web, el cual lo vamos a instalar para mayor comodidad en ''C:\ste''. Así que todas las explicaciones parten de dicha ruta de instalación.

==Configurar el servidor web, Apache==
Para configurar el servidor Apache, debemos modificar el archivo de configuración, que esta en la ruta ''C:\xampp\apache\conf'' con el nombre de ''httpd.conf''. Al final de dicho fichero debemos poner lo siguiente:

ScriptAlias "/URLALIAS" "''PATHWEBSERVICE''"
<Directory "''PATHWEBSERVICE''">
AllowOverride None
Options ExecCGI
Order allow,deny
Allow from all
</Directory>

'''URLALIAS''': Es la URL que vamos a definir donde va a estar nuestro servicio web. Para este ejemplo usaremos ''tramitacion''.
 '''PATHWEBSERVICE''': Es la ruta física donde está desplegado el servicio web. Para este ejemplo, esa ruta es la siguiente: ''C:/STE/tramitacion/''.

Un ejemplo podría ser el siguiente:

ScriptAlias "/tramitacion" "C:/STE/tramitacion"
<Directory "C:/STE/tramitacion/">
AllowOverride None
Options ExecCGI
Order allow,deny
Allow from all
</Directory>

==Configurar el servicio web STE==
Para configurar el servicio web del Sistema de Tramitación Electrónica, debemos modificar el fichero de configuración llamado ''webservice.ini'', que en nuestro ejemplo está en la ruta ''C:\STE\tramitacion''.

Al abrir el fichero ''webservice.ini'' encontramos las siguiente etiquetas que debemos configurar. Ahora vamos a pasar a explicar detalladamente que son cada una de las etiquetas de este archivo de configuración del servicio web.

*'''SERVER_ADDRESS''': IP donde se publicará el servicio web.
*'''SERVER_PORT''': Puerto donde se publicará el servicio web.
*'''WS_IDENTIFIER''': Identificador del servicio web.
*'''WS_DB_CONNECTION_STRING''': Cadena de conexión a la base de datos, donde se tenemos que poner el nombre de usuario de la base de datos, seguido de una @, a continuación indicamos la ruta de la base de datos, seguido de una @ y por ultimo la contraseña para acceder a la base de datos. En resumen: NOMBREUSUARIO@DIRECCIONBD@CONTRASEÑA
*'''WS_DB_TYPE''': Gestor de base de datos. Posibles valores: SQL Server, Oracle, PostgresSQL, Firebird.
*'''WS_DIRECTORY_DOCUMENTS''': Ruta donde se almacenan los documentos generados por la aplicación.
*'''WS_DIRECTORY_LOGS''': Ruta donde se localizan los logs del servicio web.
*'''WS_FILE_INVALID_WORDS''': Ruta del fichero donde están las palabras que no se van a indexar en la base de datos.
*'''TYPE_REGISTRATION''': Si esta etiqueta está presente, entonces en la aplicacón web los usuarios podrán registrarse libremente. Los valore que admite esta etiqueta es ''Free''.
*'''REGISTRATION_FORM''':Ruta y nombre del archivo xml que se usará para generar el formulario de registro en la aplicación web. Para este ejemplo usaremos el siguiente fichero ''C:\STE\registration.xml''.
*'''EGE_USER_RRC''': Identificador del usuario en la plataforma egeasy, con el que va a acceder la aplicación web a la plataforma. Para un correcto funcionamiento, debemos generar un usuario en la plataforma solo para esta aplicación web.
*'''EGE_CENTER_NAME''':Nombre del centro al que se le va a poner la aplicación web.
*'''EGE_DB_CONNECTION_STRING''': Cadena de conexión a la base de datos, donde se tenemos que poner el nombre de usuario de la base de datos, seguido de una @, a continuación indicamos la ruta de la base de datos, seguido de una @ y por ultimo la contraseña para acceder a la base de datos. En resumen: NOMBREUSUARIO@DIRECCIONBD@CONTRASEÑA
*'''EGE_DB_TYPE''': Nombre del tipo de base de datos que se usa para la plataforma egeasy.

*'''EGE_MODEL_DIRECTORY''': Ruta donde se localiza el modelo del centro de la plataforma egeasy.
*'''EGE_DOCUMENT_DIRECTORY''': Ruta donde se localizan la base documental de la plataforma egeasy.
*'''EGE_REGISTRY_DIRECTORY''': Ruta donde se localizan los registro de la plataforma egeasy.

Un ejemplo de un fichero de configuración, podría ser el siguiente:
SERVER_ADDRESS=10.22.144.178
SERVER_PORT=10000
WS_IDENTIFIER=WS_STE
WS_DB_CONNECTION_STRING=usuario@servidorBD@contraseña
WS_DB_TYPE=Oracle
WS_DIRECTORY_DOCUMENTS=C:\STE\Docs
WS_DIRECTORY_LOGS=C:\STE\Logs
WS_FILE_INVALID_WORDS=C:\STE\palabras.dat
TYPE_REGISTRATION=Free
REGISTRATION_FORM=C:\STE\registration.xml
EGE_USER_RRC=3825
EGE_CENTER_NAME=Acecau STE Oracle
EGE_DB_CONNECTION_STRING=usuario@servidorBD@contraseña
EGE_DB_TYPE=Oracle
EGE_MODEL_DIRECTORY=S:\Entornos 2002\Banzai\Modelos\ACECAU STEMod
EGE_DOCUMENT_DIRECTORY=S:\Entornos 2002\Banzai\Documentos\AcecauSTEDoc
EGE_REGISTRY_DIRECTORY=S:\Entornos 2002\Banzai\Registro\acecausteReg

==Configurar la aplicación web STE==

Para configurar la aplicación web del Sistema de Tramitación Electrónica, debemos modificar el fichero de configuración llamado ste.conf, que en este ejemplo se encuentra en C:\xampp\tomcat\webapps\ste\WebContent\WEB-INF\classes\org\siani\ste\configuration.

Al abrir el fichero ste.conf encontramos las siguiente etiquetas que debemos configurar. Ahora vamos a pasar a explicar detalladamente que son cada una de las etiquetas de este archivo de configuración del servicio web.

*'''SITE_DIR''': Ruta donde se encuentra instalada la aplicación web.
*'''SITE_URL''': URL donde se encuentra la aplicación web.
*'''LOG_DIR''': Ruta donde se encuentran los logs de la aplicación web.
*'''DATA_DIR''': Ruta donde se encuentra los datos variables de la aplicación web.
*'''TEMPLATES_DIR''': Ruta donde se encuentra las plantillas html de visualización.
*'''TEMP_DIR''': Ruta donde se encuentra los archivos subidos por los usuarios temporalmente.
*'''SITE_DATA_DEFINITIONS_DIR''': Ruta donde se encuentran las definiciones datos personalizados.
*'''SITE_FORMS_DIR''': Ruta donde se encuentra las vistas personalizadas de los trámites.
*'''SITE_PORT''': Puerto que usa la aplicación web.
*'''API_URL''': URL del servlet, llamado API que usa la aplicación web.
*'''SITE_IMAGES_DIR''': Ruta donde se encuentran las imagenes de la aplicación web.
*'''SITE_IMAGES_URL''': URL donde se encuentran las imagenes de la aplicación web.
*'''SITE_JAVASCRIPT_DIR''': Ruta donde se encuentran el javascript de la aplicación web.
*'''SITE_JAVASCRIPT_URL''': URL donde se encuentran el javascript de la aplicación web.
*'''SITE_STYLES_DIR''': Ruta donde se encuentran los estilos CSS de la aplicación web.
*'''SITE_STYLES_URL''': URL donde se encuentran los estilos CSS de la aplicación web.
*'''WS_SOAP_URL''': URL donde se encuentra el servicio web del STE.
*'''LANG_DIR''': Ruta donde se encuentra los archivos de idioma.
*'''EN = en''': Se define el lenguaje Ingles.
*'''ES = es''': Se define el lenguaje Español.
*'''DEFAULT_LANGUAGE''': Indica que lenguaje se va a usar por defecto en la aplicación.

Un ejemplo del fichero de configuración es(Es necesario que usemos el nombre "steprueba", tal como aparece en el ejemplo, cuando configuremos nuestro fichero):

// DIRECTORIES
SITE_DIR = c:/xampp/tomcat/webapps/ste/WebContent
SITE_URL = http://steprueba
LOG_DIR = C:/xampp/tomcat/webapps/ste/logs
DATA_DIR = C:/xampp/tomcat/webapps/ste/data
TEMPLATES_DIR = C:/xampp/tomcat/webapps/ste/templates
TEMP_DIR = C:/xampp/tomcat/webapps/ste/temp
SITE_PORT = 80
SITE_DATA_DEFINITIONS_DIR = C:/xampp/tomcat/webapps/ste/data/definitions
SITE_FORMS_DIR = C:/xampp/tomcat/webapps/ste/data/definitions/forms
API_URL = http://steprueba/api
SITE_IMAGES_DIR = c:/xampp/tomcat/webapps/ste/WebContent/images
SITE_IMAGES_URL = http://steprueba/images
SITE_JAVASCRIPT_DIR = c:/xampp/tomcat/webapps/ste/WebContent/javascript
SITE_JAVASCRIPT_URL = http://ste/javascript
SITE_STYLES_DIR = c:/xampp/tomcat/webapps/ste/WebContent/styles
SITE_STYLES_URL = http://steprueba/styles
WS_SOAP_URL = http://steprueba/tramitacion/tramitacion_ws_cgi.exe/soap/IEgeWebService
LANG_DIR = C:/xampp/tomcat/webapps/ste/languages
// LANGUAGES
EN = en
ES = es
DEFAULT_LANGUAGE = es

==Configurar el DNS==
Debemos preparar nuestra maquina indicando, mediante un nombre de dominio, dónde está situado el Sistema de Tramitación Electrónica. En nuestro caso, el sistema está instalado en local, por lo que sólo debemos ir a la ruta ''C:\WINDOWS\system32\drivers\etc\'' de nuestro equipo e introducir lo siguiente en el fichero ''hosts'':

127.0.0.1 steprueba

==Creación de tablas en la base de datos==
Para la implantación del Sistema de Tramitación Electrónica, se deben crear unas cuantas tablas e índices en la base de datos. En este ejemplo vamos a utilizar la misma base de datos y esquema donde tenemos implantada ya la plataforma egeasy. A continuación, se listarán los script con las sentencias SQL que hay que ejecutar en la base de datos para generar todo lo necesario para el Sistema de Tramitación Electrónica. Disponemos de los script tanto para SQL-Server como para Oracle.

*Script para base de datos en SQL-Server
CREATE TABLE WS$USERS
(ID NUMERIC(10) PRIMARY KEY,
NIF VARCHAR(10),
NAME VARCHAR(50),
FULLNAME VARCHAR(50),
EMAIL VARCHAR(50),
FORM IMAGE);
CREATE TABLE WS$PROCESSES
(ID NUMERIC(10) PRIMARY KEY,
LABEL VARCHAR(100),
TRAMITATION_STATUS VARCHAR(100),
ID_PROCEDURE NUMERIC(10),
ID_USER NUMERIC(10),
STATUS NUMERIC(1),
CREATE_DATE DATETIME,
START_DATE DATETIME,
END_DATE DATETIME,
LAST_READ_DATE DATETIME);
CREATE TABLE WS$TASKS
(ID NUMERIC(10) PRIMARY KEY,
ID_PROCESS NUMERIC(10),
ID_EGE NUMERIC(10),
ID_DEFINITION NUMERIC(10),
CREATE_RECEIVE_DATE DATETIME,
SEND_RESPONSE_DATE DATETIME,
STATUS NUMERIC(1),
RESPONSE_TO NUMERIC(10),
CONTENT IMAGE);
CREATE TABLE WS$TASK_SIGNATURES
(ID NUMERIC(10) PRIMARY KEY,
SIGNATURE IMAGE);
CREATE TABLE WS$TASK_SNAPSHOTS
(ID NUMERIC(10) PRIMARY KEY,
SNAPSHOT IMAGE);
CREATE TABLE WS$FILES
(ID NUMERIC(10),
ID_TASK NUMERIC(10),
ID_EGE NUMERIC(10),
ATTACH_DATE DATETIME,
SOURCE NUMERIC(1),
FILE_NAME VARCHAR(50));
CREATE TABLE EG$SEQUENCES
(NAME VARCHAR(50),
SUBSEQUENCE VARCHAR(50),
CURRENT_VALUE NUMERIC(10));
CREATE TABLE WSI$WORDS
(ID NUMERIC(10),
CAPTION VARCHAR(15));
CREATE INDEX IEGI$WORDS#CAP ON WSI$WORDS (CAPTION);
CREATE TABLE WSI$INDEX
(ID_WORD NUMERIC(10),
ID_PROCESS NUMERIC(10),
ID_TASK NUMERIC(10));
CREATE INDEX IEGI$INDEX#WRD ON WSI$INDEX(ID_WORD);

*Script para base de datos en Oracle
CREATE TABLE WS$USERS
(ID NUMBER(10) PRIMARY KEY,
NIF VARCHAR2(10),
NAME VARCHAR2(50),
FULLNAME VARCHAR2(50),
EMAIL VARCHAR2(50),
FORM LONG RAW);
CREATE TABLE WS$PROCESSES
(ID NUMBER(10) PRIMARY KEY,
LABEL VARCHAR2(100),
TRAMITATION_STATUS VARCHAR2(100),
ID_PROCEDURE NUMBER(10),
ID_USER NUMBER(10),
STATUS NUMBER(1),
CREATE_DATE DATE,
START_DATE DATE,
END_DATE DATE,
LAST_READ_DATE DATE);
CREATE TABLE WS$TASKS
(ID NUMBER(10) PRIMARY KEY,
ID_PROCESS NUMBER(10),
ID_EGE NUMBER(10),
ID_DEFINITION NUMBER(10),
CREATE_RECEIVE_DATE DATE,
SEND_RESPONSE_DATE DATE,
STATUS NUMBER(1),
RESPONSE_TO NUMBER(10),
CONTENT LONG RAW);
CREATE TABLE WS$TASK_SIGNATURES
(ID NUMBER(10) PRIMARY KEY,
SIGNATURE LONG RAW);
CREATE TABLE WS$TASK_SNAPSHOTS
(ID NUMBER(10) PRIMARY KEY,
SNAPSHOT LONG RAW);
CREATE TABLE WS$FILES
(ID NUMBER(10),
ID_TASK NUMBER(10),
ID_EGE NUMBER(10),
ATTACH_DATE DATE,
SOURCE NUMBER(1),
FILE_NAME VARCHAR2(50));
CREATE TABLE EG$SEQUENCES
(NAME VARCHAR2(50),
SUBSEQUENCE VARCHAR2(50),
CURRENT_VALUE NUMBER(10));
CREATE TABLE WSI$WORDS
(ID NUMBER(10),
CAPTION VARCHAR2(15));
CREATE INDEX IEGI$WORDS#CAP ON WSI$WORDS (CAPTION);
CREATE TABLE WSI$INDEX
(ID_WORD NUMBER(10),
ID_PROCESS NUMBER(10),
ID_TASK NUMBER(10));
CREATE INDEX IEGI$INDEX#WRD ON WSI$INDEX(ID_WORD);

==Arrancar el Sistema de Tramitación Electrónica==
Para iniciar el Sistema de Tramitación Electrónica debemos iniciar una series de aplicaciones en un cierto orden. Las aplicaciones que debemos iniciar y cómo se listan a continuación.
*'''XAMPP'''
Para iniciar el XAMPP, debemos ir a la ruta donde lo tenemos instalado, en este caso ''c:\xampp'', y ejecutar el archivo con nombre ''xampp-control.exe''.
*'''Servidor de Apache'''
Una vez abierto el panel de control del XAMPP, debemos hacer clic en el botón ''start'' para el Apache.
*'''Tomcat'''
Para iniciar el Tomcat, debemos ir a la ruta ''c:\xampp'' y ejecutar el archivo de procesos por lotes (.bat) con nombre ''tomcat_start.bat''.
*'''Servicio web del Sistema de Tramitación Electrónica'''
Para iniciar el servicio web, debemos ir a la ruta donde se instaló. Para este ejemplo, debemos ir a la carpeta tramitación, con ruta ''C:\STE\tramitacion'', y ejecutar el archivo de procesos por lotes con nombre ''lanzar.bat''.
El archivo ''lanzar.bat'' contiene el comando de consola que hay que ejecutar para iniciar el servicio web. Este comando se compone de la ruta y el nombre del archivo ''Tramitacion_server.exe'' y el argumento que se le pasa al ejecutable, el cual es la ruta donde está el archivo de configuración del servicio web. Para este ejemplo el archivo ''lanzar.bat'' contiene lo siguiente.
"c:\STE\tramitacion\Tramitacion_server.exe" "c:\STE\tramitacion\webservice.ini"
Una vez arrancada todas las aplicaciones, sólo nos queda ir al navegador e introducir la URL que definimos en los ficheros de configuración para acceder al servicio de tramitación electrónica. En este ejemplo debemos introducir ''http://steprueba''

=¿Y ahora que?=
Una vez completados todos estos pasos, ya disponemos en nuestra máquina del Sistema de Tramitación Electrónica. A continuación, ya podemos pasar a desarrollar en la plataforma egeasy para hacer que el centro del que se disponga haga uso del Sistema de Tramitación Electrónica. Le invito a seguir leyendo el siguiente artículo: [[Desarrollar con el STE]]

[[Category:Tramitación electrónica]]

Cómo integrar el Sistema de Tramitación Electrónica en egeasy

2009-08-03T14:09:35Z

Imhernandez: /* Arrancar el Sistema de Tramitación Electrónica */

__TOC__
=Introducción=
Este manual sirve para explicar todos los pasos que hay que dar para integrar el Sistema de Tramitación Electrónica en la plataforma egeasy. Esta explicación no partirá de cero, sino que se supone que ya se tiene instalada la plataforma egeasy, con un centro configurado y desarrollado para su usu cotidiano.

=Requisitos=
Para una correcta integración del Sistema de Tramitación Electrónica vamos a necesitar:
*Servidor web (Apache)
*Servidor de base de datos
*Servidor de Tomcat

=Pasos a seguir=
Para la instalación de la aplicación web del Sistema de Tramitación Electrónica, vamos a disponer de una instalación de la aplicación XAMPP, que nos proporciona de una forma rápida y sencilla las aplicaciones requeridas para una puesta en marcha. Para que las explicaciones de los ficheros de configuración sean lo menos confusas posible, en este articulo vamos a instalar la aplicación XAMPP en ''C:\'', por lo tanto todas las rutas se explicarán desde dicha ruta. Ademas de instalar la aplicación XAMPP, tenemos que instalar el servicio web, el cual lo vamos a instalar para mayor comodidad en ''C:\ste''. Así que todas las explicaciones parten de dicha ruta de instalación.

==Configurar el servidor web, Apache==
Para configurar el servidor Apache, debemos modificar el archivo de configuración, que esta en la ruta ''C:\xampp\apache\conf'' con el nombre de ''httpd.conf''. Al final de dicho fichero debemos poner lo siguiente:

ScriptAlias "/URLALIAS" "''PATHWEBSERVICE''"
<Directory "''PATHWEBSERVICE''">
AllowOverride None
Options ExecCGI
Order allow,deny
Allow from all
</Directory>

'''URLALIAS''': Es la URL que vamos a definir donde va a estar nuestro servicio web. Para este ejemplo usaremos ''tramitacion''.
 '''PATHWEBSERVICE''': Es la ruta física donde está desplegado el servicio web. Para este ejemplo, esa ruta es la siguiente: ''C:/STE/tramitacion/''.

Un ejemplo podría ser el siguiente:

ScriptAlias "/tramitacion" "C:/STE/tramitacion"
<Directory "C:/STE/tramitacion/">
AllowOverride None
Options ExecCGI
Order allow,deny
Allow from all
</Directory>

==Configurar el servicio web STE==
Para configurar el servicio web del Sistema de Tramitación Electrónica, debemos modificar el fichero de configuración llamado ''webservice.ini'', que en nuestro ejemplo está en la ruta ''C:\STE\tramitacion''.

Al abrir el fichero ''webservice.ini'' encontramos las siguiente etiquetas que debemos configurar. Ahora vamos a pasar a explicar detalladamente que son cada una de las etiquetas de este archivo de configuración del servicio web.

*'''SERVER_ADDRESS''': IP donde se publicará el servicio web.
*'''SERVER_PORT''': Puerto donde se publicará el servicio web.
*'''WS_IDENTIFIER''': Identificador del servicio web.
*'''WS_DB_CONNECTION_STRING''': Cadena de conexión a la base de datos, donde se tenemos que poner el nombre de usuario de la base de datos, seguido de una @, a continuación indicamos la ruta de la base de datos, seguido de una @ y por ultimo la contraseña para acceder a la base de datos. En resumen: NOMBREUSUARIO@DIRECCIONBD@CONTRASEÑA
*'''WS_DB_TYPE''': Gestor de base de datos. Posibles valores: SQL Server, Oracle, PostgresSQL, Firebird.
*'''WS_DIRECTORY_DOCUMENTS''': Ruta donde se almacenan los documentos generados por la aplicación.
*'''WS_DIRECTORY_LOGS''': Ruta donde se localizan los logs del servicio web.
*'''WS_FILE_INVALID_WORDS''': Ruta del fichero donde están las palabras que no se van a indexar en la base de datos.
*'''TYPE_REGISTRATION''': Si esta etiqueta está presente, entonces en la aplicacón web los usuarios podrán registrarse libremente. Los valore que admite esta etiqueta es ''Free''.
*'''REGISTRATION_FORM''':Ruta y nombre del archivo xml que se usará para generar el formulario de registro en la aplicación web. Para este ejemplo usaremos el siguiente fichero ''C:\STE\registration.xml''.
*'''EGE_USER_RRC''': Identificador del usuario en la plataforma egeasy, con el que va a acceder la aplicación web a la plataforma. Para un correcto funcionamiento, debemos generar un usuario en la plataforma solo para esta aplicación web.
*'''EGE_CENTER_NAME''':Nombre del centro al que se le va a poner la aplicación web.
*'''EGE_DB_CONNECTION_STRING''': Cadena de conexión a la base de datos, donde se tenemos que poner el nombre de usuario de la base de datos, seguido de una @, a continuación indicamos la ruta de la base de datos, seguido de una @ y por ultimo la contraseña para acceder a la base de datos. En resumen: NOMBREUSUARIO@DIRECCIONBD@CONTRASEÑA
*'''EGE_DB_TYPE''': Nombre del tipo de base de datos que se usa para la plataforma egeasy.

*'''EGE_MODEL_DIRECTORY''': Ruta donde se localiza el modelo del centro de la plataforma egeasy.
*'''EGE_DOCUMENT_DIRECTORY''': Ruta donde se localizan la base documental de la plataforma egeasy.
*'''EGE_REGISTRY_DIRECTORY''': Ruta donde se localizan los registro de la plataforma egeasy.

Un ejemplo de un fichero de configuración, podría ser el siguiente:
SERVER_ADDRESS=10.22.144.178
SERVER_PORT=10000
WS_IDENTIFIER=WS_STE
WS_DB_CONNECTION_STRING=usuario@servidorBD@contraseña
WS_DB_TYPE=Oracle
WS_DIRECTORY_DOCUMENTS=C:\STE\Docs
WS_DIRECTORY_LOGS=C:\STE\Logs
WS_FILE_INVALID_WORDS=C:\STE\palabras.dat
TYPE_REGISTRATION=Free
REGISTRATION_FORM=C:\STE\registration.xml
EGE_USER_RRC=3825
EGE_CENTER_NAME=Acecau STE Oracle
EGE_DB_CONNECTION_STRING=usuario@servidorBD@contraseña
EGE_DB_TYPE=Oracle
EGE_MODEL_DIRECTORY=S:\Entornos 2002\Banzai\Modelos\ACECAU STEMod
EGE_DOCUMENT_DIRECTORY=S:\Entornos 2002\Banzai\Documentos\AcecauSTEDoc
EGE_REGISTRY_DIRECTORY=S:\Entornos 2002\Banzai\Registro\acecausteReg

==Configurar la aplicación web STE==

Para configurar la aplicación web del Sistema de Tramitación Electrónica, debemos modificar el fichero de configuración llamado ste.conf, que en este ejemplo se encuentra en C:\xampp\tomcat\webapps\ste\WebContent\WEB-INF\classes\org\siani\ste\configuration.

Al abrir el fichero ste.conf encontramos las siguiente etiquetas que debemos configurar. Ahora vamos a pasar a explicar detalladamente que son cada una de las etiquetas de este archivo de configuración del servicio web.

*'''SITE_DIR''': Ruta donde se encuentra instalada la aplicación web.
*'''SITE_URL''': URL donde se encuentra la aplicación web.
*'''LOG_DIR''': Ruta donde se encuentran los logs de la aplicación web.
*'''DATA_DIR''': Ruta donde se encuentra los datos variables de la aplicación web.
*'''TEMPLATES_DIR''': Ruta donde se encuentra las plantillas html de visualización.
*'''TEMP_DIR''': Ruta donde se encuentra los archivos subidos por los usuarios temporalmente.
*'''SITE_DATA_DEFINITIONS_DIR''': Ruta donde se encuentran las definiciones datos personalizados.
*'''SITE_FORMS_DIR''': Ruta donde se encuentra las vistas personalizadas de los trámites.
*'''SITE_PORT''': Puerto que usa la aplicación web.
*'''API_URL''': URL del servlet, llamado API que usa la aplicación web.
*'''SITE_IMAGES_DIR''': Ruta donde se encuentran las imagenes de la aplicación web.
*'''SITE_IMAGES_URL''': URL donde se encuentran las imagenes de la aplicación web.
*'''SITE_JAVASCRIPT_DIR''': Ruta donde se encuentran el javascript de la aplicación web.
*'''SITE_JAVASCRIPT_URL''': URL donde se encuentran el javascript de la aplicación web.
*'''SITE_STYLES_DIR''': Ruta donde se encuentran los estilos CSS de la aplicación web.
*'''SITE_STYLES_URL''': URL donde se encuentran los estilos CSS de la aplicación web.
*'''WS_SOAP_URL''': URL donde se encuentra el servicio web del STE.
*'''LANG_DIR''': Ruta donde se encuentra los archivos de idioma.
*'''EN = en''': Se define el lenguaje Ingles.
*'''ES = es''': Se define el lenguaje Español.
*'''DEFAULT_LANGUAGE''': Indica que lenguaje se va a usar por defecto en la aplicación.

Un ejemplo del fichero de configuración es(Es necesario que usemos el nombre "steprueba", tal como aparece en el ejemplo, cuando configuremos nuestro fichero):

// DIRECTORIES
SITE_DIR = c:/xampp/tomcat/webapps/ste/WebContent
SITE_URL = http://steprueba
LOG_DIR = C:/xampp/tomcat/webapps/ste/logs
DATA_DIR = C:/xampp/tomcat/webapps/ste/data
TEMPLATES_DIR = C:/xampp/tomcat/webapps/ste/templates
TEMP_DIR = C:/xampp/tomcat/webapps/ste/temp
SITE_PORT = 80
SITE_DATA_DEFINITIONS_DIR = C:/xampp/tomcat/webapps/ste/data/definitions
SITE_FORMS_DIR = C:/xampp/tomcat/webapps/ste/data/definitions/forms
API_URL = http://steprueba/api
SITE_IMAGES_DIR = c:/xampp/tomcat/webapps/ste/WebContent/images
SITE_IMAGES_URL = http://steprueba/images
SITE_JAVASCRIPT_DIR = c:/xampp/tomcat/webapps/ste/WebContent/javascript
SITE_JAVASCRIPT_URL = http://ste/javascript
SITE_STYLES_DIR = c:/xampp/tomcat/webapps/ste/WebContent/styles
SITE_STYLES_URL = http://steprueba/styles
WS_SOAP_URL = http://steprueba/tramitacion/tramitacion_ws_cgi.exe/soap/IEgeWebService
LANG_DIR = C:/xampp/tomcat/webapps/ste/languages
// LANGUAGES
EN = en
ES = es
DEFAULT_LANGUAGE = es

==Configurar el DNS==
Debemos preparar nuestra maquina indicando, mediante un nombre de dominio, dónde está situado el Sistema de Tramitación Electrónica. En nuestro caso, el sistema está instalado en local, por lo que sólo debemos ir a la ruta ''C:\WINDOWS\system32\drivers\etc\'' de nuestro equipo e introducir lo siguiente en el fichero ''hosts'':

127.0.0.1 steprueba

==Creación de tablas en la base de datos==
Para la implantación del Sistema de Tramitación Electrónica, se deben crear unas cuantas tablas e índices en la base de datos. En este ejemplo vamos a utilizar la misma base de datos y esquema donde tenemos implantada ya la plataforma egeasy. A continuación, se listarán los script con las sentencias SQL que hay que ejecutar en la base de datos para generar todo lo necesario para el Sistema de Tramitación Electrónica. Disponemos de los script tanto para SQL-Server como para Oracle.

*Script para base de datos en SQL-Server
CREATE TABLE WS$USERS
(ID NUMERIC(10) PRIMARY KEY,
NIF VARCHAR(10),
NAME VARCHAR(50),
FULLNAME VARCHAR(50),
EMAIL VARCHAR(50),
FORM IMAGE);
CREATE TABLE WS$PROCESSES
(ID NUMERIC(10) PRIMARY KEY,
LABEL VARCHAR(100),
TRAMITATION_STATUS VARCHAR(100),
ID_PROCEDURE NUMERIC(10),
ID_USER NUMERIC(10),
STATUS NUMERIC(1),
CREATE_DATE DATETIME,
START_DATE DATETIME,
END_DATE DATETIME,
LAST_READ_DATE DATETIME);
CREATE TABLE WS$TASKS
(ID NUMERIC(10) PRIMARY KEY,
ID_PROCESS NUMERIC(10),
ID_EGE NUMERIC(10),
ID_DEFINITION NUMERIC(10),
CREATE_RECEIVE_DATE DATETIME,
SEND_RESPONSE_DATE DATETIME,
STATUS NUMERIC(1),
RESPONSE_TO NUMERIC(10),
CONTENT IMAGE);
CREATE TABLE WS$TASK_SIGNATURES
(ID NUMERIC(10) PRIMARY KEY,
SIGNATURE IMAGE);
CREATE TABLE WS$TASK_SNAPSHOTS
(ID NUMERIC(10) PRIMARY KEY,
SNAPSHOT IMAGE);
CREATE TABLE WS$FILES
(ID NUMERIC(10),
ID_TASK NUMERIC(10),
ID_EGE NUMERIC(10),
ATTACH_DATE DATETIME,
SOURCE NUMERIC(1),
FILE_NAME VARCHAR(50));
CREATE TABLE EG$SEQUENCES
(NAME VARCHAR(50),
SUBSEQUENCE VARCHAR(50),
CURRENT_VALUE NUMERIC(10));
CREATE TABLE WSI$WORDS
(ID NUMERIC(10),
CAPTION VARCHAR(15));
CREATE INDEX IEGI$WORDS#CAP ON WSI$WORDS (CAPTION);
CREATE TABLE WSI$INDEX
(ID_WORD NUMERIC(10),
ID_PROCESS NUMERIC(10),
ID_TASK NUMERIC(10));
CREATE INDEX IEGI$INDEX#WRD ON WSI$INDEX(ID_WORD);

*Script para base de datos en Oracle
CREATE TABLE WS$USERS
(ID NUMBER(10) PRIMARY KEY,
NIF VARCHAR2(10),
NAME VARCHAR2(50),
FULLNAME VARCHAR2(50),
EMAIL VARCHAR2(50),
FORM LONG RAW);
CREATE TABLE WS$PROCESSES
(ID NUMBER(10) PRIMARY KEY,
LABEL VARCHAR2(100),
TRAMITATION_STATUS VARCHAR2(100),
ID_PROCEDURE NUMBER(10),
ID_USER NUMBER(10),
STATUS NUMBER(1),
CREATE_DATE DATE,
START_DATE DATE,
END_DATE DATE,
LAST_READ_DATE DATE);
CREATE TABLE WS$TASKS
(ID NUMBER(10) PRIMARY KEY,
ID_PROCESS NUMBER(10),
ID_EGE NUMBER(10),
ID_DEFINITION NUMBER(10),
CREATE_RECEIVE_DATE DATE,
SEND_RESPONSE_DATE DATE,
STATUS NUMBER(1),
RESPONSE_TO NUMBER(10),
CONTENT LONG RAW);
CREATE TABLE WS$TASK_SIGNATURES
(ID NUMBER(10) PRIMARY KEY,
SIGNATURE LONG RAW);
CREATE TABLE WS$TASK_SNAPSHOTS
(ID NUMBER(10) PRIMARY KEY,
SNAPSHOT LONG RAW);
CREATE TABLE WS$FILES
(ID NUMBER(10),
ID_TASK NUMBER(10),
ID_EGE NUMBER(10),
ATTACH_DATE DATE,
SOURCE NUMBER(1),
FILE_NAME VARCHAR2(50));
CREATE TABLE EG$SEQUENCES
(NAME VARCHAR2(50),
SUBSEQUENCE VARCHAR2(50),
CURRENT_VALUE NUMBER(10));
CREATE TABLE WSI$WORDS
(ID NUMBER(10),
CAPTION VARCHAR2(15));
CREATE INDEX IEGI$WORDS#CAP ON WSI$WORDS (CAPTION);
CREATE TABLE WSI$INDEX
(ID_WORD NUMBER(10),
ID_PROCESS NUMBER(10),
ID_TASK NUMBER(10));
CREATE INDEX IEGI$INDEX#WRD ON WSI$INDEX(ID_WORD);

==Arrancar el Sistema de Tramitación Electrónica==
Para iniciar el Sistema de Tramitación Electrónica debemos iniciar una series de aplicaciones en un cierto orden. Las aplicaciones que debemos iniciar y cómo se listan a continuación.
*'''XAMPP'''
Para iniciar el XAMPP, debemos ir a la ruta donde lo tenemos instalado, en este caso ''c:\xampp'', y ejecutar el archivo con nombre ''xampp-control.exe''.
*'''Servidor de Apache'''
Una vez abierto el panel de control del XAMPP, debemos hacer clic en el botón ''start'' para el Apache.
*'''Tomcat'''
Para iniciar el Tomcat, debemos ir a la ruta ''c:\xampp'' y ejecutar el archivo de procesos por lotes (.bat) con nombre ''tomcat_start.bat''.
*'''Servicio web del Sistema de Tramitación Electrónica'''
Para iniciar el servicio web, debemos ir a la ruta donde se instaló. Para este ejemplo, debemos ir a la carpeta tramitación, con ruta ''C:\STE\tramitacion'', y ejecutar el archivo de procesos por lotes con nombre ''lanzar.bat''.
El archivo ''lanzar.bat'' contiene el comando de consola que hay que ejecutar para iniciar el servicio web. Este comando se compone de la ruta y el nombre del archivo ''Tramitacion_server.exe'' y el argumento que se le pasa al ejecutable, el cual es la ruta donde está el archivo de configuración del servicio web. Para este ejemplo el archivo ''lanzar.bat'' contiene lo siguiente.
"c:\STE\tramitacion\Tramitacion_server.exe" "c:\STE\tramitacion\webservice.ini"
Una vez arrancada todas las aplicaciones, sólo nos queda ir al navegador e introducir la URL que definimos en los ficheros de configuración para acceder al servicio de tramitación electrónica. En este ejemplo debemos introducir ''http://steprueba''

=¿Y ahora que?=
Una vez completados todos estos pasos, ya disponemos en nuestra maquina del Sistema de Tramitación Electrónica. A continuación ya podemos pasar a desarrollar en la plataforma egeasy, para hacer que el centro del que disponga haga uso del Sistema de Tramitación Electrónica. Le invito a seguir leyendo el siguiente artículo: [[Desarrollar con el STE]]

[[Category:Tramitación electrónica]]

Cómo integrar el Sistema de Tramitación Electrónica en egeasy

2009-08-03T14:03:10Z

Imhernandez: /* Creación de tablas en la base de datos */

__TOC__
=Introducción=
Este manual sirve para explicar todos los pasos que hay que dar para integrar el Sistema de Tramitación Electrónica en la plataforma egeasy. Esta explicación no partirá de cero, sino que se supone que ya se tiene instalada la plataforma egeasy, con un centro configurado y desarrollado para su usu cotidiano.

=Requisitos=
Para una correcta integración del Sistema de Tramitación Electrónica vamos a necesitar:
*Servidor web (Apache)
*Servidor de base de datos
*Servidor de Tomcat

=Pasos a seguir=
Para la instalación de la aplicación web del Sistema de Tramitación Electrónica, vamos a disponer de una instalación de la aplicación XAMPP, que nos proporciona de una forma rápida y sencilla las aplicaciones requeridas para una puesta en marcha. Para que las explicaciones de los ficheros de configuración sean lo menos confusas posible, en este articulo vamos a instalar la aplicación XAMPP en ''C:\'', por lo tanto todas las rutas se explicarán desde dicha ruta. Ademas de instalar la aplicación XAMPP, tenemos que instalar el servicio web, el cual lo vamos a instalar para mayor comodidad en ''C:\ste''. Así que todas las explicaciones parten de dicha ruta de instalación.

==Configurar el servidor web, Apache==
Para configurar el servidor Apache, debemos modificar el archivo de configuración, que esta en la ruta ''C:\xampp\apache\conf'' con el nombre de ''httpd.conf''. Al final de dicho fichero debemos poner lo siguiente:

ScriptAlias "/URLALIAS" "''PATHWEBSERVICE''"
<Directory "''PATHWEBSERVICE''">
AllowOverride None
Options ExecCGI
Order allow,deny
Allow from all
</Directory>

'''URLALIAS''': Es la URL que vamos a definir donde va a estar nuestro servicio web. Para este ejemplo usaremos ''tramitacion''.
 '''PATHWEBSERVICE''': Es la ruta física donde está desplegado el servicio web. Para este ejemplo, esa ruta es la siguiente: ''C:/STE/tramitacion/''.

Un ejemplo podría ser el siguiente:

ScriptAlias "/tramitacion" "C:/STE/tramitacion"
<Directory "C:/STE/tramitacion/">
AllowOverride None
Options ExecCGI
Order allow,deny
Allow from all
</Directory>

==Configurar el servicio web STE==
Para configurar el servicio web del Sistema de Tramitación Electrónica, debemos modificar el fichero de configuración llamado ''webservice.ini'', que en nuestro ejemplo está en la ruta ''C:\STE\tramitacion''.

Al abrir el fichero ''webservice.ini'' encontramos las siguiente etiquetas que debemos configurar. Ahora vamos a pasar a explicar detalladamente que son cada una de las etiquetas de este archivo de configuración del servicio web.

*'''SERVER_ADDRESS''': IP donde se publicará el servicio web.
*'''SERVER_PORT''': Puerto donde se publicará el servicio web.
*'''WS_IDENTIFIER''': Identificador del servicio web.
*'''WS_DB_CONNECTION_STRING''': Cadena de conexión a la base de datos, donde se tenemos que poner el nombre de usuario de la base de datos, seguido de una @, a continuación indicamos la ruta de la base de datos, seguido de una @ y por ultimo la contraseña para acceder a la base de datos. En resumen: NOMBREUSUARIO@DIRECCIONBD@CONTRASEÑA
*'''WS_DB_TYPE''': Gestor de base de datos. Posibles valores: SQL Server, Oracle, PostgresSQL, Firebird.
*'''WS_DIRECTORY_DOCUMENTS''': Ruta donde se almacenan los documentos generados por la aplicación.
*'''WS_DIRECTORY_LOGS''': Ruta donde se localizan los logs del servicio web.
*'''WS_FILE_INVALID_WORDS''': Ruta del fichero donde están las palabras que no se van a indexar en la base de datos.
*'''TYPE_REGISTRATION''': Si esta etiqueta está presente, entonces en la aplicacón web los usuarios podrán registrarse libremente. Los valore que admite esta etiqueta es ''Free''.
*'''REGISTRATION_FORM''':Ruta y nombre del archivo xml que se usará para generar el formulario de registro en la aplicación web. Para este ejemplo usaremos el siguiente fichero ''C:\STE\registration.xml''.
*'''EGE_USER_RRC''': Identificador del usuario en la plataforma egeasy, con el que va a acceder la aplicación web a la plataforma. Para un correcto funcionamiento, debemos generar un usuario en la plataforma solo para esta aplicación web.
*'''EGE_CENTER_NAME''':Nombre del centro al que se le va a poner la aplicación web.
*'''EGE_DB_CONNECTION_STRING''': Cadena de conexión a la base de datos, donde se tenemos que poner el nombre de usuario de la base de datos, seguido de una @, a continuación indicamos la ruta de la base de datos, seguido de una @ y por ultimo la contraseña para acceder a la base de datos. En resumen: NOMBREUSUARIO@DIRECCIONBD@CONTRASEÑA
*'''EGE_DB_TYPE''': Nombre del tipo de base de datos que se usa para la plataforma egeasy.

*'''EGE_MODEL_DIRECTORY''': Ruta donde se localiza el modelo del centro de la plataforma egeasy.
*'''EGE_DOCUMENT_DIRECTORY''': Ruta donde se localizan la base documental de la plataforma egeasy.
*'''EGE_REGISTRY_DIRECTORY''': Ruta donde se localizan los registro de la plataforma egeasy.

Un ejemplo de un fichero de configuración, podría ser el siguiente:
SERVER_ADDRESS=10.22.144.178
SERVER_PORT=10000
WS_IDENTIFIER=WS_STE
WS_DB_CONNECTION_STRING=usuario@servidorBD@contraseña
WS_DB_TYPE=Oracle
WS_DIRECTORY_DOCUMENTS=C:\STE\Docs
WS_DIRECTORY_LOGS=C:\STE\Logs
WS_FILE_INVALID_WORDS=C:\STE\palabras.dat
TYPE_REGISTRATION=Free
REGISTRATION_FORM=C:\STE\registration.xml
EGE_USER_RRC=3825
EGE_CENTER_NAME=Acecau STE Oracle
EGE_DB_CONNECTION_STRING=usuario@servidorBD@contraseña
EGE_DB_TYPE=Oracle
EGE_MODEL_DIRECTORY=S:\Entornos 2002\Banzai\Modelos\ACECAU STEMod
EGE_DOCUMENT_DIRECTORY=S:\Entornos 2002\Banzai\Documentos\AcecauSTEDoc
EGE_REGISTRY_DIRECTORY=S:\Entornos 2002\Banzai\Registro\acecausteReg

==Configurar la aplicación web STE==

Para configurar la aplicación web del Sistema de Tramitación Electrónica, debemos modificar el fichero de configuración llamado ste.conf, que en este ejemplo se encuentra en C:\xampp\tomcat\webapps\ste\WebContent\WEB-INF\classes\org\siani\ste\configuration.

Al abrir el fichero ste.conf encontramos las siguiente etiquetas que debemos configurar. Ahora vamos a pasar a explicar detalladamente que son cada una de las etiquetas de este archivo de configuración del servicio web.

*'''SITE_DIR''': Ruta donde se encuentra instalada la aplicación web.
*'''SITE_URL''': URL donde se encuentra la aplicación web.
*'''LOG_DIR''': Ruta donde se encuentran los logs de la aplicación web.
*'''DATA_DIR''': Ruta donde se encuentra los datos variables de la aplicación web.
*'''TEMPLATES_DIR''': Ruta donde se encuentra las plantillas html de visualización.
*'''TEMP_DIR''': Ruta donde se encuentra los archivos subidos por los usuarios temporalmente.
*'''SITE_DATA_DEFINITIONS_DIR''': Ruta donde se encuentran las definiciones datos personalizados.
*'''SITE_FORMS_DIR''': Ruta donde se encuentra las vistas personalizadas de los trámites.
*'''SITE_PORT''': Puerto que usa la aplicación web.
*'''API_URL''': URL del servlet, llamado API que usa la aplicación web.
*'''SITE_IMAGES_DIR''': Ruta donde se encuentran las imagenes de la aplicación web.
*'''SITE_IMAGES_URL''': URL donde se encuentran las imagenes de la aplicación web.
*'''SITE_JAVASCRIPT_DIR''': Ruta donde se encuentran el javascript de la aplicación web.
*'''SITE_JAVASCRIPT_URL''': URL donde se encuentran el javascript de la aplicación web.
*'''SITE_STYLES_DIR''': Ruta donde se encuentran los estilos CSS de la aplicación web.
*'''SITE_STYLES_URL''': URL donde se encuentran los estilos CSS de la aplicación web.
*'''WS_SOAP_URL''': URL donde se encuentra el servicio web del STE.
*'''LANG_DIR''': Ruta donde se encuentra los archivos de idioma.
*'''EN = en''': Se define el lenguaje Ingles.
*'''ES = es''': Se define el lenguaje Español.
*'''DEFAULT_LANGUAGE''': Indica que lenguaje se va a usar por defecto en la aplicación.

Un ejemplo del fichero de configuración es(Es necesario que usemos el nombre "steprueba", tal como aparece en el ejemplo, cuando configuremos nuestro fichero):

// DIRECTORIES
SITE_DIR = c:/xampp/tomcat/webapps/ste/WebContent
SITE_URL = http://steprueba
LOG_DIR = C:/xampp/tomcat/webapps/ste/logs
DATA_DIR = C:/xampp/tomcat/webapps/ste/data
TEMPLATES_DIR = C:/xampp/tomcat/webapps/ste/templates
TEMP_DIR = C:/xampp/tomcat/webapps/ste/temp
SITE_PORT = 80
SITE_DATA_DEFINITIONS_DIR = C:/xampp/tomcat/webapps/ste/data/definitions
SITE_FORMS_DIR = C:/xampp/tomcat/webapps/ste/data/definitions/forms
API_URL = http://steprueba/api
SITE_IMAGES_DIR = c:/xampp/tomcat/webapps/ste/WebContent/images
SITE_IMAGES_URL = http://steprueba/images
SITE_JAVASCRIPT_DIR = c:/xampp/tomcat/webapps/ste/WebContent/javascript
SITE_JAVASCRIPT_URL = http://ste/javascript
SITE_STYLES_DIR = c:/xampp/tomcat/webapps/ste/WebContent/styles
SITE_STYLES_URL = http://steprueba/styles
WS_SOAP_URL = http://steprueba/tramitacion/tramitacion_ws_cgi.exe/soap/IEgeWebService
LANG_DIR = C:/xampp/tomcat/webapps/ste/languages
// LANGUAGES
EN = en
ES = es
DEFAULT_LANGUAGE = es

==Configurar el DNS==
Debemos preparar nuestra maquina indicando, mediante un nombre de dominio, dónde está situado el Sistema de Tramitación Electrónica. En nuestro caso, el sistema está instalado en local, por lo que sólo debemos ir a la ruta ''C:\WINDOWS\system32\drivers\etc\'' de nuestro equipo e introducir lo siguiente en el fichero ''hosts'':

127.0.0.1 steprueba

==Creación de tablas en la base de datos==
Para la implantación del Sistema de Tramitación Electrónica, se deben crear unas cuantas tablas e índices en la base de datos. En este ejemplo vamos a utilizar la misma base de datos y esquema donde tenemos implantada ya la plataforma egeasy. A continuación, se listarán los script con las sentencias SQL que hay que ejecutar en la base de datos para generar todo lo necesario para el Sistema de Tramitación Electrónica. Disponemos de los script tanto para SQL-Server como para Oracle.

*Script para base de datos en SQL-Server
CREATE TABLE WS$USERS
(ID NUMERIC(10) PRIMARY KEY,
NIF VARCHAR(10),
NAME VARCHAR(50),
FULLNAME VARCHAR(50),
EMAIL VARCHAR(50),
FORM IMAGE);
CREATE TABLE WS$PROCESSES
(ID NUMERIC(10) PRIMARY KEY,
LABEL VARCHAR(100),
TRAMITATION_STATUS VARCHAR(100),
ID_PROCEDURE NUMERIC(10),
ID_USER NUMERIC(10),
STATUS NUMERIC(1),
CREATE_DATE DATETIME,
START_DATE DATETIME,
END_DATE DATETIME,
LAST_READ_DATE DATETIME);
CREATE TABLE WS$TASKS
(ID NUMERIC(10) PRIMARY KEY,
ID_PROCESS NUMERIC(10),
ID_EGE NUMERIC(10),
ID_DEFINITION NUMERIC(10),
CREATE_RECEIVE_DATE DATETIME,
SEND_RESPONSE_DATE DATETIME,
STATUS NUMERIC(1),
RESPONSE_TO NUMERIC(10),
CONTENT IMAGE);
CREATE TABLE WS$TASK_SIGNATURES
(ID NUMERIC(10) PRIMARY KEY,
SIGNATURE IMAGE);
CREATE TABLE WS$TASK_SNAPSHOTS
(ID NUMERIC(10) PRIMARY KEY,
SNAPSHOT IMAGE);
CREATE TABLE WS$FILES
(ID NUMERIC(10),
ID_TASK NUMERIC(10),
ID_EGE NUMERIC(10),
ATTACH_DATE DATETIME,
SOURCE NUMERIC(1),
FILE_NAME VARCHAR(50));
CREATE TABLE EG$SEQUENCES
(NAME VARCHAR(50),
SUBSEQUENCE VARCHAR(50),
CURRENT_VALUE NUMERIC(10));
CREATE TABLE WSI$WORDS
(ID NUMERIC(10),
CAPTION VARCHAR(15));
CREATE INDEX IEGI$WORDS#CAP ON WSI$WORDS (CAPTION);
CREATE TABLE WSI$INDEX
(ID_WORD NUMERIC(10),
ID_PROCESS NUMERIC(10),
ID_TASK NUMERIC(10));
CREATE INDEX IEGI$INDEX#WRD ON WSI$INDEX(ID_WORD);

*Script para base de datos en Oracle
CREATE TABLE WS$USERS
(ID NUMBER(10) PRIMARY KEY,
NIF VARCHAR2(10),
NAME VARCHAR2(50),
FULLNAME VARCHAR2(50),
EMAIL VARCHAR2(50),
FORM LONG RAW);
CREATE TABLE WS$PROCESSES
(ID NUMBER(10) PRIMARY KEY,
LABEL VARCHAR2(100),
TRAMITATION_STATUS VARCHAR2(100),
ID_PROCEDURE NUMBER(10),
ID_USER NUMBER(10),
STATUS NUMBER(1),
CREATE_DATE DATE,
START_DATE DATE,
END_DATE DATE,
LAST_READ_DATE DATE);
CREATE TABLE WS$TASKS
(ID NUMBER(10) PRIMARY KEY,
ID_PROCESS NUMBER(10),
ID_EGE NUMBER(10),
ID_DEFINITION NUMBER(10),
CREATE_RECEIVE_DATE DATE,
SEND_RESPONSE_DATE DATE,
STATUS NUMBER(1),
RESPONSE_TO NUMBER(10),
CONTENT LONG RAW);
CREATE TABLE WS$TASK_SIGNATURES
(ID NUMBER(10) PRIMARY KEY,
SIGNATURE LONG RAW);
CREATE TABLE WS$TASK_SNAPSHOTS
(ID NUMBER(10) PRIMARY KEY,
SNAPSHOT LONG RAW);
CREATE TABLE WS$FILES
(ID NUMBER(10),
ID_TASK NUMBER(10),
ID_EGE NUMBER(10),
ATTACH_DATE DATE,
SOURCE NUMBER(1),
FILE_NAME VARCHAR2(50));
CREATE TABLE EG$SEQUENCES
(NAME VARCHAR2(50),
SUBSEQUENCE VARCHAR2(50),
CURRENT_VALUE NUMBER(10));
CREATE TABLE WSI$WORDS
(ID NUMBER(10),
CAPTION VARCHAR2(15));
CREATE INDEX IEGI$WORDS#CAP ON WSI$WORDS (CAPTION);
CREATE TABLE WSI$INDEX
(ID_WORD NUMBER(10),
ID_PROCESS NUMBER(10),
ID_TASK NUMBER(10));
CREATE INDEX IEGI$INDEX#WRD ON WSI$INDEX(ID_WORD);

==Arrancar el Sistema de Tramitación Electrónica==
Para iniciar el Sistema de Tramitación Electrónica debemos iniciar una series de aplicaciones en un cierto orden. Las aplicaciones que debemos iniciar y como, se listan a continuación.
*'''XAMPP'''
Para iniciar el XAMPP, debemos ir a la ruta donde lo tenemos instalado, en este caso ''c:\xampp'' y ejecutar el archivo con nombre ''xampp-control.exe''.
*'''Servidor de Apache'''
Una vez abierto el panel de control del XAMPP, debemos hacer clic en el botón ''start'' para el Apache.
*'''Tomcat'''
Para iniciar el Tomcat, debemos ir a la ruta ''c:\xampp'' y ejecutar el archivo de procesos por lotes (.bat) con nombre ''tomcat_start.bat''.
*'''Servicio web del Sistema de Tramitación Electrónica'''
Para iniciar el servicio web, debemos ir a la ruta donde se instaló, para este ejemplo debemos ir a la carpeta tramitacion con ruta ''C:\STE\tramitacion'' y ejecutar el archivo de procesos por lotes con nombre ''lanzar.bat''.
El archivo ''lanzar.bat'' contiene el comando de consola que hay que ejecutar para iniciar el servicio web, este comando se compone por la ruta y el nombre del archivo ''Tramitacion_server.exe'' y el argumento que se le pasa al ejecutable, el cual es la ruta donde esta el archivo de configuración del servicio web. Para este ejemplo el archivo ''lanzar.bat'' contiene lo siguiente.
"c:\STE\tramitacion\Tramitacion_server.exe" "c:\STE\tramitacion\webservice.ini"
Una vez arrancada todas las aplicaciones, solo nos queda ir al navegador y introducir la URL que definimos en los ficheros de condiguración, para acceder al servicio de tramitación electrónica. En este ejemplo debemos introducir ''http://ste''

=¿Y ahora que?=
Una vez completados todos estos pasos, ya disponemos en nuestra maquina del Sistema de Tramitación Electrónica. A continuación ya podemos pasar a desarrollar en la plataforma egeasy, para hacer que el centro del que disponga haga uso del Sistema de Tramitación Electrónica. Le invito a seguir leyendo el siguiente artículo: [[Desarrollar con el STE]]

[[Category:Tramitación electrónica]]

Cómo integrar el Sistema de Tramitación Electrónica en egeasy

2009-08-03T14:00:07Z

Imhernandez: /* Configurar el DNS */

__TOC__
=Introducción=
Este manual sirve para explicar todos los pasos que hay que dar para integrar el Sistema de Tramitación Electrónica en la plataforma egeasy. Esta explicación no partirá de cero, sino que se supone que ya se tiene instalada la plataforma egeasy, con un centro configurado y desarrollado para su usu cotidiano.

=Requisitos=
Para una correcta integración del Sistema de Tramitación Electrónica vamos a necesitar:
*Servidor web (Apache)
*Servidor de base de datos
*Servidor de Tomcat

=Pasos a seguir=
Para la instalación de la aplicación web del Sistema de Tramitación Electrónica, vamos a disponer de una instalación de la aplicación XAMPP, que nos proporciona de una forma rápida y sencilla las aplicaciones requeridas para una puesta en marcha. Para que las explicaciones de los ficheros de configuración sean lo menos confusas posible, en este articulo vamos a instalar la aplicación XAMPP en ''C:\'', por lo tanto todas las rutas se explicarán desde dicha ruta. Ademas de instalar la aplicación XAMPP, tenemos que instalar el servicio web, el cual lo vamos a instalar para mayor comodidad en ''C:\ste''. Así que todas las explicaciones parten de dicha ruta de instalación.

==Configurar el servidor web, Apache==
Para configurar el servidor Apache, debemos modificar el archivo de configuración, que esta en la ruta ''C:\xampp\apache\conf'' con el nombre de ''httpd.conf''. Al final de dicho fichero debemos poner lo siguiente:

ScriptAlias "/URLALIAS" "''PATHWEBSERVICE''"
<Directory "''PATHWEBSERVICE''">
AllowOverride None
Options ExecCGI
Order allow,deny
Allow from all
</Directory>

'''URLALIAS''': Es la URL que vamos a definir donde va a estar nuestro servicio web. Para este ejemplo usaremos ''tramitacion''.
 '''PATHWEBSERVICE''': Es la ruta física donde está desplegado el servicio web. Para este ejemplo, esa ruta es la siguiente: ''C:/STE/tramitacion/''.

Un ejemplo podría ser el siguiente:

ScriptAlias "/tramitacion" "C:/STE/tramitacion"
<Directory "C:/STE/tramitacion/">
AllowOverride None
Options ExecCGI
Order allow,deny
Allow from all
</Directory>

==Configurar el servicio web STE==
Para configurar el servicio web del Sistema de Tramitación Electrónica, debemos modificar el fichero de configuración llamado ''webservice.ini'', que en nuestro ejemplo está en la ruta ''C:\STE\tramitacion''.

Al abrir el fichero ''webservice.ini'' encontramos las siguiente etiquetas que debemos configurar. Ahora vamos a pasar a explicar detalladamente que son cada una de las etiquetas de este archivo de configuración del servicio web.

*'''SERVER_ADDRESS''': IP donde se publicará el servicio web.
*'''SERVER_PORT''': Puerto donde se publicará el servicio web.
*'''WS_IDENTIFIER''': Identificador del servicio web.
*'''WS_DB_CONNECTION_STRING''': Cadena de conexión a la base de datos, donde se tenemos que poner el nombre de usuario de la base de datos, seguido de una @, a continuación indicamos la ruta de la base de datos, seguido de una @ y por ultimo la contraseña para acceder a la base de datos. En resumen: NOMBREUSUARIO@DIRECCIONBD@CONTRASEÑA
*'''WS_DB_TYPE''': Gestor de base de datos. Posibles valores: SQL Server, Oracle, PostgresSQL, Firebird.
*'''WS_DIRECTORY_DOCUMENTS''': Ruta donde se almacenan los documentos generados por la aplicación.
*'''WS_DIRECTORY_LOGS''': Ruta donde se localizan los logs del servicio web.
*'''WS_FILE_INVALID_WORDS''': Ruta del fichero donde están las palabras que no se van a indexar en la base de datos.
*'''TYPE_REGISTRATION''': Si esta etiqueta está presente, entonces en la aplicacón web los usuarios podrán registrarse libremente. Los valore que admite esta etiqueta es ''Free''.
*'''REGISTRATION_FORM''':Ruta y nombre del archivo xml que se usará para generar el formulario de registro en la aplicación web. Para este ejemplo usaremos el siguiente fichero ''C:\STE\registration.xml''.
*'''EGE_USER_RRC''': Identificador del usuario en la plataforma egeasy, con el que va a acceder la aplicación web a la plataforma. Para un correcto funcionamiento, debemos generar un usuario en la plataforma solo para esta aplicación web.
*'''EGE_CENTER_NAME''':Nombre del centro al que se le va a poner la aplicación web.
*'''EGE_DB_CONNECTION_STRING''': Cadena de conexión a la base de datos, donde se tenemos que poner el nombre de usuario de la base de datos, seguido de una @, a continuación indicamos la ruta de la base de datos, seguido de una @ y por ultimo la contraseña para acceder a la base de datos. En resumen: NOMBREUSUARIO@DIRECCIONBD@CONTRASEÑA
*'''EGE_DB_TYPE''': Nombre del tipo de base de datos que se usa para la plataforma egeasy.

*'''EGE_MODEL_DIRECTORY''': Ruta donde se localiza el modelo del centro de la plataforma egeasy.
*'''EGE_DOCUMENT_DIRECTORY''': Ruta donde se localizan la base documental de la plataforma egeasy.
*'''EGE_REGISTRY_DIRECTORY''': Ruta donde se localizan los registro de la plataforma egeasy.

Un ejemplo de un fichero de configuración, podría ser el siguiente:
SERVER_ADDRESS=10.22.144.178
SERVER_PORT=10000
WS_IDENTIFIER=WS_STE
WS_DB_CONNECTION_STRING=usuario@servidorBD@contraseña
WS_DB_TYPE=Oracle
WS_DIRECTORY_DOCUMENTS=C:\STE\Docs
WS_DIRECTORY_LOGS=C:\STE\Logs
WS_FILE_INVALID_WORDS=C:\STE\palabras.dat
TYPE_REGISTRATION=Free
REGISTRATION_FORM=C:\STE\registration.xml
EGE_USER_RRC=3825
EGE_CENTER_NAME=Acecau STE Oracle
EGE_DB_CONNECTION_STRING=usuario@servidorBD@contraseña
EGE_DB_TYPE=Oracle
EGE_MODEL_DIRECTORY=S:\Entornos 2002\Banzai\Modelos\ACECAU STEMod
EGE_DOCUMENT_DIRECTORY=S:\Entornos 2002\Banzai\Documentos\AcecauSTEDoc
EGE_REGISTRY_DIRECTORY=S:\Entornos 2002\Banzai\Registro\acecausteReg

==Configurar la aplicación web STE==

Para configurar la aplicación web del Sistema de Tramitación Electrónica, debemos modificar el fichero de configuración llamado ste.conf, que en este ejemplo se encuentra en C:\xampp\tomcat\webapps\ste\WebContent\WEB-INF\classes\org\siani\ste\configuration.

Al abrir el fichero ste.conf encontramos las siguiente etiquetas que debemos configurar. Ahora vamos a pasar a explicar detalladamente que son cada una de las etiquetas de este archivo de configuración del servicio web.

*'''SITE_DIR''': Ruta donde se encuentra instalada la aplicación web.
*'''SITE_URL''': URL donde se encuentra la aplicación web.
*'''LOG_DIR''': Ruta donde se encuentran los logs de la aplicación web.
*'''DATA_DIR''': Ruta donde se encuentra los datos variables de la aplicación web.
*'''TEMPLATES_DIR''': Ruta donde se encuentra las plantillas html de visualización.
*'''TEMP_DIR''': Ruta donde se encuentra los archivos subidos por los usuarios temporalmente.
*'''SITE_DATA_DEFINITIONS_DIR''': Ruta donde se encuentran las definiciones datos personalizados.
*'''SITE_FORMS_DIR''': Ruta donde se encuentra las vistas personalizadas de los trámites.
*'''SITE_PORT''': Puerto que usa la aplicación web.
*'''API_URL''': URL del servlet, llamado API que usa la aplicación web.
*'''SITE_IMAGES_DIR''': Ruta donde se encuentran las imagenes de la aplicación web.
*'''SITE_IMAGES_URL''': URL donde se encuentran las imagenes de la aplicación web.
*'''SITE_JAVASCRIPT_DIR''': Ruta donde se encuentran el javascript de la aplicación web.
*'''SITE_JAVASCRIPT_URL''': URL donde se encuentran el javascript de la aplicación web.
*'''SITE_STYLES_DIR''': Ruta donde se encuentran los estilos CSS de la aplicación web.
*'''SITE_STYLES_URL''': URL donde se encuentran los estilos CSS de la aplicación web.
*'''WS_SOAP_URL''': URL donde se encuentra el servicio web del STE.
*'''LANG_DIR''': Ruta donde se encuentra los archivos de idioma.
*'''EN = en''': Se define el lenguaje Ingles.
*'''ES = es''': Se define el lenguaje Español.
*'''DEFAULT_LANGUAGE''': Indica que lenguaje se va a usar por defecto en la aplicación.

Un ejemplo del fichero de configuración es(Es necesario que usemos el nombre "steprueba", tal como aparece en el ejemplo, cuando configuremos nuestro fichero):

// DIRECTORIES
SITE_DIR = c:/xampp/tomcat/webapps/ste/WebContent
SITE_URL = http://steprueba
LOG_DIR = C:/xampp/tomcat/webapps/ste/logs
DATA_DIR = C:/xampp/tomcat/webapps/ste/data
TEMPLATES_DIR = C:/xampp/tomcat/webapps/ste/templates
TEMP_DIR = C:/xampp/tomcat/webapps/ste/temp
SITE_PORT = 80
SITE_DATA_DEFINITIONS_DIR = C:/xampp/tomcat/webapps/ste/data/definitions
SITE_FORMS_DIR = C:/xampp/tomcat/webapps/ste/data/definitions/forms
API_URL = http://steprueba/api
SITE_IMAGES_DIR = c:/xampp/tomcat/webapps/ste/WebContent/images
SITE_IMAGES_URL = http://steprueba/images
SITE_JAVASCRIPT_DIR = c:/xampp/tomcat/webapps/ste/WebContent/javascript
SITE_JAVASCRIPT_URL = http://ste/javascript
SITE_STYLES_DIR = c:/xampp/tomcat/webapps/ste/WebContent/styles
SITE_STYLES_URL = http://steprueba/styles
WS_SOAP_URL = http://steprueba/tramitacion/tramitacion_ws_cgi.exe/soap/IEgeWebService
LANG_DIR = C:/xampp/tomcat/webapps/ste/languages
// LANGUAGES
EN = en
ES = es
DEFAULT_LANGUAGE = es

==Configurar el DNS==
Debemos preparar nuestra maquina indicando, mediante un nombre de dominio, dónde está situado el Sistema de Tramitación Electrónica. En nuestro caso, el sistema está instalado en local, por lo que sólo debemos ir a la ruta ''C:\WINDOWS\system32\drivers\etc\'' de nuestro equipo e introducir lo siguiente en el fichero ''hosts'':

127.0.0.1 steprueba

==Creación de tablas en la base de datos==
Para la implantación del Sistema de Tramitación Electrónica, se deben crear unas cuantas tablas y indices en la base de datos. Par este ejemplo vamos a utilizar la misma base de datos y esquema donde tenemos implantada ya la plataforma egeasy. A continuación se listaran los script con las sentencias SQL que hay que ejecutar en la base de datos, para generar todo lo necesario para el Sistema de Tramitación Electrónica. Disponemos de los script tanto para SQL-Server como para Oracle.

*Script para base de datos en SQL-Server
CREATE TABLE WS$USERS
(ID NUMERIC(10) PRIMARY KEY,
NIF VARCHAR(10),
NAME VARCHAR(50),
FULLNAME VARCHAR(50),
EMAIL VARCHAR(50),
FORM IMAGE);
CREATE TABLE WS$PROCESSES
(ID NUMERIC(10) PRIMARY KEY,
LABEL VARCHAR(100),
TRAMITATION_STATUS VARCHAR(100),
ID_PROCEDURE NUMERIC(10),
ID_USER NUMERIC(10),
STATUS NUMERIC(1),
CREATE_DATE DATETIME,
START_DATE DATETIME,
END_DATE DATETIME,
LAST_READ_DATE DATETIME);
CREATE TABLE WS$TASKS
(ID NUMERIC(10) PRIMARY KEY,
ID_PROCESS NUMERIC(10),
ID_EGE NUMERIC(10),
ID_DEFINITION NUMERIC(10),
CREATE_RECEIVE_DATE DATETIME,
SEND_RESPONSE_DATE DATETIME,
STATUS NUMERIC(1),
RESPONSE_TO NUMERIC(10),
CONTENT IMAGE);
CREATE TABLE WS$TASK_SIGNATURES
(ID NUMERIC(10) PRIMARY KEY,
SIGNATURE IMAGE);
CREATE TABLE WS$TASK_SNAPSHOTS
(ID NUMERIC(10) PRIMARY KEY,
SNAPSHOT IMAGE);
CREATE TABLE WS$FILES
(ID NUMERIC(10),
ID_TASK NUMERIC(10),
ID_EGE NUMERIC(10),
ATTACH_DATE DATETIME,
SOURCE NUMERIC(1),
FILE_NAME VARCHAR(50));
CREATE TABLE EG$SEQUENCES
(NAME VARCHAR(50),
SUBSEQUENCE VARCHAR(50),
CURRENT_VALUE NUMERIC(10));
CREATE TABLE WSI$WORDS
(ID NUMERIC(10),
CAPTION VARCHAR(15));
CREATE INDEX IEGI$WORDS#CAP ON WSI$WORDS (CAPTION);
CREATE TABLE WSI$INDEX
(ID_WORD NUMERIC(10),
ID_PROCESS NUMERIC(10),
ID_TASK NUMERIC(10));
CREATE INDEX IEGI$INDEX#WRD ON WSI$INDEX(ID_WORD);

*Script para base de datos en Oracle
CREATE TABLE WS$USERS
(ID NUMBER(10) PRIMARY KEY,
NIF VARCHAR2(10),
NAME VARCHAR2(50),
FULLNAME VARCHAR2(50),
EMAIL VARCHAR2(50),
FORM LONG RAW);
CREATE TABLE WS$PROCESSES
(ID NUMBER(10) PRIMARY KEY,
LABEL VARCHAR2(100),
TRAMITATION_STATUS VARCHAR2(100),
ID_PROCEDURE NUMBER(10),
ID_USER NUMBER(10),
STATUS NUMBER(1),
CREATE_DATE DATE,
START_DATE DATE,
END_DATE DATE,
LAST_READ_DATE DATE);
CREATE TABLE WS$TASKS
(ID NUMBER(10) PRIMARY KEY,
ID_PROCESS NUMBER(10),
ID_EGE NUMBER(10),
ID_DEFINITION NUMBER(10),
CREATE_RECEIVE_DATE DATE,
SEND_RESPONSE_DATE DATE,
STATUS NUMBER(1),
RESPONSE_TO NUMBER(10),
CONTENT LONG RAW);
CREATE TABLE WS$TASK_SIGNATURES
(ID NUMBER(10) PRIMARY KEY,
SIGNATURE LONG RAW);
CREATE TABLE WS$TASK_SNAPSHOTS
(ID NUMBER(10) PRIMARY KEY,
SNAPSHOT LONG RAW);
CREATE TABLE WS$FILES
(ID NUMBER(10),
ID_TASK NUMBER(10),
ID_EGE NUMBER(10),
ATTACH_DATE DATE,
SOURCE NUMBER(1),
FILE_NAME VARCHAR2(50));
CREATE TABLE EG$SEQUENCES
(NAME VARCHAR2(50),
SUBSEQUENCE VARCHAR2(50),
CURRENT_VALUE NUMBER(10));
CREATE TABLE WSI$WORDS
(ID NUMBER(10),
CAPTION VARCHAR2(15));
CREATE INDEX IEGI$WORDS#CAP ON WSI$WORDS (CAPTION);
CREATE TABLE WSI$INDEX
(ID_WORD NUMBER(10),
ID_PROCESS NUMBER(10),
ID_TASK NUMBER(10));
CREATE INDEX IEGI$INDEX#WRD ON WSI$INDEX(ID_WORD);

==Arrancar el Sistema de Tramitación Electrónica==
Para iniciar el Sistema de Tramitación Electrónica debemos iniciar una series de aplicaciones en un cierto orden. Las aplicaciones que debemos iniciar y como, se listan a continuación.
*'''XAMPP'''
Para iniciar el XAMPP, debemos ir a la ruta donde lo tenemos instalado, en este caso ''c:\xampp'' y ejecutar el archivo con nombre ''xampp-control.exe''.
*'''Servidor de Apache'''
Una vez abierto el panel de control del XAMPP, debemos hacer clic en el botón ''start'' para el Apache.
*'''Tomcat'''
Para iniciar el Tomcat, debemos ir a la ruta ''c:\xampp'' y ejecutar el archivo de procesos por lotes (.bat) con nombre ''tomcat_start.bat''.
*'''Servicio web del Sistema de Tramitación Electrónica'''
Para iniciar el servicio web, debemos ir a la ruta donde se instaló, para este ejemplo debemos ir a la carpeta tramitacion con ruta ''C:\STE\tramitacion'' y ejecutar el archivo de procesos por lotes con nombre ''lanzar.bat''.
El archivo ''lanzar.bat'' contiene el comando de consola que hay que ejecutar para iniciar el servicio web, este comando se compone por la ruta y el nombre del archivo ''Tramitacion_server.exe'' y el argumento que se le pasa al ejecutable, el cual es la ruta donde esta el archivo de configuración del servicio web. Para este ejemplo el archivo ''lanzar.bat'' contiene lo siguiente.
"c:\STE\tramitacion\Tramitacion_server.exe" "c:\STE\tramitacion\webservice.ini"
Una vez arrancada todas las aplicaciones, solo nos queda ir al navegador y introducir la URL que definimos en los ficheros de condiguración, para acceder al servicio de tramitación electrónica. En este ejemplo debemos introducir ''http://ste''

=¿Y ahora que?=
Una vez completados todos estos pasos, ya disponemos en nuestra maquina del Sistema de Tramitación Electrónica. A continuación ya podemos pasar a desarrollar en la plataforma egeasy, para hacer que el centro del que disponga haga uso del Sistema de Tramitación Electrónica. Le invito a seguir leyendo el siguiente artículo: [[Desarrollar con el STE]]

[[Category:Tramitación electrónica]]

Cómo integrar el Sistema de Tramitación Electrónica en egeasy

2009-08-03T13:55:19Z

Imhernandez: /* Configurar la aplicación web STE */

__TOC__
=Introducción=
Este manual sirve para explicar todos los pasos que hay que dar para integrar el Sistema de Tramitación Electrónica en la plataforma egeasy. Esta explicación no partirá de cero, sino que se supone que ya se tiene instalada la plataforma egeasy, con un centro configurado y desarrollado para su usu cotidiano.

=Requisitos=
Para una correcta integración del Sistema de Tramitación Electrónica vamos a necesitar:
*Servidor web (Apache)
*Servidor de base de datos
*Servidor de Tomcat

=Pasos a seguir=
Para la instalación de la aplicación web del Sistema de Tramitación Electrónica, vamos a disponer de una instalación de la aplicación XAMPP, que nos proporciona de una forma rápida y sencilla las aplicaciones requeridas para una puesta en marcha. Para que las explicaciones de los ficheros de configuración sean lo menos confusas posible, en este articulo vamos a instalar la aplicación XAMPP en ''C:\'', por lo tanto todas las rutas se explicarán desde dicha ruta. Ademas de instalar la aplicación XAMPP, tenemos que instalar el servicio web, el cual lo vamos a instalar para mayor comodidad en ''C:\ste''. Así que todas las explicaciones parten de dicha ruta de instalación.

==Configurar el servidor web, Apache==
Para configurar el servidor Apache, debemos modificar el archivo de configuración, que esta en la ruta ''C:\xampp\apache\conf'' con el nombre de ''httpd.conf''. Al final de dicho fichero debemos poner lo siguiente:

ScriptAlias "/URLALIAS" "''PATHWEBSERVICE''"
<Directory "''PATHWEBSERVICE''">
AllowOverride None
Options ExecCGI
Order allow,deny
Allow from all
</Directory>

'''URLALIAS''': Es la URL que vamos a definir donde va a estar nuestro servicio web. Para este ejemplo usaremos ''tramitacion''.
 '''PATHWEBSERVICE''': Es la ruta física donde está desplegado el servicio web. Para este ejemplo, esa ruta es la siguiente: ''C:/STE/tramitacion/''.

Un ejemplo podría ser el siguiente:

ScriptAlias "/tramitacion" "C:/STE/tramitacion"
<Directory "C:/STE/tramitacion/">
AllowOverride None
Options ExecCGI
Order allow,deny
Allow from all
</Directory>

==Configurar el servicio web STE==
Para configurar el servicio web del Sistema de Tramitación Electrónica, debemos modificar el fichero de configuración llamado ''webservice.ini'', que en nuestro ejemplo está en la ruta ''C:\STE\tramitacion''.

Al abrir el fichero ''webservice.ini'' encontramos las siguiente etiquetas que debemos configurar. Ahora vamos a pasar a explicar detalladamente que son cada una de las etiquetas de este archivo de configuración del servicio web.

*'''SERVER_ADDRESS''': IP donde se publicará el servicio web.
*'''SERVER_PORT''': Puerto donde se publicará el servicio web.
*'''WS_IDENTIFIER''': Identificador del servicio web.
*'''WS_DB_CONNECTION_STRING''': Cadena de conexión a la base de datos, donde se tenemos que poner el nombre de usuario de la base de datos, seguido de una @, a continuación indicamos la ruta de la base de datos, seguido de una @ y por ultimo la contraseña para acceder a la base de datos. En resumen: NOMBREUSUARIO@DIRECCIONBD@CONTRASEÑA
*'''WS_DB_TYPE''': Gestor de base de datos. Posibles valores: SQL Server, Oracle, PostgresSQL, Firebird.
*'''WS_DIRECTORY_DOCUMENTS''': Ruta donde se almacenan los documentos generados por la aplicación.
*'''WS_DIRECTORY_LOGS''': Ruta donde se localizan los logs del servicio web.
*'''WS_FILE_INVALID_WORDS''': Ruta del fichero donde están las palabras que no se van a indexar en la base de datos.
*'''TYPE_REGISTRATION''': Si esta etiqueta está presente, entonces en la aplicacón web los usuarios podrán registrarse libremente. Los valore que admite esta etiqueta es ''Free''.
*'''REGISTRATION_FORM''':Ruta y nombre del archivo xml que se usará para generar el formulario de registro en la aplicación web. Para este ejemplo usaremos el siguiente fichero ''C:\STE\registration.xml''.
*'''EGE_USER_RRC''': Identificador del usuario en la plataforma egeasy, con el que va a acceder la aplicación web a la plataforma. Para un correcto funcionamiento, debemos generar un usuario en la plataforma solo para esta aplicación web.
*'''EGE_CENTER_NAME''':Nombre del centro al que se le va a poner la aplicación web.
*'''EGE_DB_CONNECTION_STRING''': Cadena de conexión a la base de datos, donde se tenemos que poner el nombre de usuario de la base de datos, seguido de una @, a continuación indicamos la ruta de la base de datos, seguido de una @ y por ultimo la contraseña para acceder a la base de datos. En resumen: NOMBREUSUARIO@DIRECCIONBD@CONTRASEÑA
*'''EGE_DB_TYPE''': Nombre del tipo de base de datos que se usa para la plataforma egeasy.

*'''EGE_MODEL_DIRECTORY''': Ruta donde se localiza el modelo del centro de la plataforma egeasy.
*'''EGE_DOCUMENT_DIRECTORY''': Ruta donde se localizan la base documental de la plataforma egeasy.
*'''EGE_REGISTRY_DIRECTORY''': Ruta donde se localizan los registro de la plataforma egeasy.

Un ejemplo de un fichero de configuración, podría ser el siguiente:
SERVER_ADDRESS=10.22.144.178
SERVER_PORT=10000
WS_IDENTIFIER=WS_STE
WS_DB_CONNECTION_STRING=usuario@servidorBD@contraseña
WS_DB_TYPE=Oracle
WS_DIRECTORY_DOCUMENTS=C:\STE\Docs
WS_DIRECTORY_LOGS=C:\STE\Logs
WS_FILE_INVALID_WORDS=C:\STE\palabras.dat
TYPE_REGISTRATION=Free
REGISTRATION_FORM=C:\STE\registration.xml
EGE_USER_RRC=3825
EGE_CENTER_NAME=Acecau STE Oracle
EGE_DB_CONNECTION_STRING=usuario@servidorBD@contraseña
EGE_DB_TYPE=Oracle
EGE_MODEL_DIRECTORY=S:\Entornos 2002\Banzai\Modelos\ACECAU STEMod
EGE_DOCUMENT_DIRECTORY=S:\Entornos 2002\Banzai\Documentos\AcecauSTEDoc
EGE_REGISTRY_DIRECTORY=S:\Entornos 2002\Banzai\Registro\acecausteReg

==Configurar la aplicación web STE==

Para configurar la aplicación web del Sistema de Tramitación Electrónica, debemos modificar el fichero de configuración llamado ste.conf, que en este ejemplo se encuentra en C:\xampp\tomcat\webapps\ste\WebContent\WEB-INF\classes\org\siani\ste\configuration.

Al abrir el fichero ste.conf encontramos las siguiente etiquetas que debemos configurar. Ahora vamos a pasar a explicar detalladamente que son cada una de las etiquetas de este archivo de configuración del servicio web.

*'''SITE_DIR''': Ruta donde se encuentra instalada la aplicación web.
*'''SITE_URL''': URL donde se encuentra la aplicación web.
*'''LOG_DIR''': Ruta donde se encuentran los logs de la aplicación web.
*'''DATA_DIR''': Ruta donde se encuentra los datos variables de la aplicación web.
*'''TEMPLATES_DIR''': Ruta donde se encuentra las plantillas html de visualización.
*'''TEMP_DIR''': Ruta donde se encuentra los archivos subidos por los usuarios temporalmente.
*'''SITE_DATA_DEFINITIONS_DIR''': Ruta donde se encuentran las definiciones datos personalizados.
*'''SITE_FORMS_DIR''': Ruta donde se encuentra las vistas personalizadas de los trámites.
*'''SITE_PORT''': Puerto que usa la aplicación web.
*'''API_URL''': URL del servlet, llamado API que usa la aplicación web.
*'''SITE_IMAGES_DIR''': Ruta donde se encuentran las imagenes de la aplicación web.
*'''SITE_IMAGES_URL''': URL donde se encuentran las imagenes de la aplicación web.
*'''SITE_JAVASCRIPT_DIR''': Ruta donde se encuentran el javascript de la aplicación web.
*'''SITE_JAVASCRIPT_URL''': URL donde se encuentran el javascript de la aplicación web.
*'''SITE_STYLES_DIR''': Ruta donde se encuentran los estilos CSS de la aplicación web.
*'''SITE_STYLES_URL''': URL donde se encuentran los estilos CSS de la aplicación web.
*'''WS_SOAP_URL''': URL donde se encuentra el servicio web del STE.
*'''LANG_DIR''': Ruta donde se encuentra los archivos de idioma.
*'''EN = en''': Se define el lenguaje Ingles.
*'''ES = es''': Se define el lenguaje Español.
*'''DEFAULT_LANGUAGE''': Indica que lenguaje se va a usar por defecto en la aplicación.

Un ejemplo del fichero de configuración es(Es necesario que usemos el nombre "steprueba", tal como aparece en el ejemplo, cuando configuremos nuestro fichero):

// DIRECTORIES
SITE_DIR = c:/xampp/tomcat/webapps/ste/WebContent
SITE_URL = http://steprueba
LOG_DIR = C:/xampp/tomcat/webapps/ste/logs
DATA_DIR = C:/xampp/tomcat/webapps/ste/data
TEMPLATES_DIR = C:/xampp/tomcat/webapps/ste/templates
TEMP_DIR = C:/xampp/tomcat/webapps/ste/temp
SITE_PORT = 80
SITE_DATA_DEFINITIONS_DIR = C:/xampp/tomcat/webapps/ste/data/definitions
SITE_FORMS_DIR = C:/xampp/tomcat/webapps/ste/data/definitions/forms
API_URL = http://steprueba/api
SITE_IMAGES_DIR = c:/xampp/tomcat/webapps/ste/WebContent/images
SITE_IMAGES_URL = http://steprueba/images
SITE_JAVASCRIPT_DIR = c:/xampp/tomcat/webapps/ste/WebContent/javascript
SITE_JAVASCRIPT_URL = http://ste/javascript
SITE_STYLES_DIR = c:/xampp/tomcat/webapps/ste/WebContent/styles
SITE_STYLES_URL = http://steprueba/styles
WS_SOAP_URL = http://steprueba/tramitacion/tramitacion_ws_cgi.exe/soap/IEgeWebService
LANG_DIR = C:/xampp/tomcat/webapps/ste/languages
// LANGUAGES
EN = en
ES = es
DEFAULT_LANGUAGE = es

==Configurar el DNS==
Debemos preparar nuestra maquina, para indicar mediante un nombre de dominio donde esta situado el Sistema de Tramitación Electrónica, para nuestro caso, el sistema esta instalado en local. Por lo tanto solo debemos ir a la ruta de nuestro equipo donde está el fichero ''hosts'', que esta en ''C:\WINDOWS\system32\drivers\etc\'' e introducir lo siguiente:

127.0.0.1 ste

==Creación de tablas en la base de datos==
Para la implantación del Sistema de Tramitación Electrónica, se deben crear unas cuantas tablas y indices en la base de datos. Par este ejemplo vamos a utilizar la misma base de datos y esquema donde tenemos implantada ya la plataforma egeasy. A continuación se listaran los script con las sentencias SQL que hay que ejecutar en la base de datos, para generar todo lo necesario para el Sistema de Tramitación Electrónica. Disponemos de los script tanto para SQL-Server como para Oracle.

*Script para base de datos en SQL-Server
CREATE TABLE WS$USERS
(ID NUMERIC(10) PRIMARY KEY,
NIF VARCHAR(10),
NAME VARCHAR(50),
FULLNAME VARCHAR(50),
EMAIL VARCHAR(50),
FORM IMAGE);
CREATE TABLE WS$PROCESSES
(ID NUMERIC(10) PRIMARY KEY,
LABEL VARCHAR(100),
TRAMITATION_STATUS VARCHAR(100),
ID_PROCEDURE NUMERIC(10),
ID_USER NUMERIC(10),
STATUS NUMERIC(1),
CREATE_DATE DATETIME,
START_DATE DATETIME,
END_DATE DATETIME,
LAST_READ_DATE DATETIME);
CREATE TABLE WS$TASKS
(ID NUMERIC(10) PRIMARY KEY,
ID_PROCESS NUMERIC(10),
ID_EGE NUMERIC(10),
ID_DEFINITION NUMERIC(10),
CREATE_RECEIVE_DATE DATETIME,
SEND_RESPONSE_DATE DATETIME,
STATUS NUMERIC(1),
RESPONSE_TO NUMERIC(10),
CONTENT IMAGE);
CREATE TABLE WS$TASK_SIGNATURES
(ID NUMERIC(10) PRIMARY KEY,
SIGNATURE IMAGE);
CREATE TABLE WS$TASK_SNAPSHOTS
(ID NUMERIC(10) PRIMARY KEY,
SNAPSHOT IMAGE);
CREATE TABLE WS$FILES
(ID NUMERIC(10),
ID_TASK NUMERIC(10),
ID_EGE NUMERIC(10),
ATTACH_DATE DATETIME,
SOURCE NUMERIC(1),
FILE_NAME VARCHAR(50));
CREATE TABLE EG$SEQUENCES
(NAME VARCHAR(50),
SUBSEQUENCE VARCHAR(50),
CURRENT_VALUE NUMERIC(10));
CREATE TABLE WSI$WORDS
(ID NUMERIC(10),
CAPTION VARCHAR(15));
CREATE INDEX IEGI$WORDS#CAP ON WSI$WORDS (CAPTION);
CREATE TABLE WSI$INDEX
(ID_WORD NUMERIC(10),
ID_PROCESS NUMERIC(10),
ID_TASK NUMERIC(10));
CREATE INDEX IEGI$INDEX#WRD ON WSI$INDEX(ID_WORD);

*Script para base de datos en Oracle
CREATE TABLE WS$USERS
(ID NUMBER(10) PRIMARY KEY,
NIF VARCHAR2(10),
NAME VARCHAR2(50),
FULLNAME VARCHAR2(50),
EMAIL VARCHAR2(50),
FORM LONG RAW);
CREATE TABLE WS$PROCESSES
(ID NUMBER(10) PRIMARY KEY,
LABEL VARCHAR2(100),
TRAMITATION_STATUS VARCHAR2(100),
ID_PROCEDURE NUMBER(10),
ID_USER NUMBER(10),
STATUS NUMBER(1),
CREATE_DATE DATE,
START_DATE DATE,
END_DATE DATE,
LAST_READ_DATE DATE);
CREATE TABLE WS$TASKS
(ID NUMBER(10) PRIMARY KEY,
ID_PROCESS NUMBER(10),
ID_EGE NUMBER(10),
ID_DEFINITION NUMBER(10),
CREATE_RECEIVE_DATE DATE,
SEND_RESPONSE_DATE DATE,
STATUS NUMBER(1),
RESPONSE_TO NUMBER(10),
CONTENT LONG RAW);
CREATE TABLE WS$TASK_SIGNATURES
(ID NUMBER(10) PRIMARY KEY,
SIGNATURE LONG RAW);
CREATE TABLE WS$TASK_SNAPSHOTS
(ID NUMBER(10) PRIMARY KEY,
SNAPSHOT LONG RAW);
CREATE TABLE WS$FILES
(ID NUMBER(10),
ID_TASK NUMBER(10),
ID_EGE NUMBER(10),
ATTACH_DATE DATE,
SOURCE NUMBER(1),
FILE_NAME VARCHAR2(50));
CREATE TABLE EG$SEQUENCES
(NAME VARCHAR2(50),
SUBSEQUENCE VARCHAR2(50),
CURRENT_VALUE NUMBER(10));
CREATE TABLE WSI$WORDS
(ID NUMBER(10),
CAPTION VARCHAR2(15));
CREATE INDEX IEGI$WORDS#CAP ON WSI$WORDS (CAPTION);
CREATE TABLE WSI$INDEX
(ID_WORD NUMBER(10),
ID_PROCESS NUMBER(10),
ID_TASK NUMBER(10));
CREATE INDEX IEGI$INDEX#WRD ON WSI$INDEX(ID_WORD);

==Arrancar el Sistema de Tramitación Electrónica==
Para iniciar el Sistema de Tramitación Electrónica debemos iniciar una series de aplicaciones en un cierto orden. Las aplicaciones que debemos iniciar y como, se listan a continuación.
*'''XAMPP'''
Para iniciar el XAMPP, debemos ir a la ruta donde lo tenemos instalado, en este caso ''c:\xampp'' y ejecutar el archivo con nombre ''xampp-control.exe''.
*'''Servidor de Apache'''
Una vez abierto el panel de control del XAMPP, debemos hacer clic en el botón ''start'' para el Apache.
*'''Tomcat'''
Para iniciar el Tomcat, debemos ir a la ruta ''c:\xampp'' y ejecutar el archivo de procesos por lotes (.bat) con nombre ''tomcat_start.bat''.
*'''Servicio web del Sistema de Tramitación Electrónica'''
Para iniciar el servicio web, debemos ir a la ruta donde se instaló, para este ejemplo debemos ir a la carpeta tramitacion con ruta ''C:\STE\tramitacion'' y ejecutar el archivo de procesos por lotes con nombre ''lanzar.bat''.
El archivo ''lanzar.bat'' contiene el comando de consola que hay que ejecutar para iniciar el servicio web, este comando se compone por la ruta y el nombre del archivo ''Tramitacion_server.exe'' y el argumento que se le pasa al ejecutable, el cual es la ruta donde esta el archivo de configuración del servicio web. Para este ejemplo el archivo ''lanzar.bat'' contiene lo siguiente.
"c:\STE\tramitacion\Tramitacion_server.exe" "c:\STE\tramitacion\webservice.ini"
Una vez arrancada todas las aplicaciones, solo nos queda ir al navegador y introducir la URL que definimos en los ficheros de condiguración, para acceder al servicio de tramitación electrónica. En este ejemplo debemos introducir ''http://ste''

=¿Y ahora que?=
Una vez completados todos estos pasos, ya disponemos en nuestra maquina del Sistema de Tramitación Electrónica. A continuación ya podemos pasar a desarrollar en la plataforma egeasy, para hacer que el centro del que disponga haga uso del Sistema de Tramitación Electrónica. Le invito a seguir leyendo el siguiente artículo: [[Desarrollar con el STE]]

[[Category:Tramitación electrónica]]

Cómo integrar el Sistema de Tramitación Electrónica en egeasy

2009-08-03T13:43:18Z

Imhernandez: /* Configurar la aplicación web STE */

__TOC__
=Introducción=
Este manual sirve para explicar todos los pasos que hay que dar para integrar el Sistema de Tramitación Electrónica en la plataforma egeasy. Esta explicación no partirá de cero, sino que se supone que ya se tiene instalada la plataforma egeasy, con un centro configurado y desarrollado para su usu cotidiano.

=Requisitos=
Para una correcta integración del Sistema de Tramitación Electrónica vamos a necesitar:
*Servidor web (Apache)
*Servidor de base de datos
*Servidor de Tomcat

=Pasos a seguir=
Para la instalación de la aplicación web del Sistema de Tramitación Electrónica, vamos a disponer de una instalación de la aplicación XAMPP, que nos proporciona de una forma rápida y sencilla las aplicaciones requeridas para una puesta en marcha. Para que las explicaciones de los ficheros de configuración sean lo menos confusas posible, en este articulo vamos a instalar la aplicación XAMPP en ''C:\'', por lo tanto todas las rutas se explicarán desde dicha ruta. Ademas de instalar la aplicación XAMPP, tenemos que instalar el servicio web, el cual lo vamos a instalar para mayor comodidad en ''C:\ste''. Así que todas las explicaciones parten de dicha ruta de instalación.

==Configurar el servidor web, Apache==
Para configurar el servidor Apache, debemos modificar el archivo de configuración, que esta en la ruta ''C:\xampp\apache\conf'' con el nombre de ''httpd.conf''. Al final de dicho fichero debemos poner lo siguiente:

ScriptAlias "/URLALIAS" "''PATHWEBSERVICE''"
<Directory "''PATHWEBSERVICE''">
AllowOverride None
Options ExecCGI
Order allow,deny
Allow from all
</Directory>

'''URLALIAS''': Es la URL que vamos a definir donde va a estar nuestro servicio web. Para este ejemplo usaremos ''tramitacion''.
 '''PATHWEBSERVICE''': Es la ruta física donde está desplegado el servicio web. Para este ejemplo, esa ruta es la siguiente: ''C:/STE/tramitacion/''.

Un ejemplo podría ser el siguiente:

ScriptAlias "/tramitacion" "C:/STE/tramitacion"
<Directory "C:/STE/tramitacion/">
AllowOverride None
Options ExecCGI
Order allow,deny
Allow from all
</Directory>

==Configurar el servicio web STE==
Para configurar el servicio web del Sistema de Tramitación Electrónica, debemos modificar el fichero de configuración llamado ''webservice.ini'', que en nuestro ejemplo está en la ruta ''C:\STE\tramitacion''.

Al abrir el fichero ''webservice.ini'' encontramos las siguiente etiquetas que debemos configurar. Ahora vamos a pasar a explicar detalladamente que son cada una de las etiquetas de este archivo de configuración del servicio web.

*'''SERVER_ADDRESS''': IP donde se publicará el servicio web.
*'''SERVER_PORT''': Puerto donde se publicará el servicio web.
*'''WS_IDENTIFIER''': Identificador del servicio web.
*'''WS_DB_CONNECTION_STRING''': Cadena de conexión a la base de datos, donde se tenemos que poner el nombre de usuario de la base de datos, seguido de una @, a continuación indicamos la ruta de la base de datos, seguido de una @ y por ultimo la contraseña para acceder a la base de datos. En resumen: NOMBREUSUARIO@DIRECCIONBD@CONTRASEÑA
*'''WS_DB_TYPE''': Gestor de base de datos. Posibles valores: SQL Server, Oracle, PostgresSQL, Firebird.
*'''WS_DIRECTORY_DOCUMENTS''': Ruta donde se almacenan los documentos generados por la aplicación.
*'''WS_DIRECTORY_LOGS''': Ruta donde se localizan los logs del servicio web.
*'''WS_FILE_INVALID_WORDS''': Ruta del fichero donde están las palabras que no se van a indexar en la base de datos.
*'''TYPE_REGISTRATION''': Si esta etiqueta está presente, entonces en la aplicacón web los usuarios podrán registrarse libremente. Los valore que admite esta etiqueta es ''Free''.
*'''REGISTRATION_FORM''':Ruta y nombre del archivo xml que se usará para generar el formulario de registro en la aplicación web. Para este ejemplo usaremos el siguiente fichero ''C:\STE\registration.xml''.
*'''EGE_USER_RRC''': Identificador del usuario en la plataforma egeasy, con el que va a acceder la aplicación web a la plataforma. Para un correcto funcionamiento, debemos generar un usuario en la plataforma solo para esta aplicación web.
*'''EGE_CENTER_NAME''':Nombre del centro al que se le va a poner la aplicación web.
*'''EGE_DB_CONNECTION_STRING''': Cadena de conexión a la base de datos, donde se tenemos que poner el nombre de usuario de la base de datos, seguido de una @, a continuación indicamos la ruta de la base de datos, seguido de una @ y por ultimo la contraseña para acceder a la base de datos. En resumen: NOMBREUSUARIO@DIRECCIONBD@CONTRASEÑA
*'''EGE_DB_TYPE''': Nombre del tipo de base de datos que se usa para la plataforma egeasy.

*'''EGE_MODEL_DIRECTORY''': Ruta donde se localiza el modelo del centro de la plataforma egeasy.
*'''EGE_DOCUMENT_DIRECTORY''': Ruta donde se localizan la base documental de la plataforma egeasy.
*'''EGE_REGISTRY_DIRECTORY''': Ruta donde se localizan los registro de la plataforma egeasy.

Un ejemplo de un fichero de configuración, podría ser el siguiente:
SERVER_ADDRESS=10.22.144.178
SERVER_PORT=10000
WS_IDENTIFIER=WS_STE
WS_DB_CONNECTION_STRING=usuario@servidorBD@contraseña
WS_DB_TYPE=Oracle
WS_DIRECTORY_DOCUMENTS=C:\STE\Docs
WS_DIRECTORY_LOGS=C:\STE\Logs
WS_FILE_INVALID_WORDS=C:\STE\palabras.dat
TYPE_REGISTRATION=Free
REGISTRATION_FORM=C:\STE\registration.xml
EGE_USER_RRC=3825
EGE_CENTER_NAME=Acecau STE Oracle
EGE_DB_CONNECTION_STRING=usuario@servidorBD@contraseña
EGE_DB_TYPE=Oracle
EGE_MODEL_DIRECTORY=S:\Entornos 2002\Banzai\Modelos\ACECAU STEMod
EGE_DOCUMENT_DIRECTORY=S:\Entornos 2002\Banzai\Documentos\AcecauSTEDoc
EGE_REGISTRY_DIRECTORY=S:\Entornos 2002\Banzai\Registro\acecausteReg

==Configurar la aplicación web STE==

Para configurar la aplicación web del Sistema de Tramitación Electrónica, debemos modificar el fichero de configuración llamado ste.conf, que en este ejemplo se encuentra en C:\xampp\tomcat\webapps\ste\WebContent\WEB-INF\classes\org\siani\ste\configuration.

Al abrir el fichero ste.conf encontramos las siguiente etiquetas que debemos configurar. Ahora vamos a pasar a explicar detalladamente que son cada una de las etiquetas de este archivo de configuración del servicio web.

*'''SITE_DIR''': Ruta donde se encuentra instalada la aplicación web.
*'''SITE_URL''': URL donde se encuentra la aplicación web.
*'''LOG_DIR''': Ruta donde se encuentran los logs de la aplicación web.
*'''DATA_DIR''': Ruta donde se encuentra los datos variables de la aplicación web.
*'''TEMPLATES_DIR''': Ruta donde se encuentra las plantillas html de visualización.
*'''TEMP_DIR''': Ruta donde se encuentra los archivos subidos por los usuarios temporalmente.
*'''SITE_DATA_DEFINITIONS_DIR''': Ruta donde se encuentran las definiciones datos personalizados.
*'''SITE_FORMS_DIR''': Ruta donde se encuentra las vistas personalizadas de los trámites.
*'''SITE_PORT''': Puerto que usa la aplicación web.
*'''API_URL''': URL del servlet, llamado API que usa la aplicación web.
*'''SITE_IMAGES_DIR''': Ruta donde se encuentran las imagenes de la aplicación web.
*'''SITE_IMAGES_URL''': URL donde se encuentran las imagenes de la aplicación web.
*'''SITE_JAVASCRIPT_DIR''': Ruta donde se encuentran el javascript de la aplicación web.
*'''SITE_JAVASCRIPT_URL''': URL donde se encuentran el javascript de la aplicación web.
*'''SITE_STYLES_DIR''': Ruta donde se encuentran los estilos CSS de la aplicación web.
*'''SITE_STYLES_URL''': URL donde se encuentran los estilos CSS de la aplicación web.
*'''WS_SOAP_URL''': URL donde se encuentra el servicio web del STE.
*'''LANG_DIR''': Ruta donde se encuentra los archivos de idioma.
*'''EN = en''': Se define el lenguaje Ingles.
*'''ES = es''': Se define el lenguaje Español.
*'''DEFAULT_LANGUAGE''': Indica que lenguaje se va a usar por defecto en la aplicación.

Un ejemplo del fichero de configuración es:

// DIRECTORIES
SITE_DIR = c:/xampp/tomcat/webapps/ste/WebContent
SITE_URL = http://ste
LOG_DIR = C:/xampp/tomcat/webapps/ste/logs
DATA_DIR = C:/xampp/tomcat/webapps/ste/data
TEMPLATES_DIR = C:/xampp/tomcat/webapps/ste/templates
TEMP_DIR = C:/xampp/tomcat/webapps/ste/temp
SITE_PORT = 80
SITE_DATA_DEFINITIONS_DIR = C:/xampp/tomcat/webapps/ste/data/definitions
SITE_FORMS_DIR = C:/xampp/tomcat/webapps/ste/data/definitions/forms
API_URL = http://ste/api
SITE_IMAGES_DIR = c:/xampp/tomcat/webapps/ste/WebContent/images
SITE_IMAGES_URL = http://ste/images
SITE_JAVASCRIPT_DIR = c:/xampp/tomcat/webapps/ste/WebContent/javascript
SITE_JAVASCRIPT_URL = http://ste/javascript
SITE_STYLES_DIR = c:/xampp/tomcat/webapps/ste/WebContent/styles
SITE_STYLES_URL = http://ste/styles
WS_SOAP_URL = http://ste/tramitacion/tramitacion_ws_cgi.exe/soap/IEgeWebService
LANG_DIR = C:/xampp/tomcat/webapps/ste/languages
// LANGUAGES
EN = en
ES = es
DEFAULT_LANGUAGE = es

==Configurar el DNS==
Debemos preparar nuestra maquina, para indicar mediante un nombre de dominio donde esta situado el Sistema de Tramitación Electrónica, para nuestro caso, el sistema esta instalado en local. Por lo tanto solo debemos ir a la ruta de nuestro equipo donde está el fichero ''hosts'', que esta en ''C:\WINDOWS\system32\drivers\etc\'' e introducir lo siguiente:

127.0.0.1 ste

==Creación de tablas en la base de datos==
Para la implantación del Sistema de Tramitación Electrónica, se deben crear unas cuantas tablas y indices en la base de datos. Par este ejemplo vamos a utilizar la misma base de datos y esquema donde tenemos implantada ya la plataforma egeasy. A continuación se listaran los script con las sentencias SQL que hay que ejecutar en la base de datos, para generar todo lo necesario para el Sistema de Tramitación Electrónica. Disponemos de los script tanto para SQL-Server como para Oracle.

*Script para base de datos en SQL-Server
CREATE TABLE WS$USERS
(ID NUMERIC(10) PRIMARY KEY,
NIF VARCHAR(10),
NAME VARCHAR(50),
FULLNAME VARCHAR(50),
EMAIL VARCHAR(50),
FORM IMAGE);
CREATE TABLE WS$PROCESSES
(ID NUMERIC(10) PRIMARY KEY,
LABEL VARCHAR(100),
TRAMITATION_STATUS VARCHAR(100),
ID_PROCEDURE NUMERIC(10),
ID_USER NUMERIC(10),
STATUS NUMERIC(1),
CREATE_DATE DATETIME,
START_DATE DATETIME,
END_DATE DATETIME,
LAST_READ_DATE DATETIME);
CREATE TABLE WS$TASKS
(ID NUMERIC(10) PRIMARY KEY,
ID_PROCESS NUMERIC(10),
ID_EGE NUMERIC(10),
ID_DEFINITION NUMERIC(10),
CREATE_RECEIVE_DATE DATETIME,
SEND_RESPONSE_DATE DATETIME,
STATUS NUMERIC(1),
RESPONSE_TO NUMERIC(10),
CONTENT IMAGE);
CREATE TABLE WS$TASK_SIGNATURES
(ID NUMERIC(10) PRIMARY KEY,
SIGNATURE IMAGE);
CREATE TABLE WS$TASK_SNAPSHOTS
(ID NUMERIC(10) PRIMARY KEY,
SNAPSHOT IMAGE);
CREATE TABLE WS$FILES
(ID NUMERIC(10),
ID_TASK NUMERIC(10),
ID_EGE NUMERIC(10),
ATTACH_DATE DATETIME,
SOURCE NUMERIC(1),
FILE_NAME VARCHAR(50));
CREATE TABLE EG$SEQUENCES
(NAME VARCHAR(50),
SUBSEQUENCE VARCHAR(50),
CURRENT_VALUE NUMERIC(10));
CREATE TABLE WSI$WORDS
(ID NUMERIC(10),
CAPTION VARCHAR(15));
CREATE INDEX IEGI$WORDS#CAP ON WSI$WORDS (CAPTION);
CREATE TABLE WSI$INDEX
(ID_WORD NUMERIC(10),
ID_PROCESS NUMERIC(10),
ID_TASK NUMERIC(10));
CREATE INDEX IEGI$INDEX#WRD ON WSI$INDEX(ID_WORD);

*Script para base de datos en Oracle
CREATE TABLE WS$USERS
(ID NUMBER(10) PRIMARY KEY,
NIF VARCHAR2(10),
NAME VARCHAR2(50),
FULLNAME VARCHAR2(50),
EMAIL VARCHAR2(50),
FORM LONG RAW);
CREATE TABLE WS$PROCESSES
(ID NUMBER(10) PRIMARY KEY,
LABEL VARCHAR2(100),
TRAMITATION_STATUS VARCHAR2(100),
ID_PROCEDURE NUMBER(10),
ID_USER NUMBER(10),
STATUS NUMBER(1),
CREATE_DATE DATE,
START_DATE DATE,
END_DATE DATE,
LAST_READ_DATE DATE);
CREATE TABLE WS$TASKS
(ID NUMBER(10) PRIMARY KEY,
ID_PROCESS NUMBER(10),
ID_EGE NUMBER(10),
ID_DEFINITION NUMBER(10),
CREATE_RECEIVE_DATE DATE,
SEND_RESPONSE_DATE DATE,
STATUS NUMBER(1),
RESPONSE_TO NUMBER(10),
CONTENT LONG RAW);
CREATE TABLE WS$TASK_SIGNATURES
(ID NUMBER(10) PRIMARY KEY,
SIGNATURE LONG RAW);
CREATE TABLE WS$TASK_SNAPSHOTS
(ID NUMBER(10) PRIMARY KEY,
SNAPSHOT LONG RAW);
CREATE TABLE WS$FILES
(ID NUMBER(10),
ID_TASK NUMBER(10),
ID_EGE NUMBER(10),
ATTACH_DATE DATE,
SOURCE NUMBER(1),
FILE_NAME VARCHAR2(50));
CREATE TABLE EG$SEQUENCES
(NAME VARCHAR2(50),
SUBSEQUENCE VARCHAR2(50),
CURRENT_VALUE NUMBER(10));
CREATE TABLE WSI$WORDS
(ID NUMBER(10),
CAPTION VARCHAR2(15));
CREATE INDEX IEGI$WORDS#CAP ON WSI$WORDS (CAPTION);
CREATE TABLE WSI$INDEX
(ID_WORD NUMBER(10),
ID_PROCESS NUMBER(10),
ID_TASK NUMBER(10));
CREATE INDEX IEGI$INDEX#WRD ON WSI$INDEX(ID_WORD);

==Arrancar el Sistema de Tramitación Electrónica==
Para iniciar el Sistema de Tramitación Electrónica debemos iniciar una series de aplicaciones en un cierto orden. Las aplicaciones que debemos iniciar y como, se listan a continuación.
*'''XAMPP'''
Para iniciar el XAMPP, debemos ir a la ruta donde lo tenemos instalado, en este caso ''c:\xampp'' y ejecutar el archivo con nombre ''xampp-control.exe''.
*'''Servidor de Apache'''
Una vez abierto el panel de control del XAMPP, debemos hacer clic en el botón ''start'' para el Apache.
*'''Tomcat'''
Para iniciar el Tomcat, debemos ir a la ruta ''c:\xampp'' y ejecutar el archivo de procesos por lotes (.bat) con nombre ''tomcat_start.bat''.
*'''Servicio web del Sistema de Tramitación Electrónica'''
Para iniciar el servicio web, debemos ir a la ruta donde se instaló, para este ejemplo debemos ir a la carpeta tramitacion con ruta ''C:\STE\tramitacion'' y ejecutar el archivo de procesos por lotes con nombre ''lanzar.bat''.
El archivo ''lanzar.bat'' contiene el comando de consola que hay que ejecutar para iniciar el servicio web, este comando se compone por la ruta y el nombre del archivo ''Tramitacion_server.exe'' y el argumento que se le pasa al ejecutable, el cual es la ruta donde esta el archivo de configuración del servicio web. Para este ejemplo el archivo ''lanzar.bat'' contiene lo siguiente.
"c:\STE\tramitacion\Tramitacion_server.exe" "c:\STE\tramitacion\webservice.ini"
Una vez arrancada todas las aplicaciones, solo nos queda ir al navegador y introducir la URL que definimos en los ficheros de condiguración, para acceder al servicio de tramitación electrónica. En este ejemplo debemos introducir ''http://ste''

=¿Y ahora que?=
Una vez completados todos estos pasos, ya disponemos en nuestra maquina del Sistema de Tramitación Electrónica. A continuación ya podemos pasar a desarrollar en la plataforma egeasy, para hacer que el centro del que disponga haga uso del Sistema de Tramitación Electrónica. Le invito a seguir leyendo el siguiente artículo: [[Desarrollar con el STE]]

[[Category:Tramitación electrónica]]

Cómo integrar el Sistema de Tramitación Electrónica en egeasy

2009-08-03T13:39:35Z

Imhernandez: /* Configurar el servicio web STE */

__TOC__
=Introducción=
Este manual sirve para explicar todos los pasos que hay que dar para integrar el Sistema de Tramitación Electrónica en la plataforma egeasy. Esta explicación no partirá de cero, sino que se supone que ya se tiene instalada la plataforma egeasy, con un centro configurado y desarrollado para su usu cotidiano.

=Requisitos=
Para una correcta integración del Sistema de Tramitación Electrónica vamos a necesitar:
*Servidor web (Apache)
*Servidor de base de datos
*Servidor de Tomcat

=Pasos a seguir=
Para la instalación de la aplicación web del Sistema de Tramitación Electrónica, vamos a disponer de una instalación de la aplicación XAMPP, que nos proporciona de una forma rápida y sencilla las aplicaciones requeridas para una puesta en marcha. Para que las explicaciones de los ficheros de configuración sean lo menos confusas posible, en este articulo vamos a instalar la aplicación XAMPP en ''C:\'', por lo tanto todas las rutas se explicarán desde dicha ruta. Ademas de instalar la aplicación XAMPP, tenemos que instalar el servicio web, el cual lo vamos a instalar para mayor comodidad en ''C:\ste''. Así que todas las explicaciones parten de dicha ruta de instalación.

==Configurar el servidor web, Apache==
Para configurar el servidor Apache, debemos modificar el archivo de configuración, que esta en la ruta ''C:\xampp\apache\conf'' con el nombre de ''httpd.conf''. Al final de dicho fichero debemos poner lo siguiente:

ScriptAlias "/URLALIAS" "''PATHWEBSERVICE''"
<Directory "''PATHWEBSERVICE''">
AllowOverride None
Options ExecCGI
Order allow,deny
Allow from all
</Directory>

'''URLALIAS''': Es la URL que vamos a definir donde va a estar nuestro servicio web. Para este ejemplo usaremos ''tramitacion''.
 '''PATHWEBSERVICE''': Es la ruta física donde está desplegado el servicio web. Para este ejemplo, esa ruta es la siguiente: ''C:/STE/tramitacion/''.

Un ejemplo podría ser el siguiente:

ScriptAlias "/tramitacion" "C:/STE/tramitacion"
<Directory "C:/STE/tramitacion/">
AllowOverride None
Options ExecCGI
Order allow,deny
Allow from all
</Directory>

==Configurar el servicio web STE==
Para configurar el servicio web del Sistema de Tramitación Electrónica, debemos modificar el fichero de configuración llamado ''webservice.ini'', que en nuestro ejemplo está en la ruta ''C:\STE\tramitacion''.

Al abrir el fichero ''webservice.ini'' encontramos las siguiente etiquetas que debemos configurar. Ahora vamos a pasar a explicar detalladamente que son cada una de las etiquetas de este archivo de configuración del servicio web.

*'''SERVER_ADDRESS''': IP donde se publicará el servicio web.
*'''SERVER_PORT''': Puerto donde se publicará el servicio web.
*'''WS_IDENTIFIER''': Identificador del servicio web.
*'''WS_DB_CONNECTION_STRING''': Cadena de conexión a la base de datos, donde se tenemos que poner el nombre de usuario de la base de datos, seguido de una @, a continuación indicamos la ruta de la base de datos, seguido de una @ y por ultimo la contraseña para acceder a la base de datos. En resumen: NOMBREUSUARIO@DIRECCIONBD@CONTRASEÑA
*'''WS_DB_TYPE''': Gestor de base de datos. Posibles valores: SQL Server, Oracle, PostgresSQL, Firebird.
*'''WS_DIRECTORY_DOCUMENTS''': Ruta donde se almacenan los documentos generados por la aplicación.
*'''WS_DIRECTORY_LOGS''': Ruta donde se localizan los logs del servicio web.
*'''WS_FILE_INVALID_WORDS''': Ruta del fichero donde están las palabras que no se van a indexar en la base de datos.
*'''TYPE_REGISTRATION''': Si esta etiqueta está presente, entonces en la aplicacón web los usuarios podrán registrarse libremente. Los valore que admite esta etiqueta es ''Free''.
*'''REGISTRATION_FORM''':Ruta y nombre del archivo xml que se usará para generar el formulario de registro en la aplicación web. Para este ejemplo usaremos el siguiente fichero ''C:\STE\registration.xml''.
*'''EGE_USER_RRC''': Identificador del usuario en la plataforma egeasy, con el que va a acceder la aplicación web a la plataforma. Para un correcto funcionamiento, debemos generar un usuario en la plataforma solo para esta aplicación web.
*'''EGE_CENTER_NAME''':Nombre del centro al que se le va a poner la aplicación web.
*'''EGE_DB_CONNECTION_STRING''': Cadena de conexión a la base de datos, donde se tenemos que poner el nombre de usuario de la base de datos, seguido de una @, a continuación indicamos la ruta de la base de datos, seguido de una @ y por ultimo la contraseña para acceder a la base de datos. En resumen: NOMBREUSUARIO@DIRECCIONBD@CONTRASEÑA
*'''EGE_DB_TYPE''': Nombre del tipo de base de datos que se usa para la plataforma egeasy.

*'''EGE_MODEL_DIRECTORY''': Ruta donde se localiza el modelo del centro de la plataforma egeasy.
*'''EGE_DOCUMENT_DIRECTORY''': Ruta donde se localizan la base documental de la plataforma egeasy.
*'''EGE_REGISTRY_DIRECTORY''': Ruta donde se localizan los registro de la plataforma egeasy.

Un ejemplo de un fichero de configuración, podría ser el siguiente:
SERVER_ADDRESS=10.22.144.178
SERVER_PORT=10000
WS_IDENTIFIER=WS_STE
WS_DB_CONNECTION_STRING=usuario@servidorBD@contraseña
WS_DB_TYPE=Oracle
WS_DIRECTORY_DOCUMENTS=C:\STE\Docs
WS_DIRECTORY_LOGS=C:\STE\Logs
WS_FILE_INVALID_WORDS=C:\STE\palabras.dat
TYPE_REGISTRATION=Free
REGISTRATION_FORM=C:\STE\registration.xml
EGE_USER_RRC=3825
EGE_CENTER_NAME=Acecau STE Oracle
EGE_DB_CONNECTION_STRING=usuario@servidorBD@contraseña
EGE_DB_TYPE=Oracle
EGE_MODEL_DIRECTORY=S:\Entornos 2002\Banzai\Modelos\ACECAU STEMod
EGE_DOCUMENT_DIRECTORY=S:\Entornos 2002\Banzai\Documentos\AcecauSTEDoc
EGE_REGISTRY_DIRECTORY=S:\Entornos 2002\Banzai\Registro\acecausteReg

==Configurar la aplicación web STE==

Para configurar la aplicación web del Sistema de Tramitación Electrónica, debemos modificar el fichero de configuración llamado ste.conf que esta en la ruta C:\xampp\tomcat\webapps\ste\WebContent\WEB-INF\classes\org\siani\ste\configuration, que para este ejemplo será donde esta instalado.

Al abrir el fichero ste.conf encontramos las siguiente etiquetas que debemos configurar. Ahora vamos a pasar a explicar detalladamente que son cada una de las etiquetas de este archivo de configuración del servicio web.

*'''SITE_DIR''': Ruta donde se encuentra instalada la aplicación web.
*'''SITE_URL''': URL donde se encuentra la aplicación web.
*'''LOG_DIR''': Ruta donde se encuentran los logs de la aplicación web.
*'''DATA_DIR''': Ruta donde se encuentra los datos variables de la aplicación web.
*'''TEMPLATES_DIR''': Ruta donde se encuentra las plantillas html de visualización.
*'''TEMP_DIR''': Ruta donde se encuentra los archivos subidos por los usuarios temporalmente.
*'''SITE_DATA_DEFINITIONS_DIR''': Ruta donde se encuentran las definiciones datos personalizados.
*'''SITE_FORMS_DIR''': Ruta donde se encuentra las vistas personalizadas de los trámites.
*'''SITE_PORT''': Puerto que usa la aplicación web.
*'''API_URL''': URL del servlet, llamado API que usa la aplicación web.
*'''SITE_IMAGES_DIR''': Ruta donde se encuentran las imagenes de la aplicación web.
*'''SITE_IMAGES_URL''': URL donde se encuentran las imagenes de la aplicación web.
*'''SITE_JAVASCRIPT_DIR''': Ruta donde se encuentran el javascript de la aplicación web.
*'''SITE_JAVASCRIPT_URL''': URL donde se encuentran el javascript de la aplicación web.
*'''SITE_STYLES_DIR''': Ruta donde se encuentran los estilos CSS de la aplicación web.
*'''SITE_STYLES_URL''': URL donde se encuentran los estilos CSS de la aplicación web.
*'''WS_SOAP_URL''': URL donde se encuentra el servicio web del STE.
*'''LANG_DIR''': Ruta donde se encuentra los archivos de idioma.
*'''EN = en''': Se define el lenguaje Ingles.
*'''ES = es''': Se define el lenguaje Español.
*'''DEFAULT_LANGUAGE''': Indica que lenguaje se va a usar por defecto en la aplicación.

Un ejemplo del fichero de configuración es:

// DIRECTORIES
SITE_DIR = c:/xampp/tomcat/webapps/ste/WebContent
SITE_URL = http://ste
LOG_DIR = C:/xampp/tomcat/webapps/ste/logs
DATA_DIR = C:/xampp/tomcat/webapps/ste/data
TEMPLATES_DIR = C:/xampp/tomcat/webapps/ste/templates
TEMP_DIR = C:/xampp/tomcat/webapps/ste/temp
SITE_PORT = 80
SITE_DATA_DEFINITIONS_DIR = C:/xampp/tomcat/webapps/ste/data/definitions
SITE_FORMS_DIR = C:/xampp/tomcat/webapps/ste/data/definitions/forms
API_URL = http://ste/api
SITE_IMAGES_DIR = c:/xampp/tomcat/webapps/ste/WebContent/images
SITE_IMAGES_URL = http://ste/images
SITE_JAVASCRIPT_DIR = c:/xampp/tomcat/webapps/ste/WebContent/javascript
SITE_JAVASCRIPT_URL = http://ste/javascript
SITE_STYLES_DIR = c:/xampp/tomcat/webapps/ste/WebContent/styles
SITE_STYLES_URL = http://ste/styles
WS_SOAP_URL = http://ste/tramitacion/tramitacion_ws_cgi.exe/soap/IEgeWebService
LANG_DIR = C:/xampp/tomcat/webapps/ste/languages
// LANGUAGES
EN = en
ES = es
DEFAULT_LANGUAGE = es

==Configurar el DNS==
Debemos preparar nuestra maquina, para indicar mediante un nombre de dominio donde esta situado el Sistema de Tramitación Electrónica, para nuestro caso, el sistema esta instalado en local. Por lo tanto solo debemos ir a la ruta de nuestro equipo donde está el fichero ''hosts'', que esta en ''C:\WINDOWS\system32\drivers\etc\'' e introducir lo siguiente:

127.0.0.1 ste

==Creación de tablas en la base de datos==
Para la implantación del Sistema de Tramitación Electrónica, se deben crear unas cuantas tablas y indices en la base de datos. Par este ejemplo vamos a utilizar la misma base de datos y esquema donde tenemos implantada ya la plataforma egeasy. A continuación se listaran los script con las sentencias SQL que hay que ejecutar en la base de datos, para generar todo lo necesario para el Sistema de Tramitación Electrónica. Disponemos de los script tanto para SQL-Server como para Oracle.

*Script para base de datos en SQL-Server
CREATE TABLE WS$USERS
(ID NUMERIC(10) PRIMARY KEY,
NIF VARCHAR(10),
NAME VARCHAR(50),
FULLNAME VARCHAR(50),
EMAIL VARCHAR(50),
FORM IMAGE);
CREATE TABLE WS$PROCESSES
(ID NUMERIC(10) PRIMARY KEY,
LABEL VARCHAR(100),
TRAMITATION_STATUS VARCHAR(100),
ID_PROCEDURE NUMERIC(10),
ID_USER NUMERIC(10),
STATUS NUMERIC(1),
CREATE_DATE DATETIME,
START_DATE DATETIME,
END_DATE DATETIME,
LAST_READ_DATE DATETIME);
CREATE TABLE WS$TASKS
(ID NUMERIC(10) PRIMARY KEY,
ID_PROCESS NUMERIC(10),
ID_EGE NUMERIC(10),
ID_DEFINITION NUMERIC(10),
CREATE_RECEIVE_DATE DATETIME,
SEND_RESPONSE_DATE DATETIME,
STATUS NUMERIC(1),
RESPONSE_TO NUMERIC(10),
CONTENT IMAGE);
CREATE TABLE WS$TASK_SIGNATURES
(ID NUMERIC(10) PRIMARY KEY,
SIGNATURE IMAGE);
CREATE TABLE WS$TASK_SNAPSHOTS
(ID NUMERIC(10) PRIMARY KEY,
SNAPSHOT IMAGE);
CREATE TABLE WS$FILES
(ID NUMERIC(10),
ID_TASK NUMERIC(10),
ID_EGE NUMERIC(10),
ATTACH_DATE DATETIME,
SOURCE NUMERIC(1),
FILE_NAME VARCHAR(50));
CREATE TABLE EG$SEQUENCES
(NAME VARCHAR(50),
SUBSEQUENCE VARCHAR(50),
CURRENT_VALUE NUMERIC(10));
CREATE TABLE WSI$WORDS
(ID NUMERIC(10),
CAPTION VARCHAR(15));
CREATE INDEX IEGI$WORDS#CAP ON WSI$WORDS (CAPTION);
CREATE TABLE WSI$INDEX
(ID_WORD NUMERIC(10),
ID_PROCESS NUMERIC(10),
ID_TASK NUMERIC(10));
CREATE INDEX IEGI$INDEX#WRD ON WSI$INDEX(ID_WORD);

*Script para base de datos en Oracle
CREATE TABLE WS$USERS
(ID NUMBER(10) PRIMARY KEY,
NIF VARCHAR2(10),
NAME VARCHAR2(50),
FULLNAME VARCHAR2(50),
EMAIL VARCHAR2(50),
FORM LONG RAW);
CREATE TABLE WS$PROCESSES
(ID NUMBER(10) PRIMARY KEY,
LABEL VARCHAR2(100),
TRAMITATION_STATUS VARCHAR2(100),
ID_PROCEDURE NUMBER(10),
ID_USER NUMBER(10),
STATUS NUMBER(1),
CREATE_DATE DATE,
START_DATE DATE,
END_DATE DATE,
LAST_READ_DATE DATE);
CREATE TABLE WS$TASKS
(ID NUMBER(10) PRIMARY KEY,
ID_PROCESS NUMBER(10),
ID_EGE NUMBER(10),
ID_DEFINITION NUMBER(10),
CREATE_RECEIVE_DATE DATE,
SEND_RESPONSE_DATE DATE,
STATUS NUMBER(1),
RESPONSE_TO NUMBER(10),
CONTENT LONG RAW);
CREATE TABLE WS$TASK_SIGNATURES
(ID NUMBER(10) PRIMARY KEY,
SIGNATURE LONG RAW);
CREATE TABLE WS$TASK_SNAPSHOTS
(ID NUMBER(10) PRIMARY KEY,
SNAPSHOT LONG RAW);
CREATE TABLE WS$FILES
(ID NUMBER(10),
ID_TASK NUMBER(10),
ID_EGE NUMBER(10),
ATTACH_DATE DATE,
SOURCE NUMBER(1),
FILE_NAME VARCHAR2(50));
CREATE TABLE EG$SEQUENCES
(NAME VARCHAR2(50),
SUBSEQUENCE VARCHAR2(50),
CURRENT_VALUE NUMBER(10));
CREATE TABLE WSI$WORDS
(ID NUMBER(10),
CAPTION VARCHAR2(15));
CREATE INDEX IEGI$WORDS#CAP ON WSI$WORDS (CAPTION);
CREATE TABLE WSI$INDEX
(ID_WORD NUMBER(10),
ID_PROCESS NUMBER(10),
ID_TASK NUMBER(10));
CREATE INDEX IEGI$INDEX#WRD ON WSI$INDEX(ID_WORD);

==Arrancar el Sistema de Tramitación Electrónica==
Para iniciar el Sistema de Tramitación Electrónica debemos iniciar una series de aplicaciones en un cierto orden. Las aplicaciones que debemos iniciar y como, se listan a continuación.
*'''XAMPP'''
Para iniciar el XAMPP, debemos ir a la ruta donde lo tenemos instalado, en este caso ''c:\xampp'' y ejecutar el archivo con nombre ''xampp-control.exe''.
*'''Servidor de Apache'''
Una vez abierto el panel de control del XAMPP, debemos hacer clic en el botón ''start'' para el Apache.
*'''Tomcat'''
Para iniciar el Tomcat, debemos ir a la ruta ''c:\xampp'' y ejecutar el archivo de procesos por lotes (.bat) con nombre ''tomcat_start.bat''.
*'''Servicio web del Sistema de Tramitación Electrónica'''
Para iniciar el servicio web, debemos ir a la ruta donde se instaló, para este ejemplo debemos ir a la carpeta tramitacion con ruta ''C:\STE\tramitacion'' y ejecutar el archivo de procesos por lotes con nombre ''lanzar.bat''.
El archivo ''lanzar.bat'' contiene el comando de consola que hay que ejecutar para iniciar el servicio web, este comando se compone por la ruta y el nombre del archivo ''Tramitacion_server.exe'' y el argumento que se le pasa al ejecutable, el cual es la ruta donde esta el archivo de configuración del servicio web. Para este ejemplo el archivo ''lanzar.bat'' contiene lo siguiente.
"c:\STE\tramitacion\Tramitacion_server.exe" "c:\STE\tramitacion\webservice.ini"
Una vez arrancada todas las aplicaciones, solo nos queda ir al navegador y introducir la URL que definimos en los ficheros de condiguración, para acceder al servicio de tramitación electrónica. En este ejemplo debemos introducir ''http://ste''

=¿Y ahora que?=
Una vez completados todos estos pasos, ya disponemos en nuestra maquina del Sistema de Tramitación Electrónica. A continuación ya podemos pasar a desarrollar en la plataforma egeasy, para hacer que el centro del que disponga haga uso del Sistema de Tramitación Electrónica. Le invito a seguir leyendo el siguiente artículo: [[Desarrollar con el STE]]

[[Category:Tramitación electrónica]]

Cómo integrar el Sistema de Tramitación Electrónica en egeasy

2009-08-03T13:35:10Z

Imhernandez: /* Pasos a seguir */

__TOC__
=Introducción=
Este manual sirve para explicar todos los pasos que hay que dar para integrar el Sistema de Tramitación Electrónica en la plataforma egeasy. Esta explicación no partirá de cero, sino que se supone que ya se tiene instalada la plataforma egeasy, con un centro configurado y desarrollado para su usu cotidiano.

=Requisitos=
Para una correcta integración del Sistema de Tramitación Electrónica vamos a necesitar:
*Servidor web (Apache)
*Servidor de base de datos
*Servidor de Tomcat

=Pasos a seguir=
Para la instalación de la aplicación web del Sistema de Tramitación Electrónica, vamos a disponer de una instalación de la aplicación XAMPP, que nos proporciona de una forma rápida y sencilla las aplicaciones requeridas para una puesta en marcha. Para que las explicaciones de los ficheros de configuración sean lo menos confusas posible, en este articulo vamos a instalar la aplicación XAMPP en ''C:\'', por lo tanto todas las rutas se explicarán desde dicha ruta. Ademas de instalar la aplicación XAMPP, tenemos que instalar el servicio web, el cual lo vamos a instalar para mayor comodidad en ''C:\ste''. Así que todas las explicaciones parten de dicha ruta de instalación.

==Configurar el servidor web, Apache==
Para configurar el servidor Apache, debemos modificar el archivo de configuración, que esta en la ruta ''C:\xampp\apache\conf'' con el nombre de ''httpd.conf''. Al final de dicho fichero debemos poner lo siguiente:

ScriptAlias "/URLALIAS" "''PATHWEBSERVICE''"
<Directory "''PATHWEBSERVICE''">
AllowOverride None
Options ExecCGI
Order allow,deny
Allow from all
</Directory>

'''URLALIAS''': Es la URL que vamos a definir donde va a estar nuestro servicio web. Para este ejemplo usaremos ''tramitacion''.
 '''PATHWEBSERVICE''': Es la ruta física donde está desplegado el servicio web. Para este ejemplo, esa ruta es la siguiente: ''C:/STE/tramitacion/''.

Un ejemplo podría ser el siguiente:

ScriptAlias "/tramitacion" "C:/STE/tramitacion"
<Directory "C:/STE/tramitacion/">
AllowOverride None
Options ExecCGI
Order allow,deny
Allow from all
</Directory>

==Configurar el servicio web STE==
Para configurar el servicio web del Sistema de Tramitación Electrónica, debemos modificar el fichero de configuración llamado ''webservice.ini'' que esta en la ruta ''C:\STE\tramitacion'', que para este ejemplo será donde esta instalado.

Al abrir el fichero ''webservice.ini'' encontramos las siguiente etiquetas que debemos configurar. Ahora vamos a pasar a explicar detalladamente que son cada una de las etiquetas de este archivo de configuración del servicio web.

*'''SERVER_ADDRESS''': IP donde se publicará el servicio web.
*'''SERVER_PORT''': Puerto donde se publicará el servicio web.
*'''WS_IDENTIFIER''': Identificador del servicio web.
*'''WS_DB_CONNECTION_STRING''': Cadena de conexión a la base de datos, donde se tenemos que poner el nombre de usuario de la base de datos, seguido de una @, a continuación indicamos la ruta de la base de datos, seguido de una @ y por ultimo la contraseña para acceder a la base de datos. En resumen: NOMBREUSUARIO@DIRECCIONBD@CONTRASEÑA
*'''WS_DB_TYPE''': Gestor de base de datos. Posibles valores: SQL Server, Oracle, PostgresSQL, Firebird.
*'''WS_DIRECTORY_DOCUMENTS''': Ruta donde se almacenan los documentos generados por la aplicación.
*'''WS_DIRECTORY_LOGS''': Ruta donde se localizan los logs del servicio web.
*'''WS_FILE_INVALID_WORDS''': Ruta del fichero donde están las palabras que no se van a indexar en la base de datos.
*'''TYPE_REGISTRATION''': Si esta etiqueta está presente, entonces en la aplicacón web los usuarios podrán registrarse libremente. Los valore que admite esta etiqueta es ''Free''.
*'''REGISTRATION_FORM''':Ruta y nombre del archivo xml que se usará para generar el formulario de registro en la aplicación web. Para este ejemplo usaremos el siguiente fichero ''C:\STE\registration.xml''.
*'''EGE_USER_RRC''': Identificador del usuario en la plataforma egeasy, con el que va a acceder la aplicación web a la plataforma. Para un correcto funcionamiento, debemos generar un usuario en la plataforma solo para esta aplicación web.
*'''EGE_CENTER_NAME''':Nombre del centro al que se le va a poner la aplicación web.
*'''EGE_DB_CONNECTION_STRING''': Cadena de conexión a la base de datos, donde se tenemos que poner el nombre de usuario de la base de datos, seguido de una @, a continuación indicamos la ruta de la base de datos, seguido de una @ y por ultimo la contraseña para acceder a la base de datos. En resumen: NOMBREUSUARIO@DIRECCIONBD@CONTRASEÑA
*'''EGE_DB_TYPE''': Nombre del tipo de base de datos que se usa para la plataforma egeasy.

*'''EGE_MODEL_DIRECTORY''': Ruta donde se localiza el modelo del centro de la plataforma egeasy.
*'''EGE_DOCUMENT_DIRECTORY''': Ruta donde se localizan la base documental de la plataforma egeasy.
*'''EGE_REGISTRY_DIRECTORY''': Ruta donde se localizan los registro de la plataforma egeasy.

Un ejemplo de un fichero de configuración, podría ser el siguiente:
SERVER_ADDRESS=10.22.144.178
SERVER_PORT=10000
WS_IDENTIFIER=WS_STE
WS_DB_CONNECTION_STRING=usuario@servidorBD@contraseña
WS_DB_TYPE=Oracle
WS_DIRECTORY_DOCUMENTS=C:\STE\Docs
WS_DIRECTORY_LOGS=C:\STE\Logs
WS_FILE_INVALID_WORDS=C:\STE\palabras.dat
TYPE_REGISTRATION=Free
REGISTRATION_FORM=C:\STE\registration.xml
EGE_USER_RRC=3825
EGE_CENTER_NAME=Acecau STE Oracle
EGE_DB_CONNECTION_STRING=usuario@servidorBD@contraseña
EGE_DB_TYPE=Oracle
EGE_MODEL_DIRECTORY=S:\Entornos 2002\Banzai\Modelos\ACECAU STEMod
EGE_DOCUMENT_DIRECTORY=S:\Entornos 2002\Banzai\Documentos\AcecauSTEDoc
EGE_REGISTRY_DIRECTORY=S:\Entornos 2002\Banzai\Registro\acecausteReg

==Configurar la aplicación web STE==

Para configurar la aplicación web del Sistema de Tramitación Electrónica, debemos modificar el fichero de configuración llamado ste.conf que esta en la ruta C:\xampp\tomcat\webapps\ste\WebContent\WEB-INF\classes\org\siani\ste\configuration, que para este ejemplo será donde esta instalado.

Al abrir el fichero ste.conf encontramos las siguiente etiquetas que debemos configurar. Ahora vamos a pasar a explicar detalladamente que son cada una de las etiquetas de este archivo de configuración del servicio web.

*'''SITE_DIR''': Ruta donde se encuentra instalada la aplicación web.
*'''SITE_URL''': URL donde se encuentra la aplicación web.
*'''LOG_DIR''': Ruta donde se encuentran los logs de la aplicación web.
*'''DATA_DIR''': Ruta donde se encuentra los datos variables de la aplicación web.
*'''TEMPLATES_DIR''': Ruta donde se encuentra las plantillas html de visualización.
*'''TEMP_DIR''': Ruta donde se encuentra los archivos subidos por los usuarios temporalmente.
*'''SITE_DATA_DEFINITIONS_DIR''': Ruta donde se encuentran las definiciones datos personalizados.
*'''SITE_FORMS_DIR''': Ruta donde se encuentra las vistas personalizadas de los trámites.
*'''SITE_PORT''': Puerto que usa la aplicación web.
*'''API_URL''': URL del servlet, llamado API que usa la aplicación web.
*'''SITE_IMAGES_DIR''': Ruta donde se encuentran las imagenes de la aplicación web.
*'''SITE_IMAGES_URL''': URL donde se encuentran las imagenes de la aplicación web.
*'''SITE_JAVASCRIPT_DIR''': Ruta donde se encuentran el javascript de la aplicación web.
*'''SITE_JAVASCRIPT_URL''': URL donde se encuentran el javascript de la aplicación web.
*'''SITE_STYLES_DIR''': Ruta donde se encuentran los estilos CSS de la aplicación web.
*'''SITE_STYLES_URL''': URL donde se encuentran los estilos CSS de la aplicación web.
*'''WS_SOAP_URL''': URL donde se encuentra el servicio web del STE.
*'''LANG_DIR''': Ruta donde se encuentra los archivos de idioma.
*'''EN = en''': Se define el lenguaje Ingles.
*'''ES = es''': Se define el lenguaje Español.
*'''DEFAULT_LANGUAGE''': Indica que lenguaje se va a usar por defecto en la aplicación.

Un ejemplo del fichero de configuración es:

// DIRECTORIES
SITE_DIR = c:/xampp/tomcat/webapps/ste/WebContent
SITE_URL = http://ste
LOG_DIR = C:/xampp/tomcat/webapps/ste/logs
DATA_DIR = C:/xampp/tomcat/webapps/ste/data
TEMPLATES_DIR = C:/xampp/tomcat/webapps/ste/templates
TEMP_DIR = C:/xampp/tomcat/webapps/ste/temp
SITE_PORT = 80
SITE_DATA_DEFINITIONS_DIR = C:/xampp/tomcat/webapps/ste/data/definitions
SITE_FORMS_DIR = C:/xampp/tomcat/webapps/ste/data/definitions/forms
API_URL = http://ste/api
SITE_IMAGES_DIR = c:/xampp/tomcat/webapps/ste/WebContent/images
SITE_IMAGES_URL = http://ste/images
SITE_JAVASCRIPT_DIR = c:/xampp/tomcat/webapps/ste/WebContent/javascript
SITE_JAVASCRIPT_URL = http://ste/javascript
SITE_STYLES_DIR = c:/xampp/tomcat/webapps/ste/WebContent/styles
SITE_STYLES_URL = http://ste/styles
WS_SOAP_URL = http://ste/tramitacion/tramitacion_ws_cgi.exe/soap/IEgeWebService
LANG_DIR = C:/xampp/tomcat/webapps/ste/languages
// LANGUAGES
EN = en
ES = es
DEFAULT_LANGUAGE = es

==Configurar el DNS==
Debemos preparar nuestra maquina, para indicar mediante un nombre de dominio donde esta situado el Sistema de Tramitación Electrónica, para nuestro caso, el sistema esta instalado en local. Por lo tanto solo debemos ir a la ruta de nuestro equipo donde está el fichero ''hosts'', que esta en ''C:\WINDOWS\system32\drivers\etc\'' e introducir lo siguiente:

127.0.0.1 ste

==Creación de tablas en la base de datos==
Para la implantación del Sistema de Tramitación Electrónica, se deben crear unas cuantas tablas y indices en la base de datos. Par este ejemplo vamos a utilizar la misma base de datos y esquema donde tenemos implantada ya la plataforma egeasy. A continuación se listaran los script con las sentencias SQL que hay que ejecutar en la base de datos, para generar todo lo necesario para el Sistema de Tramitación Electrónica. Disponemos de los script tanto para SQL-Server como para Oracle.

*Script para base de datos en SQL-Server
CREATE TABLE WS$USERS
(ID NUMERIC(10) PRIMARY KEY,
NIF VARCHAR(10),
NAME VARCHAR(50),
FULLNAME VARCHAR(50),
EMAIL VARCHAR(50),
FORM IMAGE);
CREATE TABLE WS$PROCESSES
(ID NUMERIC(10) PRIMARY KEY,
LABEL VARCHAR(100),
TRAMITATION_STATUS VARCHAR(100),
ID_PROCEDURE NUMERIC(10),
ID_USER NUMERIC(10),
STATUS NUMERIC(1),
CREATE_DATE DATETIME,
START_DATE DATETIME,
END_DATE DATETIME,
LAST_READ_DATE DATETIME);
CREATE TABLE WS$TASKS
(ID NUMERIC(10) PRIMARY KEY,
ID_PROCESS NUMERIC(10),
ID_EGE NUMERIC(10),
ID_DEFINITION NUMERIC(10),
CREATE_RECEIVE_DATE DATETIME,
SEND_RESPONSE_DATE DATETIME,
STATUS NUMERIC(1),
RESPONSE_TO NUMERIC(10),
CONTENT IMAGE);
CREATE TABLE WS$TASK_SIGNATURES
(ID NUMERIC(10) PRIMARY KEY,
SIGNATURE IMAGE);
CREATE TABLE WS$TASK_SNAPSHOTS
(ID NUMERIC(10) PRIMARY KEY,
SNAPSHOT IMAGE);
CREATE TABLE WS$FILES
(ID NUMERIC(10),
ID_TASK NUMERIC(10),
ID_EGE NUMERIC(10),
ATTACH_DATE DATETIME,
SOURCE NUMERIC(1),
FILE_NAME VARCHAR(50));
CREATE TABLE EG$SEQUENCES
(NAME VARCHAR(50),
SUBSEQUENCE VARCHAR(50),
CURRENT_VALUE NUMERIC(10));
CREATE TABLE WSI$WORDS
(ID NUMERIC(10),
CAPTION VARCHAR(15));
CREATE INDEX IEGI$WORDS#CAP ON WSI$WORDS (CAPTION);
CREATE TABLE WSI$INDEX
(ID_WORD NUMERIC(10),
ID_PROCESS NUMERIC(10),
ID_TASK NUMERIC(10));
CREATE INDEX IEGI$INDEX#WRD ON WSI$INDEX(ID_WORD);

*Script para base de datos en Oracle
CREATE TABLE WS$USERS
(ID NUMBER(10) PRIMARY KEY,
NIF VARCHAR2(10),
NAME VARCHAR2(50),
FULLNAME VARCHAR2(50),
EMAIL VARCHAR2(50),
FORM LONG RAW);
CREATE TABLE WS$PROCESSES
(ID NUMBER(10) PRIMARY KEY,
LABEL VARCHAR2(100),
TRAMITATION_STATUS VARCHAR2(100),
ID_PROCEDURE NUMBER(10),
ID_USER NUMBER(10),
STATUS NUMBER(1),
CREATE_DATE DATE,
START_DATE DATE,
END_DATE DATE,
LAST_READ_DATE DATE);
CREATE TABLE WS$TASKS
(ID NUMBER(10) PRIMARY KEY,
ID_PROCESS NUMBER(10),
ID_EGE NUMBER(10),
ID_DEFINITION NUMBER(10),
CREATE_RECEIVE_DATE DATE,
SEND_RESPONSE_DATE DATE,
STATUS NUMBER(1),
RESPONSE_TO NUMBER(10),
CONTENT LONG RAW);
CREATE TABLE WS$TASK_SIGNATURES
(ID NUMBER(10) PRIMARY KEY,
SIGNATURE LONG RAW);
CREATE TABLE WS$TASK_SNAPSHOTS
(ID NUMBER(10) PRIMARY KEY,
SNAPSHOT LONG RAW);
CREATE TABLE WS$FILES
(ID NUMBER(10),
ID_TASK NUMBER(10),
ID_EGE NUMBER(10),
ATTACH_DATE DATE,
SOURCE NUMBER(1),
FILE_NAME VARCHAR2(50));
CREATE TABLE EG$SEQUENCES
(NAME VARCHAR2(50),
SUBSEQUENCE VARCHAR2(50),
CURRENT_VALUE NUMBER(10));
CREATE TABLE WSI$WORDS
(ID NUMBER(10),
CAPTION VARCHAR2(15));
CREATE INDEX IEGI$WORDS#CAP ON WSI$WORDS (CAPTION);
CREATE TABLE WSI$INDEX
(ID_WORD NUMBER(10),
ID_PROCESS NUMBER(10),
ID_TASK NUMBER(10));
CREATE INDEX IEGI$INDEX#WRD ON WSI$INDEX(ID_WORD);

==Arrancar el Sistema de Tramitación Electrónica==
Para iniciar el Sistema de Tramitación Electrónica debemos iniciar una series de aplicaciones en un cierto orden. Las aplicaciones que debemos iniciar y como, se listan a continuación.
*'''XAMPP'''
Para iniciar el XAMPP, debemos ir a la ruta donde lo tenemos instalado, en este caso ''c:\xampp'' y ejecutar el archivo con nombre ''xampp-control.exe''.
*'''Servidor de Apache'''
Una vez abierto el panel de control del XAMPP, debemos hacer clic en el botón ''start'' para el Apache.
*'''Tomcat'''
Para iniciar el Tomcat, debemos ir a la ruta ''c:\xampp'' y ejecutar el archivo de procesos por lotes (.bat) con nombre ''tomcat_start.bat''.
*'''Servicio web del Sistema de Tramitación Electrónica'''
Para iniciar el servicio web, debemos ir a la ruta donde se instaló, para este ejemplo debemos ir a la carpeta tramitacion con ruta ''C:\STE\tramitacion'' y ejecutar el archivo de procesos por lotes con nombre ''lanzar.bat''.
El archivo ''lanzar.bat'' contiene el comando de consola que hay que ejecutar para iniciar el servicio web, este comando se compone por la ruta y el nombre del archivo ''Tramitacion_server.exe'' y el argumento que se le pasa al ejecutable, el cual es la ruta donde esta el archivo de configuración del servicio web. Para este ejemplo el archivo ''lanzar.bat'' contiene lo siguiente.
"c:\STE\tramitacion\Tramitacion_server.exe" "c:\STE\tramitacion\webservice.ini"
Una vez arrancada todas las aplicaciones, solo nos queda ir al navegador y introducir la URL que definimos en los ficheros de condiguración, para acceder al servicio de tramitación electrónica. En este ejemplo debemos introducir ''http://ste''

=¿Y ahora que?=
Una vez completados todos estos pasos, ya disponemos en nuestra maquina del Sistema de Tramitación Electrónica. A continuación ya podemos pasar a desarrollar en la plataforma egeasy, para hacer que el centro del que disponga haga uso del Sistema de Tramitación Electrónica. Le invito a seguir leyendo el siguiente artículo: [[Desarrollar con el STE]]

[[Category:Tramitación electrónica]]

Cómo integrar el Sistema de Tramitación Electrónica en egeasy

2009-08-03T13:28:38Z

Imhernandez: /* Requisitos */

__TOC__
=Introducción=
Este manual sirve para explicar todos los pasos que hay que dar para integrar el Sistema de Tramitación Electrónica en la plataforma egeasy. Esta explicación no partirá de cero, sino que se supone que ya se tiene instalada la plataforma egeasy, con un centro configurado y desarrollado para su usu cotidiano.

=Requisitos=
Para una correcta integración del Sistema de Tramitación Electrónica vamos a necesitar:
*Servidor web (Apache)
*Servidor de base de datos
*Servidor de Tomcat

=Pasos a seguir=
Para la instalación de la aplicación web del Sistema de Tramitación Electrónica, vamos a disponer de una instalación de la aplicación XAMPP, que nos proporciona de una forma rápida sencilla las aplicaciones requeridas para una puesta en marcha. Para que las explicaciones de los ficheros de configuración sean lo menos confuso posible, en este articulo vamos a instalar la aplicación XAMPP en ''C:\'', por lo tanto todas las rutas se explicaran de dicha ruta. Ademas de instalar la aplicación XAMPP, tenemos que instalar el servicio web, el cual lo vamos a instalar para mayor comodidad en ''C:\ste''. Así que todas las explicaciones parten de dicha ruta de instalación.

==Configurar el servidor web, Apache==
Para configurar el servidor Apache, debemos modificar el archivo de configuración, que esta en la ruta ''C:\xampp\apache\conf'' con el nombre de ''httpd.conf''. Al final de dicho fichero debemos poner lo siguiente:

ScriptAlias "/URLALIAS" "''PATHWEBSERVICE''"
<Directory "''PATHWEBSERVICE''">
AllowOverride None
Options ExecCGI
Order allow,deny
Allow from all
</Directory>

'''URLALIAS''': Es la URL que vamos a definir donde va a estar nuestro servicio web. Para este ejemplo usaremos ''tramitacion''.
 '''PATHWEBSERVICE''': Es la ruta física donde está desplegado el servicio web. Para este ejemplo, esa ruta es la siguiente: ''C:/STE/tramitacion/''.

Un ejemplo podría ser el siguiente:

ScriptAlias "/tramitacion" "C:/STE/tramitacion"
<Directory "C:/STE/tramitacion/">
AllowOverride None
Options ExecCGI
Order allow,deny
Allow from all
</Directory>

==Configurar el servicio web STE==
Para configurar el servicio web del Sistema de Tramitación Electrónica, debemos modificar el fichero de configuración llamado ''webservice.ini'' que esta en la ruta ''C:\STE\tramitacion'', que para este ejemplo será donde esta instalado.

Al abrir el fichero ''webservice.ini'' encontramos las siguiente etiquetas que debemos configurar. Ahora vamos a pasar a explicar detalladamente que son cada una de las etiquetas de este archivo de configuración del servicio web.

*'''SERVER_ADDRESS''': IP donde se publicará el servicio web.
*'''SERVER_PORT''': Puerto donde se publicará el servicio web.
*'''WS_IDENTIFIER''': Identificador del servicio web.
*'''WS_DB_CONNECTION_STRING''': Cadena de conexión a la base de datos, donde se tenemos que poner el nombre de usuario de la base de datos, seguido de una @, a continuación indicamos la ruta de la base de datos, seguido de una @ y por ultimo la contraseña para acceder a la base de datos. En resumen: NOMBREUSUARIO@DIRECCIONBD@CONTRASEÑA
*'''WS_DB_TYPE''': Gestor de base de datos. Posibles valores: SQL Server, Oracle, PostgresSQL, Firebird.
*'''WS_DIRECTORY_DOCUMENTS''': Ruta donde se almacenan los documentos generados por la aplicación.
*'''WS_DIRECTORY_LOGS''': Ruta donde se localizan los logs del servicio web.
*'''WS_FILE_INVALID_WORDS''': Ruta del fichero donde están las palabras que no se van a indexar en la base de datos.
*'''TYPE_REGISTRATION''': Si esta etiqueta está presente, entonces en la aplicacón web los usuarios podrán registrarse libremente. Los valore que admite esta etiqueta es ''Free''.
*'''REGISTRATION_FORM''':Ruta y nombre del archivo xml que se usará para generar el formulario de registro en la aplicación web. Para este ejemplo usaremos el siguiente fichero ''C:\STE\registration.xml''.
*'''EGE_USER_RRC''': Identificador del usuario en la plataforma egeasy, con el que va a acceder la aplicación web a la plataforma. Para un correcto funcionamiento, debemos generar un usuario en la plataforma solo para esta aplicación web.
*'''EGE_CENTER_NAME''':Nombre del centro al que se le va a poner la aplicación web.
*'''EGE_DB_CONNECTION_STRING''': Cadena de conexión a la base de datos, donde se tenemos que poner el nombre de usuario de la base de datos, seguido de una @, a continuación indicamos la ruta de la base de datos, seguido de una @ y por ultimo la contraseña para acceder a la base de datos. En resumen: NOMBREUSUARIO@DIRECCIONBD@CONTRASEÑA
*'''EGE_DB_TYPE''': Nombre del tipo de base de datos que se usa para la plataforma egeasy.

*'''EGE_MODEL_DIRECTORY''': Ruta donde se localiza el modelo del centro de la plataforma egeasy.
*'''EGE_DOCUMENT_DIRECTORY''': Ruta donde se localizan la base documental de la plataforma egeasy.
*'''EGE_REGISTRY_DIRECTORY''': Ruta donde se localizan los registro de la plataforma egeasy.

Un ejemplo de un fichero de configuración, podría ser el siguiente:
SERVER_ADDRESS=10.22.144.178
SERVER_PORT=10000
WS_IDENTIFIER=WS_STE
WS_DB_CONNECTION_STRING=usuario@servidorBD@contraseña
WS_DB_TYPE=Oracle
WS_DIRECTORY_DOCUMENTS=C:\STE\Docs
WS_DIRECTORY_LOGS=C:\STE\Logs
WS_FILE_INVALID_WORDS=C:\STE\palabras.dat
TYPE_REGISTRATION=Free
REGISTRATION_FORM=C:\STE\registration.xml
EGE_USER_RRC=3825
EGE_CENTER_NAME=Acecau STE Oracle
EGE_DB_CONNECTION_STRING=usuario@servidorBD@contraseña
EGE_DB_TYPE=Oracle
EGE_MODEL_DIRECTORY=S:\Entornos 2002\Banzai\Modelos\ACECAU STEMod
EGE_DOCUMENT_DIRECTORY=S:\Entornos 2002\Banzai\Documentos\AcecauSTEDoc
EGE_REGISTRY_DIRECTORY=S:\Entornos 2002\Banzai\Registro\acecausteReg

==Configurar la aplicación web STE==

Para configurar la aplicación web del Sistema de Tramitación Electrónica, debemos modificar el fichero de configuración llamado ste.conf que esta en la ruta C:\xampp\tomcat\webapps\ste\WebContent\WEB-INF\classes\org\siani\ste\configuration, que para este ejemplo será donde esta instalado.

Al abrir el fichero ste.conf encontramos las siguiente etiquetas que debemos configurar. Ahora vamos a pasar a explicar detalladamente que son cada una de las etiquetas de este archivo de configuración del servicio web.

*'''SITE_DIR''': Ruta donde se encuentra instalada la aplicación web.
*'''SITE_URL''': URL donde se encuentra la aplicación web.
*'''LOG_DIR''': Ruta donde se encuentran los logs de la aplicación web.
*'''DATA_DIR''': Ruta donde se encuentra los datos variables de la aplicación web.
*'''TEMPLATES_DIR''': Ruta donde se encuentra las plantillas html de visualización.
*'''TEMP_DIR''': Ruta donde se encuentra los archivos subidos por los usuarios temporalmente.
*'''SITE_DATA_DEFINITIONS_DIR''': Ruta donde se encuentran las definiciones datos personalizados.
*'''SITE_FORMS_DIR''': Ruta donde se encuentra las vistas personalizadas de los trámites.
*'''SITE_PORT''': Puerto que usa la aplicación web.
*'''API_URL''': URL del servlet, llamado API que usa la aplicación web.
*'''SITE_IMAGES_DIR''': Ruta donde se encuentran las imagenes de la aplicación web.
*'''SITE_IMAGES_URL''': URL donde se encuentran las imagenes de la aplicación web.
*'''SITE_JAVASCRIPT_DIR''': Ruta donde se encuentran el javascript de la aplicación web.
*'''SITE_JAVASCRIPT_URL''': URL donde se encuentran el javascript de la aplicación web.
*'''SITE_STYLES_DIR''': Ruta donde se encuentran los estilos CSS de la aplicación web.
*'''SITE_STYLES_URL''': URL donde se encuentran los estilos CSS de la aplicación web.
*'''WS_SOAP_URL''': URL donde se encuentra el servicio web del STE.
*'''LANG_DIR''': Ruta donde se encuentra los archivos de idioma.
*'''EN = en''': Se define el lenguaje Ingles.
*'''ES = es''': Se define el lenguaje Español.
*'''DEFAULT_LANGUAGE''': Indica que lenguaje se va a usar por defecto en la aplicación.

Un ejemplo del fichero de configuración es:

// DIRECTORIES
SITE_DIR = c:/xampp/tomcat/webapps/ste/WebContent
SITE_URL = http://ste
LOG_DIR = C:/xampp/tomcat/webapps/ste/logs
DATA_DIR = C:/xampp/tomcat/webapps/ste/data
TEMPLATES_DIR = C:/xampp/tomcat/webapps/ste/templates
TEMP_DIR = C:/xampp/tomcat/webapps/ste/temp
SITE_PORT = 80
SITE_DATA_DEFINITIONS_DIR = C:/xampp/tomcat/webapps/ste/data/definitions
SITE_FORMS_DIR = C:/xampp/tomcat/webapps/ste/data/definitions/forms
API_URL = http://ste/api
SITE_IMAGES_DIR = c:/xampp/tomcat/webapps/ste/WebContent/images
SITE_IMAGES_URL = http://ste/images
SITE_JAVASCRIPT_DIR = c:/xampp/tomcat/webapps/ste/WebContent/javascript
SITE_JAVASCRIPT_URL = http://ste/javascript
SITE_STYLES_DIR = c:/xampp/tomcat/webapps/ste/WebContent/styles
SITE_STYLES_URL = http://ste/styles
WS_SOAP_URL = http://ste/tramitacion/tramitacion_ws_cgi.exe/soap/IEgeWebService
LANG_DIR = C:/xampp/tomcat/webapps/ste/languages
// LANGUAGES
EN = en
ES = es
DEFAULT_LANGUAGE = es

==Configurar el DNS==
Debemos preparar nuestra maquina, para indicar mediante un nombre de dominio donde esta situado el Sistema de Tramitación Electrónica, para nuestro caso, el sistema esta instalado en local. Por lo tanto solo debemos ir a la ruta de nuestro equipo donde está el fichero ''hosts'', que esta en ''C:\WINDOWS\system32\drivers\etc\'' e introducir lo siguiente:

127.0.0.1 ste

==Creación de tablas en la base de datos==
Para la implantación del Sistema de Tramitación Electrónica, se deben crear unas cuantas tablas y indices en la base de datos. Par este ejemplo vamos a utilizar la misma base de datos y esquema donde tenemos implantada ya la plataforma egeasy. A continuación se listaran los script con las sentencias SQL que hay que ejecutar en la base de datos, para generar todo lo necesario para el Sistema de Tramitación Electrónica. Disponemos de los script tanto para SQL-Server como para Oracle.

*Script para base de datos en SQL-Server
CREATE TABLE WS$USERS
(ID NUMERIC(10) PRIMARY KEY,
NIF VARCHAR(10),
NAME VARCHAR(50),
FULLNAME VARCHAR(50),
EMAIL VARCHAR(50),
FORM IMAGE);
CREATE TABLE WS$PROCESSES
(ID NUMERIC(10) PRIMARY KEY,
LABEL VARCHAR(100),
TRAMITATION_STATUS VARCHAR(100),
ID_PROCEDURE NUMERIC(10),
ID_USER NUMERIC(10),
STATUS NUMERIC(1),
CREATE_DATE DATETIME,
START_DATE DATETIME,
END_DATE DATETIME,
LAST_READ_DATE DATETIME);
CREATE TABLE WS$TASKS
(ID NUMERIC(10) PRIMARY KEY,
ID_PROCESS NUMERIC(10),
ID_EGE NUMERIC(10),
ID_DEFINITION NUMERIC(10),
CREATE_RECEIVE_DATE DATETIME,
SEND_RESPONSE_DATE DATETIME,
STATUS NUMERIC(1),
RESPONSE_TO NUMERIC(10),
CONTENT IMAGE);
CREATE TABLE WS$TASK_SIGNATURES
(ID NUMERIC(10) PRIMARY KEY,
SIGNATURE IMAGE);
CREATE TABLE WS$TASK_SNAPSHOTS
(ID NUMERIC(10) PRIMARY KEY,
SNAPSHOT IMAGE);
CREATE TABLE WS$FILES
(ID NUMERIC(10),
ID_TASK NUMERIC(10),
ID_EGE NUMERIC(10),
ATTACH_DATE DATETIME,
SOURCE NUMERIC(1),
FILE_NAME VARCHAR(50));
CREATE TABLE EG$SEQUENCES
(NAME VARCHAR(50),
SUBSEQUENCE VARCHAR(50),
CURRENT_VALUE NUMERIC(10));
CREATE TABLE WSI$WORDS
(ID NUMERIC(10),
CAPTION VARCHAR(15));
CREATE INDEX IEGI$WORDS#CAP ON WSI$WORDS (CAPTION);
CREATE TABLE WSI$INDEX
(ID_WORD NUMERIC(10),
ID_PROCESS NUMERIC(10),
ID_TASK NUMERIC(10));
CREATE INDEX IEGI$INDEX#WRD ON WSI$INDEX(ID_WORD);

*Script para base de datos en Oracle
CREATE TABLE WS$USERS
(ID NUMBER(10) PRIMARY KEY,
NIF VARCHAR2(10),
NAME VARCHAR2(50),
FULLNAME VARCHAR2(50),
EMAIL VARCHAR2(50),
FORM LONG RAW);
CREATE TABLE WS$PROCESSES
(ID NUMBER(10) PRIMARY KEY,
LABEL VARCHAR2(100),
TRAMITATION_STATUS VARCHAR2(100),
ID_PROCEDURE NUMBER(10),
ID_USER NUMBER(10),
STATUS NUMBER(1),
CREATE_DATE DATE,
START_DATE DATE,
END_DATE DATE,
LAST_READ_DATE DATE);
CREATE TABLE WS$TASKS
(ID NUMBER(10) PRIMARY KEY,
ID_PROCESS NUMBER(10),
ID_EGE NUMBER(10),
ID_DEFINITION NUMBER(10),
CREATE_RECEIVE_DATE DATE,
SEND_RESPONSE_DATE DATE,
STATUS NUMBER(1),
RESPONSE_TO NUMBER(10),
CONTENT LONG RAW);
CREATE TABLE WS$TASK_SIGNATURES
(ID NUMBER(10) PRIMARY KEY,
SIGNATURE LONG RAW);
CREATE TABLE WS$TASK_SNAPSHOTS
(ID NUMBER(10) PRIMARY KEY,
SNAPSHOT LONG RAW);
CREATE TABLE WS$FILES
(ID NUMBER(10),
ID_TASK NUMBER(10),
ID_EGE NUMBER(10),
ATTACH_DATE DATE,
SOURCE NUMBER(1),
FILE_NAME VARCHAR2(50));
CREATE TABLE EG$SEQUENCES
(NAME VARCHAR2(50),
SUBSEQUENCE VARCHAR2(50),
CURRENT_VALUE NUMBER(10));
CREATE TABLE WSI$WORDS
(ID NUMBER(10),
CAPTION VARCHAR2(15));
CREATE INDEX IEGI$WORDS#CAP ON WSI$WORDS (CAPTION);
CREATE TABLE WSI$INDEX
(ID_WORD NUMBER(10),
ID_PROCESS NUMBER(10),
ID_TASK NUMBER(10));
CREATE INDEX IEGI$INDEX#WRD ON WSI$INDEX(ID_WORD);

==Arrancar el Sistema de Tramitación Electrónica==
Para iniciar el Sistema de Tramitación Electrónica debemos iniciar una series de aplicaciones en un cierto orden. Las aplicaciones que debemos iniciar y como, se listan a continuación.
*'''XAMPP'''
Para iniciar el XAMPP, debemos ir a la ruta donde lo tenemos instalado, en este caso ''c:\xampp'' y ejecutar el archivo con nombre ''xampp-control.exe''.
*'''Servidor de Apache'''
Una vez abierto el panel de control del XAMPP, debemos hacer clic en el botón ''start'' para el Apache.
*'''Tomcat'''
Para iniciar el Tomcat, debemos ir a la ruta ''c:\xampp'' y ejecutar el archivo de procesos por lotes (.bat) con nombre ''tomcat_start.bat''.
*'''Servicio web del Sistema de Tramitación Electrónica'''
Para iniciar el servicio web, debemos ir a la ruta donde se instaló, para este ejemplo debemos ir a la carpeta tramitacion con ruta ''C:\STE\tramitacion'' y ejecutar el archivo de procesos por lotes con nombre ''lanzar.bat''.
El archivo ''lanzar.bat'' contiene el comando de consola que hay que ejecutar para iniciar el servicio web, este comando se compone por la ruta y el nombre del archivo ''Tramitacion_server.exe'' y el argumento que se le pasa al ejecutable, el cual es la ruta donde esta el archivo de configuración del servicio web. Para este ejemplo el archivo ''lanzar.bat'' contiene lo siguiente.
"c:\STE\tramitacion\Tramitacion_server.exe" "c:\STE\tramitacion\webservice.ini"
Una vez arrancada todas las aplicaciones, solo nos queda ir al navegador y introducir la URL que definimos en los ficheros de condiguración, para acceder al servicio de tramitación electrónica. En este ejemplo debemos introducir ''http://ste''

=¿Y ahora que?=
Una vez completados todos estos pasos, ya disponemos en nuestra maquina del Sistema de Tramitación Electrónica. A continuación ya podemos pasar a desarrollar en la plataforma egeasy, para hacer que el centro del que disponga haga uso del Sistema de Tramitación Electrónica. Le invito a seguir leyendo el siguiente artículo: [[Desarrollar con el STE]]

[[Category:Tramitación electrónica]]

Cómo integrar el Sistema de Tramitación Electrónica en egeasy

2009-08-03T13:27:54Z

Imhernandez: /* Introducción */

__TOC__
=Introducción=
Este manual sirve para explicar todos los pasos que hay que dar para integrar el Sistema de Tramitación Electrónica en la plataforma egeasy. Esta explicación no partirá de cero, sino que se supone que ya se tiene instalada la plataforma egeasy, con un centro configurado y desarrollado para su usu cotidiano.

=Requisitos=
Para una correcta integración el Sistema de Tramitación Electrónica vamos a necesitar:
*Servidor web (Apache)
*Servidor de base de datos
*Servidor de Tomcat

=Pasos a seguir=
Para la instalación de la aplicación web del Sistema de Tramitación Electrónica, vamos a disponer de una instalación de la aplicación XAMPP, que nos proporciona de una forma rápida sencilla las aplicaciones requeridas para una puesta en marcha. Para que las explicaciones de los ficheros de configuración sean lo menos confuso posible, en este articulo vamos a instalar la aplicación XAMPP en ''C:\'', por lo tanto todas las rutas se explicaran de dicha ruta. Ademas de instalar la aplicación XAMPP, tenemos que instalar el servicio web, el cual lo vamos a instalar para mayor comodidad en ''C:\ste''. Así que todas las explicaciones parten de dicha ruta de instalación.

==Configurar el servidor web, Apache==
Para configurar el servidor Apache, debemos modificar el archivo de configuración, que esta en la ruta ''C:\xampp\apache\conf'' con el nombre de ''httpd.conf''. Al final de dicho fichero debemos poner lo siguiente:

ScriptAlias "/URLALIAS" "''PATHWEBSERVICE''"
<Directory "''PATHWEBSERVICE''">
AllowOverride None
Options ExecCGI
Order allow,deny
Allow from all
</Directory>

'''URLALIAS''': Es la URL que vamos a definir donde va a estar nuestro servicio web. Para este ejemplo usaremos ''tramitacion''.
 '''PATHWEBSERVICE''': Es la ruta física donde está desplegado el servicio web. Para este ejemplo, esa ruta es la siguiente: ''C:/STE/tramitacion/''.

Un ejemplo podría ser el siguiente:

ScriptAlias "/tramitacion" "C:/STE/tramitacion"
<Directory "C:/STE/tramitacion/">
AllowOverride None
Options ExecCGI
Order allow,deny
Allow from all
</Directory>

==Configurar el servicio web STE==
Para configurar el servicio web del Sistema de Tramitación Electrónica, debemos modificar el fichero de configuración llamado ''webservice.ini'' que esta en la ruta ''C:\STE\tramitacion'', que para este ejemplo será donde esta instalado.

Al abrir el fichero ''webservice.ini'' encontramos las siguiente etiquetas que debemos configurar. Ahora vamos a pasar a explicar detalladamente que son cada una de las etiquetas de este archivo de configuración del servicio web.

*'''SERVER_ADDRESS''': IP donde se publicará el servicio web.
*'''SERVER_PORT''': Puerto donde se publicará el servicio web.
*'''WS_IDENTIFIER''': Identificador del servicio web.
*'''WS_DB_CONNECTION_STRING''': Cadena de conexión a la base de datos, donde se tenemos que poner el nombre de usuario de la base de datos, seguido de una @, a continuación indicamos la ruta de la base de datos, seguido de una @ y por ultimo la contraseña para acceder a la base de datos. En resumen: NOMBREUSUARIO@DIRECCIONBD@CONTRASEÑA
*'''WS_DB_TYPE''': Gestor de base de datos. Posibles valores: SQL Server, Oracle, PostgresSQL, Firebird.
*'''WS_DIRECTORY_DOCUMENTS''': Ruta donde se almacenan los documentos generados por la aplicación.
*'''WS_DIRECTORY_LOGS''': Ruta donde se localizan los logs del servicio web.
*'''WS_FILE_INVALID_WORDS''': Ruta del fichero donde están las palabras que no se van a indexar en la base de datos.
*'''TYPE_REGISTRATION''': Si esta etiqueta está presente, entonces en la aplicacón web los usuarios podrán registrarse libremente. Los valore que admite esta etiqueta es ''Free''.
*'''REGISTRATION_FORM''':Ruta y nombre del archivo xml que se usará para generar el formulario de registro en la aplicación web. Para este ejemplo usaremos el siguiente fichero ''C:\STE\registration.xml''.
*'''EGE_USER_RRC''': Identificador del usuario en la plataforma egeasy, con el que va a acceder la aplicación web a la plataforma. Para un correcto funcionamiento, debemos generar un usuario en la plataforma solo para esta aplicación web.
*'''EGE_CENTER_NAME''':Nombre del centro al que se le va a poner la aplicación web.
*'''EGE_DB_CONNECTION_STRING''': Cadena de conexión a la base de datos, donde se tenemos que poner el nombre de usuario de la base de datos, seguido de una @, a continuación indicamos la ruta de la base de datos, seguido de una @ y por ultimo la contraseña para acceder a la base de datos. En resumen: NOMBREUSUARIO@DIRECCIONBD@CONTRASEÑA
*'''EGE_DB_TYPE''': Nombre del tipo de base de datos que se usa para la plataforma egeasy.

*'''EGE_MODEL_DIRECTORY''': Ruta donde se localiza el modelo del centro de la plataforma egeasy.
*'''EGE_DOCUMENT_DIRECTORY''': Ruta donde se localizan la base documental de la plataforma egeasy.
*'''EGE_REGISTRY_DIRECTORY''': Ruta donde se localizan los registro de la plataforma egeasy.

Un ejemplo de un fichero de configuración, podría ser el siguiente:
SERVER_ADDRESS=10.22.144.178
SERVER_PORT=10000
WS_IDENTIFIER=WS_STE
WS_DB_CONNECTION_STRING=usuario@servidorBD@contraseña
WS_DB_TYPE=Oracle
WS_DIRECTORY_DOCUMENTS=C:\STE\Docs
WS_DIRECTORY_LOGS=C:\STE\Logs
WS_FILE_INVALID_WORDS=C:\STE\palabras.dat
TYPE_REGISTRATION=Free
REGISTRATION_FORM=C:\STE\registration.xml
EGE_USER_RRC=3825
EGE_CENTER_NAME=Acecau STE Oracle
EGE_DB_CONNECTION_STRING=usuario@servidorBD@contraseña
EGE_DB_TYPE=Oracle
EGE_MODEL_DIRECTORY=S:\Entornos 2002\Banzai\Modelos\ACECAU STEMod
EGE_DOCUMENT_DIRECTORY=S:\Entornos 2002\Banzai\Documentos\AcecauSTEDoc
EGE_REGISTRY_DIRECTORY=S:\Entornos 2002\Banzai\Registro\acecausteReg

==Configurar la aplicación web STE==

Para configurar la aplicación web del Sistema de Tramitación Electrónica, debemos modificar el fichero de configuración llamado ste.conf que esta en la ruta C:\xampp\tomcat\webapps\ste\WebContent\WEB-INF\classes\org\siani\ste\configuration, que para este ejemplo será donde esta instalado.

Al abrir el fichero ste.conf encontramos las siguiente etiquetas que debemos configurar. Ahora vamos a pasar a explicar detalladamente que son cada una de las etiquetas de este archivo de configuración del servicio web.

*'''SITE_DIR''': Ruta donde se encuentra instalada la aplicación web.
*'''SITE_URL''': URL donde se encuentra la aplicación web.
*'''LOG_DIR''': Ruta donde se encuentran los logs de la aplicación web.
*'''DATA_DIR''': Ruta donde se encuentra los datos variables de la aplicación web.
*'''TEMPLATES_DIR''': Ruta donde se encuentra las plantillas html de visualización.
*'''TEMP_DIR''': Ruta donde se encuentra los archivos subidos por los usuarios temporalmente.
*'''SITE_DATA_DEFINITIONS_DIR''': Ruta donde se encuentran las definiciones datos personalizados.
*'''SITE_FORMS_DIR''': Ruta donde se encuentra las vistas personalizadas de los trámites.
*'''SITE_PORT''': Puerto que usa la aplicación web.
*'''API_URL''': URL del servlet, llamado API que usa la aplicación web.
*'''SITE_IMAGES_DIR''': Ruta donde se encuentran las imagenes de la aplicación web.
*'''SITE_IMAGES_URL''': URL donde se encuentran las imagenes de la aplicación web.
*'''SITE_JAVASCRIPT_DIR''': Ruta donde se encuentran el javascript de la aplicación web.
*'''SITE_JAVASCRIPT_URL''': URL donde se encuentran el javascript de la aplicación web.
*'''SITE_STYLES_DIR''': Ruta donde se encuentran los estilos CSS de la aplicación web.
*'''SITE_STYLES_URL''': URL donde se encuentran los estilos CSS de la aplicación web.
*'''WS_SOAP_URL''': URL donde se encuentra el servicio web del STE.
*'''LANG_DIR''': Ruta donde se encuentra los archivos de idioma.
*'''EN = en''': Se define el lenguaje Ingles.
*'''ES = es''': Se define el lenguaje Español.
*'''DEFAULT_LANGUAGE''': Indica que lenguaje se va a usar por defecto en la aplicación.

Un ejemplo del fichero de configuración es:

// DIRECTORIES
SITE_DIR = c:/xampp/tomcat/webapps/ste/WebContent
SITE_URL = http://ste
LOG_DIR = C:/xampp/tomcat/webapps/ste/logs
DATA_DIR = C:/xampp/tomcat/webapps/ste/data
TEMPLATES_DIR = C:/xampp/tomcat/webapps/ste/templates
TEMP_DIR = C:/xampp/tomcat/webapps/ste/temp
SITE_PORT = 80
SITE_DATA_DEFINITIONS_DIR = C:/xampp/tomcat/webapps/ste/data/definitions
SITE_FORMS_DIR = C:/xampp/tomcat/webapps/ste/data/definitions/forms
API_URL = http://ste/api
SITE_IMAGES_DIR = c:/xampp/tomcat/webapps/ste/WebContent/images
SITE_IMAGES_URL = http://ste/images
SITE_JAVASCRIPT_DIR = c:/xampp/tomcat/webapps/ste/WebContent/javascript
SITE_JAVASCRIPT_URL = http://ste/javascript
SITE_STYLES_DIR = c:/xampp/tomcat/webapps/ste/WebContent/styles
SITE_STYLES_URL = http://ste/styles
WS_SOAP_URL = http://ste/tramitacion/tramitacion_ws_cgi.exe/soap/IEgeWebService
LANG_DIR = C:/xampp/tomcat/webapps/ste/languages
// LANGUAGES
EN = en
ES = es
DEFAULT_LANGUAGE = es

==Configurar el DNS==
Debemos preparar nuestra maquina, para indicar mediante un nombre de dominio donde esta situado el Sistema de Tramitación Electrónica, para nuestro caso, el sistema esta instalado en local. Por lo tanto solo debemos ir a la ruta de nuestro equipo donde está el fichero ''hosts'', que esta en ''C:\WINDOWS\system32\drivers\etc\'' e introducir lo siguiente:

127.0.0.1 ste

==Creación de tablas en la base de datos==
Para la implantación del Sistema de Tramitación Electrónica, se deben crear unas cuantas tablas y indices en la base de datos. Par este ejemplo vamos a utilizar la misma base de datos y esquema donde tenemos implantada ya la plataforma egeasy. A continuación se listaran los script con las sentencias SQL que hay que ejecutar en la base de datos, para generar todo lo necesario para el Sistema de Tramitación Electrónica. Disponemos de los script tanto para SQL-Server como para Oracle.

*Script para base de datos en SQL-Server
CREATE TABLE WS$USERS
(ID NUMERIC(10) PRIMARY KEY,
NIF VARCHAR(10),
NAME VARCHAR(50),
FULLNAME VARCHAR(50),
EMAIL VARCHAR(50),
FORM IMAGE);
CREATE TABLE WS$PROCESSES
(ID NUMERIC(10) PRIMARY KEY,
LABEL VARCHAR(100),
TRAMITATION_STATUS VARCHAR(100),
ID_PROCEDURE NUMERIC(10),
ID_USER NUMERIC(10),
STATUS NUMERIC(1),
CREATE_DATE DATETIME,
START_DATE DATETIME,
END_DATE DATETIME,
LAST_READ_DATE DATETIME);
CREATE TABLE WS$TASKS
(ID NUMERIC(10) PRIMARY KEY,
ID_PROCESS NUMERIC(10),
ID_EGE NUMERIC(10),
ID_DEFINITION NUMERIC(10),
CREATE_RECEIVE_DATE DATETIME,
SEND_RESPONSE_DATE DATETIME,
STATUS NUMERIC(1),
RESPONSE_TO NUMERIC(10),
CONTENT IMAGE);
CREATE TABLE WS$TASK_SIGNATURES
(ID NUMERIC(10) PRIMARY KEY,
SIGNATURE IMAGE);
CREATE TABLE WS$TASK_SNAPSHOTS
(ID NUMERIC(10) PRIMARY KEY,
SNAPSHOT IMAGE);
CREATE TABLE WS$FILES
(ID NUMERIC(10),
ID_TASK NUMERIC(10),
ID_EGE NUMERIC(10),
ATTACH_DATE DATETIME,
SOURCE NUMERIC(1),
FILE_NAME VARCHAR(50));
CREATE TABLE EG$SEQUENCES
(NAME VARCHAR(50),
SUBSEQUENCE VARCHAR(50),
CURRENT_VALUE NUMERIC(10));
CREATE TABLE WSI$WORDS
(ID NUMERIC(10),
CAPTION VARCHAR(15));
CREATE INDEX IEGI$WORDS#CAP ON WSI$WORDS (CAPTION);
CREATE TABLE WSI$INDEX
(ID_WORD NUMERIC(10),
ID_PROCESS NUMERIC(10),
ID_TASK NUMERIC(10));
CREATE INDEX IEGI$INDEX#WRD ON WSI$INDEX(ID_WORD);

*Script para base de datos en Oracle
CREATE TABLE WS$USERS
(ID NUMBER(10) PRIMARY KEY,
NIF VARCHAR2(10),
NAME VARCHAR2(50),
FULLNAME VARCHAR2(50),
EMAIL VARCHAR2(50),
FORM LONG RAW);
CREATE TABLE WS$PROCESSES
(ID NUMBER(10) PRIMARY KEY,
LABEL VARCHAR2(100),
TRAMITATION_STATUS VARCHAR2(100),
ID_PROCEDURE NUMBER(10),
ID_USER NUMBER(10),
STATUS NUMBER(1),
CREATE_DATE DATE,
START_DATE DATE,
END_DATE DATE,
LAST_READ_DATE DATE);
CREATE TABLE WS$TASKS
(ID NUMBER(10) PRIMARY KEY,
ID_PROCESS NUMBER(10),
ID_EGE NUMBER(10),
ID_DEFINITION NUMBER(10),
CREATE_RECEIVE_DATE DATE,
SEND_RESPONSE_DATE DATE,
STATUS NUMBER(1),
RESPONSE_TO NUMBER(10),
CONTENT LONG RAW);
CREATE TABLE WS$TASK_SIGNATURES
(ID NUMBER(10) PRIMARY KEY,
SIGNATURE LONG RAW);
CREATE TABLE WS$TASK_SNAPSHOTS
(ID NUMBER(10) PRIMARY KEY,
SNAPSHOT LONG RAW);
CREATE TABLE WS$FILES
(ID NUMBER(10),
ID_TASK NUMBER(10),
ID_EGE NUMBER(10),
ATTACH_DATE DATE,
SOURCE NUMBER(1),
FILE_NAME VARCHAR2(50));
CREATE TABLE EG$SEQUENCES
(NAME VARCHAR2(50),
SUBSEQUENCE VARCHAR2(50),
CURRENT_VALUE NUMBER(10));
CREATE TABLE WSI$WORDS
(ID NUMBER(10),
CAPTION VARCHAR2(15));
CREATE INDEX IEGI$WORDS#CAP ON WSI$WORDS (CAPTION);
CREATE TABLE WSI$INDEX
(ID_WORD NUMBER(10),
ID_PROCESS NUMBER(10),
ID_TASK NUMBER(10));
CREATE INDEX IEGI$INDEX#WRD ON WSI$INDEX(ID_WORD);

==Arrancar el Sistema de Tramitación Electrónica==
Para iniciar el Sistema de Tramitación Electrónica debemos iniciar una series de aplicaciones en un cierto orden. Las aplicaciones que debemos iniciar y como, se listan a continuación.
*'''XAMPP'''
Para iniciar el XAMPP, debemos ir a la ruta donde lo tenemos instalado, en este caso ''c:\xampp'' y ejecutar el archivo con nombre ''xampp-control.exe''.
*'''Servidor de Apache'''
Una vez abierto el panel de control del XAMPP, debemos hacer clic en el botón ''start'' para el Apache.
*'''Tomcat'''
Para iniciar el Tomcat, debemos ir a la ruta ''c:\xampp'' y ejecutar el archivo de procesos por lotes (.bat) con nombre ''tomcat_start.bat''.
*'''Servicio web del Sistema de Tramitación Electrónica'''
Para iniciar el servicio web, debemos ir a la ruta donde se instaló, para este ejemplo debemos ir a la carpeta tramitacion con ruta ''C:\STE\tramitacion'' y ejecutar el archivo de procesos por lotes con nombre ''lanzar.bat''.
El archivo ''lanzar.bat'' contiene el comando de consola que hay que ejecutar para iniciar el servicio web, este comando se compone por la ruta y el nombre del archivo ''Tramitacion_server.exe'' y el argumento que se le pasa al ejecutable, el cual es la ruta donde esta el archivo de configuración del servicio web. Para este ejemplo el archivo ''lanzar.bat'' contiene lo siguiente.
"c:\STE\tramitacion\Tramitacion_server.exe" "c:\STE\tramitacion\webservice.ini"
Una vez arrancada todas las aplicaciones, solo nos queda ir al navegador y introducir la URL que definimos en los ficheros de condiguración, para acceder al servicio de tramitación electrónica. En este ejemplo debemos introducir ''http://ste''

=¿Y ahora que?=
Una vez completados todos estos pasos, ya disponemos en nuestra maquina del Sistema de Tramitación Electrónica. A continuación ya podemos pasar a desarrollar en la plataforma egeasy, para hacer que el centro del que disponga haga uso del Sistema de Tramitación Electrónica. Le invito a seguir leyendo el siguiente artículo: [[Desarrollar con el STE]]

[[Category:Tramitación electrónica]]