A helpful guide for those working with Camunda or Flowable who want to design processes the right way without surprises.Abbastanza spesso è necessario effettuare chiamate API a vari servizi esterni. In sostanza, si tratta di uno scenario di orchestrazione di sistema standard o addirittura di un scenario di orchestrazione di microservizi (mi scuso per il termine di tendenza). Sembra semplice e logico in un diagramma BPMN – bussiamo a qualche porta usando un’API, riceviamo una risposta e passiamo al compito successivo. Per i modelli a livello di analisi tutto è abbastanza normale.
## Esecuzione sincrona e asincrona
I motori BPM supportano due tipi di esecuzione di attività: sincrona e asincrona. A mio parere, questi nomi sono piuttosto sfortunati e inadatti, e aggiungono solo confusione.
In effetti, si tratta dei confini delle transazioni e non della vera asincronia. Nel contesto BPMN, l’esecuzione asincrona delle attività è correlata a come il processo memorizza il suo stato e gestisce l’esecuzione del passaggio.
Quando si contrassegna un’attività come asincrona (ad esempio, con `asyncBefore` in Camunda o `async` in Flowable), l’esecuzione del processo viene esplicitamente divisa in transazioni separate. Nel limite asincrono, il motore memorizza lo stato corrente del processo nel database e crea un job nella coda dei job. Un componente speciale preleverà successivamente quel job e continuerà l’esecuzione in una **nuova transazione**. (In Camunda, `asyncAfter` differisce leggermente – significa che la divisione avviene dopo l’esecuzione dell’attività ma prima del passaggio successivo.)
Pertanto, l’asincronia in BPMN è un modo di gestire le transazioni o l’elaborazione dei task tramite una coda e non l’esecuzione parallela di codice o thread.
Source: Una chiamata non bloccante di un servizio esterno all’interno di un processo
