Enterprise 2.0アプリケーションの構築

はじめに

苛烈な競争をきわめる今日のグローバル経済において、変化に対応する際の俊敏性はかつてないほど重要になっています。 今や、情報とそれに関わるインタラクションは、ほとんどの企業にとって重要資産であり、短縮し続けるサイクルタイム内で適切な意思決定をおこなうことが、成功する企業を決定づける経営特性となりました。 適切な情報へアクセスし、その情報を適切なタイミングで適切なユーザーに届けることが市場で不可欠となったことで、ソーシャル・エンタープライズ機能の構築への関心が高まり、ソーシャルWebがその探求における中心となりました。

コラボレーションの促進と従業員の生産性向上を目的として、このようなソーシャル・コラボレーション・ツールが企業で導入されるにつれて、このツールがオペレーショナル・エクセレンスの獲得にとって計り知れないほど有益であることも認識されるようになりました。 組織のシステムやプロセスに顧客からアクセスできるようにする際、Enterprise 2.0はきわめて重要な役割を果たします。 このレベルで顧客との継続的なコラボレーションが確立できれば、顧客がカスタマー・サポートへ問い合わせる回数を減らせるため、企業にとってはコストの節約につながり、顧客の満足度も高くなります。

では、どのようにしてEnterprise 2.0アプリケーションの構築に取りかかればよいのでしょうか。 重要なことは、単にWeb 2.0アプリケーションを構築すればよいわけではないと理解することです。 経営コンサルタントのMcKinsey & Companyによれば、Web 2.0プロジェクトは草の根の実験と見なされることが多く、"作りさえすれば、自然に利用される"という考え方にならって、経営陣が介入しなくてもこのテクノロジーは採用されるだろうと考えるリーダーもいます。 対照的に、Enterprise 2.0アプリケーションは事業目標を達成するためのものであり、社内（IT部門、事業部門）および社外（顧客、パートナー）の利害関係者による支援を必要とします。 Enterprise 2.0のテクノロジー戦略は、Web 2.0機能のさまざまな側面を組み合わせてセキュアな包括的プラットフォームを構築するものであり、事業目標に照らして、ビジネスに関する対話やタスクが実行されなければなりません。 また、高度なユーザー・エクスペリエンスを推進および実現し、もっともセキュアな方法でエンタープライズ・コンテンツを公開します。 Enterprise 2.0アプリケーションには、コンテンツ管理、セキュリティ、検索、そしてWeb 2.0の機能が結集されています。 Enterprise 2.0アプリケーションでは、ERPアプリケーション、CRMシステム、そのほかのバックエンド・エンタープライズ・アプリケーションから情報が収集され、コンテキストに基づいて、セキュアかつ見つけやすい方法でこれらの情報が提供されます。

この記事では、Enterprise 2.0アーキテクチャの主要な構成要素について説明し、Enterprise 2.0アプリケーションを構築する際の、統合に関する重要な考慮事項を示します。 最後に、Wind Riverによる、オラクルのEnterprise 2.0プラットフォームを利用したオンライン・カスタマー・サポート・ポータルの改良事例について説明します。

Enterprise 2.0の構成要素

Enterprise 2.0は、さまざまな規律、テクノロジー、そしてエクスペリエンスをまとめたビジネス戦略です。 リッチなEnterprise 2.0に必要とされる基本的機能は、コンテンツ管理、Web 2.0フレームワーク、セキュリティ、およびエンタープライズ・アプリケーションとの統合機能です。

図1： Enterprise 2.0の構成要素

コンテンツ管理 — 組織は、あまり意識していなくても構造化データと非構造化データを扱っています。 構造化データには、文書、ファイル、ビデオが含まれ、おもに社内で作成されます。 非構造化データは、おもに顧客とのインタラクションから生成され、ブログ記事、Wiki項目、チャット・スクリプトなどが含まれます。 コンテンツ管理プラットフォームは一貫性のある単一インフラストラクチャを提供することで、統一した方法で、データを管理、公開、提供します。

Web 2.0フレームワーク — コンテンツ管理プラットフォームはコンテンツの作成および管理に対応しますが、Web 2.0フレームワークは、コラボレーティブ・プラットフォームを提供して、きわめてコラボレーティブな方法でエンタープライズ・データを公開する機能を通じて、リッチなインタラクションを可能にします。 Web 2.0プラットフォームのソーシャル特性を考慮すると、このコラボレーティブなプレゼンテーション・レイヤーは、ユーザー・フレンドリーでナビゲートしやすいだけでなく、単一プレゼンテーション・レイヤーでありながら、マルチチャネル（PC、モバイル・デバイス、PDAなど）からアクセスできる点が重要です。 そして、もっとも重要な点は、インスタント・メッセージング、音声対話、Wiki、ブログ、コミュニティ、タグ付け、ユーザー評価、パーソナライゼーションなどのサービスを通じて、Web 2.0フレームワークがユーザーとシステムによる対話型の参加を実現していることです。

セキュリティ — Enterprise 2.0システムは、セキュリティを最優先事項とする企業を念頭に置いて構築しなければなりません。 とくに、Enterprise 2.0ソリューションがきわめてアクセスしやすく、高度にインタラクティブな性質をもつ点を考慮すると、コンテンツの公開とパーソナライズによって非常に特殊なセキュリティ上の課題を突きつけられます。 コンテンツを公開および編集できるのは誰か。 時間が経つと、コンテンツはどうなるか。 どのユーザー・ロールベースの制限をコンテンツに割り当てるか。 Enterprise 2.0は、安全で、セキュアで、監査可能で、制御可能でなければなりません。 セキュリティ・レイヤーは、認証および認可機能を提供し、ユーザー・ロールおよびIDに基づいてコンテンツをパーソナライズし、コンテンツのライフ・サイクルを通じて完全な監査証跡を実現し、コンテンツの公開と監視を制御します。

統合 — Enterprise 2.0では、ERPアプリケーション、CRMシステム、そのほかのバックエンド・エンタープライズ・アプリケーションから情報が取得され、コンテキストを維持したセキュアな方法でエンドユーザーに提示されます。 ユーザーは、エンタープライズ・アプリケーションから取得したデータ、またはエンタープライズ・アプリケーションに格納されるデータでコラボレーションします。 したがって、データとビジネス・フローを編成する複数のエンタープライズ・アプリケーションを統合し、コンテンツ管理レイヤーでこのデータをマージし、Web 2.0のフロントエンドを使用してエンドユーザーにデータを提示する必要があります。

Enterprise 2.0の統合

複数の異なる製品で構成される多くのテクノロジー層では、レイヤー間で問題なくインタラクションが実行できることが重要になります。 業界標準に沿ってEnterprise 2.0フレームワークを構築すると、最小限のコード変更だけで相互運用性が確保できます。 プラットフォームが標準に準拠していれば、柔軟な設計アーキテクチャが保証されるため、将来的にEnterprise 2.0環境を拡張でき、必要に応じて新機能を組み込むことも容易になります。 では、Enterprise 2.0アプリケーションを構築する場合の、統合に関する重要な考慮事項について確認していきましょう。

図2： Web 2.0、コンテンツ管理、SOA、セキュリティ・レイヤー間でのEnterprise 2.0統合

コンテンツ管理とWeb 2.0レイヤーの統合
コンテンツ管理レイヤーから取得したコンテンツをリッチUIに表示する最善の方法は何でしょうか。 ポータルや基盤となるコンテンツ管理フレームワークに依存しない柔軟なEnterprise 2.0アーキテクチャを開発することができるのでしょうか。 幸いにも、標準を利用することで、統合に伴う困難を大幅に軽減できます。 JCR（Java Content Repository、JSR-170）標準に対応したコンテンツ管理システムには、アーキテクチャ上の柔軟性が備わっています。 JSR-170に準拠したコンテンツ管理システムには、任意のコンテンツ・リポジトリへの接続に使用できる標準APIを使用することによってアクセスが可能です。 これにより、Web 2.0レイヤーは、基盤となるコンテンツ管理プラットフォームに依存しなくなります。 つまり、Web 2.0レイヤーは、統合機能をハードコーディングしなくても、複数の異なるコンテンツ・リポジトリに接続できます。

同様に、Java Portlet Specification（JSR-168、およびその後継であるJSR-286）とWSRP(Web Services for Remote Portlets）は、異なるポータル・ベンダー間での相互運用を可能にします。 JSR-168とWSRPに準拠しているポートレットは依存関係をもたないビジネス・オブジェクトへ変換され、異なるEnterprise 2.0アプリケーション間で共有できるため、再利用が促進されます。

コンテンツ管理レイヤーおよびWeb 2.0レイヤーでの認証
Web 2.0レイヤーとコンテンツ管理レイヤーはともに、ユーザー・プロファイルに基づいてアクセスを制御する必要があります。 したがって、Web 2.0レイヤーとコンテンツ管理レイヤーの構成には、シングル・サインオンを使用した認証とLDAPプロバイダによるIDストアが必要です。 J2EEのセキュリティ制限を越えて、アプリケーションによるユーザー認証と認可適用を実現するためにもっとも重要な標準は、Java Authentication and Authorization Service（JAAS）です。これは、Java Community ProcessによってJava言語に追加された、セキュリティに関する標準アプリケーション・プログラミング・インタフェース（API）です。

SOAを使用したエンタープライズ・アプリケーションとWeb 2.0レイヤーの統合
SOAは、BPEL（Business Process Execution Language）を使用したビジネス・プロセス・オーケストレーションを実現する手段としての役割を果たします。 BPELは、各種のバックエンド・アプリケーションとユーザー間でのWebサービスに基づく統合を自動化します。 Web 2.0レイヤーとSOAレイヤー間では、双方向の統合が実現されます。 Web 2.0レイヤーを使用するユーザーは、BPELプロセスを直接呼び出すことで、重要なビジネス・プロセスを開始したり、進行させたりすることができます。 一方で、SOAは、コンテキスト依存のエンタープライズ・データをWeb 2.0レイヤーに提供します。

ここまで、Web 2.0機能を使用してECM（エンタープライズ・コンテンツ管理）ソリューションを強化する際の、アーキテクチャ上の原則について説明してきました。次に、これらの設計原則を適用した実際のアプリケーション（Wind River Systemsのオンライン・カスタマー・サポートWebサイト）について確認していきましょう。

Wind Riverにおける、オンライン・カスタマー・サポートへのEnterprise 2.0の適用

デバイス・ソフトウェアの最適化（DSO）におけるマーケット・リーダーであるWind Riverは、30,000名を超える従業員および顧客によって使用されているオンライン・サポート・システム（OLS）のネットワーク全体を通じて、情報交換およびコラボレーションを抜本的に簡素化したいと考えていました。

当初のOLSは、開発およびデリバリ向けの統一プラットフォームを提供して、従業員、顧客、パートナーを支援することを目的として設計されました。 OLSの初期目標は、顧客およびパートナーがパーソナライズされたサポート・データへセルフサービスでアクセスして、サービス・リクエストを登録し、製品の欠陥およびパッチ情報を見つけられるようなプラットフォームを提供することでした。 また、同じプラットフォームを使用して、従業員（サポート、製品管理、技術文書、エンジニアリングなどの部門）がコラボレーティブにコンテンツを提供し、そのコンテンツを顧客と共有できるようにする必要がありました。 しかし、残念ながら、初期のOLSシステムはこれらの要件を満たすことができませんでした。 機能もインフラストラクチャも不十分であったため、特定のユーザーをターゲットとしたコンテンツを表示することはできなかったのです。

このOLSインフラストラクチャは、PHPおよびPerlを使用した各種CGIアプリケーションをベースとしたものであり、これらのアプリケーションはOracle E-Business Suiteやファイルベース・システム、データベース・システムなどの多様なシステムからコンテンツを取得していました。 このため、サポートされるすべてのコンテンツ（サポート・マニュアル、技術的ヒント、FAQ、How-Toガイドなど）が一元管理されていませんでした。 公開プロセスは完全に手動に依存しており、エンジニアリング、製品管理、OLSスタッフ間での複雑な調整が必要でした。 リポジトリが一元管理されておらず、ドキュメントを動的に更新することもできなかったため、Wind Riverのサポート組織にとってメンテナンスは悪夢のようなものでした。 データ整合性を維持しながら、顧客へ最新情報を提供するまでの時間を最小化することは、大きな課題でした。

もう1つの苦情として顧客から寄せられていたのは、Wind Riverから購入した製品に関連するOLSコンテンツを見つけることが非常に難しいという意見でした。 この問題を解決するためのWind Riverの構想は、顧客ごとにOLSコンテンツをパーソナライズして、購入済み製品に関連するコンテンツを表示するというものでした。

しかし、この時点で、製品およびサポートに関するコンテンツと顧客が購入した製品を結びつけるインフラストラクチャは存在しませんでした。 このため、顧客の製品インストール・ベースと顧客が探しているコンテンツを関連づけることは困難でした。 このように、コンテンツが一元管理されておらず、エンタープライズ・システムとの統合が不十分であることは、顧客のユーザー・エクスペリエンスに悪影響を及ぼしていました。 顧客は、必要なサポート・データを見つけるために、Wind Riverの元のOLS Webサイトを独力で検索およびナビゲートしなければなりませんでした。 また、顧客とWind Riverのサポート・スタッフがリアルタイムでやり取りすることで、素早く問題を解決するようなコラボレーティブ・インフラストラクチャは提供されていませんでした。

上記の問題を解決するため、Wind RiverはEnterprise 2.0によるアプローチを採用しました。 コンテンツ・リポジトリにサポート・コンテンツを一元管理し、Web 2.0インタフェースを利用して、コンテンツ・リポジトリおよびそのほかのエンタープライズ・システムから取得したコンテンツをターゲット化して提供することが決定されました。 具体的には、どのようにこれを達成したのでしょうか。 ここからは、アーキテクチャについて確認していきましょう。

図3： Wind Riverオンライン・カスタマー・サポートのEnterprise 2.0アーキテクチャ

コンテンツ管理

Wind Riverは、製品関連ドキュメント、パッチ、デモ、デジタル資産、イメージ・ファイル、およびビジネス・プロセス要件を一元管理するために、Oracle Universal Content Management（Oracle UCM）を選びました。 Oracle UCMは、オンライン・サポート・ポータル上で、3,000から5,000個の物理ファイルと約78,000個のデジタル・ファイルを管理するために使用されることになりました。

図4： Oracle UCMレイヤーによる、コンテンツ管理の集中化とコンテンツ公開の簡素化

Oracle UCMは、カスタマー・デリバリ・プラットフォームを一元化する基盤を構築するだけでなく、コンテンツの公開プロセスを簡素化します。 また、承認および公開の内部フレームワークを構築することで、OLSコンテンツ（マニュアル、パッチ、デモなど）の実際の所有権を、ITやオンライン・サポートの各管理者からコンテンツの作者（製品管理、エンジニアリング、技術文書など）へと移します。 これにより、コンテンツ提供プロセスにおいて、コンテンツ処理上の非効率性が軽減され、総合的なデータ整合性が向上します。

Web 2.0

OLSのフロントエンドは、Oracle WebCenterを使用して実装されました。 Oracle WebCenterには、Enterprise 2.0に対応したコラボレーティブなソーシャル・アプリケーションを構築する独自機能が含まれており、検索、公開、そしてナレッジ・マネジメントがシームレスに結合されています。 Oracle WebCenterは、J2EE、JavaServer Faces（JSF）、およびOracle Application Development Framework（Oracle ADF）などのテクノロジーを基盤としています。 Oracle ADFコンポーネントとポートレットを組み合わせて使用することで、ユーザー・インタフェースのフロントエンドが構築されます。 コンポーネントをOracle ADFコンポーネントとして構築するか、またはポートレットとして構築するかという決定は、以下のガイドラインに従って下されます。

ポートレット — コンポーネントの機能が1つのシステムのみをベースとしており、そのほかのコンポーネントとのやり取りが多くない場合、ポートレットを使用します。 この種のコンポーネントの例としては、"予防的アラート・サブスクリプション・フォーム"があります。 このフォームはユーザーから入力データを受け取り、アラート・データベースへ格納します。 そのほかのシステムとはやり取りせず、システム内で処理を実行します。 このようなコンポーネントは、ポートレットの理想的な候補です。 また、ユーザーごとにカスタマイズする必要のあるコンポーネントもポートレットとして構築します。

Oracle ADFコンポーネント — コンポーネントがページ上の別のコンポーネントとやり取りし、そこからデータを取得する場合、Oracle ADFコンポーネントを使用します。 ポートレット間での相互通信も可能ですが、コンポーネント間のやり取りが同一システム上でおこなわれる場合には、Oracle ADFコンポーネントが理想的です。

図5： Oracle WebCenterを使用して構築したOLSのホームページ

Oracle WebCenterを使用して構築されたWind RiverのOLSフロントエンドでは、電子メールやコンテンツ・アラートをサブスクライブすることで、顧客が各自のオンライン・サポート・エクスペリエンスをパーソナライズして、必要な情報を取得できます。

また、Wind Riverは、将来的に、掲示板やチャットなどのWeb 2.0機能をサイトに追加することで、ユーザー・コミュニティの構築を目指しています。このようなコミュニティでは、Wind Riverテクノロジーへの投資を最大化するために、ユーザーがヒントやベスト・プラクティス、そして変革を実現するアイディアを互いに提供し合います。

JCRを使用してOracle Universal Content Managementと統合するオプションも提供されていますが、ここでは、Oracle Content Integration Suite（Oracle CIS）を使用してOracle WebCenterとOracle UCMを統合しました。 Oracle CISは、標準APIを活用するだけでなく、キャッシュ機能とクラスタリング機能を提供することで、パフォーマンスを向上させます。 Oracle CISを使用すると、Oracle WebCenterサーバーを実行するマシンに対して、コンテンツを含むファイル・システムをローカルでマウントできるため、Oracle WebCenterから見てローカル・ファイルとして処理することができます。 これにより、ポータル・リクエストは、コンテンツを検索およびフェッチするためにネットワークを経由する必要がなくなるため、さらにパフォーマンスが向上します。 この点が、RSSフィードなどの機能にとってきわめて重要となる、プッシュベースのコンテンツ統合アプローチのメリットです。

セキュリティ

OLSユーザーには多数の種類があるため、セキュリティ・インフラストラクチャはこれらをサポートするものでなければなりません。次に、OLSユーザーの種類を示します。

1. パブリック — パブリック・ユーザーが実行できるのは、製品マニュアルの参照とダウンロードのみです。
   
   
2. ポータル・ユーザー — OLSに登録していてWind Riverライセンスをもたない（Wind River製品を所有していない）ユーザーが実行できるのは、プロファイルの更新とライセンスの追加のみです。 OLSコンテンツにアクセスすることはできません。
   
   
3. ベーシック — 有効なライセンスをもっているが、Wind Riverの製品サポート契約は有効でないユーザー。 Wind River製品を所有していても、製品サポートが期限切れになっているか、または製品サポートを購入していないユーザーです。 このユーザーはOLSにアクセスできますが、技術的ヒント、アプリケーション・ノート、マニュアルなどの基本的なコンテンツの参照のみに限定されます。
   
   
4. メンテナンス — 有効なライセンスおよび製品サポートをもっているユーザー。 Wind River製品を所有しており、Wind Riverとの有効なサポート・サービス契約を結んでいるユーザーです。 このユーザーは、プレミアム・ユーザー向けの限定コンテンツ以外のすべてのOLSコンテンツを参照できます。
   
   
5. プレミアム — プレミアム・サポート・アカウントをもつメンテナンス・ユーザーは、プレミアム・サポート・アカウント限定のプレミアム・コンテンツを含めたすべてのOLSコンテンツを参照できます。
   
   
6. 従業員 — 従業員は、プレミアム・コンテンツを含む、すべてのOLSコンテンツを参照できます。 従業員は、未公開の欠陥情報や顧客が登録したすべてのサービス・リクエスト（顧客が参照できるのは各自のサービス・リクエストのみ）を含む、顧客からはアクセスできないコンテンツも参照できます。

上記の要件に基づき、Oracle WebCenterおよびOracle UCMに対して、それぞれ以下のセキュリティ・モデルが設計されました。

Oracle UCMセキュリティ・モデルにおける"プレミアム_x"は、Oracle UCMアカウントを表します。 プレミアムxユーザーはメンテナンス・グループに含まれますが、アクセスするコンテンツには追加のフィルタリングが必要になる場合があります。 Oracle UCMアカウントは、このような目的で使用されます。 たとえば、ダウンロード・ドキュメントには、Oracle Internet Directoryメンテナンス・グループに属するすべてのユーザーからアクセスできます。 ただし、"企業X"というプレミアム・サポート・アカウントに固有のあるダウンロード・ドキュメントは、メンテナンス・グループのうち、Oracle Internet Didrectoryグループ"プレミアム_企業X"に含まれるユーザーでなければアクセスできないとします。 これを達成するには、対象となるドキュメントをアカウント"プレミアム_企業X"に関連づけます。

また、セキュリティ上の目的でメタデータ・フィールドを使用することも可能です。 たとえば、Wind Riverでは、"Internal"というメタデータ・フィールドが使用されています。 このフィールドの値に"true"が設定されている場合、コンテンツにアクセスできるのは従業員のみです。 Oracle WebCenterは、Oracle UCMとコントラクトを確立する際、ログイン・ユーザーが従業員であれば条件式を変更し、メタデータ・フィールド"internal = true"を追加して渡します。

Oracle WebCenterとOracle UCMレイヤーはいずれも、Oracle Single Sign-On（Oracle SSO）およびOracle Internet Directoryを使用して認証および認可をおこないます。Oracle UCMにはID管理のプラグインが含まれており、LDAPベースの任意のディレクトリからユーザー情報を取得できます。 また、Oracle UCMの構成ファイルを使用すると、LDAPグループ名をOracle UCMセキュリティ・グループおよびOracle UCMアカウントにマッピングできます。

OLSでは、Oracle UCMのSSO機能ではなく、Oracle UCMのネイティブ認証スキームを使用しました。 これは、Oracle UCMがパブリック・ユーザーやすべての従業員に対して公開されているわけではないためです。Oracle UCMにログインしてコンテンツを変更できるのは、特定の従業員やコンテンツ提供者のみです。 ただし、Oracle UCMはOracle Internet Directoryに対して認証をおこないます。

Oracle WebCenterもまた、Oracle Internet Directoryからユーザー情報（ロールなど）を取得します。 ただし、ネイティブ認証スキームではなくSSOを介してログインできるように、SSOが設定されています。 これは、アプリケーション・サーバーにSSOを設定し、アプリケーションをSSO対応として識別することで実現されます。 その後、web.xmlを介してJ2EEセキュリティを使用して、ページ・レベルのセキュリティを有効化します。

次に、ユーザーがOLSにログインした場合に実行されるステップを示します（図6を参照）。

1. ユーザーがOLSポータル・ページにナビゲートすると、OLSのJ2EEセキュリティ設定によりページが保護されているかどうかがチェックされます。 具体的には、アプリケーションの各種パスに定義されているセキュリティ制約と照らして、ページのパスを調査します。
   
   
2. ページが保護されている場合、リクエストがOracle Internet Directoryログイン・モジュールに転送されます。 ページが保護されていない場合、リクエストはページに転送され、認証は要求されません。
   
   
3. Oracle Internet Directoryログイン・モジュールにより、ユーザー・セッションが検証されます。 ユーザーがすでに認証されている場合、ログイン・モジュールによりリクエストはターゲット・ページに転送されます。 それ以外の場合、リクエストはログイン・モジュールによりSSOログイン・ページに転送され、認証がおこなわれます。
   
   
4. ユーザーはSSOログイン・ページに資格証明を入力し、これらはOracle Internet Directoryに対して検証されます。 資格証明が検証されたら、ユーザーはログイン・モジュールに転送されます。
   
   
5. ログイン・モジュールにより、キャッシュからユーザーのOracle Internet Directoryプロファイルが生成されます。 ユーザーにとって最初のログインである場合、プロファイルはOracle Internet Directoryから生成され、キャッシュに格納されます。
   
   
6. 次に、ユーザーがアクセスしようとしていた、本来のセキュアなページに戻ります。 この時点で、J2EEセキュリティにより、ユーザーのロールがこのページへのアクセスを許可されているかどうかが確認されます。
   
   
7. ユーザーが、（正しいOracle Internet Directoryグループに属していることにより）ページに対するアクセス権をもつ場合、リクエストはページに転送されます。 それ以外の場合、"アクセス拒否"ページが表示されます。
   
   
8. ターゲット・ページは、Oracle UCM CIS問合せを利用して、ターゲット・ページに要求されたOracle UCMデータを取得します。 また、ユーザー・コンテキスト（ユーザー名）がOracle CISに渡されます。
   
   
9. Oracle UCMは、ユーザー・コンテキストに基づいて、キャッシュまたはOracle Internet Directoryからユーザー・プロファイルをロードします。 ユーザーのロール、セキュリティ・グループ、およびアカウント・マッピングを使用して、Oracle CIS問合せによって取得されたコンテンツをOracle UCMがフィルタリングし、ユーザーが参照できるドキュメントのみが返されます。
   
   
10. Oracle WebCenterは、Oracle CIS問合せから返されたデータに基づいてページをレンダリングします。 Oracle CIS問合せから返されたデータはユーザー・コンテキストに依存するため、ページは、ユーザー・グループごとに異なる方法でレンダリングされます。
    
    
11. ポートレットは、アクセス制御に基づいてレンダリングされます。 Oracle WebCenterでは、任意のOracle WebCenterコンポーネントをユーザー・ロールに応じて表示または非表示にできます。 J2EEユーザー・プロファイルには、ユーザーに割り当てられたすべてのロールの一覧が含まれます。 すべてのOracle WebCenterコンポーネントには、"rendered"というプロパティが設定されています。 このプロパティは、あらゆる条件に応じて、動的にtrueまたはfalseに設定できます。 Oracle WebCenterのコンポーネントおよびポートレットは、このプロパティがtrueに設定されている場合のみレンダリングされます。 したがって、ロールの一覧に基づいて、特定のユーザーに特定のコンポーネントを表示するかどうかの評価を簡単に実行できます。

図6： OLSログイン、Oracle UCM、ポータル、IDMの統合

上記シナリオに基づいて、従業員向けの問合せも変更されます。 ログイン中のユーザーが"従業員"ロールに割り当てられている場合、すべてのOracle CIS問合せに(xInternal `TRUE`)が追加され、従業員のみに表示されるコンテンツ項目が追加取得されます。

統合

Wind Riverの構想は、Oracle UCMコンテンツに対して顧客が購入した製品を照合して、一致したコンテンツのみを表示することで、顧客が容易にサポート・コンテンツを探せるようにすることでした。 これには、OLSにOracle E-Business Suite（Oracle EBS）を統合する必要がありました。 この重要な統合を実現しない限り、OLSは、顧客に表示するコンテンツをパーソナライズする手段を手に入れることができません。

顧客の製品インストール・ベース、ライセンス・エンタイトルメント、サポート契約をはじめとする、Wind Riverの顧客情報はすべて、Oracle EBSに保存されています。 Oracle EBSと統合することで、OLSは、顧客のライセンスおよび製品インストール・ベースに該当するサポート・コンテンツをOracle UCMから取得できます。 このようにして、顧客がコンテンツを探すために検索を実行したり、OLSをナビゲートしたりしなくても、顧客が購入した製品に関連するサポート・コンテンツが表示されます。

Wind Riverは、Oracle UCMおよびOracle WebCenterでOracle EBSデータを使用できるようにするため、Oracle SOA Suite、Oracle TopLink、およびデータベース統合を組み合わせました。 この統合におけるキー・ポイントは、Oracle UCMにおけるすべてのコンテンツ項目をOracle EBSの製品階層にマッピングしたことです。 これにより、Oracle EBSに問合せを実行して顧客が所有する製品を見つけたら、この情報を使用して、製品から顧客に関連するOracle UCMコンテンツ項目へのマッピングを実行できます。

Wind Riverでは、Oracle UCMスキーマ機能を使用して、製品階層がツリー・ビューに表示されています。 また、すべてのコンテンツ項目タイプに対してカスタム・メタデータ・フィールドが作成され、一意の製品IDが格納されています。これにより、各コンテンツ項目が特定の製品にマッピングされます。 次に、コンテンツ項目が割り当てられている製品をユーザーが容易に選択できるように、ツリー・ビューがメタデータ・フィールドに関連づけられています。 これにより、すべてのOracle UCMコンテンツ項目からOracle EBS製品へのマッピングが実現します（例：VxWorksマニュアルは、VxWorks製品に結びつけられる）。 次に、このプロセスを表すスクリーンショットを示します。

図7： Oracle E-Business SuiteからOracle UCMへの製品マッピング

Oracle WebCenterは、Oracle TopLinkを使用してOracle EBSと統合することで、パーソナライズした情報をマイ・ライセンス・ポートレットとマイ・プロダクト・ポートレットに表示します。 マイ・ライセンス・ポートレットとマイ・プロダクト・ポートレットは、Wind Riverのすべての顧客に対して、コンテンツのパーソナライズとナビゲーションにおける重要な役割を果たします。 マイ・ライセンス・ポートレットには、顧客のOLSアカウントに関連づけられたすべてのライセンスが表示されます。 マイ・ライセンス・ポートレットでライセンス番号をクリックするとマイ・プロダクト・ビューが開き、このライセンス番号に対してライセンス供与されたすべての製品およびバージョンの一覧が表示されます。この情報はすべて、Oracle EBSとの統合を通じて取得されています（図8を参照）。

さらに、それぞれの製品およびバージョンの隣に、その製品およびバージョンに関連するすべてのOLSコンテンツへのリンクが表示されます。 たとえば、図8の最下部に表示された製品の"Manuals"リンクをクリックすると、製品"Compiler/Diab"のバージョン"4.4"にマッピングされたすべてのマニュアルを容易に参照できます。 この結果として表示されるマニュアル・ビューを図9に示します。

図8： マイ・プロダクト・ビュー

図9： マニュアル・ビュー

Oracle WebCenterは、Oracle UCMから取得したコンテンツをマニュアル・ビューに表示します。 はじめに、Oracle WebCenterは、Oracle UCM消費環境へのOracle CISコールを実行し、選択された製品およびバージョンをOracle CISの問合せパラメータとして渡します。 次に、Oracle UCMは、コンテンツ種類が"マニュアル"であり、渡された製品およびバージョンに一致するすべてのコンテンツ項目をOracle WebCenterに返します。 Oracle WebCenterによりデータがレンダリングされて、マニュアル・ビューに表示されます。 次に、このプロセスを表す図を示します。

図10： Oracle WebCenterとOracle E-Business Suiteの統合によるパーソナライズ

結論

Wind Riverは、次の3つの方法によって、このプロジェクトのROIを達成しました。

1. 以前は、OLSチームがすべてのOLSコンテンツを手動でメンテナンスしていました。 製品をメジャー・リリースする場合、マニュアル、アプリケーション・ノート、FAQ、およびこの製品リリースに関連するすべてのコンテンツをOLSポータルに手動で公開するために、OLSチームは何週間もかける必要がありました。 Oracle UCMのセルフサービス・モデルを利用することで、Wind Riverのコンテンツ作者（技術文書、エンジニアリングなど）自身が、OLSチームやITチームの助けを借りることなく、製品リリース向けコンテンツを簡単にレビューおよび公開できるようになりました。 これにより、プロセスがシームレスなセルフサービスとなったため、OLSにコンテンツを公開するために要する時間が大幅に短縮されました。
   
   
2. OLSポータルの顧客満足度調査によると、最初の1ヶ月で満足度が47%から82%に向上しました。 平均では、このプロジェクトより前のOLS顧客満足度は、40～50%の間を推移していました。
   
   
3. パーソナライズされたナビゲーションのおかげで、顧客が探しているコンテンツを見つけるまでに必要なクリックの数が25～50%も削減されました（コンテンツ種類により異なります）。 さらに重要な点は、関連するコンテンツを見つけるために顧客が検索やナビゲートをおこなうかわりに、OLSが自動的にコンテンツを提示することです。もはや、顧客はコンテンツを探す必要はありません。 このことは、クリック数を大幅に減らしただけでなく、顧客満足度の向上に大きく貢献しました。

Wind River OLSポータルの例で確認したとおり、Enterprise 2.0とは、高度にセキュアでコラボレーティブなインタフェースを使用して、エンタープライズ・データをエンドユーザーに提供することです。 Web 2.0、コンテンツ管理、およびセキュリティは、Enterprise 2.0戦略を推進する上で重要な役割を果たします。 Web 2.0レイヤーは、単一ユーザー・インタフェースを使用して、コンテンツ、プロセス、システム、およびユーザーへのアクセスを実現します。 集中型コンテンツ管理は、複数のサイトやアプリケーション間でのコンテンツ提供体験に一貫性を実現します。 同時に、コンテンツの整合性により、リスクを軽減し、ユーザー導入率を高めます。 最後に、セキュリティおよびプライバシは、Enterprise 2.0の中核を成す存在です。 SSO、ロールベース・アクセス、認証、および認可の各機能により、Enterprise 2.0の安全性とセキュリティが確立され、監査と制御が実現されます。

Melody Wood、Sanjay Kwatra、Sachin Agarwal、Fahad Ansariの貢献に感謝します。

詳しい情報については、 WebCenter Servicesを参照してください。

	Nam Doan-Huy Namは、Wind River Systemsのビジネス・アプリケーション担当Senior Managerです。 Wind Riverの幅広い事業部門を支える、Oracle E-Business Suiteアーキテクチャおよび統合チーム、Webアプリケーション・チーム、およびDBAチームを管理しています。 Wind Riverに勤務する以前は、テクニカル・リード・コンサルタントとしてERP実装に携わっていました。
	YiHong Xu YiHongは、Wind RiverのWebアーキテクトとして10年の経歴をもちます。 品質管理エンジニアとしてのキャリアからスタートしたYiHongは、2003年にWeb技術者へと転向しました。Webアーキテクトとして、ビジネス要件からユースケースへの変換、ツールの特定と評価、ハードウェア・プラットフォームおよびソフトウェア・プラットフォームの選定、異機種Webシステム間での一貫性の維持を含む、Web戦略の開発を担当しています。 YiHongは、電気工学の修士号を取得しています。
	Narshimha Rao KondapakaはIT部門のProject Managerであり、Wind Riverでの勤務歴は4年になります。 11年以上にわたって、Oracleのテクノロジーおよびアプリケーションに従事してきました。 Oracle Applicationsの技術開発者としてキャリアを開始したのちに、優れたビジネス・アナリストに転身しました。 最近Project Managerになり、オンライン・サポート・ポータルの実装において重要な役割を果たしました。 Raoは、コンピュータ・アプリケーションの修士号を取得しています。