ヘッダーをスキップ
Oracle® Fusion Middleware WebCenter Sites開発者ガイド
11gリリース1 (11.1.1.8.0)
E49681-03
  ドキュメント・ライブラリへ移動
ライブラリ
製品リストへ移動
製品
目次へ移動
目次

前
 
次
 

3 Oracle WebCenter Sitesの開発プロセス

WebCenter Sitesのコンテンツ管理システムから配信されることになるオンライン・サイトを開発すると、実際には次の2つのサイトを設計することになります。

言い換えると、次の2種類のエンド・ユーザーのユーザー作業環境を担当します。

これら2つの、緊密につながってはいるが別々のサイトを作成する際には、開発チームは、計画立案、開発、テストという一連の手順を実行します。この章では、1つの考えられるイベントの流れで、そして一般的な用語で、開発プロセスについて説明します。実際のワークフローは、作業環境とビジネス・ニーズに応じて異なります。

この章には次の項が含まれます。

3.1 手順1: チームを発足する

最初の手順は開発チームを結成することであり、チームは次のような人たちで構成します。

開発チームには、データベース管理者、システム管理者、コンテンツ・プロバイダなどの人たちが必要であり、(開発者のように)次のような様々な理由で実際のコーディングを行う人たちも必要です。

3.2 手順2: 機能とデザインの仕様を作成する

Oracle WebCenter Sitesのコンテンツ管理システムから配信されるオンライン・サイトは、すべてを包括した構成体で、その中ではすべてのものが他のすべてのものと対話、交差および作業します。したがって、2番目の手順は、機能仕様とデザイン仕様を作成すること、すなわちオンライン・サイトを紙上で設計することです。

何かのコーディングを始める前に、この手順のなんらかのバージョンを完了する必要があります(デザイン仕様を作業する際に、なんらかの概念検証コーディングを行う場合もあり)。

3.2.1 機能要件

デザインの指定を開始する前に、製品管理とマーケティングでは、オンライン・サイトに機能要件を提供する必要があります。

3.2.2 ページ・デザイン

マーケティング担当者からの機能要件の入手後、最初に行う作業としては、オンライン・サイトに提示するすべてのタイプのページを策定することをお薦めします。たとえば、ホーム・ページ、セクション・ページ、コラムニスト・ページ、検索ページ、記事ページです。商用ページを設計する場合は、登録ページ、製品カテゴリ・ページ、製品の説明ページ、記事ページ、FAQページ、請求書ページなど、他の種類のページが必要です。

各ページおよびサイト全体のグラフィック、ナビゲーション、機能の各面での特徴を決定します。具体的には、ナビゲーション・バー、購入ボタンとショッピング・カート、詳細ボタン、検索機能、ロゴの配置、アニメーション化されたグラフィックなどです。

Engageを使用している場合は、マーチャンダイジング・メッセージ(推奨)をページのどこに配置するか、またどのページに配置するかを判断します。たとえば、おそらくそれぞれの製品カテゴリ・ページには、ページの右上隅に新製品という名前のセクションがあります。

サイトの構造全体を策定して、原寸大の模型を作成します。

3.2.3 キャッシュ戦略

デザインにおける代表的なエレメントはキャッシングで、ページ・キャッシングと結果セット・キャッシングがあります。キャッシュ戦略を計画、テスト、実装しないと、オンライン・サイトはパフォーマンスの目標を達成できません。

オンライン・サイトに提示するページを設計する際には、各ページの断片ごとに、ページ・キャッシングをいつどのように実装できるか、また実装する必要があるかを検討する必要があります。

問合せを設計する際には、データベース内のすべての表を策定し、それぞれの表に結果セット・キャッシング設定をどのように設定するカスタマイズを決定します。

3.2.4 セキュリティ戦略(アクセス制御)

オンライン・サイトのどの部分にアクセスする場合も、事前に訪問者にIDを明らかにしてもらう必要がありますか。ページを正しく設定できるようにするためには、設計プロセスの初期段階で、どのような種類のアクセス制御を実施するかを決定する必要があります。

たとえば、訪問者がページにアクセスすることを許可する前に訪問者のアイデンティティをチェックする予定の場合、これは、そのページの構成要素のキャッシュ方法に影響します。たとえば、キャッシュされることのないコンテナ・ページを設計できます。このページは、訪問者のアイデンティティを検証し、この検証が成功した場合にかぎって、キャッシュされたページレットからページを組み立てるというものです。

3.2.5 フォーマットとコンテンツの切離し(アセットのエレメント)

コンテンツとフォーマットを切り離すという基本的な提案に続いて、サイト内に提案された各ページの各断片を見て、その断片をデータとロジックのいずれで表すかを決定します。

データがアセットとして表されるように設計され、エレメント・コードに埋め込まれていないというのが優れたデザインです。デザインまたはコンテンツのすべての構成要素を調べて、アセットが何であるかを判別します。その判別を行うには、データとロジック/コードどちらのカテゴリに構成要素が属しているかを判断します。

簡潔に言えば、本当はデータであれば、エレメントにコーディングしない(ロジックに埋め込まない)でください。データであれば、別のアセットに入れてください。

別の見方を次に示します。

  • コンテンツを表すアセットは、コンテンツ・プロバイダの担当です。

  • ロジック(任意のエレメントにコーディングされているもの)は、開発者の担当です。

3.2.5.1 アセット・タイプ(コンテンツ)の判別

ドキュメント、記事、製品およびイメージは、簡単にアセットと識別されます。ただし、ヘッダーやフッターなどのデザイン構成要素もアセットになり得ます。

  • ヘッダーまたはフッター内のコンテンツがエレメントのコードに埋め込まれている場合は、コンテンツ内の何か(電話番号やロゴなど)が変更されたら、担当開発者または別の開発者がコンテンツ内のテキストを変更する必要があります。

  • ヘッダーまたはフッター内のコンテンツがアセットに含まれている場合は、エレメント内のコードはそのアセットのIDを取得できる必要があります。そのコンテンツは、コンテンツ・プロバイダの担当になります。

ページのそれ以外の構成要素でアセットになり得るものには、次のような種類のものがあります。

  • オンラインの世論調査

  • アニメーションなどのメディア

  • その日の相場

  • 会社または株式のプロファイル

  • ナレッジ・ベースの質問と回答

開発者の視点では、構成要素のコンテンツがアセット内に表されている場合は、そのコンテンツは他の人間が担当します。自分で担当するのは、オンライン・サイトのどこにいつ表示するか、そして表示したときの外観をどのようにするかのみです。

3.2.5.2 イメージなどのBLOBの処理方法の判断

オンライン・サイトで使用するイメージなどのBLOBを管理する方法を判断する際には、次の2つの一般的なオプションがあります。

  • アセットとして扱う: WebCenter Sitesデータベースに格納し、BlobServerサーブレットで提供します。

  • 静的ファイルとして扱う: Webサーバー上のファイル構造に入れて、Webサーバーで提供します。

どちらの方法も有効なオプションです。イメージ・ファイルをWebサーバーに保持する場合、WebCenter Sitesタグを使用して、それらのファイルへのリンクを作成できます。また、Webサーバーにイメージの配信を許可すると、パフォーマンス上の利点が得られる場合があります。ただし、イメージとBLOBをWebCenter Sitesデータベースから切り離しておく場合は、次のようになります。

  • 別のファイル管理プロセスを実装する必要があります。管理システムから配信システムにイメージ・アセットを移動するパブリッシュ方法では、WebCenter Sitesデータベースに格納されていないコンテンツは移動できません。このプロセスは自分で管理する必要があります。

  • WebCenter Sitesのネイティブ・セキュリティ・メカニズムはどれも当てはまりません。つまり、WebCenter Sitesで管理されていないBLOBへのアクセスを制限する場合、ACLは使用できません。

3.2.5.3 機能デザインとフォーマットの策定(エレメント)

オンライン・サイトに組み込む予定の機能のすべてを分析する必要もあります。商用サイトを設計する場合、サイトを構成する部分が、どちらかというとアプリケーションのように動作することは疑いありません。

訪問者の登録ページ、訪問者のデータ・コレクション・ページ、ショッピング・カート、パーソナライズなどに必要なコードまたはロジックが何であるかの概略を記します。

WebCenter Sitesシステムに用意されているコーディング・オプションが、Java、XMLおよびJSPであることを忘れないでください。実現しようとしている機能のそれぞれを見ていき、その機能にとって最適のコーディング解決策がどれであるかを判別します。

3.2.6 データ・デザイン

サイトの断片のいずれをアセットとして表す必要があるかがわかったら、アセット・タイプを何にすべきかを策定できます。それぞれの新規アセット・タイプでは、データベース表を1つ以上使用します(ベーシックとフレックスいずれのアセット・タイプであるかによって異なります)。

3.2.6.1 アセット・タイプ

ベーシックとフレックスどちらのアセット・モデルを使用する場合でも、アセット・タイプを設計する際には次の点を検討してください。

  • アセット・タイプのデザインは、設計対象とするユーザー・グループの両方(オンライン・サイトへの訪問者と、データを入力する必要のあるコンテンツ・プロバイダ)に影響を与えます。

  • ページ・デザインを正常に実装するためには、いずれのタイプのアセットを、他のタイプの他のアセットにリンクまたは関連付ける必要がありますか。これらの関係を、アセット・タイプに忘れずに実装してください。

  • コンテンツ・プロバイダが効率を正当に評価します。使用する予定が本当にあるデータのみをアセット・タイプに格納して、だれも使用しないデータを保持することにコンテンツ・プロバイダが時間を浪費しないようにしてください。

3.2.6.2 アセット・タイプをサポートする補助表

システムに実装するデータ・デザインは、アセットを保持しているデータベース表を越えています。提供する情報の種類によっては、アセット・タイプをサポートする補助表を作成することが必要になる場合もあります。

たとえば、Burlington Financialサンプル・サイトには、「Mimetype」フィールドの付いたアセット・タイプがあります。「Mimetype」フィールドはドロップダウン・フィールドで、ユーザーはドロップダウン・リストから値を選択する必要があります。これらの値は、MimeTypeという名前の参照表から引き出されます。ニーズによっては、使用システムで同様の表を作成することが必要になる場合もあります。

作成する予定のあるアセット・タイプおよび補助表についての議論にはデータベース管理者にも参加してもらい、管理システムと配信システムで発生する可能性のある種類のデータベース・チューニング問題を理解してもらってください。

3.2.6.3 訪問者データ

Engageを使用している場合は、訪問者のどのようなデータを収集する予定があるのかを判別する必要もあります。これらのデータ型は、Engageの訪問者データ・アセットで表され、訪問者のIDに基づいてサイトをパーソナライズする際にセグメントを作成するために使用します。(たとえば、人口統計、購入履歴、クリックストリームなどの情報。)

WebCenter Sitesシステムが本番稼働し、訪問者のデータ収集を開始したら、そのデータを格納する表はすぐに大きくなります。これも、データベース管理者と相談しておく必要のある分野です。

3.3 手順3: 管理システムの要件を設定する

コーディングを開始する前に、管理システムをどのように編成するかを知っておく必要があります。デザインはコンテンツ管理サイトに応じて異なるため、これらの意思決定がデザインに影響を与えます。

コンテンツ管理サイトとは、実際のオンライン・サイト向けの組織構成メンバーとして、またアクセス制御ツールとして使用するオブジェクトです。テンプレート・アセットを作成すると、WebCenter Sitesでは、SiteCatalog表で、そのアセットに対するエントリが作成されます。テンプレートのページ・エントリにWebCenter Sitesで使用されるネーミング規則には、テンプレートの作成対象となるコンテンツ管理サイトの名前が含まれます。つまり、コンテンツ管理システム全体(開発システム、管理システムおよび配信システム)で整合性を維持する必要があり、コーディングを開始する前に、使用しているサイトの名前を知っておく必要があります。

第1の関心事は各サイトの名前ですが、システム管理者とビジネス・マネージャは次の点も決定する必要があります。

これらの決定には、このドキュメントと『Oracle Fusion Middleware WebCenter Sites管理者ガイド』の両方を使用してください。

3.4 手順4: データ・デザインを実装する

デザイン仕様を作成し、管理システムの構成を理解したら、データ・デザインを実装できます。

開発システムで、次の種類のタスクを完了します。

この手順と次の手順(第3.5項「手順5: オンライン・サイトを構築する」)は反復作業であり、多くの部分が重複する可能性が高いと考えられます。アセット・タイプを作成して、テンプレート作成前にアセットを作成できるようにする必要がある一方、データ・デザインに改良が必要な領域が明らかになるのは、テンプレートのコーディングとコードのテストを行った後のみになる可能性が高いと思われます。

オンライン・サイトのデータ・デザインを実装する際には、第11章「データ・デザイン: アセット・モデル」を参照してください。

3.5 手順5: オンライン・サイトを構築する

たった1つのタイプでもサンプル・アセットを開発システム上に作成したら、テンプレートのコーディングおよびオンライン・サイトの構築を開始できます。(実際は、デザイン仕様を作成した後であれば、アセットを表示しないエレメントのコーディングをいつでも開始できます。)

この手順では、次の種類のタスクを完了します。

オンライン・サイトを構築する際には、第4章「Oracle WebCenter Sitesを使用したプログラミング」を参照してください。

3.6 手順6: 管理システムを設定する

オンライン・サイトが開発システムで稼働するようになったら、オンライン・サイトを管理システムに移動します。

開発者は、次の種類のタスクを完了します。

次にシステム管理者は、次の種類のタスクを完了します。

管理システムの設定については、『Oracle Fusion Middleware WebCenter Sites管理者ガイド』を参照してください。

3.6.1 コンテンツをアセットとしてインポート

コンテンツは、使用するなんらかの非アセット・フォーマットになっていると考えられます。このコンテンツをWebCenter Sitesデータベースにアセットとしてインポートするには、XMLPostユーティリティを使用します。

3.6.2 カタログ・データおよびフレックス・アセット・データのインポート

フレックス・アセット・モデルを使用していて、これから使用するデータが前もって大量に存在している場合は、BulkLoaderユーティリティを使用してインポートできます。ただし、システム化された更新の場合は、XMLPostユーティリティを使用します。

3.6.3 サイトのデザインについて編集チームに指示

編集チームがオンライン・サイトを正常に維持できるようにするには、デザインを理解しておく必要があります。たとえば、コレクションをどのくらいの頻度で再構築するかなどがあります。

ベーシック・アセット・モデルを使用している場合は、コンテンツ・プロバイダは次の点を知っておく必要があります。

  • 該当する問合せおよびコレクション別にアセットが検索されるようにするには、アセットにどのカテゴリおよびソースを割り当てるべきか。

  • どのテンプレートをどのアセットに割り当てるべきか。

  • サイト・ページ上のリンクが正常に機能するようにするには、どのアソシエーション・フィールドにデータを入力する必要があるか。

アセット・タイプごとに開発者とシステム管理者が作成する「スタート・メニュー」ショートカットに、できるだけ多くの情報をプログラムすることをお薦めします。

フレックス・アセット・モデルを使用している場合は、コンテンツ・プロバイダは次の点を知っておく必要があります。

  • フレックス・アセットに定めた一般的な階層または分類。

  • フレックス・アセットが何の情報を継承するかについての情報。

  • どのテンプレートをどのアセットに割り当てるべきか。

3.7 手順7: 配信システムを設定する

配信システムを設定するときには、管理システムに対して完了したのと同じ手順をいくつか完了します。例:

次に、管理システム上のアセットのすべてを配信システムにパブリッシュします。

また、このシステムは管理システムでないため、次の手順も完了します。

配信システムの設定については、『Oracle Fusion Middleware WebCenter Sites管理者ガイド』のパブリッシュに関する項を参照してください。

3.8 手順8: 配信システムにパブリッシュする

管理システム上のコンテンツが準備できたら、配信システムにパブリッシュします。パフォーマンスと負荷の両面で集中的なテストを実施した後で、サイトを世間に公開します。