Considerazioni relative all'automazione sul lato server di Office

Gli sviluppatori possono sfruttare l'automazione per Microsoft Office per generare soluzioni personalizzate basate sulle caratteristiche e sulle funzionalità incorporate nel prodotto Office. Mentre è piuttosto agevole implementare tale sviluppo programmatico su un sistema client, varie complicazioni possono verificarsi quando l'automazione deve essere realizzata mediante codice sul lato server quale ASP (Active Server Pages), DCOM o un servizio di NT.

In questo articolo vengono illustrate le complicazioni che gli sviluppatori possono incontrare e vengono offerte soluzioni alternative all'automazione che possono velocizzare le prestazioni, nonché suggerite tecniche di configurazione di Office nel caso in cui l'automazione sul lato server sia assolutamente necessaria. Si noti, peraltro, che i suggerimenti che seguono sono forniti a solo scopo informativo. Microsoft sconsiglia e non supporta l'automazione sul lato server di Office.

Nota In questo contesto, il termine "lato server" si riferisce anche al codice in esecuzione su workstation basate su Microsoft Windows NT o su Microsoft Windows 2000, purché sia eseguito da una WinStation diversa dalla stazione interattiva dell'utente connesso. Ad esempio, il codice avviato dall'Utilità di pianificazione con l'account SYSTEM viene eseguito nello stesso ambiente del codice ASP o DCOM sul lato server e, pertanto, va incontro a molti degli stessi problemi. Per ulteriori informazioni sulle WinStation e su COM, vedere le sezioni "Informazioni" e "Riferimenti".

Tutte le versioni correnti di Microsoft Office sono state progettate, testate e configurate per essere eseguite come prodotti per l'utente finale su workstation client. Presumono l'esistenza di un desktop interattivo e di un profilo utente e non forniscono il livello di rientranza o di protezione necessario per soddisfare le esigenze dei componenti sul lato server progettati per l'esecuzione automatica.

Attualmente, Microsoft sconsiglia e non supporta l'automazione delle applicazioni di Microsoft Office da applicazioni o componenti client (tra cui ASP, DCOM e servizi NT) automatici e non interattivi, poiché Office potrebbe diventare instabile e/o bloccarsi se eseguito in un ambiente simile.

Se si sta creando una soluzione destinata all'esecuzione in un contesto sul lato server, utilizzare, quando possibile, componenti progettati per essere eseguiti in modo automatico in piena sicurezza oppure trovare soluzioni alternative che consentano l'esecuzione sul lato client di almeno una parte del codice. Se si sceglie di utilizzare un'applicazione di Office da una soluzione sul lato server, si riscontrerà la mancanza delle funzionalità necessarie a garantire un'esecuzione corretta e si esporrà l'intera soluzione a rischi di instabilità.

Problemi relativi all'utilizzo dell'automazione sul lato server di Office

Gli sviluppatori che tentano di utilizzare Office in una soluzione sul lato server devono essere consapevoli dei cinque elementi critici principali che possono determinare un funzionamento inatteso di Office a causa dell'ambiente di esecuzione. Per garantire la corretta esecuzione del codice, sarà necessario assumere misure appropriate nei confronti di tali elementi e ridurne gli effetti quanto più possibile. Durante la creazione dell'applicazione sarà necessario considerare attentamente questi elementi, dato che non vi sono soluzioni in grado di risolverli tutti e ogni tipo di progettazione privilegerà necessariamente gli uni a scapito degli altri.

1. Identità dell'utente: l'esecuzione delle applicazioni di Office presume l'identità di un utente, anche quando vengono avviate tramite l'automazione. Viene eseguito un tentativo di inizializzare le barre degli strumenti, i menu, le opzioni, le stampanti e alcuni componenti aggiuntivi sulla base di impostazioni specificate nell'hive del Registro di sistema dell'utente che avvia l'applicazione. Poiché molti servizi vengono eseguiti con account privi di profili utente (ad esempio l'account SYSTEM o IWAM_[nomeserver]), è possibile che Office non venga correttamente inizializzato all'avvio e che venga restituito un errore di CreateObject o CoCreateInstance. Anche qualora sia possibile avviare l'applicazione di Office, senza un profilo utente potrebbero non funzionare correttamente altre funzioni. Se si prevede di realizzare l'automazione di Office da un servizio, sarà necessario configurare il codice o Office in modo che venga eseguito con un profilo utente caricato.
2. Interattività con il desktop: l'esecuzione delle applicazioni di Office presume un desktop interattivo. Inoltre, in alcune circostanze, il corretto funzionamento di determinate funzioni di automazione potrebbe richiedere la visibilità delle applicazioni stesse. Office è progettato in modo tale che, se si verifica un errore imprevisto o se un parametro non specificato è necessario per il completamento di una funzione, venga visualizzata una finestra di dialogo modale in cui si richiede all'utente di scegliere come proseguire. Poiché in un desktop non interattivo una finestra di dialogo modale non può essere eliminata, il thread si blocca a tempo indeterminato. Alcune pratiche di scrittura del codice consentono di ridurre il rischio di tale inconveniente, ma non sono in grado di eliminarlo del tutto. Questo unico fatto rende, di per sé, rischiosa e priva di supporto l'esecuzione di applicazioni di Office da un ambiente sul lato server.
3. Rientranza e scalabilità: i componenti sul lato server devono essere componenti COM di tipo multithread altamente rientranti che garantiscano minimo sovraccarico e alta velocità di esecuzione per più client. Le applicazioni di Office hanno, in quasi tutti questi aspetti, caratteristiche esattamente opposte. Sono server di automazione non rientranti basati su STA progettati per fornire funzionalità differenti, ma con un elevato consumo di risorse, a un singolo client. Come soluzioni sul lato server offrono scalabilità ridotta e prevedono limitazioni rigide per determinati elementi, ad esempio la memoria, che non possono essere modificate a livello di configurazione. Per di più, l'utilizzo di risorse globali (ad esempio file mappati in memoria, componenti aggiuntivi o modelli globali e server di automazione condivisi) da parte di tali applicazioni può limitare il numero di istanze eseguibili simultaneamente e portare a condizioni di competizione se configurate in un ambiente con più client. È importante che gli sviluppatori che prevedono di eseguire simultaneamente più istanze di un'applicazione di Office prendano in considerazione il "pooling" o la serializzazione dell'accesso all'applicazione di Office per evitare il rischio di blocchi critici o del danneggiamento di dati.
4. Flessibilità e stabilità: la tecnologia di Microsoft Windows Installer (MSI) utilizzata in Office 2000, Office XP, Office 2003 e Office 2007 facilita le operazioni di installazione e di ripristino automatico per l'utente finale. Con MSI è stato introdotto il concetto di "installazione al primo utilizzo", che consente l'installazione o la configurazione dinamica delle funzionalità in fase di esecuzione per il sistema o, più spesso, per un particolare utente. In un ambiente sul lato server questa struttura rallenta le prestazioni e aumenta le possibilità che venga visualizzata una finestra di dialogo in cui si richiede all'utente di autorizzare l'installazione o di fornire un disco di installazione appropriato. Nonostante sia stata progettata per aumentare la flessibilità di Office come prodotto per l'utente finale, l'implementazione delle funzionalità di MSI è controproducente in un ambiente sul lato server. Inoltre, non è possibile garantire la stabilità generale di Office se eseguito sul lato server in quanto non è progettato né testato per questo specifico utilizzo. L'utilizzo di Office come componente di servizio su un server di rete può ridurre la stabilità del computer e, conseguentemente, quella dell'intera rete. Se si prevede di automatizzare Office sul lato server, provare a isolare il programma su un computer dedicato che non sia in grado di influire su funzionalità critiche e che possa essere riavviato ogni volta che è necessario.
5. Protezione sul lato server: poiché le applicazioni di Office non sono state progettate per l'utilizzo sul lato server, in esse non sono stati presi in considerazione i problemi di protezione riscontrati dai componenti distribuiti. In Office non viene eseguita l'autenticazione di richieste in ingresso e non è prevista una protezione dell'utente dall'esecuzione involontaria di macro o dall'avvio involontario di un altro server da cui possa essere eseguita una macro sulla base del codice sul lato server. Non aprire file caricati sul server da un Web anonimo. Sulla base delle ultime impostazioni di protezione valide, potrebbero venire eseguite dal server delle macro in un contesto Administrator o System con privilegi completi, compromettendo in modo grave la rete. Inoltre, in Office vengono utilizzati numerosi componenti sul lato client, quali Simple MAPI, WinInet e MSDAIPP, che possono memorizzare nella cache le informazioni di autenticazione per velocizzarne l'elaborazione. Se Office viene automatizzato sul lato server, un'istanza potrebbe servire più di un client, e poiché le informazioni di autenticazione sono state memorizzate nella cache per la sessione, un client potrebbe essere in grado di utilizzare le credenziali nella cache di un altro client e ottenere così, mediante la rappresentazione di altri utenti, autorizzazioni di accesso altrimenti non consentite.

Oltre ai problemi di natura tecnica, è poi necessario considerare la fattibilità di un tal genere di progettazione riguardo alla gestione delle licenze. Le attuali regole per la gestione delle licenze impediscono l'utilizzo delle applicazioni di Office su un server per servire le richieste di client, a meno che su tali client non siano installate, a loro volta, copie di Office coperte da licenza. L'utilizzo dell'automazione sul lato server per fornire funzionalità di Office a workstation prive di licenza non è previsto dal Contratto di Licenza con l'utente finale.

Oltre a questi problemi di più ampia portata, è stato riscontrato che a molti utenti, quando tentano di realizzare l'automazione sul lato server e se non modificano l'installazione predefinita di Office, viene visualizzato un messaggio di errore comune analogo a quelli indicati di seguito.

• CreateObject/CoCreateInstance restituisce uno dei messaggi di errore di runtime riportati di seguito e non può essere avviata per l'automazione.
  
  In Microsoft Visual Basic (VB) o ASP:
  • Messaggio 1
    Errore di runtime "'429": il componente ActiveX non può creare l'oggetto
  • Messaggio 2
    Errore di runtime "'70": autorizzazione negata
  In Microsoft Visual C o Visual C++:
  • Messaggio 1
    CO_E_SERVER_EXEC_FAILURE (0x80080005): esecuzione del server non riuscita
  • Messaggio 2
    E_ACCESSDENIED (0x80070005): accesso negato
  Questi errori si verificano perché il codice sul lato server viene eseguito senza un profilo utente o perché l'identità dell'utente specificata per il contesto di avvio non dispone delle autorizzazioni DCOM appropriate.
• L'apertura di un documento di Office provoca la visualizzazione di un messaggio di errore analogo ai seguenti:
  • Messaggio 1
    Errore di runtime '5981' (0x800A175D): impossibile aprire la memoria macro
  • Messaggio 2
    Errore di runtime "'1004": metodo '~' dell'oggetto '~' non riuscito
  In genere la causa è la non riuscita inizializzazione di VBA per insufficienza di autorizzazioni o per mancata registrazione di componenti VBA, tipiche entrambe di quando un utente esegue codice da un account senza un profilo utente (problema 1) e il token dell'utente non contiene il SID interattivo (problema 2).
  
  
• CreateObject/CoCreateInstance si blocca e non viene completata o restituisce risultati dopo molto tempo. Su alcuni server la creazione viene realizzata velocemente, ma nel registro eventi di Windows (NT) sono elencati errori 1004.
  
  Questo problema è in genere causato da una finestra di dialogo modale visualizzata sul desktop non interattivo che esegue il codice sul lato server (problema 2). Se la finestra di dialogo viene visualizzata a causa di un problema di installazione di un componente MSI, ad esempio una voce del Registro di sistema mancante o un file immagine danneggiato, verrà chiesto di fornire il CD di installazione se questo non viene rilevato nel punto di installazione e sarà effettuata la reinstallazione di uno o più componenti (problema 4).
• Alcune funzioni generano errori imprevisti o si bloccano a tempo indeterminato.
  
  In assenza di interattività (problema 2), alcune risorse quali stampanti, unità mappate, oggetti OLE incorporati e gli Appunti, potrebbero non essere disponibili o assumere uno stato non definito. Analogamente, in assenza di un profilo utente (problema 1), le risorse di rete non sono disponibili e le autorizzazioni concesse sono minime.
• L'invio di più richieste o l'esecuzione di test a pieno carico potrebbero provocare l'errore, il blocco o l'arresto anomalo del codice alla creazione o alla chiusura di un'istanza di un'applicazione di Office. Quando si verificano questi eventi, è possibile che il processo rimanga in esecuzione in memoria e non possa essere terminato o che, da questo punto del codice in poi, tutte le istanze dell'applicazione automatizzata generino errori.
  
  Poiché le applicazioni di Office condividono risorse globali (problema 3), l'accesso a un'applicazione di Office deve essere serializzato per specifiche azioni, includendo eventi quali l'avvio, l'arresto, la stampa, l'esportazione e l'aggiornamento dei collegamenti OLE (comprese le notifiche DDE).

Oltre a quelli qui elencati potrebbero riscontrarsi altri problemi o essere visualizzati altri messaggi. Tuttavia, si tratta in genere di conseguenze dei cinque elementi critici precedentemente elencati. Per risolvere questo tipo di errori, è necessario che gli sviluppatori configurino l'ambiente operativo di Office in modo che simuli uno stato sul lato client oppure che rimuovano l'applicazione di Office dal codice sul lato server e utilizzino componenti maggiormente scalabili o l'automazione sul lato client.

Soluzioni alternative all'automazione per l'esecuzione sul lato server

Microsoft consiglia agli sviluppatori di individuare soluzioni alternative all'automazione di Office per l'esecuzione sul lato server. A causa delle limitazioni di progettazione di Office, le modifiche alla configurazione del programma non sono sufficienti a risolvere tutti i problemi. Microsoft consiglia numerose alternative installabili sul lato server senza la necessità di Office e in grado di eseguire operazioni comuni in modo più efficiente e rapido rispetto all'automazione. Prima di includere nel progetto Office come componente sul lato server, prendere in considerazione le soluzioni alternative.

Molte operazioni di automazione sul lato server implicano la creazione di documenti. Poiché Office 2000 e versioni successive supportano HTML come formato di documento nativo, la maggior parte dei documenti può essere creata in HTML, se necessario anche in XML (Extensible Markup Language), e trasmessa a un client utilizzando il tipo MIME (Multipurpose Internet Mail Extensions) in modo che il testo risultante venga visualizzato in Office. Il documento può essere modificato, salvato e, se necessario, restituito al server semplicemente utilizzando codice ASP sul server. Nelle precedenti versioni di Office è possibile utilizzare altri formati di testo facilmente gestibili, quali RTF, per ottenere lo stesso effetto.

Alcuni formati binari nativi possono essere modificati mediante Office Web Components (OWC) o ActiveX Data Objects (ADO), con notevole beneficio in termini di velocità e scalabilità. È possibile visualizzare o modificare le proprietà dei documenti senza necessità dell'automazione e gestire file e versioni mediante le Estensioni del server di FrontPage (FPSE, FrontPage Server Extensions) o il supporto DAV (Distributed Authoring and Versioning). Quando l'automazione è essenziale, la maggior parte delle operazioni può essere scaricata sul client, garantendo al sistema maggiore stabilità e scalabilità dato che ogni utente esegue le operazioni nel proprio contesto e con le proprie impostazioni.

Per ulteriori informazioni sugli argomenti qui discussi e per i relativi esempi di implementazione, fare clic sui numeri degli articoli della Microsoft Knowledge Base riportati di seguito: Se per la propria attività è necessario creare file binari di Office sul lato server, è possibile rivolgersi ad alcuni fornitori indipendenti che offrono componenti utili a questo scopo. Di seguito viene fornito un elenco di noti fornitori di tali servizi. Questo elenco viene fornito solo a scopo informativo e non è esclusivo. È possibile che altri fornitori offrano servizi analoghi più adatti per esigenze specifiche. Sarà quindi opportuno esaminare tutte le possibili soluzioni di terze parti per individuare il fornitore più appropriato. I fornitori riportati di seguito offrono alcune soluzioni che consentono la creazione e la modifica a livello di programmazione di formati di file nativi di Office. Per ulteriori informazioni sui fornitori di terze parti, visitare i seguenti siti Web (informazioni in lingua inglese):

Aia Software B.V.Polar SoftArtisans SyncFusion Keylogix Nota I prodotti di terze parti citati in questo articolo sono forniti da produttori indipendenti. Microsoft non rilascia alcuna garanzia implicita o esplicita relativa alle prestazioni o all'affidabilità di tali prodotti.

Configurazione di Office per l'esecuzione sul lato server

Se le soluzioni alternative non sono praticabili e si decide di procedere con l'automazione sul lato server di Office, è necessario prendere in considerazione i vari elementi critici discussi in precedenza per assicurare una corretta esecuzione in tale ambiente. Dal momento che la maggior parte dei problemi è connessa alla configurazione, non è possibile fornire un'unica procedura che garantisca il funzionamento dell'automazione sul lato server di Office in tutti i casi e per tutti i sistemi. Alcune impostazioni di configurazione potrebbero trovarsi in conflitto con altre opzioni e ogni approccio presenta vantaggi e svantaggi. Potrà essere pertanto necessario sperimentare vari approcci per individuare quello più efficace per lo specifico ambiente operativo.

Per automatizzare Office in base al codice sul lato server è in genere necessario attenersi alle seguenti linee guida:

• Delineare il progetto in modo da isolare e incapsulare Office.
• Scrivere il codice del progetto secondo modalità che consentano di prevedere i problemi e di tentarne una correzione dinamica.
• Dotare il progetto di un'identità e un profilo utente specifici da utilizzare per Office.

Quando si prevede l'utilizzo dell'automazione di Office, è necessario delineare il progetto considerando aspetti quali i problemi di protezione sul lato server e l'assenza di rientranza di Office. Limitare l'utilizzo di Office a un'istanza specifica controllata da un oggetto di serializzazione (mutex o primitivo bloccante personalizzato) o raggruppare un insieme strettamente controllato di istanze da un gestore (o intermediario) di oggetti personalizzato che sia in grado di generare gli oggetti dell'applicazione quando necessario, controllando però gli aspetti relativi alla serializzazione. Poiché in Office viene ricevuta una certa quantità di informazioni di stato, la presenza di più client che eseguono simultaneamente alcune azioni, quali l'avvio, l'arresto, la stampa e così via, può causare un conflitto e il blocco critico di uno o più thread chiamanti mediante la visualizzazione di un messaggio di errore in cui si richiedono all'utente ulteriori informazioni o mediante il rifiuto di liberare una risorsa globale utilizzata da tutte le istanze.

Il primo passo consiste, pertanto, nel limitare l'utilizzo dell'automazione di Office nella progettazione sul lato server e nell'isolare il processo in un computer che non gestisce funzionalità critiche e che possa essere riavviato ogni volta che è necessario. Isolare anche il processo chiamante, così che l'eventuale blocco di un client chiamante non riduca le prestazioni di un servizio di sistema essenziale. Ad esempio, non eseguire l'automazione direttamente da Microsoft Internet Information Server (IIS) utilizzando un thread di sistema, ma isolare il codice in modo che venga eseguito in un thread specifico e che, in caso di errore, non riduca pertanto le funzionalità generali di IIS. Valutare inoltre le modalità con cui nella progettazione viene imposta la protezione e l'autenticazione. Poiché in Office non viene imposta la protezione sul lato server, è necessario scrivere codice che consenta ai soli moduli di codice (pagine ASP, file di script e così via) attendibili la creazione di un'istanza automatica di un'applicazione di Office e la chiamata dei relativi metodi e che garantisca la sicurezza di tutti i documenti prima che vengano aperti in Office. La protezione delle applicazioni di Office eseguite su server deve essere sempre impostata su Alta. Se nella progettazione non è stata inclusa l'imposizione della protezione, il server funzionerà in condizioni di rischio.

Una volta predisposta la progettazione, creare codice a elevata protezione per provare a prevenire il verificarsi di errori e a gestirli quando questi si verificano. Assicurarsi che il codice consenta il passaggio di valori per parametri facoltativi, poiché la mancanza o il conflitto tra valori può spesso comportare la visualizzazione di messaggi di Office in cui si richiedono all'utente ulteriori informazioni. Utilizzare in tutte le funzioni l'intercettazione degli errori per gestire correttamente le condizioni di errore e registrarli mediante codice di registrazione attivabile o disattivabile tramite un'impostazione personalizzata (nel Registro di sistema o in un file INI). Se si esegue un'azione che può causare la visualizzazione di una finestra di dialogo di errore indipendente da Office, ad esempio, una finestra di dialogo dipendente dal driver della stampante visualizzata durante la stampa quando la carta della stampante è esaurita, prepararsi a gestire eventuali blocchi critici utilizzando un thread di timeout o un secondo thread per controllare l'avanzamento. Per ulteriori informazioni, fare clic sul numero dell'articolo della Microsoft Knowledge Base riportato di seguito: Utilizzare il codice di registrazione per tenere traccia dei problemi e per eseguire il debug del programma. Se si utilizza un pool di oggetti personalizzati, è possibile aggiungere test di prestazioni e di scalabilità per monitorare l'utilizzo e registrare i problemi riscontrati da tutti i client. Tramite un controller centrale è inoltre possibile terminare istanze di Office con errori e ricrearle quando necessario per rafforzare la stabilità complessiva.

Una volta che il programma è pronto per la distribuzione, assicurarsi che la configurazione di Office sul server sia appropriata a garantire l'esecuzione di un contesto utente idoneo. Poiché è necessario per l'esecuzione di Office, verificare che il programma sia caricato con un profilo utente in modo da garantire una corretta automazione. Per effettuare questa operazione in un ambiente sul lato server sono disponibili tre soluzioni alternative:

• Configurare tutte le istanze dell'applicazione di Office avviata tramite l'automazione in modo che vengano eseguite con l'account utente interattivo.
• Configurare tutte le istanze dell'applicazione di Office avviata tramite l'automazione in modo che vengano eseguite con l'account di un utente specifico.
• Configurare il codice in modo che venga eseguito con l'account di un utente specifico utilizzando un pacchetto MTS/COM+ e consentendo all'applicazione di Office di ereditare l'identità dell'utente che avvia l'applicazione.

La prima soluzione consente l'esecuzione di Office con funzionalità di identità e interattività in uno specifico desktop. È quella preferibile in fase di debug, dal momento che Office può essere reso visibile e qualsiasi finestra di dialogo o errore di protezione generale può essere visualizzato dall'utente connesso localmente. Poiché per essere eseguita correttamente tale soluzione richiede che l'utente interattivo rimanga connesso, potrebbe non essere idonea in determinate situazioni. Per ulteriori informazioni, fare clic sul numero dell'articolo della Microsoft Knowledge Base riportato di seguito: La seconda soluzione prevede l'assegnazione di un utente specifico, ma non consente l'interattività. Office viene avviato con l'utente assegnato in una nuova WinStation su un desktop invisibile. Tale soluzione richiede un'ulteriore configurazione per assicurare il caricamento dell'hive del Registro di sistema dell'utente, non realizzabile per impostazione predefinita mediante COM/DCOM. Poiché si tratta di un'impostazione globale di sistema, potrebbe entrare in conflitto con altri programmi. Per informazioni su questo tipo di configurazione di Office, fare clic sul numero dell'articolo della Microsoft Knowledge Base riportato di seguito: La terza soluzione consente di assegnare un'identità a uno specifico sito Web o modulo di codice, senza impostare un'identità fissa per Office a livello globale. Office viene eseguito con tale identità e caricato correttamente sempre che l'identità sia stata precedentemente configurata per lo specifico computer e che l'hive del Registro di sistema sia stato caricato. Si tratta della soluzione generalmente più flessibile e protetta, ma, come la precedente, non offre interattività con un desktop visibile e richiede un'ulteriore impostazione. Per informazioni su questo tipo di configurazione di Office, fare clic sul numero dell'articolo della Microsoft Knowledge Base riportato di seguito: È necessario valutare quale delle suddette soluzioni si adatta meglio alle specifiche esigenze e quale sia il modo migliore per distribuirla. Le informazioni fornite in questo articolo non garantiscono la risoluzione di tutti i problemi per tutti i client. È consigliata l'esecuzione di test approfonditi prima di distribuire la soluzione adottata.

Per ulteriori informazioni sull'automazione sul lato server, fare clic sui numeri degli articoli della Microsoft Knowledge Base riportati di seguito: