アダプタの開発

     前  次    目次     
ここから内容

設計時 GUI の開発

ADK の設計時フレームワークには、アダプタのユーザがアプリケーション ビューの定義、デプロイ、およびテストの際に必要となる Web ベースの GUI を作成するためのツールが用意されています。各アダプタには EIS 固有の機能がありますが、アプリケーション ビューをデプロイするための GUI は、すべてのアダプタで必要です。設計時フレームワークでは、主に以下のコンポーネントを使用して、このような GUI の作成やデプロイの作業を最小限に抑えることができます。

この節では、以下の内容を扱います。

 


設計時フォーム処理の概要

Java サーブレットと JSP を組み合わせることで、さまざまな方法でフォームを処理できます。どの方法でフォームを処理する場合でも、以下の基本的な要件を満たす必要があります。

フォーム処理クラス

Web アプリケーションで使用する各フォームに対してすべてのフォーム処理機能を実装すると、プロセスが冗長になりエラーの原因にもなります。ADK 設計時フレームワークでは、MVC (Model-View-Controller) パラダイムによって、このプロセスが簡素化されています。このパラダイムでは、以下の 5 つのクラスをベースとします。

RequestHandler

com.bea.web.RequestHandler

このクラスは HTTP リクエスト処理ロジックを提供します。このクラスは、MVC ベース メカニズムのモデル コンポーネントです。RequestHandler オブジェクトは ControllerServlet によってインスタンス化され、HTTP セッション中に handler キーの下に保存されます。ADK には com.bea.adapter.web.AbstractDesignTimeRequestHandler クラスが用意されています。この抽象基本クラスにより、アプリケーション ビューをデプロイする際にすべてのアダプタに共通して必要な機能が実装されます。アダプタまたは EIS 固有のロジックを定義するには、このクラスを拡張する必要があります。

ControllerServlet

com.bea.web.ControllerServlet

このクラスは HTTP リクエストを受け取ると、リクエスト中の各フィールド値の有効性を検証し、リクエストの処理を RequestHandler に委託します。また、表示するページを決定します。ControllerServlet は Java Reflection を使用して、RequestHandler で呼び出すメソッドを特定します。ControllerServletdoAction という HTTP リクエスト パラメータを探し、フォーム処理ロジックを実装するメソッド名を指定します。このパラメータがなければ、ControllerServletRequestHandler でメソッドを呼び出しません。

ControllerServlet は、Web アプリケーションに使用する web.xml ファイルでコンフィグレーションされます。ControllerServlet は、RequestHandler で実行するメソッドに HTTP リクエストを委託します。ControllerServlet を使用する場合、コードを指定する必要はありません。ただし、表 9-5 に示すパラメータを指定する必要があります。

ActionResult

com.bea.web.ActionResult

ActionResult では、リクエストの処理結果がカプセル化されます。また、次に表示するページを決定するための情報が ControllerServlet に提供されます。

Word およびその子孫

com.bea.web.validation.Word

Web アプリケーションのすべてのフィールドについて、有効性を検証する必要があります。com.bea.web.validation.Word クラスおよびその子孫により、フォーム中の各フィールドの有効性を検証するロジックが提供されます。無効なフィールドがあると、Word オブジェクトはメッセージ バンドルを使用して、該当するフィールドに応じてインターナショナライズまたはローカライズされたエラー メッセージを検索します。ADK には、表 9-1 に示すカスタム バリデータが用意されています。

表 9-1 Word オブジェクトのカスタム バリデータ
バリデータ
フィールドに対する値の判断
Integer
指定された範囲内の整数値であるかどうかを判断する。
Float/Double
指定された範囲内の浮動小数点数であるかどうかを判断する。
Identifier
有効な Java 識別子であるかどうかを判断する。
Perl 5 Regular Expression
Perl 5 の正規表現に一致するかどうかを判断する。
URL
(ユーザが入力した値が) 有効な URL であるかどうかを判断する。
Email
(ユーザが入力した値が) 有効な電子メール アドレスであるかどうかを判断する。
Date
(ユーザが入力した値が) 指定の日付と時間フォーマットに従っており、有効な日時であるかどうかを判断する。

AbstractInputTagSupport およびその子孫

com.bea.web.tag.AbstractInputTagSupport

Web ツールキットで提供されるタグ クラスには以下の機能があります。

送信タグ

また、ADK には以下のような送信タグが用意されています。

<adk:submit name='xyz_submit' doAction='xyz'/>

このタグにより、doAction パラメータがリクエスト中の ControllerServlet に渡されます。この結果、ControllerServlet から登録済みの RequestHandlerxyz() メソッドが呼び出されます。

フォーム処理のシーケンス

この節では、フォームを処理するシーケンスを説明します。

前提条件

フォームを処理するための前提条件は、以下のとおりです。

  1. カスタム ADK 入力タグを使用した JSP が HTTP 応答オブジェクトに書き込まれるとき、このタグにより com.bea.web.validation.Word のインスタンスがオブジェクトによって初期化され、入力フィールド名をキーとして、Web アプリケーション スコープにこのインスタンスが格納される。このようなタグにより、ControllerServlet で検証オブジェクトが有効になるため、まず HTTP リクエストを大まかに検証してから、RequestHandler にリクエストを出すことができます。以下に例を示します。
  2. <adk:int name='age' minInclusive='1' maxInclusive='120' required='true'/>
  3. JSP エンジンが com.bea.web.tag.IntegerTagSupport のインスタンスで doStartTag() メソッドを呼び出したら、このタグの HTML が生成される。IntegerTagSupport インスタンスにより、com.bea.web.validation.IntegerWord の新しいインスタンスが作成され、これがキー age に基づいて Web アプリケーション スコープに追加されます。その結果、ControllerServlet では、年齢の値を検証する必要があるときはいつでも、対応する ServletContext から IntegerWord インスタンスを検索できます。検証によって、年齢に渡された値が 1 以上かつ 120 以下であることが確認されます。
  4. HTML フォームでは、doAction という非表示フィールドも発行する。このフィールドの値は、フォーム処理を実行する RequestHandler 上のメソッドを ControllerServlet で特定するときに使用されます。

これらの前提条件を満たすと、コード リスト 9-1 のような JSP フォームが表示されます。

コード リスト 9-1 JSP フォームのサンプル
<form method='POST' action='controller'>
Age: <adk:int name='age' minInclusive='1' maxInclusive='120'
required='true'/>
<adk:submit name='processAge_submit' doAction='processAge'/>
</form>

シーケンスの手順

以下のダイアグラムに、フォーム処理の実行方法を順を追って示します。

図 9-1 UI フォーム処理

UI フォーム処理

シーケンスは以下のとおりです。

  1. ユーザが、以下のデータが指定されたフォームを送信します。age=10, doAction=processAge
  2. ControllerServlet が HTTP リクエストから年齢フィールドのデータを読み込みます。
  3. ControllerServletage をキーとして使用して、ServletContext から com.bea.web.validation.Word を検索します。このオブジェクトは、com.bea.web.validation.IntegerWord のインスタンスです。
  4. ControllerServletWord インスタンスで validate() メソッドを呼び出し、パラメータとして 10 を渡します。
  5. Word インスタンスにより、この値 10 が 1 以上 120 以下の値であることが判断され、この値が有効であることを示す true が返されます。
  6. ControllerServlet がセッションから RequestHandler を検索または作成して、handler としてセッションに追加します。
  7. ControllerServlet は、Java Reflection API を使用して、processAge() メソッドを探して、RequestHandler でこのメソッドを呼び出します。このメソッドが存在しない場合は、例外が生成されます。メソッド シグネチャは、以下のとおりです。
  8. public ActionResult processAge(HttpServletRequest request) throws Exception
  9. RequestHandler は、フォームの入力データを処理した後、ActionResult オブジェクトを返して処理結果を示します。ActionResult には、ControllerServlet が次に表示するページを決定するための情報が格納されます。その情報は、Web アプリケーション内に表示する別の JSP や HTML のページの名前などにします。たとえば、thanks という情報があった場合には、次に thanks.jsp ページが表示されます。
  10. ActionResult が正常に実行されると、ControllerServlet により HTTP 応答が Web アプリケーションの表示ページにリダイレクトされます。ADK では、表示ページは通常 display.jsp です。
  11. display.jsp ページには、content パラメータ (たとえば、thanks.jsp) により指定される JSP があります。これにより、その JSP がユーザに表示されます。

 


設計時 GUI の機能

設計時 GUI の開発では、実行時アダプタを開発する場合とは異なる独自の機能を使用します。この節では、設計時 GUI の機能を説明します。

Java Server Page

設計時 GUI は、一連の JSP (Java Server Page) で構成されます。JSP とは、特定のトランザクションを開始する目的で Java サーブレットを呼び出すための HTML ページのことです。ユーザ側から見た JSP は、通常の Web ページと変わりません。

設計時 GUI を構成する JSP を以下の表に示します。

表 9-2 設計時 GUI の JSP
ファイル名
説明
display.jsp
アダプタ ホームページとも呼ばれる表示ページ。このページには、ルック アンド フィールの作成に必要な HTML が表示される。
login.jsp
アダプタの設計時 GUI のログイン ページ。
confconn.jsp
接続パラメータの確認ページには、EIS の接続パラメータを指定するためのフォームが表示される。
appvwadmin.jsp
アプリケーション ビュー管理ページには、アンデプロイされたアプリケーション ビューの概要が表示される。
addevent.jsp
イベントの追加ページでは、イベントをアプリケーション ビューに追加できる。
addservc.jsp
サービスの追加ページでは、サービスをアプリケーション ビューに追加できる。
edtevent.jsp
イベントの編集ページでは、必要に応じてユーザがイベントを編集できる。
edtservc.jsp
サービスの編集ページでは、必要に応じてユーザがサービスを編集できる。
depappvw.jsp
アプリケーション ビューのデプロイ ページでは、ユーザがデプロイメント プロパティを指定できる。

これらの JSP の実装方法については、「手順 2 : ページ フローの定義」を参照してください。

JSP テンプレート

テンプレートとは、HTTP リクエストで指定するパラメータに基づいて Java サーブレットが動的に生成する HTML ページのことです。テンプレートを使用することにより、Web アプリケーションで使用するカスタム ページやカスタム HTML の量を最小限に抑えることができます。

設計時フレームワークの JSP テンプレートのセットを使用すると、アダプタの新しいアプリケーション ビューを定義、デプロイ、およびテストするための Web アプリケーションを効率的に作成できます。アダプタの開発者にとって、ADK のテンプレートには以下の 3 つの利点があります。

ADK で提供される JSP テンプレートのリストについては、「JSP テンプレート」を参照してください。

JSP タグの ADK ライブラリ

ADK で提供される JSP タグ ライブラリを使用すると、使いやすい HTML フォームを簡単に作成できます。アダプタ ページを開発する際、HTML フォーム入力コンポーネントのカスタム タグを使用すれば、検証メカニズムへシームレスにリンクできます。以下の表に、ADK に用意されているカスタム タグを示します。

表 9-3 ADK の JSP タグ
タグ
説明
adk:check box
フォームを表示するときに、チェックボックスのフォーム フィールドをチェックする必要があるかどうかを決定する (このタグではデータ検証は実行しない)。
adk:content
メッセージ バンドル内のメッセージにアクセスする。
adk:date
日付値が特定のフォーマットに従って入力されているかを検証する。
adk:double
double 値が入力されているかを検証する。
adk:email
有効な電子メール アドレス (複数も可) が入力されているかを検証する。
adk:float
float 値が入力されているかを検証する。
adk:identifier
有効な Java 識別子が入力されているかを検証する。
adk:int
integer 値が入力されているかを検証する。
adk:label
メッセージ バンドルからラベルを表示する。
adk:password
ユーザがテキスト フィールドに入力した値と Perl 5 の正規表現を照合して、入力にアスタリスク (*) を付ける。
adk:submit
フォームを検証メカニズムにリンクする。
adk:text
ユーザが入力した値と Perl 5 の正規表現を照合する。
adk:textarea
ユーザがテキスト領域に入力した値と Perl 5 の正規表現を照合する。
adk:url
有効な URL が入力されているかを検証する。

JSP タグの属性

表 9-4 に記載されている属性を使用すると、JSP タグをさらにカスタマイズできます。

表 9-4 JSP タグの属性
タグ
必須の属性
省略可能な属性
adk:int, adk:float, adk:double
name - フィールド名
default - ページに表示されるデフォルト値
maxlength - 値の最大長
size - 表示サイズ
minInclusive - ユーザが指定する値はこの値以上でなければならない
maxInclusive - ユーザが指定する値はこの値以下でなければならない
minExclusive - ユーザが指定する値はこの値を下回ってはならない
maxExclusive - ユーザが指定する値はこの値を上回ってはならない
required - true または false (デフォルトは false。つまり、フィールドは必須ではない)
attrs - 追加の HTML 属性
adk:date
name - フィールド名
default - ページに表示されるデフォルト値
maxlength - 値の最大長
size - 表示サイズ
required - true または false (デフォルトは false。つまり、フィールドは必須ではない)
attrs - 追加の HTML 属性
lenient - true または false (デフォルトは false。つまり、日付フォーマッタを厳密に解析)
format - ユーザ入力で予期されるフォーマット (デフォルトは mm/dd/yyyy)
adk:email, adk:url, adk:identifier
name - フィールド名
default - ページに表示されるデフォルト値
maxlength - 値の最大長
size - 表示サイズ
required - true または false (デフォルトは false。つまり、フィールドは必須ではない)
attrs - 追加の HTML 属性
adk:text, adk:password
name - フィールド名
default - ページに表示されるデフォルト値
maxlength - 値の最大長
size - 表示サイズ
required - true または false (デフォルトは false。つまり、フィールドは必須ではない)
attrs - 追加の HTML 属性
pattern - Perl 5 の正規表現
adk:textarea
name - フィールド名
default - ページに表示されるデフォルト値
required - true または false (デフォルトは false。つまり、フィールドは必須ではない)
attrs - 追加の HTML 属性
pattern - Perl 5 の正規表現
rows - 表示する行数
columns - 表示するカラム数

注意 : タグの使用方法については、以下の場所にある adk.tld を参照してください。
注意 : WLI_HOME/adapters/src/war/WEB-INF/taglibs

アプリケーション ビュー

アプリケーション ビューは、アプリケーション固有の機能に対するビジネス レベルのインタフェースです。詳細については、「アプリケーション ビュー」を参照してください。

 


ファイル構造

設計時 GUI アダプタを構築する際に必要なファイル構造は、サービス接続を構築する場合と同じです。「手順 2a : ディレクトリ構造の設定」を参照してください。参照先で説明されているファイル構造のほかに、以下の点にも注意する必要があります。

 


イベント フロー

図 9-2 に、設計時 GUI の開発手順を示します。

図 9-2 設計時 GUI の開発のイベント フロー

設計時 GUI の開発のイベント フロー

 


手順 1 : 設計時 GUI の要件の定義

設計時 GUI の開発を始める前に、以下の質問に答えて要件を定義する必要があります。

 


手順 2 : ページ フローの定義

ユーザがアプリケーション ビューを呼び出したときの JSP の表示順序を指定する必要があります。この節では、効果的なアプリケーション ビューで必要となる基本的なページのフローを説明します。ここで説明する要件は最低限必要なものであり、フローには必要に応じてページを追加できます。

ページ 1 : ログイン

アプリケーション ビューはセキュアなシステムであるため、ビューを実装する前にログインする必要があります。このため、最初は必ず Application Integration Design Console ログオン ページを表示します。

このページを使用するには、有効なユーザ名とパスワードを入力します。この情報から、ユーザが、デフォルトの WebLogic Server セキュリティ レルムに定義されたアダプタ グループのメンバーであることを確認します。

注意 : アプリケーション ビューの Web アプリケーションに対するセキュリティ要件は、WLI_HOME/adapters/ADAPTER/src/war/WEB-INF/web.xml ファイルで指定されています。これは、adapter.war ファイルに組み込まれています。

ページ 2 : アプリケーション ビューの管理

ユーザが正常にログインすると、Application Integration Design Console ページが表示されます。このページには、アプリケーション ビュー、各フォルダのステータス、およびこれらに対して実行されたアクションを示すフォルダが表示されます。ユーザはこのページから既存のアプリケーション ビューを表示したり、新しいアプリケーション ビューを追加できます。

ページ 3 : 新規アプリケーション ビューの定義

新規アプリケーション ビューの定義ページ (defappvw.jsp) では、クライアントが配置された任意のフォルダに新しいアプリケーション ビューを定義できます。これには、アプリケーション ビューとアダプタを関連付けるための説明が必要になります。このフォームには、アプリケーション ビュー名と説明を入力するフィールドと、アプリケーション ビューと関連付けるアダプタを表示するドロップダウン リスト ボックスがあります。

新しいアプリケーション ビューを定義した後に [OK] を選択すると、接続のコンフィグレーション ページが表示されます。

ページ 4 : 接続のコンフィグレーション

新しいアプリケーション ビューが有効であれば、ユーザは接続のコンフィグレーションを行う必要があります。つまり、アプリケーション ビューの有効性が検証された後、接続パラメータのコンフィグレーション ページ (confconn.jsp) が表示されます。このページは、EIS の接続パラメータを指定するためのフォームです。接続パラメータは EIS 固有であるため、このページの外観はアダプタごとに異なります。

ユーザが接続パラメータを送信すると、アダプタはこのパラメータを使用して EIS への新しい接続を試みます。EIS に接続されると、ユーザには次のアプリケーション ビュー管理ページが表示されます。

ページ 5 : アプリケーション ビューの管理

ユーザには、新しいアプリケーション ビューを管理する方法が必要です。アプリケーション ビュー管理ページ (appvwadmin.jsp) には、アンデプロイされたアプリケーション ビューの概要が表示されます。具体的には、以下の情報が表示されます。

さらに、アプリケーション ビューにイベント リストやサービス リストを提供するほかに、新しいイベントやサービスを追加できるページへのリンクも設定します。

ページ 6 : イベントの追加

次にユーザは、イベントをアプリケーション ビューに追加する必要があります。イベントの追加ページ (addevent.jsp) で、これを行うことができます。

新しいイベントには、以下の規則を適用します。

新しいイベントを定義して保存すると、アプリケーション ビュー管理ページに戻ります。

ページ 7 : サービスの追加

アプリケーション ビューに新しいサービスを追加する必要もあります。サービスの追加ページ (addservc.jsp) で、これを行うことができます。

新しいイベントには、以下の規則を適用します。

新しいサービスを定義して保存するとアプリケーション ビュー管理ページに戻ります。

ページ 8 : アプリケーション ビューのテスト

1 つ以上のサービスまたはイベントを追加すると、アプリケーション ビューをテストできます。アプリケーション ビューをテストすると、テスト用のイベントやサービスの処理にこれを利用できるようになります。アプリケーション ビューのテストをする場合は、以下の 2 つの方法を選択できます。

アプリケーション ビューのパブリッシュ

アプリケーション ビューのテストに成功したら、アプリケーション ビューをアプリケーション ビューの概要ページからパブリッシュできるため、WebLogic Workshop アプリケーションから使用できるようになります。

アプリケーション ビューの保存

アプリケーション ビュー (テストとパブリッシュを行っていないビューも含む) を保存すると、後で Application Integration Design Console からアプリケーション ビューへ戻ることができます。この処理では、アプリケーション ビューは目的の WebLogic Workshop アプリケーション内の Application Integration リポジトリに保存されます。アプリケーション ビューはテストを行うと自動的にこのリポジトリに保存されるので、実際にアプリケーション ビューのテストをする前にデザイン セッションを残す場合にのみ、この手順は必要となります。

ページ 9 : アプリケーション ビューの概要

アプリケーション ビューが正常にデプロイされると、アプリケーション ビューの概要ページ (appvwsum.jsp) が表示されます。このページにはアプリケーション ビューに関する以下の情報が表示されます。

 


手順 3 : 開発環境のコンフィグレーション

ここでは、設計時 GUI 開発をサポートするためのソフトウェア環境を設定します。

手順 3a : メッセージ バンドルの作成

エンドユーザ向けのメッセージはメッセージ バンドルに格納する必要があります。メッセージ バンドルは、key=value の組み合わせで構成される単純な .properties テキスト ファイルで、この key=value の組み合わせにより、メッセージをインターナショナライズできます。実行時にロケールと地域言語を指定すると、メッセージの内容が、key=value の組み合わせの指定に従って翻訳され、メッセージが指定されたロケールに適切な言語で表示されます。

メッセージ バンドルの作成方法の詳細については、以下のサイトの JavaSoft チュートリアルでインターナショナライゼーションについて参照してください。

http://java.sun.com/docs/books/tutorial/i18n/index.html

手順 3b : WebLogic Server を再起動せずに JSP を更新する環境のコンフィグレーション

設計時 UI は、WAR ファイルの J2EE Web アプリケーションとしてデプロイされます。WAR ファイルは、JAR ファイルにある WEB-INF/web.xml 内で Web アプリケーション記述子が付いた JAR ファイルです。ただし、WAR ファイルでは、WebLogic Server の J2EE Web コンテナを使用してその場で JSP を再コンパイルすることはできません。このため、通常は単に JSP ファイルを変更するだけでも、WebLogic Server を再起動する必要があります。これは JSP の特長と相反するため、ADK では WebLogic Server を再起動しなくても JSP を更新できるように以下の解決策をお勧めします。

  1. アダプタの設計時 UI 用に有効な WAR ファイルを作成します。サンプル アダプタでは、Ant を使用してこのファイルを作成します。コード リスト 9-2 に、J2EE WAR ファイルを生成する対象を示します。
  2. コード リスト 9-2 WAR ファイルの作成対象
    <target name='war' depends='jar'>

    <!-- 既存の環境をクリーンアップする -->
    <delete file='${LIB_DIR}/${WAR_FILE}'/>

    <war warfile='${LIB_DIR}/${WAR_FILE}'
    webxml='${SRC_DIR}/war/WEB-INF/web.xml'
    manifest='${SRC_DIR}/war/META-INF/MANIFEST.MF'>

    <!--
    重要 !WEB-INF/web.xml ファイルを WAR から削除する
    このファイルは上記の webxml 属性によりすでに含まれている
    -->
    <fileset dir="${SRC_DIR}/war" >
    <patternset >
    <include name="WEB-INF/weblogic.xml"/>
    <include name="**/*.html"/>
    <include name="**/*.gif"/>
    </patternset>
    </fileset>

    <!--
    重要 !ADK 設計時フレームワークをアダプタの設計時
    Web アプリケーションに含める。
    -->
    <fileset dir="${WLI_HOME}/adapters/src/war" >
    <patternset >
    <include name="**/*.css"/>
    <include name="**/*.html"/>
    <include name="**/*.gif"/>
    <include name="**/*.js"/>
    </patternset>
    </fileset>

    <!--
    設計時 UI をサポートするアダプタのクラスを含める
    -->
    <classes dir='${SRC_DIR}' includes='sample/web/*.class'/>

    <classes dir='${SRC_DIR}/war' includes='**/*.class'/>
    <classes dir='${WLI_HOME}/adapters/src/war'
    includes='**/*.class'/>

    <!--
    Web アプリケーションで必要とされ、EAR で共有されないすべての JAR
    ファイルを、WAR ファイルの WEB-INF/lib ディレクトリ下に含める
    -->
    <lib dir='${WLI_LIB_DIR}'
    includes='adk-web.jar,webtoolkit.jar,wlai-client.jar'/>
    </war>
    </target>

    この Ant ターゲットは、PROJECT_ROOT/lib ディレクトリ内に設計時インタフェース用の有効な WAR ファイルを作成します。このディレクトリで、PROJECT_ROOT は WebLogic Integration がインストールされている場所で、開発者はここにアダプタを構築します。たとえば、DBMS サンプル アダプタは、以下の場所で構築されます。

    WLI_HOME/adapters/DBMS

  3. WebLogic Server Administration Console を使用して、Web アプリケーションを WebLogic Server にロードします。
  4. 開発環境をコンフィグレーションします。サンプルの開発環境情報をコード リスト 9-3 に示します。
  5. コード リスト 9-3 アダプタ開発ツリーの名前
    <Application Deployed="true" Name="BEA_WLS_SAMPLE_ADK_Web"
    Path="WLI_HOME\adapters\PROJECT_ROOT\lib">
        <WebAppComponent Name="BEA_WLS_SAMPLE_ADK_Web"
    ServletReloadCheckSecs="1" Targets="myserver" URI=
    "BEA_WLS_SAMPLE_ADK_Web"/>
    </Application>

    アダプタ論理名とディレクトリの値を以下のように設定します。

    1. BEA_WLS_SAMPLE_ADK_Web を使用するアダプタの論理名に置き換えます。
    2. WLI_HOME を、WebLogic Integration がインストールされているディレクトリのパス名に置き換えます。コード リスト 9-3 に示すように、PROJECT_ROOT を、アダプタ開発ツリーのトップレベル ディレクトリの名前に置き換えます。
    3. 注意 : GenerateAdapterTemplate を実行すると、コード リスト 9-3 の情報が自動的に更新されます。WLI_HOME/adapters/ ADAPTER/src/overview.html を開いて、この情報をコピーし、config.xml エントリに貼り付けることができます。
  6. JSP を変更するには、src/war ディレクトリ内で変更し、WAR ターゲットを再構築します。一時ディレクトリ内の JSP は変更しないでください。WAR ファイルが作成されると、これは、特定の JSP への変更のみを取り上げる WebLogic Server によってモニタされるディレクトリにも抽出されます。WebLogic Server が実行するモニタの間隔は、WEB-INF/weblogic.xml にある pageCheckSeconds パラメータで指定されます。コード リスト 9-4 にこのパラメータの設定方法を示します。
  7. コード リスト 9-4 モニタ間隔の設定
    <jsp-descriptor>
    <jsp-param>
    <param-name>compileCommand</param-name>
    <param-value>/jdk130/bin/javac.exe</param-value>
    </jsp-param>
    <jsp-param>
    <param-name>keepgenerated</param-name>
    <param-value>true</param-value>
    </jsp-param>
    <jsp-param>
    <param-name>pageCheckSeconds</param-name>
    <param-value>1</param-value>
    </jsp-param>
    <jsp-param>
    <param-name>verbose</param-name>
    <param-value>true</param-value>
    </jsp-param>
    </jsp-descriptor>

    この方法では、WAR ファイルが正しく構築されているかもテストされます。

 


手順 4 : 設計時 GUI の実装

Web アプリケーションで使用するフォームごとに「設計時フォーム処理の概要」で説明する手順を実行すると、プロセスが冗長になりエラーの原因にもなります。設計時フレームワークでは、MVC (Model-View-Controller) パラダイムをサポートすることにより、このプロセスが簡素化されます。

設計時 GUI を実装するには、DesignTimeRequestHandler クラスを実装する必要があります。このクラスでは、フォームからのユーザ入力を受け入れ、設計時 GUI のアクションを実行します。このクラスを実装するには、ADK の AbstractDesignTimeRequestHandler を拡張する必要があります。このオブジェクトが提供するメソッドの詳細については、DesignTimeRequestHandler クラスの Javadoc を参照してください。

AbstractDesignTimeRequestHandler の拡張

AbstractDesignTimeRequestHandler は、WebLogic Server でアプリケーション ビューをデプロイ、編集、コピー、削除するためのユーティリティ クラスを提供します。これにより、アプリケーション ビュー記述子にアクセスできます。アプリケーション ビュー記述子では、アプリケーション ビューに適用する接続パラメータ、イベント リスト、サービス リスト、ログ レベル、およびプールの設定が提供されます。アプリケーション ビューの概要ページに、各パラメータが表示されます。

AbstractDesignTimeRequestHandler は、すべてのアダプタに共通するすべてのアクションに適用できる実装を提供します。主なアクションは以下のとおりです。

インクルードするメソッド

これらのアクションを正しく実行するには、AbstractDesignTimeRequestHandler を実装する際に、以下のメソッドを指定する必要があります。

AbstractDesignTimeRequestHandler の各具象実装に、以下の 2 つのメソッドを指定する必要があります。

手順 4a : ManagedConnectionFactory クラスの指定

ManagedConnectionFactory クラスを指定するには、以下のメソッドを実装する必要があります。

protected Class getManagedConnectionFactoryClass();

このメソッドにより、アダプタに対する SPI の ManagedConnectionFactory 実装クラスが返されます。このクラスは、AbstractManagedConnectionFactory が EIS への接続を試行する際に必要です。

手順 4b : initServiceDescriptor() の実装

サービス接続では、アダプタのユーザが設計時にサービスを追加できるように、initServiceDescriptor() を実装する必要があります。このメソッドの実装をコード リスト 9-5 に示します。

コード リスト 9-5 initServiceDescriptor() の実装
protected abstract void initServiceDescriptor(ActionResult result,
IServiceDescriptor sd,
HttpServletRequest request)
throws Exception

このメソッドは、AbstractDesignTimeRequestHandleraddservc() の実装によって呼び出されます。このメソッドにより、IServiceDescriptor パラメータに関連付けられた EIS 固有の情報が初期化されます。addservc() の基本クラスを実装することにより、エラー処理などを実行します。ユーザが addservc JSP を送信すると、addservc() メソッドが呼び出されます。

手順 4c : initEventDescriptor() の実装

イベント接続では、アダプタのユーザが設計時にイベントを追加できるように、initEventDescriptor() を実装する必要があります。このメソッドの実装をコード リスト 9-6 に示します。

コード リスト 9-6 initEventDescriptor() の実装
protected abstract void
initEventDescriptor(ActionResult result,
IEventDescriptor ed,
HttpServletRequest request)
throws Exception;

このメソッドは、AbstractDesignTimeRequestHandleraddservc() の実装によって呼び出されます。このメソッドにより、IServiceDescriptor パラメータに関連付けられた EIS 固有の情報が初期化されます。addevent() の基本クラスを実装することにより、エラー処理などを実行します。ユーザが addevent JSP を送信すると、addevent() メソッドが呼び出されます。addevent には共通のロジックが含まれ、EIS 固有のロジックが initEventDescriptor() に委託されるので、この JSP はオーバーライドしないでください。

注意 : サービス記述子にプロパティを追加する場合は、Bean 属性の命名規約に従って名前を指定する必要があります。従わない場合、サービス記述子が InteractionSpec を正しく更新しません。

 


手順 5 : HTML フォームの記述

設計時 GUI を実装する最後の手順は、インタフェースを構成する各種のフォームを記述することです。フォームの作成に慣れるためには、以下の節を参照してください。

以下の節では、これらのフォームのコードの記述方法を説明します。フォームのサンプル コードも紹介します。

手順 5a : confconn.jsp フォームの作成

このページでは、ユーザが EIS 用の接続パラメータを指定するための HTML フォームを提供します。このページには、アダプタの設計時 Web アプリケーションを表示する必要があります。このフォームは doAction=confconn によって ControllerServlet にポストされます。つまり、設計時インタフェースの RequestHandler で以下のメソッドを指定する必要があります。

public ActionResult confconn(HttpServletRequest request) throws
Exception

このメソッドを実装すると、指定した接続パラメータに基づいてアダプタの ManagedConnectionFactory の新しいインスタンスを作成できます。ManagedConnectionFactory により、EIS への接続を設定するための CCI ConnectionFactory が指定されます。このため、confconn フォームの送信を処理することにより EIS に接続するために必要なパラメータが正しく指定されているかどうかが検証されます。

サンプル アダプタの confconn フォームをコード リスト 9-7 に示します。

コード リスト 9-7 confconn.jsp のコーディング
1  <%@ taglib uri='/WEB-INF/taglibs/adk.tld' prefix='adk' %>
2 <form method='POST' action='controller'>
3 <table>
4 <tr>
5 <td><adk:label name='userName' required='true'/></td>
6 <td><adk:text name='userName' maxlength='30' size='8'/></td>
7 </tr>
8 <tr>
9 <td><adk:label name='password' required='true'/></td>
10 <td><adk:password name='password' maxlength='30'size='8'/></td>
11 </tr>
12 <tr>
13 <td colspan='2'><adk:submit name='confconn_submit'
doAction='confconn'/></td>
14 </tr>
15 </table>
16 </form>

以下の節では、コード リスト 9-7 の内容を説明します。

ADK タグ ライブラリのインクルード

コード リスト 9-7 の行 1 で、JSP エンジンに ADK タグ ライブラリをインクルードするように指定します。

<%@ taglib uri='/WEB-INF/taglibs/adk.tld' prefix='adk' %>

ADK が提供するタグは、表 9-3 に示します。

ControllerServlet のポスト

コード リスト 9-7 の行 2 で、フォームが ControllerServlet にポストされます。

<form method='POST' action='controller'>

ControllerServlet は、Web アプリケーションに使用する web.xml ファイルでコンフィグレーションされます。このクラスは、RequestHandler で実行するメソッドに HTTP リクエストを委託します。ControllerServlet を使用するためにコードを指定する必要はありません。ただし、表 9-5 に示す初期パラメータを指定する必要があります。

表 9-5 ControllerServlet の初期パラメータ
パラメータ
説明
MessageBundleBase
アダプタで使用するすべてのメッセージ バンドルに基本名を指定する。ADK は、常にサンプル アダプタに論理名を使用する。ただし、メッセージ バンドルには独自の命名規約を選択できる。このプロパティは、ra.xml ファイルでも設定できる。
DisplayPage
アプリケーションのページのフローおよびルック アンド フィールを制御する JSP の名前を指定する。サンプル アダプタでは、このページに display.jsp が表示される。
LogConfigFile
アダプタの log4j コンフィグレーション ファイルを指定する。
RootLogContext
ルート ログの内容を指定する。ログの内容を利用して、プログラムの各モジュールに合わせてログ メッセージを分類できる。ADK では、特定のアダプタのメッセージがすべて分類されるように、ルート ログの内容にアダプタの論理名を使用する。
RequestHandlerClass
アダプタのリクエスト ハンドラ クラスに完全修飾名を付ける。サンプル アダプタの場合、この値は sample.web.DesignTimeRequestHandler

フォーム フィールドのラベル表示

コード リスト 9-7 の行 5 で、フォームのフィールドのラベルを表示します。

<adk:label name='userName' required='true'/>

表示する値は、ユーザのメッセージ バンドルから取得します。required 属性により、ユーザによるこのパラメータの指定が必須かどうかを示します。

テキスト フィールド サイズの表示

コード リスト 9-7 の行 6 で、テキスト フィールドにサイズ 8、最大長 30 が設定されます。

<adk:text name='userName' maxlength='30' size='8'/>

フォームの送信ボタンの表示

コード リスト 9-7 の行 13 で、アダプタのユーザが入力を送信するためのボタンをフォームに表示します。

<adk:submit name='confconn_submit' doAction='confconn'/>

ボタンのラベルは、confconn_submit キーを使用してメッセージ バンドルから取得されます。フォーム データを送信すると、ControllerServlet が登録済みのリクエスト ハンドラ (RequestHandlerClass プロパティを参照) で confconn メソッドを検索し、リクエスト データをリクエスト ハンドラに渡します。

confconn() の実装

AbstractDesignTimeRequestHandler により、confconn() メソッドが実装されます。このメソッドの実装によって、Java Reflection API を利用して、アダプタの ManagedConnectionFactory インスタンスのセッター メソッドに、ユーザが指定した接続パラメータがマップされます。アダプタの ManagedConnectionFactory に具象クラスを指定するだけで済むようになります。このクラスを指定するには、以下のメソッドを実装します。

public Class getManagedConnectionFactoryClass()

手順 5b : addevent.jsp フォームの作成

このフォームを使用すると、アプリケーション ビューに新しいイベントを追加できます。このフォームは EIS 固有です。サンプル アダプタの addevent.jsp フォームをコード リスト 9-8 に示します。

コード リスト 9-8 addevent.jsp フォームを作成するサンプル コード
1  <%@ taglib uri='/WEB-INF/taglibs/adk.tld' prefix='adk' %>
2 <form method='POST' action='controller'>
3 <table>
4 <tr>
5 <td><adk:label name='eventName' required='true'/></td>
6 <td><adk:text name='eventName' maxlength='100' size='50'/></td>
7 </tr>
8 <tr>
9 <td colspan='2'><adk:submit name='addevent_submit'
doAction='addevent'/></td>
10 </tr>
11 </table>
12 </form>

以下の節では、addevent.jsp の内容を説明します。

ADK タグ ライブラリのインクルード

コード リスト 9-8 の行 1 で、JSP エンジンに ADK タグ ライブラリをインクルードするように指定します。

<%@ taglib uri='/WEB-INF/taglibs/adk.tld' prefix='adk' %>

ADK が提供するタグについては、表 9-3 で説明しています。

ControllerServlet のポスト

コード リスト 9-8 の行 2 で、フォームが ControllerServlet にポストされます。

<form method='POST' action='controller'>

ControllerServlet は、Web アプリケーションに使用する web.xml ファイルでコンフィグレーションされます。このクラスは、RequestHandler で実行するメソッドに HTTP リクエストを委託します。ControllerServlet を使用するためにコードを指定する必要はありません。ただし、表 9-5「ControllerServlet の初期パラメータ」に示すように、初期パラメータを指定する必要があります。

フォーム フィールドのラベル表示

コード リスト 9-8 の行 5 で、フォームのフィールドのラベルを表示します。

<adk:label name='eventName' required='true'/>

表示する値は、ユーザのメッセージ バンドルから取得します。required 属性により、ユーザによるこのパラメータの指定が必須かどうかを示します。

テキスト フィールド サイズの表示

コード リスト 9-8 の行 6 で、テキスト フィールドにサイズ 50、最大長 100 が設定されます。

<adk:text name='eventName' maxlength='100' size='50'/>

フォームの送信ボタンの表示

コード リスト 9-8 の行 9 で、アダプタのユーザが入力を送信するためのボタンをフォームに表示します。

<adk:submit name='addevent_submit' doAction='addevent'/>

ボタンのラベルは、addevent_submit キーを使用してメッセージ バンドルから取得されます。フォーム データを送信すると、ControllerServlet が登録済みのリクエスト ハンドラ (RequestHandlerClass プロパティを参照) で addevent() メソッドを検索し、リクエスト データをリクエスト ハンドラに渡します。

その他のフィールドの追加

イベントの定義に必要なその他のフィールドを追加する必要があります。複数のフィールドを使用したフォームの例については、「DBMS サンプル アダプタを使用したアダプタ開発方法の学習」を参照してください。

手順 5c : addservc.jsp フォームの作成

このフォームを使用すると、アプリケーション ビューに新しいサービスを追加できます。このフォームは EIS 固有です。サンプル アダプタの addservc.jsp フォームをコード リスト 9-9 に示します。

コード リスト 9-9 addservc.jsp のコーディング
1  <%@ taglib uri='/WEB-INF/taglibs/adk.tld' prefix='adk' %>
2 <form method='POST' action='controller'>
3 <table>
4 <tr>
5 <td><adk:label name='serviceName' required='true'/></td>
6 <td><adk:text name='serviceName' maxlength='100' size='50'/></td>
7 </tr>
8 <tr>
9 <td colspan='2'><adk:submit name='addservc_submit'
doAction='addservc'/></td>
10 </tr>
11 </table>
12 </form>

ADK タグ ライブラリのインクルード

コード リスト 9-9 の行 1 で、JSP エンジンに ADK タグ ライブラリをインクルードするように指定します。

<%@ taglib uri='/WEB-INF/taglibs/adk.tld' prefix='adk' %>

タグ ライブラリでは、ADK で提供される使いやすいフォーム検証機能がサポートされます。ADK タグ ライブラリには、表 9-3 に示すタグが用意されています。

ControllerServlet のポスト

コード リスト 9-9 の行 2 で、フォームが ControllerServlet にポストされます。

<form method='POST' action='controller'>

ControllerServlet は、Web アプリケーションに使用する web.xml ファイルでコンフィグレーションされます。このクラスは、RequestHandler で実行するメソッドに HTTP リクエストを委託します。ControllerServlet を使用するためにコードを指定する必要はありません。ただし、表 9-5「ControllerServlet の初期パラメータ」に示すように、初期パラメータを指定する必要があります。

フォーム フィールドのラベル表示

コード リスト 9-9 の行 5 で、フィールドのラベルを表示します。

<adk:label name='serviceName' required='true'/>

表示する値は、ユーザのメッセージ バンドルから取得します。required 属性により、ユーザによるこのパラメータの指定が必須かどうかを示します。

テキスト フィールド サイズの表示

コード リスト 9-9 の行 6 で、テキスト フィールドにサイズ 50、最大長 100 が設定されます。

<adk:text name='serviceName' maxlength='100' size='50'/>

フォームの送信ボタンの表示

コード リスト 9-9 の行 9 で、アダプタのユーザが入力を送信するためのボタンをフォームに表示します。

<adk:submit name='addservc_submit' doAction='addservc'/>

ボタンのラベルは、addservc_submit キーを使用してメッセージ バンドルから取得されます。フォーム データを送信すると、ControllerServlet が登録済みの RequestHandler (RequestHandlerClass プロパティを参照) で addservc メソッドを検索し、リクエスト データをリクエスト ハンドラに渡します。

その他のフィールドの追加

サービスの定義に必要なその他のフィールドを追加する必要があります。複数のフィールドを使用したフォームの例については、「DBMS サンプル アダプタを使用したアダプタ開発方法の学習」を参照してください。

手順 5d : イベントおよびサービスの編集機能の実装 (省略可能)

設計時にアダプタのユーザに対してイベントやサービスを編集する機能を有効にする場合は、アダプタ プロパティを編集し、edtservc.jspedtevent.jsp のフォームを作成して、特定のメソッドを実装する必要があります。ここでは、以下のタスクについて説明します。

注意 : この手順は省略可能です。ユーザにこれらの機能を提供する必要はありません。

アダプタ プロパティ ファイルの更新

最初にアダプタ プロパティ ファイルを以下のように変更し、サンプル アダプタに合わせてシステム プロパティを更新します。

アダプタ プロパティ ファイルを更新した後、新しいファイルを元のファイルと比較し、同期していることを確認します。

edtservc.jsp および addservc.jsp の作成

これらの JSP は編集機能を提供するために呼び出されるファイルです。編集 JSP ファイルと追加 JSP ファイルの主な違いは、記述子の値のロード方法です。編集 JSP ファイルは、既存の記述子の値をロードします。このため、DBMS サンプル アダプタでの編集および追加には、同じ HTML ファイルを使用します。

これらの HTML ファイルは各 JSP ページに静的にインクルードされます。これにより、JSP/HTML とプロパティを複製する必要がなくなります。記述子の値は編集ページに表示するコントロールにマップされます。ここから、任意の変更を送信できます。

記述子に定義された値でコントロールを初期化するには、AbstractDesignTimeRequestHandlerloadEvent/ServiceDescriptorProperties() メソッドを呼び出します。このメソッドにより、サービスのプロパティがすべて、RequestHandler に設定されます。これらの値を設定すると、RequestHandler により JSP ファイルで使用する ADK コントロールに各値がマップされます。

loadEvent/ServiceDescriptorProperties() をデフォルトの設定で実装すると、ADK タグに関連付けられたプロパティ名を使用して、記述子の値がマップされます。ADK タグ名以外の値を使用してサービスやイベントのプロパティをマップする場合は、これらの値をオーバーライドして ADK タグ名マッピングに記述子を渡す必要があります。

また、HTML を解決する前に、RequestHandler を初期化する必要があります。この初期化は 1 度だけ実行します。edtevent.jsp のロード時に使用するコード例をコード リスト 9-10 に示します。

コード リスト 9-10 edtevent.jsp のロード時に使用するサンプル コード
if(request.getParameter("eventName") != null){
handler.loadEventDescriptorProperties(request);
}

edtservc.jsp ファイルを edtservc に送信する必要があります。

<adk:submit name='edtservc_submit' doAction='edtservc'/>

edtevent.jsp ファイルを edtevent に送信する必要があります。

<adk:submit name='edtevent_submit' doAction='edtevent'/>

以下の場所の DBMS サンプル アダプタに例を示します。

WLI_HOME/adapters/dbms/src/war

メソッドの実装

最後に、表 9-6 に示すメソッドを実装します。

表 9-6 edtservc.jsp および edtevent.jsp で実装するメソッド
メソッド
説明
loadServiceDescriptorProperties
および
loadEventDescriptorProperties
これらのメソッドにより、RequestHandler に ADK のタグから値へのマッピング機能が提供される。開発者が同じ値を使用して ADK タグに名前を付け、サービス/イベント記述子をロードする場合、マッピングはフリーになる。これ以外の場合は、開発者が DesigntimeRequestHandler のこれらのメソッドをオーバーライドしてマッピングを行う必要がある。
boolean supportsEditableServices()
および
boolean supportsEditableEvents()
これらのメソッドはマーカとして使用する。これらのメソッドが返す値が true の場合は、アプリケーション ビュー管理ページに編集リンクが表示される。DesigntimeRequestHandler のオーバーライドがサポートされている。
editServiceDescriptor
および
editEventDescriptor
これらのメソッドを使用して、編集済みのサービス データまたはイベント データを永続化する。これらのメソッドにより、要求から ADK タグ値が抽出され、これがサービス記述子またはイベント記述子に追加される。また、これらのメソッドではイベントまたはサービスに関連するスキーマの特別な処理を行う。スキーマの変更が必要な場合は、ここで更新する。要求から読み取った値が必要なくなった場合は、RequestHandler から削除する必要がある。

各メソッドの実装例については、サンプル アダプタを参照してください。

手順 5e : Web アプリケーション デプロイメント記述子の記述

一般に、アダプタ用の web.xml 記述子と weblogic.xml 記述子により、単純なパターンに従って、設計時 Web アプリケーションのすべての JSP ページ名と、設計時 Web アプリケーションのその他の設定情報がリストされます。多くのアダプタの Web 記述子は非常に似ているため、ADK には自動的に Web 記述子を生成する方法が用意されています。そのためアダプタ開発者は、サイズが大きく、他のアダプタの Web 記述子とほとんど一致するような Web 記述子を管理する必要がなくなります。

使用するアダプタの Ant build.xml で特別な Ant 対象をインクルードおよび呼び出すことで、Web アプリケーション記述子を生成しなければならないことがあります。GenerateAdapterTemplate を使用して ADK サンプル アダプタのクローンを作成する場合、作成される build.xml には必要な Ant 対象およびその対象を使用するための呼び出しがすでに含まれています。WLI_HOME/adapters/sample/project/build.xml を参照して、generate_web_descriptors 対象を検索してください。この Ant 対象には web-gen.properties と呼ばれるファイルがあり、そこに格納されている情報から web.xml および weblogic.xml 記述子を生成します。サンプル アダプタ build.xml では、この対象は packages 対象の最上位付近で呼び出されます。

サンプル アダプタには、アダプタに指定する際のテンプレートとして機能する web-gen.properties ファイルが含まれています。このファイルで設定するプロパティとその意味を以下に示します。

 


手順 6 : ルック アンド フィールの実装

設計時 GUI の開発時に採用すべき重要なプログラミング手法は、アプリケーション ビューで使用するすべてのページで一貫したルック アンド フィールを実装することです。ルック アンド フィールは display.jsp によって決定されます。このページは ADK に組み込まれており、設計時 Web アプリケーションに以下の利点をもたらします。

一連のページで一貫したルック アンド フィールを実装するには

  1. サンプル アダプタの display.jsp を出発点とします。例については、WLI_HOME/adapters/sample/src/war/WEB-INF/web.xml を参照してください。
  2. HTML を使用して、独自のルック アンド フィールか社内の統一基準に従って、ルック アンド フィールのマークアップを変更します。
  3. HTML マークアップのいずれかの場所に、次の行を追加します。
  4. <%pageContext.include(sbPage.toString());%>

    このコードは、別のページをインクルードする際に使用するカスタム JSP タグです。このタグでは、JSP スクリプトレット sbPage.toString() を使用して、HTML または JSP ページを表示ページにインクルードします。sbPage.toString() は、実行時に content (HTTP リクエスト パラメータ) の値の妥当性を検証します。

 


手順 7 : 環境変数の実装

この手順は省略可能です。環境変数は、システム管理者や WebLogic Integration アプリケーション デプロイヤが、デプロイ対象の環境に応じて環境固有の情報に新しい値を指定できるように、アプリケーション ビュー内にある環境固有の情報を分離するためのものです。環境に固有と判断できるイベントやサービスのプロパティがアダプタに含まれていない場合は、アダプタで環境変数を実装する必要はありません。DBMS サンプル アダプタでイベントやサービスのプロパティに含まれる環境固有の情報の例としては、以下のものがあります。

環境変数を実装するかどうかを決定する場合には、イベントおよびサービス接続情報は考慮しないでください。本来、接続情報は、接続先の EIS インスタンスに固有のものです。環境変数は、イベントおよびサービスを定義する際に環境固有の情報を分離するためにのみ使用されます。

アダプタで環境変数のサポート機能を実装する場合は、アダプタの設計時 GUI と実行時段階の両方でこのサポート機能を設定する必要があります。実行時の考慮事項の詳細については、「サービス アダプタの開発」を参照してください。

設計時 GUI では、以下の 2 種類の手順で、環境変数のサポート機能を追加できます。

手順 7a : 変数セットの表示および編集

アプリケーション ビューの変数セットを表示および編集する際によく使われる方法は、イベントとサービスを定義する JSP ページに varset.jsp JSP ページを追加する方法です。これは、以下の JSP コードを追加することで実行できます。

<p>
<hr>
<p>

<jsp:include page='varset.jsp'>
  <jsp:param name='mode' value='writeable'/>
  <jsp:param name='hostPage' value='addservc'/>
</jsp:include>

これにより、アプリケーション ビューの環境変数を表示および編集するときに、水平線の下にテーブルが表示されます。この varset.jsp テーブルで、ユーザが変数の定義を追加、削除、および編集できます。varset.jsp JSP の使用例については、DBMS サンプル アダプタを参照してください。このコードの mode パラメータは常に writable にし、hostPage パラメータは、変数セット JSP をホストしている JSP の名前にする必要があります (.jsp 拡張子は付けない)。

注意 : varset.jsp JSP ページを使用せずに、独自の変数を定義することができます。com.bea.connector パッケージで定義されている IMutableVariableSet インタフェースを使用して、アプリケーション ビューに定義された変数を制御できます。以下のコードは、アプリケーション ビュー記述子を取得し、これに対して myVariable という新しい変数を定義する方法を示します。
import com.bea.wlai.common.IApplicationViewDescriptor;
import com.bea.connector.IMutableVariableSet;

IApplicationViewDescriptor avd = getApplicationViewDescriptor();
IMutableVariableSet varSet = avd.getMutableVariableSet();

// 変数を追加する
IVariable myVar = varSet.addVariable("myVariable", "string", "My Variable",
"the default value");

// 次に、変数を削除する
varSet.removeVariable("myVariable");

手順 7b : 変数セットの使用

varset.jsp JSP ページを追加してあれば、このページで定義できる環境変数を使用することができます。環境変数の使用方法は、アダプタの性質と、アダプタに保持される環境固有の情報によって異なります。

通常、環境変数を使用して設定するのは、イベントまたはサービスのプロパティの値の一部またはすべてのいずれかです。実行時に環境変数によって設定される値は、デフォルト値にすることも、システム管理者またはアプリケーション デプロイヤが変数に設定した特定の値にすることもできます。変数をプロパティの値の一部に使用するか、その値全体に使用するかは、作成者が決定できます。

DBMS サンプル アダプタでは、場合により、変数をプロパティ値全体として使用したり (たとえば、イベントのカタログ名やスキーマ名)、プロパティ値の一部として使用したり (たとえば、サービスの SQL 文中のカタログ名やスキーマ名) しています。DBMS サンプル アダプタでは、変数名に中括弧を付けて {var_name} と表記することで、環境変数が使用されていることを示しています。イベントとサービスのいずれでもこの構文が使用されます。中括弧で変数名を区切るのは、中括弧が SQL 構文では予約された文字でも有効な文字でもないためです。したがって、DBMS サンプル アダプタでは、パーサで混同が生じることなく、SQL 文で確実に中括弧を解析できます。

アダプタでは、プロパティ値で変数参照をユニークかつ安全に識別するためのさまざまな規約が必要となる場合があります。

イベントおよびサービスのプロパティ値で変数参照を表記する方法を決定すると、これらのプロパティ値で使用されている変数を検証するときに必要なコードを記述できます。以下の規則が適用されます。

実行時に、Application Integration エンジンにより変数とその値がセットで設定されます。実行時のアダプタ コードでは、設定済みプロパティ値のすべての変数参照の代わりに、変数の実行時の値を使用する必要があります。詳細については、「サービス アダプタの開発」または「イベント アダプタの開発」を参照してください。

varset.jsp によって (設計時に) 定義された変数のリストを入手するには、スーパークラス (AbstractDesignTimeRequestHandler) メソッドの呼び出しにより設定される IApplicationViewDescriptor を取得します。

import com.bea.connector.IVariableSet;

IApplicationViewDescriptor avd = getApplicationViewDescriptor();
IVariableSet varSet = avd.getVariableSet();

// 変数名をリストに表示する

String[] varNames = varSet.listVariableNames();

// 最初の変数を取得する

IVariable var = varSet.getVariable(varNames[0]);

 


手順 8 : サンプル アダプタの設計時インタフェースのテスト

WebLogic Integration には、サンプル アダプタの設計時インタフェースの基本機能を検証するためのテスト ドライバが用意されています。このテスト ドライバは、http://www.httpunit.org にあるテスト用 Web インタフェースのフレームワークである HTTP ユニットを基準に作成されています。HTTP ユニットは、JUnit テスト フレームワーク (http://www.junit.org で入手可) に関連しています。HTTP ユニットと JUnit の両バージョンが WebLogic Integration に組み込まれています。

テスト ドライバではいくつかのテストが実行されます。これによりアプリケーション ビューが作成されてイベントとサービスの両方がアプリケーション ビューに追加され、アプリケーション ビューにデプロイ/アンデプロイを実行し、イベントとサービスの両方についてテストを実行します。正常に実行が終了すると、テスト ドライバはすべてのアプリケーション ビューを削除します。

ファイルおよびクラス

すべてのテスト ケースが、DesignTimeTestCase クラス、または対応する親クラス (AdapterDesignTimeTestCase) で有効です。DesignTimeTestCase クラス (sample.web パッケージ、および WLI_HOME/adapters/sample/src/sample/web フォルダ内) には、サンプル アダプタに固有のテストが組み込まれています。AdapterDesignTimeTestCase (com.bea.adapter.web パッケージ、および WLI_HOME/lib/adk-web.jar ファイル内) には、すべてのアダプタと一部の便利なメソッドに適用されるテストが組み込まれています。

テストの実行

設計時インタフェースをテストするには、以下の一連の手順を実行します。

  1. サンプル アダプタをデプロイして、WebLogic Server を起動します。次に、現在の作業フォルダを特定のプロジェクト フォルダに変更して、以下の手順で setenv コマンドを実行します。
  2. WLI_HOME に移動し、コマンド プロンプトで setenv と入力します。
  3. setenv コマンドにより、手順 3 の実行に必要な環境が設定されます。

  4. コマンド プロンプトで以下のように入力して、サンプル アダプタの Web フォルダに移動します。
  5. cd WLI_HOME/adapters/sample/project
  6. designTimeTestCase.properties ファイルを編集します。実行するテスト ケースのリストを含む行に、web.DesignTimeTestCase を追加します。以下のような行になります。
  7. test.case=web.DesignTimeTestCase
  8. ファイルの末尾付近で、ユーザ名とパスワードの 2 つのエントリの値の変更が必要になる場合があります。テスト ドライバが WebLogic Integration に接続する際に使用するユーザ名とパスワードを指定します。
  9. test.properties ファイルを編集した後、WebLogic Server を起動します。
  10. コマンド プロンプトで以下のコマンドを入力してテストを実行します。
  11. ant designtimetest

  ページの先頭       前  次