Documento de Administrador

Contenido:

1. Introducción 2. Requerimientos 3. Instalación 4. Ingreso al sistema 5. Pantalla Principal Administrador

a. Menú de herramientas b. Herramientas c. Ventanas de Aplicación d. Vista de Aplicaciones e. Menú Contextual Mouse f. Menú Aplicaciones g. Menú Herramientas h. Administrador de usuarios i. Barra de Herramientas j. Vista de aplicaciones

6. Editor de Aplicaciones Workflows 7. Editor de Formularios 8. Especificación de Codificación de Formularios 9. Aplicación Ejemplo

1. Introducción

Este manual presenta la aplicación LoopFlow por parte del Administrador. Contempla principalmente de cuatro partes:

• Uso de la aplicación LoopFlow • Administración de usuarios • Aplicaciones Workflows • Edición de formularios

2. Requerimientos Hardware:

- PC Intel x86 - Pentium III o Equivalente (Pentium 4 o Athlon 64 recomendado) - 256 MB RAM (512 recomendados) - 1 Tarjeta Red - 50 MB en HD

Software:

- Windows 2000 (XP recomendado) - Java 1.4.2 (1.5 recomendado) (http://www.java.com)

3. Instalación

Proceso de instalación: • Descomprimir el archivo LoopFlow.rar en C:\ • Abrir archivo c:\LoopFlow\plugins\loopflow_0.0.3.jar con WinRAR • Modificar el archivo interno del comprimido

\loopflow\data\settings.properties de la siguiente manera: o Reemplazar en workSessionServer, umanSessionServer,

drofloViewer y ftpServer la palabra “localhost” por la dirección IP del servidor OpenWFE.

o Si no descomprimió en C:\ modificar las rutas a los archivos de configuración logfile, defaultLaunchItem, defaultWorkflow, expressionMap

4. Ingreso al Sistema

La identificación es controlada mediante un nombre de usuario y contraseña, las cuales son ingresadas en los respectivos TextBox. Cuando el usuario hace clic en entrar Loopflow intenta conectarse al servidor para validar los datos de usuarios, si la validación no es correcta o sucede algún tipo de error que no permita identificarse con el servidor, loopflow emitirá un mensaje de error. Cuando el usuario hace clic en cancelar simplemente se cierra la aplicación. Si se activa la casilla ‘ingresar como administrador’ se inicia una sesión especial con todas las herramientas necesarias para crear y modificar aplicaciones Workflows.

5. Pantalla Principal Administrador

a. Menú de Herramientas: se tiene acceso a todos los componentes que existen visualmente

b. Herramientas: se encuentran solo los componentes del menú de

herramientas que son más importantes

c. Ventanas de Aplicación: Muestra las distintas ventanas abiertas de las sub aplicaciones

d. Vista de Aplicaciones: contiene un árbol que muestra el detalle de las

aplicaciones

e. Menú Contextual Mouse: este menú esta asociado a las aplicaciones cuando se usa el botón derecho del Mouse

Menú Contextual Mouse

Ventanas de Aplicación

Vista de

Aplicaciones

Menú de Herramientas Herramientas

f. Menú Aplicaciones: muestra las distintas herramientas que las aplicaciones pueden utilizar.

g. Menú Herramientas:

h. Administrador de usuarios: en esta ventana se administran las cuentas de los usuarios; se pueden agregar más usuarios y reestablecer sus contraseñas

i. Barra de Herramientas:

El 1º botón esta asociado abrir el formulario para una nueva aplicación; el 2º botón se utiliza para editar la aplicación seleccionada; el 3º botón elimina una aplicación seleccionada y el 4º botón esta asociado el administrador de usuarios para mantener las cuentas de los usuarios.

j. Vista de aplicaciones:

El cuadro área 1 es el área al cual pertenece la aplicación y app1 es la aplicación en si. Al hacer clic en área 1 se deshabilitan acciones como editar o eliminar la aplicación lo mismo sucede al apretar el botón derecho del Mouse se deshabilita el menú contextual.

Al hacer clic en app1 se habilitan las acciones de editar y eliminar una aplicación y el menú contextual del Mouse también se habilita.

6. Editor de aplicaciones workflow Este editor consta de 4 componentes: Editor XML; Editor de Permisos; Editor de Vistas y Editor de Formulario. Pasos para crear una nueva aplicación: Hacer clic en el botón de la barra de herramientas para crear una nueva aplicación y se abrirá la siguiente ventana.

Donde dice área de la aplicación se busca o se escribe el área a la cual se quiere que pertenezca la nueva aplicación, luego se escribe el nombre que se le dará a la nueva aplicación y se le hace clic en confirmar. Permisos de usuario: Luego de confirmar la nueva aplicación se abre la ventana de los permisos de usuario

Usuarios: En el recuadro aparecen todos los usuarios del sistema, se deben seleccionar los usuarios que se permitirán en esta aplicación, una vez hecha la elección se hace clic en agregar. Permisos: En la ventana aparecen los usuarios permitidos en la aplicación, al hacer clic sobre uno de ellos en la ventana que se encuentra al lado derecho se puede seleccionar los permisos específicos que tendrá el usuario en la aplicación, se realiza de igual manera para todos los usuarios. Los permisos específicos que puede tener un usuario son: leer, escribir, delegar y lanzar. En esta ventana se pueden además eliminar permisos a los usuarios. Una vez realizados los permisos se hace clic en guardar cambios. Permisos de vistas: Mediante este permiso se pueden crear vistas de los usuarios, este permiso es una opción voluntaria no es obligatoria.

Nombre: Se agrega en el recuadro el nombre que se le quiere dar a la vista.

Vista: En la ventana de la izquierda aparecen las vistas creadas y en la ventana de la derecha se seleccionan los usuarios que vana pertenecer a la vista, luego de seleccionarlos se oprime agregar y también existe la opción de agregar directamente todos los usuarios de la aplicación a la vista. Se puede eliminar una vista y también se pueden eliminar usuarios. Luego de seleccionar todo se hace clic en guardar cambios. Editor XML:

En el primer cuadro se seleccionan las funciones que se quiere que tenga la aplicación y en el cuadro de al lado los participantes los cuales son los usuarios y las vistas. En la ventana del editor se pueden ir agregando los participantes con los solo oprimir el botón con forma de flecha. Una vez terminada la selección se valida el XML, se puede ver un diagrama y se guardan los cambios.

7. Editor de Formularios

Al editar una aplicación verá la pestaña Editor de Formulario, que le permitirá crear o modificar el formulario inicial asociado a la aplicación de manera gráfica.

Fig. 7.1 Editor de formularios

Al seleccionar la pestaña usted verá una representación jerárquica (en árbol)

de los componentes que ya existen en el formulario a la izquierda de la pantalla. Si usted no ha creado el formulario, el único objeto será la raíz y su titulo será Formulario.

Para agregar un nuevo componente, simplemente seleccione el tipo de la lista en la parte superior y presione el botón Agregar. Si el componente que estaba seleccionado en el árbol del formulario era un contenedor (por ejemplo, un Section) su componente se agregará dentro de él, al fondo de la lista. De lo contrario su componente se agregará directamente antes o después del componente seleccionado dependiendo de lo que si eligió la opción Arriba o Bajo la selección. Los componentes se van agregando en una fila hasta llenar sus columnas (definidas por el contenedor) y cualquier componente que sobrepase la última columna pasará a la siguiente fila.

Para eliminar un componente, basta seleccionarlo en el árbol y presionar el botón Eliminar. Si elimina un componente Section, también se eliminarán todos los componentes en su interior.

Los tipos de componentes que son soportados por el sistema de formulario actualmente son los siguientes:

• Text: Es un campo de texto con una etiqueta asociada. El campo de texto puede ser de una o varias líneas.

• Check: Es un casillero que puede estar marcado o no y tiene una etiqueta asociada.

• Combo: Es una lista desplegable, de la cual se puede elegir un valor. • FileUpload: Es un campo de texto con un botón que permite seleccionar

un archivo (NOTA: actualmente no sube un archivo al servidor) • FileLink: Permite agregar un link al formulario junto con una etiqueta.

(NOTA: Este componente esta pensado para ser usado en conjunto con FileUpload y por lo tanto tampoco cumple funcionalidad actualmente)

• Section: Es un contenedor de otros componentes con una barra de titulo que permite mostrar u ocultar a todos los componentes en su interior.

Al seleccionar un componente, las propiedades de él se despliegan en la parte

inferior de la barra de herramientas.

Fig. 7.2 Propiedades de un componente, y su modificación

Las propiedades que aparecen en esta sección varían con el tipo del

componente seleccionado. A continuación se explicará el significado, posibles valores y la forma de editar las distintas propiedades.

Propiedades comunes:

• Nombre: Esta propiedad determina el nombre con el cual el componente aparece en el árbol de componentes. Para editar la propiedad basta hacer clic sobre el nombre actual y escribir uno nuevo. El nombre debe ser único dentro del contenedor en el que se encuentra el componente, por lo tanto, si usted proporciona un nombre ya existente, el editor le avisará y revertirá el cambio. El nombre de un componente le permitirá hacerle referencia cuando

necesite leer o modificar la información o los parámetros que lo definen desde el lenguaje de procesos. Para mayores detalles sobre la estructura interna de los componentes en un ítem de trabajo vea la sección Especificación de Codificación de Formularios.

• Texto: El significado de esta propiedad varía con el tipo del componente, pero siempre se refiere a un texto visible en el formulario. Por ejemplo, en el caso de un Text, Check, Combo, y otros, esta propiedad determina la etiqueta del componente. En el caso de un Section, será el titulo.

• Activado: Esta propiedad solo aparece en los componentes que no son contenedores y determina si el componente puede realizar la acción que le corresponde. Si su valor es false (falso), el componente se desplegará, pero el usuario no podrá realizar ninguna acción sobre el. Esto permite, por ejemplo, componentes Text que no sean editables.

• Visible: Esta propiedad determina si el componente será visible o no para los usuarios del formulario. Esto permite definir componentes con anterioridad para ser mostrados más adelante. Para editar la propiedad basta hacer clic sobre el valor y seleccionar uno nuevo de la lista que aparecerá. Los valores posibles son true (verdadero), y false (falso);

• LayoutData: Esta es una propiedad compuesta que determina las dimensiones y posición que toma el componente en el formulario. Tiene varios parámetros que se explican a continuación:

o hAlign, vAlign: Representan la alineación horizontal y vertical del componente dentro de su contenedor. Los valores posibles son: comienzo (a la izquierda, o arriba, dependiendo del caso), centro, final (a la derecha, o abajo), y llenar. Éste último valor indica que el componente debiera adaptarse al tamaño de la ventana donde se esta desplegando el formulario.

o hGrab, vGrab: Estas propiedades indican si el componente debiera apoderarse del espacio libre en el sentido horizontal o vertical, respectivamente. Valores posibles: true, false.

o hSpan, vSpan: Indican cuantas columnas o filas debe abarcar el componente, respectivamente (valor numérico). La siguiente imagen explica el significado de estas propiedades:

Fig. 7.3 Sections con distintos valores de hSpan

En la imagen el contenedor raíz ha sido configurado con dos columnas. El Section llamado Detalle tiene un hSpan de 2, mientras que las secciones inferiores tienen un hSpan de 1.

o hHint, vHint: Estas propiedades le indican al componente, que tamaño (en píxeles) debiera intentar tener en las direcciones horizontal y vertical respectivamente. Valor predeterminado: -1 (significa que el componente se adaptará a su contenido). Estas propiedades no se aplican al componente Section y no son desplegadas.

o minWidth, minHeight: Estos valores determinan el ancho y alto mínimo (en píxeles) que es aceptable para el componente. Valor predeterminado: 0. Estas propiedades no se aplican al componente Section y no son desplegadas.

Propiedades específicas a componentes: • Raíz: El objeto raíz tiene la propiedad específica Titulo, que representa el

titulo del formulario. • Contenedores (Raíz y Section): Ambos objetos tienen la propiedad

NumColumnas que determina el número de columnas que deben usarse para organizar los componentes que están en su interior. Como fue mencionado antes, el número de columnas ocupadas por un componente puede ser modificado con la propiedad hSpan de LayoutData.

• Text: Este componente tiene la propiedad MultiLinea, que indica si es un campo para textos largos que abarcan múltiples líneas. Por ejemplo, el Text Descripción en la figura 7.3 no es multilínea, mientras que Detalle si lo es. Valores posibles: true, false.

• Combo: Este componente tiene la propiedad Items que indica los valores posibles que un usuario podrá seleccionar. Para editarlo, haga clic sobre el valor y luego sobre el botón que aparecerá marcado con puntos suspensivos. Al hacer esto aparecerá el dialogo visto en la figura 7.2, que le permitirá agregar o eliminar ítems del componente.

8. Especificación de Codificación de Formularios

LoopFlow almacena los formularios en los ítems de trabajo codificándolos como atributos anidados. Esto tiene la ventaja de reutilizar una parte considerable del código entregado por OpenWFE lo cual facilitó su implementación, pero la representación XML de los atributos anidados no es compacta por lo cual un formulario simple puede bordear los 50 KB en disco. Por estos motivos y otros se planea en el futuro cambiar la representación por una de XML compacto y personalizado almacenado en un solo atributo simple del ítem de trabajo.

La codificación actual sigue el patrón que se explica a continuación: • __title__ : <string> Titulo del formulario • __layout__: <string> Distribución de componentes en la raíz del formulario. Actualmente solo se soporta “Grid”. Opcional. • __layoutparms__ : <map>

o numColumns : <integer> número de columnas • [nombre que no comienza con “__”]: <map> Esto se considera como un componente, pero solo si contiene el atributo “__type__” en su interior.

o __type__ : <string> valores posibles: [Text, Check, Combo, FileBox, FileLink, Section]

o __num__: <integer> posición del componente en la lista de su padre contenedor.

o __text__ : <string> Propiedad Texto o __disabled__: <boolean> Inverso de Propiedad Activado o __hidden__ : <boolean> Inverso de Propiedad Visible o __required__: <boolean> Propiedad Requerido o __layoutdata__: <map> Propiedad LayoutData

� hAlign: <string> Propiedad hAlign � hGrab: <boolean> Propiedad hGrab � hSpan: <integer> Propiedad hSpan � hHint: <integer> Propiedad hHint � minWidth: <integer> Propiedad minWidth � vAlign: <string> Propiedad vAlign � vGrab: <boolean> Propiedad vGrab � vSpan: <integer> Propiedad vSpan � vHint: <integer> Propiedad hHint � minHeight: <integer> Propiedad minHeight

o __data__: � [si __type__ = Text] <string> Contenido � [si __type__ = Check] <boolean> Contenido � [si __type__ = Combo] <map> Contenido

• __index__: <integer> posición en la lista que fue seleccionada por el usuario

• __items__: <list> Propiedad Items � [si __type__ = FileBox] <string> archivo seleccionado � [si __type__ = FileLink] <string> URL del link � [si __type__ = Section] <map> contiene los mismo

atributos que la raiz salvo por __title__ que no se considera.

La forma de referenciar datos de un componente desde el lenguaje de

definición de procesos es la siguiente: o Para leer se usa la notación interna de OpenWFE para acceder a campos

anidados ${f:campo.campo_anidado}. Por ejemplo, para leer el contenido de un Text llamado txt, dentro de un Section llamado sct: ${f:sct.__data__.txt.__data__}. NOTA: esta notación retorna el valor literal, por lo tanto si se quiere usar para ser agregada al contenido de otro campo tiene que estar entre las comillas del valor string (Ejemplo: <set field=”copia” value=”${f:sct.__data__.txt.__data__}” />)

o Para modificar una propiedad de un componente se debe usar la expresión

“set-nested” de LoopFlow. Por ejemplo para modificar la propiedad anterior: <set-nested path=”sct.__data__.txt.__data__” value=”Aqui va el valor” /> Si el valor ingresado no es un string debe especificarse el atributo type=”bool” o type=”int” según sea el caso.

9. Aplicación Ejemplo En esta sección se muestran los pasos necesarios para realizar una

aplicación en LoopFlow. Esta aplicación ejemplifica la problemática típica en una empresa de un sistema de solicitudes. Siempre se recomienda modelar un proceso de workflow primero como diagrama. El diagrama de ejemplo se muestra a continuación.

En este diagrama se puede ver que el proceso comienza cuando un usuario emite una solicitud. Esto pasa a un proceso de envío de correo dependiendo de algún valor dentro del formulario (en este caso un checkbox). Luego pasa a una vista que contiene a dos usuarios que actúan como confirmadores de las solicitudes. Si ellos rechazan la solicitud esta vuelve al solicitante para que haga cualquier mejora necesaria. De lo contrario el confirmador elige a quien enviar la solicitud. Al llegar al destinatario, este debe atender la solicitud y realizar lo que se solicita. Una vez hecho esto llena un informe para el cual hay un espacio designado en el formulario que se ha hecho visible. Finalmente, cuando el destinatario procede con el flujo, el ítem de trabajo llega al solicitante original, quien evalúa si la solicitud fue resuelta correctamente. De no ser así, puede rechazarla y esta será devuelta al destinatario para que corrija las deficiencias. Al finalizar se extraerán datos de la solicitud y se almacenarán en una base de datos.

Ahora que ya tenemos definidos los distintos pasos que debe realizar la

aplicación debemos crearla. El primer paso es ingresar a LoopFlow como administrador (ver Sección 4). Suponiendo que hay 4 usuarios en el sistema (para los propósitos del ejemplo les llamaremos user1-4) pasaremos a crear la aplicación con el área ejemplo y nombre solicitudes, entregaremos todos los permisos a los usuarios y crearemos una vista confirmadores con dos de ellos (ver Sección 6).

Una vez creados los permisos y la vista, deberíamos diseñar el formulario

con el Editor de Formulario (ver Sección 7) ya que necesitaremos hacer referencia a sus componentes. Para los propósitos de este flujo las secciones de Informe y Evaluación debieran no ser visibles al comienzo, por lo tanto hay que cambiar su propiedad Visible antes de guardar el formulario.

Una vez que todo esto ha sido realizado, se puede pasar a crear la definición de proceso para la aplicación con el Editor XML (ver Sección 6).

Ahora en el editor XML necesitamos definir la secuencia de eventos que

deben ocurrir con una solicitud a medida que va pasando por las distintas etapas. Para esto es útil revisar la documentación de OpenWFE (se encuentra en la carpeta docs) y la Sección 8.

Es útil dividir el proceso en subprocesos, para poder comprenderlo mejor.

En este caso podemos dividirlo en los siguientes subprocesos: • Envío de solicitud: consiste en el paso de la solicitud entre el

solicitante y los confirmadores • Destino de solicitud: consiste en el paso de la solicitud entre el

destinatario y el solicitante • Envío de correo: configura los parámetros y llama a un agente de

correo • Registro en Base de datos: extrae datos del formulario y los

almacena en una base de datos por medio de un agente.

Un dato importante a notar es que el llenado del formulario inicial para ejecutar una petición no forma parte del proceso sino que es algo previo a él.

Con estas cosas en mente pasaremos a revisar la definición del proceso.

<?xml version="1.0" encoding="UTF-8"?> <process-definition name="ejemplo.solicitudes" revision="1.0" > <description> Una aplicación de ejemplo </description> <!-- flujo normal --> <sequence>

--Aquí comienza el flujo normal cuando ya se ha llenado el formulario inicial. Primero se llama al subproceso de correo, el cual revisará si un checkbox de correo en el formulario estaba activado. De ser así enviará una notificación de correo a quien corresponda. El siguiente paso es copiar la descripción de un campo del formulario al campo especial __descripcion__ que permite que esta se despliege en la lista de WorkItems. Luego desactivamos los campos que llenó el solicitante para que los confirmadores solo los puedan leer. La notación sigue lo especificado en la Sección 8. Los nombres de los componentes dependen de lo que se haya escrito en el editor de formularios.

<subprocess ref="enviar_correo"/> <set field="__descripcion__" value="${f:scdetsol.__data__.txdesc.__data__}"/> <set-nested path="scdetsol.__data__.txdesc.__disabled__" value="true" type="bool"/> <set-nested path="scdetsol.__data__.cbprio.__disabled__" value="true" type="bool"/> <set-nested path="scdetsol.__data__.txdetalle.__disabled__" value="true" type="bool"/> <set-nested path="cbenviar.__hidden__" value="false" type="bool"/>

--Aquí se pasa a la vista de confirmadores para que ellos tomen una decisión. En este caso un Combo donde el primer item era Rechazar y los demás los nombres de los otros usuarios, permite decidir hacia donde debiera seguir el flujo. Para esto usamos la sentencia if. La primera llamada a subproceso se ejecutará si se cumple la condición (que esté seleccionado Rechazar), mientras que será la segunda de lo contrario. <participant ref="role-ejemplo-solicitudes-view:confirmadores" /> <if test="${f:cbenviar.__data__.__index__} == 0"> <!-- rechazado --> <subprocess ref="enviar_solicitud" /> <subprocess ref="destino_solicitud" /> </if> </sequence> <!-- Envio Solicitud --> <process-definition name="enviar_solicitud"> <sequence>

--Este subproceso ejecuta el caso en que fue rechazada inicialmente la solicitud, para esto reactiva los campos que necesita el solicitante, y oculta el Combo que permite elegir a quien enviar, finalmente procede el ítem al participante, determinado por el campo especial __solicitante__. Nótese que es necesario usar el nombre completo del participante (es por eso que se usa role-ejemplo-solicitudes- antes del nombre del usuario). <set-nested path="scdetsol.__data__.txdesc.__disabled__" value="false" type="bool"/> <set-nested path="scdetsol.__data__.cbprio.__disabled__" value="false" type="bool"/> <set-nested path="scdetsol.__data__.txdetalle.__disabled__" value="false" type="bool"/> <set-nested path="cbenviar.__hidden__" value="true" type="bool"/> <subprocess ref="enviar_correo"/> <participant ref="role-ejemplo-solicitudes-${f:__solicitante__}" />

--El proceso luego sigue exactamente igual a lo visto en el proceso general. En el lenguaje de procesos de OpenWFE, los loops se hacen con notación similar a la de recursividad. <subprocess ref="enviar_correo"/> <set-nested path="scdetsol.__data__.txdesc.__disabled__" value="true" type="bool"/> <set-nested path="scdetsol.__data__.cbprio.__disabled__" value="true" type="bool"/> <set-nested path="scdetsol.__data__.txdetalle.__disabled__" value="true" type="bool"/> <set-nested path="cbenviar.__hidden__" value="false" type="bool"/> <participant ref="role-ejemplo-solicitudes-view:confirmadores" /> <if test="${f:cbenviar.__data__.__index__} == 0"> <!-- rechazado --> <subprocess ref="enviar_solicitud" /> <subprocess ref="destino_solicitud" /> </if> </sequence> </process-definition>

--Este proceso se encarga de activar la sección de informe (y desactivar la sección de evaluación para el caso en que es devuelto al destinatario) y luego de entregarlo a quien fue seleccionado en el combobox. Este es un ejemplo de utilización de un valor leído del formulario para indexar a otro. Finalmente el proceso envía al solicitante el resultado de la solicitud, y dependiendo de si este la aprueba o no, registra en base de datos o repite este proceso. <!-- Destino Solicitud --> <process-definition name="destino_solicitud"> <sequence> <subprocess ref="enviar_correo"/> <set-nested path="cbenviar.__hidden__" value="true" type="bool"/> <set-nested path="sceval.__hidden__" value="true" type="bool"/> <set-nested path="scinforme.__hidden__" value="false" type="bool"/> <participant ref=" role-ejemplo-solicitudes-${f:cbenviar.__data__.__items__.${f:cbenviar.__data__.__index__}}" /> <subprocess ref="enviar_correo"/> <set-nested path="sceval.__hidden__" value="false" type="bool"/> <participant ref=" role-ejemplo-solicitudes-${f:__solicitante__}" /> <if test="${f:sceval.__data__.ckaprobado.__data__}"> <!-- aprobado --> <subprocess ref="registrar" /> <subprocess ref="destino_solicitud" /> </if> </sequence> </process-definition>

--Este proceso se encarga de enviar un correo a una determinada dirección. Los parámetros configurados aquí son solo un ejemplo y podrían ser configurados apropiadamente antes de llamar el proceso. <!-- Envio correo --> <process-definition name="enviar_correo"> <sequence> <set field="__emailFrom__" value="sistema@localhost"/>

<set field="__emailTarget__" value="direccion@host.com"/> <set field="__emailSubject__" value="__emailSubject__"/> <set field="__emailContent__" value="__emailContent__"/>

<if test="${f:ckmail.__data__}"> <participant ref="email-agent" /> </if> </sequence> </process-definition>

--Finalmente este proceso ejecuta un Insert en una base de datos Access, almacenando los distintos campos en una tabla. Nuevamente esto es solo un ejemplo de cómo se podría usar un agente (incluido en el paquete de servidor de LoopFlow). <!-- Registrar historial en bd --> <process-definition name="registrar"> <sequence> <set field="__typedb__" value="access"/> <set field="__sql__" value="INSERT INTO solicitudes (solicitante, descripcion, detalle, informe, duracion, nota, observaciones) VALUES ('${f:__solicitante__}', '${f:scdetsol.__data__.txdesc.__data__}', '${f:scdetsol.__data__.txdetalle.__data__}', '${f:scinforme.__data__.txinforme.__data__}', '${f:scinforme.__data__.txduracion.__data__}', '${f:sceval.__data__.cbnota.__data__.__items__.${f:sceval.__data__.cbnota.__data__.__index__}}', '${f:sceval.__data__.txobd.__data__}')"/>

<set field="__dbName__" value="C:/openwfe/apre-scripts/ejemplo.mdb"/> <participant ref="sql-agent" /> </sequence> </process-definition> </process-definition>

Para mayor información sobre el lenguaje de definición de procesos, se

recomienda revisar la documentación de OpenWFE.