MSDN マガジン: 注目記事2010 時代の Office 文書のサーバー サイド開発技術更新日: 2010 年 7 月 30 日 この記事は オンライン版月刊技術情報誌 MSDN マガジンの中から特におすすめの記事を解説したものです。MSDN マガジンの本文は「SharePoint 2010 によるサーバー側での Word 文書のマージ」を参照してください。 従来、Web アプリケーション開発など、サーバー サイドで Office 文書の処理をおこなう場合、Office オートメーションが頻繁に使用されていました。しかし、その動作を想像するとおわかりの通り、サーバー上で Office のインスタンスを起動する際のセキュリティの課題、対話型セッションの問題、スケーラビリティの克服など、多くの課題をクリアしなければならず、実際にこの苦労に直面したプログラマーの方も多かったことでしょう。(なお、Office のサーバー サイド オートメーションは、推奨もサポートも行われていないので注意してください。) Office 2007 以降では、ご存じの通り、OpenXML により、こうした過去の悪夢から解放されました。 では、次のようなケースはどうでしょうか? 例えば、サーバー サイドで、Word 文書を元に PDF や XPS へ変換したい場合、あるいは、過去の Word ファイル (.doc) やリッチ テキスト フォーマット (.rtf) などの資産を変換したい場合です。あるいは、文書に埋め込まれた動的フィールドの再計算をおこないたい場合もあるでしょう。こうした顧客要求の前では、万能と思えた OpenXML も、「諸刃の剣」と化してしまいます。そして、あの Office オートメーションの悪夢の再来です。 しかし、Office オートメーションの使用を考える前に、少し待ってください。"2010" の時代になり、こうしたサーバー サイドの文書処理技術は、さらに進化を遂げています。 MSDN マガジン「SharePoint 2010 によるサーバー側での Word 文書のマージ」では、こうした現実の Word 文書のサーバー サイド プログラミング手法として、OpenXML による文書処理と Word Automation Services を組み合わせたサンプルを紹介しています。このサンプルが示しているように、Word Automation Services は、これまでの OpenXML の技術を塗り替えるものではなく、OpenXML が苦手とする上記のようなサーバー サイド固有のニーズを満たす技術として、OpenXML の技術を補完する "Better Together" の関係にあります。 関連リンクページのトップへ |