ある IBM WebSphere Portal サーバーからの差分を別のサーバーにインポートするプロセスは、ステージングと呼ばれています。このプロセスの詳細は、IBM WebSphere Portal Version 6.0 インフォメーション・センターの「Overview of staging your portal to production (ポータルの実稼働環境へのステージングの概要)」セクションに説明があります。また単純なケースの例としては、初期リリースや以降のリリースの作成などがあります。初期リリースの作成は、一回限りの作業であることの方が多く、新規サーバー (例えば、新規ハードウェア上の別の実動サーバー) を作成する場合にのみ必要となります。

もっとも単純なケースは、以下の 4 つのシステムがある場合です。

• 開発者がコンテンツの新規作成または変更を行う開発システム
• 開発者が、開発したフラグメントをデプロイする統合システム
• 統合システムからのリリースがテストのためにデプロイされるステージング・システム
• すべての変更が最終的にデプロイされる実動システム

注: この導入部では、既存のサーバー (ステージング、統合、実稼働) が存在せず、これらを新規にインストールする必要があることを前提としています。このインストールを行う手順を WebSphere Portal のインフォメーション・センターでは「空ポータル」のインストールと呼んでいます。

重要: インストールしたポータルをコピーすることはサポート対象外です。そのようなコピーを行うと、複数の異なるサーバー上に同じオブジェクト ID が生成される可能性があり、オブジェクト ID は ReleaseBuilder ツールにとって重要な項目であるため、このことにより、オブジェクトが誤って上書きされてしまうおそれがあります。

初期リリースの作成

開発者は常に、作成したコンテンツ (成果物) を統合システムにデプロイしています。統合システム上のリリースが最終版であると判断されると、開発者はこれをリリース・エクスポートでエクスポートすることができます。エクスポートはその全体を (空の) ステージング・サーバーにインポートすることが可能です。リリースのインポートを除き、関連する処理の大部分が、統合システム上で行われます。

リリースがテストされ、実稼働環境に移行可能な状態になったら、同じプロセスを使用してコンテンツを統合環境から実稼働環境に移動させます。

そのために、統合システムから作成したエクスポートを、実動サーバーに直接インポートすることができます。この方法の利点は、ステージング・サーバーで行った作業のみを複製することにより、リリース・エクスポートをステージング・サーバーから新規作成してこれを実動サーバーへの変更の移動に使用した場合に発生する可能性のある取り扱いや処理上のエラーが除外されることです。

注: 実動サーバーを作成した後は、実動サーバー上では手動での変更を一切行わないでください。手動で変更を行うと、変更に不整合が生じるおそれがあるためです。このことは、両方のシステムにまったく同じリソースを作成する (と考えている) 場合に特に注意する必要があります。実際には、両方のシステム上に新規の (かつ異なる) オブジェクト ID が生成されているため、まったく同じリソースを作成するとは言えません。

上に戻る

以降のリリースの作成

初期リリースを作成したら、新機能、新規ポートレット、新規ページの実装を開始します。または、単に現行リリースの内容を変更したり問題を修正したりします。

すべての成果物を統合システムに移動させた時点で、新規リリースを作成できるようになります。この記事で紹介する単純なケースでは、以下を行うことによってこの作業を行うことができます。

• 新規リリース・エクスポートを統合システム上で作成します。
• ReleaseBuilder ツールを初期リリース・エクスポートおよび新規作成したリリース・エクスポートに対して実行します。ここで、-inOld パラメーターは初期リリース・エクスポートを、-inNew パラメーターは新規作成したリリース・エクスポートを表します。
• その結果生成された XML ファイルを、テストのためにステージング・サーバーにインポートします。

テストが正常に終了したら、リリースを実動サーバーに転送することができます。ここでも、リリースをステージング・サーバー上でデプロイするために使用した ReleaseBuilder エクスポートと同じものを使用できます。

注: 常に、(例えば 1 ページ、または下位ページを含む 1 ページなどの) 部分エクスポートではなくリリース・エクスポートを作成するようにしてください。ReleaseBuilder ツールでは、完全なリリース・エクスポートのみを取り扱うことができます。リリース・エクスポートには、共用と見なされる成果物のみが含まれ、専用リソースは含まれません。

上に戻る

ReleaseBuilder ツール

サポートされるシナリオとそうでないシナリオがある理由を完全に理解するには、ReleaseBuilder がどのように設計されており、内部でどのように機能するかを知ることが重要です。

ReleaseBuilder は、2 つのリリース・エクスポートを元に、両者間の差分を抽出します。リリース・エクスポートを使用した場合にのみ有効な結果が得られるのであり、単一リソース・エクスポートやページ階層エクスポートなどのエクスポートを使用した場合には、一見正常に処理されているように見えたとしても、無効な結果となることに注意することが重要です。

内部では、ツールは 2 つのリストを保持します。1 つは旧リリース (現行の実動リリース) のための、もう 1 つは新規リリースのためのリストです。その後、オブジェクト ID を使用し、同等 (必ずしも同一である必要はありません) のオブジェクトには同一のオブジェクト ID が付与されていることを前提として、新規リリースのリスト内で検出された各リソースについて、一致するリソースを検出するプロセスが開始します。このプロセスが適用されるオブジェクトは、以下のとおりです。

• virtual-resource
• markup
• client
• skin
• theme
• wsrp-producer
• web-app
• content-node
• credential-segment
• url-mapping-context

ReleaseBuilder は、一致するオブジェクトを検出すると、詳細を分析し、変更されていないパラメーターを削除し、関連する変更のみを含む出力 (差分) ファイルを生成します。

開発システム、ステージング・システム、統合システム、および実動システムすべてにわたって同じユーザー・リポジトリーを共有していない場合には、そのセットアップに必要な変更を反映するよう XML ファイルを修正する必要があることに注意が必要です。例えば、ユーザー A に、LDAP1 内および実動システム上の新規ページを編集する権限が付与されている場合、そのユーザーは LDAP2 においてはユーザー B となる必要があります。スタイル・シートを作成してこのマッピングを ReleaseBuilder 出力 (差分) ファイルに適用し、それが実動システムに適切にインポートされるようにする必要があります。

ReleaseBuilder で処理されない WebSphere Portal 成果物

以下のリストは、ステージングから実動へのプロセスに関与する各システム上に手動でインストールする必要のあるすべての WebSphere Portal 成果物を列挙したものです。各成果物のインストール方法については、インフォメーション・センターに説明があります。

• ポートレット (WAR ファイル。例については下記参照)
• テーマおよびスキン (JSP、イメージ、CSS など。または例については下記参照)
• ポータル画面 (JSP、イメージ)
• ポートレット・サービス (Java ライブラリー)
• J2EE 成果物 (EAR ファイル、Java ライブラリー)
• カスタム・ユーザー・レジストリー (Java ライブラリー)
• クレデンシャル・ボールト・アダプター (Java ライブラリー)
• カスタム・クレデンシャル (Java ライブラリー)
• JAAS ログイン・モジュール (Java ライブラリー)

ReleaseBuilder でステージング不可能なアイテム

以下のアイテムのステージングは、ReleaseBuilder では処理できません。

• 実稼働環境への文書ライブラリーのステージング (シンジケーションによって処理されます。)
• 実稼働環境へのアプリケーション・テンプレートのステージング (バックアップ/リストアによって処理されます。)
• 実稼働環境へのパーソナライゼーションのステージング (エクスポート/インポートまたはパブリッシュによって処理されます。)
• 実稼働環境への Web コンテンツのステージング (シンジケーションによって処理されます。)

ステージングの実行方法の詳細については、WebSphere Portal のインフォメーション・センターを参照してください。

上に戻る

初期リリースのセットアップ

以下のセットアップは、実動サーバーとステージング・サーバーを最初に同期させるための手順です。

セットアップ 1: ゼロからすべてをインストールする

このセットアップ方法は、可能な中でもっとも簡単なもので (上記の「導入」セクション参照)、詳しくはインフォメーション・センターでも説明されています。手順の要約は以下のとおりです。

1. 実動システムのための空の WebSphere Portal のインストールを実行します。
2. ステージング・サーバーのためのフルインストールを実行します。
3. コンテンツが作成され、ステージング・サーバー上で最終版となったら、リリースを XMLAccess でエクスポートします。
4. 先ほど作成したリリース・エクスポートを実動システムにインポートします。

セットアップ 2: 既存の実動サーバー

既存の実動サーバーがある場合、必要な作業は新規にステージング・サーバーを作成することです。新規ステージング・サーバーを作成するには、以下の手順に従います。

1. ステージング・サーバーのための空の WebSphere Portal のインストールを実行します。
2. 実動システムのリリース・エクスポートを実行します。
3. リリース・エクスポートをステージング・サーバーにインポートします。

これ以降は、実動システム上ではリリース・データの変更を行わないでください。

セットアップ 3: 既存のステージング・サーバー

この手順はセットアップ 2 と非常によく似ています。役割が異なるのみです。

• 実動サーバーのための空の WebSphere Portal のインストールを実行します。
• ステージング・システムのリリース・エクスポートを実行します。
• リリース・エクスポートを実動サーバーにインポートします。

ここでも、上記と同じルールが適用されます。すなわち、いかなるリリース・データの変更も、実動サーバー上では行わないようにします。

セットアップ 4: 既存の実動サーバーと既存のステージング・サーバー

以下の 2 つの方法のうちのいずれかを使用して、両サーバーを同期する必要があります。

1. 以前リソースが手動で実稼働環境に移動されていて、オブジェクト ID がリソースとともに移動されていた場合、再度手動でステージング・サーバーからのすべてのリソースを実動サーバーとの間でクロスチェックし、本来同じはずでありながら異なるオブジェクト ID が付与されているものを同期することが可能な場合があります。ただし、この手順にはエラーが生じやすいため、推奨されません。
2. サーバーのうちの 1 つをベースラインとして選択します。通常は実動システムをベースラインとする場合が多く、必然的にセットアップ 2 または 3 に戻ることになります。既存のステージング・サーバーも、開発サーバーとして引き続き使用することができます。

上に戻る

以降のリリースのシナリオ

これらのシナリオでは、使用する環境間の同期を維持することができます。ここで覚えておくべき重要事項は、リソースがどのように転送されるかということです。すなわち、大半のケースでオブジェクト ID を保持する必要があります。このことを WebSphere Portal インフォメーション・センターでは「object id preservation mode (オブジェクト ID 保持モード)」と呼んでいます。

可能な限り早期の段階で、リリースの差分を作成することが重要です。これにより、ステージング・システムまたは統合システムのために既に行ったデプロイメントを、より上位のシステムに複製することが可能になります。

シナリオ 1: 複数の開発環境、1 つのステージング環境、1 つの実稼働環境

この第 1 のシナリオ (図 1 参照) では、以下のことを行います。

1. フラグメントを開発システムからステージング・サーバーに移動させます。
2. ステージング・サーバー上のリリースをエクスポートします。これはリリース n+1 と見なされます。
3. リリース n および n+1 に対して ReleaseBuilder を実行します。
4. ReleaseBuilder の出力を実動システムにインポートします。

シナリオ 2: 複数の開発環境、1 つの統合環境、1 つのステージング環境、1 つの実稼働環境

この第 2 のシナリオ (図 2 参照) では、以下のことを行います。

1. フラグメントを開発システムからステージング・サーバーに移動させます。
2. 統合サーバー上のリリースをエクスポートします。これはリリース n+1 と見なされます。
3. リリース n および n+1 に対して ReleaseBuilder を実行します。
4. ReleaseBuilder の出力をステージング・システムにインポートします。
5. 修正が必要なエラーが発生したときは、1 からやり直します。
6. 統合テストが正常に終了したら、手順 3 で得られた ReleaseBuilder の出力を実動システムにインポートします。

シナリオ 3: 複数の開発環境、複数の統合環境、1 つのステージング環境、1 つの実稼働環境

このシナリオでは、2 人の作業者が同じリソース上で同時に作業することはない (または、少なくとも 2 人が行った修正内容は必ず調整される) ことを前提としています。このシナリオにおいて、開発組織が相互に依存している場合には、統合システムの同期を維持することが難しい場合があります。

複数の統合システム (図 3 参照) があるということは、複数の異なるビルディング・ブロックが複数の異なる者によって開発およびテストされることを意味します。各作業者が自身の担当部分を最終確定した後、部分リリースをステージング・システム (これ以降、統合システムとしても機能することになります) にインポートし、その後実動システムにインポートすることができます。

このシナリオは、実際には、シナリオ 1 のような 2 つの異なるチェーンと見なすことができます。1 つは開発 - 統合 - ステージング、もう 1 つは統合 - ステージング - 実稼働というチェーンです。例えば、次のようなことです。

• チェーン 1
  1. フラグメントを開発システムから統合サーバーに移動させます。
  2. 統合サーバー上のリリースをエクスポートします。これはこのチェーンのリリース n+1 と見なされます。
  3. 各統合サーバー上のリリース n および n+1 に対して ReleaseBuilder を実行します。
  4. 統合サーバーからの ReleaseBuilder 出力をステージング・システムにインポートします。

• チェーン 2
  1. フラグメントを統合システムからステージング・サーバーに移動させます。
  2. ステージング・サーバー上のリリースをエクスポートします。これはこのチェーンのリリース n+1 と見なされます。
  3. 各ステージング・サーバー上のリリース n および n+1 に対して ReleaseBuilder を実行します。
  4. ReleaseBuilder の出力を実動システムにインポートします。

重要: 2 つの XMLAccess タスクを同時に実行すること (例えば、2 人の管理者が異なる出力ファイルを同じポータル環境にインポートするなど) は、WebSphere Portal の V5.1 より前のバージョンではサポートされていません。しかし、バージョン 5.1 では、この点が変更されたため、これらのタスクを調整する必要が出てきました。

シナリオ 4: 複数の開発環境、複数の統合環境、複数のステージング環境、複数の実稼働環境

このシナリオの前提は、すべての実動システムの同期を維持する必要があるということです。以下のように、シナリオ 1 の手順 4 を変更すると、このシナリオに適用できます。

1. フラグメントを開発システムからステージング・サーバーに移動させます。
2. ステージング・サーバー上のリリースをエクスポートします。これはリリース n+1 と見なされます。
3. リリース n および n+1 に対して ReleaseBuilder を実行します。
4. ReleaseBuilder の出力をすべての実動システムにインポートします。

注: このシナリオは、推奨されるシナリオではありません。実動システムにインポートする再現可能な手順が得られないためです。基本的に、実動システムをステージング・システムまたは統合システムにするシナリオです (図 4 参照)。

上に戻る

サンプル・シナリオ

例として、図 5 のように、シナリオ 3 に若干変更を加えたものを使用します。

すべての環境が実稼働環境から同期されます (初期リリースのセットアップ 2 参照)。すべてのシステムが同じユーザー・リポジトリーに接続することを前提としています。さらに、元の構成を参照するためとして、エクスポート・ファイル export_release_0.xml が作成されます (図 6 参照)。

D:\IBM\WebSphere\PortalServer\bin>xmlaccess -user wpsadmin -password 
wpsadmin -url http://localhost:10038/wps/config/ -in 
D:/IBM/WebSphere/PortalServer/doc/xml-samples/ExportRelease.xml -out export_release_0.xml

すべての環境が同期されるため、この参照用構成ファイルをすべてのシステムにコピーすることができます。ReleaseBuilder を試しに実行してみると、環境間でまったく差異が発生しないことがわかります。

例 1: ポートレットの追加

例 1 は、テスト 1 システムで実行されました。ポートレットをインストールして必要なユーザー・アクセス権を設定した後に、ポートレットを目的のページに置き、適切に構成しました。変更内容に問題がないと認められた後に、リリース 1 のための構成ファイルを作成しました (図 7 参照)。

D:\IBM\WebSphere\PortalServer\bin>xmlaccess -user wpsadmin -password 
wpsadmin -url http://localhost:10038/wps/config/ -in D:/IBM/WebSphere/PortalServer/
doc/xml-samples/ExportRelease.xml -out export_release_1_test1.xml

リリースは先ほど行った変更のみでなく、WebSphere Portal 構成の全体を表すものであることに注意が必要です。

これが最初のリリースであったため、ReleaseBuilder で参照用構成と比較することにより出力 (差分) ファイルを作成しました。

D:\IBM\WebSphere\PortalServer\bin>ReleaseBuilder.bat -inOld export_release_0.xml 
-inNew export_release_1_test1.xml -out diff_release_1_test1.xml

出力 (差分) ファイル diff_release_1_test1.xml はその後、ポートレット WAR ファイルとともにステージング環境にコピーされました。ポートレット WAR ファイルは portal_server_root/installableApps にコピーする必要がありました。

新規ポートレットをインストールしようとすると、portal_server_root /deployed/archive 内に Web アプリケーションが見つかりません、という警告が表示されます。XMLAccess が portal_server_root/installableApps からフォールバックとしてポートレットを選出して自動的にインストールするため、このメッセージは無視して構いません。

WebSphere Portal バージョン 6 では、portal_server_root/deployed/archive ディレクトリーをコピーして警告メッセージが表示されないようにすることも可能です。その後、XMLAccess を使用して、出力 (差分) ファイルを統合環境にインポートしました (図 8 参照)。

D:\IBM\WebSphere\PortalServer\bin>xmlaccess.bat -in diff_release_1_integration1.xml 
-user wpsadmin -password wpsadmin -url http://localhost:10038/wps/config

WebSphere Portal サーバーを再起動した後、リリースが意図したとおりにデプロイされていることを検証しました。

例 2: ページの再配置

例 2 は、ページ配置と削除のみで構成されている例で、テスト 2 システム上で実行されました。その後、構成ファイルを作成しました。また、テスト 2 システムでの最初のリリースだったため、リリース 1 という名前も付けました (図 9 参照)。

D:\IBM\WebSphere\PortalServer\bin>xmlaccess -user wpsadmin -password wpsadmin 
-url http://localhost:10038/wps/config/ -in D:/IBM/WebSphere/PortalServer/doc/
xml-samples/ExportRelease.xml -out export_release_1_test2.xml

ここでも、ReleaseBuilder で元の構成と比較することにより出力 (差分) ファイルを作成しました (図 10 参照)。

D:\IBM\WebSphere\PortalServer\bin>ReleaseBuilder.bat -inOld export_release_0.xml 
-inNew export_release_1_test2.xml -out diff_release_1_test2.xml

その後出力 (差分) ファイル diff_release_1_test2.xml は統合環境にコピーされ、XMLAccess でインポートされました (図 11 参照)。

D:\IBM\WebSphere\PortalServer\bin>xmlaccess.bat -in diff_release_1_test2.xml -user 
wpsadmin -password wpsadmin -url http://localhost:10038/wps/config

WebSphere Portal サーバーを再起動した後、リリースが意図したとおりにデプロイされていることを検証しました。

ここまでの過程で、2 つのリリースがステージング環境にインポートされました (図 12 参照)。

この 2 つのリリースが同じサーバーにデプロイされたのは初めてであったため、両リリースが相互に干渉しないことを検証し、その後、結合されたリリース 1 のための構成ファイルを作成しました (図 13 参照)。

D:\IBM\WebSphere\PortalServer\bin>xmlaccess -user wpsadmin -password 
wpsadmin -url http://localhost:10038/wps/config/ -in D:/IBM/WebSphere/PortalServer/doc/
xml-samples/ExportRelease.xml -out export_release_1.xml

この時点で出力 (差分) ファイルが作成されると、2 つの過去のインポートからのすべての変更を含むファイルとなります (図 14 参照)。

D:\IBM\WebSphere\PortalServer\bin>ReleaseBuilder.bat -inOld export_release_0.xml 
-inNew export_release_1.xml -out diff_release_1.xml

このファイルを実稼働環境にインポートすると、リリースのチェーンは完了します (図 15 参照)。XMLAccess を実行する前に必ず、ポートレット WAR ファイルを portal_server_root/installableApps にコピーしてください。

例 3: テーマおよびスキン

ReleaseBuilder でテーマおよびスキンの定義をステージングする作業は、新規ポートレットまたは更新されたポートレットをインストールする作業に似ています(アイコンや JSP などの、実際のテーマやスキン自体は XMLAccess によってステージングされないことに注意が必要です)。

WebSphere Portal の管理画面で、テーマを追加して特定のページに適用させた後に、先ほど説明したように WebSphere Portal 構成エクスポートと出力 (差分) ファイルを作成することができます。

WebSphere Portal WAR ファイルと同様に、テーマおよびスキンも手動で次の環境にコピーする必要があります。これを行うには、必要なサブフォルダーを、ソース環境の …/themes and …/skins からターゲット環境の <wp_profiles>/installedApps/…/wps.ear/wps.war にコピーします。新規または更新された JSP が検出されるよう、インポート後に WebSphere Portal を再起動するようにしてください。

上に戻る

一般的なリリース・ワークフロー

図 16 は、ReleaseBuilder を使用した場合の一般的なワークフローに、サンプル・シナリオを反映させたものです。

拡大表示

上に戻る

特別な考慮事項

ここで、注意する必要のあるいくつかの特別な考慮事項について解説します。

クラスター環境

クラスター環境の場合には、ポートレット、テーマ、およびスキンの配布は WebSphere Application Server の Deployment Manager (DM) によって処理されます。リソースがすべてのノードで同時に利用可能になるとは限らないため、すべてのデプロイメントを行う単一のデプロイメント・ノードを選択する必要があります。したがって、セルの １ つのノード上の出力 (差分) ファイルのみをインポートする必要があります。ただし、portal_server_root/config から WPSconfig.<bat|sh> activate-portlets を発行することにより、ポートレットをアクティブにする必要があることに注意してください。

リリースの復帰

誤ってデプロイされたリリースを復帰させる必要がある場合には、以下の 2 つの対処法があります。

1. その後、他のいかなるリリースも実稼働環境にインポートされていない場合には、ReleaseBuilder を使用する場合にのみリリースを復帰させる必要があります。例えば、最終の有効なリリースがリリース <n> であり、リリース < n+1> を削除する必要があるときは、以下のように ReleaseBuilder を使用してください。

   ReleaseBuilder.bat -inOld release_ <n+1>.xml -inNew release_ <n>.xml-out remove_release_ <n+1>.xml

   
   この操作により、出力 (差分) ファイル remove_release_ <n+1>.xml が生成されます。このファイルを XMLAccess を使用して適用することにより、誤って追加されたものを削除することができます。
2. 上記とは逆に、1 つ以上のリリースが既に実稼働環境にインポートされており、古い方のリリースを削除する必要がある場合には、これを新規リリースとして取り扱います。必要な変更を統合環境またはステージング環境に実施して、既に追加された内容を反映させた上で、新規リリースを通常どおり実稼働環境にインポートします。

緊急の変更要求の場合にリリースを削除するアプローチとして考えられるもの (ただし、推奨されません) としてもう 1 つ、現行リリースと、誤ってデプロイされたリリースの直前のリリースから、出力 (差分) ファイルを作成するという方法があります。その後、削除する必要のあるファイルを除くすべての出力 (差分) ファイルを再適用して、現行状況を確立する必要があります。

例えば、リリース <n+1> を削除するには、以下の操作を行います。

ReleaseBuilder.bat -inOld release_ <n+3>.xml -inNew release_ <n>.
xml -out remove_all_since_release_n.xml

その後、ここでも XMLAccess を使用して、出力 (差分) ファイル < n+2> および < n+3> を適用します。リリースの復帰では、実稼働環境内のすべてのリリース・エクスポート・ファイルとすべての出力 (差分) ファイルが削除されていない、またはアーカイブされていることを前提としています。

古いバイナリー (例えば、ポートレット WAR ファイル) のプロパティーも復帰する必要があることに注意してください。原則として、XMLAccess の管理対象でないすべてのリソースがこれに該当します。

固有名を使用したリソースの削除と再作成

既存のリソース、例えば特定の固有名を持つページが削除され、同じ固有名で再作成された場合、インポート手順を実行すると DuplicateKeyException となる可能性があります。これは、ページが削除された時に、データベース内で削除されたものとマークされたにもかかわらず、実際にはそのページは (表示されていないだけであって) 依然として存在していることから起こります。この問題を回避するには、まず削除をステージングし、クリーンアップ操作を実行し、ページを再作成した上で、作成したものを再度ステージングしてください。

部分エクスポートに基づくステージング

ReleaseBuilder を部分エクスポートに対して使用することは、以下の理由により、通常はサポートされません。

部分エクスポートが <content-node action=”export” uniquename=”myUniqueName” export-descendants=”true”/> を使用して行われた場合には、一部のアイテム (web-app、servlet、portlet-app、および portlet) に action=”locate” という設定がなされる可能性があり、これは ReleaseBuilder では認識されません。すなわち、ReleaseBuilder に対する入力ファイルには、action=”update” と設定されているアイテムのみが含まれるということになります。

ポートレットがページ上で変更された場合、部分リリース・エクスポートはリスト 1 および 2 のコードのようになります。

リスト 1. 旧リリース

<web-app action=”locate” uid=”webapp1”…>
          <portlet-app action=”locate uid=”webapp1.1”>
                <portlet action=”locate” name=”My Portlet” objectid=”_5_xx”>
        </portlet-app>
</web-app>
<content-node action=”update”…>
:
               <portletinstance action=”update” portletref=”_5_xx”/>

:
</content-node>

リスト 2. 新規リリース

<web-app action=”locate” uid=”webapp2”…>
          <portlet-app action=”locate uid=”webapp2.1”>
                   <portlet action=”locate” name=”A Portlet” objectid=”_5_yy”>

         </portlet-app>
</web-app>
<content-node action=”update”…>
:
                 <portletinstance action=”update” portletref=”_5_yy”/>
:
</content-node>

これにより、ReleaseBuilder は、web-app を削除するような指令が発生し、 web-app webapp 1 が移動されたのかと判断するかもしれません。

このように部分エクスポートを活用することはできますが、何らかの理由で内容が削除されてしまう場合があるため、出力 (差分) ファイルは使用前に十分な確認とレビューを行なう必要があります。

上に戻る

まとめ

ReleaseBuilder を使用する際には、使用環境で対処しようとしている目的のシナリオを中心に計画を立て、その上で初期リリースを作成し、その後差分リリースの作成を開始する必要があります。ReleaseBuilder ではオブジェクト ID が重要な項目として使用されること、および以降の変更を除いて、ソース・システムとターゲット・システムの同期を確保する必要があることに注意することがきわめて重要です。

実動システム上で管理インターフェースを通じて手動で更新を行うと、望ましくない結果がもたらされるおそれがあるため、そのような更新を行うべきでないことを常に念頭に置いてください。また、システムの再同期が必要となった場合には、初期リリースの作成手順を使用して再同期を行うことができます。

参考文献

• developerWorks Japan: Lotus: Lotusの日本の技術情報サイトです
  
  
• developerWorks: Lotus(US) : Lotusの英語の技術情報サイトです
  
  
• ディスカッション・フォーラム(US)をご覧ください。
  
  
• US サポート技術情報Technote Using ReleaseBuilder effectively(US)をご覧ください。
  
  
• WebSphere Portal for Multiplatforms Version 5.1 インフォメーション・センター (US) のページを参照してください。
  
  
• IBM WebSphere Portal Version 6.0 インフォメーション・センター(US) のページを参照してください。
  
  

著者について

この記事を評価する

コメント

上に戻る

目次

• 初期リリースの作成
• 以降のリリースの作成
• ReleaseBuilder ツール
• 初期リリースのセットアップ
• 以降のリリースのシナリオ
• サンプル・シナリオ
• 一般的なリリース・ワークフロー
• 特別な考慮事項
• まとめ
• 参考文献
• 著者について
• コメント