Tag: Appian

In Precedenza abbiamo visto le caratteristiche del linguaggio Appian che lo caratterizzano, in questo articolo ne approfondiamo il tema della struttura delle rule e illustriamo le funzioni essenziali che ne permettono l’operatività.

Nel primo paragrafo rivedremo brevemente gli aspetti essenziali del linguaggio utilizzato, mentre nel secondo vedremo la struttura di una rule appian e le funzioni essenziali che vengono utilizzate tutti i giorni da ogni appian developer.

Caratteristiche principali del linguaggio SAIL

Abbiamo già illustrato che Appian ha un suo linguaggio proprietario, SAIL, che di fatto punta ad essere un linguaggio fortemente espressivo e flessibile: questi pregi vengono bilanciati da un neo come la totale mancanza di un sistema di cattura e gestione delle eccezioni all’interno di Sail.

Considerato quanto evidenziato possiamo dire che un buon codice appian deve avere queste caratteristiche:

• Essere breve, conciso, pena un design rivedibile.
• Deve prevedere una batteria di test per i casi più comuni.

I mattoncini principali per costruire gli script Sail sono :

1. Variabili
2. Costanti
3. Le funzioni

Ogni istruzione è separata dalla virgola ed ogni oggetto si denota con un’espressione del tipo prefisso!nome_oggetto

Il prefisso dell’oggetto non è altro che il prefisso di dominio ed è utilizzato per disambiguare la tipologia di oggetto richiamata: un oggetto può essere una variabile, una rule appian, una funzione esterna o nativa.

Struttura e funzioni principali da utilizzare nelle rule

Elementi principali della struttura di una rule

Illustriamo i primi costrutti utili della struttura di una rule.

Abbiamo già visto i commenti, in Appian che si scrivono un po’ come Java e C#, si scrivono utilizzando la notazione slash e asterisco.

/* questo è un commento monolinea */

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

Funzioni essenziali

Ora che conosciamo la struttura delle rule, Illustriamo le funzioni essenziali che permettono l’operatività in appian: le funzioni possono originarsi dal sistema (funzioni di sistema) da eventuali plugin, da altre rule create.

Le funzioni di sistema hanno due domini, un dominio “a” e un dominio “fn”. La caratteristica principale del dominio “fn” è che possiamo ometterne la dichiarazione in fase di utilizzo, vale a dire scrivere if è la stessa cosa che scrivere fn!if.

Abbiamo già visto la funzione if come funzionei di sistema che permette di effettuare un calcolo 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.

In questo contesto vediamo una nuova rule, fondamentale, ed è la localvariables.

Il dominio di questa funzione è “a” (pertanto per usarla dobbiamo indicarla come “a!localvariables“, tale funzione viene utilizzata per creare blocchi in cui dichiarare al proprio interno delle variabili con visibilità limitata al blocco, per dichiararle si utilizza il dominio “local”.

^{Facciamo un breve passo indietro, ed osserviamo un esempio di variabile come local!miaVariabile: il fatto che prima di ! ci sia “local” ci fa’ capire subito che ci si riferisce ad una variabile, nel caso in cui volessimo invocare la rule “miaRule” basterà scrivere rule!miaRule().}

Un’altra funzione fondamentale è la funzione foreach, ha come dominio “a” ed è utilizzata per effettuare delle iterazioni su un array di dati. La funzione restituisce un array il cui il contenuto alla riga i-esima è quanto elaborato alla i-esima iterazione, eccovi un esempio:

All’interno del ciclo, possiamo utilizzare il dominio “fv” per avere accesso a due elementi importanti:

• fv!index : che avrà come valore l’indice dell’iterazione corrente
• fv!item : che avrà come valore l’elemento contenuto all’interno dell’iterazione i-esima.

Per chi viene dal mondo della programmazione (come il sottoscritto) troverà dolorosa l’assenza del ciclo for in Sail, tuttavia ci viene in soccorso la funzione fn!enumerate che non fa’ altro che creare un array da 0 a n-1 unico parametro di input.

Pertanto l’esempio riportato sopra si può riscrivere in questo modo:

qui abbiamo un’altra chicca del linguaggio: la somma viene effettuata su tutti gli elementi dell’array creando implicitamente un foreach.

Pertanto per ottenere lo stesso risultato basterà scrivere fn!enumerate(4)+2.

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”.