Extend SharePoint to Integrate Other Office Applications

Articolo
08/24/2016

Inside SharePointIntegrazione delle applicazioni di Microsoft Office

Pav Cherny

Indice

Integrazione delle applicazioni di Microsoft Office
Estensione dell'interfaccia utente di SharePoint
Uso del controllo OpenDocuments di Microsoft Office
Comunicazione con SharePoint
Implementazione di una soluzione OpenControl personalizzata
Conclusioni

Microsoft Windows SharePoint Services (WSS) 3.0 e Microsoft Office SharePoint Server (MOSS) 2007 si integrano perfettamente con le applicazioni desktop presenti in Microsoft Office System 2007, favorendo la collaborazione su documenti, fogli di calcolo, calendari, informazioni sui contatti e altro ancora. Di fatto, l'integrazione è così perfetta che

si può dire che Office System 2007 sia una piattaforma unificata di soluzioni per l'ufficio.

Questo è un vantaggio straordinario per le organizzazioni che puntano sulla tecnologia Microsoft® Office per incrementare la produttività degli information worker. Tuttavia, le organizzazioni con un portafoglio diversificato di applicazioni di Microsoft Office non possono godere dello stesso livello di interoperabilità immediata. Office System 2007 fornisce le funzionalità di integrazione necessarie, eppure le interfacce e i componenti dispongono solo di una documentazione minima e non funzionano in ogni circostanza. Questo fa sì che per i fornitori di terze parti risulti difficile integrare la tecnologia SharePoint® nelle applicazioni prodotte, mentre è ancora più difficile per i loro clienti assicurare un'esperienza unificata agli information worker.

In questa rubrica, mostrerò come le applicazioni di Microsoft Office possano integrarsi e comunicare con SharePoint e come, in base agli stessi principi, sia possibile integrare con SharePoint le applicazioni non Microsoft. Innanzitutto, però, illustrerò brevemente le impostazioni di configurazione del server, i componenti del lato client e i protocolli di comunicazione utilizzati per ottenere un'integrazione perfetta.

Una volta chiariti questi dettagli, potrò affrontare la discussione dell'integrazione delle applicazioni che non sono dotate di supporto di SharePoint incorporato. In questo contesto, andrò oltre il tradizionale livello che solitamente si concentra sull'implementazione di componenti IFilter per estendere le funzionalità di ricerca e aggiungere le icone personalizzate ai server SharePoint. L'estensione della ricerca e la restituzione dei risultati con le icone appropriate non riescono a produrre un'integrazione completa delle applicazioni; gli utenti potrebbero anche voler aprire i documenti direttamente dall'interfaccia utente di SharePoint.

E questo è il punto in cui la questione si complica. Se nelle workstation non è stato distribuito Microsoft Office, è necessario disporre di un componente lato client che non sia prontamente disponibile. Ma anche se Microsoft Office è stato distribuito, potrebbe accadere che il componente non funzioni in modo affidabile, a seconda della configurazione e della topologia del sito SharePoint.

Per risolvere il problema, ho creato una soluzione personalizzata che consente l'integrazione di qualsiasi applicazione, come ad esempio Blocco note, Adobe Reader o Autodesk AutoCAD, senza i requisiti di distribuzione di Microsoft Office. La soluzione personalizzata spiega anche perché, in alcune situazioni, l'integrazione delle applicazioni basata sui componenti standard di Microsoft Office non riesce. La soluzione, insieme alle istruzioni dettagliate per la distribuzione e la configurazione, si trova nel materiale di accompagnamento di questa rubrica, disponibile nella sezione Code Downloads di questo sito.

Integrazione delle applicazioni di Microsoft Office

Dal punto di vista dell'utente, i menu di SharePoint sembrano funzionare come il menu Start di Microsoft Windows®. La creazione di un nuovo documento in una raccolta documenti è semplice: si fa clic su Nuovo, quindi su Nuovo documento e viene avviato Microsoft Office Word 2007. Anche la modifica di un documento esistente è altrettanto facile: si passa il puntatore del mouse sul nome del documento, si apre il menu a discesa ECB (Edit Control Box), quindi si fa clic su Modifica in Microsoft Office Word. Raramente si pensa che Microsoft Office Word 2007 è stato avviato da una pagina Web tramite JavaScript, che l'applicazione viene eseguita localmente, mentre il documento risiede molto lontano in un database SQL Server® e che esiste un server Web all'interno del percorso di accesso ai dati, come illustrato nella Figura 1.

Figura 1 Lavorare in SharePoint con un documento di Microsoft Office Word (fare clic sull'immagine per ingrandirla)

Malgrado la complessità, l'esperienza dell'utente al lavoro su una workstation Windows in cui è installato Office System 2007 risulta perfetta. Lavorare con i documenti in una raccolta SharePoint è molto simile a lavorare con file locali o file in una condivisione di rete.

Tuttavia in una workstation Windows priva di Microsoft Office 2003 o di Office System 2007, l'interfaccia utente è diversa. Quando si fa clic su Nuovo documento o Modifica in Microsoft Office Word viene soltanto visualizzata una finestra di dialogo che informa che non è disponibile un'applicazione compatibile con Windows SharePoint Services.

Non è certo una sorpresa. Sono diversi i fattori che devono concorrere per fornire all'utente di Microsoft Office quell'esperienza unificata così tanto gradita. Per poter eseguire il rendering dei comandi desiderati nei menu Nuovo ed ECB, SharePoint deve disporre delle informazioni riguardanti i tipi di contenuto presenti nella raccolta documenti. In risposta ai clic del mouse su questi comandi, deve essere eseguito il codice JavaScript per avviare l'applicazione associata, avvalendosi del percorso per il documento. Questa parte non è indipendente dalla configurazione della workstation, dal momento che il codice JavaScript viene eseguito localmente. Inoltre, l'applicazione associata deve comunicare con SharePoint per leggere e, forse, scrivere i file. Per integrare le applicazioni con SharePoint, sono questi gli elementi da riunire.

D'altra parte, le comunicazioni tra SharePoint e il server database è trasparente per l'applicazione, così come lo sono i processi di indicizzazione sul server Web per favorire le ricerche. Per questa ragione, nel presente articolo non mi dilungherò oltre su questi aspetti, consigliando invece la consultazione del pacchetto Microsoft Filter documentato nell'articolo della Microsoft Knowledge Base "How to Register Microsoft Filter Pack with Windows SharePoint Services 3.0", disponibile all'indirizzo support.microsoft.com/kb/946338 (in inglese). A questo punto, concentreremo l'attenzione sull'aggiunta dei comandi, l'implementazione dei componenti lato client necessari e la definizione delle comunicazioni tra le applicazioni.

Estensione dell'interfaccia utente di SharePoint

Sono disponibili moltissime opzioni per estendere la funzionalità e l'interfaccia utente di SharePoint. Per avviare direttamente le applicazioni, è possibile cambiare il progetto dei siti, personalizzare le pagine ASP.NET, sviluppare le web part oppure modificare il codice JavaScript in WSS e MOSS.

Niente impedisce di aprire il file Ows.js in un editor di testo (il file si trova nella cartella COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\12\Template\Layouts\1033 nei server front-end di SharePoint) e di cambiare il modo in cui funzionano le funzionalità createNewDocumentWithProgIDCore, editDocumentWithProgIDNoUI e DispDocItem. Tuttavia, esiste un metodo migliore che non richiede la modifica della base di codice WSS in modi non supportati: usare le associazioni tra tipi di contenuto e tipi di documento.

Nel mio articolo "Standardizzazione della gestione dei dati con tipi di contenuto personalizzati" (vedere TechNet Magazine, febbraio 2008, disponibile all'indirizzo technet.microsoft.com/magazine/cc194408.aspx), ho spiegato come creare tipi di contenuto globali e specifici del sito per gestire i documenti e altro contenuto negli elenchi e nelle raccolte documenti di SharePoint. Si può anche consultare il foglio di lavoro Content Type.pdf disponibile nel materiale di accompagnamento del presente articolo, in cui viene descritto come creare un nuovo tipo di contenuto per i file txt e associarlo con una raccolta documenti. Il risultato è che diventa possibile selezionare il comando Contenuto testo nel menu Nuovo, allo stesso modo in cui si seleziona il comando Documento per i documenti di Microsoft Office Word (vedere la Figura 2).

Figura 2 Tipo di contenuto personalizzato nell'interfaccia utente di SharePoint (fare clic sull'immagine per ingrandirla)

Anche il menu ECB può essere esteso. Ci si potrebbe aspettare che il menu ECB fosse in grado di riconoscere il tipo di contenuto, ma con la versione corrente di WSS il menu non è implementato in questo modo. Al contrario, si deve registrare il tipo di documento nel file Docicon.xml, che si trova nella cartella %COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\12\Template\Xml in ogni server front-end di SharePoint.

Ad esempio, aggiungendo la seguente associazione al tipo di documento nella sezione <ByExtension> di Docicon.xml, SharePoint visualizzerà il comando Modifica in Blocco note (per ulteriori informazioni, vedere il file Text Content Type.pdf):

<Mapping Key="text" Value="ictxt.gif" 
  EditText="Notepad"
  OpenControl="SharePoint.OpenDocuments"/>

Il parametro Key identifica l'estensione del nome del file, il parametro Value definisce l'icona del documento da visualizzare nell'interfaccia utente, il parametro EditText definisce la stringa che SharePoint aggiunge al comando "Modifica in", mentre il parametro OpenControl specifica il ProgID di un componente COM del lato client. È il ProgID che le funzioni JavaScript di SharePoint passano alla chiamata ActiveXObject (per ulteriori informazioni, vedere Ows.js) per creare un'istanza dell'oggetto COM, che potrà essere l'applicazione stessa oppure un controllo helper che avvia l'applicazione in base al tipo di file associato.

Sito Web di Prodotti e tecnologie SharePoint

Tenere presente che il parametro OpenControl denominato SharePoint.OpenDocuments fa riferimento a un controllo ActiveX® fornito con le versioni più recenti di Microsoft Office (%PROGRAMFILES%\Microsoft Office\Office12\Owssupp.dll). Se questo file è già presente nelle workstation e se l'icona specificata per il documento (tramite il parametro Value) si trova nella cartella %COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\12\Template\Images dei server SharePoint, il lavoro di integrazione richiesto potrebbe già essere a buon punto.

L'SDK di Windows SharePoint Services 3.0 contiene alcune informazioni sulle API del lato client fornite con Office System 2007, incluso il controllo OpenDocuments. Per informazioni, vedere la sezione "Client-Side API Reference" disponibile all'indirizzo msdn2.microsoft.com/ms440037 (in inglese).

Uso del controllo OpenDocuments di Microsoft Office

Il controllo OpenDocuments soddisfa le esigenze più critiche dell'integrazione delle applicazioni, ma richiede Microsoft Office 2003 oppure Office System 2007 e le sue funzionalità sono piuttosto limitate. I comandi presenti nel menu Nuovo potrebbero non funzionare sempre e, a volte, visualizzano notifiche che possono essere fuorvianti.

Come illustrato nella Figura 3, il controllo OpenDocuments informa l'utente che l'applicazione richiesta non è installata correttamente oppure che è impossibile aprire il file modello, ma questo non è vero in nessuno dei due casi. Anche la funzionalità Modifica in presenta dei problemi. Viene visualizzato spesso il secondo messaggio di errore mostrato in primo piano nella Figura 3. Tra i diversi problemi è quello che in assoluto mi affascina di più, perché mette fuori strada anche gli esperti di SharePoint, come spiegherò più avanti.

Figura 3 Messaggi di errore fuorvianti prodotti dal controllo OpenDocuments (fare clic sull'immagine per ingrandirla)

Tuttavia, il controllo OpenDocuments risulta utile negli ambienti in cui su tutte le workstation sono installate versioni recenti di Microsoft Office. Tra l'altro, per fare in modo che agli utenti non sia visualizzato il primo messaggio di errore, è possibile nascondere i tipi di contenuto dal menu Nuovo; a questo scopo, visualizzare le impostazioni della raccolta documenti, fare clic su Modifica ordine pulsante Nuovo e tipo di contenuto predefinito, quindi deselezionare la casella di controllo Visibile di tutti i tipi di contenuto in questione. Inoltre, si può cercare di semplificare al massimo la topologia del sito, al fine di evitare i problemi di comunicazione WebDAV (Web-Based Distributed Authoring and Versioning). Così facendo, si elimina il secondo messaggio di errore.

Comunicazione con SharePoint

Fin qui sono riuscito a estendere l'interfaccia utente di SharePoint e forse avviare un'applicazione tramite il controllo OpenDocuments, ma la mia applicazione ha ancora bisogno di un modo per comunicare con SharePoint per accedere ai dati. Come sempre, SharePoint supporta più metodi per ottenere questo risultato, come ad esempio le Estensioni del server di Microsoft Office FrontPage®, le chiamate RPC (Remote Procedure Call) di WSS, i servizi Web e WebDAV. Di fatto, le applicazioni di Microsoft Office, come ad esempio Word 2007, potrebbero utilizzare uno o tutti questi metodi di comunicazione, a seconda di come si accede a un documento, se tramite le cartelle Web, le unità di rete mappate oppure l'interfaccia utente di SharePoint.

I metodi di comunicazione client/server di SharePoint si basano su HTTP come protocollo sottostante. Ad esempio, FrontPage e le chiamate RPC di WSS utilizzano tutti le richieste HTTP POST e HTTP GET dirette alle estensioni ISAPI residenti nei server SharePoint all'interno della cartella %COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\12\ISAPI e di tutte le relative sottocartelle.

Una delle estensioni ISAPI più importanti è Owssvr.dll, che implementa, tra l'altro, la funzionalità necessaria per lavorare con gli elenchi e le raccolte documenti. Nella Figura 4 viene mostrata la finestra di dialogo Salva di SharePoint in Office Word 2007 (a sinistra) e in un browser (a destra) aperta direttamente tramite la richiesta URL https://sharepoint/HR/Administration/_vti_bin/owssvr.dll?dialogview=FileSave&location=Shared%20Documents&FileDialogFilterValue=*.docx. Le somiglianze tra le due schermate acquisite sono evidenti.

Figura 4 Finestra di dialogo Salva di SharePoint in Office Word 2007 e in Internet Explorer (fare clic sull'immagine per ingrandirla)

Altre estensioni ISAPI importanti sono Author.dll, che implementa FrontPage e le chiamate RPC di WSS per le operazioni di modifica dal lato client (ad esempio, caricamento, ridenominazione ed eliminazione di documenti); Admin.dll per gestire i siti ed eseguire varie altre attività amministrative; Shtml.dll per supportare l'invio di moduli HTML.

In genere è impossibile aggiungere il supporto di FrontPage e delle chiamate RPC di WSS alle applicazioni esistenti, come ad esempio Blocco note o Adobe Reader, senza dover accedere al codice sorgente. Tuttavia, si può fornire la necessaria funzionalità per le comunicazioni utilizzando la funzionalità Web Client di Windows.

SharePoint supporta anche WebDAV attraverso Httpext.dll, che risiede nella cartella %WINDIR%\System32\Inetsrv\, ma continuiamo a rimanere dal lato client. Nei computer che eseguono Windows Server® 2008 o Windows Vista®, la funzionalità Web Client è installata per impostazione predefinita. Un servizio WebClient corrispondente si trova nella applet Servizi in Strumenti di amministrazione del Panello di controllo. In Windows XP e Windows Server 2003, è necessario installare il client Web in modo esplicito. In ogni caso, accertarsi che il servizio WebClient sia avviato e che il tipo Avvio sia impostato su Automatico.

Nella Figura 5 viene mostrata l'architettura del client Web. Il servizio WebClient viene implementato in una DLL in modalità utente (Webclnt.dll) che Gestione controllo servizi carica nel processo host Svchost.exe. Webclnt.dll fornisce l'interfaccia Provider di rete per le operazioni diverse da quelle di I/O (ad esempio, l'autenticazione dell'utente per l'accesso a WebDAV; il montaggio dei siti SharePoint come unità di rete; l'enumerazione di siti, elenchi e raccolte documenti di SharePoint come risorse di rete; la disconnessione delle unità montate).

Figura 5 Architettura del redirector del client WebDav (fare clic sull'immagine per ingrandirla)

Per eseguire questo lavoro, Webclnt.dll comunica con un driver del file system in modalità kernel che fornisce la funzionalità redirector effettiva. Il driver del redirector del client WebDav (Mrxdav.sys) è basato sul sottosistema RDBSS (Redirected Drive Buffering Subsystem), che viene integrato con I/O Manager e altri componenti kernel al fine di fornire i servizi di un file system remoto. Con Mrxdav.sys viene implementata la funzionalità di comunicazione WebDAV per supportare l'accesso a livello di file system ai siti e alle raccolte documenti di SharePoint.

Disporre dell'accesso ai siti e alle raccolte documenti di SharePoint tramite un redirector di rete significa eliminare la necessità del supporto di FrontPage e delle chiamate RPC di WSS nelle applicazioni dell'utente. Le unità di rete possono essere associate alle raccolte documenti (come, ad esempio, net use x: http://wss/doclib/Shared%20Documents) ed è anche possibile accedere alle risorse di SharePoint tramite i percorsi UNC.

L'URL http://wss/doclib/Shared%20Documents è associato a \\wss\doclib\Documenti%20condivisi. Pertanto, sono disponibili diverse scelte per aprire un documento in un'applicazione. Ad esempio, si può aprire un documento in Blocco note con il percorso HTTP http://wss/doclib/Shared%20Documents/New%20Text%20Document.txt oppure il percorso UNC \\wss\doclib\Documenti%20condivisi\New%20Text%20Document.txt.

Purtroppo, la funzionalità Web Client evidenzia diversi limiti. Ad esempio, non è possibile accedere alle proprietà personalizzate o alle applicazioni Web che utilizzano porte TCP personalizzate. Anche l'esecuzione del client Web fornito con Windows Vista non riesce se l'utente non dispone dell'accesso a un sito padre nella gerarchia, come spiegato nel file WebDAV Access.pdf (vedere il materiale di accompagnamento).

Il percorso https://sharepoint/HR/Administration/Shared%20Documents/ include un sito principale (ovvero https://sharepoint) che non esiste, eppure senza accesso alla radice il client Web non riesce a stabilire le funzionalità del server Web. Il server Web respinge la richiesta OPTIONS del client Web con il codice di stato 401, indicante che l'accesso non è autorizzato e, di conseguenza, il client Web continua a richiedere le credenziali utente, come illustrato nella Figura 6, anche se l'utente dispone dell'accesso amministrativo alla raccolta di siti SharePoint/HR e a tutti i siti che contiene.

Figura 6 Accesso non riuscito a WebDAV (fare clic sull'immagine per ingrandirla)

Quando si utilizza il controllo OpenDocuments, se il client Web non riesce ad aprire un documento viene visualizzato il messaggio di errore mostrato nella Figura 3. L'applicazione è disponibile e l'associazione al tipo di documento è corretta. Ma è al documento che non è possibile accedere tramite il redirector WebDAV.

Implementazione di una soluzione OpenControl personalizzata

In genere, due sono le opzioni che consentono di risolvere le limitazioni del client Web. Si può attendere che Microsoft fornisca una versione aggiornata del client Web oppure si può implementare una soluzione OpenControl personalizzata in grado di risolvere la situazione corrente. L'implementazione di una soluzione OpenControl personalizzata non è un'impresa da poco, ma elimina la necessità di disporre di Microsoft Office nella workstation, consente di gestire in modo utile i comandi Nuovo e Modifica in, nonché di porre rimedio alle situazioni in cui il client Web non riesce.

Se una qualunque di queste eventualità dovesse risultare interessante, allora è il caso di dare un'occhiata al codice sorgente AppStart incluso nel materiale di accompagnamento. AppStart consente di esporre le interfacce COM di OpenControl in un assembly Microsoft .NET Framework, a cui il codice JavaScript di SharePoint può effettuare una chiamata. Inoltre, il codice sorgente AppStart offre la dimostrazione di uno dei modi di verificare l'accessibilità ai file e di scaricare un file nel computer locale tramite HTTP nel caso in cui l'accesso diretto tramite WebDAV non fosse possibile. Infine, il codice sorgente AppStart risponde al comando Nuovo scaricando nel computer locale il modello associato al tipo di contenuto, di modo che l'utente possa iniziare a lavorare sul documento. I fogli di lavoro Text Content Type.pdf e Adobe Reader Support.pdf descrivono come distribuire la soluzione OpenControl.

Il diagramma contenuto nella Figura 7 mostra l'architettura di AppStart. Il mio componente OpenControl (chiamato Biblioso.dll) espone due interfacce COM identiche che il codice JavaScript di SharePoint chiama per creare nuovi documenti o per aprire documenti esistenti da modificare (Biblioso.AppStart.2 e Biblioso.AppStart.3).

Figura 7 Architettura di AppStart (fare clic sull'immagine per ingrandirla)

Se si apre un documento per modificarlo, Biblioso.dll verifica l'esistenza del file e avvia l'applicazione associata seguendo il percorso al documento, se il file è accessibile direttamente tramite WebDAV. In caso contrario, Biblioso.dll avvia un server COM esterno al processo che, a sua volta, carica OpenDocsUtility.dll per scaricare il file tramite HTTP e avviare l'applicazione seguendo il percorso al documento scaricato.

Il server COM esterno al processo consente alla soluzione di sottrarsi al processo di Internet Explorer®, che limita i download alla cartella dei file temporanei Internet in Modalità protetta. Gli utenti devono poter scaricare i file senza i limiti imposti dalla Modalità protetta e un server COM esterno al processo che funziona come broker di applicazioni fornisce esattamente questa opzione.

Lo sviluppo di server COM esterni al processo non è supportato in .NET, pertanto per questo eseguibile ho preferito C/C++. In C++ ho implementato soltanto il minimo indispensabile, ovvero la finestra di dialogo Salva con nome. Per mantenere la soluzione quanto più semplice possibile e limitare il sovraccarico di sviluppo, ho inserito il codice di download vero e proprio in un assembly .NET (OpenDocsUtility.dll), che successivamente richiamo tramite un'altra interfaccia COM.

Per semplificare la distribuzione, ho aggiunto alla soluzione un progetto di installazione. Tra le altre cose, la routine di installazione registra tutti i componenti COM e scrive le impostazioni specifiche dell'applicazione in HKEY_LOCAL_MACHINE\SOFTWARE\Biblioso\AppStart. I parametri più importanti sono AllowedApps e AllowedFileTypes. La soluzione AppStart funziona soltanto con le applicazioni e i tipi di file che devono essere specificati esplicitamente in questi parametri.

Inoltre, la routine di installazione crea un criterio di elevazione per il server COM esterno al processo, di modo che Biblioso.dll nel processo di Internet Explorer possa avviare AppBrokerEngine.exe senza attivare avvisi di protezione. Per ulteriori informazioni sulla Modalità protetta di Internet Explorer e sul modo di gestirla durante lo sviluppo delle applicazioni, consiglio vivamente di leggere l'articolo di Marc Silbey e Peter Brundrett "Understanding and Working in Protected Mode Internet Explorer", disponibile all'indirizzo msdn2.microsoft.com/bb250462 (in inglese).

Quando si prendono in esame i componenti di AppStart, tenere presente che questa soluzione è stata sviluppata soltanto per mostrare ciò che è possibile fare, pertanto non è ancora pronta per gli ambienti di produzione. Non c'è stato il tempo sufficiente per ottimizzare il codice e testare a fondo la soluzione oppure per documentarne le funzionalità, a parte i commenti del codice sorgente.

L'utilizzo della soluzione è perciò completamente sotto la responsabilità dell'utente. Per chi fosse interessato a studiare il codice sorgente per creare una soluzione personale, il consiglio è di iniziare con AppStart.cs nel progetto di codice Biblioso. È un file che implementa l'interfaccia COM di OpenControl e i punti di ingresso delle chiamate JavaScript da Ows.js.

Conclusioni

WSS 3.0 e MOSS 2007 forniscono ampie funzionalità di integrazione delle applicazioni capaci di creare un'esperienza utente perfetta quando si lavora con documenti e altri elementi negli elenchi e nelle raccolte documenti di SharePoint. Le applicazioni desktop in Office System 2007 ne sono una dimostrazione lampante ed è possibile raggiungere lo stesso livello di integrazione e usabilità anche con applicazioni non contenute in Office.

Il nucleo dell'architettura dell'integrazione delle applicazioni è costituito dai componenti COM, utilizzati dalle funzioni JavaScript di SharePoint per avviare l'applicazione, seguendo il percorso dei documenti. Office System 2007 fornisce alcuni di questi componenti COM, ottimizzati per esigenze specifiche delle applicazioni di Microsoft Office, sebbene sia possibile anche riutilizzare il controllo OpenDocuments di Office per integrare applicazioni non Microsoft. Il controllo OpenDocuments riesce a soddisfare le esigenze più elementari. In caso di requisiti più avanzati per l'integrazione delle applicazioni, occorre implementare un controllo personalizzato.

L'integrazione completa di un'applicazione con SharePoint comporta non solo l'installazione di componenti IFilter e di icone dei documenti per estendere le funzionalità di ricerca e visualizzazione, ma anche la creazione di tipi di contenuto e di associazioni a tipi di documento personalizzati nei server SharePoint, così da fornire gli appositi comandi Nuovo e Modifica in nell'interfaccia utente di SharePoint. Questi comandi chiamano funzioni JavaScript che richiamano metodi esposti attraverso un componente OpenControl, il quale deve essere anch'esso disponibile nella workstation.

Un'altra tessera importante del puzzle è rappresentata dal client Web, incluso e installato per impostazione predefinita in Windows Vista. Il client Web implementa un redirector WebDAV e un driver di file system remoto, di modo che tutte le applicazioni possano accedere alle risorse presenti negli elenchi e nelle raccolte documenti di SharePoint, analogamente a quanto avviene con le condivisioni file nella rete. Sebbene presenti degli inconvenienti, il client Web fornito con Windows Vista è un capitolo fondamentale della storia dell'integrazione delle applicazioni.

Anche il supporto di WebDAV colma il divario tra le applicazioni eseguite in workstation non Windows e SharePoint. In genere, la tecnologia dei controlli COM e ActiveX non è disponibile in questi sistemi operativi, pertanto non è possibile avviare automaticamente le applicazioni. Tuttavia, la maggior parte dei sistemi operativi include redirector WebDAV che consentono agli utenti almeno di accedere direttamente ai documenti contenuti nelle raccolte documenti senza dover ricorrere al download dei file nelle workstation locali.

WSS 3.0 e MOSS 2007 sono due capisaldi della storia del successo di Office System 2007 e gli utenti di applicazioni di terze parti basate su Microsoft Office possono sfruttare i vantaggi offerti da SharePoint allo stesso modo. Le funzionalità di integrazione vanno ben oltre Microsoft Office. Sfruttando al meglio SharePoint, è possibile creare una piattaforma unificata di soluzioni per l'ufficio capace di offrire la medesima esperienza utente sia per il software di Microsoft Office che per quello di terze parti, con il conseguente aumento della produttività degli information worker.

Pav Cherny è un esperto e un autore in materia di IT, specializzato in tecnologie Microsoft per la collaborazione e le comunicazioni unificate. Le sue pubblicazioni includono white paper, manuali di prodotti e libri su amministrazione del sistema e operazioni IT. Pav è Presidente di Biblioso Corporation, un'azienda specializzata in servizi di localizzazione e documentazione gestita.

Risorse aggiuntive