Regole Workflow

• Codice (campo CODE)

Questo campo identifica la regola di Workflow.

• Descrizione (campo INTIT)

Permette di definire una descrizione associata ad ogni scheda.

• Categoria (campo CATEG)

Questo campo permette di effettuare dei raggruppamenti per tipologia delle regole di workflow.

• Attivo (campo ENAFLG)

Fintanto che tale casella non è selezionata, la regola di Workflow non si attiva.

• Tipo evento (campo TYPEVT)

Il tipo evento Workflow può assumere i seguenti valori:

• Oggetto: si è in una funzione di tipo objet (gestione di una scheda in creazione, variazione, duplicazione, cancellazione...). Il codice evento corrisponde quindi al codice dell'oggetto.
• Entrata funzione: si attiva la regola all'entrata in un funzione del prodotto software. Il codice evento corrisponde al codice della funzione (un oggetto codificato XXX corrisponde alla funzione GESXXX, questo tipo d'evento può quindi anche essere utilizzato per gli oggetti).
• Stampa: si lancia una stampa, il cui codice può essere specificato nel campo codice evento.
• Fine job: si attiva un Workflow alla fine del job batch, il cui codice corrisponde al codice evento (occorre che il job batch in oggetto abbia la casella Messaggio utente selezionato, altrimenti ciò non funzionerà: un messaggio d'avviso segnala se non è il caso, senza pertanto impedire l'inserimento).
• Arresto job: Questa regola di Workflow viene attivata quando un utente decide, dal controllo dei job, d'arrestare un job batch, il cui codice corrisponde al codice evento. Invia una richiesta d'arresto al server batch, ed è il server che arresta il job. Tenuto conto del contesto d'esecuzione di tale evento, si è limitati nelle possibilità di attivazione. In questo modo:
• non si dispone delle variabili d'ambiente abituali (GUSER, per esempio), ma esclusivamente della registrazione corrente nella tabella ABATRQT d'abbreviazione [ABR].
• è possibile inviare soltanto un messaggio via posta (nessuna tabella di controllo non può essere aggiornata).
• Import/Export: questo tipo d'evento si attiva all'inizio (e/o alla fine) d'import (e/o d'export), il codice evento permette di indicare il modello utilizzato.
• Firma: questa regola viene attivata durante l'approvazione di un regola anteriore, il cui codice può essere fornito dal codice evento.
• Manuale: questa regola viene attivata sul percorso di un insieme di tabella descritte nel modello di dati. Tale percorso è attivato da un'operazione manuale, che può essere lanciata in batch. Ciò permette generalmente di attivare le regole Workflow legate a delle variazioni di campi nel database (la regola percorre le tabelle d'audit).
• Diversi: questa regola viene attivata sugli eventi particolari identificati da una lista finita di codici evento. Questi eventi possono sia essere generici per tutti i software scritti in tecnologia DiapasonX (per esempio connessione, sconnessione...), sia dipendere da una funzione propria al software utilizzato. Si troverà la lista degli eventi generici in un primo allegato di documentazione, e la liste degli eventi propri a ogni software in un secondo allegato di documentazione.

• Codice evento (campo CODEVT)

Questo campo permette di indicare il contesto attivante, secondo il tipo che è definito primariamente:

• per un tipo Oggetto, si fornisce il codice oggetto corrispondente.
• per un tipo Entrata funzione, si fornisce il codice funzione.
• per un tipo Stampa, si fornisce il codice stampa.
• per un tipo Fine job o Arresto job,
• per un tipo Import/Export, si fornisce il modello d'import/export utilizzato.
• per un tipo Firma, si fornisce il codice della regola all'origine della richiesta di firma/approvazione.
• Per un tipo Manuale, il codice non è inserito.
• Per un tipo Diversi, si fornisce il codice che identifica l'evento diverso all'origine dell'attivazione della regola.

Questo campo è obbligatorio soltanto per il tipo evento Diversi. Se non è indicato, l'evento si attiva in modo generico, sapendo che è sempre possibile testare maggiormente il contesto per essere selettivo (grazie generalmente alle variabili GFONCTION, GOLDETAT...)

• campo LIBEVT

Descrizione associata al codice inserito nel campo precedente.

• Operazioni (campo OPERATION)

Questo campo permette di precisare in maniera più dettagliata il contesto di esecuzione della regola di Workflow. A seconda dei tipi di Workflow, le informazioni inserite sono differenti:

• Per un tipo Oggetto, si inseriscono una serie di codici che permettono di definire le operazioni standard ( M come modifica, C come creazione...) e particolari ad un oggetto quando specificato (bottoni e voci di menù) che provocheranno l'attivazione dell'evento. Diventa allora obbligatorio almeno un codice operazione.
• Per un tipo Stampa, si inserisce C (o nulla) per la stampa o P per inviare la stampa in allegato.
• Per un tipo Firma, si inserisce il codice operazione collegato alla risposta data nel processo di firma.
• Per un tipo Import/Export, si precisa tramite un elenco di massimo 4 codici se l'attivazione della regola deve avvenire all'inizio e/o alla fine e se riguarda le operazioni di import e/o di export.
• Per tutti gli altri tipi, questo campo non viene inserito.

• Fine transazione (campo TYPDEC)

Nel caso di variazione di una scheda di un oggetto semplice, il workflow può essere attivato prima dell'aggiornamento delle tabelle (ciò permette di definire dei criteri sulle classi [F] e [M]) o alla fine della transazione di variazione (dopo l'aggiornamento delle tabelle).

• Modello di dati (campo MODELE)

E' possibile indicare qui un modello dati che definisce un insieme di tabelle collegate che devono essere disponibili nel contesto del Workflow. Nel caso di un evento di tipo Manuale, questo codice è obbligatorio per definire il contesto d'esecuzione: negli altri casi permette semplicemente di completare tale contesto.

• Regola assegnazione (campo REGLE)

Questo campo permette di definire delle regole d'assegnazione dei destinatari di Workflow in modo esterno alla regola. Fa riferimento ad una tabella di regole nelle quali si definisce una lista di campi sui quali verteranno i criteri d'assegnazione dei destinatari.

Una regola viene valorizzata al momento dell'attivazione del Workflow, in funzione del contesto, e restituisce uno o più utenti definiti da un riquadro di variabili locali [L]USER, ciò permette sia di fornire una lista di destinatari per un Workflow fornito, sia una sequenza di destinatari nel caso di una concatenazione di regole.

E' importante notare che:

• quando una regola d'assegnazione viene definita in una regola di Workflow, l'insieme dei destinatari è valutato in funzione dei criteri definiti e memorizzati nel riquadro [L]USER.
• quando nessuna regola d'assegnazione viene definita, ma la regola di Workflow è di tipo Firma, si eredita dei valori di [L]USER calcolati nell'evento all'origine della firma (questi valori sono salvati nello storico). Se si desidera che la regola d'assegnazione d'origine sia rivalorizzata (poiché sono cambiati dei valori di criterio), occorre indicare nuovamente tale regola d'assegnazione nella regola di Workflow.

• Tipo workflow (campo TYPWRK)

Definisce se si attiva un Workflow su ogni riga di dettaglio o esclusivamente sulla testata.

Questo campo non viene inserito, ma visualizzato:

• se nessuna regola d'assegnazione né nessun modello di dati sono definiti. Il tipo vale Riga se il Workflow è manuale, altrimenti è di tipo Testata.
• Se una regola d'assegnazione che utilizza una tabella rigaviene definita, il Workflow è di tipo Riga.

Se nessuna regola d'assegnazione viene fornita, ma viene associato un modello integrante dei legami (1,N), il campo viene inserito. E' possibile quindi scegliere se l'attivazione si effettua sulla riga o sulla testata (sapendo che le righe possono inoltre essere raggruppate per inviare una notifica per gruppo).

• Tabella riga (campo TABLIG)

Permette di definire il campo riga nel caso di una regola dove il contesto integra delle tabella di testata e delle tabelle di riga.

• campo ABRLIG

• Raggruppamento righe (campo GROUPE)

Questo campo permette di definire dei criteri di raggruppamento che forniscono una lista di espressioni (o di campi) separati da dei punti e virgola. Ciò permette di raggruppare delle righe di dettaglio per attivare soltanto un Workflow che ad ogni rottura sui valori definiti per quest'espressioni.

Ciò è possibile nei due casi:

• Quando un evento di Workflow utilizza un modello di dati facendo apparire dei legami (1,N), e il Workflow è di tipo riga (percorre l'integralità di riga della tabella riga scelta), si possono raggruppare le righe tra di esse.
• Quando un evento di Workflow è di tipo Manuale (l'insieme delle righe lette puà essere raggruppato allo stesso modo).

• Tipo (campo TYPCND)

Quando l'evento di Workflow è di tipo Riga, le condizioni possono condurre sia sulla testata, sia sulla riga, a seconda della scelta inserita qui.

• Condizioni (campo CONDITION)

Questi campi permettono condizioni complementari sotto forma di espressioni logiche (Formula di calcolo) che includono delle variabili in linea al momento dell'esecuzione della regola (contenuti di maschere di videate o di tabelle in linea, a seconda della descrizione del contesto...). Se queste condizioni sono tutte vere, il messaggio sarà inviato e/o la traccia scritta nel file di log.

Vi è da notare che, quando il contesto è di tipo testa e righe, è possibile filtrare una parte delle righe collegate ad una testata definendo delle condizioni righe per non tener conto delle righe per le quali la condizione è falsa. Se rimane almeno una riga interessata e le condizioni della testata sono vere, l'attivazione si effettuerà ugualmente.

• Attivazione mail (campo ENAMES)

Flag che permette d'attivare o meno dei messaggi indicati nella scheda corrispondante.

• Attivazione azione (campo ENAACT)

Flag che permette d'attivazione delle azioni indicate nella scheda corrispondente.

• Attivazione avanzamento (campo ENASUI)

Questo campo permette di definire delle regole d'assegnazione dei destinatari di Workflow in modo esterno alla regola. Fa riferimento ad una tabella di regole nelle quali si definisce una lista di campi sui quali verteranno i criteri d'assegnazione dei destinatari.

Una regola viene valorizzata al momento dell'attivazione del Workflow, in funzione del contesto, e restituisce uno o più utenti definiti da un riquadro di variabili locali [L]USER, ciò permette sia di fornire una lista di destinatari per un Workflow fornito, sia una sequenza di destinatari nel caso di una concatenazione di regole.

E' importante notare che:

• quando una regola d'assegnazione viene definita in una regola di Workflow, l'insieme dei destinatari è valutato in funzione dei criteri definiti e memorizzati nel riquadro [L]USER.
• quando nessuna regola d'assegnazione viene definita, ma la regola di Workflow è di tipo Firma, si eredita dei valori di [L]USER calcolati nell'evento all'origine della firma (questi valori sono salvati nello storico). Se si desidera che la regola d'assegnazione d'origine sia rivalorizzata (poiché sono cambiati dei valori di criterio), occorre indicare nuovamente tale regola d'assegnazione nella regola di Workflow.

• Messa a punto (campo DEBUG)

Flag che permette d'attivare un aiuto al collaudo. Durante l'esecuzione di una regola e se quest'opzione è attiva, il motore di workflow invia alla videata gli eventuali messaggi d'errore di valutazione sulle condizioni, il log e il messaggio.

• [Utilisation thème] (campo USETHEMEFL)

• Condizione (campo CNDDES)

Questo campo permette di definire una condizione logica. Se la valorizzazione di tale condizione ripropone un valore falso (nullo), la riga dei destinatari non è presa in considerazione dall'evento.

Vi è da notare che si dispone, oltre alle variabili legate al contesto dell'evento, del riquadro di variabili [L]COND, che permette, su una riga fornita, di fare riferimento alla condizione della riga numero N (N essendo l'indice).

Così, per esempio, se si esprime una condizione sulla prima riga del riquadro, e se sulla seconda riga si utilizza l'espressione: not [L]COND(1), ciò significa che i destinatari della seconda riga saranno presi in considerazione se la condizione della prima riga è falsa.

• Tipo (campo TYPDES)

Nell'applicazione Sage X3, il destinatario può essere legato a:

• un codice utente (si cercano allora le sue coordinate nella scheda utente),
• un terzo (si inserisce la sua mansione nel riquadro per identificare, sulla scheda terzi, quali sono i destinatari interessati).

Nell'applicazione Sage HRM, il destinatario può essere legato a:

• un terzo,
• un utente,
• un dipendente,
• un responsabile,
• un circuito gerarchico.

Nell'applicazione Sage Warehousing, il destinatario può essere legato a:

• un utente,
• un sito,
• un deposito,
• un trasportatore,
• un fornitore,
• un cliente società.

• Destinatari (campo DESTIN)

• Funzione (campo FNCDES)

Quest'informazione è inserita solo se il tipo destinatario è un terzo. Fa riferimento al menù locale che definisce le funzioni degli interlocutori nella scheda terzo.

• Invio mail (campo ENVOI)

Possono essere inseriti qui tre valori che riguardano i destinatari della riga:

• No: nessun messaggio sarà inviatogli.
• Sì: sarà inviatogli un messaggio in quanto destinatari principali.
• Copia: un messaggio è inviatogli in copia.

• Avanzamento (campo SUIVI)

Questo flag indica se i destinatari della riga vogliono ricevere una notifica nel loro piano di lavoro, a seconda del valore inserito:

• No: in questo caso, nessuna notifica sarà disponibile nel piano di lavoro.
• Sì: una notifica verrà loro inviata, potrà essere semplicemente visualizzata, per segnalare che l'utente l'ha letta.
• Con firma: questa notifica dovrà essere firmata da uno dei destinatari della riga.

Dal momento che una notifica viene inviata ad almeno una delle righe di destinatari, il folder Controllo definisce il testo che appare nel controllo, così come le risposte possono essere proposte in caso di richiesta di firma.

• Nature (campo NATURE)

Questo campo può essere utilizzato per classificare le righe di controllo a seconda della loro categoria. E' generalmente un criterio che può essere presente nel piano di lavoro o essere utilizzato come filtro su una delle sue schede.

• Opzione delegati (campo OPTDEL)

Questo campo permette di precisare il modo in cui si gestisce il fatto che il destinatario identificato nella riga sia assente (ovvero che si sia definito un utente delegato per un periodo di tempo che include il momento in cui la regola viene attivata). Se ha definito degli utenti delegati Con potere, il valore di questo campo definisce chi è destinatario della notifica o del messaggio:

• Se vale No, è coinvolto il solo destinatario indicato di origine.
• Se vale Tutti, sono coinvolti il destinatario di origine e tutti gli utenti definiti come delegati diretti del destinatario. Il destinatario diretto ed i suoi delegati diretti possono apporre la firma.
• Se vale Cascata, sono coinvolti il destinatario di origine, i suoi delegati, i delegati dei suoi delegati, ecc... Il destinatario, i suoi delegati diretti ed i delegati dei suoi delegati possono apporre la firma.
• Se vale Primo libero, è convolto il primo destinatario che non possiede delegati. Il destinatario diretto non può più firmare in questo caso se è presente almeno un delegato.

• [Email expéditeur] (campo SENDMAIL)

• Oggetto (campo OBJET)

Questo campo permette di definire il contenuto del campo Oggettodel messaggio inviato, sotto il formato di un'espressione calcolata che verrà valorizzata al momento dell'attivazione dell'evento.

• Testo (campo TEXTE)

Questo campo permette di definire il contenuto principale del messaggio. La sua scrittura si esegue sotto forma di testo libero includendo delle espressioni logiche (Formula di calcolo) tra due barre verticali che fungono da separatore. Si potrà ad esempio scrivere dei contenuti quali:

L'evento occorso il | num$(date$) | ha dato luogo a questo invio da parte di | GUSER |

Tag particolari:

"LIG" Permette di inserire l'espressione definita nel campo "Riga" della regola workflow.
"CLB/variabile clob o espressione" permette di inserire il contenuto di un campo clob nel testo. Questo numero di tag è limitato a 5.
"SIG/codice risposta/espressione testo" permette di visualizzare un link http nel testo. Il clic su questo link attiva la risposta della regola workflow. Questa parametrizzazione può essere operativa solo se i parametri generali supervisore del gruppo "WRK" sono indicati correttamente.

• Riga (campo TEXLIG)

L'espressione calcolata inserita in questo campo viene valutata, al momento dell'attivazione dell'evento, per ogni riga di dettaglio (nel caso di un Workflow di tipo riga con un raggrupamento dei dati). Ogni riga così calcolata viene inserita nel corpo del messaggio nel posto in cui si trova la formula |LIG|.

In funzione della lunghezza della riga, bisogna a volte aggiungere l'espressione "chr$(13)+chr$(10)" nella formula per forzare il salto di riga tra ogni riga.

• Invio (campo TYPMES)

Questo campo permette di indicare se l'invio deve essere effettuato localmente per posta (in interfaccia MAPI), dal server (via SMTP), o indifferentemente dall'uno o dall'altro (in quel caso un parametro generale denominato TYPMES lo definisce).

• Icona di ritorno (campo RETOUR)

Questa casella permette, se viene selezionata, d'inserire come allegato nel messaggio inviato un icona contenente il contesto che permette di richiamare la scheda (per doppio-click sopra). Attenzione, ciò funziona soltanto per una connessione in modalità client-server.

• Funzione di ritorno (campo BAKFCT)

Quando un'icona che permette di ritornare a Formula DiapasonX è allegata nel corpo del messaggio, tale campo permette d'indicare una funzione di ritorno diversa dalla funzione che ha attivato il Workflow.

Nel Workflow oggetto, nel caso della creazione o della variazione di una scheda, ciò permette, piuttosto di connettersi alla scheda di default, di andare su una scheda collegata (la scheda dell'utente che ha creato o modificato l'informazione che ha attivato il Workflow, per esempio).

• Chiave di legame (campo BAKLNK)

Questo campo permette, se la casella da selezionare Icona di ritorno è selezionata, di definire la funzione sulla quale l'utente sarà connesso dopo doppio-click sull'icona inclusa nel messaggio.

Se la funzione di ritorno è di tipo oggetto, è utile inserire la funzione soltanto se essa è diversa dall'oggetto d'origine.

Nel caso di un Workflow Manuale, il codice funzione è obbligatorio se l'icona di ritorno è inclusa (non può avere un valore di default in questo caso).

• Desktop (campo BAKSYRA)

• Chiave di legame (campo BAKLNKSYRA)

• Mobile (campo BAKMOBILE)

• Chiave di legame (campo BAKLNKMOBI)

• Messaggio modificabile (campo INTERV)

Questo flag permette di rendere il messaggio modificabile prima dell'invio: si apre allora una videata dove è possibile inserire delle modifiche. Ciò è possibile solo se l'attivazione del Workflow avviene in modo interattivo (viceversa, non si aprirà la finestra).

Attenzione, il fatto di contrassegnare questa casella provoca l'interruzione temporanea del processo di Workflow, questo in quanto si è in attesa di una validazione dell'utente. Se l'evento di workflow avviene quando vi è una transazione in corso (lo si può testare con la condizione adxlog<>0), tutti gli altri eventi di workflow contemporanei vengono bloccati da questo inserimento. Si consiglia caldamente quindi di contrassegnare questa casella solo su eventi che si riproducono fuori transazione (salvo eventualmente, in maniera temporanea, a scopi di debugging).

Un buon sistema per per assicurarsi contro questo rischio consiste nell'aggiungere, nei criteri di attivazione di un evento di questo tipo, la condizione adxlog=0 (cosa che consiste nell'inibire l'attivazione di eventi di tale tipo).

• Raggruppamento per destinatario (campo GRPENV)

Quando un evento di Workflow crea più notifiche, questa casella serve a raggruppare i messaggi creati dall'evento.

Ci sono più notifiche se il Workflow è di tipo "Riga", o se si tratta dell'evento straordinario "ANU" (attivato sull'annullo di firma).

Le notifiche vengono raggruppate tra di esse se hanno in comune le seguenti caratteristiche:

• l'emittente
• il tipo di server
• il contesto di ritorno
• l'oggetto del messaggio
• l'avviso di ricevimento
• i destinatari
• il flag firmatario

• Avviso di lettura (campo REQREC)

Questa casella permette, se è selezionata, d'inviare il messaggio richiedendo un avviso di ricevimento. Attenzione, ciò può funzionare soltanto se il messaggio viene inviato dalla postazione client e non dal server.

• File traccia collegato (campo TRACE)

Questa casella può essere selezionata soltato se l'evento attivante corrisponde alla fine di un job batch.

In questo caso, se viene selezionata, il file di traccia associato al job batch viene allegato al messaggio inviato.

• Documento da allegare (campo JOINT)

Questo campo permette d'associare un allegato al messaggio, fornendo un percorso d'accesso di rete sotto forma di un'espressione calcolata che verrà valorizzata al momento dell'attivazion dell'evento.

• Allegato (campo JOIOBJ)

Quando questa casella è selezionata, su un Workflow di tipo oggetto, gli allegati alla scheda possono essere inviati in allegato al messaggio.

• Tutti i tipi (campo ALLTYPJOI)

Questo campo permette, quando la casella Tutti i tipinon è selezionata, di definire un filtro sul tipo di allegati alla scheda (tabella diversa 902) che devono essere inviati con il messaggio.

• Tipo documento allegato (campo TYPJOI)

• Tutte le categorie (campo ALLCATJOI)

Questa casella è inserita soltanto:

• per un workflow di tipo oggetto
• per il quale la casella Allegato viene selezionata (invia degli allegati alla scheda come documenti legati al messaggio).

Se tale casella è selezionata, tutte le categorie di allegati dalla scheda che attiva il Workflow sono inviate come dei documenti allegati al messaggio. Altrimenti, si inserirà la relativa categoria.

• Categoria (campo CATJOI)

Questo campo permette, quando dei documenti allegati ad una scheda devono essere inviati in allegato al messaggio, di filtrare i documenti legati dalla propria categoria (menù locale 96)

• Testo avanzamento (campo TEXSUI)

Questo campo contiene un'espressione valorizzata al momento dell'attivazione del Workflow. Il risultato di questa valorizzazione è una stringa alfanumerica salvata nella variabile [AWS]TEXSUI. E' questo valore che è generalmente presentato nel monitor Workflow per valutare l'evento da firmare.

• Firma (campo FLGSIG)

Se questa casella è selezionata, il controllo dà luogo ad un processo di firma: si trovano quindi, nel riquadro situato in basso videata, un certo numero di scelte di firma possibili.

• Data limite (campo DELSIG)

Dal momento in cui la casella Firma viene selezionata, è possibile definire un'espressione di tipo data definendo la data al di là della quale si considera che esiste un ritardo se la firma non è stata effettuata.

Il valore del campo corrispondente viene salvato nel campo DATREL della tabella dei controlli AWRKHISSUI. Questo campo può essere gestito nel monitor Workflow, per definire un ordine di classificazione, una valorizzazione per uno stile particolare (condizione di tipo date$>=[AWS]DATREL+1, per esempio). Ma può anche essere gestito per una gestione di sollecito degli eventi in attesa di firma, sapendo che il campo [AWS]NBREL permette di contare i solleciti eventualmente effettuati.

• Contesto (campo VARCTX)

Questo riquadro contiene delle espressioni valorizzate al momento dell'attivazione di un Workflow. Queste variabili sono:

• salvate nello storico di Workflow (variabili da VALCTX1 a VALCTX15).
• utilizzabili nel contesto di firma/approvazione (riquadro variabili da CTX(1) a CTX(15)) associato all'evento originale, o ad un evento di Workflow consecutivo alla firma.

Il significato di tali variabili è che permettono di trasmettere delle informazioni che non sono situate nelle tabelle all'origine del contesto attivante, e quindi che non sono trasmesse automaticamente da un evento alla firma o all'evento successivo. Effettivamente, le tabella dell'oggetto, o quelle della regola d'assegnazione vengono trasmesse automaticamente; al contrario, non sono trasmesse:

• delle variabili globali (le variabili GUSER, GFONCTION, GABREV, CLEOBJ, per esempio, che definiscono rispettivamente l'utente corrente, la funzione corrente, il codice dell'oggetto, e la chiave corrente al momento dell'attivazione di un Workflow oggetto).
• delle variabili legate alle videate in linea
• delle espressioni quali date$, time$... che identificano il contesto d'attivazione

E' quindi questo tipo di variabile che è importante trasmettere tramite il contesto. Me è anche importante definire nel contesto delle variabili trasmesse, semplicemente per saperle visualizzare nel monitor di Workflow.

• Risposta (campo ACTSIG)

Questo campo fa riferimento alla tabella diversa numero 54 che definisce delle scelte possibili alla firma (per esempio Validazione, Rifiuto). Nel piano di lavoro delle firme (approvazioni), un click destro sulla riga da approvare permetterà di proporre tramite la lista delle scelte generate da tale lista, quelle per le quali la condizione è verificata.

• Operazione (campo OPESIG)

Questo codice operazione, definito dalla tabella diversa 55, è il codice che identifica la firma creata. Corrisponde al codice operazione utilizzato in un evento di tipo Firma consecutivo all'evento approvato. Vi è da notare che più righe possono portare le stesso codice operazione.

Questo codice non è memorizzato nello storico di Workflow al termine delle firma. E' effettivamente il valore del campo Risposta, che non ammette degli omonimi tra le diverse righe, che viene salvato).

• Condizione (campo CNDSIG)

Questa colonna contiene un'espressione logica valutata al momento della firma. Se la condizione viene realizzata, la risposta definita sulla riga viene proposta tramite le scelte possibili. Ciò permette, per esempio, di disporre di maggiori livelli di approvazione, in funzione del numero di firmatari che hanno già firmato (solo l'ultimo firmatario che ha accesso ad una firma che attiva un aggiornamento finale). Lo stesso, è possibile definire una scelta apparentemente impossibile (da una condizione sempre falsa di tipo 1=0). Tale scelta potrà essere forzata da un'azione di firma attivata da un altro evento di Workflow. E' così che sono elaborate, nelle parametrizzazioni standard, le escalation nei processi di firma.

• Causale (campo REANUM)

Questa colonna permette di indicare un numero di tabella diversa contenente delle causali di risposta.
Se viene alimentata, verrà richiesta una causale di risposta alla firma dell'evento.

• Campo aggiornato (campo FLDMAJ)

Questa colonna contiene il nome di un campo generato da una delle tabelle del contesto attivante. Questo campo va aggiornato dal valore calcolato a partire dall'espressione successiva, durante i processi di firma/approvazione. Così è possibile, per esempio, aggiornare un campo come ENAFLG (flag Attivo) dell'oggetto corrente durante un processo di firma.

• Valore (campo EXPVAL)

Questa colonna permette di definire l'espressione di un valore calcolato al momento della firma. Il valore corrispondente alla riga di risposta scelta sarà utilizzato, in caso di firma:

• sia per aggiornare il campo definito nella colonna precedente con questo valore.
• sia durante l'attivazione di eventuali azioni definiti nella scheda successiva. In questo caso, si ritrova il valore corrispondente nella variabile alfanumerica [L]RESULT.

• Modificabile (campo MODSIG)

Se questo campo vale Si, il valore calcolato nella colonna corrispondente viene proposto, dopo la scelta della firma, al fine di permettere un'eventuale modifica. Ciò permette per esempio di inserire una modifica dettagliata. Il valore che risulta dall'inserimento sarà utilizzato per realizzare l'aggiornamento se c'é n'é uno, e trasmette alla variabile [L]RESULT per gestione da un'azione complementare.

• Codice azione (campo ACTION)

Questo campo contiene un codice azione la cui esecuzione può essere attivata se vengono soddisfatte le condizioni. Vi è da notare che tale azione deve avere la casella Workflow selezionata, e che di conseguenza non può interagire con l'interfaccia utente (nessuna finestra associata).

• Attivazione (campo DECACT)

Questo campo, i cui valori sono definiti nel menù locale 2923, definisce le condizioni di attivazione del Workflow. Sono utilizzabili i seguenti valori:

• Inizio Workflow: l'azione è attivata all'inizio della composizione del testo del messaggio. Quando il Workflow è di tipo Riga, viene eseguita una volta per testata, prima della composizione del testo di testata. Le variabili ritornate dall'azione possono essere utilizzate nel testo del mail (ma per lo più per definire i destinatari o le condizioni dell'invio, che sono già valorizzate in questa fase).
• Fine Workflow: l'azione è attivata dopo l'invio del messaggio. Quando il Workflow è di tipo riga, quest'azione viene eseguita una volta per gruppi di righe.
• Pre-riga: l'azione viene attivata prima della lettura della prima riga, quando si ha un Workflow di tipo testata e righe. Ciò permette per esempio d'inizializzare delle variabili di totalizzazione per ottenere un totale delle righe, essendo la totalizzazione realizzata in un'azione Riga.
• Riga: l'azione viene attivata appena prima della composizione di ogni riga di messaggio, nel caso di un Workflow di tipo riga. Le variabili ritornate dall'azione possono quindi essere utilizzate nel testo riga.
• Firma: l'azione viene attivata dopo l'inserimento della firma (la variabile [L]RESULT generata da questo inserimento è quindi conosciuta), ma prima dell'aggiornamento (è possibile modificare tale valore durante l'azione). Nel caso di una firma, tutti gli aggiornamenti vengono realizzati in una sola transazione. Così, se un Rollback viene realizzato in una delle azioni attivate dall'evento, si ripristina la situazione di partenza per tutti gli aggiornamenti effettuati.

In caso generale, dal punto di vista transazionale, occorre notare che l'azione effettuata parte dalla transazione di Workflow del messaggio (se un Rollbackviene effettuato durante la composizione del messaggio, gli aggiornamenti fatti con l'azione vengono assegnati). Viene effettuata una transazione indipendente per controllo (ma tale transazione essendo realizzata dopo, i valori ritornati dall'azione possono essere utilizzati.

Nel caso particolare del Workflow su oggetto, tutto è effettuato in una sola transazione. In altro modo, se la creazione o la variazione di una scheda fallisce, viene effettuato un Rollback sull'insieme degli aggiornamenti attivati dalle azioni.

Lo stesso vale per il controllo: la transazione che segue l'inserimento del controllo include l'attivazione delle azioni.

• Condizione esecuzione (campo CONACT)

Si inserisce qui un'espressione logica, valorizzata nel contesto di attivazione dell'azione. Se il risultato della valorizzazione è vero (non nullo), l'azione viene attivata. Se il risultato è falso, l'azione non è attivata. Se non viene inserita nessuna espressione, l'azione è sempre attivata.

• Parametro (campo PARAM)

• Tipo (campo TYPPAR)

• Ritorno (campo ADRVAL)

• Valore parametro (campo PARVAL)

Si inserisce qui un'espressione valorizzata che viene trasmessa come argomento all'azione, o il codice di una variabile che conterrà un valore di ritorno (se l'argomento è di tipo Puntatore). Tutte le variabili del contesto di Workflow possono qui essere utilizzate.