Extend SharePoint to Integrate Other Office Applications

Article
08/23/2016

Au cœur de SharePointIntégration d'applications Office

Pav Cherny

Sommaire

Intégration d'applications Office
Extension de l'interface utilisateur SharePoint
Utilisation du contrôle Office OpenDocuments
Communication avec SharePoint
Implémentation d'une solution OpenControl personnalisée
Résumé

Microsoft Windows SharePoint Services (WSS) 3.0 et Microsoft Office SharePoint Server (MOSS) 2007 s'intègrent de manière transparente à des applications de bureau dans Microsoft Office System 2007, ce qui facilite la collaboration sur les documents, les tableurs, les calendriers, les informations de contacts et bien plus encore. En fait, l'intégration est tellement transparente que l'on

peut dire qu'Office System 2007 est une plate-forme de solutions Office unifiée.

C'est formidable pour les entreprises qui se concentrent sur la technologie Microsoft® Office pour augmenter la productivité des spécialistes de l'information. Cependant, les organisations ayant un portefeuille varié d'applications Office ne peuvent pas apprécier le même niveau d'interopérabilité dès le départ. Office System 2007 fournit les capacités d'intégration nécessaires, cependant les interfaces et composants sont très peu documentés et ne fonctionnent pas en toutes circonstances. Ainsi, il est difficile pour les fournisseurs tiers d'intégrer la technologie SharePoint® à leurs applications et encore plus dur pour leurs clients de fournir une expérience unifiée aux spécialistes de l'information.

Dans cet article, je vais vous montrer comment les applications Office s'intègrent et communiquent avec SharePoint et comment vous pouvez intégrer des applications autres que Microsoft avec SharePoint selon sur les mêmes principes. Mais tout d'abord, je vais parler brièvement des paramètres de configuration du serveur, des composants côté client et des protocoles de communication utilisés pour obtenir une intégration transparente.

Une fois que ces détails sont clairs, je peux aborder l'intégration d'applications ne s'accompagnant pas d'une prise en charge SharePoint intégrée. Dans cet effort, j'irai plus loin que le niveau habituel qui porte généralement sur l'implémentation de composants IFilter pour étendre les capacités de recherche et j'ajouterai des icônes personnalisées sur des serveurs SharePoint. L'extension de la recherche et le renvoi de résultats avec des icônes correctes ne permettent pas d'obtenir une intégration d'application complète. Les utilisateurs risquent de vouloir également ouvrir ces documents directement depuis l'interface utilisateur SharePoint.

C'est là que ça se complique. Vous avez besoin d'un composant côté client qui ne soit pas facilement disponible si vous n'avez pas déployé Office sur vos postes de travail. Mais, même si vous avez déployé Office, vous trouverez peut-être que ce composant ne fonctionne pas de manière fiable, en fonction de votre topologie et configuration de site SharePoint.

Pour résoudre ce problème, j'ai créé une solution personnalisée qui vous permet d'intégrer n'importe quelle application, telle que le Bloc-notes, Adobe Reader ou Autodesk AutoCAD, sans qu'il soit nécessaire de déployer Office. Cette solution personnalisée montre également pourquoi l'intégration d'applications fondée sur des composants Office standard échoue dans certaines situations. Vous trouverez cette solution, ainsi que des instructions de déploiement et de configuration détaillées, dans les ressources associées à cet article, disponibles dans la section Téléchargement de code de Microsoft.com.

Intégration d'application Office

Du point de vue de l'utilisateur, les menus SharePoint semblent fonctionner comme le menu Démarrer de Windows®. Il est facile de créer un nouveau document dans une bibliothèque de documents : cliquez sur Nouveau, puis sur Nouveau Document et Microsoft Office Word 2007 démarre. Il est tout aussi facile de modifier un document existant. Passez le curseur sur le document, puis ouvrez le menu déroulant Edit Control Box (ECB) et cliquez sur Edition dans Word. Il vient rarement à l'esprit que vous avez lancé Word 2007 depuis une page Web via JavaScript, que vous exécutez l'application localement tandis que le document se trouve loin, dans une base de données SQL Server® et qu'un serveur Web existe dans le chemin d'accès aux données, comme illustré à la figure 1.

Figure 1 Utilisation d'un document Word dans SharePoint (cliquer sur l'image pour l'agrandir)

Malgré cette complexité, l'expérience utilisateur sur un poste de travail Windows avec Office System 2007 est continue. L'utilisation de documents dans une bibliothèque SharePoint fonctionne à peu près comme l'utilisation de fichiers locaux ou de fichiers sur un partage réseau.

Cependant, sur un poste de travail Windows non doté d'Office 2003 ou Office 2007, l'interface utilisateur est différente. Lorsque vous cliquez sur Nouveau document ou Edition dans Word, une boîte de dialogue vous informant qu'une application compatible avec Windows SharePoint Services n'est pas disponible s'affiche.

Ceci n'est pas vraiment surprenant. Plusieurs éléments doivent être présents pour fournir l'expérience unifiée des utilisateurs Office. SharePoint doit être conscient des types de contenus présents dans la bibliothèque de documents pour afficher les commandes désirées dans les menus Nouveau et BCE. Lorsque l'on clique sur ces commandes avec la souris, le code JavaScript doit s'exécuter pour lancer l'application associée, en utilisant le chemin menant au document. Cette partie n'est pas indépendante de la configuration des postes de travail parce que le code JavaScript s'exécute localement. En outre, l'application associée doit communiquer avec SharePoint pour lire, voire écrire, des fichiers. Il s'agit là des éléments que vous devez réunir si vous souhaitez intégrer vos applications avec SharePoint.

D'autre part, la communication entre SharePoint et le serveur de base de données est transparente pour l'application, de même que les processus d'indexation sur le serveur Web pour faciliter les recherches. C'est pour cette raison que je n'aborderai pas davantage ces aspects dans cet article, mais je vous recommande de consulter le Microsoft Filter Pack décrit dans l'article de la Base de connaissances Microsoft « Comment enregistrer Microsoft Filter Pack avec Windows SharePoint Services 3.0, » disponible à l'adresse support.microsoft.com/kb/946338. Portons à présent notre attention sur l'ajout de commandes, l'implémentation de composants côté client nécessaires et la simplification de la communication entre applications.

Extension de l'interface utilisateur SharePoint

De nombreuses options sont disponibles pour étendre l'interface utilisateur et les fonctionnalités SharePoint. Vous pouvez modifier la conception de vos sites, personnaliser les pages ASP.NET, développer des composants WebPart ou modifier le code JavaScript inclus dans WS et MOSS pour démarrer vos applications directement.

Rien ne vous empêche d'ouvrir le fichier Ows.js dans un éditeur de texte (le fichier se trouve dans le dossier COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\12\Template\Layouts\1033 sur vos serveurs frontaux SharePoint) et de modifier le fonctionnement des fonctions createNewDocumentWithProgIDCore, editDocumentWithProgIDNoUI et DispDocItem. Mais il y a une meilleure méthode qui ne nécessite pas la modification de la base de code WSS par des moyens non pris en charge : l'utilisation de types de contenus et de mappages de types de documents.

Dans mon article « Normalisez la gestion des données grâce aux types de contenu personnalisés » (voir TechNet Magazine, février 2008, technet.microsoft.com//fr-fr/magazine/cc194408.aspx), j'ai expliqué comment créer des types de contenu globaux et spécifiques pour gérer des documents et d'autres contenus dans des bibliothèques de documents et des listes SharePoint. Vous pouvez également consulter la feuille de travail Text Content Type.pdf dans les ressources associées à cet article, qui illustre comment créer un nouveau type de contenu pour des fichiers .text et associer ce type de contenu à une bibliothèque de documents. Résultat : vous pouvez sélectionner la commande Contenu de texte du menu Nouveau tout comme vous pouvez sélectionner la commande Document pour les documents Word (voir la figure 2).

Figure 2 Un type de contenu personnalisé dans l'interface utilisateur SharePoint (cliquer sur l'image pour l'agrandir)

Le menu BCE est également extensible. Vous vous attendiez peut-être à ce que le menu BCE reconnaisse les types de contenus, mais ce n'est pas comme ça que la version WSS actuelle implémente ce menu. En fait, vous devez enregistrer votre type de document dans Docicon.xml, qui se trouve dans le dossier %COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\12\Template\Xml sur chaque serveur frontal SharePoint.

En ajoutant le mappage de type de document suivant à la section <ByExtension> de Docicon.xml, par exemple, vous pousserez SharePoint à afficher la commande Edition du Bloc-notes (voir le fichier Text Content Type.pdf pour des instructions plus détaillées) :

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

Le paramètre Key identifie l'extension de nom de fichier, le paramètre Value définit l'icône du document à afficher dans l'interface utilisateur, le paramètre EditText définit la chaîne que SharePoint ajoute à la commande « Editer dans » et le paramètre OpenControl spécifie le ProgID d'un composant COM côté client. Il s'agit du ProgID que les fonctions JavaScript SharePoint transmettent vers un appel ActiveXObject (voir Ows.js pour plus de détails) pour instancier l'objet COM, qui peut être l'application elle-même ou un contrôle d'assistance qui démarre l'application en fonction du type de fichier associé.

Site Web des technologies et produits SharePoint

Notez que l'OpenControl appelé SharePoint.OpenDocuments se rapporte à un contrôle ActiveX® fourni avec des versions récentes d'Office (%PROGRAMFILES%\Microsoft Office\Office12\Owssupp.dll). Si ce fichier existe sur vos postes de travail et que l'icône de document spécifiée (paramètre Valeur) se trouve dans le dossier %COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\12\Template\Images sur vos serveurs SharePoint, vous aurez peut-être déjà accompli le plus gros du travail d'intégration nécessaire.

Le kit de développement logiciel Windows SharePoint Services 3.0 inclut des API côté client fournies avec Office 2007, y compris le contrôle OpenDocuments. Consultez la section « Références API côté client » à l'adresse msdn2.microsoft.com/ms440037.

Utilisation du contrôle Office OpenDocuments

Le contrôle OpenDocuments s'adresse aux besoins d'intégration d'application les plus essentiels, mais il nécessite Office 2003 ou Office 2007 et ses capacités sont un peu limitées. Les commandes du menu Nouveau ne marchent pas toujours et elles affichent parfois ce qui risque d'être des notifications d'utilisateur trompeuses.

Comme illustré à la figure 3, le contrôle OpenDocuments informe l'utilisateur que l'application requise n'est pas installée correctement ou que le fichier modèle ne peut pas être ouvert, mais aucun des deux n'est le cas. La fonctionnalité Editer dans pose également des problèmes. Le deuxième message d'erreur affiché au premier plan de la figure 3 est fréquent. C'est mon chouchou car il trompe même les experts SharePoint, mais je vous en dirai plus sur lui dans un moment.

Figure 3 Messages d'erreur trompeurs du contrôle OpenDocuments (cliquer sur l'image pour l'agrandir)

Néanmoins, le contrôle OpenDocuments est utile dans les environnements où des versions récentes d'Office sont installées sur tous les postes de travail. Entre autres choses, vous pouvez masquer vos types de contenu dans le menu Nouveau (affichez les Paramètres de la bibliothèque de documents, cliquez sur Modifier l'ordre et le type de contenu par défaut pour les nouveaux boutons et décochez la case Visible pour tous les types de contenus en question) pour que les utilisateurs n'obtiennent pas le premier message d'erreur. Vous pouvez également avoir une topologie de site simple afin d'éviter des problèmes de communication WebDAV, ceci élimine le second message d'erreur.

Communication avec SharePoint

Jusqu'ici, j'ai réussi à étendre l'interface utilisateur SharePoint et peut-être à lancer une application au moyen du contrôle OpenDocuments, mais mon application a toujours besoin d'une façon de communiquer avec SharePoint pour accéder aux données. Comme toujours, SharePoint prend en charge plusieurs méthodes pour y parvenir, telles que les extensions serveur pour Microsoft Office FrontPage®, les appels de procédure distante WSS, WebDAV et des services Web. En fait, des applications Office, notamment Word 2007, pourraient utiliser l'ensemble ou une partie de ces méthodes de communication, selon la façon dont vous accédez à un document, que ce soit par exemple via des dossiers Web, des périphériques réseau connectés ou l'interface utilisateur SharePoint.

Les méthodes de communication client/serveur SharePoint reposent toutes sur le protocole HTTP. Par exemple, Frontpage et les appels de procédure distante WSS utilisent tous des requêtes HTTP POST et HTTP GET dirigées vers des extensions ISAPI qui résident sur des serveurs SharePoint au sein du dossier %COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\12\ISAPI et de tous ses sous-dossiers.

L'une des extensions ISAPI les plus importantes est Owssvr.dll, qui implémente, entre autres choses, la fonctionnalité nécessaire pour travailler avec des listes et des bibliothèques de documents. La figure 4 montre la boîte de dialogue Enregistrer de SharePoint dans Word 2007 (à gauche) et dans un navigateur (à droite) ouvert directement par l'intermédiaire de la requête https://sharepoint/HR/Administration/_vti_bin/owssvr.dll?dialogview=FileSave&location=Shared%20Documents&FileDialogFilterValue=*.docx. Les similarités entre les deux captures d'écran sont évidentes.

Figure 4 La boîte de dialogue Enregistrer de SharePoint dans Word 2007 et dans Internet Explorer (cliquer sur l'image pour l'agrandir)

Autres extensions ISAPI importantes : Author.dll, qui implémente FrontPage et les appels de procédure distante WSS pour les opérations de modification côté client, telles que le téléchargement, le changement de nom et la suppression de documents ; Admin.dll pour gérer des sites et exécuter plusieurs autres tâches administratives ; et Shtml.dll pour prendre en charge les envois de formulaires HTML.

Il est généralement impossible d'ajouter la prise en charge de FrontPage et des appels de procédure distante WSS dans des applications existantes, telles que le Bloc-notes ou Adobe Reader, sans avoir accès au code source. Mais vous pourriez fournir l'installation de communication nécessaire au moyen de la fonctionnalité Client Web incluse dans Windows.

SharePoint prend également en charge WebDAV via Httpext.dll, qui réside dans le dossier %WINDIR%\System32\Inetsrv\, mais restons du côté client. Sur les ordinateurs exécutant Windows Server® 2008 ou Windows Vista®, la fonctionnalité Client Web est installée par défaut. Vous trouverez un service WebClient correspondant dans l'applet Services des Outils d'administration du Panneau de configuration. Sur Windows XP et Windows Server 2003, vous devez installer le Client Web de façon explicite. Dans tous les cas, assurez-vous que le service WebClient est lancé et que le type de démarrage est défini sur Automatique.

La figure 5 illustre l'architecture du Client Web. Le service WebClient est implémenté dans une DLL en mode utilisateur (Webclnt.dll) que le Gestionnaire de contrôle des services charge dans un processus hôte Svchost.exe. Webclnt.dll fournit l'interface Fournisseur de réseau pour les opérations autres que E/S (telles que l'authentification de l'utilisateur pour l'accès à WebDAV, le montage de sites SharePoint en tant que périphériques réseau, l'énumération de sites SharePoint, les listes et les bibliothèques de documents comme ressources réseaux et la déconnexion de lecteurs installés).

Figure 5 L'architecture du redirecteur client WebDAV (cliquer sur l'image pour l'agrandir)

Pour exécuter ce travail, Webclnt.dll communique avec un pilote du système de fichiers en mode noyau qui fournit la véritable fonctionnalité de redirecteur. Le pilote du redirecteur client WebDAV (Mrxdav.sys) est fondé sur le RDBSS, qui s'intègre avec le Gestionnaire d'E/S et d'autres composants du noyau pour fournir les services d'un système de fichiers distant. Mrxdav.sys implémente la fonction de communication WebDAV pour prendre en charge l'accès au niveau du système de fichiers à des sites et bibliothèques de documents SharePoint.

Le fait d'avoir accès à des sites et des bibliothèques de documents SharePoint par l'intermédiaire d'un redirecteur réseau élimine la nécessité d'une prise en charge de Frontpage et des appels de procédure distante WSS dans les applications utilisateur. Vous pouvez associer des périphériques réseau à des bibliothèques de documents (ex : net use x: http://wss/doclib/Shared%20Documents) et vous pouvez également accéder à des ressources SharePoint par des chemins UNC.

L'URL http://wss/doclib/Shared%20Documents correspond à \\wss\doclib\Shared%20Documents. Vous disposez donc de choix pour ouvrir un document dans une application. Vous pouvez par exemple ouvrir un document dans le Bloc-notes avec le chemin HTTP http://wss/doclib/Shared%20Documents/New%20Text%20Document.txt ou le chemin UNC \\wss\doclib\Shared%20Documents\New%20Text%20Document.txt.

Malheureusement, la fonctionnalité Client Web a plusieurs restrictions. Vous ne pouvez pas accéder à des propriétés personnalisées ou des applications Web qui utilisent des ports TCP personnalisés. Le Client Web fourni avec Windows Vista échoue également si l'utilisateur n'a pas accès à un site parent dans la hiérarchie, comme illustré dans WebDAV Access.pdf (voir les documents d'accompagnement).

Le chemin https://sharepoint/HR/Administration/Shared%20Documents/ inclut un site racine non existant (https://sharepoint). Pourtant, sans accès à la racine, le Client Web ne peut pas déterminer les fonctionnalités du serveur Web. Le serveur Web rejette la requête OPTIONS du Client Web avec le code d'état 401, qui établit que l'accès est non autorisé et, par conséquent, le Client Web continue de demander les informations d'identification de l'utilisateur, comme illustré à la figure 6, bien que l'utilisateur ait un accès administratif à l'ensemble des sites sharepoint/HR et tous les sites à l'intérieur.

Figure 6 Échec d'accès à WebDAV (cliquer sur l'image pour l'agrandir)

Lorsque vous utilisez le contrôle OpenDocuments, vous recevez le message d'erreur affiché à la figure 3 si le Client Web n'ouvre pas un document. L'application est disponible et le mappage de type de document est correct. C'est le document qui n'est pas accessible via le redirecteur WebDAV.

Implémentation d'une solution OpenControl personnalisée

En général, vous avez deux options pour résoudre les lacunes du Client Web. Vous pouvez attendre que Microsoft fournisse une version de Client Web mise à jour ou vous pouvez implémenter une solution OpenControl personnalisée qui peut gérer la situation actuelle. L'implémentation d'une solution OpenControl personnalisée n'est pas une tâche facile, mais elle élimine la nécessité d'avoir Office sur vos postes de travail, elle vous permet de gérer la commande Nouveau en plus de la commande Editer dans de façon pertinente et elle vous permet de traiter les situations dans lesquelles le Client Web échoue.

Si un de ces problèmes vous concerne, examinez le code source AppStart inclus dans les ressources associées. Il vous montre comment exposer les interfaces COM OpenControl dans un assembly Microsoft .NET Framework, que le code SharePoint JavaScript peut appeler. Le code source AppStart montre également une façon possible de vérifier l'accessibilité aux fichiers et de télécharger un fichier sur l'ordinateur local via HTTP si l'accès direct par WebDAV n'est pas possible. Enfin, le code source AppStart répond à la commande Nouveau en téléchargeant le modèle associé au type de contenu sur l'ordinateur local pour que l'utilisateur puisse commencer à traiter le document. Les feuilles de travail Text Content Type.pdf et Adobe Reader Support.pdf expliquent comment déployer cette solution OpenControl.

Le diagramme illustré à la figure 7 affiche l'architecture AppStart. Mon composant OpenControl personnalisé (appelé Biblioso.dll) expose deux interfaces COM identiques que SharePoint JavaScript appelle pour créer de nouveaux documents ou ouvrir des documents existants afin de les modifier (Biblioso.AppStart.2 et Biblioso.AppStart.3).

Figure 7 L'architecture AppStart (cliquer sur l'image pour l'agrandir)

Si un document est ouvert pour modifications, Biblioso.dll vérifie que le fichier existe et démarre l'application associée avec le chemin vers le document si le fichier est accessible directement par WebDAV. Si le fichier n'est pas accessible, Biblioso.dll démarre un serveur COM hors processus qui charge OpenDocsUtility.dll pour télécharger le fichier via HTTP et lancer l'application avec le chemin vers le document téléchargé.

Le serveur COM hors processus permet à la solution de sortir du processus Internet Explorer®, ce qui limite les téléchargements vers le dossier Fichiers Internet temporaires en mode protégé. Les utilisateurs doivent pouvoir télécharger des fichiers sans les restrictions de mode protégé et un serveur COM hors processus fonctionnant comme un broker d'application fournit cette option.

Le développement de serveurs COM hors processus dans .NET n'est pas pris en charge, donc j'ai basculé vers C/C++ pour cet exécutable. J'ai implémenté uniquement la boîte de dialogue Enregistrer sous minimale en C++. Pour que la solution reste la plus simple possible et pour garder une surcharge de développement basse, j'ai placé le code de téléchargement dans un assembly .NET (OpenDocsUtility.dll), que j'ai ensuite appelé par le biais d'une autre interface COM.

Pour faciliter le déploiement, j'ai ajouté un projet d'installation à la solution. Entre autres choses, la routine d'installation enregistre tous les composants COM et écrit des paramètres spécifiques à l'application dans HKEY_LOCAL_MACHINE\SOFTWARE\Biblioso\AppStart. Les paramètres les plus importants sont AllowedApps et AllowedFileTypes. La solution AppStart fonctionnera uniquement avec ces applications et types de fichiers que vous devez spécifier explicitement dans ces paramètres.

La routine d'installation crée également une stratégie d'élévation pour le serveur COM hors processus afin que Biblioso.dll dans le processus Internet Explorer puisse démarrer AppBrokerEngine.exe sans déclencher des avertissements de sécurité. Si vous aimeriez en savoir plus sur Internet Explorer en mode protégé et savoir comment le gérer dans le développement d'applications, je vous recommande vivement l'article de Marc Silbey et Peter Brundrett « Explication et utilisation du mode protégé dans Internet Explorer » disponible à l'adresse msdn2.microsoft.com/bb250462.

Lorsque vous examinez les composants AppStart, souvenez-vous que cette solution a été développée simplement pour montrer ce que l'on peut faire. Elle n'est pas encore prête pour les environnements de production. Le temps manquait pour optimiser le code et tester la solution à fond, ou pour documenter les fonctionnalités, en dehors des commentaires sur le code source.

Vous utilisez cette solution à vos risques et périls. Si vous aimeriez étudier le code source pour créer votre propre solution, commencez par AppStart.cs dans le projet de code Biblioso. Ce fichier implémente l'interface COM OpenControl et les points d'entrée pour les appels JavaScript depuis Ows.js.

Conclusion

WSS 3.0 et MOSS 2007 fournissent des fonctionnalités d'intégration d'applications étendues pour une expérience utilisateur transparente lorsque vous travaillez avec des documents et d'autres éléments dans des bibliothèques de documents et des listes SharePoint. Les applications de bureau dans Microsoft Office System 2007 l'illustrent très bien et il est possible d'atteindre le même niveau d'intégration et d'utilisabilité avec des applications autres qu'Office également.

Au cœur de l'architecture d'intégration d'applications se trouvent les composants COM, que les fonctions SharePoint JavaScript utilisent, avec le chemin du document, pour démarrer l'application. Microsoft Office System 2007 fournit plusieurs de ces composants COM, optimisés pour des besoins d'applications Office spécifiques, bien qu'il soit également possible de réutiliser le contrôle OpenDocuments d'Office pour intégrer des applications autres que Microsoft. Le contrôle OpenDocuments répond aux besoins les plus fondamentaux. Pour les exigences d'intégration d'applications plus avancées, vous pouvez implémenter un contrôle personnalisé.

L'intégration complète d'une application avec SharePoint signifie non seulement installer des composants IFilter et des icônes de documents pour étendre les capacités de recherche et d'affichage, mais elle implique également la création de types de contenus personnalisés et de mappages de types de documents sur les serveurs SharePoint pour fournir des commandes Nouveau et Editer dans appropriées dans l'interface utilisateur SharePoint. Ces commandes appellent des fonctions JavaScript qui appellent des méthodes exposées par un composant OpenControl. Le composant OpenControl doit également être disponible sur le poste de travail.

Autre pièce important du puzzle : le Client Web, inclus et installé par défaut sur Windows Vista. Le Client Web implémente un redirecteur WebDAV et un pilote du système de fichiers distants afin que n'importe quelle application puisse accéder à des ressources dans des listes et des bibliothèques de documents SharePoint, un peu comme les partages de fichiers sur le réseau. Bien que le Client Web fourni avec Windows Vista ait des défauts, il joue un rôle essentiel dans l'intégration d'applications.

La prise en charge WebDAV comble également les fossés entre des applications exécutées sur des postes de travail autres que Windows et SharePoint. La technologie de contrôle COM et ActiveX n'est généralement pas disponible sur ces systèmes d'exploitation, donc vous ne pouvez pas utiliser les composants OpenControl pour démarrer des applications automatiquement, mais la plupart des systèmes d'exploitation incluent des redirecteurs WebDAV pour que les utilisateurs puissent au moins accéder à des documents directement dans des bibliothèques de documents sans avoir à télécharger les fichiers sur les postes de travail locaux.

WSS 3.0 et MOSS 2007 sont les pierres angulaires de la réussite de Microsoft Office System 2007 et les utilisateurs d'applications Office tierces peuvent tirer parti de SharePoint de la même façon. Les capacités d'intégration s'étendent bien au-delà d'Office. En tirant pleinement parti de SharePoint, vous pouvez générer une plate-forme de solutions Office unifiée qui fournit la même expérience utilisateur pour Office et des logiciels tiers et, par conséquent, augmenter la productivité des professionnels de l'informatique.

Pav Cherny est un expert informatique et auteur spécialisé dans les technologies Microsoft pour la collaboration et la communication unifiée. Ses publications incluent des livres blancs, des manuels de produits et des livres avec un intérêt particulier pour les opérations informatiques et l'administration système. Pav est le président de Biblioso Corporation, une entreprise spécialisée dans la documentation gérée et les services de localisation.

Ressources supplémentaires