--- schema_version: "1" id: 6181016264296816f2d0ee0d05e5ac2e6816aa044cd09b7c8476a78ef2c03d42 title: Eccellenza operativa - Schemi di automazione collection: architect version: current locale: it-it portal_url: https://docs.salesforce.com/architect/current/it-it/well-architected/guides/operational-excellence-automation-patterns.md canonical_url: https://architect.salesforce.com/docs/architect/it-it/well-architected/guide/operational-excellence-automation-patterns.html source_site: architect.salesforce.com content_type: documentation content_hash: 9b611530931d59454f9b6f4f8964c919eca3ceb6f4a81ec900fd83de2815b25d products: - Framework ben progettato - Architect Site Content Repo --- # Eccellenza operativa - Schemi di automazione
Ulteriori informazioni sull'[eccellenza operativa](/docs/architect/it-it/well-architected/guide/operational-excellence.html) ben progettata → [Automazione ed efficienza](/docs/architect/it-it/well-architected/guide/operational-excellence.html#automation-and-efficiency) ## KPI e metriche **Schemi** | Dove cercare | Che bell'aspetto | | --- | --- | | Piattaforma \| Cruscotti digitali | ✅ Tutte le metriche correlate ai KPI sono incluse in almeno un cruscotto digitale | | Piattaforma \| Documentazione | ✅ Gli output per ogni automazione sono misurabili e temporizzati | | Piattaforma \| Documentazione | ✅ Gli stakeholder responsabili sono elencati per ogni KPI | **Anti-schemi** | Dove cercare | Che brutto aspetto | | --- | --- | | Piattaforma \| Cruscotti digitali | ⚠️ La generazione di rapporti KPI non esiste o mancano nei cruscotti digitali metriche correlate ad alcuni KPI | | Piattaforma \| Documentazione | ⚠️ Esistono KPI senza stakeholder responsabili | | Piattaforma \| Documentazione | ⚠️ Non esistono KPI per le automazioni o hanno intervalli di tempo non chiari per le misurazioni | ## Automazione dichiarativa **Schemi** | Dove cercare | Che bell'aspetto | | --- | --- | | Piattaforma \| Flusso | ✅ Flow Builder viene utilizzato per l'automazione attivata da record (sostituendo Process Builder e le regole di flusso di lavoro) | | Piattaforma \| Flusso | ✅ I flussi attivati da record con esecuzione prima del salvataggio vengono utilizzati per la popolazione dei campi prima della creazione del record | | Piattaforma \| Flusso | ✅ I flussi gestiscono la logica decisionale, i loop, le chiamate API, le operazioni DML e la complessa orchestrazione a più fasi | | Piattaforma \| Flusso | ✅ Il controllo delle transazioni del flusso viene utilizzato per confermare le modifiche intermedie quando necessario | | Piattaforma \| Flusso | ✅ La gestione dei guasti è implementata per il ripristino grazioso degli errori nei flussi | | Piattaforma \| Flusso | ✅ I flussi schermata reattivi offrono esperienze utente dinamiche | | Piattaforma \| Flusso | ✅ L'automazione dichiarativa viene scelta quando gli utenti aziendali o gli amministratori devono modificare la logica senza il coinvolgimento dello sviluppatore | | Piattaforma \| Flusso | ✅ Le variabili non fanno riferimento a valori codificati (per tipi di record, utenti, ecc.) | | Piattaforma \| Flusso | ✅ La logica dei flussi passa ad Apex in contesti con grandi volumi di dati | | Piattaforma \| Flusso | ✅ I sottoflussi vengono utilizzati per le sezioni dei processi che devono essere riutilizzate in tutta l'azienda | | Piattaforma \| Flusso | ✅ Tutti i flussi AutoLaunched utilizzano elementi decisionali e/o di pausa per valutare i criteri di immissione e impedire loop o esecuzioni infinite su grandi volumi di dati | | Piattaforma \| Flusso | ✅ Gli utenti sono invitati a fornire dati solo quando i dati di sistema esistenti non possono essere utilizzati | | Piattaforma \| Flusso | ✅ I flussi sono organizzati in una struttura gerarchica costituita da un flusso principale e sottoflussi di supporto | | Piattaforma \| Flusso | ✅ Tutti gli input utente hanno uno scopo chiaro all'interno del flusso | | Piattaforma \| Flusso | ✅ Ogni flusso serve un unico scopo specifico | | Piattaforma \| Flusso | ✅ Ogni fase esegue un'operazione specifica e granulare | | Piattaforma \| Flusso | ✅ Tutti i flussi avviati nel contesto utente astraggono le transazioni del contesto di sistema ai sottoflussi, posizionate in modo coerente dopo l'elemento Pausa per creare una nuova transazione | | Piattaforma \| Flusso | ✅ Tutti i flussi attivati da record hanno valori di ordine di attivazione compilati | | Piattaforma \| Flusso | ✅ I flussi che coinvolgono chiamate di sistema esterne o processi di lunga durata utilizzano percorsi asincroni | | Piattaforma \| Flusso | ✅ Sequenze complesse di operazioni sui dati correlate vengono create con Orchestrator (invece di invocare più sottoflussi all'interno del flusso monolitico) | | Piattaforma \| Convalida | ✅ L'integrità dei dati viene applicata a livello di piattaforma utilizzando regole di convalida, regole di duplicazione e campi obbligatori | | Piattaforma \| Convalida | ✅ Le regole di convalida impediscono l'immissione di dati non validi prima del salvataggio (più efficiente della convalida dei trigger) | | Piattaforma \| Processi di approvazione | ✅ L'instradamento delle approvazioni in più fasi gestisce i percorsi di approvazione paralleli e sequenziali con i responsabili approvazioni delegati | | Piattaforma \| Processi di approvazione | ✅ L'architettura di approvazione tiene conto degli scenari di eccezione (tutti i responsabili approvazioni in vacanza, esigenze aziendali urgenti che ignorano le normali approvazioni) | **Anti-schemi** | Dove cercare | Che brutto aspetto | | --- | --- | | Piattaforma \| Flusso | ⚠️ Process Builder e regole di flusso di lavoro utilizzate per la nuova automazione (Flow Builder è la direzione strategica) | | Piattaforma \| Flusso | ⚠️ Automazione programmatica utilizzata quando gli utenti aziendali o gli amministratori devono modificare la logica senza il coinvolgimento dello sviluppatore | | Piattaforma \| Flusso | ⚠️ I flussi mancano della gestione dei guasti con conseguente scarso ripristino degli errori | | Piattaforma \| Flusso | ⚠️ Le variabili hanno valori codificati | | Piattaforma \| Flusso | ⚠️ I flussi devono essere disattivati manualmente prima del caricamento in blocco dei dati | | Piattaforma \| Flusso | ⚠️ Porzioni di un flusso vengono ripetute tra i flussi anziché utilizzare sottoflussi | | Piattaforma \| Flusso | ⚠️ I flussi attivano avvisi di "eccezione non gestita" | | Piattaforma \| Flusso | ⚠️ Anche i flussi semplici causano regolarmente errori relativi ai limiti del governor | | Piattaforma \| Flusso | ⚠️ I flussi richiedono input aggiuntivi per fornire contesto | | Piattaforma \| Flusso | ⚠️ I flussi hanno più scopi | | Piattaforma \| Flusso | ⚠️ I gruppi di fasi correlate contengono funzionalità che si sovrappongono a gruppi di fasi in altri flussi | | Piattaforma \| Flusso | ⚠️ I flussi richiedono gli input degli utenti quando è possibile utilizzare i dati memorizzati | | Piattaforma \| Flusso | ⚠️ I flussi richiedono input i cui dati non vengono utilizzati | | Piattaforma \| Flusso | ⚠️ Esecuzione di DML utilizzando la raccolta che viene generata dal componente schermata (utilizzando l'impostazione "Utilizza gli ID e tutti i valori dei campi di un record o di una raccolta di record" per creare, aggiornare o eliminare l'elemento quando la raccolta viene generata dal componente schermata) | | Piattaforma \| Flusso | ⚠️ I flussi attivati da record non utilizzano affatto gli attributi dell'ordine di attivazione o non utilizzano i valori dell'ordine di attivazione in modo coerente | | Piattaforma \| Flusso | ⚠️ Percorsi asincroni non utilizzati in modo coerente o per nulla | | Piattaforma \| Flusso | ⚠️ Grandi flussi monolitici tentano di coordinare sequenze complesse di operazioni correlate sui dati (con o senza sottoflussi) | | Piattaforma \| Processi di approvazione | ⚠️ L'architettura di approvazione non tiene conto degli scenari di eccezione (tutti i responsabili approvazioni in vacanza, esigenze aziendali urgenti) | | Piattaforma \| Convalida | ⚠️ Integrità dei dati applicata solo nei trigger anziché nelle regole di convalida (validazione dei trigger meno efficiente e più complessa) | ## Automazione programmatica **Schemi** | Dove cercare | Che bell'aspetto | | --- | --- | | Piattaforma \| Apex | ✅ Il framework trigger handler impone il trigger singolo per oggetto, l'in blocco, la separazione delle preoccupazioni e la prevenzione dell'esecuzione ricorsiva | | Piattaforma \| Apex | ✅ Gli handler trigger delegano alle classi di servizio per la logica aziendale, mantenendo una chiara separazione delle preoccupazioni | | Piattaforma \| Apex | ✅ I trigger utilizzano la protezione ricorsione utilizzando flag statici o una classe di controllo ricorsione dedicata | | Piattaforma \| Apex | ✅ Future Apex viene utilizzato con parsimonia, per chiamate o DML oggetto di sistema | | Piattaforma \| Apex | ✅ Le chiamate Apex asincrone utilizzano Area di attesa per 'concatenare' DML complessi tra le transazioni | | Piattaforma \| Apex | ✅ Batch Apex viene utilizzato per grandi volumi di dati (elabora grandi quantità di dati con limiti governor dedicati per blocco) | | Piattaforma \| Apex | ✅ I processi batch hanno una gestione degli errori che registra i record non riusciti senza arrestare l'intera esecuzione batch | | Piattaforma \| Apex | ✅ API in blocco viene utilizzata solo quando devono essere elaborate grandi quantità di dati (API native SOAP e REST sfruttate per quantità di dati più piccole) | | Piattaforma \| Apex | ✅ Queueable Apex è utilizzato per l'orchestrazione di flussi di lavoro complessi, chiamate esterne con logica di nuovo tentativo e l'elaborazione che beneficia dei limiti asincroni | | Piattaforma \| Apex | ✅ Pianificato Apex esegue l'elaborazione su pianificazioni fisse per la manutenzione notturna, la generazione di rapporti giornalieri, la sincronizzazione periodica dell'integrazione e le regole aziendali basate sul tempo | | Piattaforma \| Standard di progettazione | ✅ I casi d'uso per le operazioni sincrone e asincrone all'interno delle automazioni sono delineati chiaramente come parte degli standard di progettazione | | Piattaforma \| Documentazione | ✅ I percorsi di esecuzione pianificati e potenziali per le automazioni sono delineati chiaramente | **Anti-schemi** | Dove cercare | Che brutto aspetto | | --- | --- | | Piattaforma \| Apex | ⚠️ Più trigger su un unico oggetto con ordine di esecuzione imprevedibile e logica sovrapposta | | Piattaforma \| Apex | ⚠️ Logica aziendale incorporata direttamente nei file trigger che rende difficile il test | | Piattaforma \| Apex | ⚠️ Nessun framework di handler trigger o schemi di trigger incoerenti tra gli oggetti | | Piattaforma \| Apex | ⚠️ I processi batch Apex hanno dimensioni dell'ambito molto piccole (ad esempio, dimensioni dell'ambito = 1) | | Piattaforma \| Apex | ⚠️ Batch Apex utilizzato per le chiamate esterne (grandi volumi di dati Salesforce inviati al sistema esterno utilizzando Batch Apex) | | Piattaforma \| Apex | ⚠️ Funzioni Apex asincrone utilizzate in modo arbitrario (Metodi futuri e Apex inseribile in coda utilizzati in modo incoerente o intercambiabile) | | Piattaforma \| Apex | ⚠️ Apex asincrono usato raramente | | Piattaforma \| Apex | ⚠️ Le operazioni del database non hanno una logica chiara e coerente per passare l'esecuzione ad Apex batch quando necessario | | Piattaforma \| Standard di progettazione | ⚠️ I casi d'uso per le operazioni sincrone e asincrone non sono affrontati | | Piattaforma \| Documentazione | ⚠️ L'invocazione dell'automazione non è documentata | ## Eventi piattaforma **Schemi** | Dove cercare | Che bell'aspetto | | --- | --- | | Piattaforma \| Eventi piattaforma | ✅ Gli eventi piattaforma vengono utilizzati per l'automazione basata sugli eventi che separa i publisher dagli abbonati | | Piattaforma \| Eventi piattaforma | ✅ Gli editori non sono a conoscenza degli abbonati e pubblicano fire-and-forget | | Piattaforma \| Eventi piattaforma | ✅ Più abbonati reagiscono in modo indipendente agli eventi tramite flussi attivati da eventi piattaforma, trigger Apex o integrazioni esterne | | Piattaforma \| Eventi piattaforma | ✅ I replay ID vengono utilizzati per riprodurre gli eventi mancati da qualsiasi punto della finestra di conservazione di 72 ore | | Piattaforma \| Eventi piattaforma | ✅ Gli eventi piattaforma consentono la comunicazione tra organizzazioni, la notifica del sistema esterno e l'orchestrazione del flusso di lavoro interno | **Anti-schemi** | Dove cercare | Che brutto aspetto | | --- | --- | | Piattaforma \| Eventi piattaforma | ⚠️ Accoppiamento diretto tra publisher e abbonati che impedisce l'automazione componibile | | Piattaforma \| Eventi piattaforma | ⚠️ L'aggiornamento del livello account chiama direttamente l'aggiornamento opportunità, la notifica del team account e la sincronizzazione del data warehouse in un'unica transazione (l'accoppiamento stretto richiede modifiche alla logica dell'account ogni volta che è necessaria una nuova elaborazione a valle) | | Piattaforma \| Apex | ⚠️ Pubblica immediatamente Eventi piattaforma utilizzati adhoc (eventi in tempo reale utilizzati al posto di Pubblica dopo l'impegno indipendentemente dai requisiti degli ordini di pubblicazione o dai rischi di blocco dei record) | ## Standard di sviluppo Apex **Schemi** | Dove cercare | Che bell'aspetto | | --- | --- | | Piattaforma \| Apex | ✅ Le istruzioni SOQL utilizzano operatori di confronto di logica positiva (`INCLUDES`, `IN`) come logica principale o unica | | Piattaforma \| Apex | ✅ SOQL evita `= NULL`, `!= NULL` o li utilizza con parsimonia dopo operatori di confronto positivi | | Piattaforma \| Apex | ✅ SOQL non utilizza istruzioni `LIMIT 1` | | Piattaforma \| Apex | ✅ SOQL non utilizza la parola chiave `ALL ROWS` | | Piattaforma \| Apex | ✅ SOQL non viene visualizzato all'interno dei loop | | Piattaforma \| Apex | ✅ I criteri dei caratteri jolly vengono visualizzati in SOSL (non SOQL) | | Piattaforma \| Apex | ✅ le istruzioni SOQL evitano confronti di `LIKE` o confronti di testo parziali | | Piattaforma \| Apex | ✅ SOQL è racchiuso in blocchi di `try-catch` | | Piattaforma \| Apex | ✅ Le variabili non fanno riferimento a valori codificati (per tipi di record, utenti, ecc.) | | Piattaforma \| Apex | ✅ Ogni classe serve un unico scopo specifico | | Piattaforma \| Apex | ✅ Ogni metodo esegue un'operazione specifica e granulare | | Piattaforma \| Apex | ✅ Tutte le variabili di input hanno uno scopo chiaro all'interno della classe | | Piattaforma \| Apex | ✅ L'esecuzione di codice richiede un numero minimo di risorse | **Anti-schemi** | Dove cercare | Che brutto aspetto | | --- | --- | | Piattaforma \| Apex | ⚠️ Le istruzioni SOQL utilizzano `NOT`, criteri di `NOT IN` come operatore principale o solo di confronto (non selettivo) | | Piattaforma \| Apex | ⚠️ Le istruzioni SOQL utilizzano la parola chiave `ALL ROWS` (non selettiva) | | Piattaforma \| Apex | ⚠️ Le istruzioni SOQL utilizzano `= NULL`, criteri di `!= NULL` come operatore principale o solo di confronto (non selettivo) | | Piattaforma \| Apex | ⚠️ Le variabili hanno valori codificati | | Piattaforma \| Apex | ⚠️ SOQL viene visualizzato all'interno dei loop | | Piattaforma \| Apex | ⚠️ Le istruzioni SOQL utilizzano frequentemente criteri di filtro per `LIKE` e caratteri jolly (non selettivi) | | Piattaforma \| Apex | ⚠️ SOQL non racchiuso in blocchi di `try-catch` | | Piattaforma \| Apex | ⚠️ Le istruzioni SOQL utilizzano `LIMIT 1` (non selettivo) | | Piattaforma \| Apex | ⚠️ SOSL utilizzato raramente o in modo non coerente per i criteri di selezione dei caratteri jolly | | Piattaforma \| Apex | ⚠️ Le classi hanno più scopi | | Piattaforma \| Apex | ⚠️ I metodi eseguono più operazioni o i metodi eseguono operazioni che non sono in linea con lo scopo dichiarato della classe di cui fanno parte | | Piattaforma \| Apex | ⚠️ Le variabili di input non vengono effettivamente utilizzate nei metodi | | Piattaforma \| Apex | ⚠️ I metodi recuperano inutilmente i dati dal database o da sistemi esterni | ## Gestione degli errori **Schemi** | Dove cercare | Che bell'aspetto | | --- | --- | | Piattaforma \| Apex | ✅ Le eccezioni personalizzate vengono utilizzate per creare messaggi di errore avanzati e logica | | Piattaforma \| Apex | ✅ Il codice racchiude tutte le chiamate DML, SOQL e altre fasi critiche del processo in blocchi di `try-catch` | | Piattaforma \| Apex | ✅ I metodi delle classi di database possono essere utilizzati esclusivamente per tutte le operazioni sui dati (anziché DML) | | Piattaforma \| Apex | ✅ In contesti asincroni e in blocco, vengono utilizzati metodi di classe Database anziché DML | | Piattaforma \| Aura | ✅ JavaScript racchiude tutte le operazioni sui dati e le fasi critiche del processo in blocchi di `try-catch` | | Piattaforma \| Aura | ✅ All'interno dei blocchi di `try-catch`, `Error` JavaScript nativo viene utilizzato nelle istruzioni throw (nessun utilizzo di `$A.error()`) | | Piattaforma \| Aura | ✅ Tutta la logica di errore recuperabile viene visualizzata all'interno degli estratti `catch` e fornisce messaggi utente chiari | | Piattaforma \| Flusso | ✅ I flussi con operazioni sui dati, chiamate e altre logiche di elaborazione critiche hanno percorsi di errore per tutte le azioni chiave | | Piattaforma \| Flusso | ✅ I flussi schermata utilizzano costantemente connettori di errore per mostrare gli errori agli utenti | | Piattaforma \| Flusso | ✅ I messaggi di errore personalizzati sono configurati per gli errori che verranno visualizzati sullo schermo | | Piattaforma \| Componenti Web Lightning (LWC) | ✅ JavaScript racchiude tutte le operazioni sui dati e le fasi critiche del processo in `if ()` /`else if ()` blocchi | | Piattaforma \| Componenti Web Lightning (LWC) | ✅ Tutte le funzioni di `@wire` utilizzano le proprietà `data` e `error` fornite dall'API | | Piattaforma \| Componenti Web Lightning (LWC) | ✅ Tutte le `if (error)`/`else if (error)` istruzioni contengono logica per elaborare gli errori e fornire messaggi informativi | **Anti-schemi** | Dove cercare | Che brutto aspetto | | --- | --- | | Piattaforma \| Apex | ⚠️ DML, SOQL, callout o altre fasi critiche del processo non racchiuse in blocchi try-catch | | Piattaforma \| Apex | ⚠️ Non vengono utilizzati metodi di classe Database | | Piattaforma \| Apex | ⚠️ Operazioni sui dati eseguite esclusivamente con DML | | Piattaforma \| Apex | ⚠️ Le istruzioni di `System.debug` vengono visualizzate nel codice di produzione (e non vengono commentate) | | Piattaforma \| Aura | ⚠️ JavaScript non racchiude in modo coerente le operazioni sui dati e le fasi critiche del processo nei blocchi di `try-catch` | | Piattaforma \| Aura | ⚠️ I componenti utilizzano `$A.error()` | | Piattaforma \| Aura | ⚠️ La logica degli errori recuperabili non viene visualizzata in modo coerente nelle istruzioni di `catch` e i messaggi di errore agli utenti non sono chiari | | Piattaforma \| Flusso | ⚠️ I flussi non utilizzano i percorsi di errore in modo coerente o del tutto | | Piattaforma \| Flusso | ⚠️ Messaggi di errore personalizzati non utilizzati, in modo che gli utenti visualizzino il messaggio predefinito "Si è verificato un errore non gestito in questo flusso" | | Piattaforma \| Componenti Web Lightning (LWC) | ⚠️ Le funzioni di `@wire` non utilizzano le proprietà `data` e `error` fornite dall'API (o non le utilizzano in modo coerente) | | Piattaforma \| Componenti Web Lightning (LWC) | ⚠️ Se utilizzate, le istruzioni `if (error)`/`else if (error)` non contengono in realtà logica per elaborare gli errori e fornire messaggi di errore utili | | Piattaforma \| Componenti Web Lightning (LWC) | ⚠️ JavaScript non utilizza in modo coerente `if ()` /`else if ()` blocchi con operazioni sui dati o fasi del processo critiche |