La gerarchia delle scelte di estensione

In PL-400 la domanda ricorrente non è “so scrivere questo codice?”, ma “qual è lo strumento meno costoso da manutenere che soddisfa il requisito?”. Microsoft impone una gerarchia precisa: prima configurazione out-of-the-box, poi low-code (business rule, cloud flow, colonne e controlli standard, PCF di community), infine pro-code (plug-in, custom API, JavaScript, Azure Functions). Salire nella scala solo quando il livello inferiore non copre il requisito. Ogni scalino aggiunge costo di ALM, dipendenza da sviluppatori e superficie di manutenzione.

I due assi decisionali: low-code/pro-code e client/server

Ogni estensione va collocata su due assi indipendenti:

  • Low-code vs pro-code: quanto codice e quale pipeline di build servono per costruirla e aggiornarla.
  • Client-side vs server-side: dove viene eseguita la logica.

L’asse client/server è spesso quello che decide la risposta. La logica client-side (business rule, form script con Client API, PCF, logica di canvas app) dà feedback immediato ma non è un confine di sicurezza: può essere bypassata da API, import di dati o integrazioni. La logica server-side (plug-in, custom API, cloud flow) viene applicata indipendentemente dal client ed è l’unica scelta valida quando serve integrità del dato.

Decisioni ricorrenti d’esame

Business rule vs plug-in

Una business rule copre logica dichiarativa su una tabella: impostare/pulire valori, mostrare/nascondere, abilitare/disabilitare, rendere obbligatorio, mostrare messaggi di validazione. Con scope “Entity” gira anche server-side su create/update. Preferiscila quando la logica è semplice e legata a poche colonne. Passa al plug-in quando servono: iterazioni, query su altre tabelle, chiamate esterne, controllo sulla pipeline (pre-validation, pre-operation, post-operation) o rollback transazionale. Se la regola è di data integrity e deve valere anche per import/API, la business rule (o il JavaScript) non basta: serve un plug-in server-side.

Colonna/controllo standard vs PCF

Prima di scrivere un PCF (Power Apps Component Framework) code component, verifica se un controllo standard risolve: choice, toggle, slider, star rating, campi rich text sono già disponibili. Il PCF è giustificato solo quando l’esperienza richiesta (rendering custom, interazione, visualizzazione di dataset) supera i controlli nativi. È pro-code TypeScript con un ciclo di build e va versionato in una solution: costo di manutenzione reale, da spendere solo quando la UX lo richiede davvero.

Cloud flow asincrono vs plug-in sincrono

Un plug-in sincrono esegue dentro la transazione dell’operazione: latenza immediata, può bloccare il salvataggio e fare rollback. Usalo quando devi validare o impedire l’operazione, o garantire consistenza nella stessa transazione. Ma allunga il tempo percepito dall’utente e ha limiti stretti (timeout circa 2 minuti): mai chiamate a sistemi esterni in sincrono.

Un cloud flow asincrono (o un plug-in registrato asincrono) è la scelta corretta quando l’operazione non deve completarsi prima di restituire il controllo all’utente: notifiche, integrazioni, arricchimento dati, orchestrazione. Il cloud flow è low-code, ricco di connector e più facile da manutenere, a costo di eventual consistency, latenza e nessun rollback dell’operazione scatenante.

Supportabilità, performance e ALM

  • Supportabilità: le soluzioni low-code (business rule, cloud flow) sono upgrade-safe e non richiedono manutenzione dell’SDK; il pro-code va aggiornato e presidiato.
  • Performance: i plug-in sincroni estendono la transazione — tienili leggeri, senza I/O esterno; le business rule danno feedback istantaneo lato client.
  • ALM: tutto deve stare in una solution. I plug-in (assembly) e i PCF sono codice e richiedono source control e pipeline di build; i cloud flow richiedono connection reference ed environment variable per essere deployabili tra ambienti. Più pro-code introduci, più pesante diventa il tuo ciclo di rilascio.

Trappole tipiche d’esame

  • Mostrare/nascondere e rendere obbligatoria una colonna in base a un’altra sul form → business rule, non JavaScript né plug-in (minimo costo).
  • Regola che deve valere anche per import bulk e chiamate API, non solo sul form → plug-in sincrono server-side (pre-validation/pre-operation), perché la validazione client-side è bypassabile.
  • Alla creazione del record, inviare dati a un sistema esterno senza far attendere l’utente → cloud flow asincrono (o plug-in async), mai un plug-in sincrono con chiamata esterna.
  • Serve un controllo visuale custom su una colonna (es. slider o rendering particolare) → PCF code component, ma solo dopo aver escluso i controlli standard.
  • Scelta tra riscrivere logica in pro-code o usare una configurazione nativa → parti sempre dal livello meno costoso che soddisfa il requisito; sali a plug-in/PCF solo quando low-code non basta.