Storage e ottimizzazione dei costi API - Schemi
Ulteriori informazioni su Ottimizzazione delle risorse → Ottimizzazione dei dati
Schemi
| Dove cercare | Che bell’aspetto |
|---|---|
| Dati attivi del modello di dati | ✅ I dati attivi ricevono un trattamento di archiviazione premium: i dati a cui si accede regolarmente per le operazioni aziendali rimangono negli oggetti Salesforce standard con funzionalità di query complete, automazione del flusso di lavoro e accesso degli utenti. I dati attivi giustificano l’investimento nello storage perché l’accesso frequente richiede una disponibilità immediata ✅ Esempio: Le opportunità dell’anno corrente e i casi attivi rimangono negli oggetti standard con funzionalità complete |
| Dati caldi del modello di dati | ✅ I dati caldi utilizzano una strategia di archiviazione intermedia: i dati a cui si accede occasionalmente per generare rapporti o fare riferimento possono rimanere in Salesforce con flag di archiviazione che abilitano le visualizzazioni filtrate o migrare a Big Object che supportano il recupero basato su indice senza funzionalità di flusso di lavoro ✅ Esempio: Opportunità dell’anno precedente contrassegnate come archiviate ma che rimangono interrogabili per l’analisi storica |
| Cold Data del modello di dati | ✅ Dati freddi archiviati in Big Object o sistemi esterni: i dati conservati per conformità ma raramente accessibili vengono spostati in Big Object (non vengono conteggiati nei limiti di memoria dati standard) o sistemi di archiviazione esterni. Big Object appropriati per archivi a volume elevato con schemi di accesso prevedibili. L’archiviazione esterna nei data warehouse o nell’archiviazione di oggetti offre la conservazione dei dati di conformità a costi più bassi ✅ Esempio: Casi più vecchi di 36 mesi archiviati in Big Object con recupero basato su indice per l’accesso alla conformità |
| Dati scaduti del modello di dati | ✅ Dati scaduti eliminati tramite processi automatizzati - I requisiti di conservazione dei dati precedenti senza valore aziendale devono essere eliminati tramite processi automatici anziché accumularsi all’infinito. Molte organizzazioni non eliminano mai i dati a causa di problemi di “cosa succederebbe se un giorno ne avessimo bisogno”, con conseguente aumento dello spazio di archiviazione che consuma budget senza giustificazione aziendale ✅ Esempio: Il criterio di conservazione dei dati elimina automaticamente i record dopo 7 anni in base ai requisiti di conservazione previsti dalla normativa |
| Imposta → Panoramica del sistema → Archiviazione dati Imposta → Utilizzo memoria | ✅ Schema: I cruscotti digitali della capacità mostrano il consumo di memoria per oggetto con trend di crescita, l’utilizzo dell’API per integrazione con schemi di picco e l’utilizzo della capacità di elaborazione con proiezioni ✅ Abilitare l’ottimizzazione proattiva prima che i limiti creino interruzioni o addebiti in eccesso imprevisti |
| Nessun tracciamento → Sorprese annuali | ⚠️ Anti-pattern: Sovraccarico di memoria rilevato durante la trattativa di rinnovo che richiede l’acquisto immediato a prezzi premium senza tempo per valutare le strategie di archiviazione ⚠️ L’organizzazione acquista memoria aggiuntiva ogni anno senza analizzare quali dati consumano capacità o se l’archiviazione ridurrebbe la crescita |
Schemi
| Dove cercare | Che bell’aspetto |
|---|---|
| Salesforce Files File di grandi dimensioni | ✅ Integrazione archiviazione file esterna per un risparmio sui costi su larga scala: archiviare i file in servizi come Amazon S3 o Archiviazione BLOB di Azure con Salesforce che mantiene i record di riferimento che si collegano a contenuti esterni. La memoria esterna costa 0,02-0,05 $ per GB al mese rispetto alla memoria file Salesforce a 1-3 $ per GB al mese, a seconda della versione, creando un risparmio di 10-20 volte sui costi su larga scala ✅ Esempio: La soluzione di gestione dei contratti memorizza i contratti attivi (ultimi 24 mesi) in Salesforce Files per l’anteprima e la collaborazione native, esegue automaticamente la migrazione dei contratti più vecchi a S3 con i link Salesforce, riducendo la memoria file del 70% pur mantenendo l’accesso ✅ Trade-off: L’integrazione della memoria esterna richiede uno sforzo di sviluppo e introduce la dipendenza dal servizio esterno, ma offre un risparmio di 10-20 volte sui costi per i casi d’uso più complessi, riducendo il numero di casi in pochi mesi |
| Ciclo di vita dei file di Gestione dei contenuti | ✅ Gestione del ciclo di vita dei file archivia o elimina file vecchi - Implementa l’archiviazione automatica spostando i file oltre le soglie di conservazione nella memoria esterna o nell’eliminazione. I file a cui si accede raramente dopo la creazione iniziale, inclusi gli allegati dei casi per i casi chiusi e le versioni dei documenti sostituite, sono candidati all’archiviazione principale ✅ Nota: La memoria file include Salesforce Files, allegati, documenti e contenuti. Le organizzazioni con casi d’uso intensivi di documenti, tra cui la gestione dei contratti, le librerie di asset e gli allegati di casi, spesso si avvicinano ai limiti di memoria dei file più velocemente di quanto facciano i dati. |
Schemi
| Dove cercare | Che bell’aspetto |
|---|---|
| Modelli di copia parziale gestione Sandbox | ✅ I modelli di dati selettivi ottimizzano la capacità di archiviazione dei Sandbox: escludere gli oggetti di grandi volumi dai modelli Copia parziale quando il volume di dati completo non è necessario per testare gli scenari. Implementare la conservazione dei dati specifica del Sandbox rimuovendo i record più vecchi di quelli richiesti dai test, liberando capacità per dati di test aggiuntivi ✅ Esempio: Il modello Sandbox Copia parziale include gli ultimi 12 mesi di opportunità e casi ma esclude i dati archiviati, fornendo dati di test rappresentativi entro 5 GB di capacità anziché richiedere Copia completa ✅ Trade-off: La definizione di modelli di dati selettivi richiede un lavoro di analisi ma consente di utilizzare tipi Sandbox a basso costo eliminando i dati non necessari per testare gli scenari |
| Cadenza di aggiornamento gestione Sandbox | ✅ Cadenza di aggiornamento allineata ai requisiti di aggiornamento dati effettivi - Allinea l’aggiornamento Sandbox ai requisiti di aggiornamento dati effettivi anziché alle pianificazioni arbitrarie. Molte organizzazioni aggiornano mensilmente i Sandbox Copia completa quando l’aggiornamento trimestrale sarebbe sufficiente per i loro schemi di test, sprecando capacità di aggiornamento che potrebbero supportare ulteriori Sandbox ✅ Esempio: Sandbox Copia completa aggiornato trimestralmente anziché mensilmente, liberando la capacità di aggiornamento per ulteriori Sandbox Copia parziale |
| Sandbox temporanei di gestione Sandbox | ✅ Gestione Sandbox temporanea con policy di scadenza: tenere traccia degli ambienti creati per progetti specifici o test dei picchi con date di eliminazione documentate. La proliferazione temporanea dei Sandbox è una fonte comune di rifiuti poiché i Sandbox di progetto passano allo stato permanente senza giustificazione. Implementare policy di scadenza che richiedono una giustificazione del rinnovo per mantenere gli ambienti temporanei oltre l’ambito iniziale ✅ Esempio: Project Sandbox creato con scadenza di 90 giorni che richiede una giustificazione aziendale per estendersi oltre il completamento del progetto |
Schemi
| Dove cercare | Che bell’aspetto |
|---|---|
| Integration Monitoring Peak Usage Analysis (Monitoraggio dell’integrazione) | ✅ Picchi di utilizzo - Identificare gli schemi di consumo giornalieri e settimanali. Le pianificazioni integrazione concentrate durante l’orario di ufficio competono con le chiamate API avviate dall’utente. La diffusione delle integrazioni batch nelle finestre di attività ridotta ottimizza l’utilizzo della capacità senza aumentare i limiti ✅ Esempio: Integrazioni batch spostate dalle 9:00 alle 2:00, riducendo le controversie API nelle ore di punta e abilitando integrazioni aggiuntive entro la capacità esistente |
| API in blocco codice personalizzato 2.0 | ✅ API in blocco 2.0 per qualsiasi operazione che elabora centinaia di record - Utilizzare API in blocco 2.0 per qualsiasi operazione che elabora più di poche centinaia di record. L’API in blocco elabora fino a 150 milioni di record per processo consumando un numero minimo di chiamate API rispetto all’elaborazione dei record singolarmente ✅ Esempio: La sincronizzazione notturna dei dati utilizza l’API in blocco 2.0 che elabora 100.000 record con un consumo API minimo anziché singole chiamate API per record |
| Cache piattaforma codice personalizzato | ✅ Platform Cache elimina le query ripetitive per i dati di riferimento - Inserisci nella cache i dati di riferimento a cui si accede di frequente per eliminare le query ripetitive. Il caching di codici paese, cataloghi di prodotti o dati di configurazione riduce il consumo API per le integrazioni che eseguono ripetutamente query sui dati di riferimento invariati ✅ Esempio: Catalogo di prodotti memorizzato nella cache piattaforma, riducendo le chiamate API da 1.000 query giornaliere a un singolo aggiornamento della cache |
| Acquisizione dati di modifica dell’architettura di integrazione | ✅ Modifica acquisizione dati elimina schemi di polling inutili - Utilizzare Modifica acquisizione dati per la sincronizzazione dei dati anziché schemi di polling. CDC pubblica gli eventi solo quando i dati cambiano, eliminando le chiamate API sprecate che controllano le modifiche che non si sono verificate ✅ Esempio: La sincronizzazione dei dati dei clienti utilizza gli eventi di pubblicazione Acquisizione dati di modifica quando i clienti aggiornano, utilizzando le chiamate API solo per le modifiche effettive (200 al giorno) anziché analizzare ogni record cliente ogni ora (1,2 milioni di query al giorno) ✅ Trade-off: L’architettura basata sugli eventi richiede l’implementazione di Eventi piattaforma o CDC ma riduce il consumo API del 95% per gli schemi di rilevamento delle modifiche, riducendo il numero di interruzioni nel giro di poche settimane |
| Nessun monitoraggio → Reactive Discovery | ⚠️ Anti-pattern: Il consumo API monitorato solo quando si verificano eccezioni ai limiti, creando modifiche reattive dell’architettura antincendio e di emergenza sotto pressione ⚠️ Manca l’analisi del trend proattiva che consente l’ottimizzazione prima che i limiti vincolino le operazioni aziendali |
Schemi
| Dove cercare | Che bell’aspetto |
|---|---|
| Sincrona in tempo reale dello schema di integrazione | ✅ Le integrazioni sincrone consumano capacità API massima: le integrazioni in tempo reale consumano una o più chiamate API per transazione. I flussi di transazioni a volume elevato possono consumare una notevole capacità API. Schemi sincroni appropriati quando la coerenza immediata dei dati è un requisito aziendale obbligatorio ma comporta il costo di consumo API più elevato ✅ Esempio: L’invio dell’ordine richiede un controllo inventario immediato e la prenotazione nel sistema ERP per giustificare lo schema sincrono nonostante il costo API più elevato |
| Elaborazione batch schema di integrazione | ✅ Le integrazioni batch riducono il consumo API del 90%+ rispetto al consumo sincrono - Elaborano i record in blocco, riducendo drasticamente le chiamate API per record. L’API in blocco 2.0 elabora milioni di record con un consumo API minimo. Opportuno quando la sincronizzazione quasi in tempo reale soddisfa le esigenze aziendali ed elimina il 90% del consumo API rispetto agli schemi sincroni ✅ Esempio: La sincronizzazione dei dati dei clienti esegue batch orari anziché aggiornamenti in tempo reale, riducendo il consumo dell’API del 95% con latenza dei dati accettabile di 1 ora |
| Schema di integrazione basato sugli eventi | ✅ Gli schemi basati sugli eventi scalano in modo efficiente le risorse consumando solo le modifiche effettive - Utilizzare Eventi piattaforma o Acquisizione dati di modifica per una distribuzione efficiente degli eventi senza sovraccarico di polling. Gli schemi basati sugli eventi scalano in modo efficiente perché consumano risorse solo quando si verificano modifiche effettive anziché controllare ripetutamente le modifiche che non si sono verificate ✅ Esempio: Le modifiche delle fasi delle opportunità pubblicano gli eventi piattaforma consumati dai sistemi a valle, eliminando il polling e riducendo il consumo API del 98% |
| Integration Platform MuleSoft TCO (TCO piattaforma di integrazione) | ✅ MuleSoft aggiunge il costo della piattaforma ma può ridurre il TCO totale dell’integrazione attraverso il caching intelligente, il pooling delle connessioni, l’ottimizzazione batch e la governance unificata in tutti gli schemi di integrazione ✅ Trade-off: Il middleware giustifica l’investimento quando il numero di integrazioni supera le 5-7 connessioni, offrendo riutilizzabilità e governance che riducono i costi di manutenzione a lungo termine |
| Prezzi API di integrazione di terze parti | ✅ Costi API di terze parti basati sui volumi di transazione previsti - Modellare i costi di terze parti basati sui volumi di transazione previsti che riflettono l’utilizzo effettivo anziché i livelli minimi che presumono volumi bassi. I prezzi API di terze parti variano dai livelli gratuiti alla fatturazione per chiamata misurata alle licenze aziendali a tariffa unica ✅ Esempio: Il modello TCO di integrazione per il gateway di pagamento include 15.000 € di commissione annuale per la piattaforma + 0,10 € per transazione stimata in 50.000 transazioni annuali (50.000 €) + 25.000 € di sviluppo integrazione + 5.000 € di manutenzione annuale per 50.000 € totali il primo anno, 10.000 € in corso |
| Manutenzione dell’integrazione da punto a punto rispetto all’hub | ✅ Le integrazioni da punto a punto moltiplicano esponenzialmente le attività di manutenzione: ogni punto di integrazione include la creazione iniziale, la manutenzione in corso, l’evoluzione della gestione degli errori e l’adattamento quando uno dei due endpoint cambia. Le integrazioni da punto a punto moltiplicano esponenzialmente l’impegno di manutenzione man mano che il conteggio dei sistemi cresce. Cinque sistemi con connessioni da punto a punto richiedono 10 stream di manutenzione integrazione. Dieci sistemi richiedono 45 stream. Gli schemi hub-and-spoke tramite piattaforme di integrazione riducono la crescita esponenziale a scalabilità lineare ✅ Esempio: L’organizzazione con 8 sistemi connessi passa da 28 integrazioni da punto a punto a 8 connessioni hub-and-spoke, riducendo gli stream di manutenzione del 71% |
| Costi di assistenza per le operazioni di integrazione | ✅ I costi di assistenza e risoluzione dei problemi aumentano con il conteggio delle integrazioni: ogni integrazione crea potenziali punti di errore che richiedono l’infrastruttura di monitoraggio, la configurazione di avviso, la documentazione del runbook e la capacità di risposta agli incidenti. Includere i costi di assistenza continuativi nel TCO integrazione oltre lo sviluppo iniziale ✅ Esempio: Costi di assistenza per l’integrazione calcolati sul 15-20% del costo di sviluppo iniziale annuale per il monitoraggio continuo, la risoluzione dei problemi e la risposta agli incidenti |
Anti-schemi
| Dove cercare | Che brutto aspetto |
|---|---|
| Tutti i dati storici rimangono in memoria attiva per un tempo indefinito | ⚠️ crescita dello stoccaggio che consuma budget senza giustificazione aziendale. Le organizzazioni acquistano memoria aggiuntiva ogni anno senza analizzare quali dati consumano capacità o se le strategie di archiviazione potrebbero ridurre il tasso di crescita ⚠️ Bonifica: Definire la policy di conservazione dei dati con fasi del ciclo di vita: attiva (0-12 mesi), calda (12-36 mesi), fredda (36+ mesi archiviati) e scaduta (eliminata dopo la conservazione normativa). Implementare l’archiviazione automatica in Big Object o memoria esterna |
| Il modello Copia parziale include tutti gli oggetti senza filtri | ⚠️ Consuma 5 GB di capacità con dati storici irrilevanti per i test, costringendo l’acquisto di Copia completa quando la selezione strategica dei dati consentirebbe l’utilizzo di Copia parziale a costi significativamente inferiori ⚠️ Bonifica: Analizzare i requisiti di test e creare modelli Copia parziale selettivi che includano solo gli ultimi 12-18 mesi di dati ed escludano gli oggetti a volume elevato non necessari per gli scenari di test |
| L’integrazione esegue il polling di tutti i record ogni 15 minuti per verificare la presenza di modifiche | ⚠️ Consuma chiamate API 5M ogni giorno quando il 95% dei sondaggi non rileva modifiche, sprecando la capacità API in query inutili. Crea il rischio di superare i limiti API e impedire il completamento delle integrazioni legittime ⚠️ Bonifica: Sostituire lo schema di polling con Acquisizione dati di modifica o Eventi piattaforma che utilizzano chiamate API solo quando si verificano modifiche effettive, riducendo il consumo API del 95%+ |
| L’integrazione effettua chiamate API separate per ogni tipo di record in sequenza | ⚠️ Moltiplica il consumo API 5-10 volte rispetto agli approcci batch. Elaborazione degli ordini che consuma 8 chiamate API per ordine quando sarebbe sufficiente una singola chiamata composta ⚠️ Bonifica: Implementare le operazioni correlate al batching API composito in una singola chiamata API, riducendo il consumo da 8 chiamate per transazione a 1 chiamata per transazione (riduzione dell’87%) |
| Sandbox Copia completa acquistati per ogni team di sviluppo | ⚠️ Le moltiplicazioni costano 5 volte quando Copia parziale soddisfa la maggior parte dei requisiti di test. Copia completa costa 5-10 volte di più rispetto a Copia parziale e si aggiorna solo ogni mese rispetto a ogni 5 giorni ⚠️ Bonifica: Prenotare Copia completa esclusivamente per UAT di pre-produzione e convalida delle prestazioni. Utilizzare Developer Pro per lo sviluppo e Copia parziale con modelli di dati mirati per il test di integrazione |
| Integrazione approvata in base al “livello API gratuito” senza modellazione del volume | ⚠️ I volumi delle transazioni previsti superano il livello gratuito nel mese 2, causando costi annuali sorprendenti di 15.000 dollari non inclusi nell’analisi del budget o del TCO ⚠️ Bonifica: Modellare i costi API di terze parti in base ai volumi di transazione previsti, incluse le proiezioni di scala. Includere le tariffe della piattaforma, i costi per transazione e gli addebiti per eccedenza nel TCO integrazione prima dell’approvazione |
| Consumo API monitorato solo quando si verificano eccezioni limite | ⚠️ Crea modifiche reattive dell’architettura antincendio e di emergenza sotto pressione. I limiti creano interruzioni prima che vengano identificate le opportunità di ottimizzazione ⚠️ Bonifica: Implementare un cruscotto digitale di monitoraggio API proattivo con attribuzione a livello di integrazione, analisi dei picchi di utilizzo e proiezione della crescita. Impostare avvisi in corrispondenza di soglie di utilizzo di esempio come 70% e 85%, fornendo lead time per l’ottimizzazione |
| Generazione di documenti personalizzati perché “abbiamo sviluppatori disponibili” | ⚠️ Sviluppo personalizzato a 80.000 € di build iniziale + 15.000 € di manutenzione annuale quando l’opzione AppExchange a 15.000 € al mese per utente (180.000 € all’anno per 100 utenti) offre una distribuzione più rapida, manutenzione del fornitore e un TCO di 5 anni inferiore ⚠️ Bonifica: Valutare le soluzioni AppExchange prima dello sviluppo personalizzato per le funzionalità delle materie prime. TCO del modello da 3 a 5 anni che confronta build e buy con manutenzione, compatibilità della piattaforma e costi di assistenza |
| I Sandbox di progetto temporanei passano allo stato permanente senza giustificazione | ⚠️ Proliferazione Sandbox che consuma budget senza valore aziendale. Le organizzazioni accumulano oltre 20 Sandbox quando 10 soddisfano le esigenze di sviluppo effettive con una gestione del ciclo di vita corretta ⚠️ Bonifica: Implementare policy di scadenza Sandbox che richiedono una giustificazione del rinnovo. Monitoraggio dei Sandbox con date di eliminazione documentate e avvisi automatici per la revisione della scadenza |
- Pilastro di ottimizzazione delle risorse e dei costi
- Ottimizzazione delle risorse e dei costi - Schemi di licenza
- Pilastro Eccellenza operativa
Ultimo aggiornamento: 2026-06-08