Comments
Transcript
WebSphere Process Server クライアントを使用した IBM の統合
WebSphere Process Server クライアントを使用した IBM
WebSphere Portal V7 と IBM WebSphere Process Server V7
の統合
Walter Haenel
Architect, Operations and Deployment for WebSphere Portal
IBM Software Group
Boeblingen, Germany
Marie Knight
Software Test Specialist
IBM Software Group
Atlanta, GA USA
Wolfgang Reibert
WebSphere Portal development
IBM Software Group
Boeblingen, Germany
2010 年 9 月
© Copyright International Business Machines Corporation 2010. All rights reserved.
要約: IBM® WebSphere® Portal 7.0 は、IBM WebSphere Process Server のワークフロー・システムと統合
する複数の方法も含め、数多くの統合機能を展開しています。その 1 つの可能性として Enterprise
JavaTM Bean (EJB) API を使用した統合があり、これには WebSphere Process Server Client が
WebSphere Portal 上にインストールされていることが必要です。この統合は、すぐに使用可能な「タスク・
リスト」ポートレットによってサポートされています。このホワイト・ペーパーでは、WebSphere Portal 7.0 と
WebSphere Process Server の統合について、構成およびセットアップを詳細に説明します。
目次
1 はじめに . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2 計画的な統合の概要 . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1 クラスター環境での手順 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3 WebSphere Portal サーバーへの前提ソフトウェアのインストール . . . . .. . . . . . . . . . . . . . . . 5
4 サーバー間の通信の有効化 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.2 シングル・サインオンの有効化 . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . 6
4.3 SSL の有効化 . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1
5 ポータル・ページおよびポートレットの構成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.1 構成タスクの使用 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.2 プロセス・サーバー・クラスターに接続するための追加タスク . . . . . . . . . . . . . . . . . . . 15
6 プロセス統合のセットアップの確認 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.1 簡単なチェック . . . . . . . .. . . . . .. . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.2 サンプル・アプリケーションの使用 . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . 17
7 プロセス対応ポータル・サーバーのフェデレーション . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . 21
8 図を使用した詳細な説明 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
8.1 ポータル・サーバーへの前提ソフトウェアのインストール . . . . . . . . . . . . . . . . . . . . . . 21
9 スタンドアロン WPS のインストール . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
10 クロスセル・セットアップ用のサンプル・プロパティー . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . 42
11 トラブルシューティングのヒント . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
12 名前空間バインディング . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
13 まとめ . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
14 リソース . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
著者について . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
1 はじめに
このホワイト・ペーパーでは、WebSphere Process Server (WPS) クライアントを使用して、IBM WebSphere
Portal 7.0 を WebSphere Process Server 7.0 製品に統合するために必要な手順について説明します。
特に、インフラストラクチャーのセットアップに焦点を当てます。このインフラストラクチャー上で実行するソ
リューションの開発については、関連文書を参照してください。
本書の対象読者は、ソリューションの詳細な知識を必要とするアーキテクト、システムの実行および再構
成が必要な管理者、このようなソリューションをセットアップするチームです。
最初に、計画的な統合の概要について説明し、その後でソリューションのセットアップ手順に進みます。デ
プロイメント担当者の作業を簡単にするために、新しい手順や複雑な手順が詳細な説明のセクションで示
され、トラブルシューティング情報も提供されます。また、単一サーバーをクラスターに変換するときに必
要となる、スタンドアロン・サーバーから管理対象サーバーへの変換についても取り上げます。
ここでは、WebSphere Portal と WPS が、2 つの異なる WebSphere Application Server インストール済
み環境にインストールされていることを前提とします。このため、2 つのシステム間の通信を有効にする
ために必要な追加手順のみ説明します。
WebSphere Portal を WPS と統合するには、いくつかの方法があります。WPS との通信に使用される手
法の違いが、それぞれの違いになります。このため、アーキテクチャー要件の違いにより、計画されたソリ
ューションで 1 つの方法が他の方法よりも適しているケースがあります。
WPS クライアントによってサポートされる EJB 通信を使用する。このオプションは、WebSphere Portal
サーバーで実行されているポートレットが、RMI (Remote Method Invocation) / IIOP (Internet Inter-ORB
Protocol) を使用して WPS に接続することをサポートします。通信のルーティング、ワークロード管理、お
よび有効なトランスポートが RMI/IIOP によってサポートされているという利点があります。
このソリューションにより、2 つのセル間に次の依存関係が導入されます。
2
• Process Server の修正によって、クライアント・サイドで対応する修正が必要になることがあります。この
場合は、両方のセルを同時に修正しなければなりません。
• クライアントのバージョンが、WebSphere Portal に使用される WebSphere Application Server のレベ
ルに一致する必要があり、さらに WPS よりも以前のバージョンでなければなりません。この条件により、
WPS も移行しないと、WebSphere Portal を新しいバージョンに移行できない状況になることがあります。
Web サービスを使用する。このオプションは、WebSphere Portal サーバーで実行されているポートレット
が、Web サービスを使用して WPS に接続することをサポートします。XML に基づくインターフェースを
使うことの利点は、通信の双方のサイドに大きな独立性を得られることであり、特に複数の処理エンジン
に接続する際に効果的です。
一方、オブジェクトを XML に変換するオーバーヘッドがあります。WPS クラスターに接続するときは、
HTTP サーバーなど、追加のワークロード・バランシング・コンポーネントを使用する必要があります。
Bspaces を使用する。このオプションは、ブラウザーで実行されているスクリプトから WPS への直接アク
セスをサポートします。WebSphere Portal サーバー上のロードが削減されますが、WPS に送られる要求
の制御も低下します。
本書では、最初のユース・ケースを取り上げます。
WebSphere Portal と WPS は、単一のデプロイメント・マネージャーによって管理される同じ WebSphere
管理セルで実行するか、2 つの独立したセルで実行することができます。後者の場合は「クロスセル・シ
ナリオ」とも呼ばれますが、次の 2 つの追加考慮事項についても検討が必要です。
• ユーザー・ディレクトリー。プロセス・ポータル・デプロイメントが複数の LDAP サービスを使用する場合
は、WebSphere Portal サーバーおよび WPS サーバーが同じユーザー・リポジトリー環境の構成を使用
する必要があります。
• 言い換えると、両方のサーバーが WebSphere Application Server のスタンドアロン LDAP を使用す
る場合は、どちらのサーバーも WebSphere Application Server LDAP の LDAP サーバーとして構成され
たものと同じ LDAP サーバーを持つ必要があり、そのサーバー名に基づいて LTPA トークンのレルム領
域名を構築しなければなりません。
プロセス・ポータル・デプロイメントがフェデレートされた LDAP を使用する場合は、すべての LDAP ディ
レクトリーで同じユーザーを利用可能である限り、別の LDAP サーバーを指定することができます。それ
以外の場合は、シングル・サインオン (SSO) が機能しません。
• VMM。セットアップで VMM (仮想メンバー・マネージャー) ファイル・レジストリーを使用する場合は、両
方のセルに同一データが含まれることを確認します。
2 計画的な統合の概要
WebSphere Portal および WPS のインストール後、システム間でポートレットの通信チャネルをセットアッ
プする必要があります。このセットアップでは、WebSphere Portal で実行されているプロセス・ポートレット
とタスク・ポートレットが、リモート EJB への RMI/IIOP 呼び出しを通じて、他のシステムで実行されてい
る WPS サーバーに接続します (図 1 参照)。
これには、交換するオブジェクトおよび可能なメソッドが双方のサイドに認識されている必要があります。
ポートレットが通信スタブおよびメッセージング・オブジェクトを利用できるようにするには、ポートレットが
プロセス・サーバー・クラスの一部へのアクセス権を持たなければなりません。
3
WebSphere Process Server のインストール時にこのクライアント・オプションを選択することにより、これら
のクラスを WebSphere Portal システムに取り込みます。この選択によってインストールが変更され、必
要なライブラリーだけがシステムに組み込まれ、プロセス・サーバーは構成されません。
図 1. クライアントを使用したポータル・サーバーとプロセス・サーバー間の通信フロー
WebSphere Process Server 自体には (クライアント・オプションも含め)、2 つのフィーチャー・パックをイ
ンストールする必要があります。最初に、これらのフィーチャー・パックをポータル・インストール済み環境
にインストールし、次に、クライアント・インストール済み環境にインストールします。これらはすべて、IBM
Installation Manager (IBM IM) を使用して行います。
インストール担当者の作業を簡単にするために、IBM IM を使用したインストール・パネルでは、WPS イン
ストールにさまざまなタスクがバンドルされています。フィーチャー・パックおよびクライアントのインストー
ルに必要なすべてのオペレーションはインストール・パネルから実行することができ、すでに正しい順番で
並んでいます。
クライアントを WebSphere Portal にインストールしたら、ポータル・サーバーとプロセス・サーバー間の
RMI/IIOP 接続を有効にする必要があります。2 つのサーバーが同じセル内で実行されている場合は、こ
の通信は自動的にセットアップされます。しかし、クロスセル環境では、セキュリティー上の理由から通常
は通信がブロックされるため、追加の手順を考慮しなければなりません。
したがって、WPS でインバウンド通信を有効にし、セル間に SSL (Secure Sockets Layer) セキュリティー
をセットアップする必要があります。次のステップでは、WebSphere Portal によって提供されるタスクを使
用し、WebSphere Portal サーバーでアウトバウンド通信を有効にし、すぐに使用可能なポートレットをセッ
トアップします。
2.1 クラスター環境での手順
WPS 対応の WebSphere Portal サーバー・クラスターをインストールするときは、フェデレーションおよび
クラスタリングの手順を、WPS サーバー統合を有効にする手順とともに、どのような順番にするのかを決
めるいくつかのオプションがあります。
4
前提ソフトウェアのインストールはいつでも行えますが、それ以外の手順は、フェデレーションおよびクラ
スタリングの後で実行しなければなりません。これらの手順によって構成が変更され、使用できなくなるか
らです。
このため、通常は最初に WebSphere Portal クラスターを作成し、ポータル機能のテスト、WPS 統合の構
成という順序で行うことが推奨されています。
フェデレーションの前に、すでにプロセス統合が構成されている場合は、以下のセクション 7「プロセス対
応ポータル・サーバーのフェデレーション」 を参照してください。
3 WebSphere Portal サーバーへの前提ソフトウェアのインストール
このセクションでは、WebSphere Portal サーバーへの WPS クライアントのインストール、またはポータ
ル・クラスターのすべてのポータル・ノードへの WPS クライアントのインストールについて説明します。
WebSphere Process Server Client バージョン 7.0.x を使用する場合は、最初に、Web サービスおよび
XML フィーチャー・パックを WebSphere Portal にインストールする必要があります。
ポータル・サーバーを実行しているシステムがネットワークへのアクセス権を持っている場合は、
WebSphere Process Server 7.0 の CD だけが必要です。すべての追加修正およびアップグレードは、イ
ンターネットからロードされます。
1. WebSphere Process Server の CD からランチパッドを起動します。
2. IBM IM をインストールするか、既存バージョンの IBM IM を更新します。
3. WebSphere Application Server を IBM IM に登録します。
4. WPS のインストールおよびすべての前提ソフトウェアを選択します。
5. 既存の WebSphere Portal サーバーを、WPS インストールのインストール・ベースとして選択します。
6. クライアント・インストール・オプションを選択します。
これらの手順の詳細については、WebSphere Process Server インフォメーション・センター のトピック 「ソ
フトウェアのインストール」 を参照してください。
4 サーバー間の通信の有効化
メモ: このセクションの説明は、クロスセルのセットアップにのみ必要です。単一セル内では、通信は自動
的にセットアップされます。
4.1 ID アサーションの有効化
クロスセルのセットアップでは、ポータル・セルからプロセス・サーバー・セルへの Common Secure
Interoperability (CSI)v2 ID アサーションをプロセス・サーバーで有効にする必要があります。これを行う
1 つの方法として、WPS で CSIv2 インバウンド認証をアクティブにします。
1. プロセス・サーバーの WebSphere Application Server 管理コンソールで、「セキュリティー」->「グロー
バル・セキュリティー」->「RMI/IIOP セキュリティー」->「CSIv2 インバウンド通信」を選択します。
2. 「ID アサーションを使用」が有効になっていることを確認します。この設定は、チェック・マークで示しま
す (図 2 参照)。
3. 「トラステッド ID」フィールドに、WebSphere Application Server 管理ユーザーの名前を入力します。別
5
の方法として「*」を使用することもできます。この場合、システムに任意のユーザーを受け入れることにな
ります。
図 2. 「グローバル・セキュリティー」->「CSIv2 インバウンド通信」のウィンドウ
4.2 シングル・サインオンの有効化
WebSphere Process Server とスタンドアロンの WebSphere Portal サーバー間またはポータル・クラスタ
ー間の SSO を有効にします。これを行うには、まず、適切な SSO ドメインを設定し、次に、サーバー間
で LTPA 鍵を交換します。最後に、必要に応じてユーザー・レジストリー構成を調整します。LTPA 鍵を
交換する 1 つの方法を以下に示します。
1. WPS の管理コンソールで、「セキュリティー」->「グローバル・セキュリティー」->「Web および SIP セキ
ュリティー」->「シングル・サインオン」を選択します。
2. シングル・サインオンのドメイン・サフィックスを入力し、SSO が有効になっていることを確認します (図
3 参照)。
「Web インバウンド・セキュリティー属性の伝搬」は省略可能ですが、有効にすると、WPS がユーザー・レ
ジストリーにアクセスして、このユーザーのセキュリティー属性をロードする必要がなくなります。
6
図 3. 「グローバル・セキュリティー」->「シングル・サインオン」のウィンドウ
3. 引き続き、WPS の管理コンソールで、「セキュリティー」->「グローバル・セキュリティー」->「認証」->「認
証メカニズムおよび有効期限」->「LTPA」を選択します。
4. パスワードとファイルの場所を定義します。「鍵のエクスポート」ボタンをクリックします (図 4 参照)。
鍵のエクスポートに成功したことを示すメッセージが表示されます。
7
図 4. 「グローバル・セキュリティー」->「LTPA」のウィンドウ
次に、SSO ドメイン内のすべてのサーバーで、LTPA (Lightweight Third-Party Authentication) 鍵の自動
生成を無効にする必要があります。
1. 「セキュリティー」->「SSL 証明書および鍵管理」->「エンドポイント・セキュリティー構成の管理」を選択
します。
2. インバウンドまたはアウトバウンドの管理スコープまでツリーを展開し、ノードを選択します (図 5 参
照)。
3. 「関連項目」で「鍵セット」をクリックし、無効にしたい鍵セット・グループを選択します。デフォルトの名前
は「NodeLTPAKeySetGroup」です。
4. 「自動的に鍵を生成」オプションの選択を解除します。
5. 「OK」と「保存」をクリックし、変更をマスター構成に保存します。
8
図 5. 「SSL 証明書および鍵管理」のウィンドウ
WebSphere Portal Server で SSO をセットアップします。
1. WebSphere Portal の管理コンソールで、「セキュリティー」->「グローバル・セキュリティー」->「Web およ
び SIP セキュリティー」->「シングル・サインオン」を選択します。
2. シングル・サインオンのドメイン・サフィックスを入力します。
3. 引き続き、ポータルの管理コンソールで、「セキュリティー」->「グローバル・セキュリティー」->「認証」->
「認証メカニズムおよび有効期限」->「LTPA」を選択します。
4. 「クロスセルのシングル・サインオン」で、プロセス・サーバーから鍵をエクスポートしたときと同じパス
ワードを入力し、エクスポートしたファイルを指定します。
5. 「鍵のインポート」をクリックし、変更をマスター構成に保存します。
6. すべてのサーバーを再始動し、変更を有効にします。
両方のシステムに存在するユーザー ID を使用してポータル・サーバー (デフォルト:
http://<servername>:10039/wps/portal) にログインし、Business Process Choreographer (BPC) クライ
アントの URL (デフォルト: http://<servername>:9080/bpc) に切り替えることにより、SSO が機能してい
ることを確認できます。
BPC クライアントにログインする必要はありません。BPC ページを開くだけです。
4.3 SSL の有効化
WPS Server と WebSphere Portal 間に SSL (Secure Sockets Layer) トラストを確立するには、ご使用に
なっているセキュリティー環境に応じて方法が異なります。1 つの方法としては、プロセス・サーバーの
SSL 署名者証明書をポータル・サーバーの SSL トラストストアに (または、その逆方向に) インポート
します。
9
しかし、クラスターが使用されている場合は、クラスター・メンバーとデプロイメント・マネージャーのすべて
の証明書を他のセルと交換しなければならないため、特に注意が必要です。
次の 2 つのステップで、プロセス・サーバーとポータル・サーバーでのインポート方法をこの順番で説明
します。
詳細については、IBM WebSphere Application Server インフォメーション・センター のトピック「アプリケー
ションとその環境の保護」およびサブトピック「通信の保護」を参照してください。
A. WPS の SSL 署名者証明書を WebSphere Portal サーバーの SSL トラストストアにインポ
ートする
1. プロセス・サーバーの WebSphere Application Server 管理コンソールで、すべてのタスクを表示し、
「セキュリティー」->「SSL 証明書および鍵管理」->「鍵ストアおよび証明書」->「NodeDefaultTrustStore」->
「署名者証明書」を選択します。
2. ポータルの接続先のプロセス・サーバーをホストしているノードに属する署名者証明書を選択します。
正しい署名者証明書を決定するには、ノード名と「発行先」列のエントリーを比較します。
3. WPS 証明書 (プロセス・サーバーでクラスターが使用されている場合は複数の証明書) をエクスポー
トするために、「抽出」をクリックします。
4. WPS 署名者証明書を格納するファイルの名前を指定します。クラスター・ノードから抽出した証明書を
保持するファイルおよび WPS Deployment Manager から抽出した証明書を保持するファイルとは別のフ
ァイル名を使用してください。例を示します。
* /tmp/wpsDM (WPS Deployment Manager の場合)
* /tmp/wpsDef1 (プロセス・サーバー・クラスターの 1 次ノードの場合)
* /tmp/wpsDef2 (プロセス・サーバー・クラスターの 2 次ノードが存在する場合)
5. プロセス・サーバーから抽出した署名者証明書を WebSphere Portal サーバーに追加します。スタンド
アロンのポータル・サーバーまたは管理対象セルのデプロイメント・マネージャーの WebSphere
Application Server 管理コンソールで、すべてのタスクを表示し、「セキュリティー」->「SSL 証明書および
鍵管理」->「鍵ストアおよび証明書」->「NodeDefaultTrustStore」->「署名者証明書」を選択します。
6. プロセス・サーバーの署名者証明書をポータル・サーバーに追加するために、「追加」をクリックしま
す。
7. 追加する証明書ごとに別名を指定します。この別名により、署名者証明書を複数のサーバー・マシンで
使用できます。ヒント: 署名者証明書のトラッキングを補助するために、ファイル名と同じ別名または類似
する別名を作成することを考慮してください。例を示します。
* wpsDM (WPS Deployment Manager の証明書)
* wpsDef1 (プロセス・サーバー・クラスターの 1 次ノードの証明書)
* wpsDef2 (プロセス・サーバー・クラスターの 2 次ノードが存在する場合の証明書)
8. 手順 4 で抽出したプロセス・サーバーの署名者証明書を格納したファイルの名前を指定します。例を
示します。
* /tmp/wpsDM (WPS Deployment Manager の場合)
* /tmp/wpsDef1 (プロセス・サーバー・クラスターの 1 次ノードの場合)
* /tmp/wpsDef2 (プロセス・サーバー・クラスターの 2 次ノードが存在する場合)
10
9. 「適用」をクリックします。
10. ポータルがプロセス・サーバー・クラスターと接続される場合は、クラスターを構成するすべての
WPS ノードおよび WPS Deployment Manager をホスティングしているサーバーについて、上記の手順を
繰り返す必要があります。
11. WebSphere Portal サーバーを再始動します。
B. WebSphere Portal の SSL 署名者証明書を WPS の SSL トラストストアにインポートする
1. ポータル・サーバーの WebSphere Application Server 管理コンソールで、すべてのタスクを表示し、
「セキュリティー」->「SSL 証明書および鍵管理」->「鍵ストアおよび証明書」->「NodeDefaultTrustStore」->
「署名者証明書」を選択します。
2. プロセス・サーバーの接続先のポータル・サーバーをホスティングしているノードに属する署名者証明
書を選択します。正しい署名者証明書を決定するには、ノード名と「発行先」列のエントリーを比較します。
3. WebSphere Portal 証明書 (ポータルでクラスターが使用されている場合は複数の証明書) をエクスポ
ートするために、「抽出」をクリックします。
4. WebSphere Portal 署名者証明書を格納するファイルの名前を指定します。クラスター・ノードから抽出
した証明書を保持するファイルおよび WebSphere Portal Deployment Manager から抽出した証明書を保
持するファイルとは別のファイル名を使用してください。例を示します。
* /tmp/portalDM (ポータル Deployment Manager の場合)
* /tmp/portalDef1 (ポータル・クラスターの 1 次ノードの場合)
* /tmp/portalDef2 (ポータル・クラスターの 2 次ノードが存在する場合)
5. ポータル・サーバーから抽出した署名者証明書を WPS サーバーに追加します。スタンドアロンのプロ
セス・サーバーまたは管理対象セルのデプロイメント・マネージャーの WebSphere Application Server 管
理コンソールで、すべてのタスクを表示し、「セキュリティー」->「SSL 証明書および鍵管理」->「鍵ストアお
よび証明書」->「NodeDefaultTrustStore」->「署名者証明書」を選択します。
あるいは、「セキュリティー」->「SSL 証明書および鍵管理」->「鍵ストアおよび証明書」->
「CellDefaultTrustStore」->「署名者証明書」を選択することもできます。
6. ポータル・サーバーの署名者証明書をプロセス・サーバーに追加するために、「追加」をクリックしま
す。
7. 追加する証明書ごとに別名を指定します。この別名により、署名者証明書を複数のサーバー・マシンで
使用できます。ヒント: 署名者証明書のトラッキングを補助するために、ファイル名と同じ別名または類似
する別名を作成することを考慮してください。例を示します。
* portalDM (ポータル・サーバーの Deployment Manager の証明書)
* portalDef1 (ポータル・サーバー・クラスターの 1 次ノードの証明書)
* portalDef2 (ポータル・サーバー・クラスターの 2 次ノードが存在する場合の証明書)
8. 手順 4 で抽出したポータル・サーバーの署名者証明書を格納したファイルの名前を指定します。例を
示します。
* /tmp/portalDM (ポータル・サーバーの Deployment Manager の場合)
* /tmp/portalDef1 (ポータル・サーバー・クラスターの 1 次ノードの場合)
* /tmp/portalDef2 (ポータル・サーバー・クラスターの 2 次ノードが存在する場合)
9. 「適用」をクリックします。プロセス・サーバーがポータル・サーバー・クラスターと接続される場合は、ク
11
ラスターを構成するすべての WebSphere Portal ノードおよび WebSphere Portal Deployment Manager
をホスティングしているサーバーについて、上記の手順を繰り返す必要があります。
10. プロセス・サーバーを再起動します。
自身のルート証明書および接続先サーバーのルート証明書が管理コンソールに表示されます (図 6 参
照)。
図 6. 署名者証明書のウィンドウ
5 ポータル・ページおよびポートレットの構成
すぐに使用可能なプロセス・ポートレットを実行するには、正しいプロセス・サーバーおよび必須ライブラリ
ーにアクセスするように、プロセス・ポートレットをデプロイおよび構成する必要があります。また、一部の
デフォルト・ページは、プロセス統合の即時開始が可能なようにセットアップできます。これに利用できる
タスクは、次のとおりです。
A) setup-base-wp.processintegration.config - このタスクは、次のことを行います。
- Java2 セキュリティーが使用されているときに、クライアント・コード・アクセスを許可します。
- プロセス・サーバーの EJB 参照を作成します。
- 必須クラス用の共有ライブラリー BPEJSFlib を作成します。
- インバウンドおよびアウトバウンドの ID アサーションをポータル・サーバーで構成します。
また、必要なリソース環境プロバイダー・エントリーを WebSphere Portal Configuration Service に作成し
ます。
たとえば、前のバージョンからの移行後、独自のタスク・ページを作成する、または既存のタスク・ページ
が存在する場合に、このタスクを使用します。
12
B) setup-wp.processintegration.config - このタスクは、上記のすべての手順を実行するだけでなく、ユー
ザーがプロセスを管理したり、プロセス・サーバーによって制御されたタスクを使用したりするデフォルト
のポータル・ページを作成します。追加手順は、ポータルの 1 次ノードで実行する場合にのみ行います。
setup-base-wp.processintegration.config タスクによって、次の構成成果物が WebSphere Portal サーバ
ーまたはクラスター・ノードに作成されます。
• 共有ライブラリーの BPElib および BPEJSFlib
• プロセス・サーバーの間接名前空間バインディング、Human Task Manager および Business Flow
Manager (クロスセルのシナリオの場合のみ)。ポータル名前空間で間接バインドを利用できる名前は、
cell/persistent/pi/BFMHome および cell/persistent/pi/HTMHome です。バインディングは、次の要素
で構成されています。
➢ 接続プロトコル、ホスト名、およびリモート・ホストのポートを指定するプロバイダー URL (たとえば、
corbaloc:iiop:host_name.domain_name:port)。
➢ プロセス・サーバーの名前空間における EJB のデフォルトの JNDI (Java Naming and Directory
Interface) 名。次のとおりです。
com/ibm/bpe/api/BusinessFlowManagerHome
com/ibm/task/api/HumanTaskManagerHome
これらのバインディングは、WPS と通信するために、「タスク・リスト」ポートレットおよび一般プロセス統合
ポートレット (「プロセス管理」および「タスク処理」) によって使用されます。
• プロセス統合用のカスタム・プロパティー (WP ConfigService のリソース環境プロバイダー・エントリー
に追加)。具体的には、次のとおりです。
一般プロパティー
• processintegration.htmJndiName
• processintegration.bfmJndiName
• processintegration.htmVersion
「タスク通知機能」タグに固有のプロパティー
• processintegration.myTasksPageUniqueName
• processintegration.pendingtasks.lifetime
「タスク・リスト」ポートレットに固有のプロパティー
• processintegration.filtersetresourcebundle
• processintegration.filterset.default.allTasks
• processintegration.filterset.default.claimedTasks
• processintegration.filterset.default.unclaimedTasks
• processintegration.filterset.default.order
5.1 構成タスクの使用
ポータル・サーバーまたはポータル・クラスターのすべてのノードで、選択したタスクを実行して、新たにイ
ンストールした WPS Client に WebSphere Portal を適応させます。
13
1. 以下のプロパティーが、wkplc.properties ファイルで設定されていることを確認します。このファイルは
wp_profile_root/ConfigEngine/properties ディレクトリーにあります。
• PortalAdminId
• PortalAdminPwd
• WasUserid
• WasPassword
あるいは、対応するコマンド行パラメーターを使用して、これらのプロパティーを指定します。2. すべての
ポータル・ノードで、wp_profile_root/ConfigEngine/properties ディレクトリーにある
wkplc_comp.properties ファイルを開き、以下のようにプロパティーの値を設定します。ほとんどのプロパ
ティーはスタンドアロンのポータル・サーバーまたはポータル・クラスターの 1 次ノードでのみ必要ですが、
すべてのポータル・ノードで整合性を保つことが推奨されています。
サンプルの構成については、第 10 章「クロスセル・セットアップ用のサンプル・プロパティー」(42 ページ
※実際のページが確定してから修正してください。) を参照してください。
• pi.IsWPSCluster - WPS クラスターに接続する場合は true を設定します。
• pi.ClusterName - プロセス・サーバー・クラスターに接続する場合にのみ必要です。このプロパティーに
は、クラスターの名前を設定します。プロセス・サーバーのゴールデン・トポロジーが使用されている場合
は、複数のクラスターがプロセス・サーバーのインストール済み環境に存在するため、この場合は
「default.AppTarget」を選択します。
• pi.IsCrossCell - WPS とは異なるセルで WebSphere Portal を実行する場合は true を設定し、それ以
外の場合は false を設定します。
• pi.ProcessServerHostAddress - このプロパティーはクロスセルにのみ必要です。プロセス・サーバーの
ホスト名を指定します。「5.2 プロセス・サーバー・クラスターに接続するための追加タスク」(15 ページ
※実際のページが確定してから修正してください。) に記されているように、クラスターの場合は、開始時
に単一のホストを選択し、後から、他のクラスター・メンバーの情報を追加します。
• pi.ProcessServerBootstrapPort - このプロパティーはクロスセルにのみ必要です。プロセス・サーバー
のブートストラップ・ポートを設定します。「5.2 プロセス・サーバー・クラスターに接続するための追加タス
ク」(15 ページ ※実際のページが確定してから修正してください。) に記されているように、クラスターの
場合は、pi.ProcessServerHostAddress で定義されたホストのポートを選択し、後から、他のクラスター・メ
ンバーの情報を追加します。
• pi.NodeName. このプロパティーは単一セルにのみ必要です。プロセス・サーバーが位置するノードの名
前を設定します。
• pi.ServerName - このプロパティーは単一セルにのみ必要です。プロセス・サーバーが位置するサーバ
ーの名前を設定します。
• pi.ProcessArtifactsLocation - 2 次ノードに必要な唯一のプロパティーです。リモート・プロセス成果物
の .jar ファイルを置くことができるフォルダーを設定します。
3. ポータル・クラスターでプロセス統合を有効にする場合は、対応する WebSphere Application Server
のノード・エージェントが開始され、自動同期が有効になっていることを確認します。
14
4. 各ポータル・ノードの wp_profile_root/ConfigEngine ディレクトリーで、構成コマンドを実行します。
• ポータルによって提供される「プロセス統合」ページを使用してプロセス統合をセットアップし、プロセ
ス・ポータル環境を移行しているのではない場合は、次のコマンドを入力します。
MicrosoftR WindowsR: ConfigEngine.bat setup-wp.processintegration.config -DwasPassword=password
UNIXR: ConfigEngine.sh setup-wp.processintegration.config -DwasPassword=password
• ポータルによって提供される「プロセス統合」ページを使用せずにプロセス統合をセットアップする場合、
またはプロセス・ポータル環境を移行した場合は、次のコマンドを入力します。
Windows: ConfigEngine.bat setup-base-wp.processintegration.config -DwasPassword=password
UNIX: ConfigEngine.sh setup-base-wp.processintegration.config -DwasPassword=password
• ポータル・クラスターでセットアップ・コマンドを実行する場合は、「Web モジュールの管理」ポートレット
を使用して、新たにデプロイされたポートレットの processtemplates.war と tasklistportlet.war を手動
でアクティブにする必要があります。
5. ポータル・サーバーまたはクラスターを再始動します。プロセス・サーバーによって管理されるビジネ
ス・プロセス・アプリケーションとともに機能することが必要なすべてのオブジェクトとプロパティーが、ポー
タル環境での表示および使用のために構成されます。
これで、「マイ・プロセス」ページと「マイ・タスク」ページが、「プロセス統合」ページのデフォルトのページと
して利用できるようになります。
5.2 プロセス・サーバー・クラスターに接続するための追加タスク
• 上記タスクによる名前空間バインディングのセットアップにより、単一ポータルまたはポータル・クラスタ
ーが単一のプロセス・サーバーに接続されます。プロセス・サーバー・クラスターが使用されている場合、
EJB はサーバーではなくクラスターにバインドされるため、EJB はターゲットの名前空間の異なる場所に
存在します。
したがって、これを反映するために、間接バインディングの名前空間の部分を変更する必要があります。
新しい名前空間の部分は次のとおりです。
cell/clusters/<process.server_cluster.name>/com/ibm/bpe/api/BusinessFlowManagerHome
• クロスセルのセットアップで、構成されたプロセス・サーバーが停止している場合は、プロセス・サーバ
ー・クラスター内で実際には他のクラスター・メンバーがまだ実行されている可能性があるにもかかわらず、
プロセス・ポートレットは機能しません。
• クラスターで実行されているすべてのメンバーにアクセスできるようにするには、名前空間バインディン
グのプロバイダー URL を変更し、利用できるすべてプロセス・サーバー・ノードへの接続を可能にする必
要があります。これを行うには、ホストとポートのペアをコンマ区切りのリストとしてプロバイダー URL に
追加します。サンプルについては、次のセクションを参照してください。
名前空間バインディングを変更する詳細手順
WPS サーバー・フェイルオーバー用の 2 次クラスター・ノードを追加するには、以下の手順に従います。
1. 「_BFM_Binding」のバインディングを変更します。
a) ポータル・サーバーの管理コンソールで、「環境」->「ネーミング」->「名前空間バインディング」->
「_BFM_Binding」を選択します。
15
b) JNDI 名を
「cell/clusters/process.server_cluster.name/com/ibm/bpe/api/BusinessFlowManagerHome」に変更しま
す。
c) クロスセルのセットアップでは、追加ホストとポートの組み合わせを示すコンマ区切りの値を使用して
残りのノードを追加することにより、プロセス・サーバー・クラスターの 2 次ノードを指定するようプロバイ
ダー URL も変更します。
2 番目のホスト、つまりホスト 2 とブートストラップ・ポート 2 のクラスター・ペアを追加すると、エントリ
ーは次のようになります。
corbaloc:iiop:host_name1.domain.name:boot.strap_Port1,:host_name2.domain.name:boot.strap_Port2
単一ホストと 2 つのホストの場合の corbaloc の例を示します (host:port の組み合わせの間にある、
「,:」の部分に注目してください)。
corbaloc:iiop:wps211.de.ibm.com:2811
corbaloc:iiop:wps211.de.ibm.com:2811,:wps210.de.ibm.com:2811
2. これらの手順を「_HTM_Binding」にも繰り返します。
3. ポータル・サーバーまたはクラスターを再始動します。プロセス・サーバーによって管理されるビジネ
ス・プロセス・アプリケーションとともに機能することが必要なすべてのオブジェクトとプロパティーが、ポー
タル環境での表示および使用のために構成されます。
6 プロセス統合のセットアップの確認
WebSphere Portal と WebSphere Process Server 間の統合をセットアップする上記の手順が完了したら、
統合が成功したことを確認できます。
6.1 簡単なチェック
以下の手順で、簡単なチェックが可能です。
1. ポータル・サーバーで、必要な成果物、プロパティー、ページ、およびポートレットが使用できるかどう
かチェックします。これには、すぐに使用可能なポートレットがデプロイされ、標準ページが作成されてい
なければなりません。
a) WPS サーバー/クラスターおよび WebSphere Portal を始動します。
b) ポータル管理者のユーザー ID を使用して、WebSphere Portal にログインします。
c) 「アプリケーション」を選択します (図 7 参照)。「ようこそ」、「マイ・プロセス」、および「マイ・タスク」の
各ページがある「プロセス統合」というタブが表示されます。また、「マイ・プロセス」を選択すると、「プロセ
ス管理」ポートレットがエラーなしで表示されます。
16
図 7. 「プロセス管理」ポートレット
d) 「マイ・タスク」を選択すると、「タスク・リスト」ポートレットが表示されます。同様に、エラーは示されませ
ん (図 8 参照)。
図 8. 「マイ・タスク」ポートレット
6.2 サンプル・アプリケーションの使用
プロセス・アプリケーションを持っていない場合は、WebSphere Process Server とともに提供されるテス
ト・アプリケーションの「Business Process Choreographer Installation Verification Test」(bpcivt.ear) を使
用できます。あるいは、本書の「ダウンロード」に添付されている TravelBookingApp.ear を使用すること
もできます。
17
アプリケーションをインストールするには、次の手順を実行します。
1. WPS の WebSphere Application Server 管理コンソールにログインし、「アプリケーション」->「エンター
プライズ・アプリケーション」を選択します。
2. TravelBookingApp.ear ファイルをインストールし、構成に保管します。
3. 「エンタープライズ・アプリケーション」リストでアプリケーションを選択し、「開始」をクリックします。
WPS でのインストール・プロセスに問題がある場合は、WebSphere Process Server インフォメーション・
センターの「コンソールを使用したエンタープライズ・アプリケーション・ファイルのインストール」 を参照し
てください。
クロスセルのデプロイメントでは、次の手順を使用して、プロセス成果物をポータル・サーバーにコピーす
る必要があります。
1. ポータル・サーバーで、pi.ProcessArtifactsLocation プロパティーで定義されたフォルダーを作成しま
す。
デフォルトは、ポータル・サーバー・プロファイルの processArtifacts フォルダーです。
2. プロセス・サーバーでファイル・システムを開き、<Process Server Home>\profiles\<profile
name>\installedApps\<node name>\TravelBookingApp.ear に移動します。
3. このフォルダー内の TravelBooking.jar をポータル・サーバー・マシンにコピーし、ポータル・サーバ
ー・プロファイルの processArtifacts フォルダーに貼り付けてください。
4. ポータルにログインし、プロセスのインスタンスを作成します。
a) ポータルで「アプリケーション」->「プロセス統合」->「マイ・プロセス」を選択します。
b) 「プロセス管理」ポートレットで「プロセス・テンプレート」タブを選択します。TravelRequestProcess1 プ
ロセスが表示されます (図 9 参照)。
c) 「TravelRequestProcess1」を選択し、「新規インスタンス」ボタンをクリックします。
図 9. 「プロセス・テンプレート」タブ
d) 入力フォームが表示されます (図 10 参照)。フィールドに値を入力し、「送信」をクリックします。
18
図 10. TravelRequestProcess1 の入力フォーム
5. ポートレットの「プロセス」タブに戻ります。プロセスがリストに表示されています (図 11 参照)。
図 11. リストに表示されたプロセス・インスタンス
6. 「マイ・タスク」ページに切り替えます。「タスク・リスト」ポートレットに、申請されるのを待っている承認
要求が表示されます (図 12 参照)。
19
図 12. 要求の承認
7. タスクを選択して「申請」ボタンをクリックすることにより、タスクを申請します。タスクの名前
「approveRequest」がリンクに変わります。リンクをクリックして、このタスクを開きます (図 13 参照)。
タスク・ページが「承認」ポートレットで開かれます。
図 13. approveRequest タスク
8. 要求を承認するには、「完了」をクリックします。要求がタスク・リストから削除され、「プロセス管理」ポ
ートレット内のプロセスが「完了」状態となります。
これで、プロセス統合の確認が終了しました。
20
7 プロセス対応ポータル・サーバーのフェデレーション
パフォーマンス上の理由で、またはクラスターの移行後に、スタンドアロンのポータル・サーバーをクラス
ターに変換することが必要になる場合があります。どちらのケースでも、すでにプロセス統合が機能して
いるポータル・サーバーを、デプロイメント・マネージャーによって管理される WebSphere セルに組み込
む必要があります。
この手順をフェデレーションと呼びます。
すでにプロセス対応のポータル・サーバーがフェデレートされている場合は、シングル・サーバー・セットア
ップのほとんどの構成を再利用できますが、一部の構成はセル構成によって上書きされ、フェデレーショ
ン後に調整する必要があります。
必要な変更は、(1) IIOP セキュリティー・プロトコルの変更と (2) 新規セルでの名前空間バインディング
の作成です。これを行うには、post-federationwp.processintegration.config タスクを次のように実行しま
す。
Windows: ConfigEngine.bat post-federation-wp.processintegration.config -DWasPassword=password
UNIX: ConfigEngine.sh post-federation-wp.processintegration.config -DwasPassword=password
8 図を使用した詳細な説明
上記の一部のセクションを、図を使用して詳細に説明します。
8.1 ポータル・サーバーへの前提ソフトウェアのインストール
どのインストール手順も、開始する前に更新するアプリケーション・サーバーのインストール済み環境のす
べてのサーバーが (ノード・エージェントも含め) 停止していることを確認してください。
インターネット接続がない場合
インターネット接続を利用できない場合は、別のシステムを使用して、WPS の バージョン 7.0.0.2 にアッ
プグレードするために必要な追加パッケージをダウンロードできます。必要なパッケージは次のとおりで
す。
• IBM Installation Manager の最新バージョン (少なくとも 1.4.0) をダウンロードします。
• 適切な V7.0.0.2 フィックス・パックを WebSphere Enterprise Service Bus または WebSphere Process
Server のダウンロード・サイトからダウンロードします。パッケージはディスク内の一時的な場所にダウン
ロードします。
wpsclient.7002.repository.zip (WebSphere Process Server Client の場合)
wesb.7002.repository.zip (WebSphere Enterprise Service Bus の場合)
• WebSphere Application Server V7 Feature Pack フィックス・パック・リポジトリー、および WebSphere
Application Server インポート・リポジトリーのローカル・コピーをまだインストールしていない場合は、以下
の場所からダウンロードします。
WebSphere Application Server V7 Feature Pack for XML V1.0.0 Fix Pack 5
WebSphere Application Server V7 Feature Pack for Service Component Architecture (SCA) V1.0.1 Fix
Pack 3
21
WebSphere Application Server V7 インポート・リポジトリー
WebSphere Application Server V7 Feature Pack for XML V1.0.0 インポート・リポジトリー
WebSphere Application Server V7 Feature Pack for Service Component Architecture (SCA) V1.0.1 イン
ポート・リポジトリー
ダウンロードしたリポジトリーを IBM IM が検出できるようにするために、これらのリポジトリーを IBM IM
に登録する必要があります。
インターネット接続がある場合
以下の手順はクライアントのインストールを示しています。ただし、既存のインターネット接続、またはすべ
ての追加リポジトリーの既存の登録があるものとします。
1. WPS 7.0.0.0 パッケージ (Windows の場合は WPS_v7_Win32_Install.zip) をアンパックします。
2. ランチパッド (launchpad.exe) を起動します。
3. すでに、WebSphere Portal のインストール済み環境とともに WebSphere Application Server がインス
トールされているので、「既存の WebSphere Application Server にインストール」を選択し、1 から 5 の
ステップを実行します (図 14 参照)。
図 14. WPS ランチパッド
22
メモ: 図のステップ 4 と 5 では、フィーチャー・パックの更新とクライアントのインストールを組み合わせ
ることができます。以下の手順ではこの組み合わせを実行しており、この方法によってユーザー対話が少
なくなります。それぞれのインストール・パッケージでこれを個別に行うときは、各パッケージに示された手
順を実行します。パッケージの順番は次のとおりです。
a) XML Feature Pack
b) SCA Feature Pack with SDO
c) WebSphere Process Server Client
組み合わせる場合は、IBM IM によって自動的に依存関係が検出され、正しい順序でインストールされま
す。それでは、上図 14 に示された 5 つのステップの詳細を見ていきましょう。
ステップ 1. IBM Installation Manager のインストールまたは更新
このステップでは、サーバー上でインストールまたはアップグレードする IBM IM の一時バージョンが表示
されます。IBM IM はソフトウェアのインストールを管理するため、既存のソフトウェア・インストール環境を
アップグレード、変更、または削除するサーバーに位置している必要があります。
ここでは、IBM IM によって、システムでバージョン 1.3.3 が実行されていることが示され、バージョン
1.4.0 が見つかったために、この新しいバージョンにアップグレードするよう求められています (図 15 参
照)。
図 15. 更新を求める IBM IM のウィンドウ
自動アップグレードは、インターネット接続が存在する場合にのみ利用できます。インターネット接続がな
いシステムでは、最新の IBM IM をインストールすることで、アップグレードの必要がなくなります。
実際には、インターネット接続がある場合でも、クライアントを複数のシステムにインストールするときは、
この方法が適しているでしょう。この場合は、最新バージョンを 1 度だけダウンロードするので、特にイン
ターネット接続が低速のときなど、次回のインストール・プロセスが大幅に迅速化する可能性があります。
ご使用条件に同意した後、1.4.0 バージョンの IBM IM がダウンロードされ、サーバーにインストールされ
ます。IBM IM の再始動後、このステップが完了し、IBM IM を閉じることができます。
23
ステップ 2. WebSphere Application Server の更新
WebSphere Portal Server のインストールは WebSphere Application Server 7.0.0.11 に基づいています。
これは、必要な WPS のバージョンよりも以降のバージョンであるため、このステップは省略できます。
ステップ 3. WebSphere Application Server のインポート
WebSphere Application Server 7.0 は IBM IM を使用してインストールされたものではないため、IBM IM
ではアプリケーション・サーバーの情報を利用できません。既存の WebSphere Application Server のイン
ストール済み環境をインポートすることで、管理情報が IBM IM で利用可能になります。これを行うには、
次の手順に従います。
1. このステップをクリックし、最初の IBM IM パネルで「インポート」を選択します。(「インストール」パネル
によって WebSphere Application Server のバージョンに関する必要なメタ情報が IBM IM に追加される
ため、「インポート」リンクは「インストール」パネルから始めた場合にのみ利用できることがあります。)
2. インポートするポータル・アプリケーション・サーバーのインスタンスを選択します。場所は、「ドロップダ
ウン」メニューから選択できます。
3. 「次へ」ボタンをクリックし、アプリケーション・サーバーのインストール済み環境に関する情報を表示し
ます。次のウィンドウでは、ポータルのインストール済み環境が WebSphere Application Server 7.0.0.11
に基づいていることもわかります (図 16 参照)。
4. 「インポート」ボタンをクリックし、アプリケーション・サーバーのインストール済み環境に関する情報をイ
ンポートします。
図 16. 「既存の WebSphere インストールをインポート」ウィンドウ
24
5. インストールが成功したことを確認するために、「ファイル」メニューから「インストール済みパッケージ
のリスト」アクションを使用して、インストールされたすべてのパッケージのリストを表示できます (図 17
参照)。
図 17. インストールされたパッケージのリスト
上図からわかるように、複数のアプリケーション・サーバーのインストール済み環境が含まれている場合、
それぞれのインストール済み環境は名前の固有のサフィックスで識別されます。以降のステップで名前が
必要となるので、より多くのアプリケーション・サーバーのインストール済み環境が IBM IM に登録されて
いる場合は、正確な名前を知っておくことが重要です。
6. IBM IM を閉じ、インストール・パネルから次のステップを開始します。
25
ステップ 4 および 5: フィーチャー・パックの更新、WebSphere Process Server クライアントのインストー
ル
このステップでは、必要なフィーチャー・パックおよび WPS クライアントをアプリケーション・サーバーのイ
ンストール済み環境に追加します。
この例では、フィーチャー・パックがインストールされていない環境から開始したので、更新機能ではなく、
インストール機能を IBM IM で選択する必要があります。
1. 「インストール」パネルで、「ステップ 4」または「ステップ 5」をクリックすることにより、IBM IM を開始し
ます。
2. 選択した内容によっては、この操作を始めるために、メインの IBM IM パネルで「インストール」ボタン
のクリックが必要になることがあります。コマンド行から直接 IBM IM を開始することもできましたが、イン
ストール・パネルから開始することにより、必要なリポジトリーが追加されます。
前述のように、ここでは WebSphere Process Server と XML および SCA 用のフィーチャー・パックを選
択することにより、フィーチャー・パックのインストールとクライアントのインストールを 1 つのアクションに
組み合わせます。インストールするフィーチャーに関する詳細は、後のパネルで選択できます。
図 18 に示すように、WebSphere Process Server バージョン 7.0.0.0 だけが提供されています。これは
CD に含まれていますが、インストールしたいのはバージョン 7.0.0.2 です。
図 18. 「パッケージのインストール」ウィンドウ
26
3. 製品の新しいバージョンのフィックス・パックをインストールするには、「他のバージョン、フィックス、お
よび拡張機能の確認」ボタンをクリックします。IBM IM によって、製品の新しいバージョンがネットワークで
検索されます。
4. 「次へ」をクリックします。次のウィンドウでは、7.0.0.2 バージョンがインストール用に選択されています
(図 19 参照)。
図 19. 更新された「パッケージのインストール」ウィンドウ
5. 「次へ」をクリックします。別のウィンドウに、このレベルの推奨 Fix が表示されます (図 20 参照)。変
更せずに受け入れ、「次へ」をクリックします。
27
図 20. 推奨 Fix のウィンドウ
7. 次のウィンドウでご使用条件に同意し、「次へ」をクリックします。これで、インストールするソフトウェア
が選択できたので、どこにインストールするのかを決める必要があります。
8. 次のウィンドウで、インストールする場所の指定を求められます (図 21 参照)。正しいアプリケーショ
ン・サーバーのインストール済み環境を選択します。複数のインストール済み環境がリストされている場合
は、正しいインストール・ディレクトリーにチェック・マークを付けてください。
28
図 21. 場所の選択のウィンドウ
9. 「次へ」をクリックし、図 22 に示すウィンドウを表示します。このウィンドウでは、インストールする実際
のコンポーネントを選択する必要があります。いくつかのコンポーネントが事前に選択されていますが、使
用したいコンポーネントではありません。プロセス・サーバー全体のインストールが選択されていますが、
インストールしたいのはクライアントだけです。
10. このため、WebSphere Process Server 7.0.0.2 の下にある WebSphere Process Server のボックスの
チェック・マークを外します。この手順は特に重要です。チェック・マークを外さないと、プロセス・サーバー
全体がインストールされます。「次へ」をクリックします。
29
図 22. フィーチャーの選択のウィンドウ
11. 要約ウィンドウが表示されます。このウィンドウには、インストールするものとして、クライアント・オプ
ションだけが選択されています (図 23 参照)。
30
図 23. 要約ウィンドウ
12. 「インストール」ボタンをクリックし、フィーチャー・パックとプロセス・サーバー・クライアントをインストー
ルします。インストールの成功を示すウィンドウが表示されます。このウィンドウでは、「プロファイル管理
ツール」(PMT) オプションが事前に選択されています (図 24 参照)。このオプションを選択したままにし
ます。
31
図 24. インストールの成功を示すウィンドウ
13. 「終了」をクリックしてプロファイル管理ツールを開始し、wp_portal プロファイルを選択します (図 25
参照)。ポータル・プロファイルの標準名は「wp_profile」で、標準のインストール済み環境にのみこのプロフ
ァイルが存在します。
64 ビット・システムではプロファイル管理ツールを使用できないので、代わりに、コマンド行から拡張を実
行する必要があります (以降の説明については、セクション 8.2 を参照してください)。
図 25. wp_portal プロファイル
32
14. wp_profile プロファイルを選択し、新たに有効になった「拡張」ボタンをクリックします。「拡張の選択」
ウィンドウが表示されます (図 26 参照)。「SCA with SDO」を選択して続行します。
このウィンドウでプロセス・サーバーの拡張も選択できる場合は、クライアントだけでなく、プロセス・サー
バー全体がインストールされていると考えられます。このような場合は、プロセス・サーバーをアンインスト
ールし、クライアントのインストールを再実行する必要があります。
図 26. 拡張の選択のウィンドウ
フィーチャー・パック「SCA Version 1.0 with SDO 2.1.1」の拡張が完了すると、プロファイルに関する詳細が
PMT ウィンドウに表示されます (図 27 参照)。
図 27. プロファイルの詳細
(XML フィーチャー・パックによる拡張は、SCA の拡張の前提となっているので自動的に実行されること
に注意してください。)
15. PMT を閉じて、IBM IM に戻ります。
33
8.2 コマンド行を使用したポータル・サーバーの拡張
これを行うには、以下の手順を実行します。
1. WebSphere Portal のファイル・システムを開き、c:\IBM\WebSphere\AppServer\bin に移動します。
2. プロファイルを拡張するために、manageprofiles コマンドを実行します。
<manageprofiles> -augment -templatePath <AppServer>\profileTemplates\SCA\default.sdo
-profileName <Portal profile name>
拡張コマンドが成功したことを示すメッセージが表示されます。
3. どのような拡張がプロファイルに行われたのかを確認するには、次のコマンドを使用します。
<manageprofiles> -listAugments -profileName <profile name>
出力は図 28 のようになります。
図 28. 拡張のリスト
9 スタンドアロン WPS のインストール
このセクションでは、テスト目的でスタンドアロンの WPS をインストールする方法を説明します。実動に
関するすべてのインストールについては、WebSphere Process Server Version 7.0.0.2 インフォメーション・
センター を参照してください。
メモ: 64 ビット・システムにインストールする場合は、次の点に留意してください。
• PMT を使用できません。代わりに、コマンド行を使用してプロファイルを作成する必要があります。
• IBM IM はブラウザーで開かれます。IBM IM は Microsoft Internet Explorer 8 では良好に動作しませ
ん。このため、開始する前に、デフォルトのブラウザーを Mozilla Firefox に設定してください。
1. インストールを開始するために、プロセス・サーバーのメディアのルート・ディレクトリーでランチパッド
の実行可能ファイルを見つけ、これを始動します。
2. 「ランチパッド」ウィンドウで「新規インストール」を選択し、プロセス・サーバーをインストールする場所
を指定します (図 29 参照)。次に、ウィンドウ内のステップ 1 のリンクをクリックし、WebSphere
Application Server のインストールをこのスペースに実行します。
34
図 29. 「ランチパッド」ウィンドウ
これで、WebSphere Application Server がインストールされ、IBM IM にインポートされます。
3. 次に、ステップ 2 を実行します。IBM IM の「パッケージのインストール」ウィンドウが表示されます。こ
のウィンドウでは、プロセス・サーバーとその前提ソフトウェアがすでに選択されています。しかし、最新の
レベルではありません。
4. 最新バージョンを表示するために、「他のバージョン、フィックス、および拡張機能の確認」ボタンをクリ
ックします。
ウィンドウは図 30 のようになります。
35
図 30. 「パッケージのインストール」ウィンドウ
5. 次のウィンドウで、プロセス・サーバーの最新のフィックス・パック (現行は 7.0.0.2) を選択します (図
31 参照)。
36
図 31. 最新のフィックス・パックの選択
6. ご使用条件に同意した後、選択したソフトウェアをインストールできる既存のパッケージ・グループを示
すウィンドウが表示されます (図 32 参照)。パッケージのインストールには既存の Application Server
が必要なので、利用可能なすべての Application Servers が表示されます。
この例では、1 つしかないので簡単ですが、既存の複数の Application Server がターゲットとして表示さ
れている場合は、インストール・ディレクトリーの値をチェックして、正しいものを選択してください。
37
図 32. パッケージ・グループの選択
7. 「次へ」をクリックします。要約ウィンドウが表示されます (図 33 参照)。
38
図 33. 要約ウィンドウ
8. 「インストール」をクリックします。インストールの終了後、PMT を開始するオプションを選択します。プ
ロファイルがない状態でツールが表示されるので、「作成」ボタンをクリックして、プロセス・サーバーのプ
ロファイルを作成します。「環境の選択」ウィンドウが表示されます (図 34 参照)。
9. 「スタンドアロンのプロセス・サーバー」オプションを選択し、「次へ」をクリックします。
39
図 34. 「環境の選択」ウィンドウ
10. 次のウィンドウで、WebSphere Application Server の標準設定を入力するか、受け入れます。
「サンプル Business Process Choreographerの構成」オプションを選択することが重要です (図 35 参
照)。このオプションを選択することにより、プロファイルの作成中に、サンプル・プロセスのランタイム環境
が作成されます。これは、開発およびテスト用には十分です。
40
図 35. プロファイルの構成オプション
11. プロファイルが作成されると、「プロファイル作成の完了」ウィンドウが表示されます (図 36 参照)。
41
図 36. 「プロファイル作成の完了」ウィンドウ
12. 「終了」をクリックし、表示されるファースト・ステップ・コンソールで、Process Server を始動します。
Process Server が実行されたらブラウザーを開き、Application Server の管理コンソールおよび
Business Process Choreographer Explorer にログインし、システムの機能をテストします。
コンソールでは、新規プロセス定義をデプロイし、デプロイされた J2EE 成果物の状態をチェックできるの
に対し、Explorer では、新規プロセスのインスタンスを開始および管理できます。URL に必要なポートは、
プロファイルのプロパティー・ディレクトリーの portdef.props ファイルに記述されています。デフォルトの
URL は次のとおりです。
• HTTP://<servername>:9080/bpc (Business Process Choreographer Explorer の場合)
• HTTP://<servername>:9060/ibm/console (管理コンソールの場合)
10 クロスセル・セットアップ用のサンプル・プロパティー
リスト 1 は、wkplc_comp.properties ファイルのスニペットです。プロセス・サーバー環境をセットアップす
るポータル・タスクの構成セクションが示されています。このサンプルは、スタンドアロン・プロセス・サー
バーへのクロスセル・セットアップ用に構成されています。
42
リスト 1. wkplc_comp.properties ファイルのスニペット
############################################################################
###
#Properties for WebSphere Portal integration with WebSphere Process Server
#The following properties are used to configure integration with
#WebSphere Process Server. You must provide information about the
#already installed WebSphere Process Server.
############################################################################
###
#pi.IsCrossCell
#Set this value to true if the WebSphere Process Server installation that
WebSphere Portal
#connects to is located in another cell. If WebSphere Process Server is not in
another cell,
#set the value to false.
#Value: true or false
#Example: No examples are available.
#Default: true
pi.IsCrossCell= true
#pi.ProcessServerHostAddress
#This property is used only if the pi.IsCrossCell value is set to true.
#The server host name address of the WebSphere Process Server installation in
another cell.
#Value: No values are available.
#Example: No examples are available.
#Default: No default
pi.ProcessServerHostAddress=BL3D8022.boeblingen.de.ibm.com
#pi.ProcessServerBootstrapPort
#This property is used only if the pi.IsCrossCell value is set to true.
#The bootstrap port of the WebSphere Process Server installation in another
cell.
#Value: port number
#Example: No examples are available.
#Default: No default
pi.ProcessServerBootstrapPort=2810
#pi.ProcessArtifactsLocation
#This property is used only if the pi.IsCrossCell value is set to true.
#The directory in which the process artifacts are located.
#Value: directory path
#Example: No examples are available.
43
#Default: ${USER_INSTALL_ROOT}/processArtifacts
pi.ProcessArtifactsLocation= ${USER_INSTALL_ROOT}/processArtifacts
#pi.IsWPSCluster
#This property is used only if the pi.IsCrossCell value is set to false.
#Set this value to true if WebSphere Portal connects to a WebSphere Process
Server cluster in the same cell.
#If WebSphere Portal connects to a WebSphere Process Server cluster in different
cell, set the value to false.
#Value: true or false
#Example: No examples are available.
#Default: No default.
pi.IsWPSCluster=
#pi.ClusterName
#This property is used only if the pi.IsCrossCell value is set to false AND
pi.IsWPSCluster value is set to true.
#The name of the WebSphere Process Server cluster.
#Value: cluster name
#Example: No examples are available.
#Default: No default.
pi.ClusterName=
#pi.NodeName
#This property is used only if the pi.IsCrossCell value is set to false AND
pi.IsWPSCluster value is set to false.
#This value is the name of the node of the WebSphere Process Server server.
#Value: node name
#Example: No examples are available.
#Default: No default.
pi.NodeName=
#pi.ServerName
#This property is used only if the pi.IsCrossCell value is set to false AND
pi.IsWPSCluster value is set to false.
#This value is the name of the WebSphere Process Server server.
#Value: server name
#Example: No examples are available.
#Default: No default.
pi.ServerName=
##### END WP.PROCESSINTEGRATION.CONFIG PROPERTIES #####
44
11 トラブルシューティングのヒント
統合プロセスにおける一般的な問題のトラブルシューティングのヒントについて検討しましょう。
問題 1: リポジトリーが不明である
リポジトリーが不明であるという問題を回避するには、以下の手順を実行してください。
1. IBM IM を開き、すべてのリポジトリーを削除します。
2. インストール CD からランチパッドを開きます。
3. 「更新」オプションを使用するか (IBM IM のメイン・ウィンドウに移動)、「インストール」オプションを使
用します (IBM IM のインストール・オプションに直接移動)。この方法により、必要なリポジトリーが自動的
に IBM IM に追加されます。
問題 2: ポートレットを利用できない
「ポートレットを利用できません」というエラー・メッセージが表示された場合は、次の 2 つの問題をチェッ
クします。
• 証明書が欠落している
• HTM API が見つからない
問題 3: 証明書が欠落している
ポータル・サーバー・ログに、リスト 2 に表示したログがある場合は、ポータルとプロセス・サーバー (クラ
スター) 間で証明書 (すべてではない) が交換されていることを示しています。
リスト 2. ポータル・サーバー・ログ
[22.07.10 16:26:21:578 CEST] 00000046 ORBRas E
com.ibm.ws.security.orbssl.WSSSLClientSocketFactoryImpl createSSLSocket
WebContainer : 3 JSSL0080E: javax.net.ssl.SSLHandshakeException - The client and
server could not negotiate the desired level of security. Reason:
com.ibm.jsse2.util.g: PKIX path building failed:
java.security.cert.CertPathBuilderException: PKIXCertPathBuilderImpl could not
build a valid CertPath.; internal cause is:
java.security.cert.CertPathValidatorException: The certificate issued by
CN=BL3D8022.boeblingen.de.ibm.com, OU=Root Certificate, OU=BL3D8022Node04Cell,
OU=BL3D8022Node04, O=IBM, C=US is not trusted; internal cause is:
java.security.cert.CertPathValidatorException: Certificate chaining error
javax.net.ssl.SSLHandshakeException: com.ibm.jsse2.util.g: PKIX path building
failed: java.security.cert.CertPathBuilderException: PKIXCertPathBuilderImpl
could not build a valid CertPath.; internal cause is:
java.security.cert.CertPathValidatorException: The certificate issued by
CN=BL3D8022.boeblingen.de.ibm.com, OU=Root Certificate, OU=BL3D8022Node04Cell,
45
OU=BL3D8022Node04, O=IBM, C=US is not trusted; internal cause is:
java.security.cert.CertPathValidatorException: Certificate chaining error
問題 4: HTM API が見つからない
リスト 3 のトレースは、間接バインディングの解決で問題が発生した可能性があることを示しています。
リスト 3. 「HTM API が見つからない」ことを示すトレース
[4/12/10 18:48:08:413 CEST] 00000041 TaskQueryServ E
com.ibm.wps.taskqueryservice.impl.TaskQueryServiceFactoryImpl
TaskQueryServiceFactory EJPTI0011E: The HTM API cannot be found at location
cell/persistent/pi/HTMHome
com.ibm.portal.taskqueryservice.TaskQueryServiceUnavailableException:
EJPTI0008E: Unable to access remote EJB cell/persistent/pi/HTMHome.
at
com.ibm.wps.taskqueryservice.impl.HtmTaskQueryService.<init>(HtmTaskQuerySer
vice
.java:80)
at
com.ibm.wps.taskqueryservice.impl.TaskQueryServiceFactoryImpl.createServiceI
nsta
nce(TaskQueryServiceFactoryImpl.java:118)
バインディングが機能していないというような問題をデバッグするには、第 12 章「名前空間バイン
ディング」(46 ページ
※実際のページが確定してから修正してください。) に記述されている方
法を使用するか、以下のトレース文字列を使用してさらにトレース情報を入手します。
*=info: com.ibm.ws.http.*=all: com.ibm.ws.webcontainer.*=all:
com.ibm.ws.webcontainer=all: com.ibm.ws.security.*=all: SASRas=all:
ORBRas=all:
com.ibm.ws.crypto.*=all: com.ibm.ws.ssl.*=all
45
問題 5: プロセスの初期化中の ClassNotFoundException
プロセスの新規インスタンスの初期化中に、クロスセル・システムの「プロセス管理」ポートレットで次のエ
ラーが表示されます。
org.eclipse.emf.ecore.xmi.ClassNotFoundException - Class 'travelRequestInput' not found.
(file:///C:/IBM/wp_profile/, 2, 225)
このエラーは、プロセス成果物がポータル環境にコピーされていないために発生することがあります。
12 名前空間バインディング
管理者がリモート・プロセス・サーバーへの EJB 接続を構成できるようにするため、およびシステムを他
のサーバーに移動する際のリダイレクトをサポートするために、JNDI 名前空間を使用してポートレットとリ
46
モート・システム間のバインディングが定義されます。
単一セルで稼働しているシステムには、同じ名前空間を共有することにより、リンクが自動的に行われる
という利点があります。2 つのセルのセットアップでは、間接バインディングを使用して、一方の名前空間
から他方の名前空間に接続しなければなりません。
スタンドアロンのプロセス・サーバーに接続するポータルでこれがどのように機能するのかを、次の例で
示します。
ポートレットが名前空間を調べ、固定された名前空間のロケーションで EJB ホームへの参照を検索して
いるものとします。ポートレットは、BFMHome (Business Flow Manager) または HTMHome (Human Task
Manager) のいずれかの参照を解決しようと試みます。
まず、ポートレットが BFMHome を検索していると仮定しましょう。したがって、ポートレットは次のロケー
ションで自分自身の名前空間を調べます。
cell/persistent/pi/BFMHome
この EJBHome は別のセルに存在しているため、EJB が実行されている他のホストの情報が、ローカル
の名前空間に含まれている必要があります。これは、他のシステムのプロトコル・ヘッダー、ホスト名、お
よびブートストラップ・ポートで構成されるプロバイダー URL によって提供されます。例を示します。
corbaloc:iiop:BL3D8022.boeblingen.de.ibm.com:2810
これで、ポートレットが他のセルの名前空間に接続できるようになりましたが、他のセルの名前空間内の
どこにホーム参照があるのかを知る必要があります。これは、間接バインディングの名前空間の部分で指
定されます。この例では次のようになります。
com/ibm/bpe/api/BusinessFlowManagerHome
名前空間の部分は Business Flow Manager が使用しているデフォルト値です。何らかの理由でデフォル
ト値が使用されていない場合は、この値を更新する必要があります。
Process Server コンソールで「アプリケーション」->「WebSphere エンタープライズ・アプリケーション」を選
択し、アプリケーション「BPEContainer...」を選択することにより、実際の値を見つけることができます。次に、
EJB「GenericBusinessFlowManagerEJB」で EJB JNDI 名を表示すると、ターゲット・リソースの JNDI 名を
得られます。この例では、次のようになります。
com/ibm/bpe/api/BusinessFlowManagerHome
名前空間で名前を解決できないことを示すメッセージがログにある場合は、設定をチェックするツールとし
て dumpNamespace コマンドを使用するとよいでしょう。このコマンドは、要求された名前空間 (ホスト名
と指定されたブートストラップ <port> で定義されています) にリモートから接続するため、どのプロファイ
ルでも開始できます。
47
1. 間接バインディングがポータルの名前空間に入力されているかチェックします。
a) プロファイルの bin ディレクトリーまたは AppServer で、次のコマンドを実行します。
dumpNameSpace.bat -url corbaloc:iiop:<hostname>:<port> -report long
b) エントリー「(top)/persistent/pi/BFMHome」の内容をチェックします。次のような内容を得られます。
Content:
com.ibm.ws.naming.util.JndiLookupInfo@1bf21bf2[_jndiName="com/ibm/bpe/api/BusinessFlowManage
rHome", _providerURL="corbaloc:iiop:BL3D8022.boeblingen.de.ibm.com:2810",
_initialContextFactory="com.ibm.websphere.naming.WsnInitialContextFactory"]
c) オブジェクトのインスタンスを生成できなかったことを示すエラーは、ツール内の欠落しているクラスが
原因であることを示すため、無視できます。
2. 間接バインディングを使用して、リモート・プロセス・サーバーの情報を見つけられるかチェックします。
a) 前の手順のプロバイダー URL を使用し、dumpNameSpace ツールを用いてプロセス・サーバーの名
前空間に接続します。この例では、次のコマンドを発行します。
dumpNameSpace.bat -url corbaloc:iiop:BL3D8022.boeblingen.de.ibm.com:2810 –report long
b) 「com/ibm/bpe/api/BusinessFlowManagerHome」を検索します。次のような結果を得られます。
67 (top)/nodes/BL3D8022Node04/servers/server1/com/ibm/bpe/api/BusinessFlowManagerHome
67 Gebundener Java-Typ: com.ibm.bpe.api.BusinessFlowManagerHome
67 Lokaler Java-Typ: com.ibm.bpe.api._BusinessFlowManagerHome_Stub
67 CORBA-Bindungstyp: org.omg.CosNaming.BindingType.nobject
67 Zeichenfolgedarstellung: IOR:00bdbdbd0000003d524d493a636f6d2e69626d2e6270652e617.......
このエントリーから次のことがわかります。
• 「CORBA-Bindungstyp: org.omg.CosNaming.BindingType.nobject」により、オブジェクトが存在します。
• オブジェクトの解決時にエラーはありません。
• 検索されたサーバーは server1 です。これが、間接バインディングで定義したホスト名およびポートに
属するサーバーであることを確認します。
13 まとめ
ポータルとプロセス・サーバー間の接続のセットアップは、多数の手順と数多くのオプションが関与するた
め、複雑なタスクと思われています。しかし、本書で説明した追加の背景情報とタスク・フローを使用する
と、正しいオプションの選択や正しい手順での操作が容易になります。
本書に記載された情報によってセットアップの時間が大幅に節約され、さらにトラブルシューティング・セク
ションは潜在的な問題の解決に役立ちます。
48
14 リソース
z
WebSphere Application Server Version 7.0 インフォメーション・センター
z
WebSphere Process Server インフォメーション・センター: コンソールを使用したエンタープライズ・ア
プリケーション・ファイルのインストール
z
Feature Pack for XML、バージョン 1.0
z
Feature Pack for SCA、バージョン 1.0.1
z
WebSphere Process Server インフォメーション・センター
z
WebSphere Process Server インフォメーション・センター: ソフトウェアのインストール
z
IBM Support Technote 「Improving the performance of complex BPC API queries on DB2」
z
IBM Installation Manager のダウンロード
z
IBM Installation Manager 1.4 インフォメーション・センター
著者について
Walter Haenel は、WebSphere Portal 開発チームの運用およびデプロイメント
担当アーキテクトです。設計やレビューを通じた内部開発の指導と、ISSL (IBM
SoftwareServices for Lotus) およびデプロイメントで特定の問題を抱える外部
カスタマーへの支援を行う役割を担っています。また、コンファレンスやカスタマ
ー・イベントで定期的に講演しています。
Marie Knight は、WebSphere Portal チームの Advisory Software Quality
Engineer です。WebSphere Process Server と WebSphere Portal の統合など、
WebSphere Portal のさまざまな機能領域のテストに携わっています。
Wolfgang Reibert は、現在、WebSphere Portal System Verification Test (SVT)
チームの Advisory Software Quality Engineer として勤務しています。特にクラ
スター構成の領域で、Portal 構成チームの元開発者としての専門技術を SVT
チームに提供しています。
49
商標
• IBM、IBM ロゴ、ibm.com、および WebSphere は、世界の多くの国で登録された International Business Machines
Corp. の商標です。
• Microsoft および Windows は、Microsoft Corporation の米国およびその他の国における商標です。
• Java およびすべてのJava 関連の商標およびロゴは Oracle やその関連会社の米国およびその他の国における
商標または登録商標です。
• 他の会社名、製品名およびサービス名等はそれぞれ各社の商標です。
50