Perché i pattern di integrazione sono un tema da architect

In PL-600 raramente ti viene chiesto “come si configura” un connettore: ti viene descritto uno scenario di business con vincoli (volume, latenza, affidabilità, dipendenze da sistemi legacy) e devi scegliere il pattern che meglio bilancia i pilastri dell’Azure Well-Architected Framework — in particolare Reliability, Performance Efficiency e Operational Excellence. La domanda ricorrente è: sincrono o asincrono? La risposta corretta quasi mai è “chiama il sistema a valle in tempo reale e spera”.

Sincrono vs asincrono: il trade-off centrale

L’integrazione sincrona (es. connettore custom o HTTP verso un’API, plug-in Dataverse in pipeline stage sincrono) è semplice da ragionare e restituisce subito il risultato all’utente. Il problema è l’accoppiamento temporale: se il sistema a valle è lento, sotto throttling o down, l’operazione utente fallisce o va in timeout. In un plug-in sincrono peggiora: blocchi la transazione Dataverse e rischi rollback a cascata.

L’integrazione asincrona (Dataverse events → Azure Service Bus, plug-in in async mode, Power Automate con code) disaccoppia produttore e consumatore. Il sistema di origine deposita un messaggio e prosegue; il consumatore lo elabora al proprio ritmo. Questo assorbe i picchi di carico (load leveling) e sopravvive ai failure temporanei del downstream.

Regola di design da ricordare: scegli sincrono solo quando l’utente ha bisogno immediato del risultato per proseguire (es. validazione di credito prima di confermare un ordine) e il sistema a valle è affidabile e veloce. In tutti gli altri casi, preferisci asincrono.

Gli strumenti e quando usarli

  • Dataverse plug-in sincrono: validazioni e trasformazioni atomiche dentro la transazione. Mai per chiamate esterne lente.
  • Dataverse plug-in asincrono / Power Automate: orchestrazioni “fire-and-continue” tolleranti a latenza.
  • Service Bus (queue): pattern punto-a-punto con un consumatore. Ideale per load leveling e per garantire l’elaborazione ordinata (con sessions) ed esattamente-una-volta lato business.
  • Service Bus (topic/subscription): pattern publish/subscribe, quando più sistemi devono reagire allo stesso evento in modo indipendente.
  • Webhook Dataverse: consegna sincrona push a un endpoint HTTPS che risponde subito; utile per notifiche a servizi custom, ma senza la resilienza intrinseca di una coda.
  • Azure Event Grid / Event Hubs: rispettivamente routing di eventi discreti e streaming ad altissimo volume (telemetria, IoT), non per messaggi transazionali di business.

Batch vs event-driven

Il batch (esportazioni schedulate, riconciliazioni notturne) è corretto quando i dati non richiedono aggiornamento immediato e il volume è alto: riduce chiamate e costi. L’event-driven è preferibile quando la reattività conta e gli eventi sono granulari. Un errore d’esame è forzare event-driven real-time dove un batch orario sarebbe più economico e sufficiente.

Progettare per la Reliability

Un design asincrono diventa affidabile solo con tre elementi:

  • Retry con backoff esponenziale: gestisce failure transitori senza martellare il downstream. Service Bus offre delivery count e retry nativi.
  • Idempotenza: poiché la consegna può essere at-least-once, lo stesso messaggio può arrivare due volte. Il consumatore deve usare una chiave di deduplicazione (es. correlation ID / message ID) così che una rielaborazione non crei duplicati.
  • Gestione del throttling: Dataverse e le API SaaS applicano service protection limits (429 + Retry-After). Il consumatore deve rispettare Retry-After e regolare la concorrenza. Service Bus aiuta smorzando il flusso a valle.

Completano il quadro dead-letter queue per i messaggi non elaborabili (poison messages), monitoring con Application Insights e transactional outbox per evitare di perdere eventi tra commit del dato e pubblicazione del messaggio.

Trappole tipiche d’esame

  • Requisito: elaborare picchi di 50.000 ordini in ingresso senza perdere richieste, sistema ERP a valle lento e talvolta offline → soluzione raccomandata: pubblicare gli eventi su Azure Service Bus queue e consumarli in modo asincrono con retry e dead-letter. Non chiamare l’ERP in un plug-in sincrono.
  • Requisito: l’utente deve vedere subito l’esito di una verifica antifrode prima di salvare → soluzione raccomandata: chiamata sincrona (plug-in sync o connettore) a un servizio a bassa latenza; l’asincrono qui non soddisfa il vincolo funzionale.
  • Requisito: tre sistemi diversi devono reagire allo stesso “cliente creato” in modo indipendente → soluzione raccomandata: Service Bus topic con subscription (pub/sub), non tre integrazioni punto-a-punto accoppiate.
  • Requisito: la stessa notifica potrebbe arrivare più volte e non deve creare record duplicati → soluzione raccomandata: consumatore idempotente con chiave di deduplicazione; non affidarsi alla “consegna esattamente-una-volta” del trasporto.
  • Requisito: integrazione va in errore 429 sotto carico → soluzione raccomandata: rispettare Retry-After, backoff esponenziale e coda a monte per il load leveling; non aumentare semplicemente il parallelismo.