Tag: bpm

In questo articolo vogliamo approfondire le caratteristiche principali processi e dei modelli di processo di appian. Daremo i primi cenni delle componenti fondamentali.

I processi permettono di definire nel nostro BPM dei flussi di lavoro complessi per eseguire determinate attività considerando una serie di task.

Per capire bene alcune caratteristiche di Appian è importante approfondire le caratteristiche principali processi e dei modelli di processo di appian, pertanto effettuiamo una prima importante distinzione tra Modello di processo e Processo.

Modelli di Processo e Processo

I processi non sono oggetti autonomi, ma si basano su uno “scheletro” ovvero i modello di processo: tale oggetto permette di definire le operazioni che verranno eseguite dal processo. Per chi conosce Java/.Net possiamo dire tranquillamente che un processo è un’istanza del modello di processo.

Per chi non conosce Java/.NET possiamo paragonare la relazione a un percorso stradale:

• Il modello di processo è un po’ come una mappa ci permette di andare dal punto A al punto B, definendo una serie di “alternative” da prendere in considerazione nel caso un semaforo rosso, traffico oppure un incidente.
• il processo è un viaggio che eseguiamo in un deteminato momento partendo da A e al punto B, tutte le scelte possibili e le scelte che abbiamo faranno comunque parte del processo anche se non le dovessimo seguire.

Un processo sufficientemente lungo comporta scelte, fermate come “i rifornimenti”, seguire determinati percorsi autostradali e a volte passare per dei telepass. Possiamo paragonare le scelte a dei gateway e ogni attività ad un task, questi possono essere classificati, in prima battuta, in due tipologie:

• eseguiti dal sistema
• eseguiti dall’utente

I task eseguiti dal sistema si definiscono “unattended” mentre i task eseguiti da un utente sono “attended”.
Un task “attended”, seguendo il nostro esempio, può essere il rifornimento del carburante. Un task “unattended” può essere tranquillamente il pagamento del casello autostradale mediante il telepass.

Un modello di processo deve avere : un nome, un inizio e una fine collegati tra di loro mediante un arco. Notiamo che i punti di inizio e fine sono a tutti gli effetti dei task unattended.

Lo user input task

Un buon esempio di un’attività attended è l’user input task.

Tale task mostra un’interfaccia su cui l’utente opera e si riterrà concluso quando ne viene effettuato “il submit”. Per effettuare un submit occorre cliccare su un tasto avente proprietà di submit (o invio), avendo cura di aver superato la validazione delle form.

Ad esempio, si impostia la proprietà submit su un bottone in questo modo:

a!buttonLayout(
          secondaryButtons: a!forEach(
            items: local!styles,
            expression: a!buttonWidget(
              size: local!size,
              style: fv!item,
              submit: true()
            )
          )
)

Impostiamo la proprietà submit impostato a true il valore della proprietà submit del pulsante.

Lo start form

Dal nodo iniziale parte il nostro processo, che può avviarsi con o senza interfaccia, o più propriamente una start form.
Attenzione, quando chiamiamo il nostro processo ed esso è con una start form, il processo non è ancora partito! il processo partirà soltanto una volta effettuato il submit!

Il submit indica ad Appian di prelevare i risultati della nostra form e passarle, a sua volta, al processo e permettergli di avviarsi.

Le interfacce in Appian si scrivono in SAIL e quindi sono soggette alle stesse proprietà di cui abbiamo discusso in precedenza.

Approfondiremo in seguito il meccanismo di passaggio delle variabili ai processi.

In questo articolo approfondiamo le caratteristiche principali della componente “Codice” del BPM, delineando le caratteristiche che lo rendono lowcode.

Nel precedente Articolo abbiamo visto le componenti principali di Appian che lo caratterizzano, qui approfondiamo le caratteristiche principali della componente “Codice” del BPM, ovvero SAIL delineando le caratteristiche che lo rendono lowcode.

SAIL è lowcode

Abbiamo già illustrato che Appian ha un suo linguaggio proprietario, SAIL, che di fatto è un linguaggio che punta ad essere un linguaggio fortemente espressivo, in particolare:

• È un linguaggio Funzionale, al cui interno abbiamo la possibilità di usufruire di funzioni di second’ordine.
• È debolmente tipato, anche se tipizzando le variabili in ingresso (rule input) l’ambiente adotta i controlli tipici della tipizzazione forte, eccetto per la possibilità di eseguire conversioni di tipo implicite;
• È fortemente espressivo, inoltre è utilizzato sia per la costruzione di rule che di interfacce
• Non ha un sistema di cattura e gestione delle eccezioni, questo fa’ sì che bisogna usare con oculatezza le rule e le interfacce in un applicativo robusto.

Le caratteristiche appena citate permettono di scrivere codice molto espressivo in grado di effettuare operazioni anche molto complesse con poche righe di codice.
Ad esempio, consideriamo un dizionario che schematizziamo in Json con un costrutto del tipo :

[{“nome”:”Vincenzo”,”cognome”:”Reggina”,”professione”:”Sviluppatore”},{“nome”:”Tizio”,”cognome”:”Rossi”,”professione”:”Pittore”},{“nome”:”Caio”,”cognome”:”Verdi”,”professione”:”Designer”}]
e da questo json vogliamo estrarre solo gli elementi del dizionario “Nome”.

Dobbiamo semplicemente scrivere il seguente codice:
a!fromJson(local!elenco).nome

SAIL come linguaggio di programmazione

Appian punta molto sul fatto che il suo BPM sia “lowcode”. Il motivo è chiaro: “lowcode” si traduce in tempi di sviluppo più rapidi, ma per farlo il proprio linguaggio, ha determinate caratteristiche. Il fatto SAIL sia un linguaggio funzionale con una forte espressività ci permette di scrivere segmenti di codice fortemente concisi che ne assicurano anche una forte riusabilità all’interno della nostra applicazione. Gli script in virtù del fatto che il linguaggio è debolmente tipato permettono sono facilmente generalizzabili. Tutto oro? assolutamente no.

Il fatto che gli script siano debolmente tipati e che non ci sia una gestione degli errori fa’ sì che gli script devono quanto più possibile essere brevi e concisi pena la decadenza della manutenibilità degli script stessi.

Primi costrutti: commenti e if.

A questo punto illustriamo i primi costrutti utili per un semplice script.

Il primo costrutto che vedremo sono i commenti, in Appian un po’ come Java e C#, si scrivono utilizzando la notazione slash e asterisco.

/* questo è un commento monolinea */

/* questo è un commento
Multilinea, ma carino */

Tutto qui,  per quanto riguarda la componente SAIL, mentre per la componente BPM è consigliato (leggi anche obbligatorio) l’utilizzo delle annotation dei processi per inserire dei commenti, ma vedremo poi.

Il secondo costrutto che vediamo è l’if il quale è una (ovviamente) funzione che differenzia il risultato in base a un valore booleano in ingresso.

if(condizione, espressione se condizione vera, espressione se condizione falsa).

Ciò che ci restituisce l’if è dettato dalla prima espressione se la condizione è vera, dalla seconda se questa è falsa.

ad esempio if(0=1,“Appian”,”Computer”) restituirà sempre la stringa “Computer”.