Extend SharePoint to Integrate Other Office Applications

[アーティクル]
08/25/2016

SharePoint の内部Office アプリケーションを統合する

Pav Cherny

Microsoft Windows SharePoint Services (WSS) 3.0 と Microsoft Office SharePoint Server (MOSS) 2007 は、2007 Microsoft Office system のデスクトップアプリケーションとシームレスに統合されており、これによって、ドキュメント、スプレッドシート、予定表、連絡先情報などを使用した共同作業を簡単に行うことができます。この非常にシームレスな統合が、

統一されたオフィスソリューションプラットフォームとしての 2007 Office system の機能を支えていると言えます。

このことは、主に Microsoft® Office テクノロジを使用してインフォメーションワーカーの生産性向上を図っている組織にとっては朗報です。ただし、多様な Office アプリケーションのポートフォリオを所有している組織には、最初から優れた相互運用性が提供されるわけではありません。必要な統合機能は 2007 Office system によって提供されますが、文書化されているインターフェイスやコンポーネントは非常に少ないので、対応できない状況もあります。このため、サードパーティベンダが SharePoint® テクノロジを自社のアプリケーションに組み込むのは困難であり、これらのベンダの顧客が統一された操作性をインフォメーションワーカーに提供するのはさらに困難です。

このコラムでは、Office アプリケーションが SharePoint とどのように統合され、どのようにして両者間の通信が行われるか、およびこの原則に基づいて、サードパーティ製のアプリケーションをどのようにして SharePoint と統合できるかについて説明します。ただし、その前に、シームレスな統合に必要なサーバー構成の設定、クライアント側コンポーネント、および通信プロトコルについて簡単に説明します。

これらの詳細を明らかにしたところで、SharePoint のサポートが組み込まれていないアプリケーションの統合について説明します。この作業は、通常のように IFilter コンポーネントを実装することによって、検索機能を拡張したり、SharePoint サーバーにカスタムアイコンを追加したりするだけにとどまりません。適切なアイコンによって検索機能を拡張して結果を返すだけでは、アプリケーションの完全な統合は実現されません。ユーザーが、これらのドキュメントを SharePoint ユーザーインターフェイス内から直接開くことができれば、より便利になります。

ここから話は複雑になります。ワークステーションに Office を展開していない場合はクライアント側コンポーネントが必要ですが、このコンポーネントは簡単には入手できません。また、Office が展開されていても、SharePoint サイトのトポロジと構成によっては、このコンポーネントが正しく動作しない場合があります。

今回、この問題を解決するために、Office を展開する必要なく、メモ帳、Adobe Reader、Autodesk AutoCAD など、任意のアプリケーションを統合できるカスタムソリューションを作成しました。このカスタムソリューションを使用すると、一部の状況で、標準的な Office コンポーネントに基づいてアプリケーションを統合できない理由もわかります。このソリューションと、その展開および構成方法に関する一連の手順は、このコラムの付属リソース (TechNet Magazine Web サイトのコードダウンロードセクションからダウンロードできます) として入手できます。

Office アプリケーションを統合する

ユーザーの観点から見ると、SharePoint のメニューは Windows® の [スタート] メニューのように動作します。ドキュメントライブラリ内で新しいドキュメントを作成する作業は単純で、[新規] をクリックし、[新しいドキュメント] をクリックすると、Microsoft Office Word 2007 が起動します。既存のドキュメントを編集する作業も同じく単純で、ドキュメント上にマウスポインタを移動し、編集コントロールボックス (ECB) ドロップダウンメニューを開いた後、[Word で編集] をクリックするだけです。ユーザーは、Web ページから JavaScript を使用して Word 2007 を起動したこと、アプリケーションをローカルで実行しているが、ドキュメントは遠隔地の SQL Server® データベースに格納されていること、および Web サーバーがデータアクセスパス内に存在することにはほとんど気が付きません (図 1 参照)。

図 1 SharePoint での Word 文書を使用した作業 (画像をクリックすると拡大表示されます)

このような複雑な動作が発生するにもかかわらず、2007 Office system がインストールされた Windows ワークステーションではシームレスなユーザーエクスペリエンスが提供されます。SharePoint ライブラリ内でのドキュメントを使用した作業は、ローカルファイルやネットワーク共有上のファイルを使用した作業に似ています。

ただし、Office 2003 や 2007 Office system がインストールされていない Windows ワークステーションでは、異なる UI が表示されます。[新しいドキュメント] や [Word で編集] をクリックすると、Windows SharePoint Services と互換性のあるアプリケーションを使用できないことを通知するダイアログボックスが表示されます。

これはそれほど驚くべきことではありません。統一感のある操作性を Office ユーザーに提供するには、いくつかの要素が連携する必要があります。まず、[新規] メニューと ECB メニューのコマンドを表示するには、ドキュメントライブラリ内で管理されているコンテンツタイプが SharePoint によって認識されなければなりません。また、これらのコマンドをクリックしたときに、関連付けられたアプリケーションを起動し、該当するドキュメントのパスをそのアプリケーションに渡す JavaScript コードが実行される必要があります。JavaScript コードはローカルで実行されるので、この動作はワークステーションの構成には依存しません。さらに、この関連付けられているアプリケーションは、ファイルを読み取ったり、場合によってはファイルにデータを書き込むために、SharePoint と通信する必要があります。アプリケーションを SharePoint と統合するには、これらすべての要素が連携しなければなりません。

一方、SharePoint とデータベースの通信や、検索速度の向上を目的として Web サーバー上で実行されるインデックス作成処理は、アプリケーションによって認識される必要はありません。このため、この記事ではこれらの側面について詳しく説明しませんが、マイクロソフトサポート技術情報の記事「Microsoft Filter Pack を Windows SharePoint Services 3.0 に登録する方法」(support.microsoft.com/kb/946338) で、Microsoft Filter Pack について確認しておくことをお勧めします。ではここからは、コマンドの追加、必要なクライアント側コンポーネントの実装、およびアプリケーションによって行われる通信の単純化について説明します。

SharePoint UI を拡張する

SharePoint のユーザーインターフェイスと機能は、さまざまな方法で拡張できます。たとえば、サイトのデザインを変更する、ASP.NET ページをカスタマイズする、Web パーツを開発する、WSS と MOSS に含まれている JavaScript コードを変更してアプリケーションを直接起動するなどの方法が考えられます。

Ows.js ファイル (SharePoint フロントエンドサーバーの COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\12\Template\Layouts\1033 フォルダにあります) をテキストエディタで編集したり、createNewDocumentWithProgIDCore、editDocumentWithProgIDNoUI、および DispDocItem 関数の動作を変更したりすることもできますが、このようにサポートを受けられない方法で WSS コードベースを変更しなくても済む方法があります。これには、ドキュメントタイプのマッピングとコンテンツタイプを使用します。

TechNet Magazine 2 月号の「カスタムコンテンツタイプを使用してデータ管理を標準化する」(technet.microsoft.com/magazine/cc194408.aspx) には、グローバルコンテンツタイプとサイト固有のコンテンツタイプを作成することによって、SharePoint ドキュメントライブラリおよびリスト内のドキュメントやその他のコンテンツを管理する方法が記載されています。また、この記事の付属リソースとして提供される Text Content Type.pdf ワークシートには、.text ファイル用の新しいコンテンツタイプを作成し、そのコンテンツタイプをドキュメントライブラリと関連付ける方法が記載されています。この方法を使用すると、Word 文書用のドキュメントコマンドを選択するときと同じように、[新規] メニューの [Text Content] (テキストコンテンツ) を選択できるようになります (図 2 参照)。

図 2 SharePoint UI に表示されたカスタムコンテンツタイプ (画像をクリックすると拡大表示されます)

同様に、ECB メニューも拡張可能です。ECB メニューがコンテンツタイプに対応していることを期待した方もいらっしゃると思いますが、WSS の現在のバージョンでは、そのような ECB メニューの実装は提供されていません。このため、Docicon.xml 内にドキュメントタイプを登録する必要があります。このファイルは、各 SharePoint フロントエンドサーバーの %COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\12\Template\Xml フォルダにあります。

たとえば、Docicon.xml の <ByExtension> セクションに、次のようなドキュメントタイプのマッピングを追加すると、SharePoint に [Edit in Notepad] (Notepad で編集) コマンドが表示されます (詳細な手順については、Text Content Type.pdf ファイルを参照してください)。

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

Key パラメータはファイル名拡張子を指定し、Value パラメータはユーザーインターフェイスに表示されるドキュメントアイコンを指定しています。また、EditText パラメータは、SharePoint の [～で編集] コマンド内に含まれる文字列を指定し、OpenControl パラメータはクライアント側 COM コンポーネントの ProgID を指定しています。SharePoint JavaScript 関数は、この ProgID を ActiveX オブジェクトの呼び出しに渡して、COM オブジェクトのインスタンスを作成します (詳細については、Ows.js を参照してください)。この COM オブジェクトは、アプリケーションそのものの場合もあれば、関連付けられているファイルの種類に基づいてそのアプリケーションを起動するヘルパコントロールの場合もあります。

SharePoint 製品およびテクノロジ Web サイト

SharePoint.OpenDocuments という名前の OpenControl は、Office の最新バージョンで提供される ActiveX® コントロール (%PROGRAMFILES%\Microsoft Office\Office12\Owssupp.dll) を参照することに注意してください。このファイルがワークステーション上に存在し、Value パラメータで指定されたドキュメントアイコンが SharePoint サーバーの %COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\12\Template\Images フォルダに格納されていれば、統合に必要な作業はほぼ完了します。

Windows SharePoint Services 3.0 SDK には、OpenDocuments コントロールなど、2007 Office system に付属しているクライアント側 API に関する情報が含まれています。詳細については、「クライアント側 API リファレンス」(msdn2.microsoft.com/ms440037) を参照してください。

Office OpenDocuments コントロールを使用する

OpenDocuments コントロールを使用すると、アプリケーションの統合に関する最も重要な要件に対処できますが、このコントロールは Office 2003 または 2007 Office system を必要とし、その機能にも若干の制限があります。[新規] メニューのコマンドは常に正しく機能するわけではなく、場合によっては、誤解を招く通知がユーザーに表示されることもあります。

OpenDocuments コントロールによって、必要なアプリケーションが正しくインストールされていないこと、またはテンプレートファイルを開くことができないことがユーザーに通知されます (図 3 参照) が、どちらの通知の内容も誤っています。また、"～で編集" 機能にも問題があります。図 3 の一番手前に表示されている 2 つ目のエラーメッセージは、よく見かけるメッセージです。私は、SharePoint の専門家でさえも誤解するこのメッセージを非常に気に入っています。詳細については、この後すぐに説明します。

図 3 OpenDocuments コントロールによって表示される誤解を招きやすいエラーメッセージ (画像をクリックすると拡大表示されます)

上記のような問題はありますが、Office の最近のバージョンがすべてのワークステーションにインストールされている環境では、OpenDocuments コントロールが役立ちます。特に大きなメリットは、コンテンツタイプを [新規] メニューに表示しないようにできることです。これを行うには、[Document Library Settings] (ドキュメントライブラリの設定) を表示し、[新規ボタンの順序と既定のコンテンツタイプの変更] をクリックして、問題のあるすべてのコンテンツタイプの [表示] チェックボックスをオフにします。この操作を行うと、ユーザーに 1 つ目のエラーメッセージが表示されなくなります。また、サイトのトポロジを単純に保つことによって、Web 分散オーサリングとバージョン管理 (WebDAV) 通信に関する問題を回避できるので、2 つ目のエラーメッセージも表示されなくなります。

SharePoint と通信する

この記事の前半では、SharePoint UI を拡張し、場合によっては OpenDocuments コントロールを使用してアプリケーションを起動しましたが、このアプリケーションには、SharePoint と通信して、SharePoint のデータにアクセスする方法も必要です。SharePoint では、この操作を行う方法も複数サポートされています。たとえば、Microsoft Office FrontPage® Server Extensions、WSS リモートプロシージャコール (RPC)、WebDAV、Web サービスを利用できます。実際に、Word 2007 などの Office アプリケーションでは、ドキュメントへのアクセス方法に応じて、これらのうちいくつかまたはすべての通信方法が使用されます。このアクセス方法には、Web フォルダ、割り当て済みのネットワークドライブ、SharePoint UI などがあります。

SharePoint クライアントと SharePoint サーバーの間で通信を行う場合、必ず HTTP プロトコルが基盤として使用されます。たとえば、FrontPage および WSS RPC では、SharePoint サーバーの %COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\12\ISAPI フォルダとそのサブフォルダ内にある ISAPI 拡張への HTTP POST および HTTP GET 要求が使用されます。

最も重要な ISAPI 拡張の 1 つは、リストとドキュメントライブラリを操作する機能が実装された Owssvr.dll です。図 4 は、SharePoint の保存ダイアログボックスが Word 2007 に表示された画面 (左側) と、同じダイアログボックスが URL 要求 https://sharepoint/HR/Administration/_vti_bin/owssvr.dll?dialogview=FileSave&location=Shared%20Documents&FileDialogFilterValue=*.docx を通じてブラウザ内で直接開かれた画面を示しています。2 つの画面が似ていることがおわかりいただけると思います。

図 4 Word 2007 と Internet Explorer に表示された SharePoint の保存ダイアログボックス (画像をクリックすると拡大表示されます)

その他の重要な ISAPI 拡張には、ドキュメントのアップロード、名前変更、削除といったクライアント側の編集操作を行うための FrontPage および WSS RPC が実装された Author.dll、サイトを管理したり、その他の多くの管理タスクを実行するための Admin.dll、HTML フォームの送信をサポートするための Shtml.dll などがあります。

一般に、ソースコードにアクセスすることなく、FrontPage および WSS RPC のサポートを追加して、メモ帳や Adobe Reader などの既存のアプリケーションをサポートすることは不可能です。ただし、Windows に含まれている Web クライアント機能を使用して、必要な通信機能を提供できます。

SharePoint でも、Httpext.dll を通じて WebDAV がサポートされます。このファイルは %WINDIR%\System32\Inetsrv\ フォルダに格納されていますが、ここではクライアント側の視点から説明します。Windows Server® 2008 または Windows Vista® を実行しているコンピュータには、既定で Web クライアント機能がインストールされています。コントロールパネルの [管理ツール] で [サービス] アプレットを開くと、対応する WebClient サービスを確認できます。Windows XP と Windows Server 2003 には、Web クライアントを明示的にインストールする必要があります。いずれの場合も、WebClient サービスを開始し、[スタートアップの種類] を [自動] に設定するようにしてください。

図 5 は、Web クライアントのアーキテクチャを示しています。WebClient サービスは、ユーザーモード DLL (Webclnt.dll) 内に実装されており、Svchost.exe ホストプロセス内でサービスコントロールマネージャによって読み込まれます。Webclnt.dll では、I/O 以外の操作 (たとえば、WebDAV に準拠したアクセスを実行するユーザーを認証する、SharePoint サイトをネットワークドライブとしてマウントする、SharePoint サイト、リスト、およびドキュメントライブラリをネットワークリソースとして列挙する、マウントされたドライブの接続を解除する) を行うためのネットワークプロバイダインターフェイスが提供されます。

図 5 WebDAV クライアントリダイレクタのアーキテクチャ (画像をクリックすると拡大表示されます)

Webclnt.dll は、この操作を完了するために、実際のリダイレクタ機能を提供する、カーネルモードのファイルシステムドライバと通信します。WebDAV クライアントリダイレクタドライバ (Mrxdav.sys) は、Redirected Drive Buffering Subsystem (RDBSS) に基づいており、I/O マネージャとその他のカーネルコンポーネントと連携して、リモートファイルシステムのサービスを提供します。また、Mrxdav.sys には WebDAV 通信機能が実装されており、これによって、SharePoint サイトおよびドキュメントライブラリへのファイルシステムレベルのアクセスがサポートされます。

ネットワークリダイレクタを経由して SharePoint サイトおよびドキュメントライブラリにアクセスできるので、ユーザーアプリケーションで FrontPage および WSS RPC をサポートする必要がなくなります。また、ネットワークドライブをドキュメントライブラリにマップしたり (net use x: http://wss/doclib/Shared%20Documents など)、UNC パスを使用して SharePoint リソースにアクセスしたりできるようになります。

URL http://wss/doclib/Shared%20Documents は、\\wss\doclib\Shared%20Documents にマップされます。このため、アプリケーション内でドキュメントを開くときに、複数の選択肢が提供されます。たとえば、あるドキュメントをメモ帳で開くときに、HTTP パス http://wss/doclib/Shared%20Documents/New%20Text%20Document.txt を使用することも、UNC パス \\wss\doclib\Shared%20Documents\New%20Text%20Document.txt を使用することもできます。

残念ながら、Web クライアント機能にはいくつか制限があります。カスタムプロパティや、カスタム TCP ポートを使用する Web アプリケーションにアクセスすることはできません。また、ユーザーが階層内の親サイトにアクセスできない場合、Windows Vista に付属している Web クライアントの処理は失敗します。詳細については、付属リソースの WebDAV Access.pdf を参照してください。

パス https://sharepoint/HR/Administration/Shared%20Documents/ には、存在しないルートサイト (https://sharepoint) が含まれていますが、Web クライアントは、このルートにアクセスできなければ Web サーバーの機能を特定できません。Web サーバーは、Web クライアントの OPTIONS 要求を拒否し、アクセスが承認されなかったことを示す状態コード 401 を返します。その結果、ユーザーがサイトコレクション sharepoint/HR とそのコレクション内のすべてのサイトに管理者としてアクセスできるにもかかわらず、Web クライアントはユーザーの資格情報を要求し続けることになります (図 6 参照)。

図 6 WebDAV に準拠したアクセスの失敗 (画像をクリックすると拡大表示されます)

Web クライアントが、OpenDocuments コントロールを使用してドキュメントを開くことができなかった場合、図 3 のようなエラーメッセージが表示されます。このアプリケーションは使用可能であり、ドキュメントタイプのマッピングも適切に実装されています。つまり、WebDAV リダイレクタを経由してもアクセスできないドキュメントが存在します。

カスタム OpenControl ソリューションを実装する

一般に、Web クライアントの欠点に対処する方法は 2 つあります。それは、更新された Web クライアントのバージョンがマイクロソフトから提供されるのを待つか、現在の状況に対処できるカスタム OpenControl ソリューションを実装することです。カスタム OpenControl の実装は簡単な作業ではありませんが、これによって、ワークステーションに Office をインストールする必要がなくなります。また、[新規] メニューの [～で編集] 以外のコマンドでも便利な動作を提供したり、Web クライアントの処理が失敗する状況に対処したりできます。

これらの効果に魅力を感じた方は、付属リソースに含まれている AppStart のソースコードを参照してください。このコードは、Microsoft .NET Framework アセンブリに OpenControl COM インターフェイスを公開し、このインターフェイスを SharePoint JavaScript コードから呼び出すことができるようにします。また、ファイルにアクセスできるかどうかを確認し、WebDAV を経由して直接アクセスできない場合は、HTTP を経由してそのファイルをローカルコンピュータにダウンロードします。さらに、[新規] メニューのコマンドから発行された要求に応じて、該当するコンテンツタイプに関連付けられたテンプレートをローカルコンピュータにダウンロードし、ユーザーがそのドキュメントを使用して作業を開始できるようにします。Text Content Type.pdf および Adobe Reader Support.pdf ワークシートには、この OpenControl ソリューションを展開する方法の概要が記載されています。

図 7 は、AppStart のアーキテクチャを示しています。カスタム OpenControl コンポーネント (Biblioso.dll) は、まったく同じ 2 つの COM インターフェイスを公開します。SharePoint JavaScript は、これらのインターフェイスを呼び出して、新しいドキュメントを作成したり、編集用に既存のドキュメントを開いたりします。

図 7 AppStart のアーキテクチャ (画像をクリックすると拡大表示されます)

編集用にドキュメントを開く場合、Biblioso.dll は、そのドキュメントが存在するかどうかを確認し、ドキュメントに関連付けられているアプリケーションを起動します。WebDAV を経由してドキュメントに直接アクセスできる場合は、そのドキュメントのパスを指定してアプリケーションを起動します。ドキュメントにアクセスできない場合、Biblioso.dll は、アウトプロセス COM サーバーを起動し、OpenDocsUtility.dll を読み込みます。OpenDocsUtility.dll は、HTTP 経由でドキュメントをダウンロードし、ダウンロードしたドキュメントのパスを指定してアプリケーションを起動します。

このアウトプロセス COM サーバーを使用すると、ソリューションを Internet Explorer® とは異なるプロセスで実行できます。保護モードの Internet Explorer のプロセスでは、インターネット一時フォルダへのダウンロードが制限されますが、ユーザーは、保護モードの制限を受けることなくファイルをダウンロードできる必要があります。アプリケーションブローカとして機能するアウトプロセス COM サーバーによって、この動作が可能になります。

.NET で動作するアウトプロセス COM サーバーの開発はサポートされていないので、C と C++ を使用してこの実行可能ファイルを作成することにしました。C++ では、必要最小限の [名前を付けて保存] ダイアログボックスのみを実装しました。ソリューションをできるだけ単純に保ち、開発作業のオーバーヘッドを低く抑えるために、.NET アセンブリ (OpenDocsUtility.dll) 内に実際のダウンロードコードを配置し、別の COM インターフェイスから呼び出すことができるようにしました。

また、簡単に展開作業を行うことができるように、セットアッププロジェクトをソリューションに追加しました。特に重要なのは、このセットアップルーチンが、HKEY_LOCAL_MACHINE\SOFTWARE\Biblioso\AppStart にすべての COM コンポーネントを登録し、アプリケーション固有の設定を書き込むことです。最も重要なパラメータは、AllowedApps と AllowedFileTypes です。AppStart ソリューションは、これらのパラメータで明示的に指定されたアプリケーションとファイルの種類のみを処理します。

このセットアップルーチンでは、アウトプロセス COM サーバーの昇格ポリシーも作成されるので、Internet Explorer のプロセス内で実行される Biblioso.dll は、セキュリティ警告を表示させることなく、AppBrokerEngine.exe を起動できます。Internet Explorer の保護モードについて、およびアプリケーション開発でこの動作モードに対処する方法については、Marc Silbey と Peter Brundrett によって執筆された「保護モードの Internet Explorer の理解と機能」(msdn2.microsoft.com/bb250462) を参照してください。

AppStart のコンポーネントを使用するときは、このソリューションが単なるデモンストレーション用に開発されたものであり、運用環境では使用できないことに注意してください。今回は時間が足りなかったので、徹底的にコードを最適化し、ソリューションをテストすることも、ソースコード内のコメント以外にドキュメントを用意することもできませんでした。

このソリューションは、各自の責任で実行してください。独自のソリューションを作成するために、このソースコードの内容を確認するには、まず Biblioso コードプロジェクトの AppStart.cs を開きます。このファイルには、OpenControl COM インターフェイスと、Ows.js からの JavaScript 呼び出しに使用するエントリポイントが実装されています。

まとめ

WSS 3.0 と MOSS 2007 によって提供される、拡張性の高いアプリケーションの統合機能を使用すると、ユーザーが SharePoint ドキュメントライブラリおよびリスト内のドキュメントやその他の項目を使用して作業するときに、シームレスな操作性が提供されます。この効果は 2007 Office system のデスクトップアプリケーションで顕著に表れますが、Office 以外のアプリケーションでも同程度の統合とユーザビリティを提供できます。

アプリケーションの統合機能のアーキテクチャにおいて中核となるのは、COM コンポーネントです。SharePoint JavaScript 関数は、これらのコンポーネントを使用し、ドキュメントのパスを指定して、アプリケーションを起動します。2007 Office system では、特定の Office アプリケーションの要件に合わせて最適化された、いくつかの COM コンポーネントが提供されますが、Office OpenDocuments コンポーネントを再利用して、マイクロソフト以外のアプリケーションを統合することもできます。OpenDocuments コントロールによって、最も基本的な要件は満たされます。アプリケーションの統合要件がさらに複雑な場合は、カスタムコントロールを実装します。

アプリケーションを完全に SharePoint と統合するには、IFilter コンポーネントとドキュメントアイコンをインストールして検索および表示機能を拡張するだけでなく、SharePoint サーバー上にカスタムコンテンツタイプとドキュメントタイプのマッピングを作成して、SharePoint ユーザーインターフェイスで適切な [新規] メニューのコマンドと [～で編集] コマンドを提供する必要があります。これらのコマンドによって呼び出された JavaScript 関数は、OpenControl コンポーネントを通じて公開されたメソッドを呼び出します。この OpenControl コンポーネントは、ワークステーション上でも使用できる必要があります。

もう 1 つの重要な要素は、Windows Vista に既定で提供およびインストールされる Web クライアントです。この Web クライアントには、WebDAV リダイレクタおよびリモートファイルシステムドライバが実装されているので、どのアプリケーションでも、ネットワーク上のファイル共有に似た SharePoint リストおよびドキュメントライブラリ内のリソースにアクセスできます。Windows Vista に付属している Web クライアントには欠点もありますが、この Web クライアントはアプリケーションの統合にとって重要な役割を果たします。

WebDAV のサポートによって、Windows 以外のワークステーション上で実行されるアプリケーションと SharePoint の相互通信も可能になります。通常、COM および ActiveX コントロールテクノロジは、これらのオペレーティングシステム上では提供されないので、OpenControl コントロールを使用しても自動的にアプリケーションを起動できませんが、ほとんどのオペレーティングシステムには WebDAV リダイレクタが含まれているので、ユーザーは少なくとも、ドキュメントライブラリ内のファイルをローカルのワークステーションにダウンロードすることなく、これらのファイルに直接アクセスできます。

WSS 3.0 と MOSS 2007 は、2007 Office system の成功を支えるソリューションであり、サードパーティ製の Office ベースのアプリケーションを使用するユーザーは、2007 Office system を使用した場合と同様のメリットを SharePoint から得ることができます。この統合機能によって、Office のメリットがさらに増幅します。SharePoint を最大限に活用することによって、Office とサードパーティ製のソフトウェアで同様のユーザーエクスペリエンスを提供する、統一されたオフィスソリューションを構築でき、その結果、インフォメーションワーカーの生産性を向上させることができます。

Pav Cherny は、主にコラボレーションとユニファイドコミュニケーションに関するマイクロソフトテクノロジを扱う IT 専門家であり、IT 関連書籍の執筆も行っています。これまでに、IT の運用とシステム管理についてのホワイトペーパー、製品マニュアル、書籍などを執筆してきました。Pav は、ドキュメント管理とローカライズサービスの専門企業 Biblioso Corporation の代表取締役です。

目次

その他のリソース