Come costruire l'output di report Excel - COM / Open XML / Template

Nelle consulenze sull’output di report Excel, la frase “vogliamo uscire su Excel” spesso contiene diversi requisiti distinti mescolati insieme.

• Gli utenti vogliono modificare l’output a mano in seguito
• Un .xlsm esistente deve essere mantenuto
• Tabelle pivot, grafici e impostazioni di stampa devono rimanere così come sono
• Grandi volumi devono essere prodotti da un batch notturno
• Deve girare non presidiato su un server
• Serve anche un PDF

Nessun approccio risolve tutti questi aspetti in modo pulito. La prima cosa da guardare non è il nome della libreria ma se stai guidando l’applicazione Excel o costruendo un file Excel.

Se sbagli qui, all’inizio può funzionare, ma la manutenzione diventa dolorosa in seguito. In questo articolo, ipotizzando l’output di report Excel in applicazioni Windows e sistemi aziendali, organizziamo come scegliere tra automazione COM / Open XML / iniezione dati basata su template / coesistenza con VBA esistente.

1. Conclusioni prima di tutto

Mettiamo le conclusioni in evidenza.

• Se il report è qualcosa che gli utenti apriranno e modificheranno in Excel in seguito, il primo candidato è template più generazione diretta .xlsx / .xlsm.
• Se generi automaticamente su un server / servizio / scheduler, è più sicuro non basare la progettazione sull’automazione Office.
• Se vuoi sfruttare file .xlsm esistenti, VBA, grafici, tabelle pivot e impostazioni di stampa, la progettazione è più robusta se spingi layout e funzionalità specifiche di Excel nel template e tieni il codice focalizzato puramente sull’iniezione dati.
• Solo quando hai veramente bisogno del comportamento dell’applicazione Excel stessa è naturale usare l’automazione COM, e anche allora limitala all’esecuzione presidiata su desktop.
• Se hai solo bisogno di un elenco semplice, CSV / PDF / pagina web spesso si adattano meglio ai requisiti fin dall’inizio.

In sintesi, per molti report aziendali è più naturale “assemblare un file Excel” che “azionare Excel”.

2. Cosa decidere per prima cosa

Ecco una tabella delle cose che vuoi decidere per prime per l’output di report Excel.

3. Principali approcci di implementazione

3.1 Automazione COM di Excel

Questo approccio lancia Excel e manipola Workbook, Worksheet e Range via COM. È più facile da capire come “guidare il vero Excel”.

Il suo punto di forza è che puoi usare il comportamento specifico di Excel così com’è. Si integra bene con cartelle di lavoro esistenti, grafici, tabelle pivot, impostazioni di stampa, macro, esportazione PDF e ti permette di lavorare direttamente con “come Excel presenterà alla fine il risultato”.

Le sue debolezze, però, sono altrettanto chiare.

• Excel deve essere installato
• Ti prendi responsabilità di durata del processo, lock dei file, dialoghi, bitness, dipendenze dal profilo utente
• Office Automation da un server o servizio non presidiato è qualcosa che Microsoft stessa non raccomanda o supporta

3.2 Generazione diretta di .xlsx

Poiché .xlsx è il formato Open XML, puoi assemblare file direttamente senza lanciare Excel. Con strumenti come Open XML SDK, il tuo programma può manipolare cartelle di lavoro, fogli, celle, stili e tabelle.

Il punto di forza di questo approccio è che è facile da eseguire in ambienti senza Excel installato e si abbina bene a job batch e server.

D’altra parte, le cose si complicano quando vuoi riprodurre naturalmente il comportamento orientato all’UI che Excel stesso fornisce. L’auto-fit delle colonne, i page break, le visualizzazioni complesse e la modifica profonda di cartelle di lavoro esistenti diventano rapidamente una lotta se provi a farle tutte in codice.

3.3 Iniezione dati basata su template

L’approccio che troviamo più facile da consigliare in pratica è creare prima un template Excel e tenere il codice focalizzato puramente sull’iniezione dati.

L’aspetto del report, le formule, la formattazione condizionale, le aree di stampa, intestazioni / piè di pagina, loghi e grafici vivono nel template. Il codice copia il template e scrive dati nei punti di ingresso concordati: named range, tabelle, intervalli di celle e così via.

Farlo separa le modifiche di layout da quelle della logica di business. Contribuisce molto ad evitare l’inferno comune nei report Excel Cells[37, 9] = ....

3.4 Mantenere asset VBA esistenti

Se file .xlsm esistenti o VBA sono vivi e vegeti, spesso è più naturale non ricostruire tutto in una volta. Lasciare l’UI del report e la formattazione finale in VBA mentre si spostano calcoli pesanti, logica DB/HTTP/business sul lato C#/.NET è una divisione molto realistica.

Ciò che conta qui è non lasciare responsabilità ambigue.

• Il lato VBA possiede il comportamento all’interno della cartella di lavoro
• Il lato .NET possiede il recupero dati e l’elaborazione business
• Il confine tra loro è fissato tramite named range, tabelle, interfacce pubbliche e simili

3.5 Casi per Microsoft 365 / Graph

Se i file Excel risiedono su OneDrive / SharePoint fin dall’inizio e vuoi condividerli da app web o mobile, l’API Excel di Microsoft Graph è un’opzione.

Non è però una risposta generica per produrre massicciamente file arbitrari su un PC locale. Permessi, posizione di storage, sessioni e operazioni assumono M365 sin dall’inizio.

3.6 Serve davvero Excel?

Se il requisito è “una tabella su cui gli utenti lavoreranno in seguito”, scegliere Excel è naturale. Ma per requisiti come questi, un altro formato è spesso la scelta più semplice.

• Stampato e archiviato -> PDF
• Importato in un altro sistema -> CSV / TSV / JSON
• Deve essere visualizzabile solo in un browser -> HTML / pagina web
• L’obiettivo principale è aggregazione e visualizzazione -> BI o dashboard

4. Confronto tra approcci

Mettere le differenze fianco a fianco in una tabella dà questo.

5. Scelta per requisiti comuni

5.1 Output sul PC utente, poi modifica diretta

In questo caso, template più generazione diretta è una scelta molto forte. Gli utenti apriranno l’output in Excel in seguito, quindi la modifica finale può essere lasciata a Excel.

5.2 Generazione ad alto volume in batch notturno o servizio

Se è coinvolto un batch notturno, è più sicuro iniziare escludendo l’automazione COM. Sposta la generazione sulla creazione diretta di .xlsx e, se necessario, lascia che gli utenti aprano i file in Excel in seguito.

5.3 Sfruttare .xlsm / VBA esistenti

Se gli asset esistenti sono ancora vivi, il percorso realistico è tenere l’.xlsm come template ed eseguire solo l’iniezione dati dall’esterno.

5.4 Grandi quantità di righe di dettaglio

Il limite per un singolo foglio Excel è 1.048.576 righe per 16.384 colonne. Quando i dati di dettaglio sono grandi, decidi prima questi punti.

• Sopra quante righe si divide in più fogli?
• Sopra quanti record si divide in più file?
• CSV sarebbe la scelta più naturale fin dall’inizio?

6. Un’architettura facile da consigliare in pratica

Ciò che risulta robusto in pratica è un’architettura divisa in quattro strati.

La cosa bella di questa divisione è che il codice diventa molto meno trascinato dall’aspetto di Excel.

7. Pitfall

7.1 Non trasformare indirizzi di cella in specifiche di business

Una volta che Cells[12, 7] rappresenta una regola di business, una modifica di layout diventa una modifica di specifica. Il codice dura più a lungo quando tocca il report tramite named range e nomi di tabelle.

7.2 Non usare celle unite come punti di inserimento dati

Le celle unite sono una funzionalità di presentazione. Usarle come target di iniezione rende probabili incidenti quando si aggiungono righe o si calcolano intervalli.

7.3 Non riempire numeri e date come “stringhe preformattate”

È più naturale memorizzare valori come valori e spingere l’aspetto nelle formati di cella.

7.4 Non lasciare che le modifiche al template passino senza controllo

Un template non è codice, ma in pratica è la specifica stessa. L’approccio sicuro è trattarlo come soggetto a version control, diff review e code review.

7.5 Se usi COM, non sottovalutare bitness e gestione della durata

Con automazione COM e integrazione VBA, le differenze 32/64 bit, la pulizia del processo Excel, i lock dei file e le differenze tra ambienti utente si fanno pagare silenziosamente.

8. Riassunto

L’output di report Excel sembra un argomento di una riga — “uscire su Excel” — ma in realtà diverse decisioni devono essere prese in anticipo.

• Stai guidando l’applicazione Excel?
• Stai costruendo un file Excel?
• Girerà sul PC utente, o non presidiato?
• Verranno mantenuti VBA o file .xlsm esistenti?
• Il deliverable finale è Excel, o PDF / CSV?

Come primo candidato in pratica, template più generazione diretta è molto forte. Aggiungere il riutilizzo di VBA esistente o l’elaborazione finale di Excel sul PC utente a seconda dei casi tende a funzionare bene.

9. Riferimenti

• Considerations for server-side Automation of Office
• Considerations for unattended automation of Office in the Microsoft 365 for unattended RPA environment
• About the Open XML SDK for Office
• How to: Copy a worksheet with SAX (Simple API for XML)
• Overview of the Excel workbooks and charts API - Microsoft Graph
• Access OneDrive and SharePoint via Microsoft Graph API
• Excel specifications and limits

Articoli correlati

Articoli recenti con gli stessi tag per approfondire argomenti vicini.

Argomenti correlati

Queste pagine collocano l’argomento in un contesto più ampio di servizi e decisioni.

Servizi collegati all’argomento

L’articolo è direttamente collegato ai servizi seguenti.

Domande frequenti

Domande che ricorrono nelle consulenze sull’argomento dell’articolo.

Qual è il modo migliore per generare report Excel da un'applicazione aziendale?

Per la maggior parte dei report aziendali, il primo candidato più forte è template più generazione diretta .xlsx/.xlsm: tieni l'aspetto, formule, formattazione condizionale, aree di stampa e grafici in un template Excel, e tieni il codice focalizzato puramente sull'iniezione di dati in named range e tabelle. Questo separa le modifiche di layout da quelle della logica di business ed evita la trappola comune in cui indirizzi di cella come Cells[37, 9] diventano specifiche di business. La prima domanda chiave non è quale libreria usare, ma se stai guidando l'applicazione Excel o costruendo un file Excel.

Posso usare l'automazione COM di Excel su un server o in un job batch schedulato?

È più sicuro di no. Microsoft stessa non raccomanda o supporta Office Automation da un server o servizio non presidiato, e l'automazione COM porta anche problemi di durata del processo, lock dei file, dialoghi, bitness e dipendenze dal profilo utente, oltre al requisito che Excel sia installato. Per batch notturni e generazione server-side, la creazione diretta di .xlsx con qualcosa come Open XML SDK gira senza Excel installato e si abbina bene a output ad alto volume. Riserva l'automazione COM per l'esecuzione presidiata su desktop, quando hai veramente bisogno del comportamento di Excel stesso.

Come devo gestire file .xlsm esistenti e macro VBA quando aggiungo output di report automatizzato?

Di solito non devi ricostruire tutto in una volta. Una divisione realistica è tenere l'.xlsm come template con l'UI del report e la formattazione finale in VBA, mentre sposti calcoli pesanti, logica DB/HTTP/business sul lato C#/.NET, che esegue solo l'iniezione dati dall'esterno. La parte importante è non lasciare responsabilità ambigue: VBA possiede il comportamento all'interno della cartella di lavoro, .NET possiede il recupero dati e l'elaborazione business, e il confine è fissato tramite named range, tabelle e interfacce pubbliche.

Quali sono i pitfall comuni nel codice di generazione report Excel?

L'articolo evidenzia cinque: non trasformare indirizzi di cella in specifiche di business (usa named range e nomi di tabelle); non usare celle unite come punti di inserimento dati, perché causano incidenti quando si aggiungono righe; memorizzare numeri e date come veri valori e spingere l'aspetto nelle formati di cella piuttosto che in stringhe preformattate; trattare i template come specifiche versionate soggette a diff e code review; e se usi COM, non sottovalutare le differenze 32/64 bit, la pulizia del processo Excel e i lock dei file. Ricorda anche che un singolo foglio ha un limite di 1.048.576 righe, quindi pianificare split di fogli o file per dati di dettaglio grandi.

Profilo dell’autore

Pagina di presentazione dell’autore dell’articolo.

Go Komura

Rappresentante di KomuraSoft LLC

Specializzato nello sviluppo di software Windows, nella consulenza tecnica e nell’analisi dei malfunzionamenti, soprattutto nei progetti con sistemi esistenti e guasti difficili da riprodurre.