2 Simbologia, Regole Fondamentali ed Operatori di Confronto

• 2.1 Start Event e Timer Start Event
• 2.2 End Event
• 2.3 Intermediate / Boundary Event Timer
• 2.4 Exclusive e Parallel Gateway
• 2.5 Conditional Task e Action Task
• 2.6 Connettori (connecting object)
• 2.7 Regole fondamentali
• 2.8 Operatori di Confronto: Descrizione e Utilizzo nelle Conditional Task
• 2.9 Operatori di Confronto: Regole di Utilizzo nelle Task di Condizione Iniziale
• 2.10 Configurazione Sezione "Quando eseguire il controllo" nella Task di Condizione Iniziale
• 2.11 Configurazione Sezione "Quando eseguire il controllo" nelle Conditional Task

2.1 Start Event e Timer Start Event

START EVENT

Rappresenta il punto univoco da cui ha inizio ogni singolo processo. Ciò significa che può esserne presente solamente uno in ogni singolo processo in quanto il flusso inizia da un solo punto.
Nota bene: deve essere sempre seguito da una task di controllo in quanto essa rappresenta la task in cui inserire le condizioni che, se verificate, faranno scatenare il processo.

Timer Start Event

Una tipologia particolare di timer è lo “Timer Start Event” che viene applicata sullo Start Event per permettere di far partire un determinato processo in un intervallo di tempo prestabilito. Può essere selezionato durante la modalità di modifica del diagramma premendo inizialmente sullo Start Event, poi sulla chiave inglese che compare tra le varie opzioni selezionabili e successivamente selezionando l’opzione “Timer Start Event”.
Nota bene: questa tipologia di start event deve essere seguita da una task di azione in quanto si possono solamente eseguire delle azioni.

Le altre tipologie di Start Event selezionabili non sono al momento implementate.

NOTA BENE: Dalla versione 24.08 sono state completamente rimosse.

2.2 End Event

END EVENT

Rappresenta il punto finale di un processo. A differenza del Start Event, può essere utilizzato più di una volta in un singolo processo, in quanto il flusso potrebbe finire in più punti.

2.3 Intermediate / Boundary Event Timer

INTERMEDIATE/BOUNDARY EVENT TIMER

Rappresenta un elemento molto utilizzato per la gestione delle tempistiche di svolgimento di task e processi.

Può essere selezionato in rapidamente dal menù a sinistra sempre durante la modalità di modifica del diagramma.

Esistono due gruppi di timer che si differenziano a seconda delle azioni da svolgere e dalle task/elementi coinvolti:

1) Intermediate Event Timer
2) Boundary Event Timer

1) INTERMEDIATE EVENT TIMER

Il primo gruppo è composto da diversi tipi di “Intermediate Event”e vengono utilizzati tra due task/elementi. Possono essere selezionati durante la modalità di modifica del diagramma premendo inizialmente sulla task o elemento da cui poi si deve passare al timer, poi sull’icona raffigurante due cerchi chiamata “Intermediate/Boundary Event Timer”.

A questo punto si deve selezionare il timer appena citato, cliccare sulla chiave inglese e poi selezionare una delle opzioni disponibili.

Timer Intermediate Catch Event

E’ un tipologia di timer utilizzata per attende un determinato periodo di tempo prima di passare alla task/elemento successivo.

Le altre tipologie di Intermediate Event selezionabili non sono al momento implementate.

NOTA BENE: Dalla versione 24.08 sono state completamente eliminate.

In fase di configurazione, cliccando sul simbolo del Timer Intermediate Catch Event, si apre l’interfaccia dedicata dove poter inserire le tempistiche di attesa e la data sulla quale basarsi.

All'interno della prima picklist partendo da sinistra, è possibile indicare se attendere la tempistica indicata PRIMA o DOPO rispetto alla data di riferimento.

Invece nella picklist successiva, vengono resi disponibili tre valori:

- Adesso -> come data di riferimenti prenderà la data-ora (timestamp) del momento preciso in cui il processi si posiziona sul timer.

- Data -> permette di inserire un data-ora statici

- Altro -> permette di inserire valori dinamici, quindi pescati dai campi data dei moduli coinvolti all'interno del processo.

2) BOUNDARY EVENT TIMER

Il secondo gruppo è composto da diversi tipi di “Boundary Event” che vengono utilizzati sulle task di controllo e si attivano nel momento in cui si rimane fermi su una task per un determinato periodo di tempo.

Possono essere selezionati durante la modalità di modifica del diagramma premendo inizialmente sulla task o elemento da cui poi si deve passare al timer, poi sull’icona raffigurante due cerchi chiamata “Intermediate/Boundary Event”.

A questo punto si deve selezionare il timer appena citato e trascinarlo su uno dei bordi della task di controllo interessata.

                                             

(N.B: Se si clicca semplicemente sull’icona verrà creato un “Intermediate Event” collegato alla task da una freccia. Se si vorrà utilizzare quel timer come Boundary Event sarà sufficiente eliminare la freccia e posizionare il timer sulla task interessata).

Una volta fatto questo si deve selezionare il timer, premere sulla chiave inglese e successivamente selezionare una tra le opzioni disponibili.

Timer Boundary Event

Permette di procedere con l’esecuzione delle task/elementi collegate al timer in base a quanto tempo il processo rimane fermo sulla task di controllo su cui si trova il timer stesso.

L’intervallo di tempo viene prestabilito durante la configurazione del timer.
Possono essere utilizzati solamente sulle task di controllo.

Le altre tipologie di Boundary Event selezionabili non sono al momento implementate.

NOTA BENE: Dalla versione 24.08 sono state completamente rimosse.

In fase di configurazione, cliccando sul simbolo del Timer Boundary Event, si apre l’interfaccia dedicata dove poter inserire le tempistiche di attesa.

2.4 Exclusive e Parallel Gateway

Exclusive Gateway

Permette di suddividere il flusso del processo in più rami differenti.
Deve essere obbligatoriamente preceduto da una task di controllo nella quale si definiscono i parametri per i quali si seguirà uno dei rami del Gateway.



Per essere utilizzato, durante la modalità di modifica del diagramma si deve premere sulla task di controllo e poi successivamente selezionare il simbolo del rombo chiamato “Gateway”.

E’ riportato qui di seguito un esempio di Exclusive Gatewy applicato.



Come tutte le altre simbologie può essere selezionata anche dal menù rapido presente a destra.

Parallel Gateway

Svolge la stessa funzione dell’ Exclusive Gateway con l’unica differenza che i rami vengono eseguiti tutti quanti in parallelo. Alla fine dei rami deve essere presente un’ Exclusive Gateway che funga da Gateway di chiusura del parallelo. Prima del Gateway di chiusura devono essere configurate tante task di controllo quanti sono i rami coinvolti.
Questa tipolgia di struttura permette di poter scegliere se proseguire con il flusso al completamento di alcuni rami specifici del Gateway oppure attendere il completamento di tutti i rami esistenti.

Nota bene:
-non possono essere utilizzati dei Parallel Gateway all’interno di altri Parallel Gateway
-più Parallel Gateway non posso avere un Exclusive Gateway di chisura condiviso.

Per essere utilizzato, durante la modalità di modifica del diagramma si deve premere sulla task e poi successivamente selezionare il simbolo del rombo chiamato “Gateway”.

E' riportato qui di seguito un esempio di Parallel Gateway applicato.



Le tipologie di Gateway riportate di seguito non sono al momento implementate.

NOTA BENE: Dalla versione 24.08 sono state completamente rimosse.

2.5 Conditional Task e Action Task

CONDITIONAL TASK

Rappresenta l’elemento utilizzato per lo svolgimento di azioni di creazione e controllo all’interno del flusso di un processo.



ACTION TASK

Per definire la tipologia di task, Vtenext mette a disposizione dei simboli utilizzabili per indicare l’azione svolta da ogni singola task.
Questi simboli possono essere selezionati durante la modalità di modifica del diagramma premendo sulla task e poi successivamente sulla chiave inglese che compare tra le varie opzioni selezionabili.

       

E’ importante precisare che questi simboli non vanno a condizionare il comportamento delle singole task, in quanto il loro scopo è semplicemente quello di mostrare un riferimento visivo iniziale che possa facilitare l’interpretazione delle singole task. Quindi sarà a discrezione dell’utente selezionare il simbolo più opportuno all’azione svolta da ogni determinata task.
Una volta selezionato, ogni simbolo verrà posizionato in alto a sinistra della task e sarà visibile durante la configurazione del processo.

Qui di seguito un esempio per ogni tipologia selezionabile:

Script Task

E’ consigliabile utilizzarla per indicare la creazione e l’aggiornamento di task.

Send Task

E’ consigliabile utilizzarla per indicare l’invio di mail e notifiche.

Receive Task

Non è presente un utilizzo particolare consigliato.

User Task

E’ consigliabile utilizzarla per indicare un’attività in carico all’utente.

Manual Task

E’ consigliabile utilizzarla per indicare un’attività in carico all’utente (process helper).

Business Rule Task

Non è presente un utilizzo particolare consigliato.

Service Task

E’ consigliabile utilizzarla per indicare il richiamo di Webservice esterni o SDK.

Gli unici due simboli che permettono invece di svolgere una determinata azione e che quindi condizionano il comportamento di una determinata task sono il “Call Activity” e il “Sub Process”.

Call Activity

Questo simbolo permette di svolgere un azione al momento non implementata.

NOTA BENE: Dalla versione 24.08 è stato completamente rimosso

Sub Process (collapsed)

Questo simbolo permette di richiamare e utilizzare un sotto processo.

2.6 Connettori (connecting object)

CONNETTORI (CONNECTIONG OBJECT)

Se in un processo gli elementi di flusso (eventi, attività o diramazioni) sono “ciò che avviene effettivamente”, essi devono essere logicamente collegati tra loro. A ciò servono i connettori.

I connettori devono sempre avere la direzione del flusso.

2.7 Regole fondamentali

1 - Alla creazione del processo, il sistema inserisce in automatico uno Start Event (per approfondimenti vedere capitolo 2.1), ovvero l'elemento che rappresenta il punto univoco da cui ha inizio ogni singolo processo.
Può esserne presente solamente uno in ogni singolo processo, in quanto, il flusso inizia da un unico punto. (Figura 1 e 2)



Figura 1



Figura 2

2 - Allo Start Event (per approfondimenti vedere capitolo 2.1) può essere collegata solamente una Conditional Task, ovvero una task di controllo nella quale poter definire le condizioni scatenanti del processo. (Figura 3 e 4)

Figura 3

Figura 4

La stessa logica vale per il Timer Start Event, con l'unica differenza che può essere collegata solamente una task di qualsiasi tipo tranne che Conditional Task. (Figura 5 e 6)

Figura 5

Figura 6

3 - Prima di un Exclusive o Parallel Gateway ci deve sempre essere una Conditional Task che permette di definire dei gruppi di condizioni sulla base dei quali il processo si suddividerà in più rami. (Figura 7 e 8)

Figura 7

Figura 8

2.8 Operatori di Confronto: Descrizione e Utilizzo nelle Conditional Task

Il sistema mette a disposizione diversi operatori di confronto da poter utilizzare all'interno delle Conditional Task, ovvero le tipologie di task che permettono di eseguire dei controlli sui campi dei moduli/form dinamiche coinvolte all'interno del processo.

ATTENZIONE! -> il sistema è "Case Sensitive", quindi gli stessi valori con maiuscole o minuscole differenti vengono trattati come se fossero diversi.
Esempio: "VTENEXT" e "vtenext" vengono visti dal sistema come valori diversi.

- "uguale" -> permette di verificare se il contenuto di un campo è uguale ad un valore statico specificato all'interno della condizione. (Figura 1)

Figura 1

NOTA BENE: il sistema non permette di confrontare più valori contemporaneamente sulla stessa riga, quindi in caso fosse necessario eseguire un controllo multiplo si dovranno creare delle condizioni separate (Figura 2 e 3)

Figura 2

Figura 3

- "diverso" ->permette di verificare se il contenuto di un campo NON è uguale ad un valore statico specificato all'interno della condizione. (Figura 4)

Figura 4

- "contiene" -> permette di verificare se all'interno di un campo è presente il valore statico specificato all'interno della condizione, a prescindere dalla posizione in cui si trovi. (Figura 5)

Prendendo come riferimento l'esempio riportato in Figura 5, nel caso in cui avessimo un'azienda chiamata "demo_vtenext", la condizione sarà verificata, in quanto, questa tringa contiene "vte".

Figura 5

Al contrario dell'operatore "uguale", il sistema permette di confrontare più valori contemporaneamente sulla stessa riga (Figura 6)

Figura 6

- "non contiene" -> permette di verificare se all'interno di un campo NON è presente il valore statico specificato all'interno della condizione, a prescindere dalla posizione in cui si trovi. (Figura 7)

Figura 7

Come per l'operatore "contiene", è possibile confrontare più valori contemporaneamente sulla stessa riga (che andranno inseriti separati con una virgola).

- "inizia per" -> permette di verificare se il contenuto di un campo inizia con il valore statico specificato all'interno della condizione. (Figura 8)

Figura 8

NOTA BENE: il sistema non permette di confrontare più valori contemporaneamente sulla stessa riga, quindi in caso fosse necessario eseguire un controllo multiplo si dovranno creare delle condizioni separate (prendere come riferimento Figura 2 e 3)

- "finisce con" ->permette di verificare se il contenuto di un campo finisce con il valore statico specificato all'interno della condizione. (Figura 9)

Figura 9

NOTA BENE: il sistema non permette di confrontare più valori contemporaneamente sulla stessa riga, quindi in caso fosse necessario eseguire un controllo multiplo si dovranno creare delle condizioni separate (prendere come riferimento Figura 2 e 3)

- "è cambiato in" -> permette di verificare se il contenuto del campo ha subito precisamente un cambiamento nel valore specificato all'interno della condizione (Figura 10)

Figura 10

Per tutte quelle tipologie di campi che potrebbero avere un valore non definito (testo, numero, data, relazionato a, ecc.), combinando l'operatore "è cambiato in" con l'operatore "diverso", è possibile configurare una condizione che permetta di captare la modifica del contenuto di un campo in un valore consistente di cui non si è a conoscenza. (Figura 11)

Figura 11

L'esempio mostrato in Figura 11 si traduce nella seguente frase: "Data di chiusura attesa è cambiato in un valore che non so definire ma, allo stesso tempo, quel valore è diverso da vuoto, quindi sarà per forza un valore consistente".

- "è cambiato da" -> permette di verificare se il contenuto del campo ha subito un cambiamento da un valore ad un altro, entrambi specificati all'interno della condizione (Figura 12)

Nel primo slot andrà specificato il valore che il campo aveva prima della modifica, mentre nel secondo slot andrà specificato il nuovo valore che è stato inserito.

Figura 12

- "maggiore di" -> permette di verificare se il contenuto di un campo numero/valuta presente è maggiore di un valore statico inserito specificato all'interno della condizione. (Figura 13)

Figura 13

- "maggiore o uguale" -> permette di verificare se il contenuto di un campo numero/valuta presente è maggiore o uguale ad un valore statico inserito specificato all'interno della condizione. (Figura 14)

Figura 14

- "minore di" -> permette di verificare se il contenuto di un campo numero/valuta presente è minore di un valore statico inserito specificato all'interno della condizione. (Figura 15)

Figura 15

- "minore o uguale" -> permette di verificare se il contenuto di un campo numero/valuta presente è minore o uguale ad un valore statico inserito specificato all'interno della condizione. (Figura 16)

Figura 16

2.9 Operatori di Confronto: Regole di Utilizzo nelle Task di Condizione Iniziale

Alcuni operatori di confronto vanno utilizzati con attenzione all'interno delle Task di "Condizione Iniziale", ossia quelle Conditional Task direttamente associate allo Start Event dentro alle quali vengono definite le condizioni che permettono al processo di scatenarsi o meno. (Figura 1 e 2).

Figura 1

Figura 2 (cliccare sull'immagine per una risoluzione grafica maggiore)

Nello specifico, nel caso in cui venga coinvolta nella condizione la fase di "modifica" (quindi selezionando una tra le seguenti voci: "alla modifica" ,"alla creazione e modifica", "ogni volta che la condizione risulti vera"), gli operatori di confronto "uguale", "diverso", "contiene", "non contiene", "inizia per", "finisce con", "maggiore di", "maggiore o uguale", "minore di", "minore o uguale" non posso essere utilizzati singolarmente, in quanto, si rischia di creare dei loop, ossia la partenza indesiderata ed incontrollata di più istanze dello stesso processo.
Questo perché, gli operatori di confronto appena citati guardano semplicemente se la condizione è verificata o meno, senza tenere in considerazione in quale salvataggio specifico quella condizione si è verificata la prima volta.

Per comprenderne al meglio il funzionamento, in Figura 3 viene riportato un esempio di Task di Condizione Iniziale NON configurata correttamente.



Figura 3 (cliccare sull'immagine per una risoluzione grafica maggiore)

La condizione "Tipo" = "Potenziale" verifica semplicemente se quel campo possiede quel specifico valore.
Impostando quindi singolarmente questa condizione e coinvolgendo la modifica (in questo caso selezionando la voce "alla creazione e modifica"), il processo non si scatenerà solamente nel salvataggio in cui verrà impostato il "Tipo" in "Potenziale" ma anche nei salvataggio successivi, fintanto che il campo "Tipo" manterrà quel specifico valore.

Proprio per ovviare a questa problematica, il sistema mette a disposizione gli operatori di confronto "è cambiato in" ed "è cambiato da" che consentono di far partire il processo solamente nel salvataggio in cui si è verificato il settaggio di quel specifico valore.

Quindi, configurando il processo come mostrato in Figura 4, il processo si scatenerà solamente nel salvataggio in cui verrà impostato il valore in "Potenziale".



Figura 4 (cliccare sull'immagine per una risoluzione grafica maggiore)

2.10 Configurazione Sezione "Quando eseguire il controllo" nella Task di Condizione Iniziale

All'interno delle delle Task di "Condizione Iniziale", ossia quelle Conditional Task direttamente associate allo Start Event dentro alle quali vengono definite le condizioni che permettono al processo di scatenarsi o meno, la sezione "Quando eseguire il controllo" viene presentata con i seguenti valori:

- "alla creazione" -> il processo si scatenerà solamente dopo la creazione di un record (istanza di un modulo)

- "alla creazione e modifica" -> il processo si scatenerà dopo la creazione o modifica di un record (istanza di un modulo), quindi di fatto in tutte le situazioni attualmente gestite nei processi.
NOTA BENE: l'eliminazione di un record è un situazione non gestita nei processi

- "alla modifica" -> il processo si scatenerà solamente dopo la modifica di un record (istanza di un modulo)

- "ogni volta che la condizione risulti vera" -> il processo si scatenerà al verificarsi delle condizioni (sempre dopo il salvataggio) inserite nella sezione "Condizioni".
Anche per gli altri valori è possibile inserire delle condizioni nella sezione "Condizioni", quindi questa voce risulta essere a tutti gli effetti analoga alla voce "alla creazione e modifica", questo perché viene coinvolta sia la creazione che la modifica.

- "solo che la prima volta che si scatena il processo" -> il processo si scatenerà sono la prima volta che si verificherà la condizione inserita nella sezione "Condizioni".
Successivamente, il processo non potrà mai più scatenarsi su quel specifico record (istanza di un modulo), anche se le condizioni configurate al suo interno si saranno verificate.

- "al lancio del sottoprocesso" -> viene utilizzata esclusivamente per la configurazione dei sotto-processi e permette di far scatenare il sotto-processo nel momento in cui viene eseguita la task di richiamo configurata nel processo padre.

- "in relazione con" -> permette di far scatenare il processo nel momento in cui viene instaurata una relazione tra due record (istanza di un modulo) di due moduli aventi una relazione N - N

Figura 1 (cliccare sull'immagine per una risoluzione grafica maggiore)

2.11 Configurazione Sezione "Quando eseguire il controllo" nelle Conditional Task

All'interno delle delle Conditional Task classiche, ossia quelle Task utilizzate per eseguire dei controlli all'interno del processo, la sezione "Quando eseguire il controllo" viene presentata con i seguenti valori:

- "alla modifica" -> il processo attenderà una modifica del record (istanza di un modulo) coinvolto prima di verificare le condizioni configurate all'interno della Conditional Task, anche se dovessero essere già verificate.

- "ogni volta che la condizione risulti vera" -> il processo verificherà nell'immediato le condizioni configurate all'interno della Conditional Task, proseguendo quindi con il flusso nel caso in cui dovessero essere già verificate.

Per comprenderne meglio il funzionamento, in Figura 1 viene mostrato un processo che, alla creazione di un'opportunità, esegue un controllo sullo Stadio di Vendita e si suddivide in due rami differenti. (Figura 1)

Figura 1

Nel caso in cui la Conditional Task "Controllo Stadio di Vendita" fosse stata impostata "alla modifica", anche se l'opportunità in creazione avrà lo "Stadio di Vendita" = "Aperta" o "Da Analizzare", il processo non considererà verificate le condizioni.
Questo perché verrà atteso un salvataggio successivo alla creazione dell'opportunità prima di verificare le condizioni configurate al suo interno. (Figura 2)

Figura 2

Invece nel caso in cui la Conditional Task "Controllo Stadio di Vendita" fosse stata impostata "ogni volta che la condizione risulti vera", se l'opportunità in creazione avrà lo "Stadio di Vendita" = "Aperta" o "Da Analizzare", il sistema eseguirà una verifica nell'immediato proseguendo quindi nel primo o secondo ramo nel caso in cui ci fossero delle condizioni verificate. (Figura 3)

Figura 3