Reglas Workflow

• Código (campo CODE)

Este campo identifica la regla de Workflow.

• Descripción (campo INTIT)

Permite definir una descripción asociada a cada ficha.

• Categoría (campo CATEG)

Este campo permite agrupar reglas de workflow según su tipología.

• Activo (campo ENAFLG)

Si esta casilla no está marcada, la regla de Workflow no se desencadenará.

• Tipo evento (campo TYPEVT)

El tipo de evento Workflow puede tomar los siguientes valores:

• Objeto: estamos en una función de tipo objeto (gestión de una ficha en creación, modificación, duplicación, supresión, etc.). El código de evento corresponde al código del objeto.
• Entrada función: se desencadena la regla al entrar en una función de la aplicación. El código de evento corresponde al código de la función (un objeto con código XXX corresponde a la función GESXXX; este tipo de evento también puede utilizarse para los objetos).
• Edición: se lanza un informe, cuyo código puede especificarse en el campo código evento.
• Fin de tarea: se desencadena un Workflow al final de la tarea batch, cuyo código corresponde al código de evento (es necesario que la tarea batch en cuestión tenga la casilla Mensaje usuario marcada, en caso contrario no funcionará : si no es el caso, aparecerá un mensaje de aviso, sin que esto impida la captura).
• Parado de la tarea: esta regla de Workflow se desencadena cuando un usuario decide, desde la supervisión de las tareas, detener una tarea batch cuyo código corresponde al código de evento. Se envía entonces una solicitud de parada al servidor batch, y es éste el que detiene la tarea. Teniendo en cuenta el contexto de ejecución de este evento, las posibilidades de desencadenamiento están limitadas. Así:
• las variables de entorno habituales no están disponibles (GUSER por ejemplo), sólo lo está el registro actual en la tabla ABATRQT de abreviatura [ABR].
• sólo se puede enviar un mensaje por la mensajería (no se pueden actualizar las tablas de seguimiento).
• Importación/Exportación: este tipo de eventos se desencadenan al inicio (y/o al final) de la importación (y/o de la exportación), y el código de evento permite precisar el modelo utilizado.
• Firma: esta regla se desencadena en el momento de la firma de una regla anterior, cuyo código puede venir dado por el código de evento.
• Manual: esta regla se desencadena por el barrido de un conjunto de tablas descritas en el modelo de datos. Este recorrido se desencadena por una operación manual, que puede ser lanzada en batch. Esto permite desencadenar las reglas Workflow vinculadas a las modificaciones de campos en la base (la regla recorre las tablas de auditoría).
• Varios: esta regla se desencadena por eventos particulares identificados por una lista definida de códigos de eventos. Estos eventos pueden ser bien genéricos para todas las aplicaciones escritas en tecnología safe (por ejemplo conexión, desconexión...), o bien depender de una función propia a la aplicación utilizada. Se encuentra la lista de los eventos genéricos en un primer anexo de documentación, y la lista de los eventos propios a cada aplicación en un segundo segundo anexo de documentación.

• Código evento (campo CODEVT)

Este campo permite precisar el contexto desencadenante según el tipo definido con anterioridad:

• para un tipo Objeto, se aporta el código del objeto que corresponde.
• para un tipo Entrada función, se aporta el código de la función.
• para un tipo Edición, se aporta el código del informe.
• para un tipo Fin de tarea o Parada de tarea, se aporta el código de la tarea batch.
• para un tipo Importación/Exportación, se aporta el modelo de importación/exportación utilizado.
• para un tipo Firma, se aporta el código de la regla en el origen de la solicitud de firma.
• Para un tipo Manual, el código no está capturado.
• Para un tipo Vario, se aporta el código que identifica el evento vario en el origen del desencadenamiento de la regla.

Este campo sólo es obligatorio para el tipo de evento Vario. Si no está indicado, el evento se desencadena de forma genérica, sabiendo que siempre es posible probar con anterioridad el contexto para ser selectivo (gracias a las variables GFONCTION, GOLDETAT...)

• campo LIBEVT

Título asociado al código introducido en la rúbrica anterior.

• Operaciones (campo OPERATION)

Este campo permite precisar de forma más afinada el contexto de ejecución de la regla de Workflow. Según los tipos de Workflow, los datos capturados son diferentes:

• Para un tipo Objeto, se captura una serie de códigos que permiten definir las operaciones estándares (M para modificación, C para creación, etc<.) y particulares para un objeto si éste está especificado (botones y elementos de menús) que provocan el desencadenamiento del evento. Es obligatorio al menos un código de operación.
• Para un tipo Firma, se captura el código de operación adjunto a la respuesta del proceso de firma.
• Para un tipo Importación/Exportación, se precisa mediante una lista de 4 códigos máximo si el desencadenamiento de la regla debe realizarse al inicio y/o al fin, y si afecta a las operaciones de importación/exportación.
• Para el resto de tipos, este campo no está capturado.

• Fin de transacción (campo TYPDEC)

En caso de modificación de una ficha de un objeto simple, el Workflow puede desencadenarse antes de la actualización de las tablas (lo que permite definir los criterios para las clases [F] y [M]) o al final de la transacción de modificación (después de la actualización de las tablas)).

• Modelo de datos (campo MODELE)

Aquí se puede indicar un modelo de datos que define un conjunto de tablas vinculadas que deben estar disponibles en el contexto del Workflow. En caso de ser un evento de tipo Manual, este código es obligatorio para definir el contexto de ejecución; en otros casos, permite simplemente completar este contexto.

• Regla de asignación (campo REGLE)

Este campo permite definir las reglas de asignación de los destinatarios de Workflow de forma externa a la regla. Hace referencia a una tabla de reglas en la que se define una lista de campos a los que afectarán los criterios de asignación de destinatarios.

Una regla se evalúa en el momento del desencadenamiento del Workflow, en función del contexto, y reenvía uno o varios usuarios definidos por un cuadro de variables locales [L]USER, lo que permite bien dar una lista de destinatarios para un Workflow dado, o una cadena de destinatarios si se trata de un encadenamiento de reglas.

Es importante señalar:

• que si una regla de asignación se define en una regla de Workflow, el conjunto de los destinatarios se evalúa en función de los criterios definidos y almacenados en el cuadro [L]USER.
• que si no se han definido reglas de asignación, pero la regla de Workflow es de tipo Firma, se heredan los valores de [L]USER calculados en el evento en el origen de la firma (estos valores se almacenan en el histórico). Si se desea que la regla de asignación de origen sea re-evaluada (por posible cambio de los valores de criterio), hay que indicar de nuevo la regla de asignación en la regla del Workflow.

• Tipo workflow (campo TYPWRK)

Define si se desencadena un Workflow en cada línea de detalle o sólo en la cabecera.

Este campo es de sólo lectura:

• si no se han definido ni ninguna regla de asignación ni ningún modelo de datos. El tipo es Línea si el Workflow es manual. En caso contrario, será de tipo Cabecera.
• Si se define una regla de asignación que emplee una tabla Línea, el Workflow será de tipo Línea.

Si no se da regla de asignación pero tiene asociado un modelo que integre los enlaces (1,N), se capturará el campo. Se puede escoger si el desencadenamiento se realizará en la línea o en la cabecera (sabiendo que las líneas pueden agruparse para enviar una notificación por grupo).

• Tabla línea (campo TABLIG)

Permite definir el campo línea en el caso de una regla en la que el contexto integra las tablas de cabecera y las tablas de línea.

• campo ABRLIG

• Agrupación de líneas (campo GROUPE)

Este campo permite definir los criterios de agrupación dando una lista de expresiones (o de campos) separados por ";". Esto permite agrupar las líneas de detalle para no desencadenar más que un Workflow en cada ruptura de los valores definidos por estas expresiones.

Esto es posible en dos casos:

• Cuando un evento de Workflow utiliza un modelo de datos que muestra los enlaces (1,N) y el Workflow es de tipo línea (barre la totalidad de la línea de la tabla escogida), se pueden agrupar las líneas entre sí.
• Cuando un evento de Workflow es de tipo Manual (el conjunto de las líneas leídas puede agruparse del mismo modo).

• Tipo (campo TYPCND)

Si el evento de Workflow es de tipo Línea, las condiciones pueden repercutir sobre la cabecera o sobre la línea, según la elección capturada aquí.

• Condiciones (campo CONDITION)

Estos campos permiten añadir condiciones en forma de expresiones lógicas (Fórmula de cálculo) que incluyen variables en línea en el momento de la ejecución de la regla (contenidos de máscaras de pantallas o de tablas en línea, según la descripción del contexto, etc.). Si estas condiciones se cumplen, se envía el mensaje y/o se escribe la traza en el fichero log.

Hay que tener en cuenta que si el contexto es de tipo cabecera de líneas, se puede filtrar una parte de las líneas vinculadas a una cabecera definiendo condiciones de líneas para no tener en cuenta las líneas para las que la condición es falsa. Si queda al menos una línea afectada y las condiciones de cabecera son ciertas, el desencadenamiento se realizará igualmente.

• Activación mail (campo ENAMES)

Indicador que permite activar o no el envío de los mensajes indicados en la pestaña correspondiente.

• Activación acción (campo ENAACT)

Indicador que permite activar el desencadenamiento de las acciones indicadas en la pestaña correspondiente.

• Activación seguimiento (campo ENASUI)

Este campo permite definir las reglas de asignación de los destinatarios de Workflow de forma externa a la regla. Hace referencia a una tabla de reglas en la que se define una lista de campos a los que afectarán los criterios de asignación de destinatarios.

Una regla se evalúa en el momento del desencadenamiento del Workflow, en función del contexto, y reenvía uno o varios usuarios definidos por un cuadro de variables locales [L]USER, lo que permite bien dar una lista de destinatarios para un Workflow dado, o una cadena de destinatarios si se trata de un encadenamiento de reglas.

Es importante señalar:

• que si una regla de asignación se define en una regla de Workflow, el conjunto de los destinatarios se evalúa en función de los criterios definidos y almacenados en el cuadro [L]USER.
• que si no se han definido reglas de asignación, pero la regla de Workflow es de tipo Firma, se heredan los valores de [L]USER calculados en el evento en el origen de la firma (estos valores se almacenan en el histórico). Si se desea que la regla de asignación de origen sea re-evaluada (por posible cambio de los valores de criterio), hay que indicar de nuevo la regla de asignación en la regla del Workflow.

• Depuración (campo DEBUG)

Indicador que permite activar una ayuda para la actualización. Durante la ejecución de una regla y si esta opción está activa, el motor de workflow muestra en pantalla los posibles mensajes de error de evaluación sobre las condiciones, el log y el mensaje.

• Usar tema (campo USETHEMEFL)

• Condición (campo CNDDES)

Este campo permite definir una condición lógica. Si la evaluación de esta condición reenvía un valor falso (es decir, nulo), la línea de destinatarios no quedará afectada por el evento.

Hay que tener en cuenta que se dispone, aparte de las variables vinculadas al contexto del evento, del cuadro de variables L]COND, que permite, en una línea dada, hacer referencia a la condición de la línea número N (N es el índice).

Así, por ejemplo, si se expresa una condición en la primera línea del cuadro, y en la segunda línea, se utiliza la expresión: not [L]COND(1), significa que los destinatarios de la segunda línea se tendrán en cuenta si la condición de la primera línea es falsa.

• Tipo (campo TYPDES)

Un destinatario puede estar vinculado a un código de usuario (se buscan sus coordenadas en la ficha de usuario), o a un tercero (en este caso, se captura su función en el cuadro para identificar en la ficha terceros a los posibles destinatarios).

• Destinos (campo DESTIN)

• Función (campo FNCDES)

Esta información sólo se indica si el tipo de destinatario es un tercero. Hace referencia al menú local que define las funciones de los interlocutores en la ficha terceros.

• Envío mail (campo ENVOI)

Aquí pueden capturarse tres valores concernientes a los destinatarios de la línea:

• No: no se enviará ningún mensaje.
• Sí: se envía un mensaje a los destinatarios principales.
• Copia: se envía un mensaje en copia.

• Seguimiento (campo SUIVI)

Este indicador precisa si los destinatarios de la línea recibirán una notificación en su plan de trabajo, según el valor capturado:

• No: en este caso, ninguna notificación estará disponible en el plan de trabajo.
• Sí: se les enviará una notificación; ésta podrá ser simplemente vista para indicar que el destinatario la ha leído.
• Con firma: esta notificación deberá ser firmada por uno de los destinatarios de la línea.

En cuanto se envíe una notificación a por lo menos una de las líneas de destinatarios, la pestaña Seguimiento definirá el texto que aparecerá en el seguimiento, así como las respuestas que se podrán dar en caso de solicitud de firma.

• Naturalezas (campo NATURE)

Este campo puede ser utilizado para clasificar las líneas de seguimiento según su categoría. Es un criterio que puede figurar en el plan de trabajo o ser utilizado como filtro en una de sus pestañas.

• Opción delegación (campo OPTDEL)

Este campo permite precisar la forma en la que se gestiona el hecho de que el destinatario identificado en la línea esté ausente (es decir, el hecho de que haya definido un usuario delegado para un periodo de tiempo que incluye el momento en el que se desencadena la regla). Si ha definido usuarios delegados Con poder, el valor de este campo define quién es el destinatario de la notificación o del mensaje:

• Si es No, sólo el destinatario indicado originalmente está afectado.
• Si es Todos, los afectados serán el destinatario inicial y todos los usuarios definidos como delegados.
• si es Cascada, el destinatario, sus delegados, los delegados de sus delegados, etc. están afectados.
• Si es Primero libre, el primer destinatario que no tenga delegado está afectado.

• E-mail emisor (campo SENDMAIL)

• Objeto (campo OBJET)

Este campo permite definir el contenido del campo Objetodel mensaje enviado, en forma de una expresión calculada que se evaluará en el momento del desencadenamiento del evento.

• Texto (campo TEXTE)

Este campo permite definir el contenido principal del mensaje. Se realiza en forma de un texto libre que incluye expresiones lógicas (Fórmula de cálculo) entre dos barras verticales que sirven como separadores. De este modo, por ejemplo, se podrán escribir contenidos como:

el evento ocurrido el | num$(date$) | dio lugar a este envío por | GUSER |

Etiquetas específicas:

"LIG" Permite insertar la expresión definida en el campo "Línea" de la regla workflow.
"CLB/variable clob o expresión" permite insertar el contenido de un campo clob en el texto. Este número de etiquetas está limitado a 5.
"SIG/código respuesta/expresión texto" permite mostrar un enlace http en el texto. El clic en este enlace desencadena la respuesta de la regla de workflow. Esta parametrización sólo puede aplicarse de forma óptima si los parámetros supervisor del grupo "WRK" se indican correctamente.

• Línea (campo TEXLIG)

La expresión calculada introducida en este campo se evalúa, en el momento del desencadenamiento del evento, para cada línea de detalle (en el caso de un Workflow de tipo línea con una agrupación de datos). Cada línea calculada de este modo se inserta en el cuerpo del mensaje en el lugar donde se encuentra la fórmula |LIG|

• Envío (campo TYPMES)

Este campo permite indicar si se debe realizar el envío localmente por medio del puesto (utilizando la interfaz MAPI), desde el servidor (mediante SMTP) o indistintamente desde el uno o el otro (en este caso, un parámetro general denominado TYPMES lo define).

• Icono de retorno (campo RETOUR)

Esta casilla permite, si está marcada, insertar como documento adjunto en el mensaje enviado, un icono con el contexto que permite volver a llamar la ficha (haciendo doble clic en el icono). Esto sólo funcionará si la conexión está en modo cliente-servidor.

• Función de devolución (campo BAKFCT)

Cuando un icono que permite volver a Sage X3 está adjunto al cuerpo del mensaje, este campo permite indicar una función de retorno diferente de la función que ha desencadenado el Workflow.

En Workflow objeto, si se trata de la creación o modificación de una ficha, esto permite, en vez de conectarse a la ficha por defecto, ir a la ficha vinculada (la ficha de usuario que ha creado o modificado la información que ha desencadenado el Workflow, por ejemplo).

• Clave de vínculo (campo BAKLNK)

Este campo permite, si la casilla Icono de retorno está marcada, definir la función a la que el usuario se conectará haciendo doble clic sobre el icono incluido en el mensaje.

Si la función de retorno es de tipo objeto, no tendrá ninguna utilidad capturar la función más que si ésta es diferente del objeto de origen.

En el caso de un Workflow Manual, el código de función es obligatorio si el icono de retorno está incluido (no puede tener valor por defecto en este caso).

• Desktop (campo BAKSYRA)

• Clave de vínculo (campo BAKLNKSYRA)

• Móvil (campo BAKMOBILE)

• Clave de vínculo (campo BAKLNKMOBI)

• Mensaje modificable (campo INTERV)

Este indicador permite que el mensaje pueda modificarse antes del envío: se abre una pantalla para capturar las modificaciones. Esto sólo es posible si el desencadenante de Workflow se realiza de forma interactiva (en caso contrario, la ventana no se abrirá).

• Agrupación por destinatario (campo GRPENV)

Si un evento de Workflow crea varias notificaciones, esta casilla sirve para agrupar los mensajes creados para el evento.

Si el Workflow es de tipo línea, se producirán varias notificaciones, o si se trata del evento especial "ANU" (desencadenado tras la cancelación de firma).

Las notificaciones se agrupan entre ellas si tienen las siguientes características en común:

• el emisor
• el tipo de servidor
• el contexto de retorno
• el objeto del mensaje
• el acuse de recibo
• los destinatarios
• el flag de firma

• Acuse lectura (campo REQREC)

Esta casilla permite, si está marcada, enviar el mensaje con un acuse de recibo. Atención, esta solicitud de acuse de recibo sólo puede funcionar si el mensaje se envía desde el puesto cliente y no desde el servidor.

• Fichero traza vinculado (campo TRACE)

Esta casilla sólo puede marcarse si el evento desencadenante corresponde al final de una tarea batch.

En este caso, si está marcada, el fichero traza asociado a la tarea batch irá adjunto al mensaje enviado.

• Documento a adjuntar (campo JOINT)

Este campo permite asociar un documento adjunto al mensaje, proporcionando un camino de acceso a la red en forma de una expresión calculada que se evaluará en el momento del desencadenamiento del evento.

• Documento adjunto (campo JOIOBJ)

Cuando esta casilla está marcada, en un Workflow de tipo objeto, los documentos adjuntos a la ficha pueden ser enviados como adjuntos al mensaje.

• Todos los tipos (campo ALLTYPJOI)

Este campo permite, si la casilla Todos los tipos no está marcada, definir un filtro para el tipo de documentos adjuntos a la ficha (tabla varia 902) que deben enviarse con el mensaje.

• Tipo documento adjunto (campo TYPJOI)

• Todas las categorías (campo ALLCATJOI)

Esta casilla sólo se indica:

• para un Workflow de tipo objeto
• para el que se ha marcado la casilla Documento adjunto (envío de los documentos adjuntos a la ficha como documentos vinculados al mensaje).

Si esta casilla está marcada, todas las categorías de documentos adjuntos a la ficha que desencadenan el Workflow se envían como documentos adjuntos al mensaje. En caso contrario, se capturaría la categoría necesaria.

• Categoría (campo CATJOI)

Este campo permite, si los documentos adjuntos a una ficha deben enviarse como adjuntos al mensaje, filtrar los documentos por su categoría (menú local96)

• Texto seguim (campo TEXSUI)

Este campo contiene una expresión evaluada en el momento del desencadenamiento del Workflow. El resultado de esta evaluación es una cadena alfanumérica almacenada en la variable [AWS]TEXSUI. Este valor es el que aparecerá normalmente en el monitor Workflow para calificar el evento a firmar.

• Firma (campo FLGSIG)

Si esta casilla está marcada, el seguimiento da lugar a un proceso de firma: aparece entonces en el cuadro, en la parte inferior de la pantalla, cierto número de firmas posibles.

• Fecha límite (campo DELSIG)

Una vez marcada la casilla Firma, se puede definir una expresión de tipo fecha que defina la fecha más allá de la cual se considera que hay retraso si no se ha realizado la firma.

El valor del campo correspondiente se almacena en el campo DATREL de la tabla de seguimientos AWRKHISSUI. Este campo puede utilizarse en el monitor Workflow para definir un orden de clasificación, una valoración por un estilo particular (condición de tipo date$>=[AWS]DATREL+1, por ejemplo). Pero también puede utilizarse para una gestión de relanzamiento de eventos en espera de firma, puesto que el campo [AWS]NBREL permite contar los relanzamientos realizados.

• Contexto (campo VARCTX)

Este cuadro contiene expresiones evaluadas en el momento de desencadenamiento de un Workflow. Estas variables:

• se almacenan en el histórico de Workflow (variables VALCTX1 a VALCTX15).
• se pueden utilizar en el contexto de firma (cuadro de variables CTX(1) a CTX(15) asociado al evento original o a un evento de Workflow posterior a la firma.

El interés de estas variables es que permiten transmitir datos que no aparecen en las tablas en el origen del contexto desencadenante, y que por tanto no se transmiten automáticamente de un evento a la firma o al evento siguiente. Las tablas del objeto o las de la regla de asignación se transmiten automáticamente; en cambio, no se transmiten:

• las variables globales (las variables GUSER, GFONCTION, GABREV, CLEOBJ, por ejemplo, que definen respectivamente al usuario actual, la función actual, el código del objeto y la clave actual en el momento de desencadenamiento de un Workflow objeto).
• variables vinculadas a las pantallas en línea
• expresiones como date$, time$... que definen el contexto del desencadenamiento

Por tanto, este tipo de variable es el más interesante de transmitir a través del contexto. Pero también es interesante definir en el contexto las variables transmitidas por otra parte en el contexto, simplemente para saber visualizarlas en el monitor de Workflow.

• Respuesta (campo ACTSIG)

Este campo hace referencia a la tabla varia número 54, que define las opciones posibles en el momento de la firma (por ejemplo Validación, Rechazo). En el plan de trabajo de firmas, al hacer clic con el botón derecho en la línea a firmar, se podrá proponer dentro de la lista de opciones procedentes de esta lista, las opciones para las que se verifique la condición.

• Operación (campo OPESIG)

Este código de operación, definido por la tabla varia 55, es el código que califica la firma. Corresponde al código de operación utilizado en un evento de tipo Firma consecutivo al evento firmado. Hay que tener en cuenta que varias líneas pueden llevar el mismo código de operación.

Este código no se almacena en el histórico de Workflow tras la firma. Es el valor del campo Respuesta, que no admite homónimos entre las distintas líneas, que está almacenado.

• Condición (campo CNDSIG)

Esta columna contiene una expresión lógica evaluada en el momento de la firma. Si se da esta condición, se propondrá entre otras opciones la respuesta definida en la línea. Esto permite, por ejemplo, disponer de varios niveles de firma, en función del número de firmas que ya hayan sido realizadas (la única firma que desencadena la actualización definitiva es la última). Del mismo modo, es posible definir una opción al parecer imposible (por una condición siempre falsa de tipo 1=0). Esta opción podrá ser forzada por una acción de firma desencadenada por otro evento de Workflow. De este modo se tratan, según los parámetros estándares, las escaladas en los procesos de firma.

• Motivo (campo REANUM)

Esta columna permite indicar un número de tabla varia que contiene motivos de respuesta.
Si se indica, se solicitará un motivo de respuesta al firmar el evento.

• Campo actualizado (campo FLDMAJ)

Esta columna contiene el nombre de un campo procedente de una de las tablas del contexto desencadenante. Este campo será actualizado por el valor calculado a partir de la expresión siguiente, en el momento del proceso de firma. Así podemos, por ejemplo, actualizar un campo como ENAFLG (indicador Activo) del objeto actual en el momento de un proceso de firma.

• Valor (campo EXPVAL)

Esta columna permite definir la expresión de un valor calculado en el momento de la firma. El valor correspondiente a la línea de respuesta escogida será el utilizado, en caso de firma:

• bien para actualizar el campo definido en la columna anterior con este valor.
• bien en el inicio de posibles acciones definidas en la pestaña siguiente. En este caso, se recupera el valor correspondiente en la variable alfanumérica [L]RESULT.

• Modificable (campo MODSIG)

Si este campo tiene el valor Sí, se propone el valor calculado en la columna correspondiente, tras la elección de la firma, para permitir una posible modificación. Esto permite por ejemplo capturar un motivo detallo. El valor resultante de la captura será utilizado para realizar la actualización si existe, y transmitirlo a la variable [L]RESULT para su utilización en una acción complementaria.

• Código acción (campo ACTION)

Este campo contiene un código de acción cuya ejecución puede desencadenarse si están cumplidas las condiciones. Hay que tener en cuenta que para que se produzca esta acción, la casilla Workflow debe estar marcada, y por tanto, no puede interaccionar con la interfaz usuario (no hay ventana asociada).

• Desencadenamiento (campo DECACT)

Este campo, cuyos valores están definidos por el menú local 2923, define las condiciones de desencadenamiento del Workflow. Se pueden utilizar los valores siguientes:

• Inicio Workflow: la acción se desencadena al inicio de la constitución del texto del mensaje. Si el Workflow es de tipo Línea, sólo se ejecutará una vez por cabecera, antes de la constitución del texto de la misma. Las variables devueltas por la acción pueden utilizarse en el texto del mail (pero más aún para definir los destinatarios o las condiciones del envío, que en este punto ya han sido evaluadas).
• Fin Workflow: la acción se desencadena tras el envío del mensaje. Si el Workflow es de tipo línea, esta acción sólo se ejecuta una vez por grupo de líneas.
• Antes de línea: la acción se desencadena antes de la lectura de la primera línea, si hay Workflow de tipo cabecera y líneas. Esto permite por ejemplo, inicializar variables de acumulación para obtener un total de líneas. El cúmulo se realiza en la acción Línea.
• Línea: la acción se desencadena justo antes de la constitución de cada línea de mensaje, en el caso de un Workflow de tipo línea. Las variables devueltas por la acción pueden utilizarse en el texto línea.
• Firma: la acción se desencadena tras la introducción de la firma (la variable [L]RESULT procedente de esta captura es conocida), pero antes de la actualización (se puede modificar este valor durante la acción). En el caso de una firma, todas las actualizaciones se realizan en una sola transacción. De esta manera, si un Rollback se realiza en una de las acciones desencadenadas por el evento, se vuelve a la situación inicial para todas las actualizaciones realizadas.

En el caso general del punto de vista de la transacción, hay que tener en cuenta que la acción forma parte de la transacción de Workflow del mensaje (si se realiza un Rollback en el momento de la constitución del mensaje, las actualizaciones realizadas en la acción se verán afectadas). Se realizará una transacción independiente para el seguimiento (pero al realizarse esta transacción a continuación, los valores que aporta la acción pueden utilizarse).

En el caso particular del Workflow en objeto, todo se realiza en una sola transacción. Dicho de otro modo, si la creación o la modificación de una ficha no se realiza satisfactoriamente, se realiza un Rollback sobre el total de las actualizaciones llevadas a cabo por las acciones.

Para el seguimiento, el proceso es similar: la transacción que sigue a la captura del seguimiento incluye el desencadenamiento de las acciones.

• Condición de ejecución (campo CONACT)

Aquí se captura una expresión lógica, evaluada en el contexto de desencadenamiento de la acción. Si el resultado de la evaluación es verdadero (es decir, no nulo), la acción se desencadenará. Si el resultado es falso, la acción no se desencadenará. Si no se ha capturado ninguna expresión, la acción se desencadenará igualmente.

• Parámetro (campo PARAM)

• Tipo (campo TYPPAR)

• Retorno (campo ADRVAL)

• Valor parámetro (campo PARVAL)

Aquí se captura una expresión evaluada que se transmite como un argumento a la acción en la que el código de una variable tendrá un valor de retorno (si el argumento es de tipo Puntero). Pueden utilizarse todas las variables del contexto de Workflow.