Programmazione Archivi - Vincenzo Reggina

Custom Data Type, le annotazioni di struttura delle tabelle

I Custom Data Types (CDT) in Appian utilizzano le annotazioni JPA (Java Persistence API) all’interno della loro definizione XSD (XML Schema Definition) per personalizzare il modo in cui i dati vengono mappati e gestiti in un database relazionale.

Utilizzo delle Annotazioni JPA

Le annotazioni JPA sono essenziali quando si mappa un CDT alle tabelle e colonne del database.

Inclusione nell’XSD: Per utilizzare un’annotazione JPA, essa deve essere inclusa all’interno del tag <xsd:appinfo> che ha l’attributo source impostato su "appian.jpa".
Generazione Automatica: Molte delle configurazioni di base, come la specificazione della chiave primaria (@Id) o la definizione delle relazioni tra tabelle, vengono aggiunte automaticamente da Appian quando si crea un tipo di dati da una tabella di database o quando si definiscono le relazioni nel designer del tipo di dati.

Annotazioni JPA Supportate

Appian supporta una vasta gamma di annotazioni JPA per la mappatura e la definizione del comportamento del database:

Categoria	Annotazioni Supportate
Mappatura Base	`@Table`, `@SecondaryTable`, `@SecondaryTables`, `@Column` (con attributi a seconda dell’esigenza).
Chiavi	`@Id`, `@GeneratedValue`.
Relazioni	`@JoinColumn`, `@JoinTable`, `@ManyToOne`, `@OneToOne`, `@OneToMany`, `@ManyToMany`.
Ereditarietà/Override	`@Inheritance`, `@PrimaryKeyJoinColumn`, `@MappedSuperclass`, `@AttributeOverride`.
Altro	`@Transient`, `@Version`, `@Basic`, `@Lob`, `@OrderBy`, `@UniqueConstraint`, `@SequenceGenerator`.

Le annotazioni più utili per la definizione di tabelle

In questo paragrafo facciamo una carrellata delle annotazioni strutturali che ritengo più utili per la modellazione delle tabelle. Le annotazioni JPA devono essere impostate prima di pubblicare il data store. Appian legge le annotazioni JPA solo quando crea una tabella o una colonna; le colonne esistenti non vengono mai aggiornate in base alle annotazioni JPA.

L’annotazione @Table, @Id

Possiamo utilizzare l’annotazione @Table per indicare il nome della tabella da utilizzare, bypassando le operazioni per limitare a 27 caratteri i nomi delle tabelle e colonne del database.

<xsd:annotation> <xsd:appinfo source="appian.jpa">@Table(name="Persona")</xsd:appinfo> </xsd:annotation>

Colgo l’occasione per fornirvi un piccolo tool per calcolare il nome generato da un nome che già supera i 27 caratteri.

Per indicare una colonna come chiave primaria possiamo usare l’annotazione @id e per abilitare l’auto increment possiamo usare @GeneratedValue

<xsd:element name="id" nillable="true" type="xsd:int"> <xsd:annotation> <xsd:appinfo source="appian.jpa">@Id @GeneratedValue</xsd:appinfo> </xsd:annotation> </xsd:element>

Nota bene: se non esiste un campo id con chiave primaria, appian creerà una colonna a_id con tali caratteristiche .

le annotazioni @Lob e @Column

Quando lavoriamo con JPA, di solito i campi delle entità vengono mappati su colonne “normali” del database, come VARCHAR per le stringhe o INTEGER per i numeri. Questo funziona bene finché i dati hanno dimensioni contenute. Ma cosa succede se dobbiamo memorizzare un testo molto lungo, come un articolo, una descrizione dettagliata, oppure un file binario come un PDF o un’immagine? In questi casi, i tipi standard non bastano: il database ha bisogno di gestire i dati come Large Object, cioè oggetti di grandi dimensioni.

Ecco un esempio di lob:
<xsd:element name="fileContent" nillable="true" type="xsd:string"> <xsd:annotation> <xsd:appinfo source="appian.jpa">@Lob</xsd:appinfo> </xsd:annotation> </xsd:element>

Con questa configurazione, con un database MariaDB verrà creato un campo di tipo “LongText”, per ottenere un “MediumText” bisogna:
<xsd:element name="mediumtext" nillable="true" type="xsd:string"> <xsd:annotation> <xsd:appinfo source="appian.jpa">@Column(columnDefinition="mediumtext")/xsd:appinfo> </xsd:annotation> </xsd:element>

Qui vediamo l’utilizzo per personalizzare l’annotazione @Column che permette di impostare anche il nome e la dimensione della colonna, ad esempio:
<xsd:element name="name" nillable="true" type="xsd:string"> <xsd:annotation> <xsd:appinfo source="appian.jpa">@Column(length=200,name="NOME")</xsd:appinfo> </xsd:annotation> </xsd:element>
Questo ci permette di indicare la colonna sul database con nome “Nome” e lunghezza 200.

L’annotazione @Transient

L’annotazione @Transient è una delle annotazioni JPA (Java Persistence API) supportate da Appian per la definizione dei Custom Data Types (CDT).

Nel contesto dei CDT utilizzati per il mapping a un database relazionale tramite Data Stores, l’annotazione @Transient serve a specificare che un campo definito nell’XSD del CDT non deve essere persistito (memorizzato) nel database.

In sostanza, un campo marcato con @Transient fa parte della struttura dati logica (il CDT) all’interno di Appian, ma viene ignorato dal meccanismo di persistenza di Appian quando scrive o legge i dati dal database sottostante.

Questa annotazione è utile per i campi che contengono dati temporanei, calcolati, o informazioni che sono rilevanti solo all’interno del processo o dell’interfaccia di Appian, ma non devono avere una colonna corrispondente nella tabella del database.

Ecco un esempio:
<xsd:element name="ignora" nillable="true" type="xsd:string"> <xsd:annotation> <xsd:appinfo source="appian.jpa">@Transient</xsd:appinfo> </xsd:annotation> </xsd:element>

L’annotazione per il locking ottimistico: @Version

Abbiamo già visto questa annotazione quando abbiamo affrontato l’argomento delle strategie di locking da adottare alla scrittura di un record, ecco un esempio:

<xsd:element name="versionNumber" nillable="true" type="xsd:int">
    <xsd:annotation>
        <xsd:appinfo source="appian.jpa">@Version</xsd:appinfo>
    </xsd:annotation>
</xsd:element>

Nota bene: il campo deve essere intero.

Conclusioni

I Custom Data Types di Appian, arricchiti dalle annotazioni JPA, offrono agli sviluppatori un modo semplice e potente per modellare i dati in un database. Con poche regole chiare – come l’uso di @Table per nominare le tabelle, @Id per definire la chiave primaria o @Lob per gestire testi e file di grandi dimensioni – è possibile rendere le applicazioni più flessibili e aderenti alle esigenze reali. Queste annotazioni permettono di impostare oculatamente le opzioni desiderate.

Riferimenti

https://docs.appian.com/suite/help/25.4/Supported_XSD_Elements_and_JPA_Annotations.html

https://docs.appian.com/suite/help/25.4/cdt_design_guidance.html

Appian nel segno della continuità con la versione 25.04

Con l’arrivo di Santa Claus imminente immancabile arriva anche la nuova versione della piattaforma, tanta IA ovviamente intercalate nel BPM low code, vediamo in questo articolo le novità principali che toccano gli sviluppatori. Su tutto viene introdotto Agent Studio, oltre a seguire il cammino di Process HQ.

Ecco Agent Studio

Appian ha introdotto una nuova funzionalità chiamata Agent Studio, la cui funzione principale è di automatizzare processi complessi e orientati agli obiettivi utilizzando agenti di intelligenza artificiale. L’idea di fondo è di esprimere gli obiettivi da raggiungere in linguaggio naturale e far sì che gli agenti AI costruiscano le basi dell’applicazione da realizzare.

Gli agenti sfruttano il data fabric e gli oggetti di design. Dal punto di vista pratico, un agente AI è un oggetto low‑code che si comporta come un collaboratore digitale: interpreta le istruzioni, ragiona sulle alternative e sceglie le azioni più adatte per arrivare al risultato. È un modo diverso di pensare all’automazione, più vicino al linguaggio delle persone che alla logica dei programmatori.

A differenza delle AI Skills, che automatizzano singole attività, gli agenti orchestrano interi processi, adattandosi a situazioni complesse e non prevedibili.

Gli agenti si prestano molto bene per la prototipazione rapida:

consentono di passare da un’idea a un’automazione completamente funzionante in poche ore.
Sono individuati nella piattaforma come degli oggetti lowcode, come gli smart services, che forniscono un output dopo aver completato il task.

Sviluppo rapido: Appian Composer

Avete mai sentito parlare di Vibe Coding? sicuramente.
Fermo restando la mia volontà di ritornare sul tema con un approfondimento specifico, introduciamo Appian Composer che in questa release diventa generalmente disponibile: con questo tool abbiamo un approccio più strutturato di un semplice “query to code”, ma bensì un “query to plan”.

La funzionalità che permette a partire da un documento dei requisiti in un piano applicativo dettagliato, in cui vengono proposti i possibili processi e le possibili rule da utilizzare con un supporto alla creazione rapida e generazione in un click. Il tab workflow offrirà una panoramica visiva del flusso applicativo, mostrando la sequenza delle attività e dei passaggi come un diagramma interattivo:

Con questo tool salutiamo anche il Quick Apps Designer, il Composer è l’unico modo per costruire nuove applicazioni rapidamente.

Process HQ

Creazione immediata di report personalizzati con comandi in linguaggio naturale e anteprima grafica in chat.
Disponibilità di AI Copilot direttamente nella home page di Process HQ per esplorare dati e generare report.
Controllo centralizzato: gli amministratori possono attivare o disattivare tutte le funzionalità AI (chat, KPI, viste) con un solo clic dalla Console di Amministrazione.
I report di Process HQ possono esser inseriti nelle distribuzioni.
Gli oggetti report ora possono puntare ai report di Process HQ.

Sviluppo

Il lato sviluppo della piattaforma riflette molti aspetti che abbiamo visto come novità.

È stata introdotta la rule a!genAiModels per scoprire i modelli AI generativi disponibili.
Lo smart service Execute Generative AI Skill supporta la selezione del modello runtime, che sovrascrive il modello configurato nell’AI skill.
È stato introdotto un nuovo componente di campo chat, utilizzabile mediante a!chatField che per impostazione predefinita utilizza il modello linguistico scelto da Appian tramite la funzione a!callLanguageModel, ma consente anche di collegare un modello AI personalizzato.
Gli header dei record possono essere disabilitati con un flag “Non mostrare le intestazioni dei record” (do not Show record headers) per aver un maggiore controllo sull’aspetto di questa interfaccia.
La rule a!fileUpload si arricchisce con il parametro documentActions che permette di scegliere un’azione da effettuare dopo aver effettuato l’upload, come il rinomina o vedere una preview.
a!documentViewerField supporta la navigazione diretta e l’evidenziazione del testo.
Introdotta la funzionalità di “skip degli errori della sincronizzazione dei record” (“Skip failed smart service syncs”) che permette di ignorare i fallimenti delle sincronizzazioni lasciando l’accessibilità ai record.
UUID Oggetto: L’UUID dell’oggetto è ora visualizzabile nella finestra di dialogo delle proprietà di tutti gli oggetti, ad eccezione di AI skills, robotic tasks e robot pools.

Conclusioni

In questo articolo ho evidenziato le novità più significative di Appian, che confermano la continuità nell’integrazione dell’intelligenza artificiale. La nuova release introduce l’Agent Studio, corredato da numerosi componenti per lo sviluppo, accelera la pianificazione delle attività e la realizzazione tramite Appian Composer, arricchisce Process HQ con un collegamento diretto alle funzionalità applicative e offre diversi miglioramenti pensati per semplificare l’uso dell’AI generativa. Tutte queste innovazioni sono orientate a supportare sviluppatori e clienti nel raggiungimento dei loro obiettivi di business, aumentando al contempo l’efficienza delle attività.

Riferimenti

https://docs.appian.com/suite/help/25.4/Appian_Release_Notes.html

https://docs.appian.com/suite/help/25.4/Chat_Component.html

https://youtu.be/HabxZBSTFt8?list=TLGGuhpgEuzDg7syMzExMjAyNQ

I tipi di dati complessi in Appian

In questo articolo discutiamo le tipologie di dati complessi in Appian: un altro mattoncino basilare per sviluppare su piattaforma.

Appian permette una definizione di struttura dati rigida mediante i Custom Data Types mentre una definizione più flessibile mediante i dictionary o le map.

I Custom Data Types (CDT)

I CDT in Appian sono oggetti che permettono di definire strutture dati che rappresentano raggruppamenti logici di informazioni correlate.

Con i CDT in Appian possiamo:

Definizione di modelli dati complessi riutilizzabili in varie applicazioni e processi.
Facilitazione dell’integrazione con sistemi esterni attraverso il mapping automatico dei campi dati.
Supporto alla conservazione e recupero di dati strutturati.
Utilizzo nei moduli dinamici, per creare form che si adattano ai dati sottostanti.

I CDT sono una componente essenziale per costruire applicazioni robuste e scalabili in Appian, migliorando la gestione e l’integrazione dei dati per l’automazione dei processi di business.

Possiamo vedere i CDT come una forma “forte” di tipo per un oggetto, ma Appian prevede diverse forme di struttura che contengono informazioni, ovvero :

CDT
Dictionary
Map

Dictionary e Map

I dictionary e le map (come i CDT) sono oggetti che permettono di rappresentare un insieme di oggetti strutturati come chiave-valore che possono essere visti come una collezione di elementi dove ogni chiave è associata a un valore unico.

Ecco un esempio di codice per ottenere una mappa di oggetti:

load(
  local!mappa: a!map(
  chiave1: "Valore 1",
  chiave2: "Valore 2",
  chiave3: 123,
  chiave4: true
  /* a seguire è un dizionario*/
  {
     /*Accesso ai valori */
    local!mappa.chiave1,   /* restituisce il valore 1 */
    local!mappa.chiave3,   /* restituisce 123 */
   }
)

Il dizionario si ottiene direttamente da SAIL con la sintassi {…} (un esempio è /* a seguire è un dizionario*/) mentre per la map bisogna utilizzare la funzione a!map. Considera inoltre che i modelli di processo non supportano il tipo Dictionary.

Le differenze

La differenza principale tra un dictionary e le map è che all’interno di una map, ogni chiave è associata a un valore e il tipo di quel valore viene mantenuto. I valori memorizzati in una mappa non vengono incapsulati in varianti, mentre un dictionary incapsula ogni valore in un tipo AnyType (variant): di conseguenza con le map non bisogna preoccuparsi del type casting.

Il dizionario si ottiene direttamente da SAIL con la sintassi {…} mentre per la map bisogna utilizzare la funzione a!map. Considera inoltre che i modelli di processo non supportano il tipo Dictionary.

Riferimenti

Appian Community

Map Appian 25.03

Appian, le novità della versione 25.03

Ormai le vacanze sono agli sgoccioli e puntuale come ogni anno ecco la terza iterazione delle nuove funzionalità, come di consueto in questa serie di articoli, introduciamo le novità principali di di Appian 25.03, focalizzandoci su alcuni aspetti relativamente allo sviluppo su piattaforma.

AI Copilot per utenti business

In questa nuova versione Copilot restituirà risultati più pertinenti grazie alla miglior comprensione del significato delle query, non solo delle parole chiave, tale novità si rifletterà anche sul chatbot su Data Fabric. La ricerca intelligente mostrerà fino a 10 corrispondenze semantiche, anche su campi testuali lunghi, con messaggi di errore più chiari e notifiche in caso di problemi di indicizzazione.

AI Agents

Per la skill AI Advanced IDP Tools vengono introdotte le query di ricerca per estrarre dati aggiuntivi dai documenti, rispondendo a domande e indicando i riferimenti.

Le skill AI generative ora supportano file JPEG, PNG e TIFF (inclusi TIFF multipagina) come input di documenti, senza bisogno di conversioni o plugin. Anche la skill AI Advanced IDP Tools supporta file TIFF multipagina.

È possibile aggiornare dinamicamente il prompt utilizzato dallo smart service Execute Generative AI Skill direttamente nel modello di processo. Questo permette di adattare l’input per casi d’uso specifici limitando copie superflue.

Process HQ

Per Process HQ la novità di rilievo è l’Integrazione nel Sito Appian: è possibile aggiungere la Libreria di Report e Dashboard di Process HQ come pagina dedicata all’interno di un sito Appian, consentendo agli utenti di accedere e gestire report e dashboard direttamente dal sito.

Gli altri miglioramenti di rilievo sono:

La possibilità di configurare report con funzionalità di drill-down, permettendo di collegare diverse visualizzazioni dei dati e accedere a informazioni più dettagliate direttamente, inclusi link diretti alla vista riepilogativa del record.
La creazione di report è stata integrata direttamente nella pagina Report e Dashboard di Process HQ, senza uscire dal site.
Si può contrassegnare come preferiti report e dashboard per un accesso rapido. Ogni report/dashboard si apre automaticamente in una propria scheda.
Nuove metriche di processo per gli eventi record che calcolano la durata dei processi attraverso campi record personalizzati. Queste metriche possono essere monitorate e visualizzate tramite Process HQ.

Data Fabric

Per Data Fabric sono stati apportati miglioramenti nella sincronizzazione dei dati, gestione documentale e performance delle query. In particolare sono state introdotte le sincronizzazioni incrementali: permettono di pianificare (anche per tipi di record basati su database) un sottoinsieme di record consentendo aggiornamenti frequenti (minuti/ore) e la flessibilità di programmare anche sincronizzazioni complete (di solito in orari off business).

Segnalo anche questi miglioramenti :

Monitoraggio avanzato delle query: La scheda “Query Performance” ora mostra il numero di campi inclusi in ogni query; sono stati migliorati i log sail_details.csv e introdotto interface_query_record_type_details.csv.
Interrogazione di più dati correlati: La funzione a!relatedRecordData() può ora recuperare più dati da relazioni uno-a-molti (fino a 100 record in a!queryRecordType()/griglie, fino a 250 in a!queryRecordByIdentifier())

Interfacce

Per creare interfacce con migliori prestazioni è stata introdotta la funzione a!asyncVariable() per caricare dati in modo asincrono.
Per la gestione dei documenti è stato introdotto l’upload con preview, inoltre viene generata una summary view e la visualizzazione dei documenti correlati.

Anche sul fronte accessibilità sono stati fatti dei passi in avanti, migliorando le griglie editabili, i colori preconfigurati con contrasto ottimizzato.

Le altre novità di rilievo sono le seguenti:

un nuovo banner accessibile per i messaggi
Un nuovo template sidebar per i layout di tipo “wizards”
la possibilità di scrollare i pannelli all’interno dei form layouts
Il parametro “visibility” è stato rinominato in “Show When”.

Record Action

Per le record actions è possibile includere sia tipi di record correlati one-to-one che one-to-many. Per le relazioni one-to-many, Appian genera automaticamente una griglia editabile nell’interfaccia dell’azione record.

Conclusioni

In questa terza iterazione della versione 25 di Appian, viene ulteriormente potenziata la sezione IA, tenendo sempre il focus verso le prestazioni con alcuni accorgimenti anche facile da introdurre su progetti esistenti.

L’evoluzione del Data Fabric mostra una chiara volontà di rendere il dato più fluido e governabile, mentre le nuove Interfaces offrono strumenti di design più potenti e inclusivi, capaci di migliorare l’esperienza utente su ogni dispositivo. Le funzionalità di AI e automazione continuano a crescere, semplificando attività ripetitive e suggerendo soluzioni intelligenti in tempo reale.

Riferimenti

https://docs.appian.com/suite/help/25.3/Appian_Release_Notes.html

Appian 25.3 Release Highlights (Guarda il video su YouTube)

25.3 Webinar di annuncio del prodotto (Guarda il video su YouTube)

Appian, un primo approccio alle distribuzioni

Scopriamo assieme le distribuzioni di appian, focalizzandoci sulle distribuzioni manuali

In Appian, le distribuzioni (o “deployments” in inglese) rappresentano il processo di trasferimento delle modifiche da un ambiente sorgente a un ambiente di destinazione. Questo processo è fondamentale per spostare applicazioni, configurazioni e dati tra diverse fasi del ciclo di sviluppo, come da sviluppo a test o da test a produzione.

Tra le tematiche per chi arriva da contesti “classici” ed approccia Appian rimane piacevolmente sorpreso dalla semplicità di utilizzo delle distribuzioni, successivamente si rimane anche piacevolmente sorpresi dalle possibili modalità.

In particolare esistono tre metodi principali per distribuire un pacchetto in Appian:

1. Confronta e Distribuisci (Diretto): Questo è il metodo più semplice e consigliato. Permette di distribuire applicazioni, pacchetti, plugin e script di database direttamente tra ambienti connessi tramite passaggi guidati. Richiede la configurazione di ambienti connessi.

2. Tramite API (Esterno): Consente di personalizzare il processo di distribuzione tramite le API native di Appian, utilizzabili con strumenti esterni come Jenkins.

3. Esporta e Importa (Manuale): Implica l’esportazione manuale di un pacchetto o un’applicazione dall’ambiente sorgente e la successiva importazione nell’ambiente di destinazione. È consigliato se non si dispone di ambienti connessi.

Il metodo Confronta e Distribuisci

Il metodo Confronta e Distribuisci è la modalità più assistita che mette a disposizione Appian, consente dopo aver creato il pacchetto di confrontarlo con l’ambiente (connesso) e quindi verificare anzitempo eventuali dipendenze mancanti e/o errori di sorta.

Con questo metodo non ci sono file e operazioni manuali: il tutto avviene all’interno della piattaforma guidato. La piattaforma controlla se ci sono errori o conflitti. Se qualcosa va storto, è possibile tornare indietro facilmente grazie alla funzione di rollback.

Il metodo Manuale

Questo metodo è di fatto risulta l’unica opzione per chi lavora su ambienti disconnessi senza usare strumenti di DevOps.

Il contro più importante di utilizzare questa modalità è che ci costringe a dover “verificare”, meglio conosciuta come ispezione, dei pacchetti solo al momento in cui bisogna installare.

Gli esiti di una ispezione sono i seguenti:

Nessun errore, in tal caso è possibile installare il pacchetto
Avvisi, possiamo installare ma non è assicurato l’uniformità dell’installazione
Errori, non potremo installare il pacchetto.

Sia che ci sia un Avviso, sia che ci siano errori, consiglio sempre di non distribuire a meno che non si effettui una review puntuale sugli oggetti.

In presenza di errori, ignorare non è una possibilità: significa compromettere la distribuzione, che potrebbe risultare incompleta o addirittura fallire del tutto. Gli errori di distribuzione indicano che uno o più oggetti nel pacchetto non sono definiti correttamente, e Appian non è in grado di importarli nell’ambiente di destinazione. Se non vengono corretti, si rischia di incorrere in errori di runtime una volta che l’applicazione è in uso.

Le cause più comuni sono riferimenti a oggetti che sono stati eliminati oppure l’uso di campi di tipo record non validi. Per aiutare a risolverli, Appian fornisce una griglia dedicata agli errori di distribuzione, dove ogni voce è accompagnata da un link diretto all’oggetto problematico e da una descrizione dettagliata nella colonna “Problemi”. Questo consente di individuare rapidamente la causa e intervenire in modo mirato.

Il metodo programmatico: le WebApi

Le WebApi permettono di usare fondamentalmente le funzionalità disponibili per le distribuzioni manuali mediante appunto delle WebApi Rest, che hanno il vantaggio che possono esser integrate in un ciclo DevOps.

Questa modalità rispetto al metodo Confronta e Distribuisci chiaramente perde il confronto diretto tra ambienti sorgente e destinazione, ma rispetto al metodo manuale guadagna la possibilità di creare script che rendono il processo di distribuzione automatizzabile e ripetibile.

Conclusioni

La conclusione di questo primo approccio alle distribuzioni è che in generale le distribuzioni si effettuano sempre allo stesso modo:

Confronto tra il pacchetto e l’applicazione target, disponibile solo per i metodi Confronta e Distribuisci.
Verifica del pacchetto inviato (valido per tutti i metodi)
Installazione del pacchetto (valido per tutti i metodi)

Il vantaggio dei metodi 1 e 2 sono innegabili e per chi usa il terzo metodo… proviamo e riproviamo le installazioni delle nostre distribuzioni.

Riferimenti

https://docs.appian.com/suite/help/25.2/inspect-deployment-packages.html

https://docs.appian.com/suite/help/25.2/Deploy_to_Target_Environments.html

Appian, le novità della release 25.2

Dopo aver passato in rassegna le novità della release 25.1 vediamo le principali novità della release 25.2.

Novità Principali

Control Panel, nuovo workspace completamente no-code per gli utenti aziendali, utile per costruire interfacce e strutture dati senza intervento degli sviluppatori.

AI Document Center, piattaforma per l’elaborazione intelligente dei documenti con modelli di classificazione ed estrazione dei dati, ora più precisi e facili da configurare.

Advanced Plug-ins, nuovi plugin come GridPlus e Microsoft Document Editor per potenziare l’esperienza utente e l’integrazione di tecnologie avanzate.
Data Fabric

Gestione di documenti come record types, senza necessità di cartelle.

Sync incrementali e supporto fino a 20 milioni di righe per tipo di record.

Nuove funzioni di validazione e riutilizzo di campi dati.

Control Panel

Il Control Panel è una delle funzionalità di punta introdotte nella release 25.2 di Appian. Si tratta di uno spazio di lavoro completamente no-code, pensato per dare maggiore autonomia agli utenti aziendali. In pratica, consente a persone che non sono sviluppatori di progettare applicazioni, organizzare dati e creare interfacce, semplicemente usando strumenti visivi e intuitivi, senza scrivere codice.

Con il form builder è possibile costruire moduli e interfacce attraverso il trascinamento di campi preconfigurati. Non servono competenze tecniche: bastano pochi clic per aggiungere intestazioni, validazioni, colonne e testi formattati. Questo rende molto più veloce e coerente lo sviluppo, anche perché i form creati possono essere riutilizzati in contesti diversi.

Oltre alla costruzione delle interfacce, il Control Panel permette anche di definire e strutturare i dati in modo logico e gerarchico. Questo significa che ogni reparto può organizzare le proprie informazioni in modo ordinato, con campi condivisi e controlli standardizzati, riducendo il rischio di errori o duplicazioni.

Tutto questo è possibile grazie a un oggetto di configurazione chiamato control panel object, impostato dagli sviluppatori low-code. Questo oggetto funge da fondamento invisibile: definisce cosa possono fare gli utenti nel workspace, quali termini usare, come organizzare i dati e quali permessi assegnare.

Un altro aspetto importante riguarda proprio la sicurezza. Il sistema consente di assegnare permessi molto dettagliati, per esempio permettendo solo al reparto Risorse Umane di vedere e modificare i dati a loro riservati. In questo modo, la flessibilità non compromette la governance né la riservatezza.

Il Control Panel trasforma Appian in una piattaforma dove business e IT possono collaborare in modo fluido. Da un lato gli utenti aziendali possono plasmare le applicazioni sulla base delle loro reali esigenze operative, dall’altro gli sviluppatori mantengono il controllo tecnico e la qualità architetturale del progetto. Gli utenti aziendali possono costruire ciò che conoscono meglio, mentre gli sviluppatori mantengono il controllo strutturale e la sicurezza.

Advanced Plug-in

Gli Advanced Plug-ins sono una nuova categoria di componenti sviluppati direttamente da Appian, disponibili per ambienti Cloud e self-managed, per estendere le funzionalità della piattaforma, integrando tecnologie avanzate e risolvendo esigenze aziendali comuni. A differenza dei plug-in standard, questi sono gestiti, aggiornati e supportati ufficialmente da Appian. Non soggetti al ciclo completo di sviluppo software Appian, ma comunque testati a fondo per sicurezza e affidabilità.

Gli Advanced Plug-ins sono sviluppati da Appian: garantiscono qualità, sicurezza e aggiornamenti continui.

In passato, alcune funzionalità, pur essendo di base, si sono rivelate particolarmente utili. Appian ha scelto di affidarne l’implementazione alla propria community di sviluppatori, una decisione che in parte ha rappresentato una deviazione rispetto agli obiettivi strategici della piattaforma. Alcuni plugin si sono dimostrati un autentico valore aggiunto, anche per un utilizzo essenziale del sistema. Ritengo quindi positivo che la piattaforma stia compiendo un passo in avanti in questa direzione, con l’augurio che in futuro si possa integrare sotto questo cappello tutte le funzionalità considerate “basiche”.

Gli Advanced Plug-ins sono di fatto un passo avanti verso una piattaforma più modulare e potente, in cui le aziende possono:

Integrare strumenti familiari (come Microsoft Office) nei propri flussi di lavoro.
Gestire dati in modo più efficiente e personalizzato.
Ridurre i tempi di sviluppo grazie a componenti pronti all’uso e altamente configurabili.

Plug-in inclusi nella release 25.2

1. GridPlus

Un componente avanzato per visualizzare e modificare dati in formato tabellare.
Supporta ordinamento, filtri, selezione multipla, creazione e cancellazione inline, e navigazione da tastiera.
Le colonne possono essere trascinate, congelate e ridimensionate per una visualizzazione ottimale.

2. Microsoft Document Editor

Disponibile solo per clienti Cloud.

Permette di visualizzare e modificare documenti Word, Excel e PowerPoint direttamente all’interno di Appian.

Elimina la necessità di scaricare e ricaricare file.

Supporta modifiche collaborative in tempo realetra più utenti.

Document record type

Un Document Record Type in Appian è un tipo speciale di record che ti permette di gestire documenti come parte integrante dei tuoi dati applicativi, sfruttando tutte le potenzialità del data fabric.

I document record type in Appian rappresentano un approccio evoluto alla gestione dei documenti nelle applicazioni aziendali. Non vengono trattati più come file isolati, ma come veri e propri elementi strutturati del data fabric, con metadati accessibili, relazioni chiare con altri dati e livelli di sicurezza integrati. Questo significa che possono essere interrogati, filtrati, ordinati e collegati ad altri record proprio come avviene con le informazioni tabellari. Quando i documenti sono parte essenziale di una pratica, di un caso o di un processo (come contratti, richieste, certificati), i document record type puntano a rendere il tutto più ordinato, sicuro e facilmente riutilizzabile. È la scelta ideale quando si cerca una gestione documentale moderna, intelligente e integrata nel cuore delle applicazioni Appian.

Smart Search

Smart Search è una funzionalità di ricerca che non si limita a cercare parole chiave esatte, ma comprende il significato della tua ricerca.

Interpreta l’intento dietro le parole
Trova risultati anche se usi sinonimi o termini diversi
Funziona su campi di testo e documenti allegati

Esempio: se cerchi “interruzione elettrica”, può restituire anche risultati che parlano di “blackout” o “mancanza di corrente

Smart Search cerca all’interno di tutti i record types del Data Fabric, compresi quelli basati su dati esterni (service-backed) e all’interno di campi di testo, descrizioni, nomi, e altri attributi testuali, infine all’interno di documenti allegati ai record, usando tecniche di semantic search per capirne il contenuto

Conformità dei processi, Conformace Rate

Il conformance rate in Process HQ di Appian rappresenta la percentuale di casi che seguono l’ordine previsto delle attività in un processo. È un indicatore chiave (KPI) che misura quanto le esecuzioni reali del processo rispettano il modello ideale o atteso.

· Identifica deviazioni che possono causare inefficienze o rischi

· Aiuta a migliorare la qualità e la compliance dei processi

· Supporta decisioni basate su dati reali, non solo su modelli teorici

Nella funzionalità vengono fornite le seguenti informazioni:

La percentuale di conformità delle attività di processo, gli attributi che influenzano la conformità e infine le sequenze di attività inaspettate.

Nuove funzioni

a!applyValidations(): permette di applicare le validazioni già configurate nel record field (es. formato email, valore obbligatorio, ecc.) per espanderle con validazioni aggiuntive contestuali

a!isBetween(): permette a verificare se un valore rientra in un intervallo specificato, ed è comunemente usata per creare validazioni. È compatibile con valori di tipo:

Data (date)
Data e ora (datetime)
Numero intero (integer)
Numero decimale (decimal)

a!startsWith(), a!endsWith(), a!isInText() : permettono di capire se è presente una stringa rispettivamente all’inizio, alla fine o all’interno di un testo.

Riferimenti

https://docs.appian.com/suite/help/25.2/Appian_Release_Notes.html

Appian, le novità della versione 25.1

Vediamo le principali novità della prima versione del 2025 del prodotto.

La versione 25.1 di Appian introduce alcune novità e molto attese da tutta la comunità di utilizzatori della piattaforma.

Novità principali della versione 25.1

Data Fabric potenziato
ora supporta fino a 10 milioni di righe per tipo di record e anche dati non strutturati. Le query complesse sono fino a 40 volte più veloci.

AI Skills più scalabili
promette una elaborazione documentale fino a 75 volte più veloce, perfetta per grandi volumi.

KPI di processo nei dashboard in Process HQ
è possibile trascinare KPI relativi ai processi direttamente nelle dashboard, con link ai processi corrispondenti.

Miglioramenti Appian AI Copilot per business users:

Chat integrata con i dati tramite a!dataFabricChatField() e Interrogazione documenti con a!documentsChatField()

Risposte in tempo reale e contestuali direttamente dentro le app

Miglioramenti AI Copilot per utenti business

Nel rilascio Appian 25.1, l’AI Copilot può interagire con due componenti principali integrate direttamente nelle applicazioni, le funzioni sono progettate per offrire assistenza AI in tempo reale e nel contesto dell’applicazione, senza passare da ambienti esterni.

Le due componenti interrogabili con l’AI Copilot

a!dataFabricChatField()

Permette agli utenti di fare domande direttamente ai dati del Data Fabric.
Ideale per trovare record o ottenere informazioni senza dover navigare tra interfacce o fare query complesse.
Esempio: un utente può chiedere “quali ordini sono in ritardo?” e ottenere una risposta contestuale e immediata.

a!documentsChatField()

Consente conversazioni con set di documenti curati direttamente all’interno dell’applicazione.
Utile per analisi testuali, riassunti automatici o per rispondere a domande su contenuti contrattuali, policy o report.
Esempio: puoi interrogare documenti HR per sapere “qual è la politica di ferie?”.

Sicurezza a livello di campo per i record field

Fino alla versione Appian 24.4, la sicurezza in un Record Type può essere impostata su due livelli principali, offrendo un controllo molto granulare:

Controlla chi può vedere ogni singola riga di dati.
Tipico per scenari in cui l’accesso dipende dal ruolo o dal proprietario del record.
Esempio: un manager può vedere solo i record dei dipendenti del proprio reparto.

Si configura tramite regole di visibilità basate sull’utente (user()), gruppi, o proprietà del record stesso.

Appian 25.01 introduce la Sicurezza a livello di campo

Tra le principali novità della prima versione del 2025 del prodotto è stata introdotta anche la Sicurezza a livello di campo (Field-Level Security).

Controlla chi può vedere ogni singolo campo all’interno di un record.
Se un utente non ha accesso a un campo, il campo può:
mostrare valore nullo (null)
essere completamente nascosto con la funzione a!doesUserHaveFieldAccess()

Con questa doppia sicurezza integrata, puoi realizzare applicazioni “zero trust”, dove ciascun utente vede solo ciò che gli è strettamente necessario.

Riferimenti

https://docs.appian.com/suite/help/25.1/Appian_Release_Notes.html

Implementare il lock dei record in Appian

In questo articolo illustriamo i meccanismi di lock disponibili sulla piattaforma appian

Non è raro un requisito in cui vi è bisogno di proteggere un record da scritture concorrenti. A tal fine, la piattaforma supporta due meccanismi di lock : il locking ottimistico e pessimistico.

I modelli di lock

I lock dei dati in Appian è implementato secondo due modelli :

Il lock ottimistico, in cui la scrittura di un record viene verificata (ed eventualmente bloccata) solo al tempo di esecuzione del commit delle modifiche sul database
Il lock pessimistico, in cui un record viene bloccato appena si richiede di effettuarne la modifica.

In generale entrambi i modelli di lock sono validi soltanto se si è coerenti nella generazione delle scritture al database, vale a dire, in tutti i casi non è garantita la coerenza dei dati a livello di sistema.

Il lock ottimistico

Il lock ottimistico si ottiene aggiungendo un campo integer sulla tabella di cui si vuole implementare i lock.
Prelevo un record con versione 1 e lo modifico, quando lo aggiorno leggo la versione: se il valore della colonna è 1 allora l’aggiornamento è valido, se invece la versione è 2 (o altro) vuol dire che quel record è stato già modificato e quindi devo bloccare l’aggiornamento.

Implementazione

Molto semplicemente, bisogna creare un campo numerico che conterrà la versione del record, successivamente aggiungere l’annotazione @Version sul campo. Dopo aver pubblicato l’entità relativa al CDT, utilizzando lo smartservice write to datastore, in caso di aggiornamenti incoerenti il sistema solleva una StaleObjectStateException che ci avverte che stiamo tentando di sovrascrivere un item già aggiornato.

Considerazioni

Con StaleObjectStateException il processo che contiene la scrittura è messo in pausa.
Sarà compito di chi gestisce la piattaforma di risolvere l’incoerenza che si è generata e nel caso scartare il processo scaduto.
Questo lock funziona correttamente solo se si utilizzano esclusivamente i write to datastore, gli aggiornamenti mediante storedprocedure restano impossibili da controllare.

Il lock Pessimistico

Il lock ottimistico è ben più complesso e meno definito da appian stesso. In sostanza dobbiamo creare un meccanismo che impedisca di recuperare il lock per la modifica in modo da assicurarci che le modifiche siano sempre coerenti.

Implementazione

Abbiamo bisogno di una tabella che contiene i lock. Tale tabella che chiamiamo lockTable dovrà contenere almeno:

Il nome del tipo dato, in questo esempio chiamiamo tale colonna NameType.
l’id del record da bloccare, in questo esempio chiamiamo tale colonna idType.

A questo punto definiamo come chiave unique la coppia NameType e idType all’interno della tabella lockTable.

Il passo successivo è creare una stored procedure getLock al cui interno proveremo a scrivere, in transazione, all’interno della tabella lockTable un record con rispettivamente il nome del tipo da modificare in NameType e come idType la chiave primaria. Infine bisogna creare una stored procedure releaseLock in cui si elimina il record dalla tabella lockTable una volta terminata la modifica.

Considerazioni

In questo caso l’eccezione lanciata dal database sarà chiave duplicata in caso di una getLock di un record già bloccato.
Sarà compito di chi gestisce la piattaforma di risolvere l’incoerenza che si è generata e nel caso scartare il processo scaduto.
Questo lock può essere utilizzato sia con stored procedure che con write to entity datastore.

Quale lock scegliere?

Appian consiglia il lock ottimistico : più leggero e facile da implementare, solo in casi estremi bisogna utilizzare il lock pessimistico. La mia risposta invece è dipende, se abbiamo un bisogno assoluto di garantire la coerenza il lock pessimistico è una buona scelta. Nel lock ottimistico un record può essere compromesso mediante stored procedure e in ottica estendibilità non metterei la mano sul fuoco per cui nel corso del tempo non si abbia bisogno di una stored procedure.

Bibliografia

https://community.appian.com/discussions/f/integrations/2995/does-appian-support-version-jpa-annotation

https://community.appian.com/w/the-appian-playbook/196/data-locking-strategies

Appian, piattaforma condivisa oppure dedicata?

In questo articolo discutiamo la necessità di dove posizionare una nuova applicazione appian, se condivisa o dedicata, considerando le nuove feature introdotte con la versione 21.3.

Abbiamo già introdotto la piattaforma nei suoi elementi più essenziali. In questo articolo fornirò la mia personalissima opinione sulla necessità di dove posizionare una nuova applicazione appian, in un ambiente ad-hoc oppure l’installazione in un ambiente preesistente.

Scenario

Il cliente ci chiede lo sviluppo di una nuova applicazione appian. Abbiamo già un ambiente di produzione in cui abbiamo già diverse applicazioni installate e funzionanti.

L’immagine è esemplificativa: vogliamo aggiungere l’Application 3 e vogliamo capire se scalare orizzontalmente o meno.

In generale dobbiamo domandarci:

In caso di fault entro quanto la mia applicazione deve ritornare disponibile?
Quale range temporale dati posso “permettermi” di perdere in caso di fault?
I dati di questa nuova applicazione necessitano di segregazione rispetto alle altre applicazioni?
Gli utenti che utilizzeranno la nuova applicazione utilizzeranno anche le applicazioni preesistenti? il dominio dei dati è strettamente correlato alla nuova utenza?

Per le domande 1 e 2, dobbiamo considerare se la nuova applicazione si discosta da quelle già presenti: è ragionevole clusterizzare le applicazioni che hanno gli stessi requisiti di alta affidabilità (HA). Sarebbe discutibile installare un’applicazione “critica” in un ambiente in cui le applicazioni preesistenti non lo sono.

La domanda 3 apre un tema in cui il prodotto si evolvendo : precedentemente alla versione 21.3 la segregazione è possibile impostando origini dati alternative e quindi utilizzando database diversi. Dalla versione 21.4 è possibile creare nuovi schemi sulla stessa instanza del database a cui le applicazioni possono accedere. Tratterò questo argomento in un futuro (stay tuned!).

La domanda 4 apre molteplici scenari: da un punto di vista della sicurezza, spesso nelle aziende la divisione dei dati è adottata come misura precauzionale per mitigare il rischio di rilascio incontrollato di informazioni, da un punto di vista prestazionale dobbiamo curare l’approccio in base al numero di utenti che verranno introdotti sulla piattaforma. Verranno aggiunti un numero non trascurabile di nuovi utenti. Per affrontare il tema dobbiamo considerare se le risorse allocate su appian sono sufficienti a sostenere l’ingresso dei nuovi utenti: in alternativa potremmo aver abbiamo bisogno fare scaling della piattaforma.

Appian riassume così i requisiti minini :

Tipologia di utilizzo	Utenti concorrenti	RAM (GB)	CPU
Applicazione singola	< 100	30	4
Uso dipartimentale	100 – 1,000	60	8
Utilizzo Aziendale	> 1,000	240	32

Raccomandazioni sizing piattaforma appian per utenti/tipologia di utilizzo

Avere un bacino d’utenza ampio è un chiaro segnale di un requisito inespresso di HA. Considero difficile che a fronte di una moltidine di utenti (quindi costi non trascurabili) fruitori non corrisponda un requisito particolare di High Availability, di fatto stiamo torniamo alla considerazione che risponde alla domanda 1 e 2.

Verranno aggiunti un numero trascurabile di utenti

In questo caso è difficile ipotizzare che si è obbligati a segregare gli ambienti: come già abbiamo visto per la domanda 3 la segregazione dei dati è ottenibile restando sulla stessa piattaforma. L’unico fattore che ci resta da considerare sono i requisiti di HA, per cui o abbiamo già requisiti molto più stringenti oppure bisogna prepararsi a requisiti molto più stringenti.

Considerazioni finali

Appian, escludendo casi particolari, consiglia l’ambiente condiviso.

I vantaggi dell’ambiente condiviso sono molteplici, cito tra i più importanti:

Possiamo riutilizzare le componenti scritte migliorando la manutenibilità dell’applicazione stessa e delle applicazioni parallele.
Velocità di sviluppo maggiore in virtù del punto 1 e dal riutilizzo delle configurazioni adottate nelle applicazioni parallele.
Maggiore economicità, creare un nuovo ambiente per un’applicazione comporta costi aggiuntivi per la manutenzione dell’instanza della piattaforma dedicata, suddivisi invece nell’ambiente condiviso.

Tra i punti di attenzione più importanti abbiamo:

Configurazione puntuale degli utenti della piattaforma : per avere una giusta segregazione dei dati abbiamo bisogno di configurare puntualmente le modalità di accesso alla piattaforma, configurazione che può diventare costosa specialmente se non eseguita in precedenza.
Bisogna prestare attenzione alle applicazioni preesistenti : gli sviluppatori devono essere formati a lavorare su una piattaforma condivisa affinché non effettuino modifiche incontrollate su elementi condivisi.

Arrivederci al prossimo articolo!

Bibliografia:

https://community.appian.com/w/the-appian-playbook/895/when-to-consider-exceptions-to-an-appian-shared-environment

https://docs.appian.com/suite/help/21.4/System_Requirements.html

Appian, Modelli di processo e Variabili.

In questo articolo è un focus dell’utilizzo delle variabili nei modelli di processo di appian.

In precedenza abbiamo visto le caratteristiche principali processi e dei modelli di processo di appian.
Abbiamo osservato che essi permettono di definire nel nostro BPM dei flussi di lavoro complessi per eseguire determinate attività. Abbiamo definito che un modello di processo non è altro che una serie di task e abbiamo visto la relazione tra un modello di processo e un processo.

Tuttavia ricorda:
I modelli di processo sono uno “scheletro” tale oggetto permette di definire le operazioni che verranno eseguite dal processo.

Chiaramente in questo contesto le variabili nei processi e nelle interfacce giocano un ruolo essenziale.

Le caratteristiche delle variabili nei modelli di processo

Le variabili di processo hanno più fattori distintivi

Il tipo
La visibilità
La struttura

Le variabili all’interno di un modello di processo possono assumere tipi semplici, come testo, numero, numero decimale e booleano e tipi complessi come i CDT: non è permesso l’uso del tipo “Any Type” (“qualsiasi tipo” in italiano).

Per utilizzare una variabile come AnyType è possibile impostare un tipo come Map che è equivalente oppure (pratica che sconsiglio) utilizzare un parametro di tipo DataSubset.

Configurare una variabile di processo

Le variabili possono avere visibilità pubblica o nascosta.
La visibilità pubblica di una variabile vuol dire che questa sarà visibile al processo chiamante e ai report, mentre la visibilità nascosta permette di rendere la variabile visibile soltanto all’interno del processo: di default la visibilità sarà sempre pubblica, ma la si può impostare nascosta semplicemente flaggando la checkbox “hidden” nella definizione della variabile (4 nella figura sotto).

Quando utilizzare una variabile hidden? in generale quando vogliamo ridurre l’utilizzo di memoria dei processi, sacrificandone la visibilità e per impedire che una variabile possa risalire nei processi.

Configurazione nuova variabile di processo

Altre caratteristiche delle variabili è la possibilità di ricevere un parametro in input o meno: in tal caso le chiameremo variabili parametriche. Per rendere una variabile come parametrica basta flaggare la checkbox “Parameter” (1 nella figura sopra) nella definizione della variabile (riquadro in azzurro).
Le variabili parametriche possono essere forzate dal designer a ricevere un valore: per farlo basta flaggare la checkbox “Required” (2 nella figura sopra).

Infine come tutte le variabili di appian possono essere definite come Array, cliccando sulla checkbox “Multiple” (3 nella figura sopra).

Variabili predefinite e smart service

I modelli di processo, come visto in precedenza può esser visto come una sequenza di smart service legati da un inizio e almeno una fine.

Se scendiamo a livello di smart service, o più in generale delle activity, le variabili hanno un diverso livello di visibilità, abbiamo:

Le variabili di processo (quelle che abbiamo descritto fin’ora)
Le variabili locali alle activity.

Le variabili di processo hanno come prefisso “pv” pertanto per riferirci ad esse all’interno del processo, dovremo utilizzare la notazione “pv!nome_variabile_di_processo“.

Le variabili locali alle activity hanno come prefisso “ac” pertanto per riferirci ad esse all’interno del processo, dovremo utilizzare la notazione “ac!nome_variabile_activity”.

Tuttavia esistono delle variabili “predefinite” con un valore che riporta un aspetto del processo o dell’activity in cui sono contenute.

Abbiamo tra le altre:

le task properties, indicate con “tp!” che riportano le proprietà dell’activity, o del task: ad esempio “tp!id” riporta l’id del task in uso.
le process properties indicate con “pp!” che riportano le proprietà dell’istanza di processo in esecuzione: ad esempio nella variabile “pp!id” sarà contenuto l’id del processo in esecuzione.
le process model properties indicate con “pm!” che riportano le proprietà del processo in esecuzione: ad esempio nella costante “pm!id” sarà contenuto l’id del processo aperto: chiaramente tutte le proprietà in questo caso saranno costanti.