JUG Day e low code

[Paolo Tomelleri]

Ciao a tutti 

sabato con dispiacere non ho potuto essere al JUg Day

per malessere stagionale ;)

Commentando la giornata con Andrea Adami , relatore e organizzatore seriale di riffe ;)  a precisa domanda mi ha detto che si è parlato sia  di low code che di  bpm e mi è dispiaciuto ancora di più non aver partecipato :(

E' un po' di tempo che mi informo su  BPM a livello di documentazione, qualche libro, un paio di corsi e qualche yuotube di sviluppatori "ufficiali".

Tutti gli esempi che ho visto sono diagrammi relativamente semplici (un task=processo) , ognuno al massimo un paio di "lane" che comunicano (sottoprocessi in parallelo) e poco altro. 

La resa grafica è buona e anche l'implementazione (guardando il codice), ma come si sa una cosa è scrivere "hello world" e un'altra sviluppare una applicazione.

Vi  chiedo , visto che ne avete parlato anche sabato, di condividere qualche informazione sulle vostre esperienze/idee su low code e sopratutto BPM,

perché penso potrebbero interessare oltre a me anche al gruppo. 

Per iniziare basterà cominciare dalla domanda se come tecnologie  possono avere  un futuro :) e cioè se vale la pena di investire tempo e risorse mentali per acquisirle.

( Per me sì, ma la mia esperienza  ,come detto sopra, non è suffragata da esperienze pratiche :)

Buona serata

Paolo T.

[Lucio Benfante]

Ciao,

avevo dimenticato questo tuo messaggio.

La mia esperienza nel "no/low Code" sono sempre state pessime, sia che si trattasse di usare BPM, sia di prodotti che sostanzialmente generavano codice mediante un'interfaccia grafica.

Spesso invitanti provandoli nelle cose semplici ed esempi di poco più di un "hello world", ma poco produttivi e scarsamente manutenibili nel tempo, non appena si passa all'uso reale.

Boh, magari qualcosa è cambiato, ma personalmente non credo che ci dedicherò del tempo.

Saluti 

  Lucio

[Marco Scarpa]

Io ho avuto a lavoro dove sono stato 10 anni esperienza con MapForce (il titolare dell'azienda è un grafico, ha scoperto che InDesign poteva importare XML duplicando automaticamente le ripetizioni e da allora si è fissato sull'XML) che è un tool grafico per realizzare mappature che trasformano XML prendendo anche da database ed altro ( https://www.altova.com/mapforce ), non essendo il titolare dell'azienda uno sviluppatore, per lui era questo lo strumento di elezione.

Per l'opinione che mi sono fatto è che va bene per fare progetti semplici ed immediati (praticamente in testa dovresti avere già tutto chiaro e il lavoro fisico dovrebbe essere solo collegare fili nell'interfaccia sapendo già come andrebbe fatto) che non dovranno mai essere modificati (impossibile) perché consente di risparmiare boilerplate, ma se qualcosa non funziona, preferisco bestemmiare un'ora su un codice che posso tracciare con un debugger che bestemmiare un'ora su una mappatura di cui devo indovinare le logiche ed inventarmi qualcosa per scoprire cosa non va (ammesso di riuscirci e che sia fattibile); inoltre, se si deve modificare qualcosa, diventa un incubo, oltre al fatto che si rimane bloccati a dover per forza modificare le mappature senza possibilità di passare ad altro perché significherebbe perdere le funzionalità già implementate per il cliente in mappatura. 

[Paolo Tomelleri]

Nella mia domanda iniziale in lista ho messo insieme low code e Bpm, ma dovevo separare.

Quello che attrae di entrambi è la promessa di disaccoppiare la logica delle operazioni dalla loro implementazione ovvero semplificando al massimo  non scrivere la logica usando un linguaggio di programmazione.

Per il low code effettivamente come dice Marco Scarpa se non hai codice sorgente sottostante ovvero se hai  una soluzione proprietaria diventa veramente un problema, se non un incubo:))

In alcune applicazioni open source potrebbe funzionare, in questi giorni sto "giocando" con Home Assistant e partendo da un file .yaml si genera il codice da inserire nel microcontrollore esp32 che dialogherà con l'applicazione. Non è proprio low code e non è di facile lettura le prime volte,  ma non si scrive una linea di codice  (in realtà al momento ci sono due righe di C++ nel .yaml sotto forma di stringhe).  

Per Il Bpm a livello di notazione la promessa sembra mantenuta, soprattutto per la concorrenza, però è vero come dice Lucio che non si trovano esempi molto strutturati di diagrammi eseguibili , per cui l'hello word è banale, ma poi quando affronti un problema vero la semplicità sembra che non sia scalabile. 

Gli esempi più articolati forniti dai fornitori di software (open source) tipo  RedHat o Camunda sono coordinamenti  semplici di servizi.

Leggendo qualche libro sulla progettazione Bpm si viene consigliati  di "andare piano" :) ovvero partenza da piccoli progetti. Mi sono fatto l'idea che in realtà la curva di apprendimento sia molto lenta per avere risultati.

Mi piacerebbe sentire se qualcuno conosce qualche applicazione (open source e NON accademica)  che ha delle funzionalità  sviluppate con l'esecuzione di workflow  Bpm , per poter vedere i diagrammi e le loro interazioni. Bpm usato solo come documentazione va bene, ma non aggiunge niente di nuovo devi comunque passare alla codifica della logica.

Ps: Nondimeno  al prossimo meeting se siamo a corto di presentazioni, con Adami, vi 'costringiamo' a vedere  un po' di low code in Home Assistant ;)))

Buona giornata.

--
Hai ricevuto questo messaggio perché sei iscritto al gruppo "JUG Padova" di Google Gruppi.
Per annullare l'iscrizione a questo gruppo e non ricevere più le sue email, invia un'email a jugpadova+...@googlegroups.com.
Per visualizzare questa discussione, visita https://groups.google.com/d/msgid/jugpadova/d3a8444e-d45e-4ac0-b9ef-93db4eaea918n%40googlegroups.com.

[Pierangelo Dal Maso]

Mi permetto di accodarmi, perché il tema BPM interessa anche a me ma ho la stessa sensazione che, al di la dell'esercizio accademico, ci siano pochi reali utilizzi pratici in workflow "corposi" - e inoltre sarebbe da capire il comportamento quando, as usual, il workflow analizzato per mesi in ore ed ore di riunioni e perfettamente messo a punto si scopre al golive che non c'entrasse niente con quello che serviva nel concreto.

Pierangelo

Il 29/01/25 11:50, Paolo Tomelleri ha scritto:

Per visualizzare questa discussione, visita https://groups.google.com/d/msgid/jugpadova/CAPxf6EB0rR97yTY%2B4i%2BCpURp1B70ngi0xQu796bRtMEEKmmp_g%40mail.gmail.com.

-- 
Pierangelo Dal Maso
Newel s.r.l.
Via Castellantico 39, 30035 Mirano (VE)
Tel.  041-4266515
Cell. 328-8728029

[Marco Bettiol]

Ciao,
di progetti opensource che usano BPM non vi saprei dire ma per lavoro ho una certa esperienza con jBPM.
Lo usiamo per modellare processi "automatici" che orchestrano servizi REST. I volumi sono considerevoli: centinaia di migliaia di processi al giorno.
A livello di modellazione BPMN credo che tutti i prodotti abbiano la stessa capacità espressiva
ma poi quando entri nel dettaglio ciascuno ha la sue peculiarità:
- ad esempio i modi per indicare i riceventi di una signal cambiano in base al prodotto usato
- oppure la gestione dei punti di consistenza di un processo (quando il BPM "salva")

Tendenzialmente jBPM non mi sento di consigliarlo per problematiche di concorrenza e nella gestione dei timer che obbligano a fare sviluppi per aggirare limiti del prodotto.
A quando ho visto meglio Camunda.

Nessuno dei 2 rientra in ambito lowcode.

Come linea di massima:

- jBPM (RedHat): sebbene lo utilizziamo non lo consiglio
- Kogito (RedHat): mi è sembrato un calderone di troppe tecnologie mischiate assieme
- Camunda 7: credo ormai sia non mantenuto ma da quanto ho visto e da esperienze di colleghi è valido. Ha una architettura tradizionale
 Java + Db relazionale che mi sembra ancora la più adeguata per la maggior parte dei casi d'uso. Ed il codice del prodotto è ben scritto.
- Camunda Platform: no esperienza diretta ma sembra lo stato dell'arte dei motori BPM. Orchestrazione asincrona, message buffering,
  si sono scritti un loro "broker" stile kafka per scalare ed eviare problematiche di concorrenza. Sicuramente ha la sua complessità a livello di infrastruttura.
- piattaforma low-code di Appian : conoscenti che ci hanno lavorato mi dicevano che sviluppi banali su jBPM sembravano fantascienza per Appian ma non so entrare più nel dettaglio


Inizialmente ero molto scettico sui BPM ma devo dire che hanno il beneficio di obbligare a scomporre
un problema in una sequenza di passi e essendo tool grafici forniscono implicitamente  visibilità sull'avanzamento.
Ovviamente sono XML per cui addio merge di sviluppi ma diciamo che dopo le fasi iniziali di un progetto
un disegno non cambia così frequentemente e un  processo grande probabilmente si puo' scomporre in sottoprocessi più piccoli.

Inoltre si presta bene a essere testato con mock per garantire la non regressione
essendo alla fine un modello BPM una sequenza di input/output su ogni nodo.

Rimango a disposizione.

Ciao,
Marco
  

Per visualizzare questa discussione, visita https://groups.google.com/d/msgid/jugpadova/44c260e5-a9bf-45e3-b512-80b411dacd2b%40newelsys.it.

[Paolo Tomelleri]

Ho alcune domande sparse per Marco Bettiol che ringrazio per aver dato "incautamente"  la sua disponibilità :)

Il che mi ha permesso di allargarmi un po' :)

1) Con il Bpm pensavo che la manutenzione del codice per modifiche di logica fosse più sotto controllo, dal momento che i task possono essere a loro volta dei processi con task.   Mi immaginavo che dopo una modifica nel grafico bpm , tipo inserimento di un task e/o aggiunta di una decisione, il tutto fosse direttamente, via maven,  compilabile nel codice finale e subito runnabile, ma mi sembra di capire che non è così lineare [vedi anche intervento di Dal Maso]

2) nel Bpm sono previste delle estensioni DMN (Decision Managment Notation: file esterni tipo excell con variabili ed espressioni booleane) per rendere la business logic un po' configurabile in sede di decisioni, hai avuto modo di vederle in azione?

3.1) Nella tua risposta indichi che <<la gestione dei punti di consistenza di un processo (quando il BPM "salva")>> è uno dei punti in cui i motori Bpm differiscono , è corretto tradurre  consistenza di un processo    come controllo  regole di business?

3.2) Il punto precedente ha a che fare con le Drooles di Red Hat?

(In Bpm le ho viste associate ai controlli di "tutte" le regole di business alla fine di un task in un libro "datato" della Manning  su Activiti, generatore di workflow usato anche in Alfresco: Drooles mi sono sembrate molto potenti per via della centralizzazione dei controlli) 

4) Mi sono fatto l'idea che "una funzionalità potenzialmente rilasciabile" cioè un "Sprint" Scrum possa essere ben formalizzato con un Bpm, ci sono controindicazioni? 

5) Una mia considerazione per quanto riguarda i motori Bpm (Bpel): Camunda,  sembra il migliore, ma  va  verso soluzioni enterprise.

Come open source oltre a jBpm che però non è indicato per timer e concorrenza ho trovato solo due alternative: "Activiti" e "Bonita".

Per quanto ho visto tempo fa "Bonita" permette anche l'aggiunta di connettori per inserire estensioni,  per entrambi cercherò di vedere per quanto possibile come gestiscono concorrenza e timer, provando con un grafico ad hoc.

Magari qualcuno conosce altri programmi alternativi.

Per Python e Rust, dopo una ricerca molto superficiale , ho trovato solo diverse librerie Xml adattate per il parsing dell' Xml fornito da Bpm.

Ciao

Paolo Tomelleri

Per visualizzare questa discussione, visita https://groups.google.com/d/msgid/jugpadova/CABgs63_O%2Bi%2Bt-0FXVVw9XqmRfrdTRCZam3w9ZR4y5rtO%3Dsx4bQ%40mail.gmail.com.

[Marco Bettiol]

Ciao Paolo,

Q1) Con il Bpm pensavo che la manutenzione del codice per modifiche di logica fosse più sotto controllo, dal momento che i task possono essere a loro volta dei processi con task.   Mi immaginavo che dopo una modifica nel grafico bpm , tipo inserimento di un task e/o aggiunta di una decisione, il tutto fosse direttamente, via maven,  compilabile nel codice finale e subito runnabile, ma mi sembra di capire che non è così lineare [vedi anche intervento di Dal Maso]

A1) Provo a risponderti anche se non ho capito benissimo. La modularizzazione padre figlio c'è e quindi puoi incapsulare complessità
per renderla riutilizzabile ma diff sui sorgenti non è molto utile su XML generati da editor. Vai di documentazione esterna + numero issue ed eventualmente svg del disegno se la modifica ha un riscontro visivo. A livello di build e run è abbastanza vicino a quello che indichi.

Jbpm ad esempio ha dei task handler che invocano funzioni java ed effettivamente compilano contro i class.
I nodi di scripting possono essere scritti in vari linguaggi tra cui java ed effettivamente viene compilato ma a runtime. Alla fine tutto l'XML risulta in un compilato java ma di cui non hai il sorgente ed esiste solo in forma compilata "in memoria".
Usa un suo formato di impacchettamento maven based che si chiama kjar

Camunda non compila ma è puramente interpretato dal BPMN2.

Q2) nel Bpm sono previste delle estensioni DMN (Decision Managment Notation: file esterni tipo excell con variabili ed espressioni booleane) per rendere la business logic un po' configurabile in sede di decisioni, hai avuto modo di vederle in azione?

A2) parlo per JBPM. Abbiamo deciso di non usare DMN per varie ragioni:
- editor JBPM si "rompeva male" durante il data entry
- questioni di evoluzione tra BPM e DMN: volevamo non essere legati a problemi di retro compatibilità su istanze di processo esistente se cambiava la struttura della DMN.
- per utilizzare DMN devi far transitare tutti i dati di accesso alle regole su BPM: generalmente cerchiamo di fornire a bpm solo le variabili decisionali minime di suo interesse per navigare il workflow
- Debug in caso di caso DMN diverso da quello atteso e poter facilmente giustificare il perchè regola selezionata
- questo vado a memoria : difficoltà di esprimere regole su assenza di valori con DMN

In sostanza quello che è DMN lo esternalizziamo su sviluppi normali java.

Q3.1) Nella tua risposta indichi che <<la gestione dei punti di consistenza di un processo (quando il BPM "salva")>> è uno dei punti in cui i motori Bpm differiscono , è corretto tradurre  consistenza di un processo    come controllo  regole di business?

Q3.1) No - fatti questa domanda: Quando è che il motore salva il suo stato (cioè variabili e nodi attualmente attivi) su database?
 Sicuramente salva quando ha nodi attivi e non ha ulteriori archi percorribili. Questo ad esempio avviene quando dei task sono asincroni:
 - timer per attendere un certo istante temporale
 - signal di attesa di un evento/messaggio
 - oppure un task umano per cui un operatore deve interagire.

Oppure meccanismi interni del motore.

Tendenzialmente se hai interazioni con sistemi esterni non transazionali ti interessa perchè in caso di rollback del motore
viene ripristinato l'ultimo punto di salvataggio.

E in questo ambito ti interessa ancora di più in caso di disegni con rami di esecuzione paralleli.

Q3.2) Il punto precedente ha a che fare con le Drools di Red Hat?
(In Bpm le ho viste associate ai controlli di "tutte" le regole di business alla fine di un task in un libro "datato" della Manning  su Activiti, generatore di workflow usato anche in Alfresco: Drools mi sono sembrate molto potenti per via della centralizzazione dei controlli)

A3.2)

No.
Drools è il motore sotto ma non centra con i punti di persistenza se non perchè l'elaborazione sicuramente termina quando nessuna "rule" è più in grado di fare "fire".

Ma altri BPM usano modelli di esecuzione più specifici e semplici rispetto a Drools.

Drools dal mio punto di vista è sovra complicato per quello che deve fare un BPM e non mi piace molto che la persistenza dello stato di default avvenga serializzando la memoria in un blob.

Q4) Mi sono fatto l'idea che "una funzionalità potenzialmente rilasciabile" cioè un "Sprint" Scrum possa essere ben formalizzato con un Bpm, ci sono controindicazioni?

A4) organizzativo. sicuramente con BPM rilasci qualcosa di incrementare che si avvicina a uno usecase.
Ed essendo orchestrazione lo rilasci dopo che tutte le dipendenze/servizi utilizzati sono disponibili e installate.

Q5) Una mia considerazione per quanto riguarda i motori Bpm (Bpel): Camunda,  sembra il migliore, ma  va  verso soluzioni enterprise.

Come open source oltre a jBpm che però non è indicato per timer e concorrenza ho trovato solo due alternative: "Activiti" e "Bonita".
Per quanto ho visto tempo fa "Bonita" permette anche l'aggiunta di connettori per inserire estensioni,  per entrambi cercherò di vedere per quanto possibile come gestiscono concorrenza e timer, provando con un grafico ad hoc.
Magari qualcuno conosce altri programmi alternativi.

Per Python e Rust, dopo una ricerca molto superficiale , ho trovato solo diverse librerie Xml adattate per il parsing dell' Xml fornito da Bpm.

A5) non visti

Ciao,

Marco

Per visualizzare questa discussione, visita https://groups.google.com/d/msgid/jugpadova/CAPxf6ED%3DPq--1%2BS%3Dps0U8uSYE3PUow1s%3D_kmNBs4rbeL%2BWnCTQ%40mail.gmail.com.

[Paolo Tomelleri]

Ciao a tutti

ringrazio ancora  Marco Bettiol

Mi ha chiarito diversi punti  adesso mi sono fatto una piccola roadmap per prendere veramente contatto con il problema, limitando le mie aspettative.

1) Vedere come viene tradotto in xml un diagramma Bpm molto concorrente, se ne trovano in letteratura, senza implementazioni.

2) Vedere come traducono l'xml  in una implementazione i prodotti open source, al momento ho selezionato Activiti e probabilmente Camunda 7.

Se produco un minimo di informazioni, ne parleremo brevemente a una prossima riunione del Jug,

quando con Adami faremo vedere qualcosa su Home Assistant e sui file yaml che hanno dei punti in comune con i bpm.

Ciao

Paolo Tomelleri

Per visualizzare questa discussione, visita https://groups.google.com/d/msgid/jugpadova/CABgs63__fd073LZoR0G9zWuwXp3oJj8_2VBT-W8r-N1eAh_JgA%40mail.gmail.com.