Report avanzati, dashboard dinamiche e dati esterni

Le domande piu insidiose di Data and Analytics Management non chiedono come si costruisce un report: chiedono dove deve vivere un dato e come ci arriva. Sono scenari lunghi, e la risposta dipende quasi sempre da tre espressioni nascoste nel testo: «sempre aggiornato», «dentro Salesforce», «ogni notte».

Quattro modi di trattare un dato che non sta nel database principale

Le prime due righe si assomigliano solo in superficie. L’external object non copia nulla: se il sistema remoto e spento, l’utente non vede i dati. Il big object e l’opposto: i dati sono in piattaforma, con un modello di accesso spartano.

Salesforce Connect e gli external object

Il percorso in Setup e sempre questo:

1. External Data Sources, New External Data Source.
2. Si sceglie il tipo: per un endpoint OData 2.0 il valore e Salesforce Connect: OData 2.0. Gli adapter comprendono OData 2.0, OData 4.0, Cross-Org (un’altra org Salesforce) e Apex Custom (una fonte che non parla OData).
3. Si inserisce la URL del servizio, si impostano autenticazione e identita; Writable External Objects decide se si potra anche scrivere verso il sistema remoto.
4. Si salva e si lancia Validate and Sync: Salesforce legge lo schema remoto e permette di scegliere quali tabelle diventano external object. Gli oggetti generati portano il suffisso __x.

Da li in poi gli external object hanno tab, list view, ricerca, pagine di dettaglio e related list, ma ogni apertura di pagina e una chiamata al sistema remoto: disponibilita e latenza di quel sistema diventano parte dell’esperienza utente. Nello scenario classico — storico ordini in un ERP che espone OData, agenti che lo consultano e lo cercano da dentro Salesforce vedendo sempre lo stato corrente, senza duplicare nulla — la risposta e external data source + Validate and Sync, non un’integrazione che copia i record ogni notte.

Big object: tanto spazio, poche comodita

Un big object regge volumi che gli oggetti custom non reggono (transazioni, audit, archivi di lungo periodo). Ci sono standard big object definiti da Salesforce e custom big object definiti dall’admin. Il prezzo di quella scala e quello che l’esame verifica:

• si definiscono in Setup (o via Metadata API) con un insieme ristretto di tipi di campo: Text, Text Area (Long), Number, Date/Time, Email, Phone, URL, Lookup Relationship;
• richiedono un indice composito che fa da chiave primaria: i campi indicizzati devono essere obbligatori e l’ordine conta. Creato l’indice, non si modifica ne si cancella: per cambiarlo si crea un altro big object;
• niente trigger, flow, process e UI standard: nessuna pagina di dettaglio, nessuna list view;
• si popolano da CSV con Data Loader, via Bulk API o SOAP API, o in Apex con insertImmediate; si interrogano con SOQL tramite Bulk API o batch Apex.

Un dettaglio che vale una domanda intera: l’inserimento e idempotente. Reinserire un record con lo stesso indice non crea un duplicato, si comporta come un upsert e aggiorna i campi non indicizzati.

Perdita di dati contro corruzione di dati

Il modello e a responsabilita condivisa: Salesforce risponde di sicurezza e disponibilita della piattaforma, il cliente dei propri dati, metadati e personalizzazioni. Da qui la distinzione che separa due rimedi diversi.

Quando il danno e circoscritto lo strumento e il Precision Repair: si sceglie una data precedente al danno, si restringono oggetto e campi con dei filtri, e si esamina l’anteprima del restore (record coinvolti, campi modificati, nuovi valori, conflitti) prima di applicare. Il full org restore riporta indietro l’intera org ed e l’ultima risorsa: travolge anche le modifiche legittime del frattempo e richiede downtime. Nello scenario dell’integrazione notturna che ha sovrascritto il Billing Address di decine di migliaia di account senza cancellare nulla, la parola chiave e proprio quella: e corruzione, si ripara quel campo, non si ripristina l’org.

Importare: Wizard, Data Loader, external ID

La scelta e meccanica: se i record sono pochi, l’oggetto e coperto e nessuno chiede automazione, e il Wizard; se cade anche uno solo di questi tre requisiti, e Data Loader.

Il pezzo che tiene insieme i caricamenti ricorrenti e l’external ID: un campo custom marcato External ID che conserva la chiave del sistema di origine. Serve a due cose:

• upsert: il caricamento usa l’external ID come chiave di corrispondenza e decide da solo se aggiornare un record esistente o inserirne uno nuovo, senza che il file contenga gli Id di Salesforce; ripetere lo stesso file non crea doppioni;
• risolvere le relazioni: nel file si indica il padre tramite l’external ID del padre, cosi il sistema esterno non deve conoscere gli identificativi interni di Salesforce.

Percio il file notturno con la chiave del contatto e la chiave dell’azienda prodotte dal sistema di fatturazione si carica con Data Loader in upsert su external ID, usando l’external ID dell’account per agganciare il contatto al padre: nessun match sul nome, nessun intervento manuale.

Un’avvertenza sui nomi: dataloader.io (il tool web che compare in alcuni progetti Trailhead, con insert, update, upsert, delete ed export) non e il Data Loader client scaricabile da Setup. Due prodotti diversi, nomi quasi identici.

Trappole tipiche d’esame

• «Sempre aggiornato» non significa «sincronizzato ogni notte». Se gli utenti devono vedere cio che il sistema esterno contiene adesso, la risposta e Salesforce Connect con external object; se invece i dati devono restare disponibili anche a fonte spenta, l’external object e la risposta sbagliata.
• Big object non vuol dire «oggetto custom grande». Niente trigger, flow, process, pagine di dettaglio e list view; tipi di campo limitati; indice composito immutabile dopo il deploy. Una risposta che promette un flow su un big object, o la modifica dell’indice, e li per essere scartata.
• Sovrascritto non e cancellato. Valori sbagliati su record esistenti sono corruzione (Repair Data Corruption, Precision Repair, con anteprima); record spariti sono perdita (Restore Data Loss, che ricostruisce anche le relazioni). Il full org restore non e mai la prima risposta a un problema circoscritto.
• La soglia non e l’unico criterio fra Wizard e Data Loader. Anche con pochi record, un oggetto non supportato o un caricamento ricorrente e non presidiato spostano la scelta su Data Loader.
• L’external ID non e l’Id di Salesforce e non e la chiave primaria. E il campo di corrispondenza dell’upsert e il modo per agganciare i record correlati tramite la chiave del padre; puo essere anche Unique, ma sono due proprieta distinte del campo.
• Diffida dei divieti che leggi nella documentazione. Alcune pagine riportano limiti che il prodotto ha superato: per esempio l’affermazione che un joined report non possa essere sorgente di un componente di dashboard non e piu vera dal Winter ’19. Un «non si puo fare» e un sospetto da verificare, non una regola.